The Triple Constraint of OSS

Central to the work of a project manager is balancing competing demands. The term “triple constraint” is a well-known phrase in project management that refers to the competing demands of scope, time, and cost. The manner in which these three demands are balanced affects quality. If one of these factors is affected, at least one other factor will also be affected.
For example, if the scope of the project increases, there will need to be an increase in the amount of time to complete the project, an increase in costs, or both. The new, fourth edition PMBOK® changes the name “time” to “schedule” and changes “cost” to “budget”, plus adds three new constraints

Many OSS projects fail to deliver on Time (Schedule), Cost (Budget) or Scope expectations. This is known as the triple constraint of project management.

PMBOK (Project Management Body of Knowledge) evolved this to show the project management star as a representation of six constraints facing a project manager, as follows:

However, I tend to believe that OSS projects that miss their time, budget or scope expectations have failed due to complexity. OSS projects tend to be highly complex projects anyway, but we somehow make them more complex than they need to be. Ruthless simplification should be our objective.

So I thought I’d add an extra factor – the complexity factor – to the PMBOK star. As the diagram below shows, if you can find a way to reduce complexity (the size of the inner white circles), then budget, schedule, risk and resources will also see reductions. Scope will probably shrink to accommodate simplicity also, but not at the expense of key functionality / requirements. The interesting part of the diagram below is that if complexity is reduced, the quality of your OSS should actually improve.

I’d love to hear your thoughts on this concept!

Read the Passionate About OSS Blog for more or Subscribe to the Passionate About OSS Blog by Email

2 thoughts on “The Triple Constraint of OSS

  1. Hi Ryan, That’s a very relevant proposal you’ve made! Yes you’d think that complexity could really be a management reporting attribute visible even at the Project Committee layer? It’s not an easy thing to quantify – perhaps it could be used as a formal classification approach to structure estimates for the other dimensions, e.g. across base, midrange & high complexity option points?

  2. Hi Evan,
    Yes, very difficult to quantify indeed!!
    It’s probably more a concept than a measurement tool – the more you can simplify, the smaller the circle gets and the smaller the constraints get (hopefully!)
    Perhaps it could be taken further to become an estimation / visualisation of constraints, with six axes emanating from the centre of the triangles and intersecting the 6 points of the triangles? The triangle could be skewed to indicate a conceptual value for each of the constraints (eg low, medium, high as you suggested or any other scales you wanted to show on each axis).

Leave a Reply

Your email address will not be published. Required fields are marked *