Five Ways IT Projects Go Wrong and What You Can Do About Them

Posted by Nigel H. on Jun 3, 2014 10:54:00 AM

Few projects have so clearly failed as the spectacularly disastrous Tacoma Narrows Bridge which began galloping like a horse until it completely collapsed on November 7. 1940. By some accounts, Boston's “Big Dig” construction project cost $12 billion more than originally estimated and was completed over five years late. Admittedly, few projects are this big and challenging, yet cost and schedule problems are hardly unusual in large public construction projects. Most IT project problems are less obvious and more subtle, but no less deadly. As every Project Manager (PM) will confirm, managing projects is difficult. In a 2010 study of a decade of IT projects, the influential Standish Group CHAOS report found amazingly that a mere 24% of IT projects were considered a success:

  • Successful: 24%

  • Challenged: (late, over budget, fell short of original requirements) 44%

  • Failed: cancelled or never used 32%

From their study, here are five major ways IT projects go wrong.

1. Incomplete objectives

People think they know what's needed, but dig deeper and there's ambiguity. As a result, the WBS isn't properly defined or is incomplete and the Critical Path is inaccurate. Work needs doing that hasn't been planned and other activities are delayed, creating cost and time overruns.

Preventing this means communicating what the project does, and does not, include. Unrealistic expectations must be avoided and every detail should be documented.

2. Lack of stakeholder involvement

Stakeholders are anyone with some “skin in the game.” That's the internal or external client, and those doing the work, but how about supporting players? Here is a short list of stakeholders to consider:

  • Internal resource groups?
  • Compliance staff?
  • Finance and accounting?
  • Key vendors that will have support final solutions?
  • Strategic partners that might be users of the system?
  • Where appropriate, what about senior managers who might have a particular interest or stake in an outcome for the organization?
Reaching out to everyone touched by or who has a current or evenutal stake in a project minimizes surprises and disruptions and surfaces problems early.

3. Scope creep

The client or users ask for additional work. It gets added to the plan, but the impacts might not be obvious. What is your process for review change requests, their impact, or any resulting delays. Change requests should not only be logged, they should not be incorporated into the project until their consequences are analyzed and understood. Are the requests minor enhancements that are obvious improvements to the project? Or, are they major changes in scope that could derail an entire phase? Will it require a radical change to the testing matrix? What are the budget impacts?

failure-success4. Not enough risk planning

As Yogi Berra said, “It's tough to make predictions, especially about the future,” yet that's what project planning is all about. Experienced PM's know to expect the unexpected, and make contingency plans, but it's still hard to cover every eventuality.

Maintaining a “Risk Register” as a living document allows every known possibility to be captured, but just logging isn't sufficient. The PM needs to review the Register regularly and work with stakeholders to develop contingency plans. You should be adding the majority of items to this Register during the early phases of a project when contingency planning is most needed.  The Register should track risks in four steps.

  • Identify, name, and give a tracking number to the risk

  • Asses its severity

  • Document possible solutions in advance

  • Track and analyze steps taken later to manage or control the risk.

5. Inadequate schedule control

Like a five year old on a road trip, the effective PM keeps asking, “Are we there yet?” to detect deviation from plan. Early detection can highlight project issues before they become too serious, but some PMs either use the wrong measures, (spend instead of labor hours, for example,) or don't review often enough.

Often the early warning of problems to come are the hours expended and the duration of key phases and tasks. This is where an effective project time tracking system scores. Accurately logged hours and real-time visibility provides solid data for progress monitoring, and frequent reviews highlight departures from a project plan while there's still time to make corrections.

Get Pacific Timesheet

 

Like what you've read? Click here to subscribe

 

Sources:
Standish report: http://www.slideshare.net/vdumain/standish-chaosreport20100521v1
Big Dig info:
http://www.roadtraffic-technology.com/projects/big_dig/
http://www.city-journal.org/html/17_4_big_dig.html .
PMI 10% wasted:
http://www.pmi.org/~/media/PDF/Knowledge%20Center/Pulse-Data-Highlights.ashx

Photo Credits: http://en.wikipedia.org/wiki/Tacoma_Narrows_Bridge_(1940)

Wikimedia Commons

 

Topics: Projects

Posts by Tag

see all

Recent Posts