One hospital's project implementation runs up against a hard deadline, leaving the testing phase incomplete. Another hospital's project is dropped in the face of massive organizational change. A county's project flounders after a shift in the political power structure, while an apparel manufacturer's project collapses because there's no budget for training.
The common thread connecting these failures is lack of due diligence, the fourth in what I consider the seven deadly sins of project management. Here are the elements that support due diligence and help keep projects on track.
Respecting Hard Deadlines. Most business operations are driven by very real deadlines (business cycles), which if breached result in significant interruptions, unhappy customers, disgruntled employees or a drop in revenues. For IT managers, the immutable principle to follow here is this: Never implement a project that results in major operational changes in the midst of an important business cycle. Surprisingly enough, this advice is routinely overlooked and project implementations crumble into a series of patchwork solutions. At the hospital mentioned above, the project team deployed an inadequately tested patient billing system, offering the lame explanation that the start of the financial year limited the time available for testing and staff training. In another more memorable case, a West Coast costume manufacturer deployed an ERP system a few weeks before Halloween, causing major snafus in its distribution system -- and resulting in multimillion-dollar losses.
Factoring in Organizational Change. By its very definition, project deployment means change: abandoning the known and moving to new and often unpredictable approaches. In the excitement over the possibility of new projects producing great benefits, many people overlook the extent of the behavioral relearning required of customers. Often, the relearning takes place without any appreciable reduction in the routine workload, and most development teams are composed of IT professionals who have very little contact with key customers. For example, in the case of the failed hospital project, only a fraction of the doctors -- clearly a crucial user group -- were involved in development. The vital question to ask and answer is, "How disruptive would the project deployment be?"
Working the Power Structure. Another important question to ask is whether the proposed project will reduce, or dramatically change, any key stakeholder's power. If so, how will that individual react to the change? It's so important to understand and acknowledge corporate fiefdoms. In the case of the failed project at the county, the county administrator wanted to reorganize the various departments and assumed that the new project would bring about the shift. To his great dismay, three of the most powerful department heads banded together to protect their turf and blocked implementation.
Prioritizing Customer Training. What will it take in terms of people, skills, resources and budget to support the end product? The answer to this routinely overlooked question can often be a deal killer, as the ongoing education, training and support costs can exceed the original project investment. Too often, this information is suppressed, or purposely underestimated, to make the proposal more attractive. So business managers end up with irrational expectations, and CIOs don't always have the courage to tell them the truth.
Astute IT executives make sure that their project managers are prepared to handle the realities of hard deadlines, organizational change, power structure shifts and customer training needs.
Gopal K. Kapur is president of the Center for Project Management in San Ramon, Calif., and author of Project Management for Information, Technology, Business and Certification. To comment on this story, email ProjectExpert@ciodecisions.com.