Project Failure, Well Illustrated

Whatever your politics – and I live in Canada where I receive government-funded healthcare that Generally Works – the brittleness of the Healthcare.gov site is a great illustrator of some very common causes of software project failure.

Arstechnica has a solid analysis of the causes of the failure in the case of the US health care site. Enumerated there, problems include architectural choices, project management missteps, and a lack of disciplined development practices.

The Arstechnica article also references the Standish Group’s research and commentary. Standish publishes disturbing statistics about the rates of software project failure. Their “recipes for success” haven’t changed much in the thirty years that they’ve been collecting data on IT projects. Their top identified success factors from their data: user involvement and executive support.  According to Thomas Edison and Michael Jordan, failure is something that can help you grow: my clients don’t want to pay for project failure, though.

Of 3,555 projects from 2003 to 2012 that had labor costs of at least $10 million, only 6.4% were successful. The Standish data showed that 52% of the large projects were “challenged,” meaning they were over budget, behind schedule or didn’t meet user expectations. The remaining 41.4% were failures — they were either abandoned or started anew from scratch.

– Computerworld article, with data from Standish

So larger projects are even harder to manage. Are there methodologies or technology solutions that solve these issues? Yes, there are tools and leading practices that address the common causes of failure, although it’s even harder in the public arena, where politics rather than reason is often the origin of the requirements. Getting the “soft” side right – sociology and psychology – seems just as important. Managing the messaging of the methodology with the organization’s culture, and achieving buy-in from the project team AND the stakeholders, significantly increases the chances of project success.

Related articles

• Obama campaign tech leader on healthcare.gov: “It makes my brain bleed” (medcitynews.com)
• The Demise of Healthcare.gov and the Importance of Testing (loadimpact.com)
• Healthcare.gov’s New Woe: Datacenter Failure (slashdot.org)
• Standish Numbers (herdingcats.typepad.com)
• 5 Lessons from Healthcare.gov Software Disaster of the Century (softwaredisastersblog.com)

No Silver Bullet

Methodologies in the development realm come and go and produce vastly different results for different teams. Philippe Kruchten writes that within the Agile methodology set of practices, which he describes as the Agile Memeplex, is “a family of approaches and practices for developing software systems.” Unfortunately, “Any attempt to define them runs into egos and marketing posturing.”

At Coding Horror’s site, there’s a great article that has a good list of the superset of software methodologies, from Structured (1969) through some of the Agile processes, and suggests that we expect marketing to get these concepts – TDD, Scrum, Agile – into the heads of managers and developers. Unfortunately, most programmers are unreachable. Atwood’s solution is to focus on some core development principles: DRY, KISS, and YAGNI.

Tom DeMarco wrote an article that essentially said that Software Engineering – the need for metrics and control – is dead. This caused a bit of a stir. In his seminal book Peopleware (written with Timothy Lister), which was originally published in 1987 and has lots of Useful Things ™ in it like how not to burn out teams, there is a chapter that outlines the relative productivity of developers depending on who does the estimating. Programmers are more productive when they do the estimates instead of their supervisor, and even more productive when the analyst does the estimate. Bad estimates, especially hopelessly optimistic estimates, sap developer productivity. But what fits with the theme of DeMarco’s recent article is the conclusion of that chapter: in cases where there is no estimate at all, developers have much higher productivity. Pressure needs to be applied selectively.

Tied to the theme of methodology as religion, or for the sake of having a methodology, is that very often the marketing words are used without understanding the point, or without having a team that is educated or motivated to gain the benefits. Flaccid Scrum doesn’t work because as Martin Fowler says, “Scrum is process that’s centered on project management techniques and deliberately omits any technical practices”. One blogger puts it like this:

It’s about how Agile teams perform and the correlation to the way people and organizations are transferred from working with a waterfall, ad hoc or other development process to Agile in general and Scrum in particular. In my experience, this metamorphosis is often not done in an adequate fashion and sets up the whole organization for confusion….

The unifying theme of all this? In software development there is no single silver bullet to create great software on time and on budget, a theme which is central to Brooks’ Mythical Man Month, McConnell’s Rapid Development, and the eventual outcome of every new “best practice.” As Martin Fowler puts it, we need to “understand the importance of strong technical practices… it isn’t methodologies that succeed or fail, it’s teams that succeed or fail.” My goal is that by sharing and tying together practices and concepts that have worked for my teams, I’m contributing to the software methodology memeplex instead of adding to Fowler’s SemanticDiffusion.

Related articles

• Has Agile Development lost its way? (robteichman.wordpress.com) (this was posted 3 hours before I posted this :))
• Why agile isn’t enough for many software projects (zdnet.com)
• Beyond Agile: New Principles? (xprogramming.com)
• Manifesto for Half-Arsed Agile Software Development (halfarsedagilemanifesto.org)
• The Frog and the Octopus: Different Perspectives (kruchten.com)