I once asked one of our project managers why he communicated a different milestone deadline to the engineering team than what was scheduled in the project plan. He replied that he wanted to put the team under pressure to deliver!! Interestingly, he is not the only one that thinks this way. It is a commonly held belief that putting the engineering team under undue pressure is the key to boosting productivity, yet most software projects still end up overrunning.
Another commonly held belief is that programmers are bad at estimating work and as such are usually not involved the project estimation phase. This leads to unrealistic timelines that puts undue pressure on the engineering team, yet such projects still end up overrunning.
Managers tend to believe that creating tighter project schedules is key to improving productivity
When it comes to estimating work, a typical conversation between a manager and the software engineer could go like this:
Manager: “How long will it take to deliver the features?”
Programmer: “Hmmm….I think it may take 3 months”
Manager: “haba!! That’s too long… Is it not just to develop these 20 interfaces and integrate with……..? That should not take more than 1 week.”
Programmer: “the work is a lot ooo… I still have to develop the architecture….. and then I need to do the authentication….. and then i have to integrate with …….”
Manager: “ehen!!!!….all that should not take you more than 2 weeks!!!….You programmers of nowadays….I used to be a developer myself many years ago….I know what I am talking about..”
Programmer: “hah!!!…there are many dependencies that you are not considering….. For example, i still have not received the API for…..”
Manager: “EHN!!!! What do you mean you don’t have the API ???”
****Manager picks up phone and shouts down at another programmer to deliver API by close of business****
Manager: “You will get the API today……But we need this delivered in 2 weeks or we can all start looking for new jobs…..”
****Programmer walks away thinking to himself how this manager is totally the worst manager in history****
The conversation above is possibly an exaggerated version of a typical work estimation conversation but it still highlights a very important issue. Managers tend to believe that creating tighter project schedules is the key to improving productivity in their teams. In some organisations I have worked with, its almost the norm to set impossible timelines for technology projects.
The evidence however does not support this theory and many technology projects still end up overrunning. If anything, a culture of putting employees under constant pressure increases burnout rates and attrition rates.
In many cases, the development team have little input during the estimation of effort on projects…
The Vicious Cycle
Unfortunately, many software projects are stuck in the vicious cycle depicted in the diagram above (Figure 1). It goes something like this
1. The manager sets or agrees to an incredibly tight timeline for completion of a project.
2. This tight deadline puts immense pressure on the development team to work long hours and cut corners.
3. The pressure on the team to work quickly has the unintended effect of increasing mistakes and bugs in the application.
4. The increase in applications errors causes delays on the project.
5. The increased delays on the project puts pressure on the manager to get the project back on track.
6. The frustrated manager puts even more pressure on the development team.
7. And the whole cycle is repeated
The problem seems to stem from how the initial estimation of work is done – or to be more specific, who performs the initial work estimation
If you ask the manager why the project is experiencing so many delays, the productivity of the programmers will most likely be blamed.
But is this really a productivity issue or an estimation issue?
The problem seems to stem from how the initial estimation of work is done – or to be more specific, who performs the initial work estimation.
Who Performs the Work Estimation
Traditionally, management is responsible for setting high level objectives/timelines and then communicating these objectives/timelines downstream. The individual contributors are expected to accept these objectives/timelines as is and run with them.
This practice has also found its way into the planning of software projects. In many cases, the software development team have little input during the scoping/estimation phase of a project but they are expected to accept and delver on the prescribed project scope and timelines.
Out of the 103 software projects sampled, it was found that productivity was higher whenever the programmer set the estimate themselves.
However, research shows that software developers are much more productive after they have estimated work themselves compared to cases in which the manager did the estimates without consulting them.
In the book Peopleware: Productive Projects and Teams, the authors (Tom DeMarco and Timothy Lister) presented the results of a survey that set out to disprove the belief that programmers worked harder when they had estimated the work effort. However, this could not be disproved as the results in Table 1 shows. Out of the 103 software projects sampled, it was found that productivity was higher whenever the programmer set the estimate themselves.
Research does show that software developers seem to be a bit more productive after they have estimated work themselves….
This is really interesting research, given the misconception that programmers tend to be overly generous in their work estimates. As a former software engineer, I can definitely attest to padding work estimates in a few cases to give myself some wiggle in case issues prop up. However it is certainly not the case that programmers are bad at estimating work given they will be the ones to do the work anyway.
It could be that a principle of psychology is responsible for this behaviour in which programmers tend to be more productive when they have set the work estimates. In the book Influence: Science and Practice, Robert Cialdini discusses Commitment and Consistency as a key principle of influence. People have a general desire to appear consistent in their behaviour and as such will strongly stand by commitments they have made. It is certainly plausible that the reason programmers are more productive when they set their work estimates is due to their desire to appear consistent.
Moving Forward
It is understandable that managers may not be quite ready to relinquish their role in the project estimation phase. After all, managers also have the cross sight in taking other factors into consideration when estimating work – such factors like stakeholder expectations, budget, competitor activity and so on.
There is wisdom in having both managers and programmers jointly taking part during the project estimation phase. In the survey results shown in Table 1, programmers were also very productive when the supervisor and programmer estimated work as a joint effort.
By ensuring both the business and technical perspectives are taken into consideration during the software project estimation phase, managers can create more accurate project estimations. Beyond that, by ensuring programmers are involved in the work estimation effort, average team productivity can be greatly improved.
So there we have it. Involving both management and the engineering team in the project estimation phase goes a long way in producing more accurate project timelines and increasing team productivity.
What more can a happy manager ask for 😉
