IT Developers Productivity – Why Software Projects are Never Under Budget
Can IT developers productivity be higher?
A Chief Finance Officer of my acquaintance used to say when given estimates that were supposedly accurate to plus or minus 30%, “There’s no such thing as minus 30% in an estimate. The only hope is that it doesn’t go beyond the plus 30%”.
He is absolutely right. Once an estimate is in place you can never do the work any quicker. Parkinson’s Law will kick in unless there is an antidote to it. And companies run few projects with an antidote.
What happens, normally, is that at the planning stage, they split the project into tasks and you allocate time to these tasks.
Once you allocate a number of days to a task, that then becomes the minimum that a task will take.
A project is therefore composed of tasks that are finished on schedule and some that are finished late. The hope is that the late tasks do not add up to a figure that is beyond your contingency.
Why do people seldom finish tasks ahead of schedule?
The reason is because there is ‘nothing in it’ for the developer to finish ahead of schedule.
If they ever do, they soon find the task estimates becoming tighter for them. They soon learn not to make a rod for their own back. They learn to pace themselves.
How to motivate People to finish ahead of Schedule
What can you do to encourage them to finish ahead of schedule? The answer is to challenge them, appreciate them and reward them for it.
Barry Boehm, of Cocomo fame, once calculated project productivity according to whoever estimated the tasks.
If a programmer’s supervisor estimated the task, productivity was 6.
When the programmer himself estimated the task, productivity was 7. If the analyst who wrote the specification estimated the task the productivity was 8.
If there was no estimate at all the productivity was 11.
This is not surprising. Parkinson’s law and the fact that there is ‘nothing in it’ for developers to finish ahead of schedule mean that tasks are either finished on time or late.
What can you do with Barry Boehm’s information?
You can’t run projects without estimates or plans. Senior Management would never authorise the project in the first place, but as soon as they publish the estimates, they are no longer estimates, they are minimum times.
There is only plus 30%, no minus 30%.
The answer is that Project Plans must exist for reporting purposes to senior management but there is no need to publish these plans to developers.
Instead, one should challenge developers.
Instead of being told that they have, for example, 20 days to complete a task, they should be told that their productivity is 20 Function Points, or some other productivity measure, per month and that the task is estimated at 20 Function Points.
Motivating Rather Than Threatening
This is a change in psychology. Everyone wants to become better.
The first way, i.e. number of days, is threatening to them. It is implicit in the estimate that when the time is up they will come under pressure and may be in trouble.
The second way is a challenge to them. A task which they complete at a faster rate than their norm gives them a sense of well being in that they are getting better at their chosen profession. A task which they complete at a slower rate than their norm is a lost opportunity to better themselves.
This relies of course on you having productivity metrics for individual programmers.
Individual organisations can decide whether these metrics should be published or not.
There are pros and cons.
Some people say that people would stop helping other people as this would cut their own productivity rate and not allow them to progress up the ‘cricket averages’.
This can be cured by not making productivity the only criteria for rewarding project personnel.
Teamwork, for example, should be another reward criteria.
The England international cricket selectors do not just pick the players who are top of the batting and bowling averages. On balance, I would tend to publish the individual productivity averages as this would tend to challenge people to not only better themselves but to become the best.
These productivity metrics are also useful to management. They need to find ways of keeping those with high productivity at the company.
It shouldn’t be the case that people have to be promoted into management in order to obtain rewards. You may gain a poor manager and lose a highly productive developer.
If you do not reward those who want to remain as developers, you will probably lose them from your organisation. To earn money commensurate with their ability, they will probably become freelance.
You will probably have to hire expensive freelancers, who have no knowledge of your systems, to replace them.
The best way to keep them is by paying them a base salary plus the aforementioned project performance bonuses.
An organisation which keeps most of its best developers, who also have systems knowledge, and who become more and more productive with each project, is going to be powerfully placed to develop computer systems competitively.
IT Developers productivity could be much higher.
For other insights into running successful projects see Project Manager Man