Sunday, July 17, 2016

Iron Square of Constraints

If you have spent any time involved in projects and dealing with project managers, I'm sure you have heard of something called the "project management triangle".  If you haven't, here is a quick look.

This diagram is used to outline the constraints a project faces, and how they are related to each other.  It is common wisdom that you can't "control" all 3 of these constraints.  That is to say, if you want to fix the cost and the schedule, then you have to be flexible on the scope of the project.

There are many tools that can be used to measure/understand/control the various constraints above.


Cost is always an interesting one.  Generally, cost is measured as a function of money that is put in to creating the product.  For example, one would consider the resources being used on a project, the labour rates of those resources, and any additional costs (desks, licensing, etc).  Risks to the cost of a project are generally detailed as part of the risk register and reported up to the project stakeholders.

One thing that is often overlooked is the cost of NOT doing something.  For example, ROI on a particular workload may only be realized if the product is first to market.  Thus, a schedule that slips may have a significant cost implication above and beyond the cost of the resources on the project. 


Scope is generally defined as the requirements specified to achieve the end result.  If you are doing a good job of this, you are capturing both the functional AND non-functional requirements. 


This constraint is generally expressed as a "go-live" date or "target" date.  While it is understood that this should not be a completely arbitrary date, most end up being this way anyways.  In theory, this date should take into account cost/scope considerations. 


It is important to note that the concept of quality is muddled in the diagram above. Looking at it, you see that quality seems to be this thing that is made up of the combination of cost/scope/schedule.  It isn't quite understood that quality can be a target on it's own.

In the book, Management 3.0, the author describes his view on the "Iron Square of Constraints".

Talking about the constraints above as a gradient is truly a powerful tool.  Let me give an example.  It can be extremely difficult to build a application that is highly scalable.  It takes a lot of work to do this, and can add significant time to the project to build out completely.  For a proof of concept, or a limited release, project stakeholders may decide to forgo some of the quality aspects in favour for more functionality, or, less time/resources.

It also is a better visual to show trade-offs.  Given constrained resources and time, I have a choice to deliver many features with low quality, or fewer features with high quality.

This holds true for a mythical customer that wants to hold quality and time as constraints.

They would have the option of changing the resources assigned to the project, or fiddling with the amount of functionality that is delivered.

Later on in the book, the author discusses the "Escher cube of constraints".  It looks something like this.

While I think it is ultimately a more complete version of the constraints in play, this might be a little much to discuss with a customer during initial project discussions.