The relationship among scope, time, resources, quality, etc.

Thought-provoking post by mysticMundane on the Triple Constraint (here) — hat-tip to Michael at IT Project Failures (here).  IMO, both yielded good insights, with some caveats.  The good:

  • I always like to see quality included as essential to the triple constraint — Michael has the picture here — the scope isn’t delivered unless the work product conforms to requirements.
  • Scope change control is impossible without a baseline.  Good luck trying to get changes when the only baseline is a vague statement that the project is supposed to “boil the ocean.”
  • I like the second graph (here) with reservations…moving the scope frontier out nicely shows how hard it is for each time/resource combination to satisfy the new scope.

The caveats:

  • While I understand their intent, the graphs make it appear that scope is a function of time and resources.  Perhaps building each product feature can be represented by that, but is simply summing “features delivered” the scope? 
  • Do we fully understand scope deeply enough; in particular, isn’t the project ultimately supposed to create deliverables that generate benefits over time?  My experience is that too many project managers focus solely on features, which are derived from the business benefits, the deliverables, and their requirements. 
  • Shouldn’t an emphasis on benefits realization be the focus when time, resources, and scope are fixed?  We must understand the business case well enough to help derive — or at least validate — the requirements.  We acknowledge “quality,” but how do we ensure that the work is not only done properly (conformance to spec), but is the right work (conformance to requirements)?   
  • Project “managers” should be careful complaining about “management” if we want to be taken seriously as leaders.  Complaining about “management” was what I did as a McDonald’s crew person…

4 Responses

  1. Absolutely agree on the need to include quality during any discussion of the triple constraints. The first diagram in the post you mentioned has quality at the center, for exactly this reason.

    In fact, if we view the triple constraints as a way to analyze a project, then quality is all-important. Quality in this case defined as a successful project.

  2. Hi Michael,
    Thanks for the comment. It was your diagram I was referring to (I’ll edit to include a link).

    Frankly, I think the Triple Constraint is getting a little long in the tooth. Without accounting for quality (especially), projects are tempted to shave away at the definition of scope. The projects may deliver features that may formally resemble the intended results, but without substantive conformance to the intended requirements.


  3. I agree with your point that some projects look good on paper but still not meet the business objectives. Still, as the commenter in the following link pointed out, the triple constraints are useful to tell folks they can get two out of three:

    It’s crude, but represents some truth.

  4. Thanks for all the comments.

    From a quality perspective,the way i look at it, adhering to the graph ( at any given point in time (in the life of a project) is a necessary condition, but still not sufficient for a quality deliverable from the project

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: