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.