How to motivate People to finish ahead of Schedule

How to motivate People to finish ahead of Schedule

One of the most important tasks on a project is in motivating people to finish ahead of schedule – yet so few project do it. Indeed you will be punished for it.

My first ever job in computing was for Barclays Bank. We worked at Juxon House just by St Paul’s Cathedral but the Computer Centre was in Willesden. The computer was there so that’s where we went to test. None of the bosses were over there so it was a bit more relaxed.

While busy testing another program I was given a program with an estimate of 15 days. I decided to really knock myself out and worked on it on the train going home and coming in and at home as well as in work. I got it finished in 3 days. I was delighted with myself. However, I was a bit knackered to after that.

Extra Days

So, what I decided I would do would be to stay for a couple of extra days at Willesden and just chill out. I would go back to Juxon House on the Monday with a program scheduled for 15 days that to their minds I did in 5 days.

Everyone would be pleased and it would be very positive for my career. So, for a couple of days I did nothing but read the papers and get sausage sandwiches from the canteen.


I felt I deserved that. However, when I got back to Juxon House the reaction wasn’t what I expected. Someone had reported to the big boss tow levels above me that I had been spending my time at Willesden reading papers and eating sausage sandwiches.

I argued that I had finished a 15 day program in 3 days and spent 2 days recovering. I was told that of I have finished a program in 3 days I should have asked for more work.

That’s when I realised that there were no kudos in finishing work early and I was never stupid enough to do so again. The only reward you would get was more work and probably tighter schedules.

This is one of the main reasons why developers only ever finish work on time or over time and one of the main reasons why project are late. They don’t motivate developers to finish their work early so it is always on time when they can and late when they can’t.

Marking System

However, I had a solution to this. When I said that developers got a mark out of 10 for timeliness, they didn’t get 10 for finishing on time. They got 7. If they wanted to get 8 or 9 or 10 they had to finish ahead of schedule. There was one developer called Adam Sandling that he had who consistently finished all his work ahead of schedule.

This was a huge bonus for the project as this helped to equalise out one or two other delays that we had on the project. It was crucial.


Another motivation for Adam was in improving as a developer. As we said earlier on we measured software by Function Points. We fed back to the developers how productive they were as measured in Function Points delivered per month. It’s a bit like the cricket or baseball betting averages.

People want  to improve. They want to be a 30 Function Points a month developer rather than a 20 Function Points a month developer. It is a measure of how good they are. Just like baseball or cricket players they want to getter themselves. It motivates them to become better. Now, there is motivation for them to finish work ahead of schedule.

Rewarding Success on a Project

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.

The Answer

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.

The Solution

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.

Psychology Change

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.

A Cut

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.

Motivating People – Black Dan Developers

Black Dan Developers – Motivating People

One way of motivating people is to give them a sense of achievement. Instead of threatening them with deadlines let them achieve.

My cousin is a fifth dan black belt at Karate. I thought that it was pretty good when he progressed through the various belts to become a black dan. I thought that this was it. He had arrived. I was even more surprised to find that he continued to progress through the dans and that he had become a bit of an expert. He had never been that confident before.

Now his self esteem is extremely high and he carries that into other areas of his life. He had left school at fifteen to go into the shipyards. After succeeding at karate he went back to university and got himself a university degree.

Software Developers

Compare that to software developers. There are trainee developers, developers, and senior developers. At senior developer you have arrived. And then you don’t go anywhere – no matter how much better you become at software development. To progress you have to do something else like business analysis or project leadership

I’m not suggesting that you should call people fifth dan senior developers (exposing yourself to ridicule), but perhaps you could have Expertise Level 5 senior developers. Achieving these levels could be related to their productivity levels, quality levels, and customer satisfaction levels etc.


If the measures are objective instead of based on management opinion, the developers know what they have to achieve instead of having them harass their managers at their reviews.

Striving for theses higher levels gives them objectives, keeps their interest, and motivates them towards continuous self-improvement. It also gives them status among their peers, status which they may not be able to transfer to another company.