Challenges of "challenged" projects

It is no secret that IT projects often fail.  That is expected, and it is overall a good thing – it takes more than one attempt to achieve success.   Other IT projects succeed, which is great all around.  And then there are projects that are considered “challenged”. 

“Challenged” projects are not the same as challenging.  Challenging projects gather enthusiasm of the team, and, hopefully, support from the rest of the organization.  In contrast, “challenged” projects are in enough trouble to not be considered a success, but they lack attention and support that would lead to reorganization - or cancellation.    These projects are project-management debt on the organization’s balance sheet, similar to technical debt a team can incur on a software project.

Here is what a “challenged” project looks like.  It is behind schedule.  The team morale is low.  Stress levels are high.  Technical debt is piling up, while the technical quality is deteriorating.  Project documentation is also deteriorating. Rising pressure to deliver, growing disconnect between the team and the rest of the organization.   Lots of time spent in long meetings, where blame is assigned and passed around.

The main difference between “challenged” and failed project is the finality.  Project that is declared a failure generally ceases to exist as a time, effort and money sink.  The hard decisions are made, and the team can move on.  In fact, when one of the Ambysoftsurveys asked about it, over 40% of respondents said that they consider canceling a troubled project a success.  However, as much as 40% of projects continue to exist in the “challenged” state in traditional and ad-hoc environments.  That means at any given time nearly half the organization is unproductive, upset, and is busy blaming their teammates.  

The Agile and iterative environments do much better – only 20% of projects are “challenged”, or, more likely, troubled projects spend less time in “challenged” state.  Iterative processes, including Agile, operate with short time-boxes, and require regular decision-making about the state of the project.   Regular integration and demos, required for Scrum and other iterative methodologies, exercise the pain points of IT developments, and emerging architecture, a hallmark of Agile, allows deal with technical challenges as they are encountered.   An involved Project Owner helps the rest of the team determine whether the product addresses the underlying business problem, which helps build the right product – or realize that an IT project is not doing well. Most importantly, Agile minimizes the stigma of failing – and lightens the burden of cancelling a project that is not worth saving.  

Canceling a failed project is always hard, but it opens new opportunities for the organization - opportunities to start over, to benefit from lessons learned, to boost morale and do better next time.  Agile helps achieve a fresh start.