Agile: Anatomy of a failed project
A finite set of problems causes almost all IT failures: including lousy requirements planning and mismatched expectations among key stakeholder groups. Agile practitioner and trainer, Mitch Lacey, dissects these issues in a valuable video presentation titled, "When Working Software Is Not Enough: A Story of Project Failure."
Mitch describes the project background, details initial warning signs, walks the audience through progressive steps of failure, and suggests post-mortem lessons learned. Mitch explains how Agile development could not overcome basic misunderstandings that ultimately led to catastrophic failure.
Several key warning signs early in the project suggested downstream failure. Most significantly, in my view, the customer stated a $500,000 budget, while Mitch's team assessed the cost at $1 million. To meet this budget, the developers pushed critical work back to the customer, as described in the following slide:
Another key warning sign was lack of clarity around requirements at the project start. Mitch illustrates this point in the following diagram:
By establishing equal weight for both the technical and non-technical dimensions, this diagram is fundamentally flawed. For most projects, ambiguous requirements, such as those as shown in the chart, directly cause downstream failure. A more complete and objective upfront analysis would have put this project firmly into the red zone; clearly, the team ignored critical warning signs.
According to the following slide, the project didn't really crumble until two months prior to planned delivery to the customer. By that time, neither side could deny the reality of failure:
As you see in the following slide, the project concluded as badly as it started--over budget, delayed, and project scope still in dispute:
THE PROJECT FAILURES ANALYSIS
Virtually all software failures involve dysfunctional relationships between three groups I call the Devil's Triangle: customer, services provider, and technology vendor. Devil's Triangle relationships are always difficult to analyze, as I reported in a post describing a failed ERP project:
The complex and interlocking set of business and technical agendas governing these relationships can make failures difficult to dissect accurately. Of course, the parties usually don’t want to discuss their failures in detail, which also makes full analysis hard.
Services provider. In comments to the video, Mitch acknowledges conflicting relationships between his employer and the customer:
My common sense answer was "cut the budget, cut the work" but that was not going to fly. I event went as far as to suggest that we just turn down the project flat - but we had a pending $6m statement of work with the customer and doing that would have put that at great risk.
To avoid jeopardizing other potential revenue from the customer, the services provider accepted a vague statement of work (SOW) that haphazardly defined the current project. One commenter to the video post correctly commented:
[W]hat was communicated when the budget was only half of what was estimated. The standard reaction should be: "then you're basically going to get half of what you asked". Instead, project tasks were offloaded to the customer (as if they don't cost anything when the customer does it). The customer could keep on thinking he could have his cake and eat it too.
Customer. In my opinion, this customer was inexperienced and also attempted to manipulate the services provider. According to Mitch:
- Customer did not review the system when they said they did
- Customer did not understand the process and the impacts their decision had – They agreed to take a direction and then move on – They did not understand the impacts – We later found they would not be accountable
Trust me, all customers understand there's a relationship between features, functions, time and cost. Customers who proclaim otherwise are being disingenuous.
Technology vendor. The internal IT department controlled technology governance and used its power to hold the project hostage. Lovely, don't you think? Here's Mitch's slide:
My take. This failure has nothing to do with Agile, waterfall, or any other methodology. The real culprit was hidden agendas, politics, inexperience, and greed.
I asked Tom Looy, Managing Director of Tacit Knowledge, a global technology services company focused on Lean and Agile development, for his insight on this case:
Situations like this happen when the prioritized backlog of story cards is frequently re-prioritized by the project stakeholders. If the 'Agile effort' on the project is focused inwardly to optimize efforts of the development team, with insufficient effort paid to managing outwardly beyond the immediate stakeholders, then your project can get still get derailed.
Regularly scheduled meetings with the stakeholders, beyond the Iteration Planning Meeting and 'Show and Tells' at the end of each iteration, are critical to achieving success. These meetings draw out any changes in the goals of the project that might re-prioritize the work and draw out conflicting agendas between project stakeholders. Regardless of the methodology used, whether Agile or anything else, these meetings are critical to overall success.
Project success depends on carefully aligning expectations among stakeholder groups. If you don't accomplish this goal, right from the start, your project will likely fail. Despite the difficulty, regardless of the time involved, this cardinal rule is virtually inviolable. Ignore it at your peril.
[Thanks to Mitch Lacy, who did the best he could under tough circumstances, for his candor and openness. His video presents one of the most practical and down to earth failure dissections I've seen. Highly recommended! Azita Houshiar, Dir. of Marketing at Tacit Knowledge, arranged the interview with Tom Looy, by responding to this Twitter tweet from me.]