Succesful IT projects really do exist

We regularly encounter failed IT projects in the news headlines, feeding the perception that it is virtually impossible to finish an IT project succesfully.

It is true that still (too) many IT projects fail, but there are plenty examples that have completed succesfully. From those succesful IT projects we could learn a lot about the factors that lead to success, rather than trying to avoid known pitfalls. That's why I have done a retrospect and noted several observations that can support more IT projects to be succesful.

Succesful IT projects really do exist!

Let's start at the beginning. Many analyses show that the source of success or failure is usually in the start of an IT project. And there lies the first observation that real IT projects are very rare. In most cases an organisation wants to change or improve something and IT is an essential part of that transformation. Although the contribution of IT to organisational transformations is becoming more and more prominent it will hardly ever reach 100%. So, no matter how well the IT project has been effectuated, it will only be considered succesful when the complete transformation is succesful.
A succesful IT project has an understanding of the environment where it is a part of. Even if the customer explicitly states that the IT project should only focus on IT, the chance of success increases when the whole environment is taken into account.

IT projects do not exist

I already stated that in my view pure IT projects are virtually non-existent. For that reason it is also important to have a clear view on the financial impact of the IT project on the organisation. When a project encounters schedule slippage or cost overruns a much used remedy to get back on track is a change of scope. If you only take the IT project into account that's a very sensible thing to do.
For the organisation this may not always be the best resolution, since the business case of the entire transformation is based on the full scope of the IT project. For the organisation as a whole, accepting the schedule slippage or cost overrun may be a more succesful resolution than delivering the IT project with a limited scope on time and within budget.

In one of her blogposts, Carol Dekkers compared this common approach in IT estimation with blindfolded scientists who investigate the size and nature of an elephant. In the accompanying image the impact of reduced functionality becomes painfully clear:

• with shortened spears the elephant is limited in overcoming obstacles
• with a smaller snake the elephant will have difficulty with his food intake
• with smaller fans the elephant the elephant is unable to cool his bloodstream sufficiently
• with a shorter tree the elephant will limp
• with a less solid wall the elephant has a reduced protection against the elements
• with a shorter rope the elephant will loose capability to deter insects

IT projects serve a (higher) goal

An IT project contributes to a transformation to bring about a change or improvement within an organisation. That is the real goal, rather than delivering a set of requirements. If the goal of the transformation changes, you should wonder whether the IT project still makes a contribution to the desired transformation. Timely killing of the project is then a more succesful action than finishing the agreed IT project against better judgement. If the (higher) goal is clear, ambiguities in requirements are more easily solved and priorities in a backlog are clear.
Smaller projects usually have a closer relation to the (higher) goal than have larger projects. The contribution of the IT project and the desired transformation is quite visible. That is probably one of the main reasons smaller projects are more often succesful than larger projects.

 

IT projects have a real owner

In many cases the owner of a product or service the IT project must contribute to is the owner of the IT project. No one has ever wondered whether this person has enough time, skills and capabilities to be the owner. As owner he must have enough influence and mandate to make decisions or to bring about the decision making process. He must be able to create involvement between the organisation and the project and must be result driven.
This requires different skills and capabilities then managing the daily operation of a product or service. Succesful IT projects tend to have an owner that is able to combine ownership with daily management, or have appointed a special owner with sufficient influence and mandate who can focus on the desired result.

IT projects have focus

Succesful IT projects deliver the most important features first and additional non-critical features later. A reason why some IT projects fail to be succesful is that they spend too much time and resources to get functionality working with little impact on the main business operation. Should all possible exceptions be handled automatically or should we accept that complex matters be handled separately by human experts? Succesful IT projects make a targeted use of the 80/20 rule and deliver the most critcal features first.
That is not necessarily Agile. For processes or services with a long turnaround time you can start the automation with an input- or order module first to generate new business. After that you can implement complex interfaces with the rest of your application portfolio without schedule pressure.

IT projects contain subject matter knowledge

Succesful IT projects do not only have an understanding of the environment where they are a part of, but do also know what that environment is all about. To acquire subject matter knowledge different approaches are available. A pro-active commissioner can send his IT projects on their way with a thorough business case that contains essential subject matter knowledge. Without such preparation you can model the relevant subject matter knowledge at the start of an IT project to make that knowledge available throughout the project life-cycle. The most popular approach is to staff your project with people who are already familiar with the project environment. Whatever approach you choose, sufficient subject matter knowledge will give you a fun chance of success.

That brings me to my last observation. Research shows that fun projects are good for both job satisfaction and a better quality result:

IT projects are fun

Recent research by the Software Improvement Group to the relation between the quality of the teamwork and the effectiveness and efficiency of the team results. In this research 29 teams with 199 team members from 18 organisations have been evaluated. This showed a strong relationship between the quality of the team and the quality of their work.

Test my observations yourself. Take a succesful and an unsuccesful IT project in mind and run them through my observations above. I like to hear your reaction.

An earlier version has been published on the website of Computable.