Why Do So Many IT Projects Fail?

Up to 75% of business and IT leaders expect their software projects to fail¹. Why is that?

Here are just a few typical reasons that a software project could fail:

• The project failed to meet original business objective(s).
• The team missed the deadline.
• The project suffered from a budget overrun.

These are obvious and often typical reasons for a project failure. However, in this post I would like to focus on one reason (often the underlying reason for the reasons above) that is often overlooked. This is the inability to quickly change direction.

Large-scale projects often take years to complete, so projects like these need to be able adapt and pivot in order to react to an ever-changing landscape (e.g. new product, new opportunity, new market). If you cannot pivot, your project it is susceptible to failure, because business goals and objectives can and will change.

So how do you prepare your project for major changes? Here are the four key guidelines for doing so.

1. Set realistic expectations

All stakeholders need to understand that budget, timeline and scope are always changing - never static. Unless you have this mindset, your natural inclination is to protect the original scope, timeline and budget irrespective if a new direction/change creates more business value. Business value is always more important.

2. Flexible contract structure

Agile contract is preferred, but not mandatory. If you are dealing with a fixed scope/price contract, then insert assumptions or procedures to deal with changes. Time-consuming change requests or amendments should be avoided or kept at minimum.

3. Spend less time documenting and more building

Documentation is important, but your main goal is to deliver a product or service and not a perfect document. Also, business requirements change – in a dynamic, variable-filled environment nothing is set in stone - , so don’t spend a large percentage of your budget on documentation. Finally, do not try to document every single requirement. Document only core features. By documenting ‘nice to have’, ‘sometime in the future’ or ‘phase 2’ features you are wasting time, taking away valuable resources and limiting your ability to pivot.

4. Focus all efforts on core features

It is much easier to pivot if you only focus on features which are needed right now rather than sometime in the future. ‘Sometime in the future’ (nice to have) features take up valuable resources and are also far more likely to change or be scrapped, so focus on core features until they are complete. For example, a stakeholder may say something like “We will expand our product line next year, so make sure navigation, product sections etc. can handle it.” Should you build this capability? Only, if you are done building all core features first. Don’t fall for the misguided reasoning that “It’s more efficient to build core and ‘nice to have’ features at the same time”. Of course it is, but your primary objective is deliver value (core features) quickly, so focus on what is critical for completion first.

With so many resources going into a project that can often make or break jobs or core business efforts, it is important to stay focused on the core objectives that determine success and to be ready for these to change. Massive projects involve business needs that change in fluctuating markets, actors that are often fickle, and technology that will always contain bugs or unanticipated roadblocks. By expecting the unexpected, you mitigate risk and reduce your chance of project failure.

¹ http://www.geneca.com/75-business-executives-anticipate-software-projects-fail/