May 1, 2015 Leave a comment
In a previous post, the notion of the famous ‘Triple Constraint‘ was presented and the main attributes and general usage of the mechanism was itemized and discussed. (For reference, please feel free to access the post: Scope, Time and Cost – Managing the Triple Constraint)
As most project managers are aware, the Triple Constraint is essentially a way to represent that when an aspect of a project’s attributes is altered, it invariably has an effect on the other attributes.
As a quick overview, the Triple Constraint is currently broken down into three distinct attributes, which form the basis of the triangle that forms when all three are displayed pictorially. The three attributes are defined as follows:
Scope – These are the functional elements that, when completed, make up the end deliverable for the project
Time – This refers to the actual time required to produce a deliverable
Cost – This is the estimation of the amount of money that will be required to complete the project
As alluded to earlier, the Triple Constraint forms a triangle, which appears as such:
Any change to a particular attribute (for example ‘cost’) must in some way affect the other attributes. The main notion of the Triple Constraint is to demonstrate that changes to a project cannot occur in a vacuum and that any modifications will result in some alterations to expected timelines, relative scope or intrinsic cost for the project.
The Triple Constraint on its surface is very useful. However, there are some who feel that the representation is not granular enough and does not adequately explain how certain changes may also affect project outcomes. With that being said, there is an expanded view of the standard Triple Constraint which displays itself in a hexagonal format. And as such, is often referred to as the Project Hexagon, shown below:
On cursory view, the Project Hexagon still has as part of its sides, the three traditional attributes of the standard Triple Constraint. Those being ‘scope’, ‘time’ and ‘cost’. Additionally, the hexagon adds the following attributes to make up the broader Project Hexagon:
Quality – The specification, conformance or general ‘fitness of purpose’ (caliber or grade) of a particular project deliverable
Risk – The potential effect of uncertainty on project objectives
Customer Satisfaction – The measure of how the product (or service) relevant to the project meets or exceeds customer expectations
Now as with the standard Triple Constraint, the Project Hexagon is also victim to the same fundamental aspect of its shape: a change to any of its attributes must invariably affect the others as well.
The usage of the Project Hexagon depends primarily on how the project manager wishes to convey the impact of potential changes to project attributes. A slippage of quality for example may not be as easy to discern on cursory view of the standard Triple Constraint. So the added granularity may be of benefit when conveying status to stakeholders or the project sponsor. Much of that decision will depend on the general preference of the manager themselves.
One thing to note: if one is deciding to leverage the Project Hexagon as a frame of reference, that should be done from the outset of the project. Utilizing the Triple Constraint and then switching to the Project Hexagon mid-way through the project can lead to confusion amongst team members and stakeholders alike. So if you are planning on leveraging the concept, it should be stipulated up front and tracked accordingly.
The decision to use the Project Hexagon may depend on conditions inherent to the project or simply the general preference of the project manager. The added granularity of the Project Hexagon can provide more useful information and more easily convey general project fundamentals in a more obvious fashion. It can be a useful tool when applied correctly and in circumstances where projects require more general metrics and more information in status, it can be very effective.