How to motivate People to finish ahead of Schedule

Motivate People

How to Motivate People

One of the most important tasks on a project is how to motivate people to finish ahead of schedule – yet so few project do it. Indeed they will punish you for it.

My first ever job in computing was for Barclay’s 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.

Program Scheduled

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.

Finishing Work Early

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 two 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.

Project Supply Chain to Motivate People

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 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.

Continuous Improvement

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 batting averages.

People want  to improve. You have to motivate people properly though. 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 – Getting it Right

Rewarding Success on an IT 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 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.

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.

Productivity Metrics

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.

Reward Mechanisms

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.

Monetary Rewards

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.

Motivating People – Black Dan Developers

Motivating People

Motivating People on a Project

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.

Objective Measures

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.

Productivity through Motivation on a Software Project

Productivity Through Motivation

Productivity through Motivation

One of the greatest gains you can make on a software project is better productivity through motivation.

The great American Football coach, Vince Lombardi, once said that there are a lot of coaches who can improve the team tactically but that the really successful ones are those that can get “inside those guys’ heads and bring the best out of them”.

I have asked many people who work as developers in the industry how much more productive they could be if they were really motivated. Most of these have many years of experience. The answers they give me are usually in the range of being 50% to 200% more productive. I won’t name them here. When asked what would motivate them to achieve these greater rates of productivity they usually answer that if they were working for themselves they could achieve those levels.

Doubly Productive

It is very interesting to note that your project members could be, on average, doubly productive if truly motivated. Maybe they will never give you the same productivity that they would give themselves. You should be able to unlock some of these productivity gains, though, if you simulate, as far as possible, working for themselves.

You should create the conditions in which they profit (and profit well) from their productivity gains. You should use the model of the City of London traders. They are trained well, given a base salary, motivated by a sharing of rewards, and set free to make money for their companies and for themselves.

Best Developers

By doing something similar, it would be easier to keep your best developers and to stop them going freelance. So, by giving them a base salary and a pension you give them security. Also, by giving them a chance to earn large bonuses by bringing in projects, and their parts of the project, ahead of budget and schedule, you give them the chance to make money.

With this mixture of security and earning potential, and possibly career progression as well, why would anyone want to leave to become freelance? Why, indeed, would they want to take another permanent job with another company which has backward practices, low rewards, and fewer opportunities to achieve and be recognised.

Imagine All Your People

Therefore, imagine a company where the people are highly motivated, have security, are well rewarded, and have high self-esteem through high (and constantly improving) productivity. This company will retain its best people and their business knowledge. It will, as a result, produce software of better quality and with better time-to-market than its competitors.

People’s morale, as a result, will be high. Customers will be highly satisfied. They will, also, gain market share and have high margins. The Finance Director will smile. The shareholders will be rich. They will reward their senior management. This company, as a result, will be a world beater. There’s absolutely no reason why this company could not be yours.

It is not easy. Any change is resisted. To be forewarned, however, is to be forearmed. Productivity through motivation, therefore, is the best way to get it.

Keeping Your Best People – The Winter Holocaust

Keeping Your Best People

Keeping Your Best People – The Winter Holocaust

Keeping your best people is one of the major factors to success.

At a company where I was Chief Information Officer we used to hold People Satisfaction Surveys based on categories like career prospects, remuneration, management, the working environment etc. We held these every three months, in January, April, July, and October. One thing that we found was that morale was seasonally affected.

Morale was highest in October, dipping in January, hitting its bottom in April after a long hard winter and picking up again in July. We also found that the People Satisfaction Survey was a good leading indicator (by about 2-3 months) for staff attrition. When people are feeling at their lowest, they send out their CVs.

Lower Morale

During the winter people come to work in the dark and leave in the dark. It is not just this factor, though, that causes lower people morale. More projects are implemented in the winter (January 1st being a favourite implementation date). Because of staff holidays fewer projects are implemented in summer.

Therefore, people are working longer and harder in the winter on projects which are probably failing without much thanks or encouragement from management. While people are working, vis inertia kicks in and they don’t find time to compile their CVs. It’s only when they have a few days away like at Christmas, Easter or one of the spring bank holidays that they start to assess whether it is worth it. Many decide it isn’t.

Keeping Your Best People – Social Activities

To be forewarned is to be forearmed. The dark days of January, February and March are the time when you should organise social activities. At this company, we used to always hold the Software Academy Awards in February. There were various awards like best manager, best developer, best business analyst etc.

Everyone in the IT department voted for these categories. We organised an awards evening, with the sports and social club meeting most of the expenses. We invited senior management. We made presentations, in reverse order, to the top three in each category. We gave each of the first three a certificate.

Keeping Your Best People – Winners

We have the winners fifty pounds in the serious categories and a bottle of champagne in the joke categories. The people organised it for the people. It engendered much interest in the two weeks before and for a few days afterwards The fact that the award was given by their peers, and that the handing over of the award was witnessed by senior management, was important.

This one event won’t sustain morale throughout the whole winter but it will contribute to it. I’ve often thought of having another awards night with the awards being decided by management. This, however, is fraught with danger. As it is outside work hours, will people turn up to see what may be perceived as ‘management lackeys’ receive their awards?

Keeping Your Best People – Pay Rises

This time of the year is probably a good time of the year to give out pay rises and promotions. At the very least it will narrow the differential between what you are paying and what they could receive in the marketplace. Once the CVs are sent out you are probably too late. When the staff agencies are sweet talking your people, and other companies are keen to have them, the grass seems an awful lot greener on the other side.

It’s counterproductive to try to keep them once they’ve resigned. They usually refuse but tell the rest of your people you’ve made the offer. It becomes the perceived wisdom among the remaining people the only way to get ahead in the company is to resign. This is not good for morale.

When people do resign, companies usually either try to make them work their full notice period (being crucial to the project) or they have them out the door that day (sometimes supervised by the security guard and marched out the door). The first is not clever. People who are going are not motivated to work. They usually spend the time de-motivating other people. It is usually people who are close to them who are next to leave the company.

Too Harsh

The second way is too harsh. They have friends and colleagues who remain at the company. People will not appreciate one of their members who have given good service to the company being ceremoniously or unceremoniously ejected. They will feel that the company does not appreciate good service.

It is better, and gentler, to give them a couple of days to pass their work over to someone else. You are going to lose them anyway. You might as well get used to it. A couple of days is also not enough for them to seriously disaffect the other members of staff. They are usually in the first flush after their resignation and feeling kindly towards their old company. Thank them, at their leaving speech, for all the good work they’ve done for the company and wish them well in their new job. This is relatively painless and everyone is reasonably happy.

Keeping your best people is crucial to your success.