Twelve things you should not ignore in projects

You don’t need fancy project management methodologies. You just need to practise what you know


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 organise 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 National Audit Office recently published an excellent guide to delivering successful IT-enabled business change. Over the past 10 years, virtually every major IT publication has run 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 cancelled. 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 organisation 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 organisation 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 US$100 million.

No contingency

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

Too long without deliverables

Most organisations 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 Leverage Partners, which helps organisations invest well in IT. Contact him at [email protected]
  • "Recommended For You"

    13 common ERP mistakes and how to avoid making them Big IT projects done small time