The Cost of Failed IT Projects

Failed IT projects

Failed IT Projects are costing companies and countries an absolute fortune every year. The cost of Failed IT Projects accumulated each year comes to more than the Gross National Product of some hefty sized countries.

Let me first of all give you some shocking facts related to the development of technology projects.

EU figures looking at 214 technology projects from 1998 to 2005 showed that only 1-in-8 technology projects met their time, budget and quality objectives.

Indeed the total cost of technology project overruns in the EU in 2004 was €142bn – yes, that’s billion.

They found that 23.8% of all projects don’t get finished at all.

Project Failure

A survey by KPMG in 2010 showed that  an incredible 70% of organizations had suffered at least one project failure in the prior 12 months!

A survey by Logica in 2008 showed that 35% of organizations abandoned a major project in the last 3 years.

A survey by KPMG in 2005 showed that only 2% of organisations said that their projects that year met all of their objectives.

Fixing Faults

According to Dosani 80% of technology projects cost more than they return because the benefits are overestimated and the costs underestimated.

According to the National Institute of Standards & Technology in the USA €60bn a year is spent on fixing faults in IT systems. Indeed 80% of the cost of a system is in making fixes to it.

In January 2013 it was announced that the Ministry of Defence had overrun by £468m on 16 projects in the past year with a total slippage of 139 months in the past year.

So, they have 16 projects that have overspent by an average of £29m each and they have slipped by an average of 8.7 monthseach   in the last 12 months.

There are some astonishing figures here that show that the world has not come to terms with successfully implementing software projects on a regular basis.

Just try getting the system you are going to develop insured against failure.

Change Needed

All over the world technology projects are failing and costing companies and countries incredible amounts of money.

Something has to change.

Companies need to take another look at the way they develop software. The whole paradigm is wrong.

Successful IT Projects

At one company where we ran IT projects for major companies like Texaco and Exxon (Esso) we managed to get 4 out of 5 projects done on time, with one of them well ahead of budget and ahead of schedule.

The only one that failed to deliver was one that we had to outsource as we didn’t have the right skills inhouse to do it.

Our people looked askance at the poor project management practices on the project as if they were looking at a backward people using backward methods and were not surprised when the project failed.

Huge Opportunity

Because there is such a huge problem there is also a huge opportunity. We intend to explain what needs to be done to get projects completed not just on time, to budget and fit-for-purpose but to be finished ahead of schedule and ahead of budget.

We change completely the way projects are run and we’ll explain how it is done in coming articles on this website.

In 2009, Roger Sessions, a well known author on the subject, in a White Paper called The IT Complexity Crisis: Danger and Opportunity, estimated that failures in IT projects cost a staggering $6.2 trillion a year globally.

That’s more than the GDP of the UK ($2.43 trillion) and Germany ($3.57 trillion) combined.

Houston, I think we have a problem!

I think we also have a solution!

Why Projects Overrun – 11 Reasons why Projects Lose Money

Why Projects Overrun

Most Projects lose money. Here we want to show you why projects overrun both time and budget, the main areas where money leaks away and how to stop the haemorraghing of profits from the project or the overrun of budget.

A Finance Director of my acquaintance once said, when I gave him the Project estimate plus or minus 30%, “You can forget the -30%. Projects are never under. You just hope that they are not too much over the +30%” – and he was, of course, correct to say that (but not on this project).

There are many reasons for this.

1.  Firstly, project estimates are usually wildly out because there is no historic data on how quickly an organisation can produce software and so the estimation process is completely flawed. If you were asked how much time someone would take to run a marathon without knowing what time they took previously your estimate could be wildly out. The first task before estimation should be to find out the previous speed of delivery of functionality which can be measured in Function Points per Man Month.

2.  Secondly tracking a project is wildly out mainly because incomplete tasks are counted in the tallies. How does one know how many errors there are left to fix in a piece of software? Developers underestimate the time left to complete to take the pressure off themselves. Who wouldn’t? Only completed tasks should be counted.

3.  Thirdly, there is no motivation for anyone to finish ahead of schedule. That means that the different components of a project are either finished on schedule or behind schedule – and unless you are very lucky and all the many components are finished on time then the project will be over time and over budget. There are several ways to cure this problem.

4.  Time is the most important thing on a project and that is what is measured and monitored. However, Fitness-for-Purpose and Quality are usually more important to the customer but these get sacrificed because Time is the most important driver whilst the project is running and the others are not usually measurable or measured during the project. The goals of the project should be aligned with what the customer wants and we have ways to measure this.

5.  They say be careful what you measure as that is what you will surely get. They also say Time is Money. However, this is not the case on projects. Because Time is all important, quality and fitness-for-purpose of the system suffers – and the rework to fix this scuppers the Time (and money) as well. This is the main reason for the failure of virtually every project and it is very curable.

6.  The Customer is King so they say – and who would want to upset a customer? Unfortunately, the customer, or those working for the main customer, are the ones most likely to screw up the project budget by failing to deliver information, equipment and data on time unless there are systems in place to make sure they can’t – and there seldom is. No one likes to kick the customer but there are times when the customer becomes the supplier and processes must be put in place to make sure they, like any other supplier, deliver on time – or else.

7.  External suppliers can also screw up the schedule, budget and profitability of a project by not delivering on time and there are seldom mechanisms in place to make sure that this is monitored and everything is delivered on time or there are severe penalties.

8.  The way projects are measured and the way those working on them are monitored is penal, de-motivating and bad for morale. There are better ways of motivating those working on projects and making them strive for success rather than having all their concentration on not failing.

9.  The person running the project may well have got to that position by being a good analyst or developer. However, the skillset for running a project is totally different from the skills and abilities they have shown so far. Any aptitude for their new role would be just a fluke. The project management role on a project should be split the way it is in the film business with a Director responsible for creating the system and a Producer responsible for the logistical side. This is currently done nowhere and brilliant analysts and developers are failing and causing major losses to their companies because they can’t estimate, track and manage suppliers and the other logistics that are needed to run a project successfully – skills which are nothing to do with being a good Analyst or Developer.

10.  The same mistakes are made over and over in projects as there is never time to look at what went wrong and how it could be put right with both a short term and long term solution. Even football teams take time on a Monday morning to go through the video to show how things went wrong so that the team can see how they can stop those things going wrong in the future. The same system would work on IT projects.

11.  One of the main ways that profitability leaks away from a project is through poor Change Control.  If this is not rigidly adhered to the customer gets a lot more functionality than they paid for. Of course functionality will grow as one looks more closely at a project. However, that is an opportunity for a supplier to make more money from a project rather than get the same amount of money for a greater amount of functionality. This is one of the main money leakers on a project. It should be one of the great money makers on a project.

Conclusion

Capitalism has been a much greater success than communism – yet at one of the bastions of capitalism, free market companies, their IT projects are run as if they are the command and control economies of communist states. There is little motivation for the workers to achieve. It would be much better to open the doors to capitalism and unleash the people on IT projects to achieve and to make the reward of success the main goal of people management on projects rather than the fear of failure.

The FD said to me “You can forget the -30%. Projects are never under. You just hope that they are not too much over the +30%”. That is certainly true in the way the great mass of projects are run. However, it doesn’t have to be so. We have shown you why projects overrun. However, there is another way.

Project Estimation on Successful Projects

Project Estimation on Successful Projects

Project Estimation is one of the most important tasks for a successful project – and yet so many places get it wrong. If the estimation is wrong then you can be scuppered right from the start. You will be fighting an uphill battle all the way – and it will be unsuccessful.

I have never seen anything so unscientific as the process used for estimating IT projects. It goes something like this. If 100 metres can be run in 9.58 seconds then if you multiply that by 100 you can see how fast someone can run 10,000 metres.

What usually happens is very rough. The project estimator or estimators will take chunks and say this should take 10 days, this should take 15 days, this should take 12 days. This is just from their experience but it is a very rough and unscientific method of estimating.

Average Person

You often get a Project Manager coming in from the outside who estimates the projects. All they can estimate is how long it would take the average person in previous places he or she has worked on previous projects he or she has worked on.

They have no idea on the speed that the people at this new company can create software. Let’s face it, even the people who have been at the company a long time would be pretty poor at estimating how long people they know would take to do a piece of work never mind someone from the outside.

1oK Race

Tell me this. How long do you think it would take me to run 10,000 metres? That’s right, you know very little about me, what condition I am in, what age I am, whether I smoke or not etc. It could be anything. However, what if I gave you an extra piece of information?

What if I told you that the last time I ran 10,000 metres I did it in 40 minutes and that I had done some good training since and was now in slightly better condition.

That would help you a lot in estimating how fast I could run 10,000 metres next time out. If you then estimated that I could run it in 39 minutes next time you probably wouldn’t be very far out.

Available

So, now tell me. How often is this information available, i.e. how speedy are the analysts and developers in an organisation and what is the quality of the code that they produce? And yet, as you could see from my 10,000 meters question, this information is crucial if you are going to make a proper assessment and a proper estimate of how quickly a project can be done.

With the information of how fast I had done the 10,000 metres it would be entirely possible to give a reasonable estimate of how fast I could run a 10,000 metres again. Without this information you are likely to be wildly out in your estimation of how fast I could run the next 10,000 meters I participated in.

And yet this is how computer projects are normally estimated. Stupid isn’t it?

Company Speed

The first thing anyone should do before estimating a project is to find out how quickly that the company was able to do previous projects. This will not be as difficult as you may imagine. The company will have a record of how long the project took in terms of man days, how much the system cost and it will have the functionality of previous systems documented.

The first thing that a new Project Manager must do is to find out how fast the company was previously in creating a system. He or she should take a good example from a recent similarly sized project.

The best way to measure the speed of a company in doing projects is to count the function points. It’s not a perfect way of estimating a system but it’s a lot better than the usual finger-in-the air method that is currently used.

Function Points

You will have been provided with the number of Man Days that the previous system took to implement. Once you have your Function Points counted, you can then divide the Man Days by Function Points to see how many Function Points were previously delivered per day.

Once you have that information you can then use that to estimate the new project. You have the specification and so and count the expected Function Points. One problem that you have here is that as the system progresses the number of Function Points is likely to rise as functionality is added or reveals itself.

Original Spec

What you should do here is to ask for a copy of the original specification at the start of the previous project before any functionality was added. If you count the function points in that you can then see how much the number of Function Points increased through the project.

If it rose 30% through the project you would then add 30% to your estimate once you’ve counted the initial function Points as that is the growth you would expect. This may take a little time but it is well worthwhile.

Different Speeds

This shows you the rate that the organisation can create working code. However, the individuals on your project may not be all the same. Also, they may have different speeds of producing code. Although salaries are not that different in IT for people on the same grades at the same companies, productivity can be very different.

However, when estimating the length of time a project will take it is probably better to take the company average rather than factor in the different speeds that different developers and analysts go at. This will give you a little extra contingency.

Calculated

As we will explain later (in articles down this page), you will be able to get your better people to finish more quickly and therefore do a greater percentage of the work – but you shouldn’t take that for granted in the beginning. Otherwise you could be badly hit if some of the better people took ill or left the company.

So, now you have your scientifically calculated the speed that the organisation can create working code. You should use that now for your estimate of the project and include the Function Point growth contingency.

Accurate Project Tracking for Successful Projects

Accurate Project Tracking

One of the most important factors in a successful project is accurate Project Tracking. Projects are seldom tracked accurately for reasons we will describe below. Bad data means bad information provided to management who then take bad decisions based on that bad information.

Time Pressure

Virtually all the pressure put on those working on an IT Project is Time Pressure. To everyone involved in a project being on schedule is the most important aspect of the project while it is being built. That is because time is money and it is easily measurable.

From developer to project leader to Project Manager to the Project Sponsors and senior people in the company time against schedule is by far the most important measure of a project when it is being built.

Of course, when a system is implemented and put into production there are other factors that become more important, i.e. where the system does as it is supposed to do, whether or not it is easy to use, the quality of the system in terms of how it works and how often or little it falls over.

These will all become more important eventually than time. However, they are less easily measured than time and are less important in terms of the tracking of the system during the build.

Huge Mistake

Virtually all the Project Management tracking during a project is about tracking time. That is a huge mistake – and counterproductive. It is the main reason that projects are late and over budget.

Be careful what you measure because that is what you get. There is tremendous pressure on developers to deliver on time.

So they do. It takes the pressure off of them. However, sometimes they would be better to take a little longer to test the software to make sure that it is working properly before handing it over for testing.

However, at that stage, no one is putting quality or fit-for-purpose pressure on them.  So what you get is software on time – but not necessarily fit-for-purpose or properly tested.

Early is Cheap

It has been shown by studies that the earlier you catch a problem in the software development cycle the cheaper it is to fix. If it is caught early in the cycle it is very cheap to fix. If it is caught late, e.g. in User Acceptance testing or in Production it is very expensive to fix.

And yet there is so little pressure during the software development process to get things right from te start. It’s all time, time, time. That’s what gets measured and this where all the pressure comes from. And yet time is seldom the most critical factor on a project.

Solution

So, how do we get round this? How do we make the most important factors on a project the most important factors while the software is being built? How do we pit Fit-For-Purpose and Quality pressure on developers during a project?

That’s very easy. You ask the customers what is important to them, how important it is and then you reward all those along the software developer supply chain for giving the users what they want.

Simple, isn’t it?

How?

So how do you do that?

Very easy indeed!

You just ask the customers or users. You just ask them what they want from the Project and how important it is to them.

They usually come up with Fitness-for-Purpose(it does what they asked for and what they want), Quality (in terms of not falling over), Ease of Use, Timeliness and Documentation. You then ask them how important these different factors are. You ask them to give a relative weighting factor.

Results

It will usually go something like

5 – Fitness-for Purpose

3 – Quality

2 – Usability

2 – Timeliness

1 – Documentation

There you are. You see how relatively unimportant timeliness is in the scheme of things. And yet that is the main thing that is measured during a project. That is the source of the main pressure.

Counterproductive

However, this is counterproductive. The more time pressure you put on the less Quality, Usability and Fitness-for-Purpose you will get – and that will have a huge impact on timeliness in the end as all of this will have to be fixed late in the cycle rather than early when it would have been much cheaper to fix.

Once you know what the user wants from your software development and from the system you are going to deliver to them then you have got to make sure that this is what is delivered to them.

Supply Chain

So, how do you do that? You create a Supply Chain from developer to analyst to systems tester to User Acceptance tester to the End Customer. At each stage whoever is receiving the software will give it marks for Fitness-for-Purpose, Quality, Usabilty, Timeliness and Documentation. They will be marks out of ten.

These marks will then be multiplied by the weighting factors so that the Timeliness mark will multiplied by 2 and the Fitness-for-Purpose mark will be multiplied by 5. These marks will be added together to produce a total mark for the delivery.

Best Return on Investment

If I was allow to introduce just one process at any company I went into, it would be this one. This one makes the most difference. The reason is that it totally changes behaviour.

Whereas previously developers would succumb to the time pressures on them and hand over work they weren’t completely satisfied with, I found that the developers and analysts themselves would resist the time pressures a little more as the realised that the bigger marks were for Fitness-for-Purpose and Quality and wanted to make sure that they got good marks for those.

They would hold on to their software for an extra day or two beyond schedule to make sure they were completely satisfied with it and it wouldn’t keep bouncing back to them.

Right First Time

Getting things right first time makes a huge saving in timeliness as it saved in the usual heaps of rework that timeliness pressure usually means so, you see, the less time pressure you put on and the more quality pressure you put on the more time you save.

What I found when I implemented this was that projects and people needed a lot less managing. People know what is wanted and managed themselves. In fact even when you put time pressure on them they’ll resist you as they take the long term view and deliver what is most wanted and what gets them the highest marks.

The easiest way to run a project is to put in good processes that reward people for the right things. That’s what you are doing here. Yet, how few project do this.

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.

Reported

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.

Improving

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.

What type of Project Managers do we want?

What type of Project Managers do we want?

Not all good programmers or good analysts become good Project Managers. It is in fact a very different skill from either of these.

How do we know who will become good Project Managers? One of the crucial skills needed is leadership. Leaders, in real life, tend to evolve rather than being appointed. How often do we see leaders of countries who have been appointed by their predecessor, being swept aside after the ‘great leader’ is gone.

Also there are some people who are used to succeeding in life and those who are used to failing. If one tennis player is used to losing to another player, then when losing again will take no great steps to reverse this.

When it comes to the time when the one who is used to winning is behind, he or she puts great mental and physical effort into reversing this situation. They just ‘can’t let it happen’, and it usually doesn’t.

Natural Leaders

Picking natural leaders who don’t let bad things happen, and who can right bad situations when they do happen, is crucial. This type of person usually has a positive attitude and is keen to insert the kind of processes into the software development lifecycle which will help him or her succeed. Also, on a project, when reverses happen, as they invariably will, they have the self will and belief to set it right.

Those who are not used to winning, as in life they are used to this situation, will spend their effort not in clearing up the mess but in justifying themselves and in making sure the blame does not attach itself to them. You need people who will grow in a crisis not shrink.

Running IT Projects the way Movies are Made

The Movie Analogy to Running IT Projects

It may seem strange but running IT Projects is not that much different to making movies. They are created in small clips and then put together at the end and the way movies are made appears to be a far better and more successful process than running IT Projects.

Programming, Analysis, and Project Management are different skills. Some programmers and analysts make good project managers. Others do not. Many do not want to become project managers. What they want to do is earn more money.

How often have you seen, at your organisation, that the best business analyst with the best business systems knowledge can’t run a project for toffee? Also how often have you seen a project manager who is logistically good and gets systems delivered in reasonable time, deliver systems that are not fit for business purpose?

The Cure

There is a cure for this which enables you to use your best people most effectively and which helps to keep them at your organisation. This is the use of Directors and Producers. In the movie industry, the Director is the person who is the creative genius, the Steven Spielberg, the person who makes the picture. This is your Senior Business Analyst.

The Producer is the person who handles the logistics. He or she makes sure the actors are hired, the contracts drawn up, the locations are booked, everyone turns up at the right place at the right time, the costumes are made, the food arrives, the star has the best caravan, the movie is on schedule etc.

Doing all this, as well as making the movie, would sap Steven Spielberg’s creative energy. There is no reason why he would be any good at this just because he can make good movies.

Equal Standing

The Producer and the Director would have equal standing and would therefore have similar recompense. The Director may even have a higher recompense.

This is a difficult idea to sell to senior management as they like to see one person in charge, i.e. the logistics person. This idea of Producers and Directors seems to them to be a bit ‘arty’ and not of the real ‘hard-nosed’ world. They also usually have projects which run over budget and time, which do not deliver fit-for-purpose systems, and have their best staff leaving in droves in this ‘hard-nosed’ world.

It should be explained to them that they would only have one point of contact. As the pressures on them are mainly money and time, their point of contact should be the Producer.

Potential Conflict

There is also the problem of potential conflict between the ‘arty’ Director and the ‘real world’ Producer. It is important, then, to appoint a Producer who gets on well with the Director (notice that it is this way round). In the movie world, it is often the case that the Director appoints the Producer, often someone who he has worked with successfully in the past.

Organisations continually complain that they are constantly losing people with good business knowledge from the systems department. With this change of emphasis, you will be able to keep your best Business Analysts. At the Academy Awards it is noticeable that although there is an award for Best Director, there is no award for Best Producer.

In Tandem

To cut any potential friction between the Producer and the Director, make their rewards mechanism the same so that their goals are aligned. Don’t reward the Director for fitness-for-purpose while rewarding the Producer for Timeliness and meeting budget.

If you have problems selling this idea to senior management, just call them the Project Manager and the Senior Business Analyst while separating the roles. It is better, however, if you can convince them that this is a good idea. It makes it easier to justify the kind of rewards for the Director / Senior Business Analyst which would keep him or her at the company.

Selecting Project Managers – Category 4 Minks

Category 4 Minks – Selecting Project Managers

Selecting Project Managers is one of the most important things you can do. If you get it wrong the project is scuppered from the start. The right people with the best processes is the perfect mix. So what type of people do you want when selecting Project Managers?

Minks

A few years ago, in the UK, the Animal Liberation Movement, set free a number of minks from a mink farm. Some of the minks, who had been bred in captivity, remained in their cages even when the doors were opened. Others stayed out for a while but came back at feeding time. Others still stayed out but could not adapt to the wild and were either killed or died of starvation. Others however stayed, adapted to the wild and thrived in their new environment.

Try thinking of you employees and fellow workers and which categories that they would fit into. Select your Project Managers only from the ‘category 4 minks’. Do not confuse them with the ‘category 3 minks’ who are usually loose canons. Do not worry if they are relatively junior. Double or triple promote then if you have to.

Appreciate, also, that the ‘category 4 minks’ are the ones most likely to leave your organisation. Those are the ones that you most want to stay.

Promotion

If you promote the leader from within the ranks, you will find problems with those that they have leapfrogged on the way up. These problems come from people who want to stay at  the company but who assumed that, in the natural order of things, that their turn for promotion will come soon.

Many of these people are good analysts or programmers that you would wish to keep at the company. You need to be able to manage this or you’ll be left with good leaders but fewer good technical workers and especially fewer people with good knowledge of your systems.

Different Strokes

How do you handle this? By having different ways of progressing up the company. Very often people mainly want promotions because of the extra status and income attached to it. You must find other ways of giving them this status and income if they achieve good results.

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.

Productivity

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

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.

Rewards

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.

objective

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.

Cutting Out Delays caused by Customers

Cutting Out Delays caused by Customers

Your project will not be delivered on time and to budget if you are not successful in cutting out delays caused by customers.

The biggest suppliers to the project are usually the internal or external customers of the project. It is a lot easier to manage suppliers to the project who are not customers. It is a lot harder to manage customers or users when they are in the role of supplier. They provide information at all stages, sign-off, facilities, test data etc.

When they deliver something late, e.g. information, it is difficult to report them to their superiors without causing friction. Any delay to the project caused by them will not be reported as such. It will be put down to you. You, therefore, had better fix it.

Crucial Mechanism

It is important to put a mechanism in place at the start of the project which ensures that any late supplying of information etc. is documented and automatically escalated. There should be a written agreement with the senior project sponsor or senior customer, i.e. whoever is ordering the software product. The project sponsor is usually happy to do this as they do not want delays to the project, with the resulting cost increases.

When a delay is caused to the project by any supplier, including the customer, a Delay Note should be issued. This delay note should document the cost in terms of scheduled days, elapsed time and money. This should be given to a senior IT person, perhaps the head of IT or of software development to be passed on to the project sponsor.

Automatic Escalation

This escalation process should be automatic so that the person who escalates it can say to their customer contact that it is part of the process. If the project is being done for an external customer, the costs of the delay should be passed on to them. This should be stated in the initial contract.

What will happen, usually, in practice, is that the customers or business users that you are liaising with will not take this seriously at first. They’ll have other priorities. They would see the current business as being more important than a system they’ll get down the line.

They don’t think you’ll report them. They don’t think you’ve got the balls to do it. They don’t think you’ll  jeopardise your relationship with them by reporting them to their boss. Therefore you must do it. The sooner you do it on the project the better – and do it to someone that the other users didn’t think you would do it do. They must think ‘if he does it to them he could do it to me’.

Stamping Authority

It’s a bit like a referee stamping his authority on a game early on to show he means business and will not take any malarkey.

I did it on one project to my opposite number, a guy called Frederik. He was the Project manager on the customer side and I was the Project Manager on the supplier side. We each had only one person above us on the project. I reported to the MD on the project and Frederik reported to the project sponsor on the customer side.

It had been pointed out to me by the software Project Manager that, although Frederik was always very insistent that we had got everything done, he often didn’t have what he was supposed to do done. This may have been the supply of information or the supply of good test data. No one had ever called him up on it before. He was the customer after all.

Good Relationship

I had a very good relationship with Frederik. We got on well and we saw most things the same way.

So, the first meeting after it had been pointed out to me that he often didn’t deliver I said at the start of the meeting that every time someone (anyone) hadn’t delivered something that they should have done at the meeting I was going to start a game of hangman for them.

Gradually the gallows were constructed line-by-line and Frederik eventually ‘hanged’. I hadn’t set it out specifically for Frederik (or so he thought). It was for everyone. His lieutenants on the project could see it and our people could see it. He was the main non-deliverer.

Good Spirit

He took it in good spirit and I was hoping that he would see the light and change his behaviour without my having to report him. He did improve for a while but then he started to deteriorate again – and it was something major. His lack of delivery on it would be a major impact on our being able to deliver the project on time. From memory I think it was the supply of test data. His would hold the whole project up.

I knew I had to act. I issued a Project Delay Note and gave it to my boss the MD. He contacted the Project Sponsor on the customer side without delay. It was Friday afternoon.

Bad Weekend

On Monday morning I was told that Frederik was trying to get hold of me. I thought I’d let him stew for a while. I waited till the afternoon to get in touch.

“I’ve had a very, very bad weekend” he said in what sounded like menacing tones. “Was it raining in Holland then?“ I asked him. “It was nothing to do with the weather” he replied. “I think you know what I’m talking about. You should have had the courtesy to come to me first”.

It seemed that his bad weekend had been caused by an almighty dressing down by a very angry Project Sponsor on the customer side, i.e. his boss on the project.

Automatic Escalation

“I was forced to do it”, I said. It was part of the procedures that you signed off on. If I didn’t do it I would have been in trouble myself if I hadn’t”.

He said “You should still have come to me first”.

I told him that I had tried other methods like the hangman. However, he still hadn’t got the message. “This was a last resort for me” I said. I think grudgingly he accepted it. However, what was more important was that his behaviour changed. He didn’t want any more bad weekends.

Be Brave

It was an uncomfortable phone call. However, you have to be brave. The rewards are very high for doing it. Can you imagine a project where the customers or users deliver everything they should on time? What a bonus this would be to your ability to deliver the project on time and to budget.

And yes, this is what happened. There were no future major delays to the project. This was a highly significant factor in our bringing in the project ahead of schedule and making a good profit which impacted very significantly on the careers of the MD and of myself.

You must also keep a wary eye out for those that work on the project for you and make sure they escalate to you any problems that they are having with their opposite numbers and their deliveries to them. If you find out that they are not escalating delays to you then you should let them know in no uncertain terms that this is not acceptable.

Zero Tolerance

There should be zero tolerance on this. The people most likely to screw up the project for you in terms of getting it done on time and to budget (and making a healthy profit) are the customers themselves. Don’t let them do it. It’s an absolute certainty that they’ll try. Impress on your people how important it is to stop them doing so. Impress on them, also, that it will be a very grave misdemeanour if your people let their opposite numbers away with this without escalating it to you. It simply won’t be tolerated.

Productivity through Motivation on a Software Project

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 if you simulate, as far as possible, working for themselves.

Conditions in which they profit (and profit well) from their productivity gains should be created. The model of the City of London traders should be used. 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. By giving them a base salary and a pension you give them security. 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 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

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 produce software of better quality and with better time-to-market than its competitors.

People’s morale will be high. Customers will be highly satisfied. They will 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 will be a worldbeater. 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

Keeping Your Best People – The Winter Holocaust

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.

Social Activities

To be forewarned is to be forearmed. The dark days of January, February and March are the time when social activities should be organised. 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. An awards evening was organised, with most of the expense being met by the sports and social club. Senior management were invited. Presentations, in reverse order, were made to the top three in each category. Each of the first three received a certificate.

Winners

The winners received fifty pounds in the serious categories and a bottle of champagne in the joke categories. It was organised by the people 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?

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 that you’ve made the offer. It becomes the perceived wisdom among the remaining people that 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.

Learning from Mistakes

Learning from Mistakes

One of the axe-sharpening activities for which there is seldom time is the activity concerned with understanding why mistakes were made and crushing them out of the process so that they do not occur again. One of the reasons why these activities are not usually allowed is that the time they take is not usually in the schedule and because many of the benefits are for future projects.

This can be cured in several ways. In the beginning do not attempt too much. Preventing defects, like politics is the art of the possible. Prevention of Defect meetings should happen, during projects, only when sub-systems are delivered into test, not when individual programmes are delivered. They should only analyse higher category defects. At one organisation, they had nine categories of defects of which they analysed only the top five categories.

The Lesson Learning meetings should last only an hour. There are two purposes for the meetings. The first is to ensure that the person who created the defects understands why they happened. If they take time out to understand why they created the defects they are less likely to create them again. This activity happens in other professions.

Football Clubs

At football clubs they use video evidence on a Monday morning to analyse the problems that occurred in the match at the weekend. The players are then able to analyse and visualise what they should have done. It breeds good habits. When Liverpool were the top team in the country, whenever a player was transferred from them to another club, the manager of the new club would always try to find out from the player what the Liverpool secret was.

But there was no secret. As Bill Shankly said, they hired the best people and did the simple things. They didn’t do things like pass the ball across their own area. They had cut out all the mistakes which had caused them problems in the past. This was good people with good processes.

Mistake Analysis

The second purpose is to allow the analysis of these mistakes so that the process can be changed to prevent the mistakes happening again. In the past I have found that many of these problems occur because of misunderstandings at various stages. Very often this analysis leads to elements of Rapid Application Development (RAD), especially Joint Application Development (JAD) being taken into the process and the use of developers rather than analysts, designers and programmers. The fewer handovers, the fewer misunderstandings there are.

Standard Practice

Fortune magazine once analysed the software practices of the top 500 companies in the USA. They found that there were four main practices which separated the best performing software departments from the worst. These were:-

o             Standardisation – of platforms, methods, models etc.

o             Joint Application Development (JAD)

o             Timeboxing

o             Prototyping

You may short circuit many of your defects by implementing these best practices.

You should analyse your mistakes so that you are constantly learning from this mistakes and getting better and more productive as an organisation.

Boost for IT as Government announce Paperless NHS

Paperless NHS

Government Health Minister Jeremy Hunt announced today that the Government plan to move towards a Paperless NHS. They intend that everyone should be able to access their medical records online by March 2015 – just before the next election. By 2018 all NHS should be able to access all patient records online.

These are brave targets. Will they be implementable by the time they want? From past experience that is unlikely. Governments have a poor record of being able to deliver major projects. Indeed this Government scrapped many of the mammoth IT projects that New Labour had initiated, including the huge NHS project which sucked in billions of pounds.

No Different

So, why do the Government think they will succeed when New Labour failed? What are they going to do differently that is going to cause them to succeed where Labour failed. They are likely to use the same partners. They are likely to use the same Project Development and Project Management methods that they used before. So why the big confidence that they will succeed?

They’ll concentrate most of their efforts on getting Timeliness. Quality, Fitness-for-Purpose and Usability will suffer as usual. Then there will be a massive amount of rework and the project will be very late and well over budget.

Huge Risk

They really are taking a huge risk here – and I don’t think they really realise it. Do they really want to go into the 2015 election with one more promise that they haven’t kept and one more target that they have missed? Having worked on projects in the private sector and in the public sector and having managed many projects I would be willing to predict that they’ll miss their targets – and miss them by a long way.

I predicted back in 2005 that the big NHS project started by New Labour would fail – and fail it did. As nothing much has changed since then I can’t see how this will succeed either. I would be astonished if it managed to do what it is supposed to do by March 2015 – just before the election. In fact I would be very confident in predicting that it won’t.