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:
- they'll spend around 8 hours working on the other stuff
- usually in bursts of no more than an hour at a time
- they'll wont be able to schedule this downtime - instead they'll be completely interrupt driven
- these interrupts will, in full accordance with Murphy's Law, invariably come at the most inconvenient time relative to the work they're currently doing
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.
January 18, 2006
Recipes For Disaster #116: Goal Misalignment
- Remove any power over project resourcing from the people responsible for the successful delivery of the project
- Remove any responsibility for the successful delivery of the project from the people with the power over project resourcing
- Sit back, relax... hijinks will ensue