Some thoughts on Agile: The Triple Constraints

In traditional project management every project manager learns about the triple constraints: scope, time, cost. When it comes to plan a project first of all it is the job of the project manager to align all three factors to form a triangle. Everything other than a triangle would not be a project in the pure sense of project management philosophy. For example when you have a well defined scope but no idea when you will be finished you don’t have a project. Or the other way around: you know exactly when you will finish but you have not specified exactly what to deliver by then.

How does a project not look like …

Or if the duration for the given scope is simply too short, enforced e.g. through some political power, you don’t have a project.

These are project management fundamentals so to speak.

It means as a project manager you need to have the degree of freedom and power to adjust at least one of the factors to form that triangle. If you don’t you better stay away from that project – this is my philosophy.

Maintaining that triangle shape of a project also is important when planning is over and you enter execution phase. You might have done a good job during planning phase to define your project well, but when you fail to manage change your triangle very quickly might turn into some other shape indicating a messed up project. Most common example: you keep adding changes to your scope without adjusting at least one of the other two factors: cost and duration. Many well planned projects fail because of improper or basically non-existent change management.

If a project gets into trouble, which is most likely the factor to be adjusted ? Budget ? Most probably not. You know how hard it is to get extra money, do you ? In contradiction you’d rather expect your budget to be cut while the project is running in times of a financial crisis or when permanent cost cuts strike your enterprise. Time line ? Not possible for many projects, but reasonable for some projects. Scope ? This is probably the factor you most likely try to adjust when you are in trouble with your project. Depending on what contract you have with your customer this might not be easy as well and requires a lot of arguing.

Now, what is the approach in Agile projects ? Do Agile projects have to worry about the Triple Constraints as well ? Of course they do. But how do Agile projects deal with that, especially when they get into trouble ?

First of all Agile Projects focus on a fixed time line – within an iteration. An iteration by definition is stable and time-boxed, which means: duration is defined and identical for every single iteration, and the iteration ends at the end of the time box. This is a solid rule in Agile.

But what about the entire project which consists of many iterations ? Do we know exactly from the beginning how many iterations we will do until we are finished ? Good question, no clear answer from my side yet. Due to the nature of Agile projects to actually encourage change I can easily imagine that the time line of an entire project is rather flexible.

What about the scope, also within an iteration ? I think this is the factor also in an Agile project which needs to be flexible while time line is not ( time-boxed ! )  – within an iteration ! If at the end of an iteration some items from the backlog have not been started they are moved to a different iteration – not necessarily the next one. If items have been started but not finished they might be re-defined and split into a finished part and an un-started part to more easily and clearly keep track on accomplished deliverables and to-be-done ones.

Nevertheless, this approach shows that the physics of the Triple Constraints also apply to Agile projects and also in an Agile project you have to have the freedom to adjust at least one of the factors when you get into trouble, when things go unexpected: scope it is in Agile projects. Within an iteration. How the Triple Constraints are applied to the entire project might require some different thinking. This to me is the major mystery in Agile projects.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: