Project Schedules
This article, about finishing ahead of project schedules, is the fourth in a series of eleven by Gerry McLaughlin.
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 one can never do it any quicker. Parkinson’s Law will kick in unless there is an antidote to it. And they run few projects with an antidote. They almost always go beyond the project schedule and budget.
What happens, normally, is that at the planning stage, they split the project into tasks and allocate time to these tasks. Once they allocate a number of days to a task, that then becomes the minimum that a task will take.
A project is therefore a series of tasks that finish on schedule and some that finish late. The hope is that the late tasks do not add up to a figure that is beyond your contingency on the project schedules.
Software Projects On Time or Late
Why do tasks seldom finish ahead of project schedules? 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.
What can one do to encourage them to finish ahead of project schedules? The answer is to challenge them, appreciate them and reward them for it.
Productivity Depends on Who‘s Estimating?
Barry Boehm, of Cocomo fame, once calculated project productivity according to whoever estimated the tasks.
If a programmer’s supervisor estimates the task, productivity is 6.
When the programmer himself estimates the task, productivity is 7.
If the analyst who wrote the specification estimates the task the productivity is 8.
If there is no estimate at all the productivity is 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.
Must Have Project Estimates
What can one 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 the estimates are on paper, 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 telling them that they have, for example, 20 days to complete a task, one should tell them that their productivity is 20 Function Points per month and that one estimates the task at 20 Function Points.
Change in Project Psychology
This is a chancge in psychology on the project.
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 the pressure is on them.
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.
Rewarding Project Results
This relies of course on your having productivity metrics for individual programmers. Individual organisations can decide whether they should publish these metrics 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’. One can cure this by not making productivity the only criteria for rewarding project personnel.
Teamwork, for example, should be another criterium for reward. 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.
Productivity Metrics Useful to Management
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.
Pay for Performan
ce Based Success
The best way to keep them is by paying them a base salary plus performance bonuses. You should relate the performance bonuses 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.
You should relate these bonuses to how much the project team save the organisation. If the estimate is based on previous productivity, then the project team should receive 25 – 50% of what their efforts save the organisation.
Organisations, especially when the Finance Director is present, tend to get over 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.
City of London Rewards Model
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.
They will not only equal, but beat, project schedules.
For more great advice on managing projects click on Project Management.
Ad – Contractor Services
If you do need an umbrella company you could try one of the following:-
Public Sector Umbrella Company
Or would you prefer to get expert advice about which umbrella company is right for your specific needs? If so fill in the form below and they will be in touch.
For all necessary business insurance, including IR35, try Business Insurance for Contractors
