Rewarding Success on a Project
The best way to get IT systems built on time is by rewarding success on a project.
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 it can never be done any quicker. Parkinson’s Law will kick in unless there is an antidote to it. And few projects are ever run with an antidote.
What happens, normally, is that at the planning stage, the project is split into tasks and time allocated to these tasks. Once a number of days is allocated 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.
On Time or Late
Why are tasks seldom finished ahead of schedule? 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.
What can be done 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. If 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 be done 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 the estimates are published, 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, developers should be challenged.
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 per month and that the task is estimated at 20 Function Points.
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 performance bonuses. The performance bonuses should be related to their own performance, the performance of their project area, and the performance of the project as a whole.
Most organisations, who pay bonuses, pay too little to motivate their developers. These bonuses should be related to how much the project team save the organisation.
If the estimate is based on previous productivity, then the project team should get 25 – 50% of what they save the organisation. Organisations, especially when the Finance Director is present, tend to get too greedy when allocating a percentage of the savings to the developers. As a result they are not motivated and there are no savings, just additional costs.
A good example is in the City of London where traders earn most of their money by making lots of money for their companies. The difference here is that the developers would make most of their money by saving their organisations lots of money.
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.