Planning, Scheduling,

Monitoring and Control

The Practical Project Management
of Time, Cost and Risk
Planning, Scheduling,
Monitoring and
Control
Planning, Scheduling,
Monitoring and
Control
The Practical Project
Management of Time,
Cost and Risk

Association for Project Management

 Association for Project Management
Ibis House, Regent Park
Summerleys Road, Princes Risborough
Buckinghamshire
HP27 9LE

© Association for Project Management 2015

All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or
transmitted, in any form or by any means, without the express permission in writing of the
Association for Project Management. Within the UK exceptions are allowed in respect of any fair
dealing for the purposes of research or private study, or criticism or review, as permitted under
the Copyright, Designs and Patents Act, 1988, or in the case of reprographic reproduction in
accordance with the terms of the licences issued by the Copyright Licensing Agency. Enquiries
concerning reproduction outside these terms and in other countries should be sent to the Rights
Department, Association for Project Management at the address above.

British Library Cataloguing in Publication Data is available.

Paperback ISBN: 978-1-903494-44-8
eISBN: 978-1-903494-48-6

Illustrations by Gary Holmes

Cover design by Fountainhead Creative Consultants
Typeset by ReineCatch Limited, Bungay, Suffolk
in 11/14pt Foundry Sans
 Contents
List of igures and tables xviii
Foreword xxiv
Preface xxvi
Acknowledgements xxviii
Peer review xxx
Purpose xxxi
The PSMC process map xxxii
1 Overview 1
1.1 Part One: Deinition 1
1.2 Part Two: Planning 2
1.3 Part Three: Scheduling 3
1.4 Part Four: Monitoring and control 4
1.5 Part Five: Record keeping and learning 6
1.6 A note on the Contents, Index and Glossary 7
1.7 Management issues 7
1.7.1 Behaviour and resources 7
1.7.2 Processes and tools (scheduling software) 8
1.7.3 Common sense 8

Part One: Deinition 9

2 Business case 11
2.1 Deinition of the business case 11
2.2 Purpose of a business case 11
2.3 Contents of the business case 12
2.3.1 Structure of the business case 12
2.3.2 Planning information 15
2.3.3 Funding requirements 16
2.3.4 Resource requirements 16
2.4 Acceptance criteria in the business case 16
2.5 Beneits realisation in the business case 17
2.6 Procurement strategy 17
2.7 Project review and assurance process of the business case 19

v
Contents

3 Scope management 21
3.1 Deinition of scope management 21
3.2 Purpose of scope management 21
3.3 The scope management process 22
3.3.1 Deining the scope 22
3.3.2 Describing the scope 22
4 Requirements management 25
4.1 Deinition of requirements management 25
4.2 Purpose of requirements management 25
4.3 Process of deining requirements 25
4.3.1 Requirement description 26
4.3.2 Factors to consider when deining
requirements 26
4.3.3 Inputs into requirements management 27
4.4 The requirements management process 27
4.4.1 Capture and deine requirements from all
stakeholders 27
4.4.2 Link requirements to the product breakdown
structures and work breakdown structures
where appropriate 27
4.4.3 Decompose requirements 28
4.5 Works information (WI) 29
4.6 Statement of work (SOW) 30
5 Stakeholder management 31
5.1 Deinition of stakeholder management 31
5.2 Purpose of stakeholder management 31
5.3 Managing stakeholders through the project 31
6 Project familiarisation 33

Part Two: Planning 35

7 Introduction to planning 37
7.1 Deinition of planning 37
7.1.1 Deinition of the planning role 37
7.2 Purpose of planning 38
7.2.1 Beneits of planning 39
7.2.2 Success in planning 40
7.3 The difference between planning and scheduling 41

vi
 Contents

7.4 Principal scheduling components 42

7.4.1 Process step schedules 42
7.4.2 Time-based schedules 42
7.4.3 Schedule narrative 43
7.5 Approaches to planning 43
7.5.1 Top-down planning 43
7.5.2 Bottom-up planning 44
7.5.3 Agile planning in the software industry 47
7.6 Planning strategies 49
7.7 Allowing for risk 51
8 Breakdown structures 53
8.1 Deinition of breakdown structures 53
8.2 Purpose of breakdown structures 53
8.3 Creating breakdown structures 53
8.3.1 Level 1 53
8.3.2 Level 2 53
8.3.3 Level 3 and beyond 55
8.4 Product breakdown structure (PBS) 57
8.4.1 What is a ‘product’ in planning terms? 57
8.4.2 Deinition of a PBS 57
8.4.3 Purpose of a PBS 57
8.4.4 Constructing a PBS 57
8.5 Work breakdown structure (WBS) 59
8.5.1 Deinition of a WBS 59
8.5.2 Purpose of a WBS 59
8.5.3 Constructing a WBS 60
8.5.4 Principles of designing a WBS 60
8.5.5 WBS dictionaries 61
8.6 Organisational breakdown structure (OBS) 64
8.6.1 Deinition of an OBS 64
8.6.2 Purpose of an OBS 64
8.6.3 Constructing an OBS 65
8.7 Responsibility assignment matrix (RAM) 65
8.7.1 Deinition of a RAM 65
8.7.2 Purpose of a RAM 65
8.7.3 Constructing a RAM 66
8.7.4 The step-by-step approach to constructing
a RAM 67

vii
Contents

8.8 RACI matrix 68

8.8.1 Deinition of a RACI matrix 68
8.8.2 Purpose of a RACI matrix 68
8.8.3 Constructing a RACI matrix 68
8.9 Cost breakdown structure (CBS) 69
8.9.1 Deinition of a CBS 69
8.9.2 Purpose of a CBS 69
8.10 Resources breakdown structure (RBS) 70
8.10.1 Deinition of a RBS 70
8.10.2 Purpose of a RBS 71
9 Dependency management 73
9.1 Deinition of dependency management 73
9.2 Purpose of dependency management 73
9.3 Interface scope 74
9.4 Schedule impact 74
10 Health, safety and environmental 75
10.1 HSE issues at strategic level (planning) 75
10.2 HSE issues at tactical level (scheduling and method statements) 76
11 Cost estimating 77
11.1 Deinition of cost estimating 77
11.2 Purpose of a cost estimate 77
11.3 Cost estimating and the project life cycle 77
11.4 Estimate types 78
11.4.1 Scope development estimates 78
11.4.2 Other types of estimate 79
11.5 Contents of an estimate 80
11.6 Estimating methodologies 80
11.6.1 Approximate estimating methods 80
11.6.2 Deinitive estimating methods 82
12 Budgeting 83
12.1 Deinition of budgeting 83
12.2 Purpose of budgeting 83
12.3 Funding and budgets 83
12.4 Producing a cost budget 84
12.4.1 Cost breakdown structure 84
12.4.2 Cash-low statements 84
12.5 Budget transfers 87

viii
 Contents

Part Three: Scheduling 89

13 Introduction to scheduling 91
13.1 Deinition of scheduling 91
13.2 Purpose of scheduling 91
13.3 The scheduling process 92
13.3.1 Steps in establishing the schedule 92
13.3.2 Once the schedule is created 93
13.4 Schedule structure 94
13.4.1 Schedule density 94
13.4.2 Detail density: considerations 98
13.4.3 Network templates (fragnets) 99
14 Types of schedule 101
14.1 Schedule types: time-based 101
14.1.1 Development or strategic schedule 101
14.1.2 Tender schedule (or ‘bid schedule’) 102
14.1.3 Contract schedule 102
14.1.4 Baseline schedule 103
14.1.5 Summary schedule 103
14.1.6 Working schedule or ‘forecast schedule’ 103
14.1.7 Target schedule 104
14.1.8 Short- and medium-term schedules 104
14.1.9 As-built schedule 105
14.1.10 Post-build schedule 106
14.1.11 ‘What ifs’ (scenario planning) 107
14.2 Schedule types: tracker schedules 107
14.2.1 Procurement schedules 107
14.2.2 Design deliverables tracker 109
14.2.3 Other tracker schedules 109
15 Schedule design 113
15.1 Deinition of schedule design 113
15.2 Purpose of schedule design 113
15.3 Elements of schedule design 113
15.3.1 Activity identity numbers (IDs) 113
15.3.2 Activity descriptions 114
15.3.3 Different activity types 115
15.3.4 Activity steps 116
15.3.5 Time units 118

ix
Contents

15.3.6 Calendars 118

15.3.7 Project, activity and resource coding 120
16 Building the schedule 121
16.1 Creating a critical path network 121
16.1.1 Deinition of critical path method 121
16.1.2 Purpose of critical path network 121
16.1.3 Methods of constructing a critical path 122
16.1.4 Inputs into a critical path analysis 123
16.1.5 Introduction to creating a network analysis 124
16.1.6 Step 1: Create a logical network 125
16.1.7 Step 2: Forward pass 125
16.1.8 Step 3: Backward pass 126
16.1.9 Step 4: Calculation of total loat 127
16.1.10 Step 5: Identiication of critical path 128
16.1.11 Training in network analysis: a note 130
16.1.12 Float 130
16.1.13 Types of logic linking 132
16.1.14 Lags and leads 135
16.1.15 Use of constraints 136
16.1.16 Types of constraints 138
16.1.17 Displaying networks on bar charts 147
16.2 Estimation of durations 147
16.2.1 Three-point estimates 148
16.2.2 PERT (programme evaluation review technique) 148
16.2.3 Comparative 149
16.2.4 Benchmarked data 149
16.2.5 Resource-dependent 150
16.2.6 Expert opinion 150
16.2.7 Personal experience 150
16.2.8 Social media 151
16.3 Resourcing the schedule 151
16.3.1 Deinition of resources 152
16.3.2 Purpose of resourcing the schedule 152
16.3.3 Process of resourcing the schedule 153
16.3.4 Resource smoothing 154
16.4 Horizontal and vertical integration of schedules 156
16.4.1 Horizontal integration 156
16.4.2 Vertical integration 157

x
 Contents

16.5 Scheduling interfaces and dependencies 157

16.5.1 Identiication 157
16.5.2 Coding 158
16.5.3 Integration and impact analysis 159
16.5.4 Impact resolution 163
16.6 Time contingencies 164
16.6.1 Deinition of buffers 164
16.6.2 Use of buffers 164
17 Communicating the schedule 167
17.1 Bar charts 167
17.1.1 Presentation considerations 167
17.1.2 An alternative to bar chart reporting 170
17.2 Line of balance 172
17.2.1 Creating a line of balance chart 172
17.2.2 Advantages of line of balance 173
17.2.3 Limitations of line of balance 174
17.3 Time chainage 174
17.3.1 Deinition of time chainage charts 174
17.3.2 Explanation of the time chainage technique 175
17.3.3 Advantages of time chainage 177
17.3.4 Limitations of time chainage 177
17.4 Schedule narrative 177
17.4.1 Scope 179
17.4.2 Health, safety and environmental
considerations 179
17.4.3 Risks, opportunities and contingencies 179
17.4.4 Breakdown structures 179
17.4.5 Project phasing 179
17.4.6 Stakeholders 179
17.4.7 Resources 179
17.4.8 Critical path(s) 180
17.4.9 Assumptions 180
17.4.10 Calendars 180
17.4.11 Activity codes 180
17.4.12 Details of any possessions, shut-downs or other
special working conditions 181
17.4.13 Consents required 181
17.4.14 Permits and licences 181

xi
Contents

18 Schedule review 183

18.1 Deinition of schedule review 183
18.2 Purpose of schedule review 183
18.3 Checking the schedule 183
18.3.1 Understanding the project schedule 184
18.3.2 Components of the schedule display 184
18.3.3 Critical matters not included in the display 187
18.4 Planning checks 188
18.4.1 Administration 188
18.4.2 Management issues 188
18.4.3 Contract requirements 188
18.4.4 Scope 189
18.4.5 Associated documents 189
18.4.6 Planning issues 189
18.4.7 Progress update 190
18.4.8 Communication of the schedule 190
18.5 Scheduling checks 190
18.5.1 Activity checks 191
18.5.2 Logic checks 193
18.5.3 Float and critical path checks 196
18.5.4 Resources checks 198
18.5.5 Review of schedule risk 198
19 BIM (Building information modelling) 199
19.1 Deinition of BIM 199
19.2 Purpose of BIM 200
19.3 BIM technology 201
19.4 The BIM culture 201
20 Agile 203
20.1 Deinition of agile 203
20.2 Purpose of agile 203
20.3 Methods 204
20.3.1 Advantages 205
20.3.2 Limitations 206

Part Four: Monitoring and control 207

21 Baseline 209
21.1 Deinition of the project baseline 209

xii
 Contents

21.2 Purpose of a project baseline 211

21.3 Principles of project baselining 211
21.4 When to set the baseline 212
21.5 Establishing the baseline schedule 212
21.6 Deinition and purpose of baseline maintenance 213
21.6.1 Deinition of baseline maintenance 213
21.6.2 Purpose of baseline maintenance 213
21.6.3 Baseline maintenance as a result of schedule changes 213
21.6.4 Illustration of the principle of baseline
maintenance 214
21.7 Re-baselining: re-planning 216
21.7.1 When to consider re-planning 217
21.8 Re-baselining: re-programming 218
21.8.1 When to consider re-programming 218
21.9 Notes and rules for schedule maintenance, re-planning and
re-baselining 220
21.10 The link between change management and the project
baseline 220
22 Performance reporting 221
22.1 Deinition of performance reporting 221
22.2 Purpose of performance reporting 222
22.3 Evaluating and recording progress 223
22.3.1 Progress assessment 223
22.3.2 What needs to be recorded in the schedule? 223
22.3.3 What else needs to be recorded in a report? 224
22.3.4 How often is progress recorded? 224
22.4 Variance analysis methods of progress monitoring 224
22.4.1 Drop line method 224
22.4.2 Activity weeks method 226
22.4.3 Milestone monitoring 228
22.4.4 Progress on a line of balance chart 229
22.4.5 Cash-low monitoring 230
22.4.6 Resource monitoring 230
22.4.7 Cost value analysis 231
22.4.8 Quantity tracking 231
22.5 Performance analysis methods of progress monitoring 234
22.5.1 Network analysis and measurement of loat usage 234
22.5.2 Earned value analysis 235

xiii
Contents

23 Cost control 251

23.1 Deinition of cost control 251
23.2 Purpose of cost control 251
23.3 The cost control process 252
23.3.1 Performance measurement baseline (PMB) 252
23.3.2 The link between cost control and change control 252
23.3.3 Performance measurement 253
23.4 Learning lessons from cost control 253
24 Short-term planning 255
24.1 Deinition of short-term planning 255
24.2 Purpose of short-term planning 255
24.3 The short-term planning process 255
24.3.1 Make ready needs 257
24.3.2 Coordination meeting 257
24.3.3 Performance reporting 257
25 Change management 259
25.1 Deinition of change management 259
25.2 Purpose of change management 259
25.3 Principles of change management 260
25.4 Change control 260
25.4.1 Why change control is needed 260
25.4.2 Change control considerations 261
25.5 Project-level change: process overview 261
25.6 Raising a change request 263
25.6.1 Drafting a change request 263
25.7 The change log 263
25.8 Initial evaluation of the change request 264
25.9 Estimating impact of change 264
25.10 Detailed evaluation of change request 264
25.10.1 Rejected request 265
25.10.2 Deferred request 265
25.11 Approved request 266
25.11.1 Change orders 266
25.11.2 Scope transfers 267
25.11.3 Schedule revisions 267
25.11.4 Corporate governance 267
25.12 Implementing the change 267
25.12.1 Adjusting schedule in line with change 268

xiv
 Contents

25.13 Communicating the change 269

25.14 Monthly change reporting requirements 269
25.14.1 Managing the schedule change process 271
26 Risk management 273
26.1 Deinition of risk management 273
26.2 Purpose of risk management 273
26.3 Risk management plan 274
26.4 The risk management process 274
26.4.1 Planning 274
26.4.2 Risk identiication 276
26.4.3 Risk assessment 277
26.4.4 Risk response 280
26.4.5 Risk review 280
26.4.6 Risk reporting 281
26.5 Risk draw down 281
26.5.1 When risks are mitigated 283
26.5.2 When risks are realised 283
26.5.3 When risks are closed 283
26.5.4 When opportunities are realised 283
26.5.5 Documenting changes in the risk budget 284
26.6 Quantitative schedule risk analysis (QSRA) 284
26.6.1 Deinition of QSRA 284
26.6.2 Purpose of QSRA 285
26.6.3 Key requirements for a QSRA 286
26.6.4 The stages of schedule risk analysis 286
26.6.5 Distribution types 288
26.6.6 Application of risks to schedule activities 291
26.6.7 QSRA output 292
26.6.8 Reporting 294
26.7 Quantitative cost risk analysis (QCRA) 296
26.7.1 Deinition of QCRA 296
26.7.2 Purpose of QCRA 296
26.7.3 The QCRA process 297
27 Forensic analysis 303
27.1 Deinition of forensic analysis 303
27.2 Purpose of forensic analysis 303
27.3 Methods of forensic analysis 303
27.3.1 As-planned versus as-built method (AP v AB) 304

xv
Contents

27.3.2 Impacted as-planned method (IAP) 305

27.3.3 Collapsed as-built method or as-built but
for (CAB) 306
27.3.4 Time impact analysis method (TIA) 307
27.3.5 Windows analysis 309
27.3.6 Other considerations 309

Part Five: Record keeping and learning 311

28 Record keeping 313
28.1 Deinition of record keeping 313
28.2 Purpose of record keeping 313
28.3 How to record 313
28.4 What to record 314
28.5 Methods of keeping records 315
29 Document management 317
29.1 Deinition of document management 317
29.2 Purpose of document management 317
29.3 Document control systems 318
29.4 Version control 318
29.5 Handover of documentation 318
30 Handover and closeout 319
30.1 Handover 319
30.1.1 Deinition of handover 319
30.1.2 Purpose of the handover process 319
30.1.3 Planning handover 320
30.1.4 Issues in the management of handover 321
30.2 Project closeout 322
30.2.1 Deinition of project closeout 322
30.2.2 Purpose of project closeout 322
30.2.3 The project closeout process 322
31 Lessons learned 325
31.1 Deinition of lessons learned 325
31.2 Purpose of lessons learned 325
31.3 Productivity data 325
31.4 Qualitative lessons learned 326
31.4.1 Stakeholders involved in a lessons learned review 326
31.4.2 Considerations 327

xvi
 Contents

The inal word 329

Glossary 331
Acronyms 343
Index 345

xvii
 Figures and tables
Figures
1.1 The importance of planning and control in project management 2
3.1 Types and relationships of breakdown structures 23
4.1 Design and development V model 28
7.1 Top-down vs. bottom-up planning 44
7.2 Rolling wave planning 46
7.3 Agile planning 47
7.4 Setting early and late curves 50
7.5 Interpreting ‘S’ curves 51
8.1 Creating a breakdown structure level 1 54
8.2 Creating a breakdown structure level 2 54
8.3 Creating a breakdown structure level 3 55
8.4 Types and relationships of breakdown structures repeated 56
8.5 Sample product breakdown structure 58
8.6 Work breakdown structure 59
8.7 Work breakdown structure dictionary (defence) 62
8.8 Work package content sheet (construction) 63
8.9 Organisation breakdown structure 64
8.10 Responsibility assignment matrix 66
8.11 Example of a RACI 69
8.12 Cost breakdown structure 70
11.1 Cost estimating process 78
12.1 Time measured in inancial periods 85
12.2 Generating a cost forecast using a banana curve 86
13.1 The scheduling process in the context of planning, monitoring
and control 94
13.2 Relationship of different densities in schedules 97
13.3 A hierarchy of plans and planning documents 98
14.1 Distorting the time/cost/quality triangle 105
14.2 Types of time-phased schedules and their relationship 106
14.3 A sample procurement schedule 108
14.4 Time-phased procurement schedule 110

xviii
 Figures and tables

14.5 Design deliverables tracker 111

15.1 Establishing steps/objective criteria 117
15.2 Suitability for steps/objective criteria 117
16.1 Example of the precedence diagram method (PDM) 122
16.2 Example of the arrow diagram method (ADM) 123
16.3 Typical time analysis coding 124
16.4 Step 1: Create a logical network 125
16.5 Step 2: The forward pass calculation 126
16.6 Step 3: The backward pass 127
16.7 Step 4: Calculation of total loat 128
16.8 Step 5: Identiication of critical path 129
16.9 Longest path calculations 129
16.10 The alternative method of calculation in a network 130
16.11 Float types 131
16.12 Finish to start relationship 133
16.13 Start to start relationship 133
16.14 Finish to inish relationship 134
16.15 Start to inish relationship 135
16.16 Summary of types of logic and lags 136
16.17 ‘As late as possible’ constraint 138
16.18 ‘Finish on’ constraint 139
16.19 ‘Finish on or after’ constraint 140
16.20 ‘Finish on or before’ constraint 141
16.21 ‘Mandatory inish’ constraint 142
16.22 ‘Mandatory start’ constraint 143
16.23 ‘Start on’ constraint 144
16.24 ‘Start on or after’ constraint 145
16.25 ‘Start on or before’ constraint 146
16.26 Bar chart display 147
16.27 Establishing the duration of a task based on resource 153
16.28 First draft resources proile 154
16.29 Resource-smoothed histogram 155
16.30 Resource-levelled chart with resource limit 156
16.31 Internal integration milestones 159
16.32 External integration milestones 160
16.33 Logic-linked dependency schedule 161
16.34 Dependency schedule driving project schedules 162
16.35 Different buffer types 165

xix
Figures and tables

17.1 A simple bar chart 168

17.2 Strategic schedule of a major construction project at low density 169
17.3 Using milestones to give clarity to the schedule 171
17.4 Creating a line of balance chart 172
17.5 Optimising work low in line of balance 173
17.6 Basic elements of a time chainage chart 174
17.7 Time chainage task 1 175
17.8 Time chainage tasks 2 and 3 176
17.9 Time chainage task 4 176
17.10 Time chainage sequencing 177
17.11 Example of a time chainage diagram for a new railway 178
18.1 Components of a schedule for review 185
18.2 Logic bottleneck 196
19.1 BIM level maturity map 200
20.1 Agile processes 204
20.2 Illustration of an agile methodology using ‘scrums’ and ‘sprints’ 205
21.1 Establishment of baseline 210
21.2 Baseline after work starts 210
21.3 Baseline maintenance step 1 214
21.4 Baseline maintenance step 2 215
21.5 Baseline maintenance step 3 216
21.6 Baseline maintenance step 4 217
22.1 Illustration of the drop line method 225
22.2 Simple ‘activity weeks’ monitoring chart 226
22.3 Cumulative results from the ‘activity weeks’ chart 227
22.4 Recording actual progress in line of balance 229
22.5 Sample cost value report 232
22.6 Quantity tracking with production curves 233
22.7 Budget allocation to the plan 237
22.8 Planned value curve 240
22.9 Earned value 241
22.10 Actual costs (ACWP) added 241
22.11 Earned value analysis: cost and schedule variance 242
22.12 Cost and schedule variance chart 243
22.13 Earned value analysis with time variance 244
22.14 Bull’s eye performance chart 245
22.15 Calculating estimated time to completion 246
22.16 Illustration of various earning techniques and appropriate uses 247

xx
 Figures and tables

22.17 Advantages and disadvantages of EVTs 248

24.1 Short-term schedules in context of other plans 256
24.2 Performance analysis on short-term schedule 258
25.1 Process overview: project change control 262
25.2 Example of monthly change reporting 270
25.3 Monthly change report 270
26.1 Risk management life cycle 275
26.2 Risk identiication in a typical risk log 277
26.3 Risk assessment matrix: severity ratings score 278
26.4 Opportunity assessment matrix: severity ratings score 278
26.5 Typical risk log continued, showing current impact and
response planning 279
26.6 Risk response options 280
26.7 Reporting of basic risk data 281
26.8 Tracking risk performance over time 282
26.9 Normal distribution curve 288
26.10 Log normal distribution curve 289
26.11 Uniform distribution 289
26.12 Triangular distribution: possible options 290
26.13 PERT distribution 291
26.14 Duration uncertainty probability chart 293
26.15 Duration uncertainty tornado chart 294
26.16 QSRA probability distribution chart 295
26.17 Full QSRA tornado chart 296
26.18 QCRA chart 299
26.19 QCRA chart (redraw) 300
30.1 Context of handover and closeout 320
31.1 Example proforma to collect output rates 326

Tables
2.1 Examples of requirements and acceptance criteria 17
6.1 Sources of project information 33
8.1 Explanation of RACI codes 68
12.1 A simple cost budget 84
13.1 Features associated with density of schedules 95
15.1 Example of activity descriptions 114
16.1 Example of three-point estimate 148

xxi
Figures and tables

16.2 Example of PERT calculation 148

16.3 Example of comparative estimates 149
16.4 Example of benchmarked data 149
16.5 Example of resource-dependent estimate 150
16.6 Interface impact schedule 163
21.1 Baseline maintenance, re-planning, re-baselining matrix 219
22.1 Measurement of loat usage 234
25.1 Example of inancial authority 267
26.1 QCRA conidence levels 301
27.1 As-planned vs. as-built method 304
27.2 Impacted as-planned method 305
27.3 Collapsed as-built method or as-built but for 306
27.4 Time impact analysis method 307

Picture credits
The following illustrations have been adapted from originals published by Taylor
Woodrow/Vinci Construction: Figure 8.8, Figure 13.2, Figure 13.3, Figure 14.3,
Figures 17.4 to 17.10, Figures 21.1 to 21.6, Figure 22.4, Figure 22.14, Figure
24.1, Figure 26.1, Figures 26.7 to 26.8, Figure 31.1
The following illustrations have been adapted from originals published by BAE
Systems: Figure 8.7, Figure 17.3
The following illustrations have been adapted from originals published by Turner
& Townsend: Table 25.1, Figure 25.2, Figure 25.3
Figure 4.1 courtesy of Neil Curtis
Figure 14.4 courtesy of Balfour Beatty
Illustration on p. 329 courtesy of Simon Taylor/Paul Kidston
All other illustrations are courtesy of the APM PMC SIG

xxii
‘Planning is an unnatural process; it is much more fun to do
something. The nicest thing about not planning is that failure comes
as a complete surprise, rather than being preceded by a period of
worry and depression.’
Sir John Harvey Jones
 Foreword

Planning has been part of my life for so many years now. I trained as a mechanical
engineer, and the last assignment of my apprenticeship was within the construc-
tion planning department of British Steel’s piping division (1974 is a long time ago
now, unfortunately!). That experience captured my imagination and I decided to
embark on a career as a planning engineer. My many experiences since have
taught me how vitally important it is to plan how a project, programme, portfolio
or business will be delivered.
Sir John Harvey Jones’ quote ‘The nicest thing about not planning is that failure
comes as a complete surprise, rather than being preceded by a period of worry
and depression’ reveals a culture still buried deep within many organisations’ and
individuals’ approach to project or business delivery today. However, when you
have been involved in the ‘complete surprise’ you realise that if the team involved
had opted for the ‘worry and depression’ this would have prompted action and
led to a more successful outcome.
Fortunately, my involvement in successfully delivered projects or programmes
far outweighs my failing project experiences, and, when looking back, success
usually comes down to good deinition, preparation and planning from inception
onwards. The Kuwait reconstruction (1991/1992) and London 2012 Olympic
(2008 to 2012) programmes were two big highlights in my career, where the
challenge was to achieve delivery within very clearly deined timescales under
the highest possible level of public scrutiny.
For these programmes, the creation and maintenance of an integrated suite of
plans/schedules allowing project/programme-level decision making to be
effective was a key part of the delivery success which both commentators at the
time and historians since have recorded.
Now, as a result of the considerable efforts of the APM Planning, Monitoring
and Control (PMC) Speciic Interest Group (SIG), organisations and programme/
project teams will have a guide covering all aspects of planning, from preparing
to undertake a project to executing that project, controlling its safe delivery to
budget, time and quality.

xxiv
 Foreword

I believe that this publication has captured the best practices for planning and
will become the reference document of note for organisations and their teams
during future project deliveries.

David Birch
Head of capital delivery project controls – National Grid
Formerly head of programme controls – ODA delivery partner CLM
(2008–2012)
12 June 2014

xxv
 Preface

Sir John Harvey Jones said that ‘Planning is an unnatural process . . .’ and we all love
this quote, as it says something that we recognise about human nature. In this guide
we contend that planning is partly a process, a ‘science’ if you like. But there is also
an art to planning, one which requires good ideas, experience, deep thought and
creative thinking, particularly around business planning, consideration of options
and choosing methodologies. This book discusses the art of planning, but places an
emphasis on the scientiic side of planning – the processes of scheduling, risk
analysis, management of change (and so on) – in what we hope is a practical manner.
The guide was conceived after the formation of the Planning, Monitoring and
Control (PMC) Speciic Interest Group (SIG) in late 2010 to ill a gap in published
APM knowledge. It was intended to cover all planning aspects of preparing to
undertake a project, executing a project, controlling its delivery to budget, time
and quality, and delivering it safely. The guide was to be about planning in the
widest sense of the word. Just as with the formation of the PMC SIG, its aim has
been to bring together different project specialisms, rather than focus on a
particular area of specialist knowledge.
After much discussion and debate, a basic structure for the guide was agreed
upon, and content started to be written. By late 2013 a large amount of material
had been gathered but momentum had lagged, so a sub-committee of the SIG
was formed to pull together all the material and ill the gaps that inevitably still
existed at that point. An intense period of writing and re-writing, as individuals
and as a group, followed.

Reading this book

We have covered a lot of material in this book and realise that it may look a
daunting read – but it has been written as a reference guide to dip into, so we
have provided a comprehensive contents and index that will, we hope, assist in
navigation through the book.
We have tried to write this guide in plain English as far as we possibly could,
adopting the ‘Emily test’ to challenge ourselves whenever we slipped into

xxvi
 Preface

‘management speak’ or other pretentious or pompous language. No doubt we

have not always passed the test, but we have done our best! (Emily is Simon
Taylor’s 10-year-old daughter, who challenged such language when being
subjected to the drafts of this guide for bed-time reading!)
This book has been written entirely by volunteers, giving their own and their
employers’ time freely and willingly for the purpose of advancing and dissemi-
nating knowledge. The effort and time given by the group were well beyond the
call of duty, and I cannot express my gratitude for the amount of time that already
busy individuals were prepared to put into writing and illustrating the guide.
This book may not be perfect – there surely remains work to be done to make
it so – but we have reached the point where this group has done its best, and we
look to the project management community to provide the feedback and
expertise to strengthen the guide in what we hope will be future editions in years
to come.

Paul Kidston
Lead author
June 2014

xxvii
 Acknowledgements

This guide was discussed, debated and drafted over a number of years, but written
and inalised by a small team who formed a sub-committee of the Association for
Project Management’s Speciic Interest Group ‘Planning, Monitoring and Control’,
consisting of:

Lead author: Paul Kidston (Head of project control, Taylor Woodrow Civil
Engineering)
Co-author: Keith Haward (Associate director, Turner & Townsend)
Jenn Browne (Programme manager, Ministry of Defence)
Carolyn Limbert (Principal planner, Harmonic Ltd)
Simon Taylor (Head of planning, Transport for London)

In addition, signiicant contributions were made by the following members of the

PMC SIG:

Mike Prescott (Head of project control management,

Cavendish Nuclear)
Stephen Jones (Sellaield Ltd, chairman of the APM PMC SIG)
Guy Hindley (Turner & Townsend, formerly of BAE Systems)
Steve Wake (SW Projects, chairman of APM)
Alex Davis (GE Oil and Gas, formerly of MoD)
Ewan Glen (BMT Hi-Q Sigma)

Signiicant contributions from outside the SIG were made by:

Franco Pittoni (Technical director – BIM & Project Controls,

Parsons Brinckerhoff)
Ewen MacLean (Berkeley Research Group, LLC)

Additional material and comments were provided by: Alan Bye (Rolls-Royce);
Andrew Chillingsworth (Atkins Rail, formerly of Turner & Townsend); Breda Ryan
(Jacobs PMCM UK Infrastructure, formerly of Heathrow Airport Limited); Claire

xxviii
 Acknowledgements

Purser (Capable Consulting, formerly of BMT Hi-Q Sigma); Deborah Perrin

(Rhead Group, formerly of Turner & Townsend); Gary Mainwaring (General
Dynamics); Ian Williams (Taylor Woodrow); Jim Malkin (Deltek); Jonathan Crone
(Foster Wheeler, formerly of Subsea7); Marvin Edwards (Goldheart); Mike
Semmons (AgustaWestland); Natalie Evans (BMT Hi-Q Sigma); Rebecca Evans
(Turner & Townsend); Roger Joby (1 to 1 to 1); Ros Downs (BAE Systems); Sue
Simmonite (BAE Systems); Tina Vadolia (BMT Hi-Q Sigma, formerly of Keval).
BAE Systems, Taylor Woodrow, BAA (Heathrow Airports Ltd) and Turner &
Townsend provided much source material, for which we are very grateful.
Venues to meet in, lunches and really strong cups of hot tea were provided by
Taylor Woodrow, APM and in particular by TfL and Turner & Townsend, both of
whom were particularly generous with their meeting rooms and catering.

Dedication
This book is dedicated to the memory of Rebecca Evans, a much respected SIG
member and contributor to this guide.

xxix
 Peer review

The guide was widely peer reviewed by people with a wide range of experience
from outside the SIG, and we are grateful to the following, who provided signi-
icant comments and suggestions:
From the Rhead group, Pete Mill, Steve Highield, John Nixon and Robin
Smoult; Ben Whitlock (Babcock International Group); James Manthorpe, Louise
Arrowsmith and Sarah Cummins, all of Taylor Woodrow. From the Cross Industry
Planning and Project Controls (CIPPC) group, Mark Singleton (Balfour Beatty
Construction Services UK), Franco Pittoni (Parsons Brinkerhoff) and Phil Budden
(Costain) all provided useful suggestions.

xxx
 Purpose

The content of this document identiies the scope of planning knowledge as

understood by the Association for Project Management (APM) Planning,
Monitoring and Control (PMC) Speciic Interest Group (SIG). This knowledge
was compiled and discussed in a series of working sessions and reviews
commencing in October 2010 and concluding, for publication purposes, in July
2014.
It provides reference guidance for practitioners and students along with the
study material required for the forthcoming Foundation exam.
This guide covers many topics, but does not attempt to supersede many other
notable APM publications; it is hoped that we have achieved a practical guide
that sits alongside them, in particular:

Project Risk Analysis and Management Guide

The Earned Value Management APM Guidelines
The Earned Value Management Handbook
The Scheduling Maturity Model
The Earned Value Management Compass

Ultimately, this guide builds on the Introduction to Project Planning guide

(published by APM in 2008) by the forerunner of the PMC SIG – the Planning
SIG, which did what its title suggested and provided an introduction and a
manifesto for project planning. Although that book explains the need for planning,
this handbook is intended to be the practical guide to best practice in planning.
This guide has been written totally by volunteers. We would welcome any
constructive feedback that may be used in improving future editions of this
guide, which we hope will follow and build on this starting point.

Note
Within this guide, text highlighted in blue means that the term thus highlighted is
referred to in the glossary.

xxxi
 The PSMC Process Map
The illustration gives a graphical representation of the stages a project will go through. This guide follows this structure and
uses the icons to introduce each section. This shows how each of the control stages relates to the others.

1. Definition 5 Records & learning

Business case Scope Requirements Stakeholder Project

management management management familiarisation Record keeping

Chapter 2 Chapter 3 Chapter 4 Chapter 5 Chapter 6 Chapter 28

2. Planning

Introduction to Breakdown Dependency Health, safety

planning structures management and environmental

Document
Chapter 7 Chapter 8 Chapter 9 Chapter 10 management

Cost estimating Budgeting

Chapter 29

Chapter 11 Chapter 12
3. Scheduling

Introduction to Types of Schedule design Building the Communicating

scheduling schedule schedule the schedule

Handover and
Chapter 13 Chapter 14 Chapter 15 Chapter 16 Chapter 17 closeout

Schedule review BIM Agile

Chapter 30

Chapter 18 Chapter 19 Chapter 20

4. Monitor & control

Baseline Performance Cost control Short- term Change

reporting planning management

Lessons learned
Chapter 21 Chapter 22 Chapter 23 Chapter 24 Chapter 25

Risk management Forensic analysis

Chapter 31

Chapter 26 Chapter 27
 1

Overview

Effective project management requires effective planning and control. Effective

planning and control requires:

• the clear deinition of the project;

• a robust approach to planning the project;
• selection and use of the appropriate scheduling techniques;
• rigorous monitoring that enables proactive control of the project;
• a sound basis for this is good record keeping, which also facilitates the virtuous
feedback and learning cycle.

This book offers tried and tested techniques and principles covering these aspects
of project management. It introduces some lesser-known and emerging practices,
some of which will move into mainstream project management in the years
to come.
The book is structured into ive main sections relecting these requirements,
and a brief introduction to each section and chapter follows.

1.1 Part One: Deinition

At a strategic level, there are a number of fundamental questions that need
addressing:

• Why is the project required?

• What does the customer want the project to deliver?
• How will the success of the project be measured?
• How will the project be procured?
• What is the attitude of its customers (or its funders) to risk?
• Similarly, what is their attitude to quality (including scope)?
• When does the client want the capability delivered by?

Part One of this guide describes the principal processes that deine the project,
and answers these questions.

1
Planning, Scheduling, Monitoring and Control

The irst topic dealt with is the creation of the business case (Chapter 2). This
is the starting point in the life of any project, and it is a vital step in ensuring that
the project is viable, affordable and desirable. It sets the scene for all that follows
– the planning, scheduling, monitoring and control, and, not least, the delivery of
the project.
Assuming the business case is approved, the scope of the project must be
deined and agreed with all stakeholders (Chapter 3). Deining the scope will
begin the process of making key decisions about the project, deining and
selecting from various options until a preferred solution is agreed and approved.
Once the scope has been agreed, the details of the requirements are
determined. See Chapter 4 (Requirements management).
Stakeholder management (Chapter 5) is dealt with briely, as the responsibility
for this falls mainly on the project manager (see Soft Issues – Project Management
Time in Figure 1.1).
Chapter 6, the inal chapter in Part One (Project familiarisation), is a checklist
of the project documentation that has been created during the deinition stage.
These are the key documents that must be read and understood to enable the
planning – and subsequent processes detailed in the guide – to be carried out in
an informed way.

Project management Project management

process time

Planning
Planning and
control
Soft
issues Soft
issues

Figure 1.1 The importance of planning and control in project management

1.2 Part Two: Planning

The planning phase of the project needs to answer some fundamental questions,
such as:

2
 Overview

• How much will the project cost?

• How long should the project take?
• Are there beneits to inishing early, and what are they?
• What are the costs of an earlier completion, and do they outweigh the beneits?
• On the other hand, how is funding released, and are there any limits on this?
• How will the performance of the project be measured, through all its phases?
• Can the project be delivered safely?

Chapter 7 introduces planning – the team approach to working out how to deliver
the project. After discussing and deining the difference between planning and
scheduling (a point worth making to help deine the two terms) – these terms
are often used interchangeably, but they are two very different processes and
require different skill sets – the opening chapter of this section goes on to discuss
the principal components that will make up the overall project plan – the various
schedules and narratives. It is important to understand these at the planning
stage, and, whilst they are introduced here, they will be covered in further detail
in Part Four.
Chapter 8 deines and discusses the purpose of the various breakdown
structures that are used in project management. We also propose a method of
creating these structures. Chapter 9 introduces the concept of dependency
management. This theme is returned to in Part Four, when the speciics of
schedule dependencies are deined in greater detail.
A critical concern of all project management must be the highest standards of
health, safety and environmental management (Chapter 10). We cannot do
justice to this topic in a book aimed across all industries, but it is a very important
aspect when planning any project. It will have a fundamental inluence on the
project – how it is planned, designed/engineered and constructed.
Finally, in Chapters 11 and 12, we discuss the cost-estimating process and the
budgeting process that follows it. The former is an essential step in the deinition
and planning (and, indeed, scheduling) of the project. The latter is essential in the
creation of targets and baselines that will form the basis of monitoring and control.

1.3 Part Three: Scheduling

A fundamental question is: who owns the schedule? The answer is, of course,
that it is the project manager, with the support of the whole project team. The
schedule is created by collating the thoughts of many people; the specialist

3
Planning, Scheduling, Monitoring and Control

planner’s role is to form these thoughts into a coherent schedule, and then to
communicate it effectively. This will include:

• developing logistical plans;

• setting up the schedule in planning software;
• deciding how the plan is to be presented and communicated.

Part Three commences with a chapter (13) setting the scene; it discusses the
purposes of scheduling and some of the basic philosophies and structures.
Chapter 14 describes the various types and purposes of schedules that might be
used on a project.
Chapter 15, entitled Schedule design, details the various elements of a
schedule that need to be considered prior to commencement of any scheduling:
for example, what type of activity should be used, or what coding and other
structures should be applied.
Chapter 16 addresses the construction of the schedule. It is this guide’s
contention that all scheduling starts with the creation of a logic-linked network.
On simple projects a bar (or Gantt) chart may sufice, but we have chosen to
describe these as outputs, or communication tools, rather than scheduling tools
in their own right. We believe this is consistent with current practice. Within this
chapter we discuss not only networks but also how durations may be calculated,
the importance of considering and scheduling resources, and how schedules are
interfaced with other stakeholders.
Chapter 17 follows with a number of suggestions about how the schedule is
communicated – from the aforementioned bar charts through to line of balance
and time chainage charts that are useful in particular circumstances. One very
important and sometimes overlooked document is the schedule narrative. This
document serves to explain and clarify the planning and scheduling effort that
has resulted in the (suite of) schedule(s) that have been created. Without this,
the project cannot be clearly understood. We suggest appropriate contents for
this narrative.
The inal part of the generic process is schedule review (Chapter 18), describing
the basic and detailed checks that should be made on the plans and schedules.
Turning once again to the question of who owns the programme, the inal
two chapters of this part (Chapters 19 and 20) deal with two emerging practices
that have an important part to play in sharing the planning and the schedule
with the project team: the agile approach, used mainly in software development,
and the building information modelling (BIM) approach for use in asset design,

4
 Overview

construction and management. The latter is mandated for use in all government
procurement activity from 2016, so it is very likely to grow in signiicance over the
coming years.

1.4 Part Four: Monitoring and control

Once the project is in its delivery phase, there are four fundamental questions
that project stakeholders will ask of the project manager:

• Where are we?

• What has it cost to get here?
• Where are we going?
• How can we correct any problems?

The irst question (Where are we?) may be decomposed into further questions
such as: Are we on schedule? If not, where have the delays occurred? What
caused the delay? Who is responsible, and what effect will it have on the project?
Finally, what can be done to recover?
The second question (What has it cost to get here?) may also be broken down
into similar questions: Where and why did any over or under spend occur? Who
is responsible and how will we recover?
The question ‘Where are we going?’ may be considered in terms of time
(When are we going to inish?), cost (What is it going to inally cost?) and quality
(Will the inished product do what we intended?). The analysis of current trends
will enable forecasting and/or challenge on these matters.
The fourth and inal question (How can we correct any problems?) also
requires project-speciic experience and very often innovative thinking, topics
that this guide does not, indeed cannot, cover. The monitoring and control
process provides the basis for asking the right questions, and perhaps the basis
for answering them.
The chapter on baselines (Chapter 21) could be a section in its own right, as it
is the pivot between the planning and scheduling effort and the processes of
monitoring and control. It is, however, a useful introduction to performance
management, and touches on issues of change and other forms of control that
are dealt with later in this part of the book.
Performance reporting (Chapter 22) covers the collection of progress and cost
information and how this is turned into useful management data. Various

5
Planning, Scheduling, Monitoring and Control

reporting techniques are discussed: irst, variance reports that simply measure
differences, exposing them (hopefully) to potential management action; second,
a category that we have called ‘performance analysis methods’ that includes
potentially the most valuable reporting of all, earned value analysis. As stated in
the earlier purpose section of this guide, this book does not supersede the APM’s
own Earned Value Handbook, and readers with a further interest in this subject
should refer to that guide. However, this guide does cover the basic principles of
earned value.
Cost control is given its own chapter (Chapter 23), and, although it is covered
with some brevity, the fundamental principles are discussed.
After the project has started, the project needs to react to progress made and
re-plan as necessary. This is often the driver of short-term planning (although
breaking plans into greater levels of detail (or ‘densities’) is also a function of
this). In Chapter 24, we outline this process.
Chapters 25 and 26 discuss two processes that will actually be active
throughout the whole life of the project. The former discusses change
management, and the latter gives an overview of risk management. This chapter
provides details of the QSRA and QCRA processes, which are the quantitative
analyses of schedule and cost, respectively (hence the acronyms). These are tools
that check the initial and ongoing robustness of the project plans.
The last chapter in Part Four (Chapter 27) discusses forensic analysis and delay
and disruption analysis.

1.5 Part Five: Record keeping and learning

Record keeping (Chapter 28) is vital to provide a comprehensive history of the
project. It forms both the basis of updating the schedules and plans for perform-
ance reporting, and to enable forensic analysis should it be necessary. It provides
the basis of much of the learning from the project that can be used to improve
future projects. Document management (Chapter 29) ensures that this and all
other relevant project information is available to those who need it.
The closely allied (but separate) processes of handover and closeout of the
project are dealt with in Chapter 30. The handover process ensures that the
project and its obligations are complete and signed off; closeout essentially closes
down all the support structures and commercial settlement of the project.
The inal chapter of the book deals with another process that exists throughout
the life of the project: lessons learned (Chapter 31). This includes both hard and

6
 Overview

soft data. An example of the former would be productivity outputs achieved; an

example of the latter might be an analysis of why the outputs were at the levels
achieved.

1.6 A note on the Contents, Index and

Glossary
We have included comprehensive contents and index to facilitate easy
referencing throughout the book. This is in keeping with the belief that this is a
guide to dip into rather than read cover to cover (although the reader is welcome
to try!). Cross referencing in the book is kept to a minimum, and as a result there
is a small amount of repetition, but in general a familiarity with the structure of the
book will aid navigation through it. As stated in the preface, we have tried to only
use plain English in this guide. However, when writing about technical subjects,
there are always going to be words used that the reader is not familiar with. In
these instances we have highlighted the word in blue, and added a deinition in
the glossary.

1.7 Management issues

There are many other factors that an organisation needs to consider that cannot
be covered by this guide, but are fundamental to successful delivery of projects;
these include:

1.7.1 Behaviour and resources

The behaviours within the organisation must allow proper recognition, time
and resource to allow the planning and control processes to happen. Making sure
that there is a development route for project teams such that the organisation/
project has suitably qualiied and experienced people is similarly important.

1.7.2 Processes and tools (scheduling software)

Each organisation must set down its own planning and scheduling processes. As
with all processes, making sure that planning and control processes are audited
to check for appropriate implementation is important. Processes must be robust

7
Planning, Scheduling, Monitoring and Control

enough to deliver the project eficiently, but scaled to suit the size and complexity
of the project as appropriate.
Some research and effort are required to ensure that the tools used and their
coniguration are suitable for the organisation or project and the team who will be
using them. In some industry sectors a big consideration will be client expecta-
tions, and this cannot be ignored.

1.7.3 Common sense

The most important piece of advice of all is to make sure that the guidance in this
book is interpreted with common sense. Any action or process that is established
must be appropriate and must show a beneit that outweighs the cost of its imple-
mentation. This cost is not just in inancial terms, but also in the use of the available
time of the team. Projects of differing complexity will require different imple-
mentations: the highly complex and risky project will require something close to
everything in this guide! A simple project will only need to apply the principles,
often in a very informal way. It is up to the skill and judgement of the organisa-
tion’s senior management to determine what is relevant.

8
 Part One

Deinition
Business case Scope Requirements Stakeholder Project
management management management familiarisation

Chapter 2 Chapter 3 Chapter 4 Chapter 5 Chapter 6

‘The beginning of wisdom is the deinition of terms.’

Socrates
 Business case

Chapter 2

2.1 Deinition of the business case

The business case provides the justiication for undertaking a project, in terms of
evaluating the beneit, cost and risk of alternative options and rationale for the
preferred solution. Its purpose is to obtain management commitment and
approval for investment in the project.
The business case summarises the ‘why’ of the project and should be reviewed
at the start of each project life cycle stage in order to conirm that the project is
achieving its objectives. This is to test the ongoing viability of a project before
proceeding into the next phase of work. It should be read alongside the project
brief (to understand ‘what’ is being delivered), and the project execution plan
(PEP) (to understand ‘how’ the project will be delivered). Alternatively, the
business case may determine that the project is not viable and should not
proceed. The business case is owned by the project sponsor.

2.2 Purpose of a business case

The purpose of generating a business case is to make the case for a particular
project to proceed, and to deine and validate, in broad terms, the constraints
within which it may be delivered. In some cases the outcome of the business case
may be that the proposed project does not proceed. A key part of the business
case is the communication of the resources, commercial strategy and capital
investment necessary to realise the business beneits that the project is due to
deliver.

11
Planning, Scheduling, Monitoring and Control

2.3 Contents of the business case

2.3.1 Structure of the business case
2.3.1.1 Executive summary
This brief introduction to the business case will contain at least the following
sections:

• description of project scope;

• key reasons for proceeding with the project;
• conclusions of cost/beneit study;
• recommended option (assuming a number of options are available);
• outputs: list of key deliverables.

2.3.1.2 Strategic case

This key section describes to the sponsors/stakeholders why the project is
required. It covers the details of the issues to be addressed, or the opportunity
that has arisen.

2.3.1.3 Economic options

There are generally three inancial aspects to be addressed when considering a
new project:

• business as usual: no project to invest in;

• mission critical: deliver absolute minimum of beneits to solve the problem;
• comprehensive change: a decision that will lead to a fully scoped project (or
projects in the case of a change programme).

Each of the economic options must be appraised in terms of costs, beneits, risks
and opportunities. Having considered the options, this section should then
clearly present the recommended option to the sponsors/stakeholders.

2.3.1.4 Beneits: advantages of undertaking the project

The beneits of undertaking the project must be made clear. These may include:

12
 Business case

• return on investment;
• improved productivity;
• lower maintenance costs;
• safer operations;
• providing essential services;
• training for increased productivity;
• enhanced customer experience.

Making the beneits SMART (speciic, measurable, achievable, relevant, time-

bound) will facilitate decision making and, in time, assist with the beneits realisa-
tion analysis.

2.3.1.5 Compromises: disadvantages of undertaking

the project
The compromises that will be required whilst undertaking the project must be
made clear. These may include:

• disruption to the organisation or other stakeholders whilst the project is

undertaken;
• drop in productivity;
• capital expenditure required and/or inancing costs.

Dis-beneits should be analysed as part of the investment appraisal to ensure that

they do not outweigh the expected beneits of the project.
As with the beneits, the compromises that the organisation will have to make
will need to be translated into SMART objectives to aid the decision-making
process.

2.3.1.6 Timescale
Different parts of the business case are emphasised at different life cycle stages:

• initiation stage: consider the different options and include a summary of each
option;
• planning stage: the case must be made for the preferred option, with detailed
costs and beneits for each to clearly show why the preferred option is
recommended;

13
Planning, Scheduling, Monitoring and Control

• execution stage: the project progress is compared with the business case to
ensure that the project continues to deliver the expected beneits, and for an
acceptable cost;
• closeout/handover: comparison between the project outcome and that
deined in the business case. Have the deined beneits of the project been
achieved, or are they going to be achieved?

However, the two key stages are the time over which the project will be run and
the period over which the beneits will be realised. The former is required to
understand cash-low forecasting, periods of disruption etc., and the latter to
facilitate the cost/beneit analysis.

2.3.1.7 Cost and performance analysis

This section contains a comparison of the beneits and dis-beneits compared
with the risks and costs of the project, along with any ongoing operational or
maintenance costs.
Financial commitment across the whole project life cycle needs to be analysed.
This includes:

• project cost, including cash-low forecasts;

• ongoing operations and maintenance costs;
• life cycle revenue;
• one-off and ongoing cost savings;
• value of beneits.

Anything that delivers more savings than it costs will produce a positive net
inancial effect, and this should be quoted with the relevant back-up data.

2.3.1.8 Resources
Ideally, projects should be possible to carry out using existing resources.
Where there are insuficient internal resources to deliver the project, proposals
must be made to either recruit additional, or acquire external, resources to
complete the work. This aspect can clearly have a major impact on the viability
of a project.

14
 Business case

2.3.1.9 Risks and opportunities

Although this is not the main location for communicating or managing risk and
opportunity, it should summarise the impact on value for money and decision
making. It should include:

• a summary of major risks identiied with the project and their likely impact,
including any mitigation plans;
• the inancial provision for risk, including the method for its evaluation;
• the inancial beneits of realising opportunities, including the method for their
evaluation.

Risks and opportunities considered in this section should include risks to cost,
time, health and safety, the environment, reputational damage, the effects on
third parties and so on, as is relevant to the particular sector or organisation.
If the project is considered too risky, then the project sponsor may decide to
not proceed.

2.3.2 Planning information

Planning information is fundamental in informing and validating the business
case, in particular:

2.3.2.1 Strategic it within the business

The plan should demonstrate how the project aligns with the business strategy.
This will highlight potential relationships with other projects, programmes or
portfolios within the business or externally.
Visibility of the bigger picture could identify constraints or issues associated
with resource availability, materials or funds. Just as large national projects like
the building of new nuclear power stations, or upgrading the UK rail network,
can generate shortages within the resource market, the same can happen with
the company’s internal resources.

2.3.2.2 Time assumptions

Time assumptions may be based on benchmark data from similar projects,
or learning from experience. There may be time constraints around funding

15