« Project Quality Management
Project Management for Dummies »

Six Constraints: An Enhanced Model for Project Control - Benefits

April 13, 2008 | Author: PM Hut | Filed under: Project Management Best Practices, Risk Management

Six Constraints: An Enhanced Model for Project Control - Benefits (#5 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

This article discusses Benefits.

The last two elements of the six-constraint model are the newest and least-familiar ones, and could be considered controversial – except that they are both already present in projects. We are not creating them – we are just bringing them to the forefront and demonstrating how they interact with the “classic” constraints (time, cost, scope, and quality). When these two new constraints – benefits and risk – are not considered, they are likely to be neglected and produce a negative impact on the project and the organization. In this article we will focus on benefits.

Benefits

Benefits represent the value the project is expected to deliver to the organization. In PRINCE2™ terms, we don’t do a project just because someone “feels” like it, or (in vague terms) “thinks it’s a good idea.” PRINCE2™ requires the project to have a Business Case – a clear justification, with measurable, agreed benefits that are expected to result from the project’s outputs. If there is no clear justification, then the project should not be started, and if the justification disappears – or is reduced below an agreed-upon limit – the project should be stopped. (That “limit” will become our constraint.) As the project has deliverables that it produces, the benefits represent the value that those items are expected to have for the organization (in financial or other terms).
While a project’s objectives may be to deliver a new sales system, its value would be in its ability to increase sales, or improve customer service. Either one of these we would want to measure, to determine whether the new sales system was worth the time and cost to create it. Even governmental or nonprofit (charitable) projects need to have a Business Case – some measurable means to focus the project, and to use to assess the effectiveness of the project. (It is rarely possible to assess all benefits during a project. In a PRINCE2™ environment we would regularly anticipate and assess expected Benefits, and have a clear plan for an assessment of achieved benefits sometime after the delivery of the project’s outputs.)

The benefits are affected by factors both internal and external to the project. PRINCE2™ recognizes that even if we are on time, on budget (cost), and meeting scope and quality expectations, a change in circumstances may indicate that it is no longer worthwhile to continue the project (ie, the benefits have diminished or disappeared). Considering benefits means we focus on the key question: “Do we want to continue expending limited organizational resources on work that has no discernible value to the organization?”

Here are a few examples.

I am a company developing a new product for our market. We will need to grab 25% of the market for that particular product for our investment to pay off. At the beginning of the project it looks like we’ll get even more. Halfway through our one-year effort we hear the news: our major competitor has announced (and will start selling within 2 months) a product that is clearly superior to ours. We can still produce our item (and bring it to market), but it’s quite clear we won’t come close to breaking even. According to PRINCE2™’s approach, we have fallen below our “benefits tolerance” – and this constraint is under threat. With the triple constraint model we might have looked for the time or cost going outside acceptable limits – but here it’s only the benefits that are in danger. We can still deliver to the expected time, cost, scope and quality – but we need the awareness (and measurement) of benefits to assess the viability of the project. The standard triple constraints are clearly inadequate to help us diagnose this problem, or its magnitude.

In this particular situation, we could pour in more funds (cost) to enable the project to come in earlier (reduce time), and therefore have a better chance of being competitive and achieving some (or all) of our benefits. It is the consciousness of this benefits threat – as one of our constraints – that has us looking to the other constraints to adapt to a change in circumstances.

In this same situation, we might also choose to cancel the project: we would rather cut our losses now, since we won’t be able to get the return on our investment that initially justified the project. A benefits threat could also have been triggered by internal issues, such as senior management of the organization choosing to get out of the business that the project’s deliverables would represent. (The degree to which a project supports organizational strategy is another way to define a Business Case or benefits measurement.)

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 Sunday, April 13th, 2008 and is filed under Project Management Best Practices, Risk Management. 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.

Project Management Categories