12 Things You Know About Projects but Choose to Ignore

Computerworld - There is no mystery as to why projects succeed or fail; people have been writing about effective project management for millennia. More than 2,000 years ago, Sun Tzu described how to organize a successful, highly complex project (a military campaign) in The Art of War. Fred Brooks’ classic book, The Mythical Man-Month, offers management advice targeted at running large IT projects. The U.K. National Audit Office recently published an excellent guide to delivering successful IT-enabled business change (www.nao.org.uk/publications/nao_reports/06-07/060733es.htm). Over the past 10 years, virtually every major IT publication has printed articles on why large projects succeed or fail.

Despite all the excellent advice available, more than half of the major projects undertaken by IT departments still fail or get canceled. Stuart Orr, principal of Vision 2 Execution, reports that less than 20% of projects with an IT component are successful, with success defined as being delivered on time and on budget while meeting the original objectives.

We know what works. We just don’t do it.

Projects fail because people ignore the basic tenets of project success that we already know. Here are some of the common reasons — and there are many — for failure:

An ineffective executive sponsor. A weak or, even worse, nonexistent executive sponsor almost guarantees business project failure. Under weak executive leadership, all projects become IT projects rather than business initiatives with IT components. Since the 1980s, research has consistently found that effective executive sponsorship and active user involvement are critical to project success.

A poor business case. An incomplete business case allows incorrect expectations to be set — and missed. Many business cases describe business benefits in far-too-broad terms. Goals and benefits must be measurable, quantifiable and achievable. (See "Business Cases: What, Why and How," Computerworld, June 13, 2005.)

The business case is no longer valid. Marketplace changes frequently invalidate original business assumptions, but teams often become so invested in a project that they ignore warning signs and continue as planned. When the market changes, revisit the business case and recalculate benefits to determine whether the project should continue.

The project is too big. Bigger projects require more discipline. It’s dangerous for an organization to undertake a project five or six times larger than any other it has successfully delivered.

A lack of dedicated resources. Large projects require concentration and dedication for the duration. But key people are frequently required to support critical projects while continuing to perform their existing full-time jobs. When Blue Cross attempted to build a new claims system in the 1980s, nearly 20% of its critical IT staffers were simultaneously assigned to other projects. The claims initiative failed. Project managers who don’t have control over the resources necessary for their projects are usually doomed.