Make It Happen
My Tipsheets are chock full of ideas. They are all aimed at translating knowledge into a quick, action-oriented 60-second nugget.

First Name:
Last Name:
Tipsheet Archive
Randall's Resources
Whenever I speak or write, I often prepare extra "bonus" materials.
Enter the Resource Code to access this special content:
Resource Code:
Try this example Resource Code: eventplanning

Avoiding tech project failures

by Randall Craig on June 10, 2016

Filed in: Blog, Make It Happen Tipsheet, Planning,

Tagged as: , , ,

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. Next week’s Tipsheet will explore these.

This week’s action plan:  While large-scale tech projects don’t start every day, most organizations are in the middle of at least one.  This week, you use these points to either reduce existing project risk, or “re-launch” a project gone bad.

Management insight:  These items don’t just apply to large software projects, but are important for virtually all projects.  Look at a project gone sideways and you’ll often see poor infrastructure choices, poor planning, poor continuity, minimized training, and inadequate support.

Note: The Make It Happen Tipsheet is also available by email. Go to to register.

Randall Craig

@RandallCraig (follow me)




Randall has been advising on Digital Strategy since 1994 when he put the Toronto Star online, the Globe and Mail's GlobeInvestor/Globefund, several financial institutions, and about 100+ other major organizations. He is the author of eight books, including Digital Transformation for Associations, the Everything Guide to Starting an Online Business, and Social Media for Business. He speaks and advises on Digital Transformation, Digital Trust, and Social Media. More at

Leave a Comment

Previous post:

Next post: