12 Things You Know About Projects but Choose to Ignore

Bart Perkins

March 12, 2007 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.

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.

Out of sight, out of mind. If your suppliers fail, you fail, and you own it. Don’t take your eyes off them.

Unnecessary complexity. Projects that attempt to be all things to all people usually result in systems that are difficult to use, and they eventually fail.

Cultural conflict. Projects that violate cultural norms of the organization seldom have a chance. The FBI’s Virtual Case File was designed to share information in a culture that values secrecy and rarely shares information across teams. Moreover, FBI culture views IT as a support function and a “necessary evil” rather than an integral part of the crime-solving process. The project violated multiple cultural norms and met with significant resistance. The Virtual Case File was finally killed after costing more than $100 million.

No contingency. Stuff happens. Projects need flexibility to address the inevitable surprises.

Too long without deliverables. Most organizations expect visible progress in six to nine months. Long projects without intermediate products risk losing executive interest, support and resources.

Betting on a new, unproven technology. Enough said.

An arbitrary release date. Date-driven projects have little chance of success. Will we ever learn to plan the project before picking the release date?

See anything new here? That’s exactly my point.

Next time, increase your chances for success by avoiding these common project pitfalls. Use the above list (and other industry guidelines) to evaluate your project. If you see too many signs of danger, cut your losses and either restructure the project or kill it.

Talk to experienced project managers and read project management literature to review what works and what doesn’t. Though, in fact, you already know.

Bart Perkins is managing partner at Louisville, Ky.-based Leverage Partners Inc., which helps organizations invest well in IT. Contact him at BartPerkins@ LeveragePartners.com.