It only takes a quick examination of each of the constraints to understand why they are important individually and collectively:

​

• Scope: is the bedrock of any project or programme. Its visibility and control are of paramount importance – disagreements over scope will, if not ironed out, lead to tension between stakeholders, a lack of clarity for the project team and ultimately to a compromise in one of the other ‘constraints’ in the model. For example, every change request which increases the scope of a programme needs to be funded – this either comes out of contingency funds (if you have provided for contingencies) or from ‘new’ money that the programme needs to complete effectively. 

​

• Time: project timescales are often the subject of great debate and scrutiny. There is a temptation to simply set a date by when a project must be done but that is anathema to good planning and often leads to a clash between the Sponsor and the Project Manager (if not the whole team). It is important that project dates are committed to on the basis of good planning and strong planning assumptions. On a project with a fixed completion/delivery date, it is a common occurrence that the full scope of the project cannot be achieved by that date – this can mean deferral of some of the scope items into a second phase, or spending more money to acquire additional/supplementary resource to achieve all of the scope in the fixed time frame, or even an acceptance that the quality of the expected outcomes will be compromised in order to achieve that date.

​

• Benefits: if the scope of a project decreases, it is likely that the benefits will be adversely impacted. If timescales elongate, there could be pressure to hit the date and a temptation to decrease the scope in order to do so, or to compromise the quality of the solution being delivered. A compromise in the breadth or depth of a solution or an accepted drop-off in quality is likely to exacerbate any adverse impact on benefits.On the other hand, when projects spot an opportunity to grab an additional benefit, it may be necessary to increase the project cost in order to realise that benefit within current project timeframes. If that benefit is significant enough, one must weigh up its value against any costs, risks and impacts on the schedule that achieving it may have before deciding to include it within the project scope.

​

• Price: the cost of the project is something that people often focus on more than any other dimension. It is sometimes seen as a cardinal sin to go over-budget. To combat this, a risk-based contingency figure should be included within the signed-off budget for any project – this ensures that you don’t need to go back to the well for more cash every time you make a change and that your Business Case is still a positive one if risks crystallise and the costs rise above the baseline level. Providing you maintain a strongly positive Net Present Value (NPV) or you are still on track to provide a highly valued service or utility, a few cost increases are annoying but pose no fundamental threat to the Business Case. However, the moment your Business Case looks like it may be compromised it is time to consider whether you need to change track.

​

• Quality: solutions can be delivered on time, budget and hit the financial benefits case but still disappoint the customer. The most common compromise made on projects relates to quality – substitute materials, squeezed testing timescales, particularly product or user acceptance testing (UAT), corners cut. Quality compromises may adversely affect the utility that the customer receives from the product or service delivered. What happens if a compromise in quality will mean you cannot sell the product you are developing? You either invest more time and money in ensuring a high-quality outcome, or you accept that sales volumes won’t be as anticipated – both of which demonstrate the Theory of 6 Constraints at work. Perhaps you can follow it up with an incremented product version.

​

• Risk: the reality is that the risks associated with a project are either extremely well-managed or very poorly managed – there is very little in between. Strong, predictive risk identification, analysis and mitigation is imperative for complex programmes and projects to succeed. This area is where you see the best Programme Managers proactively spending a lot of their time. Establishing which actions to take, should a particular risk crystallise, is one thing; understanding the cumulative risk impact of multiple crystallisations is harder and requires both intellectual input and socialisation to ensure that everyone is bought into taking action should the need arise. If there is potential for a risk to crystallise, the Theory of 6 Constraints offers a number of options:

  • you can take action immediately to offset the risk, perhaps by spending some money to bring in resource to perform a particular set of tasks 

  • if the risk may adversely affect the product, solution or the benefits profile, you may decide that the smart thing to do is to buy a little more time before you launch to ensure the right outcome for the customer 

  • perhaps the risk will lead to a compromise in quality – if so, it might be viable to release an initial solution and quickly follow it up with a quality enhancement shortly thereafter

 

The key is to act on a worsening risk profile early, to prevent risks becoming issues and issues becoming showstoppers.