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 you can never do it any quicker. Parkinson’s Law will kick in unless there is an antidote to it. And few Project Managers ever run projects 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 do people seldom finish tasks 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 even tighter for them. They soon learn not to make a rod for their own back. They learn to pace themselves.
Finished Ahead of Schedule
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. Rewarding Success is crucial to get more of 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 means people either finish tasks on time or late.
Project Without Estimates
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. However, 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, you 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 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’. You can cure this by not making productivity the only criteria for rewarding project personnel.
Rewarding Success – Teamwork
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. Rewarding Success is a really good way to do it.
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, they will probably leave 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 this reward does not motivate them. The project doesn’t save anything. There are 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.
Rewarding Success is vital to the success of the project.