« December 2005 | Main | February 2006 »

January 22, 2006

The problem with wearing many hats

The following situation has impacted my team on two of my last four projects. In both cases, members of my team (employed directly by the client) were in "multi-tasking" mode, moving between the project I was a part of and some other duties. Typically these duties were characterised as "business as usual" - support for previously deployed applications. I now recognize this for the project and organizational smell that it is.

The sales pitch that always goes along with these situations is something like "don't worry, they'll only spend one day a week on the other stuff, you have them for the rest of the time".

Indeed, if I could get them to condense all their non-project duties to fit into a single day each week, I wouldn't have much of a problem, but that's never the case. The devil-in-the-details of the "only spend one day a week" is really something along the lines of:

So the practical upshot of it all is that whilst they may spend only 20% of a working week on the "other stuff", the actual productive time spent on their principal activity is considerably less than 80%, probably more like 60-70%. Time lost through context-switching on behalf of the individual and extra communication on behalf of the team ensure that the efficiency of these people is considerably less than someone employed "full time" for only 4 days each week.

And usually the people involved are none-too-happy about the situation either. They often end up either guilty that they cannot commit 100% to either task and/or working considerable overtime to make up for the time they spend switching between tasks. Neither of these solutions is really effective in the long term.

To me, this sort of behaviour is just another example of companies attempting to understand/solve complex people issues by mapping them to vastly oversimplified quantitative models. Presumably, the principal of reductio ad absurdum suggests that the same people could have 100 different roles at any one time and still be able to devote a full 1% to each?

The underlying issues resulting in this situation seems to be a basic misunderstanding of the cost of a context-switch, a lack of sufficient communication on the BAU work, resulting in "Ted being the only person who understands that stuff" and a general reluctance to give project resourcing a sufficient degree of respect.

Posted by Andy Marks at 09:32 PM | Comments (4)

January 18, 2006

Recipes For Disaster #116: Goal Misalignment

  1. Remove any power over project resourcing from the people responsible for the successful delivery of the project
  2. Remove any responsibility for the successful delivery of the project from the people with the power over project resourcing
  3. Sit back, relax... hijinks will ensue

Posted by Andy Marks at 09:22 PM | Comments (0)