Project management triangle

(Redirected from Project triangle)

The project management triangle (called also the triple constraint, iron triangle and project triangle) is a model of the constraints of project management. While its origins are unclear, it has been used since at least the 1950s.[1] It contends that:

  1. The quality of work is constrained by the project's budget, deadlines and scope (features).
  2. The project manager can trade between constraints.
  3. Changes in one constraint necessitate changes in others to compensate or quality will suffer.
The project management triangle

For example, a project can be completed faster by increasing budget or cutting scope. Similarly, increasing scope may require equivalent increases in budget and schedule. Cutting budget without adjusting schedule or scope will lead to lower quality.

"Good, fast, cheap. Choose two." as stated in the Common Law of Business Balance (often expressed as "You get what you pay for.") which is attributed to John Ruskin but without any evidence and similar statements are often used to encapsulate the triangle's constraints concisely.[2][3] Martin Barnes (1968) proposed a project cost model based on cost, time and resources (CTR) in his PhD thesis and in 1969, he designed a course entitled "Time and Cost in Contract Control" in which he drew a triangle with each apex representing cost, time and quality (CTQ).[4] Later, he expanded quality with performance, becoming CTP. It is understood that the area of the triangle represents the scope of a project which is fixed and known for a fixed cost and time. In fact the scope can be a function of cost, time and performance, requiring a trade off among the factors.

In practice, however, trading between constraints is not always possible. For example, throwing money (and people) at a fully staffed project can slow it down.[5] Moreover, in poorly run projects it is often impossible to improve budget, schedule or scope without adversely affecting quality.

Overview

edit

The time constraint refers to the amount of time available to complete a project. The cost constraint refers to the budgeted amount available for the project. The scope constraint refers to what must be done to produce the project's end result. These three constraints are often competing constraints: increased scope typically means increased time and increased cost, a tight time constraint could mean increased costs and reduced scope, and a tight budget could mean increased time and reduced scope.

The discipline of project management is about providing the tools and techniques that enable the project team (not just the project manager) to organize their work to meet these constraints.

Another approach to project management is to consider the three constraints as finance, time and human resources. If you need to finish a job in a shorter time, you can throw more people at the problem, which in turn will raise the cost of the project, unless by doing this task quicker we will reduce costs elsewhere in the project by an equal amount.

As a project management graphic aid, a triangle can show time, resources, and technical objective as the sides of a triangle, instead of the corners.[6] John Storck, a former instructor of the American Management Association's "Basic Project Management" course, used a pair of triangles called triangle outer and triangle inner to represent the concept that the intent of a project is to complete on or before the allowed time, on or under budget, and to meet or exceed the required scope. The distance between the inner and outer triangles illustrated the hedge or contingency for each of the three elements. Bias could be shown by the distance. His example of a project with a strong time bias was the Alaska pipeline which essentially had to be done on time no matter the cost. After years of development, oil flowed out the end of the pipe within four minutes of schedule. In this illustration, the time side of triangle inner was effectively on top of the triangle outer line. This was true of the technical objective line also. The cost line of triangle inner, however, was outside since the project ran significantly over budget.

James P. Lewis [7] suggests that project scope represents the area of the triangle, and can be chosen as a variable to achieve project success. He calls this relationship PCTS (Performance, Cost, Time, Scope), and suggests that a project can pick any three.

The real value of the project triangle is to show the complexity that is present in any project. The plane area of the triangle represents the near infinite variations of priorities that could exist between the three competing values. By acknowledging the limitless variety, possible within the triangle, using this graphic aid can facilitate better project decisions and planning and ensure alignment among team members and the project owners.

STR Model

edit

The STR model is a mathematical model which views the "triangle model" as a graphic abstraction of the relationship:

Scope = f(Time × Resources)

Scope refers to complexity (which can also mean quality or performance). Resources includes humans (workers), financial, and physical. Note that these values are not considered unbounded. For instance, if one baker can make a loaf of bread in an hour in an oven, that does not mean that ten bakers could make ten loaves in one hour in the same oven, due to the oven's limited capacity.

Project management triangle topics

edit

Time

edit

For analytical purposes, the time required to produce a deliverable is estimated using several techniques. One method is to identify tasks needed to produce the deliverables documented in a work breakdown structure or WBS. The work effort for each task is estimated and those estimates are rolled up into the final deliverable estimate.

The tasks are also prioritized, dependencies between tasks are identified, and this information is documented in a project schedule. The dependencies between the tasks can affect the length of the overall project (dependency constrained), as can the availability of resources (resource constrained). Time is different from all other resources and cost categories.

Using actual cost of previous, similar projects as the basis for estimating the cost of current project.

According to the Project Management Body of Knowledge (PMBOK) the Project Time Management processes include:

  1. Plan Schedule Management
  2. Define Activities
  3. Sequence Activities
  4. Estimate Activity Resources
  5. Estimate Activity Durations
  6. Develop Schedule
  7. Control Schedule

Define Activities

edit
  1. Inputs: Management Plan, Scope Baseline, Enterprise environmental factors, Organizational process assets
  2. Tools: Decomposition, Rolling Wave Planning, Expert Judgment
  3. Outputs: Activity list, Activity attributes, Milestone list

Activity sequencing

edit
  1. Inputs: Project Scope Statement, Activity List, Activity Attributes, Milestones List, Approved change requests
  2. Tools: Precedence Diagramming Method (PDM), Arrow Diagramming Method (ADM), Schedule Network templates, dependency degeneration, applying leads and lags
  3. Outputs: Project Schedule Network diagrams, Activity List Updates, Activity Attributes updates, Request Changes

Activity resource estimating

edit
  1. Inputs: Enterprise Environmental factoring, Organizational process assets, Activity list, Activity attributes, Resources Availability, Project Management Plan
  2. Tools: Expert Judgment Collections, Alternative Analysis, Publishing estimating data, Project management software implementation, Bottom up estimating
  3. Outputs: Activity resource requirements, Activity attributes, Resource breakdown structure, resource calendars, request change updates.

Activity duration estimating

edit
  1. Inputs: Enterprise environmental factors, organization process assets, Project scope statement, activity list, activity attributes, activity resource requirements, resource calendars, project management plan, risk register, activity cost estimates
  2. Tools: Expert judgment collection, analogous estimating, parametric estimating, Bottom up Estimation, Two-Point estimation, Three-point estimation, reserve analysis
  3. Outputs: Activity duration estimates, activity attribute updates and estimates

Schedule development

edit
  1. Inputs: Organizational process assets, Project scope Statement, Activity list, Activity attributes, project Schedule Network diagrams, Activity resource requirements, Resource calendars, Activity duration estimates, project management plan, risk register
  2. Tools: Schedule Network Analysis, Critical path method, schedule compression, what if scenario analysis, resources leveling, critical chain method, project management software, applying calendars, adjusting leads and lags, schedule model
  3. Outputs: Project schedule, Schedule model data, schedule baseline, resource requirements update, activity attributes, project calendar updates, request changes, project management plan updates, schedule management plan updates

Schedule control

edit
  1. Inputs: Schedule management plan, schedule baseline, performance reports, approved change requests
  2. Tools: Progressive elaboration reporting, schedule change control system, performance measurement, project management software, variance, analysis, schedule comparison bar charts
  3. Outputs: Schedule model data updates, schedule baseline. performance measurement, requested changes, recommended corrective actions, organizational process assets, activity list updates, activity attribute updates, project management plan updates

Due to the complex nature of the 'Time' process group the project management credential PMI Scheduling Professional (PMI-SP) was created.

Cost

edit

To develop an approximation of a project cost depends on several variables including: resources, work packages such as labor rates and mitigating or controlling influencing factors that create cost variances. Tools used in cost are, risk management, cost contingency, cost escalation, and indirect costs. But beyond this basic accounting approach to fixed and variable costs, the economic cost that must be considered includes worker skill and productivity which is calculated using various project cost estimate tools. This is important when companies hire temporary or contract employees or outsource work.

Cost Process Areas

edit
  • Cost Estimating is an approximation of the cost of all resources needed to complete activities.
  • Cost budgeting aggregating the estimated costs of resources, work packages and activities to establish a cost baseline.
  • Cost Control – factors that create cost fluctuation and variance can be influenced and controlled using various cost management tools.
Project Management Cost Estimating Tools[8]
edit
  • Analogous Estimating: Using the cost of similar project to determine the cost of the current project
  • Determining Resource Cost rates: The cost of goods and labor by unit gathered through estimates or estimation.
  • Bottom Up estimating: Using the lowest level of work package detail and summarizing the cost associated with it. Then rolling it up to a higher level aimed and calculating the entire cost of the project.
  • Parametric Estimating: Measuring the statistical relationship between historical data and other variable or flow.
  • Vendor bid analysis: taking the average of several bids given by vendors for the project.
  • Reserve Analysis: Aggregate the cost of each activity on the network path then add a contingency or reserve to the end result of the analysis by a factor determined by the project manager.
  • Cost of Quality Analysis: Estimating the cost at the highest quality for each activity.

Project management software can be used to calculate the cost variances for a project.

Scope

edit

Requirements specified to achieve the end result. The overall definition of what the project is supposed to accomplish, and a specific description of what the end result should be or accomplish. A major component of scope is the quality of the final product. The amount of time put into individual tasks determines the overall quality of the project. Some tasks may require a given amount of time to complete adequately, but given more time could be completed exceptionally. Over the course of a large project, quality can have a significant impact on time and cost (or vice versa).

Together, these three constraints have given rise to the phrase "On Time, On Spec, On Budget." In this case, the term "scope" is substituted with "spec(ification)."

Evolution of the Project Constraint Model

edit
 
The Project Management Star per PMBOK
 
Interpretation of Triangle Model
 
Interpretation of Star Model, note that the "risk" and "quality" are swapped

Traditionally the Project Constraint Model recognised three key constraints; "Cost", "Time" and "Scope". These constraints construct a triangle with geometric proportions illustrating the strong interdependent relationship between these factors. If there is a requirement to shift any one of these factors then at least one of the other factors must also be manipulated.[9]

With mainstream acceptance of the Triangle Model, "Cost" and "Time" appear to be represented consistently. "Scope" however is often used interchangeably given the context of the triangle's illustration or the perception of the respective project. Scope / Goal / Product / Deliverable / Quality / Performance / Output are all relatively similar and generic variation examples of this, while the above suggestion of 'People Resources' offers a more specialised interpretation.

This widespread use of variations implies a level of ambiguity carried by the nuance of the third constraint term and of course a level of value in the flexibility of the Triangle Model. This ambiguity allows blurred focus between a project's output and project's process, with the example terms above having potentially different impetus in the two contexts. Both "Cost" and "Time" / "Delivery" represent the top level project's inputs.

The ‘Project Diamond’ model [10] engenders this blurred focus through the inclusion of "Scope" and "Quality" separately as the ‘third’ constraint. While there is merit in the addition of "Quality" as a key constraining factor, acknowledging the increasing maturity of project management, this model still lacks clarity between output and process. The Diamond Model does not capture the analogy of the strong interrelation between points of the triangles however.

PMBOK 4.0 offered an evolved model based on the triple constraint with 6 factors to be monitored and managed.[11] This is illustrated as a 6 pointed Star that maintains the strength of the triangle analogy (two overlaid triangles), while at the same time represents the separation and relationship between project inputs/outputs factors on one triangle and the project processes factors on the other. The star variables are:

  1. Input-Output Triangle
    • Scope
    • Cost
    • Time
  2. Process Triangle
    • Risk
    • Quality
    • Resources

When considering the ambiguity of the third constraint and the suggestions of the "Project Diamond"; it is possible to consider instead the Goal or Product of the project as the third constraint, being made up of the sub factors "Scope" and "Quality". In terms of a project's output both "Scope" and "Quality" can be adjusted resulting in an overall manipulation of the Goal/Product. This interpretation includes the four key factors in the original triangle inputs/outputs form. This can even be incorporated into the PMBOK Star illustrating that "Quality" in particular may be monitored separately in terms of project outputs and process. Further to this suggestion, the use of term "Goal" may best represent change initiative outputs, while Product may best represent more tangible outputs.[12]

Evolution of Project Success Criteria

edit

The triple constraints represent a minimum number of project success criteria which are not adequate by themselves. Thus, a number of studies have been carried out to define and expand the various criteria of project success based on the theory of change which is the basic input-process-output chain.

Bannerman (2008) proposed the multilevel project success framework which comprises five L Levels of project success i.e. team, project management, deliverable, business and strategic.[13]

The UNDP in 2012 proposed the results framework which has six stages of project success i.e. input, process, output, outcome and impact.[14]

Zidane et al (2016) expanded the results framework into the PESTOL framework to plan and assess project success which can be used to evaluate "value for money" spent on each project in terms of efficiency and effectiveness.[15]

Hence, the triple constraints has been developed into various frameworks to plan and appraise project success as holistically as possible.

Limitations

edit

The Project Management Triangle is used to analyze projects.[16] It is often misused to define success as delivering the required scope, at a reasonable quality, within the established budget and schedule.[17][18][19][20] The Project Management Triangle is considered insufficient as a model of project success because it omits crucial dimensions of success including impact on stakeholders,[21] learning[22] and user satisfaction.[23] Subsequently, several enhancements of the basic triple constraints have been proposed such as the diamond model, the pyramid model, six or multiple constraints and theory of constraints. Accordingly, the project success criteria have been enhanced as well from three to multiple parameters.

See also

edit

References

edit
  1. ^ Atkinson, Roger (December 1999). "Project management: cost, time and quality, two best guesses and a phenomenon, its time to accept other success criteria". International Journal of Project Management. 17 (6): 337–342. doi:10.1016/S0263-7863(98)00069-6.
  2. ^ Wyngaard, Charles Van (2012). "Theory of the triple constraint — A conceptual review". 2012 IEEE International Conference on Industrial Engineering and Engineering Management. pp. 1991–1997. doi:10.1109/IEEM.2012.6838095. ISBN 978-1-4673-2945-3. S2CID 12434391.
  3. ^ "The project triangle".
  4. ^ https://pmworldlibrary.net/wp-content/uploads/2018/11/pmwl-barnes-how-it-all-began-pmwt-july-2006.pdf [bare URL PDF]
  5. ^ Brooks, Frederick (1995). The mythical man-month (Anniversary ed.). Boston, MA, USA: Addison-Wesley Longman Publishing Co., Inc. ISBN 0-201-83595-9.
  6. ^ Carl S. Chatfield, Timothy D. Johnson (2003). Microsoft Office Project 2003 Step by Step: Step by Step. P. 476
  7. ^ Lewis, James P. (2005). Project Planning, Scheduling & Control, 4E. McGraw Hill. ISBN 978-0-07-146037-8.
  8. ^ PMBOK Third Edition 2004 p.165
  9. ^ (Chatfield, Carl. "A short course in project management". Microsoft.)
  10. ^ (Brown, Craig. "It used to be the Iron Triangle". Better Project.)
  11. ^ Project Management Institute (2009) A Guide to the Project Management Body of Knowledge: PMBOK Guide. Chapter 1
  12. ^ Brem (2011) T214 Understanding Complex Systems – TMA02. Q4
  13. ^ Bannerman (2008) https://www.pmi.org/learning/library/defining-project-success-multilevel-framework-7096
  14. ^ UNDP (2012) Overview of the development results framework
  15. ^ Zidane (2016) https://www.researchgate.net/publication/308727415_PESTOL_-_Framework_for_Project_Evaluation_on_Strategic_Tactical_and_Operational_Levels
  16. ^ Erik Bethke (2003). Game Development and Production. p.65.
  17. ^ Michael W. Newell, Marina N. Grashina (2004). The Project Management Question and Answer Book. p.8
  18. ^ Pamela McGhee, Peter McAliney (2007). Painless Project Management. p.74.
  19. ^ Michael Gentile, Ronald D. Collette, Thomas D. August (2005). The CISO Handbook. p.172
  20. ^ Sha, Mandy (2014-08-01). "Applying a project management approach to survey research projects that use qualitative methods". Survey Practice. 7 (4): 1–8. doi:10.29115/SP-2014-0021.
  21. ^ Ralph, Paul; Kelly, Paul (2014). "The dimensions of software engineering success". Proceedings of the 36th International Conference on Software Engineering (PDF). Icse 2014. ACM. pp. 24–35. doi:10.1145/2568225.2568261. ISBN 978-1-4503-2756-5. S2CID 14897722.
  22. ^ Shenhar, A.; Dvir, Dov (1997). "Mapping the dimensions of project success". Project Management Journal. 28 (2): 5–13.
  23. ^ Delone, William H.; McLean, Ephraim R. (1 April 2003). "The DeLone and McLean Model of Information Systems Success: A Ten-Year Update". Journal of Management Information Systems. 19 (4): 9–30. doi:10.1080/07421222.2003.11045748. ISSN 0742-1222. S2CID 3138489.
edit