Success rates of IT projects are very low, what does it take to be successful?
Pearl Zhu in her article “IT project failure: symptoms and reasons” comments that:
“In the United States, we spend more than $250 billion each year on IT application development, statistically, 31% of projects will be cancelled before they ever get completed. 53% of projects will cost twice as of their original estimates, overall, the success rate is less than 30%.”
These statistics are simply horrifying. Pearl goes on to discuss some of the root causes, so its worth reading the full article. A number of my previous articles on change management and IT have also touched on this subject and are referenced below.
So what should a CIO drive in order to improve the situation?
1. Well defined Problem Statement
“If you can’t explain it simply, you don’t understand it well enough.” states Joel Dobbs
Be clear on the problem you are trying to solve and why it is being solved
Ensure everyone is aligned and trying to solve the same issue, especially the IT and business teams
Four questions CIOs should ask before taking on a new initiative. What, Who, How and Why? by Joel Dobbs
- What is the problem you are solving?
- Who has the problem or is affected by it?
- How do the stakeholders (or customers) deal with the problem now?
- Why is what you are proposing better than the status quo?
Richard D. Lang commented that “a well-defined problem statement is an important guideline [to achieving project success]”.
2. Business Projects (not IT Projects)
All projects should be business projects with a technology component (with the rare exception of some infrastructure projects). Strong Business ownership is key to changing the business processes, delivering business value and ultimately to project success. If its seen as being an IT project then getting the buy-in from business teams becomes a lot more difficult and the project is highly likely to fail.
Martin Webster takes these thoughts a step further in his article: There’s No Such Thing As an IT Project.
3. Project Name describing your business goal
Name the project for the business or improvement or process being changed, NOT the technology. Otherwise it risks becoming an IT project without proper business ownership. This may sound like a trivial action, but just think about it for a second – if you use the name of the software then people think its about the IT tool and it’s ITs job to get it done. However, if you use a description of the improvement you are trying to achieve, you are sending a clear message of your business goal.
For more on this see my blog post: Change Management – What’s in a Name?
4. Change Management – Driven by Senior Business Executives
Change Management is absolutely critical to any project. You can implement a great system and define lots of lovely new processes, but if no one follows them and people carry on as they always have – then you have failed.
People do not naturally resist change, in fact people like variety, however, they fear what they do not understand. On the flip side, if they are part of and embrace the change then they can help drive it from the ground-up.
“The secret to Change Management is to communicate often and involve people throughout.”
In summary the key points are listed below:
- Ambition – make sure the change is sufficiently ambitious to animate the organisation.
- Structured and Coherent Change Programme (e.g. Kotter’s 8-step Leading Change) – a structured approach will lead to success.
- Leadership – strong business leadership is a must to drive success and keep everyone engaged and heading in the same direction.
- Urgency – if its not urgent it will not get done!
- Ensure the Change resonates with staff – the more they embrace the change the easier your job will be.
- Involve everyone – if they are part of it and helping to define it then they are less likely to be fearful or to resist it.
- Define how they benefit from the change (also known as “What’s in it for me!“) – the Leadership team will need to sell it far less if people understand how it will improve their work lives.
- Remove fear to reduce resistance – by communication and getting people involved.
For more information see my article on Success with IT Change and the various other links at the bottom of this page.
5. Two Phase Project Approach
You would never consider building a house without an architect first drawing up plans and costing out the materials, labour etc. So why do so many IT groups think they can provide accurate time and cost estimates without first designing the solution?
I strongly recommend a two step approach, the first phase covers requirements, analysis and design. The second phase covers the build and implementation. The main deliverables from the first phase are a charter, plan, cost and high level design for the second phase.
This approach requires a bit of a mindset change, as you need to commit a small amount of money up front, but you must refuse to talk total cost or timing until the first phase is complete. However, you are then able to have a meaningful conversation with your business partners with far more accurate information.
I hope that you found these insights useful and I would be interested in hearing your thoughts and suggestions for other actions to improve your chances of project success.
To read more about why large IT project fail there is a really good article “Five “Super-Pitfalls” Why Large IT Projects Fail” by Pearl Zhu.
Change Management (Part 1) – Cracking the Code of Change
Change Management (Part 2) – Step Models of Change
Change Management (Part 3a) – Change Capability
Change Management (Part 3b) – Success with IT Change
Change Management – What’s in a Name?
Why are IT projects Change Management time bombs?
The Importance of Change Leadership – Beyond “Step Models of Change”
IT project failure: symptoms and reasons by Pearl Zhu
Five “Super-Pitfalls” Why Large IT Projects Fail by Pearl Zhu
Four questions CIOs should ask before taking on a new initiative by Joel Dobbs
Project Leadership: Key Elements and Critical Success Factors by Richard D. Lang