If you’re a project manager like me, you’re sick to death of the Standish Group’s Chaos Reports.  They come up in virtually every project management course I’ve ever taken or taught, and their basic premise is that, as project managers, we stink at our jobs. Since 2011, the success rate of the projects Standish evaluated landed between 27% and 31%, and the rate of projects either challenged or failed fluctuated between 69% and 73%. Not exactly a stellar record. 

Source: Standish Group CHAOS report 2015

To be fair, the Chaos reports paint a much more nuanced picture than simply implying that project managers can’t manage projects. They measure elements such as the size of the project, the level of executive sponsorship, the level of user involvement, the skill set of the resources assigned, and much more.

Significantly, in this year's report Standish Group has changed their definition of a successful project, from simply on time, on budget and within scope, to include the new language “with a satisfactory result”. My belief is that this change is a direct result of the agile movement, as the delivery of value is now recognized as an essential element of project success. As Jennifer Lynch from Standish told InfoQ in a recent interview, “We have seen many projects that have met the Triple Constraints and did not return value to the organization or the users, and executive sponsors were unsatisfied.” On their blog, Standish Group has taken a bold departure from traditional project management measurements to state, “The Standish Group believes that organizations should forget the triple constraints and focus on the value of their project portfolio, not individual projects.” Forget the triple constraint!? For those who’ve gained their PMP certification or toiled in the traditional project world, this is heresy. For agilists, the idea of focusing on value is obvious.

New in 2015, and of special interest to any agilist, is the inclusion of comparisons between agile and waterfall projects, and the insertion of a new metric, “Emotional Maturity” in the mix of success factors.

Let’s review these new elements individually. In a head-to-head comparison between agile and waterfall projects, illustrated here, the success of agile projects, regardless of project size, is significantly higher, with the number of challenged or failed projects correspondingly lower. In the InfoQ interview, Ms. Lynch states simply that agile can be helpful “…by failing earlier and restarting faster.” Agilists know there are many more factors involved in agile success, but “fail fast” is indeed a key element.  Regardless of Ms. Lynch’s simplification, the fact that Standish has rigorously reviewed over 50,000 projects of all types and sizes, and concluded that agile is significantly more likely to succeed, is a weighty outcome. Every agile advocate trying to convince leadership that agile works now has a very influential new arrow in their quiver.

As fascinated as I am by the agile statistics, the inclusion of “Emotional Maturity” as a success factor is especially significant to me. I’m a trainer of IT consultants, focusing on consulting and relationship skills rather than technology, and I’ve contended throughout my career that projects fail for human reasons much more frequently than for technical reasons.  It’s great to get this validation of that theory from Standish. As Ms. Lynch explains, “Emotional maturity skills are often called the soft skills. Emotional maturity skills include managing expectations, consensus building, and collaboration. We saw a major correlation between poor emotional maturity skills and lower success/value rates.”

The convergence of these two new elements, agility and emotional maturity, are especially potent.  Agile requires IT professionals to break down the walls between IT and the customer, and it requires project managers to look beyond the Triple Constraint to business value. Both of these transitions require the emotional maturity and consulting skills that Standish is now highlighting. What good is an elegant technical solution if we can’t facilitate a group to consensus?   What’s the benefit of software craftsmanship if we don’t have the ability to help clients articulate their stories? The old practices, of “project bureaucrats” hiding in their cubbies updating Gantt charts, and of an IT priesthood in a separate department, with supplicants begging for software or support, are dead. The concept of agility without emotional maturity and consulting skills is a non-starter, and it’s a giant boost to see the respected Standish Group validate that idea.