In-Depth

Planning for success by planning for failure

• By Patricia Keefe
• November 1, 2004

You’ve exercised due diligence, assessed risks, allocated resources, set deadlines and dutifully gone down the standard project management checklist. The follow-up plan calls for constant communication, status reports and reassessments -- so far, so good in planning for success. Wait a minute: Have you planned for failure?

Avoiding failure is obviously critical to any plan for success, and requires constant patrolling for signs of processes gone awry, support slipping away and other omens of impending doom. In addition, it requires decisive action to kill small problems before they grow into big ones. It also comes from knowing when to fold up your tent.

A project that could have lost $10 million but only loses $3 million because it was either swiftly retrenched or shut down is, in a manner of speaking, a success. Larry Sisemore, a managing consultant with PM Solutions, gives Ford kudos for recognizing when it was time to stop its ill-fated Everest project. “A lot of companies would have continued, saying ‘We’ll make it work,’ but you have to have the strength and the ability to say ‘This is not working’ and pull the plug.”

Here’s a list of problems common to all projects: * Scope creep. It takes a backbone of steel to stave off scope creep, the silent and frequent killer of many projects. If a tremendous number of changes are coming over the transom, you need to re-evaluate the requirements and goals. On the flip side, developers can get excited about a project and decide they know what users really want. One of the cardinal rules of project management is that you do not produce any more functionality than is required or requested by users. Doing so can be a “tremendous failure inside an IT organization,” says Sisemore.

* Inadequate sponsorship. Sponsors too often don’t understand the investment in time their roles require. Sisemore thinks sponsors should receive training on how to sponsor because many have no clue.

* Inexperienced and inadequately trained project managers. Certification is just a starting point and years of technology experience do not translate into the skills needed to be a project manager. Communication, leadership, authority, creativity and agility are vital to resolving issues before they blow up.

* Changes in the business risk. What are the chances the business will change course or that a turn in the economy will affect it? “On these long, drawn-out projects, the latter can undermine the business,” says Matt Light, a research director at Gartner.

* Developing in a vacuum. It’s not enough to break down projects into smaller chunks and test each one. The pieces have to work together, and usually within a larger system, so integration testing is critical.

* Rushing the job. The testing window on large projects is more apt to shrink than grow. The project falls behind schedule, but the deadline rarely changes, leaving less time for testing. This often leads to people skipping critical test procedures. Hewlett-Packard, for example, failed to adequately test its new ordering system, resulting in a PR and financial disaster. Once you stop planning and start executing, you can expect a major failure.

* Rigidity. Just because the plan specifies a completion date doesn’t mean that date is realistic or even important. Although IT needs to try and hit the mark, management needs to understand that most dates are arbitrary and merely estimates. Speaking of rigidity, large projects often require cultural changes, but these are the most difficult to achieve.

* Miscellaneous. Other issues include inadequate or outdated risk assessment and resource allocation issues.

Process lies at the heart of project management and good software development, so it should come as no surprise that even the act of shutting down a project has its own procedures and checkpoints. The Center for Project Management in San Ramon, Calif., has created a methodology for identifying and canceling troubled projects called, appropriately enough, ProjectHalt. If your project has reached critical mass, a detailed schematic to step you through the process can be found at www.center4pm.com.

Please see the following related stories:
Oops! Ford and Oracle mega-software project crumbles by Patricia Keefe
Failing to fear is more important than fearing to fail by Patricia Keefe