by Randall CraigFiled in: Blog, Make It Happen Tipsheet, Planning, TechnologyTagged as: CRM, Project Management, Technology
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:
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.
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.
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 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.
Does this topic resonate? Reach out to Randall: he can present it to your group. (More presentation topics)
See Randall’s professional credentials: Download one-sheet.
@RandallCraig (Follow me for daily insights)
www.RandallCraig.com: Professional credentials site.
Each week, get Randall’s 60-second nugget on translating digital knowledge to action. Curious? Read 600+ past articles.
If you are interested in receiving these each week (there is no cost), fill in your name and address below.
Contact us for more on Randall’s topics, availability, and audience fit.