3 Reasons IT Projects Fail
Having worked in the IT field for over 10 years, I resonated with Moira Alexander, of Chief Information Officer (CIO.com), a subsidiary of International Data Group (IDG), in her article titled Project management guide: Tips, strategies, best practices 1, when she listed the following as reasons IT projects fail:
- Misalignment between project goals and business strategy
- Unrealistic project scope or scope that is not closely controlled
- Vague business goals or requirements
The remaining items Alexander listed in her article may have relevance to others but for me, these jumped out at me.
Misalignment has occurred with me when management is afraid to set boundaries with clients. In software development you wireframe out all aspects of development but when managers meet with clients and let too much input enter the development process it mucks up the waters. Often times, it is because clients do not understand what all goes into programming software yet want to reserve the right to randomly add in a feature that may take months or even years to produce. Features included in software must be very specific, realistic, and useful or you have a bad end product.
When someone doesn’t understand what goes into software they begin listing off features they’ve seen in movies or heard about in a tech magazine. The truth is, when you imagine something “cool” (like unnecessary window slide-in transition in RMS software) in the middle of production you effectively cancel the working contract, as well as the previous production schedule, and must reenter into the negotiation stage so you may rework the entire contract to include the given “cool” add-on. Clients become endlessly offended and have the “Why can’t you just add in anti-gravity while you’re at it?” attitude when it’s simply not a possible feature you can include and satisfy the terms of the contract (budget, time, etc.). However, when you have a manager that fails to relay this information to the client you immediately have unrealistic project scope.
Vague business goals (or requirements) has happened with me when the client was given too much opportunity to change their mind about features offered. When contracts are signed for software they stand as the diecast from which all production will come from. If at any point the model (or cast) is changed, the entire contract must be rewritten to establish a new diecast from which software may be generated. In short, I completely agree with the items listed in this article. I have personally experienced setbacks and they did specifically include these three (3) items listed.
