Posts Tagged Projects

It seems like a simple question and should have a simple answer. However, all too often projects that are proclaimed as successful seem much less so when closely scrutinized or just a few months after the project was ‘signed-off’ to great fanfare. The word ‘projects’ conjures up images of information technology, system implementations, change management processes, training, learning and development programmes. Do these share anything in common besides having a definite beginning, middle and hopeful ending? They almost always involve that other modern word in organizational effort ‘the team’. A team is temporary whereas the outcome of a project is seldom thought of as a temporary event. A project could arrive at a conclusive event that will be used to make a decision. This is the typical prototype and pilot that is much touted in system implementations but too often the decision has been made before the prototype or pilot even starts. A project may result in a conclusive event that people do things differently. The conclusive event could be an information technology system, a new or changed process, training and learning about how to do something with some payoff towards betterment.

Formal research and anecdotal evident across the spectrum of project management methodology, information technology implementation methodology, business process change methodology and human resource development show that a large percentage of such projects in both SME and large organizations are failures. This is almost never pointed out by the external consulting industry, both the large and well-known practices (Accenture, KPMG, McKinsey, and so on) and the thousands of smaller and independent consulting practitioners.

In 1995 the Standish Group reported that 31% of IT projects in the United States were cancelled before completion and 52% were 89% over budget. Further more only 16% of software projects could be considered successful. The numbers do not get much better for the period 1996 to 2010.

Ken Grant from Ryerson University evaluated 45 KM projects from the late 1990’s to 2010 and found that only 45% / 21 were considered to be successful. Why would anyone try to implement anything that will fail 55% of the time?

Gartner recently released statistics showing that at the end of 2012 technology is only used to 43% of its potential. Why would any organization spend time, effort and money on technology which fails 57% of the time?

Training, learning and education disciplines have been investigating for decades how to first help children and then adults acquire knowledge and use it in their work and lives. Much has been written but no holy grail has been found. Diane Laufenberg sums is up nicely in the Ted Talk in 2010 on learning through failure and real experience and not looking for the right answer.

They are both well worth following for any project. They give some assurance that the project is more likely to finish at an agreed upon time and at an agreed upon cost with a list of features agreed upon in advance. They do not guarantee project success or project benefit.

The most important criterion for project success is the extent of use over a period of time. These are questions to ask about a system, process or programme after it has been put into place.

Is the new system, process or programme being used one year, two years or three years after implementation?

If there is no use after one year then it has failed.

If there is use for one year it is somewhat a success, after two years a definite success and three years it is a star performer.

Was the system, process or programme significantly upgraded within one year, two years or three years after implementation?

A significant upgrade, revamp or redeployment within the first year is a probable sign it is a failure.

A significant upgrade, revamp or redeployment within two years may mean it was of some use but didn’t meet expectations.

A significant upgrade, revamp or redeployment within three years shows a clear success and a desire to keep using a successful system, process or programme to fit new or different circumstances.

This is some harsh advice but it will improve project success over time inside most organizations. As a general rule, system implementations, organizational change management initiatives and training and learning programs should be done in-house whenever possible. Organizations should only use external consultants to acquire the knowledge to learn how to do the work. This way, the organization has the skills to adjust the system, process or program after it has started to be used. Bluntly, do not use external consultants to collect requirements or perform implementation work because they will minimize the difficulty when collecting requirements and will not be available after implementation to make adjustments. When external consultants are used for requirements collection or implementation their fees should be structured so that a significant proportion of their fee (40% to 60%) should be paid one year after the project completion sign-off.