Back
Part II –The Technical Factors
Failure seldom results from only one factor, but from the convergence of many that conspire to ruin even the best plans. Part I of this article described the Organizational Factors that contribute to enterprise technology project failures. Equally significant are the Technical Factors, which entail the technology, methodology, and overall quality of the implementation. The most notable errors in this area include:
Choosing the Wrong Software: In the 1990s, during the rush to implement ERP systems to avert the Year 2000 (Y2K) problem, SAP ran the motto “The best-run businesses run SAP” (later refreshed to “The best run SAP”). It was an appealing slogan. Many companies, large and small, hastened to acquire SAP believing it was the panacea that would not only inoculate them against the impending Y2K disaster, but also fix the flaws in legacy processes that had accumulated over many years, and enable them to join the club of the “best-run businesses”. The results were too often disastrous. SAP is a superb ERP system. Just like a Ferrari is a formidable car. But not everyone has the driving skills to handle a Ferrari (or can afford its upkeep). Those who conducted a poor evaluation of the software, its transactional demands, its implementation requirements, and its fit for their business practices, suffered failures in many aspects of their projects. Some companies that managed the implementation relatively well discovered afterward that they had bought “too much system” -overly complicated, too demanding, and too expensive to maintain.
Ill-Defined Scope and Loose Boundaries: Poorly defined outcomes, and a lack or weak governance to ensure that milestones are met without distraction are a prescription for project failure. The proverbial “scope creep” creeps in only when confusing or changing requirements plague a project, the lines between the “must have” and “nice to have” are blurred, and project resources are shifted to accommodate the whims of a loud voice or someone in authority.
Ambiguous Ownership: With the first sign of trouble, blame-shifting and finger-pointing arise, often making a bad situation worse. This is especially bad when a third party (i.e., a System Integrator) is involved, with the hot potato being tossed among the customer, the vendor, the SI, and whoever else can serve as a convenient scapegoat. None of this can rescue a troubled project, but avoiding the situation from the outset by establishing clear roles and ownership of outcomes can save a ton of discord.
IT in the Driver’s Seat: Because they are cast as technology projects, IT implementation efforts are often assigned to IT to lead (or IT jumps in to lead them) with nominal support from the rest of the organization. This is a mistake. It leads to the organizational disconnect mentioned in Part I, shifting the responsibility for an enterprise transformation project to one department, and leaves IT with the master role of designing the business for the new system. Eventually, a drift occurs between what IT builds and what the users of the system expect, and the project fails.
Inadequate Skills: In one case, a large organization assigned the leadership of a major technology project to a mid-level IT manager who had risen through the ranks as a competent programmer, earning the confidence of the company’s senior managers. He had no experience with large enterprise system implementations, and his knowledge of project management was limited to his own sphere within the IT department. Yet he was now managing a large-scale multi-million-dollar project, staffed by personnel from across the entire company, and managing third-party consultants and system integrators for the first time. Try as he could to learn on the job, grave problems were inevitable.
Technical Architecture: In many companies, the IT environment grows by accumulation as there is seldom time to routinely examine the entire technical architecture. With the speed of change in technology, IT departments dedicate most of their time and resources to ensuring the stability of critical systems and introducing new components. That state is severely tested when the requirements of modernization or a new system expose deficiencies that the organization had learned to tolerate, such as poor data quality, fickle interfaces, antiquated hardware, and critical legacy systems past their end-of-life.
Poor Project Management: Project management methodologies have become like cults, with the fans of each (Waterfall, PRINCE, Agile, Scrum, Lean, etc.) strongly advocating their preferences. Too often, more time is spent on adhering to the methodology and the tools than on managing the project. Things gradually, then rapidly, get off the track, and energy is spent on keeping up appearances -the more desperate the situation, the more optimistic the progress report. A proficient project manager, an adept project team, and a supportive corporate culture make all the difference between success and a story for the annals of failures.
Short-changing Training: When a project runs into trouble, the effort to bring it back on track will predictably tackle the budget. One item I have too often seen immediately targeted is training: Shrink the time allotted for it, reduce the number of people involved, and trim the budget allocated for those activities. (Ditto for User-Testing). Keeping with the Ferrari analogy mentioned earlier, it is like spending two hundred thousand dollars on your first state-of-the-art muscle car, but skimping on driving lessons. During Go-Live week, everyone is scrambling to navigate the new system, the few people who have been trained are stretched between their own duties and fielding questions from colleagues, and the users of the new system grow frustrated and turn hostile to the technology.
Size Matters: A Gartner study found that the failure rate of large IT projects with budgets exceeding $1 million was almost 50% higher than for projects with budgets below $350,000. There is a thrill in the Big-Bang approach, but the dynamics of large tech projects are too many to fully identify and mitigate. Breaking a large project into smaller ones of limited size, complexity, and duration, and making contingency plans to deal with unavoidable risks will do much to reduce the pain.
Final Thought
Here’s the conundrum: The culprits outlined in the two parts of this article have been known and written about for decades; so why do technology projects continue to fail or -to use a less traumatic term- become impaired? One simple answer is that organizations continue to commit the majority (or all) of these blunders, believing that their projects are somehow immune to the ills that afflict other people’s projects.
There is no magic solution to this chronic problem. Complex projects are hard to get right. Their success is predicated on the skillful blending of organizational and technical elements. As obvious as this perspective may appear, the experience and wisdom to make technology projects successful are regularly underestimated.
The leadership and rigor required for introducing a product, launching a marketing campaign, or taking on a competitor, are just as crucial for implementing transformative technology. As global companies become more reliant on information and analytics to run their businesses, refreshing their technology systems periodically is inevitable. But so are the risks involved. Alleviating those risks requires the diligence and attention of top managers, and expert hands to guide the process.
My intent in this piece is to provoke a few diagnostic questions from organizations that are contemplating technology endeavors. A candid readiness assessment of organizational and technical strengths, and ability to absorb likely bumps, should be a prerequisite to any tech project to improve its chances for success.
Author: Bassam Fawaz
