More on why projects fail

This post on top reasons for IT project failure by Ron Sheldrick has up on LinkedIn for a while. Here were my two cents, nothing new if you’ve followed for a while:

@James Pastor [a fellow commenter] hit on the scope issue early on in this thread. Back in my SAP days we found that poor knowledge of the contract and SOW — especially among the project team and contractors — was a common thread among troubled projects. The strategic assumptions that underpinned the initiative were lost as the project devolved into satifying immediate, tactical needs…which deviated from the original plan.

We also found that stakeholder and communications went begging. While these stakeholder and communications management techniques are simple in form, we found that many project managers can’t muster the motivation or confidence to execute against them consistently. These “symptoms” are great non-obvious indicators for project health:

  • Projects that consistently linked stakeholder analysis, communications planning, and plan execution stayed out of trouble.
  • Project managers who did not fit into, or could not adapt to, customer cultures, mission-critical projects, etc. were reluctant to escalate projects quickly enough.
  • The most frequent communications mistake was failure to execute planned executive-level messaging, which eroded the project manager’s position in the eyes of sponsors and other leaders.

These stakeholder management findings correspond with recent external studies noting that communication breakdowns – especially “keeping quiet” about known risks or issues – are a primary driver of project failures.

Sound and fury, signifying nothing

Pay no attention to the project behind the curtain...

Communications practices are a gold mine for the troubled project prospector.

Another sign that a project is headed for trouble is another communication quirk: discussions aren’t reflected in any documented issue, action, risk, deliverable, etc.  The most familiar example is a colleague who can always “fill in the details” on a topic during the discussion, but never seems to have the details at hand.

You might as well tell me: “Dig here… plenty of goodies buried in this team, project, etc!”

Portfolio Management and Troubled Projects

SAP has had a lot of success using project portfolio management — especially via regular monitoring and controlling of the project inventory — to reduce the number of troubled projects and their impact on margin.  Michael Krigsman’s IT project failures blog has a useful post summarizing some of the main challenges.

Michael’s comment is spot-on…my bad.  Thank God for “edit…” 

His interview w/ CA is tool process-centric, and of course an SAPling won’t downplay the value of PPM tools!  In fact, we’ve found that putting a basic process foundation in place — regardless of tool support — to be very effective.  The very act of systematically monitoring the project portfolio surfaces potential project failures more quickly, reduces the probability of failure, lowers the impact if failure(s) happen, and shortens the duration of the adverse events. 

SAP PMOs that operationalized PPM — even with first-generation tools — have had fewer, shorter, and lower impact escalations than those that don’t.  PMOs that wait for the “perfect” approach always seem to get blindsided.

%d bloggers like this: