The article covered most things that can be done to avoid failure. However, they missed one major cause of failure. I witnessed three projects, each 15 years apart that failed due to the same cause – one IT management decision. A project can have only one primary goal . They changed the project goal from solving a business problem to implementing their own favorite technical or methodological solution. The costs were huge. Two could actually be measured.
These were small projects, hardly noticeable, but with a large impact. All three projects started by coding a proof-of-concept and user demo with live data. Time was included in the plan for adjustments based on user feedback and completion of the final project from the proof-of-concept. Management stepped in after the demo and transferred them to another team with instructions to rewrite the app. All three projects might have been salvaged if they had just discussed lessons learned with the prior team as highlighted by point #7 in my article “Innovation and Turmoil ” (Ask for help or advice. Ask an expert if there is one.).
Coding Methodology (most recent)
The main goal for the team was to add security to the prototype and present the app at a convention. The core structure they started with worked perfectly (one company said that it could not be done at all). The team argued constantly about how it was written, was unable to meet the convention deadline and quit without writing the security module. The security module itself would have been a partial success and could have been written however they wanted. The app had the potential to save many millions of dollars in medical research but never made it to market.
Platform (15 years ago)
The app was actually rewritten without looking at the prototype and put into production. Our company had 700 consultants on the customer’s site. The cost overrun was so large and implementation date was missed so badly that the customer VP was reprimanded in his review by the president for failing to kill it early on. After that, the customer, per contract, cut the maximum consultants on site (70) each year AND the consulting firm never received another new project. One consulting firm manager actually thought the app was a success in demonstrating object oriented technology.
Computer Language (30 years ago)
The new team was unable to complete the project at all. I would have had it in User Acceptance Test within 2 weeks of the demo, but management wanted it converted to PL/1, the language that they understood. The app was requested by the division’s largest outside customer, the largest car battery retailer in the US at the time. One year later, the company lost that battery contract.
This was not a project, but it is related. The machine converting powdered carbon to pellets was leaking dust. The Senior VP was touring our plant. He said “Tighten up those seals.” The machine ground up the seals into the pellets. We had to scrap 12 million dollars of product. Luckily, our database was able to isolate by lot number the product produced by that production line from the other 5 lines. That one statement cost the company 12 million in profit that year.
None of the managers involved in the examples ever knew how much damage they did to their company or their customers. It is very easy to destroy a project by repeating history. Don't confuse project outcomes with business outcomes . Always be careful what you say, pay attention to the small projects, and never forget the business goal.
“IT project success rates finally improving”, CIO, Sharon Florentine, Feb 27, 2017, https://www.cio.com/article/3174516/project-management/it-project-success-rates-finally-improving.html
“The Reason Why Project Management Tools Won’t Help You”, Project Times, Dmytro Moroz, July 2018, https://www.projecttimes.com/articles/the-reason-why-project-management-tools-won-t-help-you.html
“In novation and Turmoil” Journal of Systems Management, William Myers, Dec 1987, http://myersww.com/turmoil.html