The Bermuda Triangle for Projects
We all run afoul of this from time to time – it’s known as the Project Management Triangle or the Iron Triangle. It encapsulates the tension between schedule, cost and scope that occurs on any project, and it appears in a number of forms. Over time, as the Wikipedia article demonstrates, people have explored how it’s not quite that simple. In constructing a house, for instance, you can still achieve the essence of the scope of the project (e.g. all the rooms) in fixed time and cost by sacrificing quality (e.g. a formica bench instead of granite, or cheaper carpet).
It is also a critical factor in how we as Business Analysts prioritise business, stakeholder, or solution requirements. For each requirement it should be possible, if you are so inclined, to measure time and risk and cost and the value delivered by the scope of the requirement. In practice, prioritisation is typically done by a subjective stakeholder agreement session.
Understanding What’s Wrong
The Iron Triangle reaches its nadir in the phrase: ‘Fast, cheap, good – pick two.’ I have two issues with this sentence.
The first issue I have is that it encourages the idea that it is always possible to actually complete a large project on time and on budget. (That’s not what it says, but it is how it’s interpreted.) Sadly, for most Information Systems (IS) projects this is more due to good fortune than good judgement or hard work. The second issue is that ‘good’ is interpreted as referring to quality rather than scope. A while back I worked on a project where the stated priorities were time, then cost, then quality – “but we’re not sacrificing quality at all”.
Here’s why I think having an Iron Triangle of time, cost, and quality is a bad idea on an IS project. Scope in this context is implicitly fixed, even if it’s not fully understood. But when we sacrifice quality, what we’re actually sacrificing is uncontrolled scope. This is because quality usually degrades unevenly across the scope of the project, although it may degrade more in specific areas. If a piece of software has poor quality, it means it doesn’t do the job that’s being asked of it to the standard required by the client. I don’t mean that the solution must instead be perfect; rather, that it should meet the agreed and accepted quality targets. If it doesn’t then the client will not accept the solution, either actively by rejecting it or passively by not using it.
For the example below, imagine our scope as a list of 100 requirements, grouped so that requirements near to each other are part of the same scope area. As the project proceeds, analysis uncovers 10 additional requirements, which we insert in their appropriate places in the list. This causes the scope to expand.
Figure 1- time, cost and quality.
Figure 1 demonstrates what happens if we sacrifice quality. At some point (usually late) during the project we find out that due to poor quality, the requirements will be incompletely met across all requirement groups. The solution doesn’t work, and it’s not going to work within our ‘hard’ constraints of time and cost. To deliver a complete solution we now have to choose whether to:
- allow an increase to time and cost, i.e. overrun the project, in the name of delivering the expected and agreed scope;
- make scope cuts to meet the budget by stopping work on some of the groups of requirements, against the backdrop of an expectation that the full scope will be delivered;
- or, more likely, both.
What We Can Do Better
Figure 2 – time, cost and scope
In contrast, Figure 2 shows the result of sacrificing scope. As analysis proceeds we determine early that we won’t meet the budget, because our understanding of the size of the scope has increased. We reduce the scope in agreed areas as early as we can. This allows us to manage the savings that we need to continue to provide the best value, instead of being driven by the quality of the delivered functional areas. It also allows us to set expectations early about what scope will be delivered, and what workarounds or alternative solutions might need to be put in place.
When we get the opportunity to work with stakeholders to determine how we define project success, project sliders can be useful. I prefer to use sliders in such a way that no two sliders can be on the same setting. This means you need as many settings as you have sliders, but they prevent someone from setting time, cost and quality as 5 and everything else as 0, for instance. This isn’t a problem that we fix with tools, it’s about education and setting expectations. And sometimes we’re just not in a position to influence these attitudes.
When we’re working with stakeholders to prioritise requirements, we need to encourage them to think clearly about what their priorities are, and the implications of setting those priorities given the funding and schedule. We also need to make sure that the stakeholders can trace the requirements to their relevant benefits and understand the relevant costs, benefits, risks, compliance aspects, or whatever factors they have agreed to be used for prioritisation.
For example, using MoSCoW priorities:
- If it’s a Must-Have, then if we can’t find a solution, we need to reconsider the project viability. (Are you sure it’s a Must-Have? Does the business value of the requirement justify this?)
- If it’s a Should-Have, we’ll do it if we have time and budget left over. (What are the relative priorities of the Should-Haves?)
- If it’s a Could-Have, then we’ll only do it if it’s effectively free.
We need to do this whenever we’re deciding which requirements to proceed to the next stage with. For a Scrum project, this might be at each sprint. For an iterative project, this might be at the end of the stakeholder requirements analysis and the end of the solution requirements analysis for each iteration.
If instead the stakeholders persist in talking about time, cost and quality, it encourages them to think of scope as being fixed and the ‘everything’s a must-have’ mentality. It makes it harder to admit that they need to make the tough call early, and either increase schedule or cost, or decrease the scope. When they finally need to make the call, it’s more expensive and they have fewer choices.
That’s when the stakeholders need to admit that they didn’t have a priority of time, cost and then quality. What they actually needed was the ability to make transparent and informed choices about changes to scope, cost, and time. We as Business Analysts contribute to this by performing sufficient requirements analysis to identify those prioritisation factors, and by encouraging stakeholders to review their prioritisation at the right times.
Don’t forget to leave your comments below.