Has your organization invested in a “game-changing” software project, only to discover that the promised benefits never really materialize?  Or that the implementation was so flawed that the system is regarded as a financial and operating disaster?

Sadly, this happens far more than it should… but must this always be the case?  Here are five key reasons for technology project failures – and how to avoid them.

1) No detailed Blueprint:  A Blueprint is the planning engagement that maps your processes, data, and systems, then determines how a particular type of software will be used to achieve specific business goals.  It often will include three other elements:

• An early recommendation of specific software,
• A high level technical architecture,
• A listing of recommended business process changes

Without a Blueprint, the project risk is exceptionally high: the wrong system is often implemented, there is reduced front-line support, and there are often significant scope changes/change requests.

2) Don’t believe the vendors:  Software vendors (and commissioned salespeople) are in the business of selling software, so the “truth” sometimes gets stretched in the sales process:  the simplicity of implementation, the ease of use, and the ROI.  Or a promised feature turns out to be vaporware.  Trust, but verify.

3) Little understanding of trade-offs:  There is a fundamental decision that must be made whenever implementing large-scale software:  modify your processes or modify the software.

• Modify your processes to take advantage of the best practices embedded within the software.   Choosing this approach means lower software customization costs but higher change management costs.
• Modify the software to conform to your organization’s processes, and therefore maintain your strategic advantage over your competitors.  Choosing this approach means lower change management costs but higher software  customization costs.

While vendors may say that their software already works the way you do, but better, and therefore you will get the best of both worlds, refer to rule (2): Don’t believe the vendors.  Instead, ensure that there is a fulsome discussion of this issue during the Blueprint process.

4) No consulting team continuity:  Too often, the team selling the engagement is different than the team doing the blueprint, which is different than the team doing the implementation, which is different than the team doing the training. Every time there is a swap, the team needs to learn all about your organization, over and over again.  Another huge dividend from team continuity: strong relationships and an exceptionally high level of trust.  (A separate but related aspect of continuity is within the implementation team itself:  many failed projects are caused when there is no continuity in project management.)

5) Double the Training and Double the Support:  The success of the project is really not determined by the build, but rather the uptake.  Implementing a system is really more about change management: training empowers, and support is the “insurance policy.”  Skimping on either means that the system will be used inefficiently, or simply won’t get used.  Whatever you think is the right amount of training and support, double it.

While these five reasons are primarily related to working with external consultants, there are a number of internal factors as well. I explore those here.

Does this topic resonate? Reach out to Randall: he can present it to your group.  (More presentation topics)
Download Randall’s professional credentials: Speaker credentials one-sheet or Management Advisory credentials.

Content Authenticity Statement: 100% original content: no AI was used in creating this content.

@RandallCraig (Follow me for daily insights)
www.RandallCraig.com: Professional credentials site.