The Cost of Failed Projects

Failed Projects

Failed projects

Failed Projects are costing companies and countries an absolute fortune every year. The cost of Failed 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 one or more failed projects 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. That’s because the companies overestimate the benefits and underestimate the costs.

According to the National Institute of Standards & Technology in the USA companies spend £60bn a year 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. They had a total slippage of 139 months in the past year.

So, they have 16 projects that have overspent by an average of £29m each. Also, they have slipped by an average of 8.7 months each  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. There are just too many failed projects.

Successful Projects

At one company where we ran projects for major companies like Texaco and Exxon (Esso) we managed to get 4 out of 5 projects done on time. One of them  was 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 in-house to do it.

Our people looked askance at the poor project management practices on the project. It was  as if they were looking at a backward people using backward methods. They 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. 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 failed projects in IT 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!

Accurate Project Tracking for Successful Projects

Project Tracking

Project Tracking

One of the most important factors in a successful project is accurate Project Tracking. People seldom track projects 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.

Project Tracking and Management

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.

User Acceptance Testing

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 is where all the pressure comes from. And yet time is seldom the most critical factor on a project.

Quality 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?

Fitness for Purpose

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.

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

Time Pressure on Project

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 you will have to fix all of this 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, Usability, 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 they allowed me to introduce just one process at any company I went into, I would introduce this one. This one makes the most difference. The reason is that it totally changes behaviour and means accurate project tracking.

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. Accurate project tracking matters a lot.

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 you needed to manage projects and people needed a lot less. People knew what users wanted and so 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 users wanted most 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.

Good project tracking is crucial. Poor data results in poor information.

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.

Paperless NHS – Boost for IT as Government announce it

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.