“Deliver on Time” revisited – the Iron Triangle

The ‘Iron Triangle’ known to all project managers is one of the cornerstones of the profession. Essentially, it defines the major project constraints of time, cost and scope (sometimes quality is shown in the middle). On most traditional projects, scope is fixed through definition of the requirements at the start, and the PM spends a lot of time trying to manage the cost and schedule aspects. And if and when the project overruns, it is often the quality that suffers.

But how does this apply to an agile project? Do we look at it differently?

The iron triangle is not something specific to any method. It is an expression of real project constraints, whatever method you are using. Agilist Scott Ambler, Chief Methodologist at IBM Rational has written about this, urging people to respect these constraints and actively plan for how to deal with them, even on an agile project, and arguing that fixing all three elements is possibly unethical.

DSDM expressly turns the typical triangle on its head, fixing time and cost, with Scope the variable corner of the triangle. This means that DSDM is perfectly suited to fixed-cost (fixed budget in Scott Ambler’s terms) projects, something that ‘Agile’ (i.e. Scrum) has long struggled with judging by the debates on the forums. But what if the project really does demand a fixed scope? What does DSDM do then? After all, “Deliver On Time” is its second principle. Can we really fix scope and time? I wouldn’t.

Fixed-cost projects are numerous (According to Scott Ambler’s survey in 2010, 62% of agilists prefer to deliver on time… and 34% prefer to deliver when the system is ready”) and for those, using DSDM in its current state is fine. Fixed-scope projects require a different approach. I have come across Business sponsors who are happy for a project to take longer “provided I get everything I ask for”. In this situation, you could argue the case for not fixing the scope and explain till you’re blue in the face why you shouldn’t. But then you are working for the Sponsor, not the other way around. The BEST solution is to fix the scope and baseline it at a high-enough level that you know the list of requirements is unlikely to change. Then you create feature-contingency by decomposing and re-prioritising.

Or you accept that the scope is fixed. In which case, what do you do with the second principle?

Yes, DSDM works best when you fix the delivery date at the end of Foundations, but if you do have a fixed scope, fixing the schedule as well is dangerous! Unless of course, you have a large pool of skilled people sitting around ‘on the bench’ waiting to be called upon to contribute. You haven’t? No, I didn’t think you had. So if the scope is fixed, the easiest thing to do would be to prioritise using a ranking system (since MoSCoW isn’t applicable without a timescale) and just run one timebox after another until the project finishes delivering the scope. It doesn’t mean we abandon DSDM, just tweak it a little, adapting it – as you would with any other framework – to the needs of the project.

I think that, like any other project, a DSDM one should consider the possibility that the iron triangle can rotate to ensure that any one of the three corners are variable, while stressing that the preferred configuration is fixed time and (people) cost, but variable scope. Perhaps the second Principle should be “Deliver within agreed project constraints” or something similar.