« Supporting Frameworks for Successful Program Management - Ethics Training and Compliance
Resourcing Project Managers »

Six Constraints: An Enhanced Model for Project Control - How to Use the Six Constraints Model

April 22, 2008 | Author: PM Hut | Filed under: PRINCE2, Project Management Best Practices

Six Constraints: An Enhanced Model for Project Control - How to Use the Six Constraints Model (#7 in the series Six Constraints: An Enhanced Model for Project Control)
By Jay Siegelaub - MBA, PMP, PRINCE2

PRINCE2™ employs “tolerances” – its term for these six constraints – as key project controls. They are dimensions of the project for which ranges of acceptability are defined, which are monitored to identify or anticipate when a plan has entered “problematic” or “exception” territory. They are needed and used at all three planning levels of a project – the project as a whole, any one stage or phase of the project, and at the detail work package level.

The Six Constraints are:

  • Time
  • Cost
  • Scope
  • Quality
  • Benefits
  • Risk

We use the constraints model to help us control the project. Building on the examples we have provided above, the project manager with the sponsor/ stakeholders/ Project Board (Project Boards are how PRINCE2™ clarifies the sponsor role and responsibilities) establish what the project’s (and phase/ stage) limits are in these six key areas. (Benefits and risk are usually defined down to the project and phase (stage) levels only; the other four are also scaled to the work package level, if required.) Together the six provide a complete set of guidelines for the project manager to know (a) what the sponsor/ stakeholders/ Project Board see to be important (since they have a vested interest in the project’s success, and are providing the funding), and (b) what are their limits of acceptability in performance.

Constraints/ tolerances are set by the sponsor/ key stakeholders/ Project Board, so there are common, agreed expectations for a project. These constraints/ tolerances indicate for a project, as follows.

Scope: This is what the project is expected to deliver (if the scope tolerance is zero, the project must deliver no more and no less than what is specified).

Quality: The scope items are to be delivered with the defined characteristics (no deviation allowed if quality tolerance is zero), and all deliverables must be reliable – ie, the characteristics have been quality tested/ checked to the extent specified, so that they function as agreed. .

Time/ Cost: The project manager is expected to deliver the final products/ deliverables within the agreed ranges. If the project is running late and/or costing more than the specified range, the sponsor/ stakeholders/ Project Board need to be informed, so they can decide how to proceed. If the project will end below the time or cost range, they also want to know, as other projects may be able to start earlier, or be able to use the unneeded funds.

Benefits: The sponsor/ stakeholders/ Project Board expect a minimal level of benefits to accrue from this project, or it may not be worthwhile to continue investing the agreed time and cost. (Even though we could deliver the agreed scope on time and within budget, to the expected level of quality, that does not mean the project is worth continuing. Delivered scope is not the same as benefits.) Similarly, if we see potential benefits running higher than our planned upper benefits tolerance range, the sponsor/ stakeholders/ Project Board may be willing to invest more time and money, or expand the scope, in order to assure (or take advantage of) those higher benefits.

Risk: We have agreement on the level of risk the sponsor/ stakeholders/ Project Board are willing to live with in the course of the project (their risk tolerance). If the project manager cannot control (mitigate/ transfer, etc.) major risks, then the sponsor/ stakeholders/ Project Board need to decide if they are willing to live with the greater risk exposure, or want the project to close down (“It’s just too risky for us to move forward if we cannot mitigate, or don’t have a contingency plan for risk ABC.”).

Balancing Constraints

Exceeding one or more of the constraint/ tolerance limits is not a question of having done something “right” or “wrong”. It is an indicator that draws the attention of the project manager, to determine what has caused (or will cause) the deviation, and after analyzing possible consequences, devise a resolution coordinated with the sponsor/ stakeholders/ Project Board.

Well-thought-out constraints allow the sponsor/ stakeholders/ Project Board to “manage by exception” – ie, they allow the project manager to continue running the project, as long as none of those constraints is anticipated to be exceeded. If any of the six constraints has the potential to be exceeded, the project manager should approach the sponsor/ stakeholders/ Project Board to establish the cause and a course of corrective action (including possible cancellation of the project).

We have provided several examples of how an exceeding of one of the constraints can be balanced through examination/ extension of another constraint. In one case, a benefits threat (from a competitor’s product coming out before ours) could be addresses by spending more money (cost) to get our product out earlier (time), or by taking greater risks, or by reducing or increasing the project’s scope.

Here are a few other situations that the six constraint model would help to analyze and address.

  1. Quality testing is on a tight schedule, generating greater risk that errors will not be detected and corrected. (This is a common situation – and presenting it in terms of “risk to the project” is more likely to get the attention of the sponsor/ stakeholders/ Project Board than just complaining.) There are additional implications, in that defective deliverables may threaten benefits as well. This could be addressed through additional time and/or funds to test properly.

  2. Asking for additional scope or modification of characteristics (change requests) is addressed through additional funding and/or adding time to the project schedule. One would, or course, expect benefits to increase as well, and be worth the additional time/ cost.

  3. A project is depending on the availability and functionality of an untested technology – a high risk situation. Allocating additional funds (cost) or time to confirm the reliability of the final deliverables may be a way of mitigating that risk. Alternatively, the company could reduce the risk by using a known technology, but that may cause the scope of the project to be reduced, or may reduce the expected benefits.

Notice the complex interactions between the constraints. Making changes – adding scope or quality – will (hopefully) increase benefits, but may also increase risk (that the changes may impact negatively on existing scope/ characteristics). Taking greater risks may increase benefits, but also have the potential to damage benefits if the risks don’t work out. Taking more time may reduce risks (through better quality testing), or increase risk (if our product gets to market too late to compete effectively against other companies’ products, which would also reduce benefits). The six constraints constantly influence and affect each other throughout the project.

Jay Siegelaub has over 30 years of professional experience delivering and supporting projects in information technology, insurance systems, banking, and nonprofit strategic planning, as well as in the pharmaceutical, financial service, consulting, and consumer products industries. As a recognized educator he has trained thousands of project managers over the past 23 years, including 13 years as the Project Management tutorial instructor for the Drug Information Association.

Jay’s recent responsibilities included leading the North American Change Management and Training practices for a UK-based management consulting firm, training corporate consulting professionals in project and program management, and supporting clients in managing the “people” issues of their business change initiatives. He has authored articles on training, project management and information technology for various publications, and often presents at conferences, including the PMI North American Congress (1999, and 2004 – 2007), ProjectWorld and ProjectSummit.

In addition to his PMP® certification, Jay has his MBA in Organization Management from New York University’s Stern School of Business, and is an accredited PRINCE2™ Practitioner, Instructor and Examiner. He has taught and consulted in PRINCE2™ in North America for 10 years (the first US-accredited PRINCE2™ instructor), and worked for the company (and with the authors) that wrote the PRINCE2™ Manual for the UK government.

He has provided Change Management and Project Management consulting and training (including PRINCE2) to companies such as Sun Microsystems, NATO, the United Nations Development Programme, Bechtel, IBM, Philip Morris, Credit Suisse, JPMorganChase and Diageo.

Jay also consults in Organizational and Professional Development.

Share this article:
  • Digg
  • del.icio.us
  • Facebook
  • Google
  • blogmarks
  • LinkedIn
  • Reddit
  • StumbleUpon
  • TwitThis
  • Yahoo! Buzz

Related Articles

This entry was posted on Tuesday, April 22nd, 2008 and is filed under PRINCE2, Project Management Best Practices. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

No comments yet.

feel free to leave a comment

Comment Guidelines: Basic XHTML is allowed (a href, strong, em, code). All line breaks and paragraphs are automatically generated. Off-topic or inappropriate comments will be edited or deleted. Email addresses will never be published. Keep it PG-13 people!

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

All fields marked with " * " are required.

The Stevens Enterprise Project Management Master's Program

Project Management Categories