How Heroes Can Harm the Team Work

I had an opportunity to participate in a very urgent service ramp-up project as a mentor and observer. The project schedule was very tight (10 weeks), team members (total 8 including project manager) did not know each other very well, and the target was – set by the management – quite sketchy.

Because of the urgency and importance of the project, the management wanted to have one senior level member in the team in order to guarantee the outcome.

Unfortunately he – let’s call him Peter – was a hero. Let me share a story with you.

A very common pattern

Peter’s background was in process development, lean project management, and from the IT operations. He had been very successful in his work. As a seasoned professional – and as a very clever guy indeed – he was burdened by loads of other tasks as well – simultaneously he also had succeeded in getting some privileges of his own. One of them was a right to determine the schedule of his tasks within the project. Others did not mind that, or did not understand that they should mind that, as he showed undeniably how high-class and just-in-time his outcomes had been. More over his IT related tasks were ”independent as such, so only the outcome counts” as he chose to put it.

Peter defined that his part of tasks could be done more or less in one weekend, just couple of weeks before the ultimate deadline. Other team members could work together constantly and finalize their jobs after Peter’s delivery.

Team started to work and as promised Peter worked furiously during a long weekend.

Next week the team’s work progress collapsed. There were severe problems for the rest of the team in finalizing their jobs. And it was time for the management to call up a crisis meeting. In this meeting Peter showed in the very detail level, where the problems were and despite the fact that the original scope could be achieved only 70%, the management was pleased. ”He did it again!” as the head of the Steering Team said to a colleague.

What really happened?

The above-mentioned case is a typical malfunction; I call that as a synchronization problem. Synchronization is about the timing of issues, tasks, communication, decisions etc, so that the total delivery throughput is in optimum.

So what happened? Let’s analyze this case.

When the project was started every stakeholder in the project had his or her own understanding of the target (Pic1a).

They could not have a coherent understanding because they were ”strangers” to each other, and hence forced to use time to get more aligned understanding of the common project target.

The rest of the team worked, communicated and shared information with each other until when Peter started his tasks (t=8 weeks), the rest of the team had much more aligned understanding of the target comparing to Peter’s one (Pic1b). So Peter and the rest of team had partly (lets suppose 30%) different view of the target area.

When Peter started his task, he either had an assumption, that the target is the same as in the beginning or he got feedback and realized, that the target is only partly of the original and hence his work load estimations might be incorrect.

In both cases, there is a remarkable redundancy in team efficiency.

Lets imagine that Peter carries on with the first option. He makes only 70 % of the common target work and – because of the time schedule restrictions – others had done totally (10 weeks – 2 weeks)*0.3*(7 persons) = 16.8 weeks, which means 21% of redundancy in team’s total work.

If Peter understands (which is more probable), that the original target has changed, he has to adapt the situation somehow. There are roughly three (3) areas to adapt:

1. Outcome’s scope (V=Volume)
2. Outcomes quality (Q=Quality)
3. Outcomes Timing (T=Time left)

These variables are ideally linked together: VQ/T = constant. For instance if you want to squeeze the schedule, you have to give up either scope or quality.

Let us continue with the case. So Peter then has options either to decrease the quality (meaning cutting corners), ask for more time or not to do all things that are in the scope. But because he is a hero, he wouldn’t give up what he has promised and what can be seen easily. Therefore he keep the schedule(T) and Quality(Q) but squeeze the scope (V) 30% from the original. And this implies the same amount of redundancy as above.

It is important to understand, that the problem is not the workload itself, but the distribution of activities within the timeframe.

Result: a very costly equation

Peter’s workload in a team is only 1/8, but the total redundancy impact because of the dis-synchronization is around 17 weeks!

Peter’s ”heroism” is just one example and can be very useful in a certain context. We can easily imagine that if the team has not only one but several members, who are not acting in a synchronized manner, the amount of redundancy work can increase to intolerable extent. This equation is not only about money, it is about productivity and well-being of the people as well.

Have you met heroes in your work environment? I will continue to write about this topic and other challenges that projects suffer from. Meanwhile I’d love to hear your story and experiences. Glad if you share those in the comments section.

Pekka Ylisirniö