MGRC20003 Principles of Project Management

Learning Module 2
Mini Lecture 01:
Descriptive & prescriptive models

We look at models of a project, focused around the triple constraint or iron triangle, which can be used both descriptively, and prescreptively, and as a first step in diagnostics.

BIBLIOGRAPHY
For your further reading on more detail and background.
See also Blackboard for prioritised and categorised readings, and see specific citations in this lecture.

• APM Body of Knowledge 7th edition. 7th edn (2015). Association for Project Management. Available at: https://www.apm.org.uk/book-shop/apm-body-of-knowledge-7th-edition/ (Accessed: 19 August 2019).
• Atkinson, R. (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, pp. 337–342.
• Daniel, P.A. and Daniel, C. (2018) ‘Complexity, uncertainty and mental models: From a paradigm of regulation to a paradigm of emergence in project management’, International Journal of Project Management,
36(1), pp. 184–197. doi:10.1016/j.ijproman.2017.07.004.
• Garel, G. (2013) ‘A history of project management models: From pre-models to the standard models’, International Journal of Project Management, 31, pp. 663–669. doi:10.1016/j.ijproman.2012.12.011.
• Maylor, H. (2010) Project Management. 4th edn. Financial Times/Prentice Hall.
• Murray, P., 2003. The Saga of Sydney Opera House: The Dramatic Story of the Design and Construction of the Icon of Modern Australia. Routledge, London. https://doi.org/10.4324/9780203358160
• Pollack, J., Helm, J. and Adler, D. (2018) ‘What is the Iron Triangle, and how has it changed?’, International Journal of Managing Projects in Business, 11(2), pp. 527–547. doi:10.1108/IJMPB-09-2017-0107.
• Shenhar, A.J. et al. (2001) ‘Project Success: A Multidimensional Strategic Concept’, Long Range Planning, 34, pp. 699–725. doi:10.1016/s0024-6301(01)00097-8.
• Straw, G., 2015. Understanding project management: skills and insights for successful project delivery, 1st edition. ed. Kogan Page.
• Svejvig, P., 2021. A Meta-theoretical framework for theory building in project management. International Journal of Project Management 39, 849–872. https://doi.org/10.1016/j.ijproman.2021.09.006
 Learning Objectives (LM2)
1. outline factors that constrain and
enable projects
2. outline different types of project based
on their characteristics and objectives
3. explain the various forms of project
life cycle

We build on the basic definition of a project to explore the variety of characteristics projects can have. Our assumptions about a given project will inform our approach to managing it through its life cycle (i.e.,
methodology, which we explore in a future ML).

This ML focuses on ILO1.

 Models & Analytical Frameworks help make
sense of complexity

We can use a ‘model’ of a process or system to help us make sense of complexity; so we can develop and use models of projects.

See: Maylor Chapter 2, in particular Table 2.1, Figures 2.1 and 2.2, and surrounding text.

We use frameworks all the time without knowing it. Get used to adopting project management frameworks! We’ll look at analytical frameworks to use in project management in a future ML. Here we focus on models of
projects themselves.

A conceptual or analytical framework is a tool with which to deconstruct, analyse, investigate, and write about a process or system (or anything). It enables a mental model of something to be created and used.

A framework can be used as a tool to figure out what’s going on. E.g., a doctor uses their theory of the human body and its functioning as a framework to understand what’s going on with a patient; they may use certain
models as analytical ‘lenses’, depending on the symptoms: e.g., focusing in on the heart if it seems to be a heart problem. This is a descriptive and diagnostic use: describe what is happening, compare this to what ‘should’
be happening, and use this to focus in on what may be causing the problems. In other words, a medical model can describe ‘proper functioning’, e.g., what a healthy heart should ‘look’ like. In that sernse it is not just
desriptive, but ‘prescriptive’.

As an example, your knowledge of cooking and recipe ingredients is a conceptual or theoretical framework you use: it enables you to deconstruct and study a new recipe and to solve problems while cooking or developing
your own recipes. Effectively, it gives you a ‘language’ with which to interpret or explain a recipe or problems you encounter during cooking. It enables clarity and focus, as you draw on existing theories of food and its
preparation — rather than making it up as you go along! Your recipe, in a sense, describes the ‘model’ of both the process you will use to put the meal together, as well as the ‘ideal’ model of the end result.

As we’ll see later, it’s best to think of models as a subset or type of conceptual framework.
 Analytical frameworks

• A ‘lens’, ‘filter’
• Descriptive
• Diagnostic/explanatory
• Prescriptive
• Prospective, retrospective
• Predictive
• Model or framework?
• To enable decisions 4

Summarising what frameworks (and models as a type of framework) do for us:

• Make things easier to understand by breaking them down
• Focus on relevant issues/facts
• In PM, we use them to focus on project ‘stuff’
• And we can use them as tools to decide what needs to be done

• A ‘lens’, ‘filter’ : focus on what’s important, relevant, e.g., only the project ‘stuff’
• Descriptive: describe what is going on, the facts, the situation, relationships, inputs and outputs
• Diagnostic: explain why or how something is happening, uncover causes to explain effects
• Prescriptive: say what should happen (or what should have happened in the past): how should this work/be (compared to the way it actually is or was)?
• Prospective, retrospective: we can use them to make decisions about what could happen next, e.g., at the start of a project; or looking back, to analyse what has happened and explain why, or decide what needs to
change
• A model that predicts or forecasts what is likely to happen can be useful, e.g., in exploring what-if scenarios and trade-offs. That’s where forecasting models come into play. This is more the territory of models —
approximations of the ‘world’ — rather than frameworks, which are more concerned with helping us make sense of the world in a structured way.
• Model or framework? They are used interchangeably sometimes. Does it matter? We need to be clear about whether we are using them to describe or diagnose. We’ll see this problem with the iron triangle. Think of a
conceptual framework as describing a situation so that we can analyse it, but a model as both descriptive and prescriptive — ‘model’ implies we think ‘this is how the system should be’ (although models are not the ‘real
thing’!). Don’t worry too much about the terminology, as long as you’re clear how you use the tool!
• To enable decisions: ultimately, this is the purpose of using a theoretical, analytical, or conceptual framework: not just to ‘paint a picture’, but then ‘do something’ with this knowledge, e.g., to explain a problem,
propose a solution, develop a theory, decide what to do next

There are several frameworks you can use in studying projects. Use them critically (know when/why to use them), as part of your toolkit to understand and manage projects. Make them part of your project management
‘language’, as the theoretical foundations you draw on.

Although ‘models’ and ‘frameworks’ are often used interchangeably, a model suggests ‘the way something is or should be’, or the way it is supposed to work. An analytical framework more generally is simply a method for
understanding a situation, however it’s working. Of course a model is also a framework, as in the iron triangle: we can explore projects with it (e.g., what did it cost, what was its scope, how long did it take, and compare
these to plan) — this is a descriptive use, describing the situation to deconstruct it, and we can also evaluate it against the model (good or bad?) — these leads towards a prescriptive use, as in ‘the project was supposed to
stay within its constraints, but it did not, therefore it failed’.

Deconstructing or making sense of a situation using a conceptual/theoretical framework can enable us to make decisions. We can analyse not only what is/has been going on, but way; and this is a basis for diagnosing
what should be done to resolve a situation or problem. In order to prescribe a remedy, we first need to describe the situation.

For a definition and discussion of ‘models’, see Williams, 2002, p22+.

Williams, T., 2002. Modelling complex projects, Basic topics in psychology series. Wiley, Chichester;

See also (Svejvig, 2021)

 Iron Triangle as a model of a project

• Descriptive: what are the

constraints?
• Prescriptive: meeting
constraints = success
Time
Sydney
Opera House
Plan Actual

Time
Scope
(years) 4 14
Cost (AUS
$, M) 7 102
Cost Quality
5

The iron triangle is the dominant model of what a project is, in terms of the constraints it has: time, cost/budget, and quality — but also its ‘scope’ is a constraint too. So perhaps there are four dimensions! (Note that
other models, such as the PRINCE2 hexagon, recognise more than three dimensions.)

Used descriptively, we can just state what the constraints are. This is usually done right at the start, as by definition a project has finite resources, time, and a specific goal defined for it. But if these constraints change
during the project, we can describe those factors there as well.

Used prescriptively, it would imply that these constraints must also be met in order for the project to be successful, i.e., to be successful, we ‘prescribe’ that the project must ‘live’ within its time, cost, and quality goals, as
well as achieving scope.

So for example, in the classic Sydney Opera House project, its initial goals of time and cost were assumed to be the constraints of budget and schedule that it would ‘live’ within it, and thus when it did not meet these
goals/constraints, it was seen as a failure. But as we will see, it may not be appropriate to define project sucess this way, if these constraints are not ‘accurate’, or if they do not account for other important sucecss factors.

But is this model enough to be useful?

For SOH, see page 2 of Shenhar, A.J., Dvir, D., 2007. Project Management Research—The Challenge and Opportunity. Project Management Journal 38, 93–99. https://doi.org/10.1177/875697280703800210
 What’s missing from the iron triangle model?
Time
• Where do constraints ‘come from?
Scope
• Are these really all the constraints?
• Does this model fully measure Cost Quality
success?
“Two best
guesses and a
phenomenon”!
(Atkinson, 1999)

Atkinson, Roger. ‘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 (1999): 337–42.
6

We should look critically at the iron triangle/triple constraint model. It derives directly from our traditional definition, that a project is ‘bounded’ by finite time and resources, and with a specific goal. But how are these
determined? Are they just, as Atkinson suggests (in an IT context) a ‘guess’ of the future? And with quality being something that can be hard to define, and can mean different things to different people.

Are these constraints reasonable, especially at the start of a project? Who sets them? Are they established by experts who have forecast the future of the project, or are they just ‘wishes’ from management?

What other constraints are there on a project? Costs derives from people and resources, but may be subject to variation if we don’t accurately estimate them. Quality can be defined in various ways, both subjectively and
objectively (we’ll see this in a future LM). And time both influences cost, and is also affected by a range of complex factors. The level of risk in a project, which derives from its complexity and dynamism, can make these
constraints ‘fuzzy’ (uncertain). The level of risk ‘tolerance’ does not appear as a constraint here. Nor do ‘stakeholders’ which are an influence on, and are affected by, all of the constraints. So perhaps we are not factoring
in all the possible constraints on a project (we’ll look at this some more).

And if meeting the initial constraints defines success, and those initial constaints are ‘wrong’, or incomplete, then this is problematic.

See Wysocki (2019), figure 1.2 on page 19 for a variant on the scope triangle, where he brings risk and resources into the equation. He argues that resources need to be separately identified, not just incorporated into
costs.

Wysocki, R.K., 2019. Effective Project Management: Traditional, Agile, Extreme, 8th ed. ed. John Wiley & Sons, Incorporated, Newark.
 What about uncertainty, and emergence?

Gr nc re
ch ail

ea e o
a u
f

te f
r
NO
Methods/
Time
Solution
well
defined
Scope
YES

Gr nce o
ch cces
su

ea
a
Cost Quality

ter f
YES NO

s
Goals well defined
Based on Turner and Cochrane, 1993
7

While the traditional definition of a project implies that the constraints are ‘fixed’, or well known in advance, because we define projects as emergent, we must recognise uncertainty. The methods/goals matrix reminds
us that we do not always have complete knowledge of the project’s ‘features’, and thus of its constraints. Different types of projects may have different levels of uncertainty in the assumed or predicted constraints. And
this would influence how we define success.

Note that our iron triangle model does not tell us anything directly about methods, let alone how much certainty we have about them. For a specific project, any uncertainty in methods or goals ought to be reflected in
some variance or tolerance or ‘margin for error’ in the triple constraints, shouldn’t it? Cost and time would both be a function of the methods used, as well as the scope and quality goals. And the ‘values’ of the constraints
are likely to be different when first estimate or forecast at the start of the project, compared to later on in the life cycle after more detailed design and planning work has been done (hence Atkinson’s two best ‘guesses’).
But this will depend on the project’s specifics and context.
 Multiple dimensions of success

1: Project efficiency
2: Impact on the customer
3: Business success
4: Preparing for the future

Shenhar, A. J., Dvir, D., Levy, O., & Maltz, A. C. (2001). Project Success: A Multidimensional Strategic Concept. Long Range
Planning, 34(6), 699-725
8

We’ll look at the Shenhar et al model again in the future, but this takes into account more than the time and cost constraints to asess project success, depending on the level of project complexity. For simple projects, that
are well defined and ‘easy’ to predict/forecast, short term measures like time, cost, and quality may be suitable measures. But for higher risk projects, longer term measures may be more appropriate.

And longer term and sustainability goals may be needed for all kinds of projects. For example, if long term impact on the environment is important for a construction project, should that not be included as both a
constraint and a success factor? If it’s not integrated with scope or quality, and influences time and cost, then it might need to be defined as its own ‘dimension’.

But note that some types of project may have hard or ‘fixed’ constraints that really must be met, whether they are realistic estimate or not: e.g., the opening date of an Olympic Games is likely to be ‘non negotiable’; and
sometimes a budget really may be ‘all there is’; and for safety-critical systems, quality/specification must meet rigid regulations/laws. It may be necessary to ‘trade off’ other constraints to achieve these.
 ICOM: a process model of a project

•Time •Quality
•Legal
•Budget •Stakeholders
•Ethical…
•Scope •Risk
Constraints
A want Need
or need satisfied

Project
Inputs Outputs

Mechanisms
•People
•Governance
•Knowledge
•Material
•Funding
•Technology …
•Methods
9

See Maylor Figure 2.2, pg 29-30

Another model to help us describe a project is the ICOM model. This enables us to depict the input — the stimulus to a project, in terms of the need we want to satisfy, the overall ‘benefit’ to be realised, its output — what
is actually produced to satisfy the need, the constraints ‘acting’ on the project — those things that limit how it can be done and what it can accomplish, plus the mechanisms or ‘enablements’ which we use to overcome or
counter balance the constraints.

We can use this at the start of a project to try and make sense of all the factors influencing our project. Or we could use it in hindsight to help us diagnose a project problem.

For example, a budget constraint is ‘acted on’ by our funding mechanisms — which indicate where money comes from, how it flows into the project. And we can use methods such as stakeholder management to deal with
constraints imposed by stakeholders, for instance if they have very stringent needs or desires. And our governance process is the decision making ‘method’ that we would use to plan and prioritise and control in order to
keep the project to schedule. The mechanisms are the tools and processes of project management that we use to turn the initial strategic goal into realised benefits.

Note that we could integrate into time, cost, and quality the other constraints, e.g., if there are regulatory, legal, or ethical limitations on how we can conduct our project or what it can achieve, these could be incorporated
into costs (e.g., fees, or taking longer time to get legal approval). But it can be useful to separate these constraints out to give us more analytical ‘power’. We’ll see how ‘itemizing’ or breaking down cost, time, quality, and
scope into the detailed underlying influences or components can be very important in planning our projects (see breakdown structures in LM3).
 Example: cooking a meal

Need
A want
satisfied
or need

Constraints

Inputs Project Outputs

Mechanisms

Our worked example looks at how we can describe a project to create a satisfying meal to satisfy our hunger. Our options and outputs will be constrained by factors such as how much we have to spend, or what
ingredients we have access to. And our approach and how well we realise the benefit will depend on mechanisms like our tools, kitchen facilities, recipes, skills, and experience.

If the constraints and mechanisms are ‘opposing forces’ acting on the project and determining the output, we could also think of them as interchangeable, e.g., our inexperience in cooking would be a constraint on how
good a meal we produce; and having access to a large budget to buy luxury ingredients (cost ‘constraint’) could also be seen as an enabling mechanism!

It’s also important to note the difference between producing an output and delivering the benefit: if they meal we produce does not satisfy the initial need, or is of poor quality (e.g., inedible) can we consider our project a
success, even if it met time and cost goals, and scope? Did we deliver the benefit? That reminds us that defining scope (the boundaries of the project to be achieved) not only need to be measurable, but aimed at satisfying
the original need. It’s not good just delivering any old plate of food!
 Using the Iron Triangle model
Time
• Depict initial constraints
• … to assess trade-offs, priorities Scope

• … to plan
Cost Quality
• Judge success
• Pinpoint problems for analysis

11

So how can we use the iron triangle, or triple constraint model for project management?
We can use it to describe the constraints on our project, based on an initial view at the early stages of planning. What is the scope of the project (its boundaries, what’s included, what’s not), and what are our budgetary
and time constraints for delivering that scope? And how ‘good’ should the project be (quality)?

Are these ‘hard’ constraints, or goals/wishes? If we cannot deliver the project and meet all the constraints, trade-offs may be needed: the dimensions of the triangle influence each other. E.g., in general, the larger or
more complex the project (scope), the longer it will take and the more it will cost; higher levels of quality (performance, etc.) are likely to be more costly and take longer. We may need to relax one or more of the
constraints to be able to deliver the project within the desired time, budget, or quality goals (not the difference, again, between ‘goals’ and actual constraints). The trade-offs we can make will depend on priorities for each
of the variables in the triangle: e.g., if we must deliver a project by a specific date, then that would be a ‘hard’ constraint, and the others will need to be subordinate to that — all we can do then is optimise these, i.e., find
the lowest cost and highest level of quality that will enable us to meet the deadline. This are discussions for our planning phase, where we analyse our options, and iteratively determine what these constraints are — we
move away from initial goals or assumptions to more accurate estimates and forecasts. E.g., while the CEO may say that the project must be delivered by the end of the year at a cost of no more than £1M, that does not
mean it is realistic, or desirable, to do so! But if the budget is really fixed at £1M, we will have to find a way to do that by varying the other constraints. We’ll see more of this when we look at planning.

The triple constraints can be used to assess how well the project is progressing throughout its life cycle, and at the end — if the initial constraints were realistic and reasonable (but note that there may be other measures
of success that are appropriate to different types of project. E.g., if it was essential that the project be delivered on time (e.g., for the opening of the Olympic Games) we can judge how successful the project is based on
whether it met that goal. If it did not, we could use this as a basis for further inquiry into why it did not. But these requires more detailed assessment — the model itself does not diagnose problems for us, it just paints a
picture. Similarly, just because other constraints were met, does not necessarily mean the project wasn’t problematic — e.g., perhaps we could have delivered it at even lower cost, or higher quality than we did; and what
about other factors not in the triangle, like sustainability or impact on stakeholders or legal risk? We’ll look at these in more detail in future LMs.

Also see APM BoK, figure 2.1.1

 Project models in summary

• Use with care

• Assess multiple forces, Time
factors, & features
• Describing vs diagnosing vs Scope

prescribing vs predicting
Cost Quality
• Next: types of project

12

So models of a project help us make sense of it. This can be useful in planning at the early stages, to identify things we need to know, and things we don’t; what forces are ‘acting’ on the project? What are its features?
What are we constrained by, and are these ‘fixed’, or likely to change?

Remember that a model is just our approximation of a system or process; it is an analogue or analogy or metaphor, an illustration of what we assume the situation to be, or how the system should work. In the hard
sciences, models are constructs that depict a theory, but are subject to testing and revision over time — for example, our model of the atom, or how the universe emerged, or cell biology. In the social sciences, there are
many models that help us understand the interaction and emergence of processes and people — but we may need to challenge our assumptions, and recognise that how well a model ‘fits’ the situation depends on only on
the ‘inputs’ we have assumed, but on our biases, and the limitations in our knowledge — e.g., what have we not included? How accurately can we predict the future from our model? Remember that even our models of
how the weather work are not 100% accurate in all situations, especially over longer time scales. The same applies to process models of projects, or any other system of organising.

Note that just because we describe initial constraints doesn’t mean that’s how we should define success: we need to take account of the type of project we are dealing with: if it’s very complex or high risk, or subject to lots
of change from external factors beyond our control, it is unreasonable to set success criteria that are fixed and focused on the short term .

And note that just describing the features of a project does not help us explain it: just because a project fails to comply with its constraints does not tell us why or how this happened: we need additional analytical tools to
go beyond that initial description. The purpose of a model is to help us make sense of a project and its environment, to make it easier to analyse and explain and manage (hopefully!), but the model doesn’t do that ‘on its
own’ — it has to be used carefully and critically.

Do remember not to conflate project scope and project quality — although some variations of the triangle put scope as one of the vertices, it is important to distinguish scope and ‘technical’ quality. See Straw, 2015, p168.

An important model for projects describes how project emerge over their life cycle; and different kinds of projects may have different life cycle ‘profiles’, which are intimately connected with how we manage them. We
look at this next.
 Pause point?
Review, reflect, read, or write?
1. Reflect on what you’ve learned so far. Just pause and think about it — both this lecture and how it
connects to previous ones. What’s interesting, what’s useful, what’s puzzling?
2. Write down your thoughts: how are these contributing to your achieving the ILOs for this lecture and the
unit more broadly? How is this helping you grasp the Core Concepts?
3. What puzzles remain? What is still unclear? How will you resolve these? Do you need to read more by
following up some of the references? Do you need to watch this or other lectures again? Will you bring
problems or questions to seminars, or ask your tutor online?
4. How can you deepen or extend your knowledge and understanding? What’s interested you that you’d
like to explore in more detail? See the curated readings on relevant topics for ideas.
5. Look at the readings for topics in this LM to familiarise yourself with what’s available — these may be
useful in later LMs, or assignments; see the references on the first slide of the lecture, and in the curated
Reading list; make a note of any you want to return to, to resolve a puzzlement, or extend your learning.
6. What connections can you make between topics in this ML or LM and other topics you’ve learned about
already? Make a mind map to build your integrated knowledge and understanding.
7. Try the online quizzes for the topic to test yourself, or see other online exercises (as available).
8. How can you relate what you’ve learned so far to your group work? Discuss key ideas with your team.
9. Look at the optional or extending online resources suggested on Blackboard, such as short videos from
the APM outlining a topic. Browse through the latest issue of the APM Journal to learn about the key
issues being discussed in the profession and related industries.

13

This might be a good point to pause and reflect on what you have learned so far. Write some notes. Clear up any confusions by reading some of the sources, or go deeper into the detail in the references if you are
interested. Here are some specific actions you can take now — you could do any or all of the following:

• Reflect on what you’ve learned so far. Just pause and think about it — both this lecture and how it connects to previous ones. What’s interesting, what’s useful, what’s puzzling?
• Write down your thoughts: how are these contributing to your achieving the ILOs for this lecture and the unit more broadly? How is this helping you grasp the Core Concepts?
• What puzzles remain? What is still unclear? How will you resolve these? Do you need to read more by following up some of the references? Do you need to watch this or other lectures again? Will you bring problems or
questions to seminars, or ask your tutor online?
• How can you deepen or extend your knowledge and understanding? What’s interested you that you’d like to explore in more detail? See the curated readings on relevant topics for ideas.
• Look at the readings for topics in this LM to familiarise yourself with what’s available — these may be useful in later LMs, or assignments; see the references given on the first slide of the lecture, and in the curated
Reading list; make a note of any you want to return to, to resolve a puzzlement, or extend your learning.
• What connections can you make between topics in this ML or LM and other topics you’ve learned about already? Make a mind map to build your integrated knowledge and understanding.
• Try the online quizzes for the topic to test yourself, or see other online exercises (as available).
• How can you relate what you’ve learned so far to group work? Discuss key ideas with your team.
• Look at the optional or extending online resources suggested on Blackboard, such as short videos from the APM outlining a topic. Browse through the latest issue of the APM Journal to learn about the key issues being
discussed in the profession and related industries.