Planning, Scheduling,

Monitoring and
Control

For use by APM individual and corporate members only

For use by APM individual and corporate members only
 Planning, Scheduling,
Monitoring and
Control
The Practical Project
Management o Time,
Cost and Risk

Association or Project Management

For use by APM individual and corporate members only

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

© Association or Project Management 2015

All rights reserved. No part o this publication may be reproduced, stored in a retrieval system, or
transmitted, in any orm or by any means, without the express permission in writing o the
Association or Project Management. Within the UK exceptions are allowed in respect o any air
dealing or the purposes o research or private study, or criticism or review, as permitted under
the Copyright, Designs and Patents Act, 1988, or in the case o reprographic reproduction in
accordance with the terms o 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 or 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 ReneCatch Limited, Bungay, Suolk
in 11/14pt Foundry Sans

For use by APM individual and corporate members only

 Contents
List o gures and tables xviii
Foreword xxiv
Preace xxvi
Acknowledgements xxviii
Peer review xxx
Purpose xxxi
The PSMC process map xxxii
1 Overview 1
1.1 Part One: Denition 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 sotware) 8
1.7.3 Common sense 8

Part One: Denition 9

2 Business case 11
2.1 Denition o the business case 11
2.2 Purpose o a business case 11
2.3 Contents o the business case 12
2.3.1 Structure o the business case 12
2.3.2 Planning inormation 15
2.3.3 Funding requirements 16
2.3.4 Resource requirements 16
2.4 Acceptance criteria in the business case 16
2.5 Benets realisation in the business case 17
2.6 Procurement strategy 17
2.7 Project review and assurance process o the business case 19

v
For use by APM individual and corporate members only
 Contents

3 Scope management 21
3.1 Denition o scope management 21
3.2 Purpose o scope management 21
3.3 The scope management process 22
3.3.1 Dening the scope 22
3.3.2 Describing the scope 22
4 Requirements management 25
4.1 Denition o requirements management 25
4.2 Purpose o requirements management 25
4.3 Process o dening requirements 25
4.3.1 Requirement description 26
4.3.2 Factors to consider when dening
requirements 26
4.3.3 Inputs into requirements management 27
4.4 The requirements management process 27
4.4.1 Capture and dene requirements rom 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 inormation (WI) 29
4.6 Statement o work (SOW) 30
5 Stakeholder management 31
5.1 Denition o stakeholder management 31
5.2 Purpose o stakeholder management 31
5.3 Managing stakeholders through the project 31
6 Project amiliarisation 33

Part Two: Planning 35

7 Introduction to planning 37
7.1 Denition o planning 37
7.1.1 Denition o the planning role 37
7.2 Purpose o planning 38
7.2.1 Benets o planning 39
7.2.2 Success in planning 40
7.3 The dierence between planning and scheduling 41

vi
For use by APM individual and corporate members only
 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 sotware industry 47
7.6 Planning strategies 49
7.7 Allowing or risk 51
8 Breakdown structures 53
8.1 Denition o breakdown structures 53
8.2 Purpose o 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 Denition o a PBS 57
8.4.3 Purpose o a PBS 57
8.4.4 Constructing a PBS 57
8.5 Work breakdown structure (WBS) 59
8.5.1 Denition o a WBS 59
8.5.2 Purpose o a WBS 59
8.5.3 Constructing a WBS 60
8.5.4 Principles o designing a WBS 60
8.5.5 WBS dictionaries 61
8.6 Organisational breakdown structure (OBS) 64
8.6.1 Denition o an OBS 64
8.6.2 Purpose o an OBS 64
8.6.3 Constructing an OBS 65
8.7 Responsibility assignment matrix (RAM) 65
8.7.1 Denition o a RAM 65
8.7.2 Purpose o a RAM 65
8.7.3 Constructing a RAM 66
8.7.4 The step-by-step approach to constructing
a RAM 67

vii
For use by APM individual and corporate members only
 Contents

8.8 RACI matrix 68

8.8.1 Denition o a RACI matrix 68
8.8.2 Purpose o a RACI matrix 68
8.8.3 Constructing a RACI matrix 68
8.9 Cost breakdown structure (CBS) 69
8.9.1 Denition o a CBS 69
8.9.2 Purpose o a CBS 69
8.10 Resources breakdown structure (RBS) 70
8.10.1 Denition o a RBS 70
8.10.2 Purpose o a RBS 71
9 Dependency management 73
9.1 Denition o dependency management 73
9.2 Purpose o dependency management 73
9.3 Interace scope 74
9.4 Schedule impact 74
10 Health, saety 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 Denition o cost estimating 77
11.2 Purpose o a cost estimate 77
11.3 Cost estimating and the project lie cycle 77
11.4 Estimate types 78
11.4.1 Scope development estimates 78
11.4.2 Other types o estimate 79
11.5 Contents o an estimate 80
11.6 Estimating methodologies 80
11.6.1 Approximate estimating methods 80
11.6.2 Denitive estimating methods 82
12 Budgeting 83
12.1 Denition o budgeting 83
12.2 Purpose o 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-fow statements 84
12.5 Budget transers 87

viii
For use by APM individual and corporate members only
 Contents

Part Three: Scheduling 89

13 Introduction to scheduling 91
13.1 Denition o scheduling 91
13.2 Purpose o 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 (ragnets) 99
14 Types o 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 ‘orecast 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 is’ (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 Denition o schedule design 113
15.2 Purpose o schedule design 113
15.3 Elements o schedule design 113
15.3.1 Activity identity numbers (IDs) 113
15.3.2 Activity descriptions 114
15.3.3 Dierent activity types 115
15.3.4 Activity steps 116
15.3.5 Time units 118

ix
For use by APM individual and corporate members only
 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 Denition o critical path method 121
16.1.2 Purpose o critical path network 121
16.1.3 Methods o 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 o total foat 127
16.1.10 Step 5: Identication o critical path 128
16.1.11 Training in network analysis: a note 130
16.1.12 Float 130
16.1.13 Types o logic linking 132
16.1.14 Lags and leads 135
16.1.15 Use o constraints 136
16.1.16 Types o constraints 138
16.1.17 Displaying networks on bar charts 147
16.2 Estimation o 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 Denition o resources 152
16.3.2 Purpose o resourcing the schedule 152
16.3.3 Process o resourcing the schedule 153
16.3.4 Resource smoothing 154
16.4 Horizontal and vertical integration o schedules 156
16.4.1 Horizontal integration 156
16.4.2 Vertical integration 157

x
For use by APM individual and corporate members only
 Contents

16.5 Scheduling interaces and dependencies 157

16.5.1 Identication 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 Denition o buers 164
16.6.2 Use o buers 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 o balance 172
17.2.1 Creating a line o balance chart 172
17.2.2 Advantages o line o balance 173
17.2.3 Limitations o line o balance 174
17.3 Time chainage 174
17.3.1 Denition o time chainage charts 174
17.3.2 Explanation o the time chainage technique 175
17.3.3 Advantages o time chainage 177
17.3.4 Limitations o time chainage 177
17.4 Schedule narrative 177
17.4.1 Scope 179
17.4.2 Health, saety 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 o any possessions, shut-downs or other
special working conditions 181
17.4.13 Consents required 181
17.4.14 Permits and licences 181

xi
For use by APM individual and corporate members only
 Contents

18 Schedule review 183

18.1 Denition o schedule review 183
18.2 Purpose o schedule review 183
18.3 Checking the schedule 183
18.3.1 Understanding the project schedule 184
18.3.2 Components o 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 o 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 o schedule risk 198
19 BIM (Building inormation modelling) 199
19.1 Denition o BIM 199
19.2 Purpose o BIM 200
19.3 BIM technology 201
19.4 The BIM culture 201
20 Agile 203
20.1 Denition o agile 203
20.2 Purpose o 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 Denition o the project baseline 209

xii
For use by APM individual and corporate members only
 Contents

21.2 Purpose o a project baseline 211

21.3 Principles o project baselining 211
21.4 When to set the baseline 212
21.5 Establishing the baseline schedule 212
21.6 Denition and purpose o baseline maintenance 213
21.6.1 Denition o baseline maintenance 213
21.6.2 Purpose o baseline maintenance 213
21.6.3 Baseline maintenance as a result o schedule changes 213
21.6.4 Illustration o the principle o 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 or schedule maintenance, re-planning and
re-baselining 220
21.10 The link between change management and the project
baseline 220
22 Perormance reporting 221
22.1 Denition o perormance reporting 221
22.2 Purpose o perormance 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 oten is progress recorded? 224
22.4 Variance analysis methods o 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 o balance chart 229
22.4.5 Cash-fow monitoring 230
22.4.6 Resource monitoring 230
22.4.7 Cost value analysis 231
22.4.8 Quantity tracking 231
22.5 Perormance analysis methods o progress monitoring 234
22.5.1 Network analysis and measurement o foat usage 234
22.5.2 Earned value analysis 235

xiii
For use by APM individual and corporate members only
 Contents

23 Cost control 251

23.1 Denition o cost control 251
23.2 Purpose o cost control 251
23.3 The cost control process 252
23.3.1 Perormance measurement baseline (PMB) 252
23.3.2 The link between cost control and change control 252
23.3.3 Perormance measurement 253
23.4 Learning lessons rom cost control 253
24 Short-term planning 255
24.1 Denition o short-term planning 255
24.2 Purpose o 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 Perormance reporting 257
25 Change management 259
25.1 Denition o change management 259
25.2 Purpose o change management 259
25.3 Principles o 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 Drating a change request 263
25.7 The change log 263
25.8 Initial evaluation o the change request 264
25.9 Estimating impact o change 264
25.10 Detailed evaluation o change request 264
25.10.1 Rejected request 265
25.10.2 Deerred request 265
25.11 Approved request 266
25.11.1 Change orders 266
25.11.2 Scope transers 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
For use by APM individual and corporate members only
 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 Denition o risk management 273
26.2 Purpose o 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 identication 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 Denition o QSRA 284
26.6.2 Purpose o QSRA 285
26.6.3 Key requirements or a QSRA 286
26.6.4 The stages o schedule risk analysis 286
26.6.5 Distribution types 288
26.6.6 Application o 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 Denition o QCRA 296
26.7.2 Purpose o QCRA 296
26.7.3 The QCRA process 297
27 Forensic analysis 303
27.1 Denition o orensic analysis 303
27.2 Purpose o orensic analysis 303
27.3 Methods o orensic analysis 303
27.3.1 As-planned versus as-built method (AP v AB) 304

xv
For use by APM individual and corporate members only
 Contents

27.3.2 Impacted as-planned method (IAP) 305

27.3.3 Collapsed as-built method or as-built but
or (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 Denition o record keeping 313
28.2 Purpose o record keeping 313
28.3 How to record 313
28.4 What to record 314
28.5 Methods o keeping records 315
29 Document management 317
29.1 Denition o document management 317
29.2 Purpose o document management 317
29.3 Document control systems 318
29.4 Version control 318
29.5 Handover o documentation 318
30 Handover and closeout 319
30.1 Handover 319
30.1.1 Denition o handover 319
30.1.2 Purpose o the handover process 319
30.1.3 Planning handover 320
30.1.4 Issues in the management o handover 321
30.2 Project closeout 322
30.2.1 Denition o project closeout 322
30.2.2 Purpose o project closeout 322
30.2.3 The project closeout process 322
31 Lessons learned 325
31.1 Denition o lessons learned 325
31.2 Purpose o 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
For use by APM individual and corporate members only
 Contents

The nal word 329

Glossary 331
Acronyms 343
Index 345

xvii
For use by APM individual and corporate members only
 Figures and tables
Figures
1.1 The importance o planning and control in project management 2
3.1 Types and relationships o 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 o breakdown structures repeated 56
8.5 Sample product breakdown structure 58
8.6 Work breakdown structure 59
8.7 Work breakdown structure dictionary (deence) 62
8.8 Work package content sheet (construction) 63
8.9 Organisation breakdown structure 64
8.10 Responsibility assignment matrix 66
8.11 Example o a RACI 69
8.12 Cost breakdown structure 70
11.1 Cost estimating process 78
12.1 Time measured in nancial periods 85
12.2 Generating a cost orecast using a banana curve 86
13.1 The scheduling process in the context o planning, monitoring
and control 94
13.2 Relationship o dierent densities in schedules 97
13.3 A hierarchy o plans and planning documents 98
14.1 Distorting the time/cost/quality triangle 105
14.2 Types o time-phased schedules and their relationship 106
14.3 A sample procurement schedule 108
14.4 Time-phased procurement schedule 110

xviii
For use by APM individual and corporate members only
 Figures and tables

14.5 Design deliverables tracker 111

15.1 Establishing steps/objective criteria 117
15.2 Suitability or steps/objective criteria 117
16.1 Example o the precedence diagram method (PDM) 122
16.2 Example o 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 orward pass calculation 126
16.6 Step 3: The backward pass 127
16.7 Step 4: Calculation o total foat 128
16.8 Step 5: Identication o critical path 129
16.9 Longest path calculations 129
16.10 The alternative method o 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 nish relationship 134
16.15 Start to nish relationship 135
16.16 Summary o types o logic and lags 136
16.17 ‘As late as possible’ constraint 138
16.18 ‘Finish on’ constraint 139
16.19 ‘Finish on or ater’ constraint 140
16.20 ‘Finish on or beore’ constraint 141
16.21 ‘Mandatory nish’ constraint 142
16.22 ‘Mandatory start’ constraint 143
16.23 ‘Start on’ constraint 144
16.24 ‘Start on or ater’ constraint 145
16.25 ‘Start on or beore’ constraint 146
16.26 Bar chart display 147
16.27 Establishing the duration o a task based on resource 153
16.28 First drat resources prole 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 Dierent buer types 165

xix
For use by APM individual and corporate members only
 Figures and tables

17.1 A simple bar chart 168

17.2 Strategic schedule o a major construction project at low density 169
17.3 Using milestones to give clarity to the schedule 171
17.4 Creating a line o balance chart 172
17.5 Optimising work fow in line o balance 173
17.6 Basic elements o 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 o a time chainage diagram or a new railway 178
18.1 Components o a schedule or review 185
18.2 Logic bottleneck 196
19.1 BIM level maturity map 200
20.1 Agile processes 204
20.2 Illustration o an agile methodology using ‘scrums’ and ‘sprints’ 205
21.1 Establishment o baseline 210
21.2 Baseline ater 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 o the drop line method 225
22.2 Simple ‘activity weeks’ monitoring chart 226
22.3 Cumulative results rom the ‘activity weeks’ chart 227
22.4 Recording actual progress in line o 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 perormance chart 245
22.15 Calculating estimated time to completion 246
22.16 Illustration o various earning techniques and appropriate uses 247

xx
For use by APM individual and corporate members only
 Figures and tables

22.17 Advantages and disadvantages o EVTs 248

24.1 Short-term schedules in context o other plans 256
24.2 Perormance analysis on short-term schedule 258
25.1 Process overview: project change control 262
25.2 Example o monthly change reporting 270
25.3 Monthly change report 270
26.1 Risk management lie cycle 275
26.2 Risk identication 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 o basic risk data 281
26.8 Tracking risk perormance over time 282
26.9 Normal distribution curve 288
26.10 Log normal distribution curve 289
26.11 Uniorm 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 o handover and closeout 320
31.1 Example proorma to collect output rates 326

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

xxi
For use by APM individual and corporate members only
 Figures and tables

16.2 Example o PERT calculation 148

16.3 Example o comparative estimates 149
16.4 Example o benchmarked data 149
16.5 Example o resource-dependent estimate 150
16.6 Interace impact schedule 163
21.1 Baseline maintenance, re-planning, re-baselining matrix 219
22.1 Measurement o foat usage 234
25.1 Example o nancial authority 267
26.1 QCRA condence 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 or 306
27.4 Time impact analysis method 307

Picture credits
The ollowing illustrations have been adapted rom 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 ollowing illustrations have been adapted rom originals published by BAE
Systems: Figure 8.7, Figure 17.3
The ollowing illustrations have been adapted rom originals published by Turner
& Townsend: Table 25.1, Figure 25.2, Figure 25.3
Figure 4.1 courtesy o Neil Curtis
Figure 14.4 courtesy o Balour Beatty
Illustration on p. 329 courtesy o Simon Taylor/Paul Kidston
All other illustrations are courtesy o the APM PMC SIG

xxii
For use by APM individual and corporate members only
 ‘Planning is an unnatural process; it is much more un to do
something. The nicest thing about not planning is that ailure comes
as a complete surprise, rather than being preceded by a period o
worry and depression.’
Sir John Harvey Jones

For use by APM individual and corporate members only

 Foreword

Planning has been part o my lie or so many years now. I trained as a mechanical
engineer, and the last assignment o my apprenticeship was within the construc-
tion planning department o British Steel’s piping division (1974 is a long time ago
now, unortunately!). 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, portolio
or business will be delivered.
Sir John Harvey Jones’ quote ‘The nicest thing about not planning is that ailure
comes as a complete surprise, rather than being preceded by a period o 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 i the team involved
had opted or the ‘worry and depression’ this would have prompted action and
led to a more successul outcome.
Fortunately, my involvement in successully delivered projects or programmes
ar outweighs my ailing project experiences, and, when looking back, success
usually comes down to good denition, preparation and planning rom 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 dened timescales under
the highest possible level o public scrutiny.
For these programmes, the creation and maintenance o an integrated suite o
plans/schedules allowing project/programme-level decision making to be
eective was a key part o the delivery success which both commentators at the
time and historians since have recorded.
Now, as a result o the considerable eorts o the APM Planning, Monitoring
and Control (PMC) Specic Interest Group (SIG), organisations and programme/
project teams will have a guide covering all aspects o planning, rom preparing
to undertake a project to executing that project, controlling its sae delivery to
budget, time and quality.

xxiv
For use by APM individual and corporate members only
 Foreword

I believe that this publication has captured the best practices or planning and
will become the reerence document o note or organisations and their teams
during uture project deliveries.

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

xxv
For use by APM individual and corporate members only
 Preace

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’ i 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 o options
and choosing methodologies. This book discusses the art o planning, but places an
emphasis on the scientic side o planning – the processes o scheduling, risk
analysis, management o change (and so on) – in what we hope is a practical manner.
The guide was conceived ater the ormation o the Planning, Monitoring and
Control (PMC) Specic Interest Group (SIG) in late 2010 to ll a gap in published
APM knowledge. It was intended to cover all planning aspects o preparing to
undertake a project, executing a project, controlling its delivery to budget, time
and quality, and delivering it saely. The guide was to be about planning in the
widest sense o the word. Just as with the ormation o the PMC SIG, its aim has
been to bring together dierent project specialisms, rather than ocus on a
particular area o specialist knowledge.
Ater much discussion and debate, a basic structure or the guide was agreed
upon, and content started to be written. By late 2013 a large amount o material
had been gathered but momentum had fagged, so a sub-committee o the SIG
was ormed to pull together all the material and ll the gaps that inevitably still
existed at that point. An intense period o writing and re-writing, as individuals
and as a group, ollowed.

Reading this book

We have covered a lot o material in this book and realise that it may look a
daunting read – but it has been written as a reerence 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 ar as we possibly could,
adopting the ‘Emily test’ to challenge ourselves whenever we slipped into

xxvi
For use by APM individual and corporate members only
 Preace

‘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 drats o this guide or bed-time reading!)
This book has been written entirely by volunteers, giving their own and their
employers’ time reely and willingly or the purpose o advancing and dissemi-
nating knowledge. The eort and time given by the group were well beyond the
call o duty, and I cannot express my gratitude or the amount o time that already
busy individuals were prepared to put into writing and illustrating the guide.
This book may not be perect – 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 eedback and
expertise to strengthen the guide in what we hope will be uture editions in years
to come.

Paul Kidston
Lead author
June 2014

xxvii
For use by APM individual and corporate members only
 Acknowledgements

This guide was discussed, debated and drated over a number o years, but written
and nalised by a small team who ormed a sub-committee o the Association or
Project Management’s Specic Interest Group ‘Planning, Monitoring and Control’,
consisting o:

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

In addition, signicant contributions were made by the ollowing members o the

PMC SIG:

Mike Prescott (Head o project control management,

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

Signicant contributions rom outside the SIG were made by:

Franco Pittoni (Technical director – BIM & Project Controls,

Parsons Brinckerho)
Ewen MacLean (Berkeley Research Group, LLC)

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

xxviii
For use by APM individual and corporate members only
 Acknowledgements

Purser (Capable Consulting, ormerly o BMT Hi-Q Sigma); Deborah Perrin

(Rhead Group, ormerly o Turner & Townsend); Gary Mainwaring (General
Dynamics); Ian Williams (Taylor Woodrow); Jim Malkin (Deltek); Jonathan Crone
(Foster Wheeler, ormerly o 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, ormerly o Keval).
BAE Systems, Taylor Woodrow, BAA (Heathrow Airports Ltd) and Turner &
Townsend provided much source material, or which we are very grateul.
Venues to meet in, lunches and really strong cups o hot tea were provided by
Taylor Woodrow, APM and in particular by TL and Turner & Townsend, both o
whom were particularly generous with their meeting rooms and catering.

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

xxix
For use by APM individual and corporate members only
 Peer review

The guide was widely peer reviewed by people with a wide range o experience
rom outside the SIG, and we are grateul to the ollowing, who provided signi-
cant comments and suggestions:
From the Rhead group, Pete Mill, Steve Higheld, John Nixon and Robin
Smoult; Ben Whitlock (Babcock International Group); James Manthorpe, Louise
Arrowsmith and Sarah Cummins, all o Taylor Woodrow. From the Cross Industry
Planning and Project Controls (CIPPC) group, Mark Singleton (Balour Beatty
Construction Services UK), Franco Pittoni (Parsons Brinkerho) and Phil Budden
(Costain) all provided useul suggestions.

xxx
For use by APM individual and corporate members only
 Purpose

The content o this document identies the scope o planning knowledge as

understood by the Association or Project Management (APM) Planning,
Monitoring and Control (PMC) Specic Interest Group (SIG). This knowledge
was compiled and discussed in a series o working sessions and reviews
commencing in October 2010 and concluding, or publication purposes, in July
2014.
It provides reerence guidance or practitioners and students along with the
study material required or the orthcoming 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 orerunner o the PMC SIG – the Planning
SIG, which did what its title suggested and provided an introduction and a
maniesto or project planning. Although that book explains the need or 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 eedback that may be used in improving uture editions o this
guide, which we hope will ollow and build on this starting point.

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

xxxi
For use by APM individual and corporate members only
For use by APM individual and corporate members only
For use by APM individual and corporate members only
 1

Overview

Eective project management requires eective planning and control. Eective

planning and control requires:

• the clear denition o the project;

• a robust approach to planning the project;
• selection and use o the appropriate scheduling techniques;
• rigorous monitoring that enables proactive control o the project;
• a sound basis or this is good record keeping, which also acilitates the virtuous
eedback and learning cycle.

This book oers tried and tested techniques and principles covering these aspects
o project management. It introduces some lesser-known and emerging practices,
some o which will move into mainstream project management in the years
to come.
The book is structured into ve main sections refecting these requirements,
and a brie introduction to each section and chapter ollows.

1.1 Part One: Denition

At a strategic level, there are a number o undamental questions that need
addressing:

• Why is the project required?

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

Part One o this guide describes the principal processes that dene the project,
and answers these questions.

1
For use by APM individual and corporate members only
 Planning, Scheduling, Monitoring and Control

The rst topic dealt with is the creation o the business case (Chapter 2). This
is the starting point in the lie o any project, and it is a vital step in ensuring that
the project is viable, aordable and desirable. It sets the scene or all that ollows
– the planning, scheduling, monitoring and control, and, not least, the delivery o
the project.
Assuming the business case is approved, the scope o the project must be
dened and agreed with all stakeholders (Chapter 3). Dening the scope will
begin the process o making key decisions about the project, dening and
selecting rom various options until a preerred solution is agreed and approved.
Once the scope has been agreed, the details o the requirements are
determined. See Chapter 4 (Requirements management).
Stakeholder management (Chapter 5) is dealt with briefy, as the responsibility
or this alls mainly on the project manager (see Sot Issues – Project Management
Time in Figure 1.1).
Chapter 6, the nal chapter in Part One (Project amiliarisation), is a checklist
o the project documentation that has been created during the denition 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 inormed way.

Figure 1.1 The importance o planning and control in project management

1.2 Part Two: Planning

The planning phase o the project needs to answer some undamental questions,
such as:

2
For use by APM individual and corporate members only
 Overview

• How much will the project cost?

• How long should the project take?
• Are there benets to nishing early, and what are they?
• What are the costs o an earlier completion, and do they outweigh the benets?
• On the other hand, how is unding released, and are there any limits on this?
• How will the perormance o the project be measured, through all its phases?
• Can the project be delivered saely?

Chapter 7 introduces planning – the team approach to working out how to deliver
the project. Ater discussing and dening the dierence between planning and
scheduling (a point worth making to help dene the two terms) – these terms
are oten used interchangeably, but they are two very dierent processes and
require dierent skill sets – the opening chapter o 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 urther detail
in Part Four.
Chapter 8 denes and discusses the purpose o the various breakdown
structures that are used in project management. We also propose a method o
creating these structures. Chapter 9 introduces the concept o dependency
management. This theme is returned to in Part Four, when the specics o
schedule dependencies are dened in greater detail.
A critical concern o all project management must be the highest standards o
health, saety 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 undamental infuence 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 ollows it. The ormer is an essential step in the denition
and planning (and, indeed, scheduling) o the project. The latter is essential in the
creation o targets and baselines that will orm the basis o monitoring and control.

1.3 Part Three: Scheduling

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

3
For use by APM individual and corporate members only
 Planning, Scheduling, Monitoring and Control

planner’s role is to orm these thoughts into a coherent schedule, and then to
communicate it eectively. This will include:

• developing logistical plans;

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

Part Three commences with a chapter (13) setting the scene; it discusses the
purposes o scheduling and some o the basic philosophies and structures.
Chapter 14 describes the various types and purposes o schedules that might be
used on a project.
Chapter 15, entitled Schedule design, details the various elements o a
schedule that need to be considered prior to commencement o any scheduling:
or example, what type o activity should be used, or what coding and other
structures should be applied.
Chapter 16 addresses the construction o the schedule. It is this guide’s
contention that all scheduling starts with the creation o a logic-linked network.
On simple projects a bar (or Gantt) chart may suce, 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 o considering and scheduling resources, and how schedules are
interaced with other stakeholders.
Chapter 17 ollows with a number o suggestions about how the schedule is
communicated – rom the aorementioned bar charts through to line o balance
and time chainage charts that are useul in particular circumstances. One very
important and sometimes overlooked document is the schedule narrative. This
document serves to explain and clariy the planning and scheduling eort that
has resulted in the (suite o) schedule(s) that have been created. Without this,
the project cannot be clearly understood. We suggest appropriate contents or
this narrative.
The nal part o 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 o who owns the programme, the nal
two chapters o 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 sotware development,
and the building inormation modelling (BIM) approach or use in asset design,

4
For use by APM individual and corporate members only
 Overview

construction and management. The latter is mandated or use in all government
procurement activity rom 2016, so it is very likely to grow in signicance over the
coming years.

1.4 Part Four: Monitoring and control

Once the project is in its delivery phase, there are our undamental questions
that project stakeholders will ask o the project manager:

• Where are we?

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

The rst question (Where are we?) may be decomposed into urther questions
such as: Are we on schedule? I not, where have the delays occurred? What
caused the delay? Who is responsible, and what eect 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 o time
(When are we going to nish?), cost (What is it going to nally cost?) and quality
(Will the nished product do what we intended?). The analysis o current trends
will enable orecasting and/or challenge on these matters.
The ourth and nal question (How can we correct any problems?) also
requires project-specic experience and very oten innovative thinking, topics
that this guide does not, indeed cannot, cover. The monitoring and control
process provides the basis or asking the right questions, and perhaps the basis
or 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 eort and the processes o
monitoring and control. It is, however, a useul introduction to perormance
management, and touches on issues o change and other orms o control that
are dealt with later in this part o the book.
Perormance reporting (Chapter 22) covers the collection o progress and cost
inormation and how this is turned into useul management data. Various

5
For use by APM individual and corporate members only
 Planning, Scheduling, Monitoring and Control

reporting techniques are discussed: rst, variance reports that simply measure
dierences, exposing them (hopeully) to potential management action; second,
a category that we have called ‘perormance analysis methods’ that includes
potentially the most valuable reporting o all, earned value analysis. As stated in
the earlier purpose section o this guide, this book does not supersede the APM’s
own Earned Value Handbook, and readers with a urther interest in this subject
should reer to that guide. However, this guide does cover the basic principles o
earned value.
Cost control is given its own chapter (Chapter 23), and, although it is covered
with some brevity, the undamental principles are discussed.
Ater the project has started, the project needs to react to progress made and
re-plan as necessary. This is oten the driver o short-term planning (although
breaking plans into greater levels o detail (or ‘densities’) is also a unction o
this). In Chapter 24, we outline this process.
Chapters 25 and 26 discuss two processes that will actually be active
throughout the whole lie o the project. The ormer discusses change
management, and the latter gives an overview o risk management. This chapter
provides details o the QSRA and QCRA processes, which are the quantitative
analyses o schedule and cost, respectively (hence the acronyms). These are tools
that check the initial and ongoing robustness o the project plans.
The last chapter in Part Four (Chapter 27) discusses orensic 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 o the
project. It orms both the basis o updating the schedules and plans or perorm-
ance reporting, and to enable orensic analysis should it be necessary. It provides
the basis o much o the learning rom the project that can be used to improve
uture projects. Document management (Chapter 29) ensures that this and all
other relevant project inormation is available to those who need it.
The closely allied (but separate) processes o handover and closeout o the
project are dealt with in Chapter 30. The handover process ensures that the
project and its obligations are complete and signed o; closeout essentially closes
down all the support structures and commercial settlement o the project.
The nal chapter o the book deals with another process that exists throughout
the lie o the project: lessons learned (Chapter 31). This includes both hard and

6
For use by APM individual and corporate members only
 Overview

sot data. An example o the ormer would be productivity outputs achieved; an

example o the latter might be an analysis o 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 acilitate easy
reerencing throughout the book. This is in keeping with the belie that this is a
guide to dip into rather than read cover to cover (although the reader is welcome
to try!). Cross reerencing in the book is kept to a minimum, and as a result there
is a small amount o repetition, but in general a amiliarity with the structure o the
book will aid navigation through it. As stated in the preace, 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 amiliar with. In
these instances we have highlighted the word in blue, and added a denition in
the glossary.

1.7 Management issues

There are many other actors that an organisation needs to consider that cannot
be covered by this guide, but are undamental to successul delivery o 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 or project teams such that the organisation/
project has suitably qualied and experienced people is similarly important.

1.7.2 Processes and tools (scheduling sotware)

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 or appropriate implementation is important. Processes must be robust

7
For use by APM individual and corporate members only
 Planning, Scheduling, Monitoring and Control

enough to deliver the project eciently, but scaled to suit the size and complexity
o the project as appropriate.
Some research and eort are required to ensure that the tools used and their
conguration are suitable or 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 o advice o 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 benet that outweighs the cost o its imple-
mentation. This cost is not just in nancial terms, but also in the use o the available
time o the team. Projects o diering complexity will require dierent 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,
oten in a very inormal way. It is up to the skill and judgement o the organisa-
tion’s senior management to determine what is relevant.

8
For use by APM individual and corporate members only
 Part One

Denition

‘The beginning o wisdom is the denition o terms.’

Socrates

For use by APM individual and corporate members only

For use by APM individual and corporate members only
 2.1 Denition o the business case
The business case provides the justication or undertaking a project, in terms o
evaluating the benet, cost and risk o alternative options and rationale or the
preerred solution. Its purpose is to obtain management commitment and
approval or investment in the project.
The business case summarises the ‘why’ o the project and should be reviewed
at the start o each project lie cycle stage in order to conrm that the project is
achieving its objectives. This is to test the ongoing viability o a project beore
proceeding into the next phase o work. It should be read alongside the project
brie (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 o a business case

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

11
For use by APM individual and corporate members only
 Planning, Scheduling, Monitoring and Control

2.3 Contents o the business case

2.3.1 Structure o the business case
2.3.1.1 Executive summary
This brie introduction to the business case will contain at least the ollowing
sections:

• description o project scope;

• key reasons or proceeding with the project;
• conclusions o cost/benet study;
• recommended option (assuming a number o options are available);
• outputs: list o 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 o the issues to be addressed, or the opportunity
that has arisen.

2.3.1.3 Economic options

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

• business as usual: no project to invest in;

• mission critical: deliver absolute minimum o benets to solve the problem;
• comprehensive change: a decision that will lead to a ully scoped project (or
projects in the case o a change programme).

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

2.3.1.4 Benets: advantages o undertaking the project

The benets o undertaking the project must be made clear. These may include:

12
For use by APM individual and corporate members only
 Business case

• return on investment;
• improved productivity;
• lower maintenance costs;
• saer operations;
• providing essential services;
• training or increased productivity;
• enhanced customer experience.

Making the benets SMART (specic, measurable, achievable, relevant, time-

bound) will acilitate decision making and, in time, assist with the benets realisa-
tion analysis.

2.3.1.5 Compromises: disadvantages o 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 nancing costs.

Dis-benets should be analysed as part o the investment appraisal to ensure that

they do not outweigh the expected benets o the project.
As with the benets, 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
Dierent parts o the business case are emphasised at dierent lie cycle stages:

• initiation stage: consider the dierent options and include a summary o each
option;
• planning stage: the case must be made or the preerred option, with detailed
costs and benets or each to clearly show why the preerred option is
recommended;

13
For use by APM individual and corporate members only
 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 benets, and or an
acceptable cost;
• closeout/handover: comparison between the project outcome and that
dened in the business case. Have the dened benets o 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 benets will be realised. The ormer is required to
understand cash-fow orecasting, periods o disruption etc., and the latter to
acilitate the cost/benet analysis.

2.3.1.7 Cost and perormance analysis

This section contains a comparison o the benets and dis-benets compared
with the risks and costs o the project, along with any ongoing operational or
maintenance costs.
Financial commitment across the whole project lie cycle needs to be analysed.
This includes:

• project cost, including cash-fow orecasts;

• ongoing operations and maintenance costs;
• lie cycle revenue;
• one-o and ongoing cost savings;
• value o benets.

Anything that delivers more savings than it costs will produce a positive net
nancial eect, 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 insucient 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
o a project.

14
For use by APM individual and corporate members only
 Business case

2.3.1.9 Risks and opportunities

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

• a summary o major risks identied with the project and their likely impact,
including any mitigation plans;
• the nancial provision or risk, including the method or its evaluation;
• the nancial benets o realising opportunities, including the method or their
evaluation.

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

2.3.2 Planning inormation

Planning inormation is undamental in inorming and validating the business
case, in particular:

2.3.2.1 Strategic t 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
portolios within the business or externally.
Visibility o the bigger picture could identiy constraints or issues associated
with resource availability, materials or unds. Just as large national projects like
the building o 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 rom similar projects,
or learning rom experience. There may be time constraints around unding

15
For use by APM individual and corporate members only
 Planning, Scheduling, Monitoring and Control

availability that may actor into the business case, such as the ability to
expend money, or other constraints, such as the availability o key resources.
In addition, inormation or inclusion in the business case, such as resource
histograms or high-level schedules, should be provided.

2.3.3 Funding requirements

The business case may need to stipulate when urther unding needs to
be approved – possibly at a key milestone or gateway during the project
lie cycle.
The spend prole o the capital costs may need to be generated rom the
strategic schedule. This would enable the project cash-fow to be determined in
line with the key phases or milestones o the project. In most organisations,
annual spend proles are important or managing the business. This will be used
as part o the nancial planning o the organisation.
The business case should be reviewed regularly until such time as the project
is ‘brought into use’.

2.3.4 Resource requirements

The quantity o resources required and the availability o these resources is
a key actor in determining the viability o undertaking the project. The
capacity to undertake the project internally or the procurement o external
resources must be determined and appropriate options highlighted in the
business case.

2.4 Acceptance criteria in the business case

Acceptance criteria dene how the requirements will be demonstrated to the
customer to determine whether the project is complete. All project outputs must
be delivered t or purpose, to the standards and specication outlined in the
requirements.
Examples o acceptance criteria:

16
For use by APM individual and corporate members only
 Business case

Table 2.1 Examples o requirements and acceptance criteria

Requirement Acceptance criteria

Higher productivity 30% increase in manuacturing output within 3 months

Reduced maintenance Planned preventative maintenance systems available

within 1 month

Increased operational resilience Back-up systems online

The business case may contain a summary list o key project milestones relevant
to stakeholders (acceptance events).

2.5 Benets realisation in the business case

Project success is partially the achievement o requirements and is measured by
meeting the acceptance criteria as identied and agreed in the business case.
However, it is possible to have a successully delivered project that ails to deliver
expected benets, or a project that delivers signicant benets but is considered
a ailure.
Achievement o project requirements and end-user benets needs to be
considered together, because it is the creation and use o deliverables that
produces benets. For this reason, benet realisation measures should be
identied and baseline data should be collected beore implementation begins.
This should be presented alongside the project outcomes.
Business case benets are very theoretical, which is why ‘easy to measure’
statistics should be collected or benet realisation purposes that indicate
whether the theoretical benets have been delivered. The post-implementation
survey is simple and proves whether the benets predicted by the model have
been realised. I not, there may be various reasons or this, and these need to be
analysed and interpreted in a benet realisation review.

2.6 Procurement strategy

Speciying the procurement strategy at the business case stage allows the project
manager to dene the most eective procurement scenario, so establishing a
clear way orward.

17
For use by APM individual and corporate members only
 Planning, Scheduling, Monitoring and Control

The procurement strategy should consider the ollowing, but these will dier
rom organisation to organisation:

• Funding processes: how will unding be obtained or the project, and what
type o approvals will be required and when?
• Contract procurement ramework: will the project require new procurement
(because o the size, complexity or specialist nature o the project), or will an
existing ramework o suppliers be used?
• Contracting strategy: what type o contracts will be used?
• Financing constraints: are there any constraints on the nancing o the project?
I so, cash-fow orecasting may be required, as will the introduction o
spending caps.
• Risk and contingency processes: how will the project obtain and draw down
(allocate) risk and contingency monies?
• Security issues: sensitivity o inormation and security concerns will infuence
the procurement strategy. Security around intellectual property rights may be
a concern.

The business case should dene how the scope o the project will be
procured. For example, i the business need is or a rapid delivery o the
project it may be appropriate to select the shortest procurement route, single
source procurement, existing supply chain ramework, as opposed to
competitive tender.
The commercial project manager or project procurement proessional should
both have input into the business case and understand it. Much o the activity
associated with developing the business case will typically be undertaken as part
o the wider project management process. However, i large or key elements o
the project are likely to be sourced rom outside the customer, the role o
procurement is to provide support and inormation, so that inormed early
decisions, even i only ‘in principle’, can be taken.
Project managers must understand the development o the project procurement
strategy in terms o how to break a project down into packages o work, and what
actors to consider when giving direction on how individual providers will be
selected, paid and rewarded, risks allocated, etc. Investing time in developing the
strategy both increases the likelihood o the individual packages being successul
and, more importantly, allows the business to review how the packages t together
to deliver the overall benets.

18
For use by APM individual and corporate members only
 Business case

2.7 Project review and assurance process

o the business case
The business case may be periodically reviewed to ensure that the project is on
track to deliver the business benets, and that the project is still easible. These
reviews will take place throughout the project lie cycle, and additional reviews
will take place ollowing handover and closeout to ensure that the benets are
being realised by the organisation.

19
For use by APM individual and corporate members only
For use by APM individual and corporate members only
 Scope and requirements denition are the processes that ensure the project
includes all the work required to complete it, and then dene that work. They
dene the structures that enable the planning, scheduling and budgeting
exercises to be undertaken in a structured manner. This will acilitate the control
o the project as it enters its execution phases.
The management o scope should rigorously prevent ‘scope creep’. This is the
colloquial term given to any scope that is added or undertaken which is not
validated and authorised via the project’s scope denition or change control
process.
These processes control how the project scope is developed and veried.
They clearly dene who is responsible or managing the project’s scope and act
as a guide or controlling the scope.

3.1 Denition o scope management

Scope denition is the process o developing the description o the project and
its deliverables.

3.2 Purpose o scope management

Scope management should ensure that all work that is specied, and later done,
is related to the project objectives. It is also important to clearly establish what is
excluded rom the project scope. The business plan will dene the breadth o the
project scope.

21
For use by APM individual and corporate members only
 Planning, Scheduling, Monitoring and Control

3.3 The scope management process

3.3.1 Dening the scope
The initial part o the process denes the requirements o the project. This will
include discussion with a range o stakeholders, such as potential suppliers, to
determine what is possible, research and development areas, policy, legal and
more. To do this, the ollowing techniques can be used:

• build method;
• brainstorming;
• accurate/agreed requirement setting and capture;
• stakeholder/end-user management (interviews, analysis);
• key assumptions management (creating an assumptions list);
• product analysis;
• options analysis;
• acilitated workshops.

The project manager is responsible or carrying out renement and agreement o
the scope with the project executive, sponsor, programme manager, end-user
and other key stakeholders to ensure that the project delivers a relevant and
appropriate solution. It is essential that these key individuals sign up to their
agreement o scope and that this is recorded in the project management plan.
Once the scope has been agreed it should be put under a ormal change
control process, as scope creep and uncontrolled change are common causes o
project ailure.

3.3.2 Describing the scope

When a solution has been identied that meets the stakeholders’ criteria and
requirements, the scope o work is divided into various hierarchical breakdown
structures (see Figure 3.1). These may include:

• Product breakdown structure (PBS): Whilst not all industries and sectors
will use a PBS, it can be used as an interim step towards generating a WBS. It
is developed at the start o the project when the product or outcomes have
been scoped and agreed. The PBS breaks down all necessary outcomes o
a project.

22
For use by APM individual and corporate members only
 Scope management

Figure 3.1 Types and relationships o breakdown structures

23
For use by APM individual and corporate members only
 Planning, Scheduling, Monitoring and Control

• Work breakdown structure (WBS): The WBS breaks down or groups all
activities within a project. A WBS can be urther broken down into work
packages and planning packages.
• Organisation breakdown structure (OBS): This is a hierarchical structure
showing organisational accountability or the project and does not need to
refect the organisational structure o the company, just the project accountab-
ility. The OBS is dened down to the level o management control required in
the WBS. Roles are usually used in the OBS rather than names (e.g. engineer-
ing manager).
• Responsibility assignment matrix (RAM): The RAM designates the responsib-
ility o work packages to a team or individual. The RAM is a cross-reerence o
the WBS and OBS.
• Cost breakdown structure (CBS): The CBS provides a nancial view o
the project and splits the project scope into its individual cost components.
The CBS oten highlights any nancial coding used or the business accounting
system and any booking codes associated with each element o the project.
• Resource breakdown structure (RBS): The RBS organises the project
resources in a hierarchical list that is used to plan and control the project. The
structure is not usually identical to the CBS, but there will be a relationship
between them.

Breakdown structures are dealt with in greater detail in Chapter 8.

To summarise: a PBS tells you what the product is; the WBS tells you about
not only the product but the supporting services and how you deliver them; the
OBS tells you who has project accountability or elements o the WBS; the RAM
shows you the control points or management; the CBS records the costs; and
the RBS denes the type o resource and resources on the project.

24
For use by APM individual and corporate members only
 4.1 Denition o requirements management
Requirements management is the process o capturing, assessing and justiying
stakeholders’ wants and needs.
It requires the capture o requirements via a structured process. This process
should incrementally break down the requirements in a hierarchical manner,
considering dierent conditions and scenarios. The requirements, once dened,
must be validated with the project sponsor and/or key stakeholders to ensure the
ull scope has been captured.
Requirements management is an ongoing process that is maintained
throughout the project lie cycle.

4.2 Purpose o requirements management

These requirements become the principal project deliverables. Thus, it helps to
dene the project scope. This allows the project team to understand the exact
deliverables o the project and how the work will be structured to meet the
requirements and deliver the scope.

4.3 Process o dening requirements

Once the initial identication o requirements has been undertaken, system
analysis can then be undertaken, looking at each requirement in turn and

25
For use by APM individual and corporate members only
 Planning, Scheduling, Monitoring and Control

analysing the risks, assumptions, interaces, dependencies, opportunities and

constraints associated with the requirement. This then allows the design and
build phase o the project, which is oten the ‘implementation’ phase o the
project lie cycle.
Ideally, each phase would be completed prior to the next starting, but in reality
this process is oten iterative and cyclical, with requirements being continually
analysed and evaluated whilst the design is being nalised and build has
commenced.

4.3.1 Requirement description

A requirement must be described in such a way that it meets the ollowing
criteria:

• It is up to date (e.g. with regard to latest technology or to latest legislation).

• It is relevant to the sponsoring organisations and benets.
• It does not contradict any other requirement.
• It is concisely, but precisely, described, so that it is not open to dierent inter-
pretations.
• Its achievement can be demonstrated.
• It can be traced rom the operating need o the organisation, through the plan,
to what is delivered.
• Its relative importance in relation to other requirements is understood.
• It can be linked to the product breakdown structure/work breakdown structure
and activities in the project, or example by using activity coding.

Satisying all project requirements equates to the completion o the project.

4.3.2 Factors to consider when dening

requirements
When dening requirements, it is important to consider what the acceptance
criteria will be and how these will be dened. It may be useul to examine
requirements and acceptance criteria used or previous projects o a similar
nature.
It is important to take standards, legal acts and regulations to be complied with
into account when requirements are dened.

26
For use by APM individual and corporate members only
 Requirements management

4.3.3 Inputs into requirements management

• Mature business case.
• Contractual documentation containing requirements where applicable.
• The current list o project assumptions and constraints.
• Initial risk register.
• Current statement o work.
• Project execution plan.
• Supporting management plans, including benets, quality and risk.
• Applicable standards.

4.4 The requirements management process

4.4.1 Capture and dene requirements rom all stakeholders
• Dening requirements requires the identication o all stakeholders, then
obtaining and documenting their requirements. The documentation should
list all assumptions, exclusions and constraints and the acceptance, handover
and closeout criteria. When dening the requirements, it is important to distin-
guish wants rom needs.
• Identiy the sources o the requirements. One requirement may have multiple
sources, but it is important to identiy the owner(s) o each requirement. The
owner(s) will need to understand each o the sources’ views on assumptions,
exclusions and constraints, so that a common understanding o the require-
ment can be met by means agreed with all stakeholders.
• Capture any dependencies between those requirements within the scope o
work and those at the strategic, programme/portolio level where this applies.
Consider horizontal linkage o requirements between projects, plus those
requirements/constraints that have an interace/dependency with existing
ongoing activities.

4.4.2 Link requirements to the product breakdown structures

and work breakdown structures where appropriate
• Identiy and dene the individual elements o each user/customer require-
ment that can be linked to individual elements o the supplier’s system
requirements document (SRD), which in turn link to individual elements o

27
For use by APM individual and corporate members only
 Planning, Scheduling, Monitoring and Control

the technical specication, which link to individual elements o the work

breakdown structure and the associated statement o work.
• Each product described by the WBS should satisy an element o the require-
ments.
• The levels o traceability between requirements models must be determined
in order to allow or planning the resources and schedule implications or
managing requirements.
• The system requirements drive the work to be completed within the system
design process and subsequent subsystem and component design, so the link
between the system requirement structure and the work breakdown structure
must be established.

4.4.3 Decompose requirements

Requirements are decomposed into capabilities, eatures or attributes o the
project’s deliverables at a sucient level o detail to allow verication and
validation (see Figure 4.1).
Once requirements are dened, the acceptance criteria or each requirement
should be approved by the customer. The method o verication or the criteria

Figure 4.1 Design and development V Model

28
For use by APM individual and corporate members only
 Requirements management

should also be agreed upon. This could include analysis, inspection, demonstra-
tion or test, or simulation. A clearly dened requirement increases the chances o
the project sponsor being able to make a clear decision regarding acceptance
ater completion.
Requirements may be traded where appropriate, to balance time, cost, quality
and saety parameters within the scope o work, using an approved change
control process.
Once requirements have been clearly dened and agreed, they should be
clearly documented, and the strategy or the delivery o the requirements should
be detailed within the PEP and the schedule.
The requirements should be baselined beore commencing the design and
delivery process.
There are a number o design approaches, but or the majority o projects a
validation and verication requirements matrix (VVRM) is a useul model to map
the user requirements and system design, in order to acilitate the project
assurance process; compliance with requirements may be achieved by linking
the VVRM to tests, trials, demonstration, analysis and inspections within the
relevant plan and then to the project schedule.
Key review points should be identied (or example preliminary design review,
critical design review), where certain requirements must be met beore the
project proceeds urther. At these reviews, requirements and acceptance criteria
should be validated prior to testing to ensure that they are still appropriate. I not,
they can be amended through the relevant change process.
The VVRM should be updated as requirements are met through their
acceptance criteria.
Handover and closeout o all requirements and assumptions should be
captured in a ormal acceptance process

4.5 Works inormation (WI)

The works inormation is split into two parts: employers and suppliers.
Employers’ inormation species the works to be carried out by the supplier,
including technical inormation specications, system requirements, drawings,
and any constraints relating to the supplier, e.g. saety requirements, consents
required, etc.
Suppliers will respond with details o how they propose to deliver the works
in line with the customers’ requirements unless agreed otherwise. In some

29
For use by APM individual and corporate members only
 Planning, Scheduling, Monitoring and Control

industries, the suppliers’ response is known as the statement o work, as distinct

rom the works inormation.
Each works inormation item must be linked to the ormal requirement that
generates it. This is to ensure that scope creep is not generated by the creation o
the works inormation (or, indeed, that scope gaps do not appear).
The schedule must contain all the works identied in the works inormation.

4.6 Statement o work (SOW)

A statement o work (SOW) explains in clear language the customer’s needs and
requirements, and is thereore oten initially drated at the bid stage o a project
by the customer to acilitate the preparation o proposals rom multiple potential
contractors. It is oten developed in line with the business case, and the SOW
will then orm the basis o contractor selection and contract administration.
The SOW denes all the work that is required to be undertaken in order to
develop or produce the outputs o the project, along with work perormance
requirements or the project (e.g. service levels, minimum down-time, specica-
tions o building saety, structure, size, etc.). It includes qualitative and quantitative
design and perormance requirements that can be measured to determine project
success.
Once a contract has been awarded to a supplier and a project commences, the
project team oten breaks the top-level SOW into individual or work package
SOWs, creating a more detailed and lower-level WBS structure than that which
was submitted at bid stage. This acilitates clearer denition o the work packages,
as the SOW requirements can be traced throughout the WBS structure, and
ownership can be clearly assigned to the work packages.
Relevant parts o the SOWs which are reerenced in a WBS dictionary
are then considered alongside the constraints, risks, assumptions, interaces,
dependencies and opportunities. This produces the scope baseline or the
project team to estimate work schedules and costs. As schedules are worked up,
the basis o estimates or duration o activities and cost estimates is recorded or
both project audit purposes, and schedule and cost risk assessment activities.

30
For use by APM individual and corporate members only
 5.1 Denition o stakeholder management
Stakeholders are the organisations or people who have an interest or role in the
project, or are impacted by it. Stakeholder management is the ormal management
o these interests, including the management o the relationships and monitoring
the delivery o commitments made to the stakeholders.

5.2 Purpose o stakeholder management

Stakeholders have a key role in setting the criteria used to dene the success o
the project, and their involvement should not be overlooked. Managing stake-
holders can make the dierence between success and ailure o a project, and as
such should eature highly on the list o priorities and be treated with appropriate
gravity. Whilst the planner assists with this process, the main responsibility or
managing the stakeholders lies with the project manager.

5.3 Managing stakeholders through

the project
Setting the scope will include discussion with a range o stakeholders, such as
potential suppliers, to determine what is possible, research and development
areas, policy, legal and more. The project manager is responsible or carrying out
renement and agreement o the scope with the project sponsor, programme
manager, end-user and other key stakeholders to ensure that the project delivers

31
For use by APM individual and corporate members only
 Planning, Scheduling, Monitoring and Control

a relevant and appropriate solution. It is essential that these key individuals sign
up to their agreement o scope and that this is retained or record purposes.
Stakeholders must be identied, their level o interest and power to infuence
the project analysed, and plans devised or their management. Stakeholder
management is an iterative process which starts during project concept.
Stakeholders should be managed to ensure that a positive relationship with
the project is built and maintained.
Stakeholder management becomes more complex when stakeholders’ views
are not consistent throughout the lie cycle o the project as changes occur in
their opinions, roles and views regarding the project.
The project’s communication plan should be employed as a tool or stakeholder
management. It may include who the stakeholders are and their communication
needs, and who is responsible or their management and planned responses.
Stakeholder management needs to consider interaces with third parties or
outside infuences.

32
For use by APM individual and corporate members only
 When approaching the planning o a project, it is important to gain a wide appre-
ciation o important actors that may infuence the project’s success, its approach
or its complexity. Although a planner will not be expected to know the nite
technical detail o the project, planners should have an appreciation o each
element o the project. Areas where the project team typically may need to gain
a high level o understanding are listed in Table 6.1.

Table 6.1 Sources o project inormation

Document or source Example o inormation

Business case • Key dates or unding approval

The contract, especially identied • Key dates, contract dates, risk ownership,
risks and key deliverables restrictions, limitations on working conditions,
and any other requirements

Customers’ requirements • Processes to ollow, may include delivery

implications and handover or hand-back regimes

Drawings • Scope, implied methodologies

Specications • Standards, methodologies

Previous stage schedules • Key interaces with earlier phases

Meetings, workshops • Insight into the project, in particular the drivers,

output rates and methodologies

Stakeholders • Who are the ‘key players’ that will impact the
success or ailure o the project? How does this
infuence the plans?
(Continued)

33
For use by APM individual and corporate members only
 Planning, Scheduling, Monitoring and Control

Table 6.1 Continued

Document or source Example o inormation

Stakeholders (cont.) • Legal agreements with third parties (party wall

agreements; intellectual property rights)

External interaces, i.e. those that • Supply o critical resources, e.g. utilities,
will not be covered by the project power supply
schedule

Benchmark data – output or • Reer back to previous similar jobs/projects and

productivity guides use realistic durations in the new schedule

Cost estimates • Scope verication

• Identiy provisional sums

• Basis or budget loading o the schedule

Industry specic • Soil investigation reports, site visits, weather

records or construction

• Planned closures to enable works

• Capability requirements in deence

Previous projects o a similar nature • Methods, durations and benchmarking data

Lead-in times • Investigate any materials that are known to have

long procurement times, e.g. lits or escalators,
government-urnished equipment

Available resource • Check that there are no specialist resources

required that may be in short supply, e.g.
signalling engineers or rail projects

Gateways and stage approvals • Critical to a lot o projects. Find out what
approval stages are required, e.g. or design
or unding

Limitations imposed by relevant • Saety legislation

legislation
• Security clearances required

34
For use by APM individual and corporate members only
 Part Two

Planning

‘Failing to plan is planning to ail.’

Alan Lakein

For use by APM individual and corporate members only

For use by APM individual and corporate members only
 7.1 Denition o planning
Planning is the process o identiying the methods, resources and activities
necessary to accomplish the project’s objectives. It achieves this by drawing on
the expertise, experience and knowledge o organisations and individuals
(including the lessons that it has learned rom previous projects), and on external
parties i appropriate, in order to:

• understand the need, problem or opportunity that the project will address and
the benets that it will deliver;
• dene what has to be accomplished and delivered, typically stated in terms o
scope, time, budgets and quality;
• develop a plan to deliver the project.

Planning is the activity o determining how raw materials and other resources are
delivered into a desired outcome. It is also the process that will deliver a compet-
itive edge to organisations competing to win contracts to deliver work.

7.1.1 Denition o the planning role

Planning is an art rather than a science; it is based on experience, industry or
sector knowledge and technical skill, and a key ingredient is innovative thinking.
Planning is the activity o a team working together to determine the strategy or
delivering the project. To achieve this, the project team determines the method
or methods that will be used to deliver the project as well as how the project is to
be procured.

37
For use by APM individual and corporate members only
 Planning, Scheduling, Monitoring and Control

The best plans will be created by a team o project managers, engineers,

production/design managers and commercial managers working together.
Specialist planners may guide and acilitate the process. In principle, planning is
an activity that precedes scheduling.
During the planning process, the main interaces will be identied. It is
important that during this process the assumptions made, the risks, opportunities
and issues are identied and recorded.
At the planning stage o the project, it is important that the project control and
reporting methodologies that will be used are dened so that decisions around
the methods o planning eort and toolsets adopted will be adequate.
The outputs o planning are thereore:

• overall strategy or the project;

• overall methodology or the project;
• breakdown structures or managing the project;
• the identication o key dependencies;
• contributions to the project risk and opportunities register and issues log;
• the identication o interaces.

7.2 Purpose o planning

Planning is used to determine how, when and which project deliverables must
be achieved in order to deliver the products (or actions) needed or the
project’s success. This includes recording any organisational or management
approaches and processes that will be used. The planning discipline assesses
how and when activities need to take place and denes the acceptable standard
required or completion, as well as balancing standards and targets within
agreed time, cost and quality parameters. The management approach inorma-
tion will be recorded within the project management plan (PMP) – also known
as the project execution plan (PEP) – and the relevant timings or the
activities identied will be recorded within a project schedule, included within
the PMP/PEP.
Planning enables the project manager and their team to determine what
methods and techniques they intend to use to deliver the required outputs,
products and activities. Adding the activities to a schedule helps to understand
the logical relationships between activities, the impact on resource distribution,
the expenditure prole and reporting implications. In a well-planned project,

38
For use by APM individual and corporate members only
 Introduction to planning

the means o achieving the well-dened outputs, to an agreed standard, have

been examined, thought about, optimised and recorded, and are regularly
reviewed.
Planning and scheduling are essential to the authorisation o the project
delivery stages. Without a robust and realistic PMP and schedule, advancement
through the project stages should not be approved. The approval at each stage
will look closely at the plan and schedule and consider whether the project is on
course to deliver its intended business benets in accordance with the business
case.
Once agreed and authorised, plans and schedules are an essential mechanism
or communicating the project strategy and the deployment and tasking o sta,
contractors and other resources.

7.2.1 Benets o planning

• A well-planned project will identiy and document the right activities and
products to achieve the outputs and will secure the optimum resource level to
support this.
• Planning determines what activities and products need to be carried out,
when, to what standard and using which resources, including monetary unds.
Well-planned projects, where the tasks that need to be undertaken, how and
when have been careully considered, are much more likely to successully
deliver desired outcomes.
• Comprehensive scheduling ensures the optimal allocation and release o
resource and the eective control o project activities within time constraints.
• Planning is central to the control o the project and early identication o where
the project might be starting to ail.
• Planning is an integral part o problem solving at all stages o the project.
• The project schedule, risk and budget are used to orm a baseline against
which the position o the project in terms o cost, time and risk, and thereore
the perormance o the project, can be managed.
• Establishing a baseline enables the project team to check the progress o
the project, to measure success, and to identiy and assess the impact o
deviation rom the baseline. Early identication o deviation will allow the
maximum time or corrective action and assessment o impact on other
planned activities.
• With good planning, it is possible to predict whether the project remains on
target to deliver its outputs within the time, cost or perormance constraints.

39
For use by APM individual and corporate members only
 Planning, Scheduling, Monitoring and Control

• Above all, planning is about communicating the sequence, method and time
required to complete the project deliverables.

7.2.2 Success in planning

There are a number o key themes that are required or planning to be a success;
the key considerations are:

• Ensure that the planning exercise is properly led, and that all input rom the
project team and other stakeholders is considered, reviewed and included as
appropriate. This should assist in achieving buy-in o the project team. Planning
should never be an isolated exercise.
• Ensure that the right people are made available to contribute to the planning
process in the manner described above.
• Ensure that a structured approach is taken, so that the ull scope o the project
is planned and that it ties back to all the contractual requirements.
• Ensure that adequate time is allowed to undertake the planning exercise.
• Ensure that there is proper understanding o the scope and all commitments,
and that, during the planning exercise, all dependencies are identied and
described and all interaces are understood.
• Ensure all assumptions are dened, documented and taken into account.
• Ensure that adequate scheduling resources such as people and inormation
(e.g. estimating norms), along with an adequate project controls system, are
available to convert the planning exercises into understandable schedules,
reports and other documentation.
• Planning and control systems will always ail i the human actors are
ignored.
• Ensure that the scheduling disciplines discussed in this guide are applied by
the scheduler(s) to clearly dene, describe and communicate the plan, both in
terms o clarity and in terms o appropriate distribution. In practice, no one
technique will likely give a denitive answer in terms o both planning and
control. Good practices are set up by careul selection o the right tools or the
project.
• Ensure that all actors surrounding the project are taken into account. This will
include logistics planning, stakeholder management and the availability o
suitably trained and numerous resources.
• Ensure all project risks are understood and taken into account, and that any
identied risk mitigations are included in the schedule.

40
For use by APM individual and corporate members only
 Introduction to planning

7.3 The dierence between planning

and scheduling
Planning and scheduling are closely related subjects, but they are completely
separate processes; however, the terms are oten used as i they were inter-
changeable. To add to the conusion, many schedulers have been given role titles
that include the word ‘planning’. Planners may have both skill sets, but it is
important to be aware o, and or this guide to dene, the dierence between the
two roles.
Whereas planning has to be done well in order to dene the best solution to
deliver the project, scheduling needs to be done well to determine the project
parameters: how long the project will take to complete, or example. Furthermore,
it must be done well to communicate the project clearly and precisely. It can then
orm a sound oundation or project control.
Scheduling is more o a science compared with the art o planning; it usually
involves the input o planning inormation into scheduling sotware. Scheduling
uses the WBS as the ramework on which to build all the project activities. It
calculates the dates rom the activity/task durations and determines the resources
required. It also denes the logical sequence o activities and calculates the
critical path (the path or chain o activities which, i delayed, will cause a corres-
ponding delay to the overall project completion date). In this process it computes
the start and nish dates and identies the foat on all the activities. The nal
outcome o this process is to determine the easibility o delivering the project to
the required completion dates.
At the outset o a project, planning is the art o deciding the best strategy or
designing a project, implementing a project and bringing a project into use. The
key to good planning is eective communication o the strategy and method(s)
that are decided upon as the most ecient way to deliver the project. Thus, it is
about:

• dening requirements, scope, purpose and objectives;

• dening methodology;
• denition o deliverables;
• clarity o organisation and organisational responsibility;
• the identication and management o risk – both threats and opportunities;
• supporting the business case to gain unding;
• getting agreement o all stakeholders in the project;

41
For use by APM individual and corporate members only
 Planning, Scheduling, Monitoring and Control

• dening constraints;
• establishing priorities;
• dening and documenting assumptions.

A key part o planning is creating the project schedule. (This is oten reerred to
as the programme, but, in order to avoid conusion with programmes o work
and other uses o the word ‘programme’, it is common to use the term ‘schedule’,
and this guide uses this convention.)

7.4 Principal scheduling components

7.4.1 Process step schedules
The schedule will usually be presented in a graphical ormat. The schedule should
have enough inormation in it to manage the project and accurately model the
impact o change and progress. Inormation that can be held in a separate tracker
should not be included in the schedule. Examples o separate trackers include:

• design deliverable schedules;

• method statement schedules;
• consents trackers;
• handover or hand-back trackers (also known as interaces);
• approval chains (managed by specialist resource – the details o testing and
commissioning, or example).

Collectively, these documents do all orm part o the schedule, and links between
these documents and the master/working schedule must be actively managed
and updated.
It is not useul to manage all this in the specialist scheduling sotware, because
it increases the size o the schedule to less manageable proportions (it is likely to
be a high-density level o detail). It would also make it harder or the project
manager to access the data, thus detracting rom the main purpose o the schedule.

7.4.2 Time-based schedules

It is almost certain that, or any project o complexity, the schedule will be
contained in specialist scheduling sotware. This may include Gantt charts, time

42
For use by APM individual and corporate members only
 Introduction to planning

chainage charts, line o balance graphs, etc. – these are dynamic, logic-linked,
usually critical path views o the schedule or the physical and deliverable works.

7.4.3 Schedule narrative

A schedule narrative (sometimes known as the planning method statement) will
be required to accompany a schedule o medium to high complexity, to explain,
illuminate and communicate methodology, timing, and the risks and constraints
on the schedule. It should give a clear understanding to both project and
non-project team members o the way the work has been planned and scheduled,
with associated assumptions.

7.5 Approaches to planning

7.5.1 Top-down planning
Top-down planning describes an approach that starts with strategic planning o a
project and is worked into greater detail (and certainty) in parallel with the
commencement o the project. Top-down planning is ‘events’ ocused. It denes
a period o time/work leading up to a key event that occurs at the culmination o
a number o project activities – or example, a preliminary design review, which
is an ‘event’ that has much activity leading up to it, and eectively validates that
work, thus making it an important ‘event’.
Typically, this top-down approach will dene the overall project lie cycle
along with key events that will need to happen in order to achieve each
gate review. As the top-down plan is more requirements driven and needs
driven, it tends not to be date ocused, and works instead on establishing the
essential logic fows and sequences required or the successul completion o
the project.
Bottom-up planning then complements this approach by validating the eort
and duration required to deliver the requirements on the project, and should
result in a resource-driven schedule showing the project dates by which key
events can be met. Oten, there is then a rationalisation period whereby the
bottom-up and the top-down plans are aligned and trades in time, cost or quality
are made to ensure that the project can be delivered to the timescales, cost or
quality standards outlined by the customer.
See Figure 7.1 or a comparison o top-down and bottom-up planning.

43
For use by APM individual and corporate members only
 Planning, Scheduling, Monitoring and Control

Figure 7.1 Top-down vs. bottom-up planning

7.5.2 Bottom-up planning

Where ull details o the scope o work are known, a detailed schedule can be
produced, starting at the lowest level and usually measured in days. This is
typically a high-density schedule, and would be one o the more detailed planning
outputs. Fully logic-linked and usually held in a scheduling sotware tool, this
approach can be eectively utilised through collaborative planning techniques.

7.5.2.1 Collaborative planning

‘Collaborative planning’ is a technique that ensures that all key stakeholders are
actively involved in the bottom-up planning o a project, and promotes team
‘buy-in’ to the schedule and planning strategy. It is usually undertaken via a acil-
itated workshop, whereby the acilitator will help to guide the team to create a
bottom-up schedule o activities required to successully reach an agreed
end-point. There are multiple ways o acilitating planning workshops – one
eective approach is or all o the team to create task names on sticky notes,
which are then categorised and reviewed. Logic, durations, resources and any
constraints are then discussed and agreed until a ully logic-linked schedule has
been created. This approach takes a number o iterations; however, it should
oster a collaborative approach and help to ensure that all team members are ully
engaged in the planning process.

44
For use by APM individual and corporate members only
 Introduction to planning

7.5.2.2 Summarising the output

Once this higher-density schedule has been created, the detail is then summarised
into larger sections such as design, procurement and construction. These items
cover weeks or months. This provides a view o the project useul or brieng
new team members, senior management, executives and/or the customer.

7.5.2.3 Rolling wave planning

I the plan, and hence the schedule, is created once all the design is complete,
ater all contractors and sub-contractors are appointed, and ater all methodolo-
gies have been agreed, then the creation o a ully detailed, budgeted and
resourced schedule will be achievable at the outset o a project. I, however,
some or all o these are not in place, some orm o rolling wave planning is
required. A rolling wave approach can also be adopted or highly complex
projects, where there is a high risk o change, and/or a project spans multiple
years (e.g. a deence build project), or where there is a reasonable degree o
uncertainty in the project.
Rolling wave planning describes the scheduling density that is achieved at
dierent moments in time. Figure 7.2 shows a typical schedule in terms o its
current state o development. The project is broken down into ‘waves’, which are
typically anchored to key gate reviews or signicant events in the project. The
project then uses the top-down plan and systematically plans each wave to an
increasing level o granularity, starting with a high-density schedule upront in
the rst wave, and gradually reducing the level o density and hence the
requirement to ully dene details which may not be ully available to the project
until a later date.
In large-scale, long-duration projects, it may not be easible to structure the
rolling waves according to gate reviews, as these may be many years apart.
Where this is the case, the project may choose interim milestones or deliverables
by which the rolling waves should be completed, or, alternatively, may choose a
set number o periods o time (e.g. months) which should have a detailed plan
(typically 3–6 months). Where such an approach is taken, tasks and work
packages should always be ully planned out to their natural conclusion,
irrespective o the ‘cut-o’ o the rolling wave.
As the project moves nearer to the end o the rst phase, the second phase
will be planned to a higher level o density and detail, as the project team will
have more inormation available than at project inception.

45
For use by APM individual and corporate members only
 Planning, Scheduling, Monitoring and Control

Figure 7.2 Rolling wave planning

It should be noted that each wave end-point is a guide, and, when scheduling
out work, each work package should be planned to its natural conclusion, rather
than cut at a specic point in time to meet the wave end date. The waves may
relate to phases o the project as shown in the illustration above.

7.5.2.3.1 Advantages o rolling wave planning

• It allows an incremental approach to planning high-density detail, to allow
project ‘unknowns’ to be resolved over time rather than at project inception.
• It reduces the level o upront planning eort required.
• It is suitable or projects with changing or emerging scope, as scope can be
added or removed rom uture waves in a controlled way.
• It allows management o an uncertain schedule.

7.5.2.3.2 Limitations o rolling wave planning

• Eort to plan next rolling wave may divert critical resources rom schedule
delivery tasks i not planned correctly and incorporated into the original
estimates.

46
For use by APM individual and corporate members only
 Introduction to planning

• There is the possibility that, in uture rolling waves, the granularity can be
manipulated to display an intended critical path, rather than the actual critical
path or the project.
• Lack o detail in uture phases may hinder adequate risk analysis.
• Critical path activities are unclear until detail is ully understood in uture
waves.
• Thus, there is a high probability that the project end date may be aected ater
each wave o detail is added.

7.5.3 Agile planning in the sotware industry

7.5.3.1 Denition and purpose o agile planning
Agile planning is a means o adapting rapidly to changes in a business environ-
ment. An agile approach integrates planning with execution almost concurrently,
allowing early and continuous delivery. For a ull denition and purpose statement,
see Chapter 20.

7.5.3.2 The agile planning process

Agile planning is similar to rolling wave scheduling. Work is planned as time-boxed
iterations called ‘sprints’. These are typically 2 to 4 weeks in duration. The sprints
can be grouped into versions or ‘releases’ (see Figure 7.3). Releases that
are planned in the near term are shown in more detail than later ones. For
example, on a bar chart earlier releases would contain each sprint, but releases

Figure 7.3 Agile planning

47
For use by APM individual and corporate members only
 Planning, Scheduling, Monitoring and Control

scheduled later in the uture might be shown as single releases, using a longer
duration.
Not all activities are constrained to sprints; or example, procurement activities
or activities involving external stakeholders.
There is a common misconception that is it not possible to reliably develop and
use a baseline or an agile project, but this is not the case. Welcoming change
does not mean undisciplined or ad hoc delivery. The project still has a vision, a
timescale in which the vision needs to be achieved, and a budget. The planning
o the sprints is guided by the project vision.
A baseline provides the basis or speciying expected outcomes o each
iteration. As a result, customers have the ability to hold the team accountable to
the project vision at the end o each iteration and version release.
Being agile means that there is less resistance to changing the schedule; the
highest priority is to satisy the customer by early and continuous delivery o
valuable sotware. Delivery can be prioritised, using the MoSCoW technique, to
ensure the prioritisation o critical aspects o the solution:

• Must have: These are the requirements that are completely non-negotiable.
Without them, the project will not provide a solution to the customer’s
problem. Wherever possible, these are the requirements that are developed
rst, to gain customer trust and condence in the system, providing early
unctionality.
• Should have: These are the requirements that are still important, but, with
some pain, could in the worst case be taken out; however, there would need
to be ‘work-arounds’ and stakeholder management and buy-in to remove
these requirements rom the scope o the project.
• Could have: These are the ‘nice to have’ requirements. Without them,
the project solution will still deliver; however, there is value to adding
these requirements or a more complete system. These are the requirements
which, i time or cost becomes tight, are the rst to be cut out o the
scope.
• Won’t have (this time): These are the requirements that have been agreed by
the customer and project team to be non-essential, and are thereore being
let out o the scope o the project deliberately. This is not to say, however, that
i the project is awarded an extension, or i there is a delay elsewhere, some o
these non-essential requirements cannot be added in at a later date i they do
not detract rom the main project priorities.

48
For use by APM individual and corporate members only
 Introduction to planning

7.5.3.3 Planning requirements or adopting an agile approach

An agile approach requires the strategy o setting up the project to include:

• development o sel-organising teams;

• engagement o business resource throughout the project;
• collaborative approach – paying attention to behaviours is crucial;
• delegated authority suited to agile change needs to be established.

7.6 Planning strategies

As part o the business strategy, it will need to be decided how best to deliver the
project. Some o the actors that may infuence an adopted strategy would be:

• best commercial solution based on earliest completion;

• most economical solution based on availability o unds;
• the rate at which unds can be committed (sometimes reerred to as ‘cash-
fow’);
• availability o resources (labour and material);
• the rate at which the project can be mobilised;
• external actors such as a relationship with other projects.

Once the strategy has been decided upon, it will direct the rest o the planning,
estimating and scheduling eorts o the project, potentially imposing constraints
and other limitations on the schedule and methods to be adopted.
Dierent strategies can be described with diering planned value curves. The
basic possibilities are based on the critical path method (CPM), which calculates
two sets o dates based on the same schedule logic (an early completion and a
late completion or each activity). The combination o these orms an envelope in
which the works can logically be completed without delaying the desired project
completion date (see Figure 7.4).
Relying purely on CPM, the curves produced would not make achievable plans:

• The early curve, though logically possible, relies on every aspect going
perectly to plan, the absence o risk realisation and the availability o unlimited
resource. This never happens. This curve is oten reerred to as the P0 plan, P0
reerring to zero percent probability o achievement.

49
For use by APM individual and corporate members only
 Planning, Scheduling, Monitoring and Control

• Working to the late curve may be logically achievable, but will allow no
deviation rom plan, as all foat has been eliminated. I a delay to an activity
were to occur, delivery on time or to budget with the existing logic and
assumptions would be impossible. Attempting to work to this curve would
be to assume that no risk will be realised.

It is not, thereore, appropriate to rely on these sorts o planned values without

urther renement, and the use o resource-levelled schedules is thereore
recommended in this guide (Chapter 16).
Figure 7.5 shows the eect o applying a resource-levelling exercise to the
schedule. It is part o the planning strategy to decide what resources can be
applied and what limitations on them are sensible to account or in the project
schedule.
Figure 7.5 also shows a line denoted the ‘economic best t’. This is based on
constraints around the availability o unds – caps on spending at particular
points, or example. A commercial benet can be achieved rom reducing
nancing costs, but i delivery on time is a priority it will have the eect o adding
risk into the project, as it will be harder to recover rom unoreseen delays.

Figure 7.4 Setting early and late curves

50
For use by APM individual and corporate members only
 Introduction to planning

Figure 7.5 Interpreting ‘S’ curves

7.7 Allowing or risk

The uture is unwritten, that is to say uncertain. It is necessary to allow or the
unknown when planning or the uture. Depending on the stage o the project, it
is advisable to allow a 10%–20% time contingency. The ormer will be applicable
at later stages o the project lie cycle, such as at the point o going into contract.
Chapter 26 will discuss the assessment and management o risk in general, and
specically in relation to time, under the process o quantitative schedule risk
analysis (QSRA).

51
For use by APM individual and corporate members only
For use by APM individual and corporate members only
 8.1 Denition o breakdown structures
Breakdown structures are tools used to break down the project into smaller
elements to acilitate the delegation o responsibility.

8.2 Purpose o breakdown structures

Breakdown structures are used to create discrete packages o work to
dene responsibility or delivery and to acilitate project control (see
Figures 8.1–8.3).

8.3 Creating breakdown structures

8.3.1 Level 1
Level 1 o a breakdown structure is based on the ultimate project output (WBS),
the top o an organisation structure (OBS), the highest project-level cost control
package (CBS), the highest-level product (PBS), etc.

8.3.2 Level 2
The next step is to break out the structure into more manageable levels to make
the planning process easier. In the example, the product is now broken down into
phases.

53
For use by APM individual and corporate members only
 Planning, Scheduling, Monitoring and Control

Figure 8.1 Creating a breakdown structure level 1

Figure 8.2 Creating a breakdown structure level 2

54
For use by APM individual and corporate members only
 Breakdown structures

Figure 8.3 Creating a breakdown structure level 3

8.3.3 Level 3 and beyond

This exercise continues until the project team eel that they will be able to dene
tasks and logical dependencies which deliver the lowest level o a structure
(node). At this point there is no need to break out the structure any urther.
There are a number o dierent breakdown structures that a project may
employ (Figure 8.4).

55
For use by APM individual and corporate members only
 Planning, Scheduling, Monitoring and Control

Figure 8.4 Types and relationships o breakdown structures repeated

56
For use by APM individual and corporate members only
 Breakdown structures

8.4 Product breakdown structure (PBS)

8.4.1 What is a ‘product’ in planning terms?
A product is an output which meets the scope or requirement, sometimes
reerred to as (a) deliverable(s).

8.4.2 Denition o a PBS

A product breakdown structure (PBS) is a key step in a product-based planning
approach. It provides a hierarchical tree representation o the relationship
between the products and sub-products such as assemblies, sub-assemblies and
parts, which contribute to delivering the scope and objectives o a project or
programme. It provides the outline ramework or planning, contracting,
budgeting and reporting. An example is shown in Figure 8.5.
Some examples o products required to manage the project are reports, test
documentation, requirement specications and saety certications.

8.4.3 Purpose o a PBS

A PBS provides a top-down hierarchical view o all o the products (outputs)
within a project. This makes it easier to ensure that all the outputs have been
identied beore going into the detail o identiying the work packages or activities
within a work breakdown structure (WBS). Additionally, the PBS helps create a
common understanding o the deliverables in a project, and aids objective
progress capture by dening a physical output.

8.4.4 Constructing a PBS

A PBS is developed at the start o a project, once the required scope or require-
ments have been agreed. The PBS provides a breakdown o all the necessary
products (outputs) o a project, whereas a WBS provides a breakdown o the all
work packages or areas o the project.
The PBS should be included as part o the project plan and stage plans, with
progressively more detail at each level.
To construct a PBS, rst identiy those products that meet the client/customer’s
scope or requirements, such as specialist products. (A useul approach is to
gather stakeholders together to brainstorm the products needed.)

57
For use by APM individual and corporate members only
 Planning, Scheduling, Monitoring and Control

Figure 8.5 Sample product breakdown structure

The next step is to identiy the plans and reports needed to manage products
in the project.
A PBS is drawn in a hierarchical structure rom the top down. The rst
box summarises the overall product, with the subsequent branches showing
intermediate products such as assemblies, sub-assemblies and components or
parts.
It may be useul to break down products into specialist products, which are
those products required to meet the scope or requirement, and management
products, such as reports and plans.

58
For use by APM individual and corporate members only
 Breakdown structures

8.5 Work breakdown structure (WBS)

8.5.1 Denition o a WBS
A work breakdown structure (WBS) is a hierarchical breakdown o the scope or
requirement o the project into a series o manageable work packages or areas
that can be estimated, planned and assigned to the appropriate person or
department or completion. It can be based on design systems, construction/
installation zones or individually commissionable systems. An example is shown
in Figure 8.6.

8.5.2 Purpose o a WBS

A major benet o the WBS is that it breaks down the work required within a
project into work packages or areas, which can be assigned to a responsible
party. Once a project has been broken into small packages o work, there is a
better chance o understanding what needs to be done.

Figure 8.6 Work breakdown structure

59
For use by APM individual and corporate members only
 Planning, Scheduling, Monitoring and Control

The WBS provides a common ramework or the development o the planning
and control o a project. It divides work into denable work packages rom which
a statement o work can be developed and technical, schedule, cost and resource
reporting can be established. Individual work packages or areas o the WBS may
be broken down urther to give better schedule segregation.
A WBS code must be applied in order to identiy the work packages within the
project in a logical manner. This then orms the basis or accurate reporting and
mapping o time, cost and resources.
Each section o the WBS or work package can then be assessed to:

• describe what the work is;

• estimate how long it will take;
• estimate the resources and costs;
• identiy who needs to be involved;
• work out the potential threats and opportunities.

A WBS can be combined with an organisational breakdown structure (OBS) to

produce a responsibility assignment matrix (RAM) showing the responsibility or
each work package.

8.5.3 Constructing a WBS

A WBS is initially developed at the start o the project and is reviewed iteratively
at the beginning o each stage as a minimum.
It is good practice to use a WBS when developing any project schedule.
I a product breakdown structure has already been produced, this provides a
good breakdown o all necessary products and outputs o a project, and can orm
the primary input to the WBS.
Note: in the construction sector the WBS is more usually used to identiy
geographical areas where work will be carried out. However, the hierarchy
principle still applies.
The individual work packages may themselves be urther sub-divided down to
individual activities. The key thing about the WBS is the ability to break down the
project into work packages that can be assigned to a resource.

8.5.4 Principles o designing a WBS

There are three principles that should be applied when designing a WBS:

60
For use by APM individual and corporate members only
 Breakdown structures

8.5.4.1 The 100% rule

The WBS should dene the total scope o the project and capture all deliver-
ables, both internal and external, including project management:

• The sum o the work at the ‘child’ level must equal 100% o the work represen-
ted by the ‘parent’.
• The WBS should not include any work that alls outside the actual scope o the
project, i.e. it cannot include more than 100% o the work.

8.5.4.2 ‘Parent/child’ relationship

There should be no overlap in scope denition between any two elements in a
WBS. Each ‘child’ element o work should only be associated with one ‘parent’.
I not, then you run the risk o duplicating work in the project execution, and
would thereore exceed the 100% rule!

8.5.4.3 Use common sense

• Remember the aim is to dene the work o the project so that it can be planned,
managed and controlled.
• Thereore, there needs to be a sucient level o detail in the WBS, but:
• Do not decompose the WBS to a level beyond that necessary to achieve
these aims.

8.5.5 WBS dictionaries

A work breakdown structure dictionary is sometimes used on more complex
projects.

8.5.5.1 Denition o a WBS dictionary

A WBS dictionary is a tool that helps to clearly dene the work content
o each WBS node. This helps to ensure a consistent and coherent
approach to the project and clearly denes the key deliverables or each
WBS node.
In construction, the WBS dictionary is oten called the work package scope
sheet, and is a key document in dening scope and the key interaces with other

61
For use by APM individual and corporate members only
 Planning, Scheduling, Monitoring and Control

works. In other words, it is a tool to identiy scope gaps or overlaps and assist in
their elimination.

8.5.5.2 Purpose o a WBS dictionary

WBS dictionaries can be used with the customer to ensure that the scope o
work to be undertaken is agreed by all contracting parties. When a project is up
and running, change control o the WBS and associated dictionaries should be
applied. An example o a WBS dictionary is shown in Figure 8.7.
In addition to the elds illustrated, additional inormation may be contained in
a WBS dictionary, such as clarication to suppliers or sub-contractors o services
or ree issue materials to be provided (or not) to the supplier by the contractor or
client. See Figure 8.8 or an example.

Figure 8.7 Work breakdown structure dictionary (deence)

62
For use by APM individual and corporate members only
 Breakdown structures

Figure 8.8 Work package content sheet (construction)

63
For use by APM individual and corporate members only
 Planning, Scheduling, Monitoring and Control

8.6 Organisational breakdown

structure (OBS)
8.6.1 Denition o an OBS
Within product-based planning, the organisational breakdown structure (OBS)
is a top-down hierarchical representation o the management structure and
people within a project. It is used to convey the communication routes and
reporting lines within the project. A project’s OBS may dier rom that o the
organisation. See Figure 8.9 or an example.

8.6.2 Purpose o an OBS

An OBS is a useul tool – in conjunction with the WBS – or planning
projects that interace with complex organisations. It is used to show the
project organisation structured in a hierarchical manner. When used in conjunc-
tion with the WBS, the OBS helps in producing the responsibility assignment
matrix (RAM).

Figure 8.9 Organisation breakdown structure

64
For use by APM individual and corporate members only
 Breakdown structures

8.6.3 Constructing an OBS

The OBS is initially developed at the start o the project and is reviewed iterat-
ively at the beginning o each stage as a minimum.
An OBS is created by:

• First, identiying the organisational structure or the resources involved in the
project.
• This should then be broken out into the areas or departments, sub-areas or
sub-departments and down to the role that will be accountable or a WBS
element.
• This is then drawn out as a hierarchical organisational tree, showing the
reporting lines and communication paths.

8.7 Responsibility assignment matrix (RAM)

8.7.1 Denition o a RAM
A responsibility assignment matrix (RAM) (see Figure 8.10) is a project
management tool, oten depicted as a table, that shows the project
organisational breakdown structure (OBS) in relation to the work breakdown
structure (WBS) to ensure that each element o the scope o work is assigned
to a responsible team or individual. Larger projects may dene RAMs at
multiple levels.
A high-level RAM denes which group or organisational unit or team
is responsible or each component o the WBS. Lower-level RAMs can be
used within teams to assign roles and responsibilities or specic activities to
individuals.
(There is an alternative breakdown known as a £ RAM, which is discussed
under the heading o Cost breakdown structures, section 8.9.)

8.7.2 Purpose o a RAM

The RAM provides a view o all work packages, or at a lower level, activities. It
is used within the project to communicate the required work to stakeholders.

65
For use by APM individual and corporate members only
 Planning, Scheduling, Monitoring and Control

Figure 8.10 Responsibility assignment matrix

It is used to show the accountability or the various work packages or activities
within the project team.
The RAM can orm the basis or scheduling activities and is a key input when
developing the network diagram or Gantt chart.

8.7.3 Constructing a RAM

It is developed at the start o a project where there is a complex division o
responsibilities, when the scope has been agreed, the deliverables have been
dened and a WBS and OBS have been created.

66
For use by APM individual and corporate members only
 Breakdown structures

The OBS will be combined with the WBS to create a RAM. Generally, it is
shown as a grid with the WBS elements on the let-hand side and the OBS
resources across the top, marked at the appropriate intersections to indicate who
is doing what. (Sometimes the RAM is drawn the other way around, with the
WBS at the top and the OBS at the let.)

8.7.4 The step-by-step approach to constructing a RAM

• Dene your deliverables. A WBS is a project planning tool used to break
a project down into smaller, more manageable pieces o work, called work
packages. Work packages can then be broken down urther into individual
activities and their associated deliverables.
• Identiy the people involved. An OBS maps the resources available.
Create a chart o accountable individuals at departmental or sub-departmental
level. For lower-level RAMs, this can cover individuals within the department
or sub-department.
• Create the responsibility assignment matrix. Draw a matrix. The
deliverables orm the row headings, and the resources are listed as column
titles. Determine responsibilities or each item in the WBS. Note that only
one individual should be accountable or any discrete element o work.
Lower-level RAMs can record responsibilities or activities within a work
package.
• Assign other roles. For each section, work package or activity, a RACI
analysis (see 8.8) can be used to record who is accountable or that work
package or activity, and who should be consulted or inormed during its
execution. Table 8.1 shows the denition or RACI analysis, though there are
other responsibility analysis models.
• Communicate. Ensure all groups and roles are inormed o their responsib-
ilities.

8.8 RACI matrix

8.8.1 Denition o a RACI matrix
The RACI matrix is a tool used or identiying roles and responsibilities to avoid
conusion over those roles and responsibilities during the project. The acronym
RACI is explained in Table 8.1.

67
For use by APM individual and corporate members only
 Planning, Scheduling, Monitoring and Control

Table 8.1 Explanation o RACI codes

Interest Denition

R = Responsible Conducts the actual work/owns the problem

A = Accountable Approves the completed work and is held ully accountable or it.
Usually one accountable role

C = Consulted Kept ully inormed and included in decision making. Primary

supportive role

I = Inormed Kept inormed o progress and results

8.8.2 Purpose o a RACI matrix

A RACI diagram is a clear and concise summary o tasks or deliverables (or,
rather, the specic responsibilities contained within project procedures) and the
level o accountability or contribution required rom named roles or individuals
within the project.

8.8.3 Constructing a RACI matrix

The matrix is developed when the scope has been agreed, the deliverables have
been dened and a WBS and OBS have been created.

• Dene your tasks or deliverables. Identiy all the tasks involved in

delivering the project. These are listed on the let-hand side o the chart.
• Identiy the people involved. These are dened in terms o roles,
not individuals, and are listed along the top o the chart, as shown in
Figure 8.11.
• Create the RACI matrix. Complete the chart showing who has responsib-
ility, who has accountability and who will be consulted and inormed or each
task.
• Check or accountability. Ensure that every task has a role responsible
and a role accountable or it. No task should have more than one person
accountable.
• Communicate. Ensure that all groups and roles are inormed o their
responsibilities. Agree the RACI with project stakeholders beore the project
starts.

68
For use by APM individual and corporate members only
 Breakdown structures

Figure 8.11 Example o a RACI

8.9 Cost breakdown structure (CBS)

8.9.1 Denition o a CBS
A cost breakdown structure denes the level at which costs will be collected.
Unlike the WBS, it has no hierarchy as such (or, at least, no particular need or
one), as it comprises a list o cost headings. It is directly related to the WBS,
possibly at dierent levels, as illustrated in Figure 8.12.

8.9.2 Purpose o a CBS

The CBS will be created and structured at a sucient level o detail to allow
budgets to be set, and costs to be collected, recorded, monitored and controlled.
Thus, it must be mirrored in the organisation’s accounting system as well as the
project’s reporting system. In some organisations, the CBS will be set as a

69
For use by APM individual and corporate members only
 Planning, Scheduling, Monitoring and Control

Figure 8.12 Cost breakdown structure

standard and thereore imposed upon the project. In practice, this could infuence
(or possibly hinder) the project reporting system, so it needs to be taken into
account in the establishment o all breakdown structures. Indeed, it may be
necessary in these circumstances to put a project specic cost collection system
in place, which will require serious design and specication, as well as new
business processes and training.
The CBS is sometimes known as the ‘£ RAM’, or example in the deence
sector.

8.10 Resources breakdown structure

8.10.1 Denition o a RBS
A resource breakdown structure (RBS) is a hierarchical structure that groups
resources that are required to deliver the scope by unction, type and grade.
Resources may include personnel (dened individually or by discipline), tools,

70
For use by APM individual and corporate members only
 Breakdown structures

machinery, materials and equipment. Any resource that incurs a cost should be
included in the RBS.

8.10.2 Purpose o a RBS

The RBS will be created and structured at a sucient level o detail to allow the
work to be scheduled, monitored and controlled.

71
For use by APM individual and corporate members only
For use by APM individual and corporate members only
 9.1 Denition o dependency management
Dependency management is the process o monitoring and controlling the key
interaces on a project.

9.2 Purpose o dependency management

On a typical project there are many interaces. For the smooth and ecient
running o a project, interaces need to be careully and regularly monitored and
controlled.
At a high level they can be between dierent organisations:

• suppliers;
• disciplines;
• client;
• third parties;
• sub-contractors;
• other agencies (more typically in Ministry o Deence projects).

Within the project, there can be interaces or the ollowing:

• approval gateways;
• design reviews;
• client assurance reviews;
• consultation;
• discipline integration/coordination.

73
For use by APM individual and corporate members only
 Planning, Scheduling, Monitoring and Control

9.3 Interace scope

It is important that the scope o the interace between the parties is dened,
agreed and, i appropriate, documented. There will be inputs and outputs, and it
is important that these are dened and documented to ensure that they align.
Milestones will be introduced into schedules to represent each interace.
Whilst the undamental purpose o the interace milestone is to highlight the
passing o a section or piece o work to another party, they may also prove to be
a useul way o monitoring progress and perormance.

9.4 Schedule impact

Wherever the interace is in the schedule, it can have a signicant impact on
other activities. For example, an interace may relate to the handover o a piece o
work rom one team to another. So, i the ‘giving’ party is late, it could have a
detrimental impact on the ‘receiving’ party, perhaps causing a critical delay to a
key milestone. Consequently, there is a need to communicate progress o the
interaces between both parties, or example:

• Is the piece o work likely to be completed early, late or on time?

• Is the piece o work required earlier than originally advised due to changing
circumstances?
• Are there any other changes aecting the scope o the interace?

Since the consequences o interaces can include delays to the ‘receiving’ party,
or acceleration to the ‘giving’ party, there can be expensive consequences i they
are not well managed. The creation o a separate schedule to enable proactive
management o dependencies is discussed in Chapter 16.

74
For use by APM individual and corporate members only
 Health, saety and environment (HSE) is a key area o risk that needs to be
planned and managed. Since it is important and strategic in terms o project
success, it must be driven rom the very top o the organisation and be given at
least equal status to other disciplines when planning a project. Considering HSE
at the planning level allows all activities required to complete the project to be
allowed or, and, perhaps more importantly, saety to be considered when meth-
odologies are derived, such that any unnecessary saety risks are planned out o
the project.
It should be recognised that all change must be considered in the light o HSE
concerns, as accidents and near misses are requently caused by last-minute
changes o plan, which by their nature may not have received ull consideration
in the way that long-planned activities have.
From a scheduling point o view, it is important to consider any health, saety
and environmental aspects that will need to be incorporated into the schedule.
Whilst this guide is not a comprehensive guide to HSE issues, this section touches
on some important issues to be considered in the planning and scheduling o a
project.

10.1 HSE issues at strategic level (planning)

Health and saety should always be the rst priority on any project, but there are
some industries where there will be an even greater emphasis: e.g. rail, airports,
nuclear and petro-chem. In addition, any project that has an interace with the
public will need to make special provisions to ensure the protection o the public.
This is likely to involve consultation with various local authorities and emergency

75
For use by APM individual and corporate members only
 Planning, Scheduling, Monitoring and Control

services to ensure that the eect on the public and these services is considered
and their requirements must be complied with. When designing the schedule, it
is important to do so with the relevant level o saety in mind. For example, the
aorementioned industries would all require labour to have special training/
security clearance prior to being able to work on site.
It is essential that project working areas are established with a clear set o rules
and responsibilities:

• Methodology: or example, pre-abrication o site; sequencing to avoid the

need or rework, trades working out o sequence or last-minute changes.
• Time must be allowed in the schedule or obtaining necessary saety permits,
which in some industries may take months.

10.2 HSE issues at tactical level

(scheduling and method statements)
At tactical level, planning or health and saety is about the sequencing o tasks at
a detailed level; some actors to consider include:

• Ensure that sae protection is provided to all workorces, and saety zones are
created around dangerous operations.
• Ensure segregation o workorce and public – in particular, sae access and
egress o large vehicles and plant rom construction sites or assembly plants.
• Segregation within the project environment is also essential where it can be
managed – or example, the separation o machines and people.
• Ensure the security o the project.

As part o the planning, method selection and scheduling process, saety items
should be considered. Any hazards that are identied must be reported to the
relevant authorities or line management.
This guide does not seek to give industry-specic advice, but the principle o
considering HSE in the strategic and tactical planning o work is an obligation on
all involved in planning.

76
For use by APM individual and corporate members only
 11.1 Denition o cost estimating
Cost estimating is the process used to quantiy the cost o services, materials and
resources required to deliver a project.
An estimate should be robust and repeatable. The estimate should contain the
source inormation used to calculate the estimate and associated assumptions.

11.2 Purpose o a cost estimate

The purpose o a cost estimate is to determine the likely cost o the project. It may
have a number o uses, or example to create budgets, to drat proposals, to
tender or work or to get approval or research studies. Depending on its purpose,
the scope and detail o the cost estimate will vary.

11.3 Cost estimating and

the project lie cycle
Cost estimating has our main stages, as shown in Figure 11.1.

77
For use by APM individual and corporate members only
 Planning, Scheduling, Monitoring and Control

Figure 11.1 Cost estimating process

11.4 Estimate types

Estimates are produced at various stages throughout the project lie cycle and or
various purposes. The type o estimate to be prepared and the methodology to
be employed are dependent on the purpose o the estimate and the level o
scope denition.

11.4.1 Scope development estimates

The types o estimate that support the dierent stages o scope development
typically all into three broad categories:

11.4.1.1 Planning
The planning stage is the earliest stage in scope development. Typically
estimates are termed ‘conceptual’ or ‘pre-conceptual’ and will rely primarily
on approximate methods. Estimates prepared at this stage o the planning
process may be termed order o magnitude (OM) or rough order o magnitude
(ROM).

78
For use by APM individual and corporate members only
 Cost estimating

11.4.1.2 Preliminary
The preliminary stage is the next stage in scope denition. Preliminary estimates
should use denitive methods or the next stage o scope denition; however, it
is acceptable to use approximate methods or those areas o scope remaining
undened.

11.4.1.3 Denitive
The denitive stage is the nal stage in scope development. Denitive estimates
are prepared using denitive (detailed) estimating methods.

11.4.2 Other types o estimate

Other types o estimate prepared at various points in the project lie cycle include:

11.4.2.1 Optioneering
Optioneering estimates are prepared to establish the cost dierences between
two or more alternative strategies in order to arrive at ranking o alternatives to
inorm an economic decision. Both approximate and denitive methods are
appropriate or these types o estimates, depending on the level o scope deni-
tion. These are described later in this section.

11.4.2.2 Fair Price

A air price estimate is used to determine the reasonableness o competitive or
sole source bids received in connection with a proposed sub-contract, and serves
as a control in evaluating cost and pricing data in a contract negotiation. These
estimates are used in support o change orders or sub-contract compensation
event evaluations. The estimate should be produced against an identical scope to
that provided to the sub-contractor. Condentiality o the estimate is essential at
all stages o the process.

11.4.2.3 Independent cost estimate

Independent cost estimates are estimates prepared by external or third parties
with the express purpose o validating, cross-checking or analysing estimates
developed by project teams.

79
For use by APM individual and corporate members only
 Planning, Scheduling, Monitoring and Control

11.5 Contents o an estimate

Estimates should be established ater the completion o the project denition
phase and in conjunction with other elements o the planning phase. That is:

• They should be based on the dened scope and requirements.

• They should be based on established codes and standards.
• They should be based on the selected procurement planning or contracting
strategy.
• They should correlate with the schedule (i.e. allowances or time in the
estimate should match those in the schedule).
• They should recognise the available resources.
• They should be based on any known unit rates, with productivity assumptions
taken into account.
• They should recognise any stated exclusions.

An estimate should contain both a robust base estimate and a realistic contin-
gency budget.

11.6 Estimating methodologies

The estimating methodology to be employed is directly related to the stage o scope
development. These are typically divided into ‘approximate’ and ‘denitive’ methods.
Approximate methods should be used or estimating projects in the longer
term, with denitive methods being used as the project moves towards and into
the near term.
Depending on the estimate purpose and the scope denition, dierent phases
o the project may require dierent estimating methods. It is, thereore, not
uncommon to include both denitive and approximate estimating techniques
within the same project estimate.
The main estimating methodologies within these categories are as ollows.

11.6.1 Approximate estimating methods

11.6.1.1 Specic analogy estimating
This method o estimating is based upon selecting a costed project that is
similar or related to the project costs being estimated. It uses the known cost o

80
For use by APM individual and corporate members only
 Cost estimating

an item/activity used in the prior project as the basis or the cost o a similar item/
activity in the new project. Adjustments are made to account or dierences in
relative size/complexity o perormance, design or operational characteristics.
This approach works well or derivative or evolutionary projects but is unsuitable
or radical changes or substantially dierent projects.

11.6.1.2 Parametric estimating (estimating norms)

Parametric estimating uses a methodology that is based on elements o cost
extracted or gleaned rom historical data acquired rom similar systems or sub-
systems. The data is analysed to nd correlations between cost drivers and
other system parameters, such as size, design or perormance, to derive cost
estimating relationships (CERs) that can be scaled and applied to similar systems
in dierent projects to determine likely costs. The derived correlations are
expressed as equations or cost estimating relationships, which can be simple cost
actor ratios or more complex relational equations. The parametric approach
enables costs to be generated quickly rom limited data. Care needs to be
exercised to ensure that the project being estimated is within the bounds o the
CER selected.
The major dierence between analogy estimates and parametric estimates is
that the parametric estimates use a database o out-turn data rom completed
projects upon which to base the cost estimate, whereas the analogy estimate may
use data rom as ew as one or two completed projects.

11.6.1.3 Delphi technique

This is a technique based on the principle that estimates rom an experienced
and structured panel can provide a useul judgement-based output. This
approach can be used where analogous or parametric data is not available.
Several specialists are consulted in a systematic manner using a series o ques-
tionnaires, and answers are then rened based upon eedback rom the panel.
The range o answers will gradually decrease until a consensus estimate is estab-
lished. Expert judgement estimates tend to become more accurate as more
experts are consulted. It is important to note that responses are kept anonymous
to ensure impartial advice is given.

81
For use by APM individual and corporate members only
 Planning, Scheduling, Monitoring and Control

11.6.2 Denitive estimating methods

11.6.2.1 Detailed
Generally based upon a specication and set o drawings which are used to
‘take-o’ measured quantities o work required to perorm each discrete task to
which known or standard unit rates can be applied. Also known as ‘bottom-up’,
‘measured quants’, ‘ull detail’ or ‘unit cost’. For a design, engineering or services
estimate, it should be based on quantied deliverables (drawings, reports, saety
cases, etc.) or which established norms are available.

11.6.2.2 ‘Activity-based cost’ (ABC) estimating

ABC estimating is based upon application o a composite all-in rate to a specied
team or crew o workers. This method o estimating organises the work into
activities that will be accomplished by a specic gang or team o workers. The
estimated time taken to complete the work activity is multiplied by the composite
hourly rate or the gang, together with additions or materials and equipment.
Examples include dismantling and decommissioning redundant nuclear acilities.

11.6.2.3 Task analysis

The activity is broken down into discretely estimated resource types and
quantities (labour, materials, equipment, etc.) required to perorm the activity,
which is then priced at known or standard unit rates. (Also known as ‘resource-
based estimating’.)

11.6.2.4 Level o eort/business-as-usual/prelims

Used when a minimum level o support is required regardless o the number
o tasks to be carried out or in the absence o measurable or quantiable
outputs. This method should be reserved strictly or management and support-
type activities that cannot be assigned to a specic work scope or quantiable
deliverables.

82
For use by APM individual and corporate members only
 12.1 Denition o budgeting
Budgeting is the process o allocating appropriate budgets to dierent parts o
the work breakdown structure. Budgets are oten expressed in terms o money,
but may equally be described in terms o other resources such as labour, plant or
materials.

12.2 Purpose o budgeting

Budgets are set in order to set cost perormance targets or the procurement and
delivery o the project. The budget will become the basis or a true comparison
with actual costs incurred during the lie o a project (either in a cost value report,
or in earned value analysis). In the ormer case, the budget will produce the
‘value’ numbers. In earned value analysis it will orm the basis o the planned and
earned value.

12.3 Funding and budgets

Funds represent the money available or expenditure in the accomplishment o
the eort, and must not be conused with budgets; unds are spent, not budgets.
The estimate at completion provides the project team with visibility o the
expected out-turn o costs and thereore the unds that will be required to
complete the project. Perormance against the budget will be used as an indicator
o the rate o spend until completion o the project.

83
For use by APM individual and corporate members only
 Planning, Scheduling, Monitoring and Control

A business’s nancial budget is based on identication and management o

project budgets in line with available capital expenditure (unds). This is an
iterative process usually done on an annual basis.

12.4 Producing a cost budget

12.4.1 Cost breakdown structure
Cost budgets usually start with a procurement strategy, an estimate and the cost
breakdown structure. Once contracts are let, the cost inormation is organised by
contract deliverables and mapped to work packages or the purpose o budgeting.
Table 12.1 shows an example o a simple cost budget.
When the project’s budget is produced, it is important to ensure that there is
a direct link between the project’s estimated costs and activities within the
schedule (CBS and WBS). Most modern planning tools will provide a cost prole
based on the time-phased activities and schedule logic. As the project progresses,
it is important to maintain an alignment o cost and time so you can orecast as
accurately as possible, see Figure 12.1.

12.4.2 Cash-fow statements

Once budgets have been distributed, it has sometimes been traditional practice
to create cost or cash-fow orecasts in spreadsheets. Oten this is done rom a
top-down approach, and this is very disjointed rom the schedule. It is, thereore,
unlikely that meaningul results will be achieved, and certainly it is not easy to
adjust and realign these orecasts as the working schedule changes. Thus, it is
preerable to use scheduling sotware to produce orecasts. The budgets are
allocated to activities (note: not summary bars) in the project schedule.

Table 12.1 A simple cost budget

CBS Id No Contractor Work package Budget

1 Blogs & Son Concept Design £1,000

2 Smith Inc. Detailed Design £5,000

3 Big Build Co. Build £50,000

4 Internal Costs PM Cost £2,000

84
For use by APM individual and corporate members only
 Budgeting

Figure 12.1 Time measured in nancial periods

Once the budget is allocated in the scheduling sotware, ‘S-curves’ can be

drawn. These will most likely be based on the early dates, as this is how scheduling
sotware usually deaults. In reality, these activities may have an element o foat
and are subject to unoreseen change. When attempting to orecast costs, it is
important to actor in these variances, otherwise you risk putting an overly
aggressive or optimistic nancial view to the project manager and business.

85
For use by APM individual and corporate members only
 Planning, Scheduling, Monitoring and Control

Alternatively, ‘S-curves’ may be drawn based on late dates. This is equally

fawed, as it would be hopelessly pessimistic. No project should assume that late
dates are acceptable to work to, as they would make completion on time
unachievable – unless the project encounters no risk realisation, no resource
limitation and no ailure o any other kind. This never happens.
One way to actor in reality is to use a ‘mid curve’ or ‘banana curve’
(Figure 12.2). This process uses schedule logic to plot an early and a late curve
and calculates the midpoint between the two. This then allows or a portion
o project foat to be consumed and presents a more realistic cost orecast
whilst keeping the schedule aggressive and the project team ocused on early
completion.

Figure 12.2 Generating a cost orecast using a banana curve

86
For use by APM individual and corporate members only
 Budgeting

12.5 Budget transers

Budget transers are made through a change control process to ormalise the
movement o scope (budget and schedule) rom one part o the project to
another, or to move scope into or out o the project.
A secondary reason or budget transer may be the reallocation o budgets in
order to correct data errors, but this must be done through a ormal change
control process, and it is wise to limit this only to essential major revisions.
Budget transers must never be made in order to mask or account or cost
over- or underspends, either realised or anticipated.
It is good practice to ensure that transers o budget are communicated and
mutually understood by both donor and recipient, and accepted and documented.

87
For use by APM individual and corporate members only
For use by APM individual and corporate members only
 Part Three

Scheduling

‘The key is not to prioritise what’s on your schedule, but to schedule your
priorities.’
Stephen Covey

For use by APM individual and corporate members only

For use by APM individual and corporate members only
 13.1 Denition o scheduling
Scheduling can be seen as a science compared with the art o planning; it usually
involves the input o the plan into scheduling sotware. It involves the calculation
o duration and resources required; it denes the logic and sequence and the
calculation o critical path, foat, and start and nish dates o individual activities,
and thus determines the easibility o delivering the project within the desired
completion dates and budget.
Scheduling is:

• integrating dierent parts o the project;

• identication and management o interdependencies;
• the identication o specic activities, and the resources required to deliver them;
• developing a logical sequence o works based on the planning strategy and
methodologies to be adopted;
• establishing expected output rates to be used in the calculation o durations,
and hence dates or each o these activities;
• undertaking these calculations;
• identiying the critical path and establishing priorities;
• making due allowances or risks (risk mitigation planning) in the schedule.

13.2 Purpose o scheduling

The purpose o scheduling is to create the ollowing outputs to enable the
management o the project:

91
For use by APM individual and corporate members only
 Planning, Scheduling, Monitoring and Control

• the sequence o project tasks;

• the start and nish dates o all project tasks;
• the critical path (the longest path through the project);
• calculated project foat;
• a comprehensive understanding o logical dependencies between tasks;
• the resources required to complete the project;
• a schedule that the project team will use to deliver the work. This may include
various schedules dealing with interaces, key dates etc.;
• diagrams, sequencing drawings etc. to assist in explaining sequences and
timing.

Thus, scheduling:

• helps make decisions about strategies and methods considered as part o the
planning process;
• ocuses management attention on the most important issues and activities;
• considers work calendars;
• considers time contingency;
• starts at strategic level and is decomposed into medium and short-term
scheduling;
• denes the sequence o activities with which the project goals can be accom-
plished;
• quanties the resources required and cost to be expected as a result o project
execution;
• clearly denes the scope o work;
• optimises the use o resources.

13.3 The scheduling process

13.3.1 Steps in establishing the schedule

• Review the business case.

• Review the project requirements and establish key deliverables and risks;
dene the scope o work.

92
For use by APM individual and corporate members only
 Introduction to scheduling

• Develop the product breakdown structure and work breakdown structure

(PBS/WBS).
• Develop an organisation breakdown structure (OBS) and other project
structures.
• Determine and agree the project control requirements with all relevant
stakeholders.
• Create the network diagram: sequence the work (reerring to the scope docu-
mentation), establish technical constraints/logic, estimate durations and
identiy key milestones.
• Ensure consistency between dierent levels o schedule (vertical integration)
and between schedules at the same level (horizontal integration).
• Develop a schedule that meets the project required dates, using activities and
milestones, which should be ully logic-linked and constraint-ree.
• Group the activities into work packages and planning packages in accordance
with the project structures.
• Assign resources to activities (labour, material, sub-contracts, and other direct
costs).
• Assign budgets to activities.
• Run a orward and backward pass and ensure that the critical path runs
continuously rom the rst activity to the last activity; check or other critical
paths and the critical path drivers.

See Figure 13.1 or an overview o the scheduling process.

13.3.2 Once the schedule is created

• Perorm schedule integrity checks to ensure the robustness o the schedule.

• Undertake the appropriate level o quantitative schedule risk analysis.
• Issue the baseline with the appropriate level o authority and under ormal
change control.
• Monitor the progress o delivery o the plan, and control divergences rom the
original plan.

93
For use by APM individual and corporate members only
 Planning, Scheduling, Monitoring and Control

Figure 13.1 The scheduling process in the context o planning, monitoring

and control

13.4 Schedule structure

13.4.1 Schedule density

13.4.1.1 Denition o schedule density

Reerence is oten made to ‘levels’ o schedules or planning; or example, level 1
may reer to the highest-level strategic schedule, level 3 may be the working
schedule and level 5 the short-term, week-by-week schedule. Dierent organ-
isations have dierent denitions o these, so to avoid conusion this guide will
take the lead o the CIOB’s Guide to Time Management in Complex Projects and
reer to scheduling ‘density’, where low density means the higher levels or
strategic schedules (perhaps simplied schedules or communication), medium
density means the working schedule, and high-density means the week-to-week,
day-to-day or shut-down scheduling.

94
For use by APM individual and corporate members only
 Table 13.1 Features associated with density o schedules
Density Timescale Activity Typical Budget/ Logic Lags Calendars Cost Contingencies Comment
names activity resource (example) allocation
duration loading

Low – the +1 year Will tend Per each Major Logic May be Generic Major Since Adequate level
highest rom to be element budget links o included working budgetary durations will o detail or
level(s) o now elemental, groups various or week with groups be calculated easibility
schedule describing types will illustrative statutory such as using checks only; in
key parts be used purposes; and designer, empirical later schedules
o the to best negative typical contractor, data, a high appropriate
project describe lags should industry client costs degree o level o detail
the never be holidays contingency or strategic
sequence used even included is required. overview
at this level Quantitative picture only
schedule risk
analysis may
be applied to
determine

Medium 3months A urther Indicative Allocated Mainly Some lags Activity- Cost Risk should Sucient detail
– 1 year denition duration: to nish to may exist, based coding be reduced o allocation to
rom into key 4–8 activities start links though the calendars should be with greater particular
now parts or weeks. or (FS) will proportion estab- clarity. Clear contractors or
products Durations rst-pass be used will be lished at identication other resources
o the may be baseline much this stage o the risk to allow pricing
project derived reduced (foat) owner and resource
rom at this level allocation
typical
outputs

(Continued)

For use by APM individual and corporate members only

 Table 13.1 Continued
Density Timescale Activity Typical Budget/ Logic Lags Calendars Cost Contingencies Comment
names activity resource (example) allocation
duration loading

High – the Next 3 Clear, Indicative Baseline Mainly Rarely Resource- All Clear Adequate or
lowest months unambigu- duration: set and nish to acceptable; based resources identication detailed
level(s) o ous and 2–4 weeks not start links generally calendars must be o the risk description,
schedule precise Durations subject to (FS) will replaced in place i identied (foat) owner creation o
with will be change be used by activities relevant and all at this level. day-to-day
reerence derived with FS relevant Design or schedules, and
to specic rom links activity variation risks progress
location or outputs coded should not be reporting.
resource and required at Detailed design
discussion this level is complete and
methods
dened and
agreed

For use by APM individual and corporate members only

 Introduction to scheduling

Figure 13.2 Relationship o dierent densities in schedules

13.4.1.2 Typical eatures associated with density o schedules

Figure 13.2 shows the relationships between the dierent levels or density o
schedules on a typical project – note the directions o the arrows between the
boxes, which relate to the genesis o each revision or update o the schedule.
This diagram, thereore, represents the relationship o various schedules in the
execution phase.
It is useul to dene a hierarchy o schedules that will be used to describe to
the project team (and others) the relationship between dierent schedules that
are (to be) produced. A simple diagram o such a description is shown in Figure
13.3, although it will be useul to dene which (i any) schedules are contained in
the same sotware database. For example, as shown by the yellow box in the
diagram.

97
For use by APM individual and corporate members only
 Planning, Scheduling, Monitoring and Control

Figure 13.3 A hierarchy o plans and planning documents

13.4.2 Detail density: considerations

Schedules must be produced with the target audience in mind. For example, it is
likely that senior management will require low-density schedules that explain
blocks o activity and major dependencies and logic links. Management decision
making will require medium-density plans, whilst day-to-day supervision o
works will require high-density planning and scheduling. Schedules with an inap-
propriate level o detail may become useless.

13.4.2.1 Schedules with too much detail

Too much detail produces very large schedules. Large schedules with correct
logic take a long time to produce. When change comes – or whatever reason –
they can be very dicult to revise. A schedule that cannot be easily modied
loses its value as a reporting or management/decision-making tool. With greater

98
For use by APM individual and corporate members only
 Introduction to scheduling

levels o detail comes the risk o errors. Complex logic can hide errors, which will
be harder to pick up in a very large schedule.
Also, very large schedules are less likely to be read and/or used. It is important
to remember the target audience. The schedule should be in adequate detail or
the correct monitoring o the project.

13.4.2.2 Schedules with inadequate detail

Schedules with not enough detail should also be avoided. Too low a density in
planning will create schedules that do not ull their main purpose – to help
coordinate and direct the work. I the activities are too large, then important logic
may be missed, and critical tasks overlooked. This could result in a schedule that
cannot be used to accurately monitor the progress o the work.

13.4.2.3 Detail density: principles

• At high density, every activity should represent the work o only one resource.
This may mean a single trade or even an individual.
• Low density may require a more generic denition o resource, or example
‘implementation team’ or ‘civils work’.
• Probably at medium density, and certainly at high density, there should be
sucient detail to allow only nish to start relationships.
• All activities must be split not only so that they relate to only one resource, as
noted above, but so that they relate to only one key or sectional date.

13.4.3 Network templates (ragnets)

Network templates are usually adopted or repetitive sections o schedules, e.g.
foors o a multi-storey building. They can be used to quickly build up a schedule
made up o many similar phases or sections. They are copied and pasted into a
schedule to enable a repetitive schedule to be built up quickly without having to
keep typing in the same activities.

99
For use by APM individual and corporate members only
For use by APM individual and corporate members only
 14.1 Schedule types: time-based
There are a number o dierent types o time-phased schedule, created at various
stages and by various parties with subtly diering purposes and aims. In order or
a project to have clarity, it is important or these to be limited to the key schedules
described below.

14.1.1 Development or strategic schedule

This is usually the highest level o logic-driven schedule. This will very likely be
created by the customer at the inception o a project. It should incorporate the
major elements o the work and include all the key dates. Development schedules
are usually low-density schedules.

14.1.1.1 Purpose
• To provide an outline o the project parameters in terms o scope and time.
• To dene project gateway stages, including key ‘go/no-go’ points.
• To illustrate the approvals required or the project to proceed.
• To incorporate key dates over the lie o the project.
• To identiy a high-level critical path or the project.
• To show the key integration events and acceptance points.

101
For use by APM individual and corporate members only
 Planning, Scheduling, Monitoring and Control

14.1.1.2 The schedule will include

• Overall completion date.
• Sectional and key dates.
• Details o approval stages throughout the project.
• Third party inputs or outputs.

14.1.2 Tender schedule (or ‘bid schedule’)

These schedules are created by a contractor/supplier or other delivery organisa-
tion when tendering or bidding or work. They can be critical to winning or losing
a bid or work. Tender schedules are likely to be medium-density schedules.

14.1.2.1 Purpose
• To assist in the pricing o the tender.
• To identiy and communicate the methodologies and timescale or delivering
the project.
• To demonstrate good practice to the reviewing authority/customer/client.
• To show the level o resources required to complete the works.
• To dene key technologies being proposed and their levels o maturity.
• To dene inormation-required dates.
• To show inputs required rom third parties.
• To show all key interaces.
• To make adequate allowances or risk and schedule uncertainty.
• To dene the procurement strategy.
• To clearly show any works by others.
• To include all utilities and statutory undertakings.

14.1.3 Contract schedule

This is the schedule that has been signed up to in the contract. It should be
agreed at the start o a contract or programme o works. In a hierarchy o import-
ance, this is probably the most important schedule. It should cover all the scope,
whether design, procurement, installation or commissioning. It is the schedule
that will orm the baseline, and thereore the progress o the works will be

102
For use by APM individual and corporate members only
 Types o schedule

measured against it. In all contracts there should always be a ‘current’ contract
schedule. There may be changes throughout a project, but, once instructed,
these should be included in the contract schedule.
This is the schedule against which the cause and cost o any delays are
calculated. It is the schedule that is used as the basis or all monthly or period
progress reporting, so it should be at a suitable level o detail. Contract schedules
are likely to be medium-density schedules.

14.1.4 Baseline schedule

Generally the rst working schedule (or contract schedule) will be copied and set
as the baseline schedule. The baseline should be maintained as change is
approved. The baseline schedule will refect the density o scheduling that it
relates to, and is thus likely to be a medium-density schedule.

14.1.5 Summary schedule

This is a pictorial, created to explain in very simple terms the schedule and its
contents. Whilst it is possible to create such a schedule by rolling up activities in
the main schedule sotware, this is unlikely to produce a clear, logical and well-
presented view o the project. It is, thereore, better created in isolation and is
oten best presented in non-scheduling sotware. Spreadsheets or presenta-
tional tools are particularly good or this type o schedule. Summary schedules
will always be low-density schedules.

14.1.6 Working schedule or ‘orecast schedule’

It is likely that this will be developed rom the tender, or other earlier schedule. It
should include all activities relating to the delivery phase, including design activ-
ities, procurement activities, installation and commissioning tasks. Working
schedules are likely to be medium-density schedules.

14.1.6.1 Purpose
The working schedule directs delivery in the optimum sequence, on time and to
cost. Thus, the purpose is to manage the activities that are to be undertaken on
an ongoing basis.

103
For use by APM individual and corporate members only
 Planning, Scheduling, Monitoring and Control

14.1.6.2 The schedule will include

• Design.
• Procurement schedule.
• Approval periods.
• Manuacture.
• Build.
• Temporary works.
• Trac management (and logistics).
• Labour and plant resources.
• Integration activities.
• Test, commissioning and acceptance activities.
• Handover and closeout process.
• Support activities.

14.1.7 Target schedule

Some projects run with target schedules. These can be set by contractors
to challenge the workorce to complete a project earlier than the contracted
date. Target schedules will refect the density o the schedule rom which
they are created, and are thus likely to be medium-density schedules. However,
they may cover the short-term only, and are thus likely to be created at high
density.

• Advantages:
• easy to do and understand;
• ocuses the project team on early delivery.
• Disadvantages:
• requires rebalancing o the time/cost/scope/ quality triangle (Figure 14.1);
• requires sotware;
• purely tactical, no strategic view;
• distracts rom ‘one version o the truth’ reporting;
• dilutes ocus, as there is more than one schedule to consider and under-
stand;
• may engender complacency i it is known that the target schedule is not the
denitive schedule.

104
For use by APM individual and corporate members only
 Types o schedule

Figure 14.1 Distorting the time/cost/quality triangle

14.1.8 Short- and medium-term schedules

Medium-term schedules will typically be extracts o the working schedule. The
extracts are made to acilitate day-to-day planning o the works that will become
the short-term schedules. They are typically named to refect the period o time
that they cover. Examples o how they may be named include:
• three-month look ahead (medium-term schedule);
• our-week look ahead (short-term schedule).
It is very likely that these schedules will be high-density schedules, especially i
they are weekly ‘look aheads’; monthly ‘look aheads’ may be medium-density.

14.1.9 As-built schedule

This is the schedule that will be developed throughout the lie o the project, to
provide a record o what actually happened during the course o the project. It will
be useul or learning rom experience in the lessons learned process, or possibly

105
For use by APM individual and corporate members only
 Planning, Scheduling, Monitoring and Control

employed in the use o making or rebutting claims on the contract. ‘As-built’

schedules are likely to be created at medium- or high-density scheduling.
Additional items that this schedule will include:
• baselined or original planned dates;
• actual start and actual nish dates or each activity;
• details o change events;
• details o delay events.

14.1.10 Post-build schedule

The ‘as-built’ schedule is created as the project proceeds. In its absence it may
be necessary to construct a post-build schedule. It is created once the project
has nished. It is built rom historical records, but shares the aim o the ‘as-built’
schedule, in that it is created to make or rebut claims. This type o schedule
would be created as a last resort, as you would expect an ‘as-built’ schedule to be
in place; when it is not, this approach may be appropriate. Post-build schedules
are likely to be created at medium-density scheduling (see Figure 14.2).

Figure 14.2 Types o time-phased schedules and their relationship

106
For use by APM individual and corporate members only
 Types o schedule

14.1.11 ‘What is’ (scenario planning)

‘What is’ are test schedules that can be produced to see what impact a scope,
schedule or methodology change may have on the contract dates – or baseline
schedule. ‘What is’ are produced separately rom the working schedule. They
are only incorporated once all the implications have been examined and the
proposed change is agreed.
They may also be used when a critical delay occurs that impacts contractual
dates. This ‘what i’ schedule should show how the works will be re-scheduled to
enable the contractual dates to be met. Any additional working hours or resources
should be clearly identied. This is sometimes called the recovery schedule.

14.2 Schedule types: tracker schedules

A tracker schedule is one that lists the various steps through a process and details
by when each step, or action, should be complete. Typically, it describes steps
along a management process, rather than activities that produce a deliverable,
such as a design or a product. A typical example, the procurement schedule, is
illustrated in the ollowing sections. These are generally and most useully produced
in spreadsheets that can be accessed and updated without specialist sotware.
It is sometimes suggested that the time-phased schedule should contain every
step required to complete a project. The problems that this causes however,
include the growth o the schedule into an unocused and in extreme cases,
unmanageable model. Whilst it is true that every step should be represented in
the schedule, where there are alternative and better methods o dealing with
detail these should be kept separate, and updated by the responsible manager to
keep them as a live document. They must be linked to the time-phased schedule,
and these links regularly updated. It is usual, and desirable, or tracker schedules
to be created and held in widely accessible sotware, such as a spreadsheet.

14.2.1 Procurement schedules

A procurement schedule is a tracker document that covers all the required steps
o the procurement process. It is used to monitor each stage o the process to
ensure that it is completed on time. The procurement schedule must be linked to
the working schedule or updated on a periodic basis. The project-specic periods
will be dened in the project procedures.

107
For use by APM individual and corporate members only
 Figure 14.3 A sample procurement schedule

For use by APM individual and corporate members only

 Types o schedule

The spreadsheet example shown in Figure 14.3 has the advantage that it can
be set up to automatically update some o the data. Also, spreadsheets are
generally more accessible to read and update than bar charts, which require
scheduling sotware.
An alternative way o displaying the procurement schedule is to adopt a more
traditional time-phased approach, as illustrated in Figure 14.4, which is best
displayed in scheduling sotware.
However, the choice o which method to adopt is a matter o personal
preerence.

14.2.2 Design deliverables tracker

A design deliverables tracker is a document that covers the ull scope o the
design in a list o dened deliverables or the purpose o tracking and monitoring.
This may be used as a supplement to the design schedule, ensuring that detailed
tracking o individual items is possible. The progress claimed against the tracker
may be tied to payment. The design deliverables tracker must be linked to the
working schedule or updated on a periodic basis. The project-specic periods
will be dened in the project procedures.
Figure 14.5 shows a method o monitoring the progress o various design
documents until they are complete.

14.2.3 Other tracker schedules

The same principles as outlined above can be applied to many types o activity
(usually management eort) that are best kept out o the time-phased schedule
to ensure proper ocus on that schedule and proper ocus on management eort
in the deliverable trackers. Examples o other trackers that may be useul to keep
detail out o the schedule include:

• method statement trackers;

• quality control inspection trackers;
• consents trackers;
• construction or installation trackers;
• assurance documentation trackers;
• commissioning process trackers;
• handover process trackers;
• progress tracker schedules.

109
For use by APM individual and corporate members only
 Figure 14.4 Time-phased procurement schedule

For use by APM individual and corporate members only

 Figure 14.5 Design deliverables tracker

For use by APM individual and corporate members only

For use by APM individual and corporate members only
 15.1 Denition o schedule design
Schedule design reers to considerations and decisions that are made when
setting up the structures or the project. These considerations must be made
prior to commencing any scheduling work. The decisions that are made should
be detailed in the project-specic procedures.

15.2 Purpose o schedule design

Making and writing down the decisions around these structures should help to
ensure that time is not wasted in revisiting schedules to correct deects in settings,
structures and other technical aspects o scheduling.

15.3 Elements o schedule design

15.3.1 Activity identity numbers (IDs)
15.3.1.1 Purpose o structured IDs
Activity IDs provide a unique identier or each activity in the schedule. The ID
provides the planner with a quick reerence that remains constant throughout
the project’s duration. It can be auto-generated by the scheduling sotware, and
it is important or orensic analysis o the schedule that the activity IDs, once
used, are never changed or re-used.

113
For use by APM individual and corporate members only
 Planning, Scheduling, Monitoring and Control

15.3.1.2 Structure
The structure o an ID may well repeat some or all activity codes, but it
can provide a shorthand that the scheduler can use, or example, to trace logic.
Care should be taken not to over complicate the structure and the use o letters
to abbreviate the names o parts o the project (lie cycle stages, geographic
areas, etc.).
Structuring activity IDs can oten be tailored to the project; thereore, it is
recommended to use abbreviations that can be understood, or example lie
cycle stages such as DE, CN, TC or design, construct, and test and commission.
Other structures to consider when generating activity IDs are:

• geographic location;
• section o work;
• who does the work?

To maintain schedule integrity, it is important never to correct errors post

ormal issue o the schedule, and not to recycle an activity ID (use o redundant
activities).

15.3.2 Activity descriptions

Activity descriptions should be clear and unambiguous. Ideally, they should
dene the work they are describing completely, i.e. not relying on WBS headings
to provide context. This is particularly important when lters or alternative views
are applied to the schedule so that precision and clarity are maintained.
Descriptions should avoid using acronyms and should write out the ull descrip-
tion clearly, as ar as is possible (see Table 15.1).
I this is not possible, then the schedule should be structured with additional
lters, fags or outline codes which provide urther detail on the tasks in the
schedule.

Table 15.1 Examples o activity descriptions

Bad description Good description
Design Design – Earthworks
Ground Floor Slab BUILDING 1 – Formwork, Rebar, Pour Ground Floor Slab Grid 4-7/a-
RFC to 1 Fl
st
Reinorced concrete slab to 1st foor

114
For use by APM individual and corporate members only
 Schedule design

15.3.3 Dierent activity types

15.3.3.1 Tasks
Activities are usually ‘doing’ tasks, and thereore should include a verb, e.g. DIG
oundations; LAY brickwork; INSTALL steelwork.

15.3.3.2 Level o eort activities

Generally support activities which must be undertaken to support other project
activities, level o eort (LOE) activities are typically dicult to orecast, or
will not add value to the overall scheduling logic. Examples o level o eort
activities include:

• Project manager: It is dicult to predict where the PM’s eort will be ocused
on a daily or weekly basis, as it is generally ocused on areas that need support,
which oten change regularly. Scheduling these activities into a high-density
schedule would be very time-consuming and would not add value to the
overall logic structure. It is thereore appropriate to assign a LOE activity or
the PM spanning the lie o the project, as they are helping to acilitate the
project’s success.
• Planner/Scheduler: Although there may be repetitive work due to the regular
reporting cycle which can be predicted and scheduled, it does not add value
to the schedule to itemise these activities in a low level o detail; thereore,
LOE is appropriate.

Level o eort activities should be used sparingly within scheduling, as they do

not provide objective time perormance measurement through measurable
outputs. Any LOE activities used within the scheduling should be clearly
identied and their use ully justied.

15.3.3.3 Hammocks
A hammock is a summary activity that will expand and contract depending on the
activities that it is linked to. Hammock tasks are very similar to level o eort
(LOE) tasks, diering only in the ollowing:

• A hammock task does not have a calendar assigned to it, whereas a LOE task can
have a specic calendar attached (or example, part-time scheduling support).

115
For use by APM individual and corporate members only
 Planning, Scheduling, Monitoring and Control

• Only a start-start and nish-nish relationship can be assigned to determine

the start and end points o the hammock, whereas a LOE activity can have any
relationship type as a predecessor and successor.

15.3.3.4 Dummy tasks

Dummy tasks may also be schedule visibility tasks. I an activity is dependent on
a lead time, or a customer approval, or example, it may be benecial to utilise a
schedule visibility task (SVT), which is a task entered into the scheduling sotware
with no resource assigned to it, representing the elapsed time o the lead time or
the customer approval time. This could also be used in a construction environ-
ment, or curing time, as an example.
The main advantage in utilising SVTs rather than leads or lags in the schedule
is primarily or visibility. Oten, leads and lags are overlooked or hidden in
standard scheduling views created by sotware tools, and can be overlooked
by the wider team. Appropriate calendars may also be applied – or example,
curing activities would always work on a seven-day calendar, whereas works
around them may not. Adding SVTs into the schedule shows clearly the
impact o the ‘waiting time’ and avoids the need to document lead and lag
justication in the notes o the schedule, as this can be captured in the SVT
title (e.g. ‘SVT: six week customer review time or sign-o o Requirements
Document’).

15.3.3.5 Milestones (start, nish)

A milestone is an event in a schedule with no duration. Examples may include
signicant start dates, including access dates, the commencement and completion
o key phases o the project, and other key or contract dates.

15.3.4 Activity steps

When working on a large-scale project, it is sometimes preerable to manage the
quantity o tasks displayed on the schedule. It may be more appropriate to
convert a series o sequential tasks into one task which is supported by a number
o ‘steps’ or ‘objective criteria’. These steps can have pre-agreed progress
weightings to establish progress in an objective way (Figure 15.1).
It should be noted, however, that this approach is only suitable or activities
which do not have any external predecessors (Figure 15.2).

For use by APM individual 116

and corporate members only
 Schedule design

Figure 15.1 Establishing steps/objective criteria

Figure 15.2 Suitability or steps/objective criteria

For use by APM individual 117 and corporate members only
 Planning, Scheduling, Monitoring and Control

I the scheduling sotware does not have a step unction embedded, then it is
advised to capture the objective criteria in a notes eld held within the tool or
transparency and visibility.

15.3.5 Time Units

Time units are a scalable measure o time used to dene the duration o activities
and the impact o change within the project schedule. Choosing an appropriate
time unit depends on the nature o work being undertaken; however, it is
important to use only one type when developing the schedule.
The most common types o time unit are days or hours. These units are
generally suitable or most projects; however, when planning very long, high-level
projects it may be more appropriate to use weeks. In certain circumstances,
which are likely to be high-risk and/or relatively short-duration works, it may be
appropriate to schedule in minutes. Typical examples would be shut-downs or
maintenance o a process plant, or a closure on a live railway.

15.3.6 Calendars
Calendars are used to dene the amount o working and non-working time
throughout the duration o the project. They are used to determine when the
work will be carried out, e.g. night-working or weekends only.
Generally, they show the normal working week, e.g. Monday–Friday,
8.00–5.00 with 1 hour or lunch. This would result in an 8-hour day and
40-hour working week. In the UK, the 8 standard bank holidays would
be included. Industry holidays are usually 1 week at Easter and 2 weeks at
Christmas.
Consider the level o time unit being used (i.e. an 8-hour day may be used,
whatever the real hours are) and decide what is appropriate or the project. In
other words, and in general terms only, work is oten planned in days regardless
o the sotware that may calculate duration in hours.

15.3.6.1 General considerations

• Permitted working hours, e.g. airports, railways etc.
• Diering shit patterns, e.g. night-shits or 7-day working.
• Restrictions at particular times or or particular works: or example, some
works may be undertaken at any time, while some require particular times,

118
For use by APM individual and corporate members only
 Schedule design

e.g. booked or planned shut-downs or engineering hours (times when the

current is switched o on a railway).
• Planned shut-downs or routine maintenance.
• Resource working hours or availability.
• In addition to the project calendar, additional specic calendars can be set up
to cater or individual suppliers, specic customer availabilities, specic
resources, specialist acilities, etc.
• Calendars can dene reporting cycles – or example, rail industry periods.

15.3.6.2 Holidays and non-working days

Consider the country or religious parties involved:

• Calendars should contain the relevant bank holidays and weekends.

• Where relevant, they should include any known actory/site shut-downs. For
example, some Jewish developers/contractors may close their sites on key
Jewish holidays.
• Other religious holidays to consider could be not only in the Middle East, but
also in Europe, India, the US, etc.
• Be careul when setting up calendars. For example, the national holidays in
France: some o the dates stay consistent each year, so that i the date alls on
a Saturday or Sunday it is not a national holiday.

15.3.6.3 Applying to schedules

Consider how/whether dierent calendars are applied to the schedule:

• A schedule can use multiple calendars, or both activities and resources.
• Take care that calendars are correctly assigned, dened and maintained.
• It is important to clearly dene which activities take place on which calendar.
• An activity cannot take place on multiple activity calendars; i there is a need
to show such working, then the activity needs to be duplicated so that
each individual activity occurs solely on one calendar. An example o this
could be a situation where a joint team are working on a piece o work
shared between two nations, say the UK and Spain. The Spanish take
most o August o on holiday, whereas the UK continues to work.
Separate calendars, and hence separate activities, would be needed to
show this.

119
For use by APM individual and corporate members only
 Planning, Scheduling, Monitoring and Control

• Leads and lags should not have calendars allocated to them. I a logic link
needs to be on a specic calendar, then this should be an activity (dummy
task).

15.3.6.4 Ordinal dates

In some cases it will be appropriate to display a number, i.e. Week 1, Week 2 etc.
(ordinal dates), rather than calendar dates; or example, when tendering or work
with an uncertain start date. It will be important in these cases to be aware o the
eect o holiday periods and other working restrictions on the overall duration o
each deliverable and the overall project.

15.3.7 Project, activity and resource coding

Project, activity and resource codes are a fexible and powerul aid to optimise
presentation o the project schedule. They are generally used to view and analyse
the schedule data in multiple ways depending on the specic needs o the
audience.
Applying project codes such as location, sponsor, phase, asset group, etc. can
also help to view project and group programme or portolio data in order to
manage inormation eciently at an enterprise level. They can also be useully
used to identiy dependencies and interaces.
When dening the project WBS, CBS, OBS and RAM, there will be a need to
sort data by dierent groups. By assigning values to activities, it is possible to
quickly view and analyse data in the most appropriate way.
Coding can be applied to specic activity resources in order to dierentiate
between cost accounts, contracts and resource unit inormation, i.e. concrete,
track, pipe, cable, etc. This inormation can then be extracted or monitoring and
control.
It is important to dene the level o coding required in the nal schedule prior
to commencing work on the schedule. This enables easier regular analysis and
reporting.
A useul tip is to insist that coding elds are populated against every activity,
using a ‘N/A’ code or those that have no applicable code. This will mean
omissions in coding are easily seen and corrected.

120
For use by APM individual and corporate members only
 There are a number o techniques o scheduling, and these are allied to methods
o presentation. Scheduling is undertaken using logic-linked networks and the
critical path method o analysis. This is based on either the arrow diagram method
or, as is more usual in modern sotware, the precedence diagram method. The
network methods are central to all others in modern planning; the other
techniques discussed here may be considered to be alternative means o present-
ation, albeit they were originally independent techniques.

16.1 Creating a critical path network

A network is essentially a fow chart which describes the logical sequence o
activities.

16.1.1 Denition o critical path method

The critical path (longest path) is a series o activities or tasks within a project,
none o which can be delayed without aecting the project end date.
It is possible or a network to have more than one critical path i there are
multiple key or sectional completion dates. It is also possible or multiple critical
paths to exist leading to a single completion date.

16.1.2 Purpose o critical path network

The critical path network must allow you to understand the logical fow o work
and how the individual activities relate to each other. As a result o the scheduling
process, the network will dene:
121
For use by APM individual and corporate members only
 Planning, Scheduling, Monitoring and Control

• the start and nish dates o activities;

• the completion date o the project;
• total and ree foat;
• the critical path;
• areas o risk (such as bottlenecks o logic).

16.1.3 Methods o constructing a critical path

Critical paths may be calculated using a number o techniques that may
alternatively be known as precedence diagrams, logic diagrams, PERT (program
evaluation and review technique), or deterministic network diagram.

16.1.3.1 Precedence diagram method

There are two principal methods; the rst method, which will be more amiliar to
users o contemporary sotware, is the precedence diagram method (PDM), in
which the node designates the activity, and the logical interace is represented by
the arrow (Figure 16.1).
This method is sometimes known as AON (Activity on node).

Figure 16.1 Example o the precedence diagram method (PDM)

16.1.3.2 Arrow diagram method

The second method, now superseded, is the arrow diagram method (ADM), in
which the activity is shown on the arrow, as illustrated in Figure 16.2.

122
For use by APM individual and corporate members only
 Building the schedule: network analysis

Figure 16.2 Example o the arrow diagram method (ADM)

This approach only allows nish to start relationships.

‘Dummy’ activities are needed to complete the logic in these diagrams. Task D
cannot take place until Tasks B and C have completed; thereore, a dummy task
is required to link node 4 to the start o node 3.
This method is sometimes known as AOA (Activity on arrow).

16.1.4 Inputs into a critical path analysis

Prior to undertaking a critical path analysis, the project needs to be broken into its
constituent parts and dened in terms o the activities required. The interde-
pendencies between these activities must be dened such that all activities (apart
rom the starting activity or milestone) have at least one predecessor, and each
activity, apart rom the nal activity or milestone, has at least one successor. The
critical path can then be constructed, but, in order to calculate the overall
duration, the duration o each activity needs to be calculated or otherwise
estimated. It is also worth noting the ollowing:

• Care needs to be taken to correctly dene the predecessor activities and

ensure that the preceding activities deliver what is required o them.
• Dialogue is required to ensure the logical fow o activities is correctly dened.
• Lags can be introduced between activities to more accurately model the reality
o the logic. Lags are to be avoided where possible because they are invisible
on the Gantt chart.
• Denition o the project’s logic is oten an iterative process.

123
For use by APM individual and corporate members only
 Planning, Scheduling, Monitoring and Control

16.1.4.1 Time analysis

Time analysis is the process that calculates the timerame in which each activity
can take place. It identies the minimum time in which the network can be
completed based on the activity durations and the logical links dened.
The terminology used to describe the timerame is dened in Figure 16.3.
Time analysis identies the activities which are critical to the timely completion
o the network and the latest dates at which activities can be completed without
delaying the end date o the network. It consists o ve steps, but beore we go
through this process it is useul to dene the terminology used when undertaking
a critical path analysis.

16.1.5 Introduction to creating a network analysis

The ollowing paragraphs describe a step-by-step guide to constructing a
network.

• Step 1: Create a logical network.

• Step 2: Forward pass.
• Step 3: Backward pass.
• Step 4: Calculation o total foat.
• Step 5: Identication o critical path.

Further detail on types o foat, logic and constraints ollow.

Figure 16.3 Typical time analysis coding

Note: ES = Early Start; EF = Early Finish; LS = Late Start; LF = Late Finish.

124
For use by APM individual and corporate members only
 Building the schedule: network analysis

Project management teaching oers two alternative methods o calculating

the numbers contained in network analysis. This guide has opted to use the
method used by most planning sotware, starting rom day 1 o the project (which
planning sotware usually reerences as a date rather than an ordinal date).
Note: An alternative method used in teaching begins with the concept o day
zero, and ater the step-by-step guide an illustration o a completed network is
shown or reerence purposes, in section 16.1.11.

16.1.6 Step 1: Create a logical network

The rst steps in building the network are the identication o the activities
required, and the identication o the dependencies, or logic, between them.
The duration that each activity will take must be estimated, and it will then be
possible to construct a basic network with this inormation (Figure 16.4).

Figure 16.4 Step 1: create a logical network

16.1.7 Step 2: Forward pass

The orward pass calculates the earliest start and nish dates or each activity,
based on the activity durations and their logic. For the ollowing example, the
diagram below illustrates this base inormation (Figure 16.5).

125
For use by APM individual and corporate members only
 Planning, Scheduling, Monitoring and Control

The rst activity is given an early start date (Day 1). With the duration, it is then
possible to calculate the early nish date (Day 10). Thus, early start + duration
= early nish.
The second activity can start ater the rst activity has completed (Day 11).
This calculation proceeds orward through the network, eventually calculating
the earliest possible nish date or the whole network o activities.
Note that i an activity is dependent on more than one activity, it is important
to remember to ensure that the calculations have been completed on all preceding
activities. The ull orward pass will, thereore, be calculated in Figure 16.5.

• Where two or more dependencies converge at a succeeding activity, there

may be a number o dierent earliest nishes (EF) to use to establish the
earliest start (ES).
• The logic states that all preceding activities must be complete or the
succeeding activity to start, so the highest preceding EF is used to determine
the succeeding ES.

Figure 16.5 Step 2: the orward pass calculation

16.1.8 Step 3: Backward pass

The backward pass calculates the latest start and nish dates or each activity,
based on the activity durations and their logic. It is essentially the opposite o the
orward pass.

126
For use by APM individual and corporate members only
 Building the schedule: network analysis

Starting rom the last activity in the network, the latest nish is set to the same
value to determine the early nish. Then rom the late nish the duration is
subtracted to calculate the late start date. This calculation then proceeds
backwards through the network. On completion o the backward pass, the
resulting data appears as in Figure 16.6.

• Where two or more dependencies go back to a preceding activity, there may

be a number o dierent latest starts (LS) to use to establish the latest nish
(LF).
• The logic states that all succeeding activities must be able to start once the
preceding activity is complete, so the lowest succeeding LS is used as the
preceding LF.

Figure 16.6 Step 3: the backward pass

16.1.9 Step 4: Calculation o total foat

Having completed the orward and backward passes, total foat can be calculated
(Figure 16.7); it is simply the latest nish less the early nish, and is expressed in
the relevant time unit (number o days, or example).
Once foat is calculated, the critical path also becomes apparent, as the critical
path is the chain o activities with zero foat, as illustrated in Figure 16.8. Thus, in

127
For use by APM individual and corporate members only
 Planning, Scheduling, Monitoring and Control

the example the critical path is Task 1–Task 2–Task 3–Task 6. Any delay to any o
these activities will delay the completion o the project.
Note also that, in the example below, a delay o 2 days to Task 4 and/or Task 5
will also delay the project, and will also have the eect o changing the critical
path to Task 1–Task 4–Task 5–Task 6.

Total foat = late nish – early nish (TF = LF – EF)

Figure 16.7 Step 4: Calculation o total foat

16.1.10 Step 5: Identication o critical path

Once the foat has been calculated, the critical path can be identied by tracing
the path with zero days’ foat through the schedule, as shown in Figure 16.8. It is
usual to highlight the importance o the critical activities; the critical path activities
and critical logic links are shown in red.
There are instances where the critical path may not be dened simply by those
activities with zero foat. One reason could be that the schedule contains a variety
o calendars, which will aect the foat calculations. For example, a 7-day calendar
or curing o concrete may be included. Thereore, a better denition would be
the ‘longest path’ through the project (Figure 16.9).

128
For use by APM individual and corporate members only
 Building the schedule: network analysis

Figure 16.8 Step 5: Identication o critical path

Figure 16.9 Longest path calculations

129
For use by APM individual and corporate members only
 Planning, Scheduling, Monitoring and Control

16.1.11 Training in network analysis: a note

Training o network analysis takes two distinct orms. First, ollowing the method
outlined above, it is taught that early start + duration – 1 = early nish, to enable the
project to start on Day 1, not Day 0. (Similarly, late start – duration + 1 = late start.)
The second method adopts a more purely mathematical approach, as ollows
(Figure 16.10).
The network commences on Day 0 instead o Day 1, which gives dierent
start dates, as illustrated below. The end dates remain the same. However, Day 0
does not exist, so this method does not properly represent reality. Planning
sotware will always work with the Day 1 method.
When transerring the classroom teaching to planning sotware, the practical
calculation should be allowed to occur and the absence o a day zero must be
explained.

Figure 16.10 The alternative method o calculation in a network

16.1.12 Float
Float is sometimes reerred to as ‘slack’, or example in some scheduling sotware,
but this guide will use the more widely accepted term ‘foat’. Figure 16.11 illus-
trates foat types.

130
For use by APM individual and corporate members only
 Building the schedule: network analysis

16.1.12.1 Free foat

Free foat is spare time at the end o an activity that can be used without delaying
its successor activity.

16.1.12.2 Total foat

Total foat is the amount o time that an activity can be delayed without aecting
the network end date. (It is worth noting that total foat is the amount o foat that
typically applies to a sequence o activities on that path, and, i used up on the
current activity, will not be available or uture activities on the particular path).

16.1.12.3 Negative foat

Negative foat occurs in a schedule when you do not have enough time to
complete the project by the desired (and constrained) completion date. In order

Figure 16.11 Float types

131
For use by APM individual and corporate members only
 Planning, Scheduling, Monitoring and Control

to achieve the required date, you will need to recover the time in uture activities/
sequences.

16.1.12.4 Float ownership

On some complex projects, it may be appropriate to share foat between teams
(e.g. on an international project the foat between US and UK elements o the
schedule has a share arrangement, with teams obliged to notiy each other when
they have used up their element). Extreme care should be taken with this
approach, and acknowledgement o the ownership o foat should be in
accordance with the contract conditions.

16.1.12.5 Monitoring o foat

Float use should always be monitored so that there is an awareness o the critic-
ality o all works; work that is not critical will become so i it is suciently delayed.
I this is to be the case, sudden shits in the critical path should not come as a
surprise i the loss o available foat has been careully monitored and brought to
the attention o the relevant people.

16.1.13 Types o logic linking

There are many relationship types available or linking activities logically. When
developing the schedule, it is possible to use multiple types o logical relation-
ship. It is important to remember that the purpose o scheduling is to orecast
accurately, and as such choosing the correct relationship type is critical to building
a schedule that is t or purpose. The most common relationship types are:

16.1.13.1 Finish to start relationships

This is the preerable orm o logic: it implies that the schedule has been broken
down to an acceptable level o detail, and is the easiest logic to understand and
analyse. It creates clear foat paths. It is advisable to use this relationship when
developing schedule logic, as it provides the simplest schedule and the most
robust method o determining project total foat.
In Figure 16.12, a nish to start relationship shows that activity 1 has to be
100% complete to allow activity 2 to start. This also means that a delay to activity
1 will have a direct impact on the start date o activity 2.

132
For use by APM individual and corporate members only
 Building the schedule: network analysis

Figure 16.12 Finish to start relationship

16.1.13.2 Start to start relationships

A start to start relationship, as shown in Figure 16.13, shows that once activity 3
has started, activity 4 can also start. This does not necessarily mean that activity 4
must start on the same day – it means that activity 4 can now start at any time in
the uture.
Note: both activities will also need a successor, and activity 3 will need a
predecessor to complete the logic.
This relationship type is used when an activity can only be completed when its
predecessor has started; e.g. manuacture may be able to commence once the
delivery o necessary components has started, but it is not dependent upon
the delivery being completed. Once again, parallel working opportunities must be
possible and validated by the project team beore being used in the schedule.

Figure 16.13 Start to start relationship

133
For use by APM individual and corporate members only
 Planning, Scheduling, Monitoring and Control

Care should be taken when using this type o relationship. It is not as simple as
the Finish to Start link. I activity 3 starts, but is stopped or slows down or any
reason, can activity 4 really proceed unhindered? Thus these links may oten be
used with:

16.1.13.3 Finish to nish relationships

A nish to nish relationship, as shown in Figure 16.14, shows that once activity
5 has nished, activity 6 can also nish. This means that these tasks can start inde-
pendently o each other, but activity 6 cannot nish until activity 5 has completed.
Note: both activities will also need a predecessor, and activity 6 will need a
successor to complete the logic.
This relationship type is used when an activity can only be completed when its
predecessor has nished. It assumes that activities can proceed without completion
o their predecessors and that parallel working is possible; e.g. you can start
putting a planning application together whilst site surveys are being undertaken,
but you cannot complete the application until you have all the survey inormation.
Parallel working can successully be used in order to accelerate a project. However,
it is important to remember that parallel resources are required as well.

Figure 16.14 Finish to nish relationship

16.1.13.4 Start to nish relationships

This is a very rare link and should be used with extreme caution, i at all. Its use is
oten an indicator o poor scheduling practice, as it is usually illogical (that activity
8 cannot nish until ater activity 7 has started) (Figure 16.15). For this reason, it
is normally seen as bad scheduling practice to use this kind o linking.

134
For use by APM individual and corporate members only
 Building the schedule: network analysis

Figure 16.15 Start to nish relationship

It is dicult to give an example o where such a link could be valid. (An example
sometimes given is activity 7 in Figure 16.15 being ‘mix epoxy resin’ and activity
8 being ‘apply epoxy resin’, but it is hard to imagine planning at this level
o detail in most situations.) These types o links are likely to be used as a
convenience rather than a true description o logic. For this reason, they should
be avoided.

16.1.14 Lags and leads

A lag is the period o time between activities that does not represent any work. It
can be used as part o any type o logical link (nish to start, start to start, etc.).
A lead is a negative lag, and by denition illogical, as time only runs orward
(so ar as we know).
The scheduler also needs to beware o the eect o calendars on lags. An
example could be non-activities such as concrete curing (which is one potential
use o a lag, as no work is represented). The calendar relating to the lag in this case
would show a 24-hour, 7-day a week work pattern. It is unlikely that the preceding
(or ollowing) activities will work to the same calendar, and it is worth noting that
not all scheduling sotware can distinguish the calendar being applied to a lag.
Lags and leads are not activities and should not be used as a substitute or an
activity. They are generally used in low-density planning, and as detail develops
they should be removed.
The use o lags and leads should be avoided as ar as possible. Whilst use o
lags is common practice within scheduling, excessive reliance on lags, coupled
with their inherent lack o visibility, can make them dicult to status and thus
undermine the overall accuracy o the schedule. It is thereore preerable to use

135
For use by APM individual and corporate members only
 Planning, Scheduling, Monitoring and Control

a dummy activity rather than a lag. This will have the added advantage that an
appropriate calendar can be applied to the dummy activity.
The use o lags and leads is thereore, in most cases, poor scheduling practice,
and they must not be used in high-density scheduling, because as previously
stated they are illogical. (Figure 16.16 illustrates that activity 12 cannot start until
2 days beore activity 11 completes, but this is an illogical statement – the uture
is uncertain, but or this to work you have to know 2 days in advance that Activity
11 is going to complete on a particular day.)

Figure 16.16 Summary o types o logic and lags

16.1.15 Use o constraints

Activity constraints can be used to x an activity at a particular point in time. All
activities should ideally be linked by logic, but in some instances this may not be
possible – or desirable; e.g. the start o something where nothing precedes it.
‘Start on site’ or ‘appoint contractor’ may be examples. Similarly, nish dates may

136
For use by APM individual and corporate members only
 Building the schedule: network analysis

need to be xed without anything ollowing them, e.g. sectional completion

dates o various sections o work.
Within scheduling sotware there is usually a selection o dierent ways o
adding a constraint date, as described below:

• as late as possible;
• mandatory start;
• mandatory nish/deadline;
• (must) start on;
• (must) nish on;
• start on or ater/start no earlier than;
• nish on or ater/nish no earlier than;
• start on or beore/start no later than;
• nish on or beore/nish no later than.

Note: The dierent scheduling sotware may use slightly dierent terminology
or these constraints; or example, tick-boxes; ‘holding pin’; ‘start on a new day’.
It is important to understand the ways scheduling tools use constraints. This is
particularly important where you need to import schedules rom dierent sources
into the master schedule.
Care should be taken in the use o multiple constraint dates, as they can give
misleading results when the project is scheduled, especially i used in combination.
For example, using ‘start on or beore’ and ‘start on or ater’ constraints on the
same activity or logical sequence would create a result you might not anticipate
or notice i you have not appreciated the combination.
It should be noted that i a constraint date is imposed on an activity then foat
calculations will use that constraint date to calculate the ‘late nish’ date or the
activity.
I there is not enough time to do the work and to meet the constraint date,
then a negative foat value will be calculated. Conversely, i there is more than
enough time to do the work and meet the constraint date, then a positive foat
value will be generated. It is worth noting that dierent toolsets (or scheduling
sotware) can handle this in dierent ways. Problems may arise when moving
data rom one sotware product to another. Dierent results are very likely except
in the case o very simple schedules.

137
For use by APM individual and corporate members only
 Planning, Scheduling, Monitoring and Control

16.1.16 Types o constraints

In Figures 16.17–16.25, the foat calculated assumes we are considering the
critical path, or the link into the critical path. This is to simpliy the explanation;
the principle applies to all foat paths.

16.1.16.1 As late as possible constraint: ALAP

ALAP should only be used in circumstances where an activity should be done –
as the name suggests – as late as possible. It means that any foat on that activity
(or milestone) will have been used up and thereore may make the item critical.
(Note: schedules should generally be built so that all activities, when scheduled,
show the earliest dates they can be carried out – as soon as possible). Scheduling
tools typically deault to planning tasks as soon as possible unless the user
species an alternative planning approach or constraint.
This type o constraint may also be known as a ‘zero ree foat’ constraint.

Figure 16.17 ‘As late as possible’ constraint

138
For use by APM individual and corporate members only
 Building the schedule: network analysis

16.1.16.2 Finish on constraint

Holds an activity at the desired completion date. It will be overridden by preceding
logic. Total foat will be calculated against the constrained date.

Figure 16.18 ‘Finish on’ constraint

139
For use by APM individual and corporate members only
 Planning, Scheduling, Monitoring and Control

16.1.16.3 Finish on or ater constraint

Allows the activity to nish later than the date entered, so does not create
a critical activity. But will not permit the activity to nish earlier – even i the
works are completed early. Total foat will be calculated against the network
completion date.

Figure 16.19 ‘Finish on or ater’ constraint

140
For use by APM individual and corporate members only
 Building the schedule: network analysis

16.1.16.4 Finish on or beore constraint

Makes the activity critical i it nishes on or ater that date. But will allow it to
nish early.

Figure 16.20 ‘Finish on or beore’ constraint

141
For use by APM individual and corporate members only
 Planning, Scheduling, Monitoring and Control

16.1.16.5 Mandatory nish constraint (must nish on)

A rigid constraint that cannot be moved when scheduled. Can be used to create
a critical path or to show negative foat i works are slipping or in delay. (Note:
should not be used casually; it is always better to use ‘nish on or ater’ or ‘nish
on or beore’.) It is oten considered to be bad scheduling practice to use this
constraint.

Figure 16.21 ‘Mandatory nish’ constraint

142
For use by APM individual and corporate members only
 Building the schedule: network analysis

16.1.16.6 Mandatory start constraint

Makes the activity critical, and consequently the predecessor also becomes
critical when scheduled. (Note: should not be used casually; it is better to use
‘start on or ater’ or ‘start on or beore’.)

Figure 16.22 ‘Mandatory start’ constraint

143
For use by APM individual and corporate members only
 Planning, Scheduling, Monitoring and Control

16.1.16.7 Start on constraint

As or ‘nish on’, it cannot be moved when scheduled, and thereore creates a
critical path through the preceding activities. (Note: should not be used casually;
it is better to use ‘start on or ater’ or ‘start on or beore’.)

Figure 16.23 ‘Start on’ constraint

144
For use by APM individual and corporate members only
 Building the schedule: network analysis

16.1.16.8 Start on or ater constraint

Allows the activity to start later than the date entered, so does not create a critical
activity. But will not permit the activity to start earlier – even i the preceding
works are completed early.

Figure 16.24 ‘Start on or ater’ constraint

145
For use by APM individual and corporate members only
 Planning, Scheduling, Monitoring and Control

16.1.16.9 Start On or Beore Constraint

Makes the activity critical i it starts on or ater that date. But will allow it to
start early.

Figure 16.25 ‘Start on or beore’ constraint

146
For use by APM individual and corporate members only
 Building the schedule: network analysis

16.1.17 Displaying networks on bar charts

In scheduling sotware, the network is created in the way described in the
preceding sections, generating the start and nish dates, together with any foat
values or each activity. It is possible in some scheduling sotware to display the
schedule as a network, and this clearly (i well presented) shows the logical
relationships between the individual activities. A more usual representation is
in the orm o a bar chart (Figure 16.26), which has the advantage o giving a
visualisation o where the activities sit in time. Oten it is much harder to clearly
display the logic in this view. However, most scheduling sotware packages give
the users the ability to show or not to show the logic between the activity bars
and milestones.

Figure 16.26 Bar chart display

16.2 Estimation o durations

The schedule is a model o the uture based on the project objectives and outputs.
This means that, until such time as the schedule slowly becomes historical act,
the project team estimates how long it will take to achieve these objectives, along
with what resources are required and how much it will cost.
To schedule work accurately and eectively, it is important to have a good set
o robust scheduling assumptions. As the project moves orward and things
change, so must the assumptions. It is this iterative process that ensures that the
schedule is designed to deal with the uture needs o the project, reducing threats
and the range o possible outcomes.
There are many ways o ormulating a good set o scheduling assumptions:

147
For use by APM individual and corporate members only
 Planning, Scheduling, Monitoring and Control

16.2.1 Three-point estimates

Three-point estimates can be used to dene minimum, most likely and maximum
estimates based on assumptions and previous experience. Actions can arise to
address high variances rom this work. Monte Carlo analysis can then be used to
determine probability o the outcomes.
In this case, the high variance between the most likely and maximum duration
is such that the cause o the additional time required should be investigated. In
the example, this might be due to unseen services running through the earthworks
area. A risk concerning this uncertainty must be registered, and a mitigation
developed.

Table 16.1 Example o three-point estimate

Activity A B C

Minimum duration Most likely duration Maximum

duration

Dig Foundations 2 weeks 3 weeks 8 weeks

16.2.2 PERT (programme evaluation review technique)

PERT is a recognised ormula to determine activity durations rom the three-point
estimate, optimistic (O), most likely (M) or pessimistic (P). It produces a weighted
average leaning to either the optimistic or the pessimistic, depending on the size
o the variance. Once again, signicant variances between duration estimates
should be explored as potential risks.

Table 16.2 Example o PERT calculation

Activity O M P PERT

Minimum Most likely Maximum

duration duration duration

Dig oundations 2 weeks 3 weeks 8 weeks (O+(4*M)+P)/6 3.7

weeks

Note: the PERT calculation noted above is the most commonly used, although there are alternative
calculations, such as the three-point estimate, which is calculated as (P+M+O)/3.

148
For use by APM individual and corporate members only
 Building the schedule: network analysis

16.2.3 Comparative
Projects o a similar type are used to estimate durations, making appropriate
adjustments or scope (i.e. dierences in quantities). Other specic dierences
such as logistical dierences, local climate, and local resource availability must be
assessed and adjustments made accordingly.

Table 16.3 Example o comparative estimates

Activity Area Actual duration

Previous project 2,000 cubic metres 3 weeks

Dig oundations Area Estimated duration

Our project 3,000 cubic metres 4.5 weeks

16.2.4 Benchmarked data

This utilises an existing database o project and activity inormation regarding
timescales and costs or completion. Using this data, average cost and timescales
can be applied to a measurable unit and then multiplied by the number o desired
units to ascertain an approximate duration. This approach requires a library o
reliable data and is best applied to projects where local or project-specic
conditions do not provide signicant reasons or deviation. Caution needs to be
exercised, as diering circumstances will apply to all projects, but it could be
used as initial guidance.

Table 16.4 Example o benchmarked data

Activity Project Volume Actual duration

Project A 5,000 cubic metres 6 weeks

Project B 5,500 cubic metres 7 weeks

Dig oundations Project C 10,000 cubic metres 10 weeks

Project D 7,000 cubic metres 8 weeks

149
For use by APM individual and corporate members only
 Planning, Scheduling, Monitoring and Control

16.2.5 Resource-dependent
Resource-dependent activities, although constraining, are a good way o deriving
robust assumptions. Here the limitations are around labour, plant, supply o
materials, access to site, etc.
The planner or estimator uses known outputs or the available resource to
calculate the estimated duration or an activity (see Table 16.5).

Table 16.5 Example o resource-dependent estimate

Activity Volume Resource Average Estimated
availability gang output duration

Dig 2,000 cubic metres 4 gangs + plant 250 cubic 2 weeks

oundations metres per
week

16.2.6 Expert opinion

One o the best places or assumptions is the project team or people who have
expertise in the type o work required. Bringing individuals together in workshops
to discuss activity duration, sequence and associated risks can be the best way o
producing a realistic schedule.

16.2.7 Personal experience

There is no single right way o developing planning assumptions, but one
important element is using as much relevant historical data as you can. When
doing so, it is important that you document your assumptions comprehensively.
Key project assumptions should be recorded in the risk or assumptions register,
as getting them wrong may require working in a dierent way, which may incur
time delay and increased cost.
It is undamental to the planning process that the project team are involved
when developing, iterating and signing o planning assumptions, as, i done in
isolation, this can lead to a project schedule that has not gained the buy-in o the
project team. This would be worthless as an eective tool to manage the project
and orecast outcomes.
The process o planning work as a team, will quickly derive a set o working
assumptions against which to base a preliminary schedule, starting with the

150
For use by APM individual and corporate members only
 Building the schedule: network analysis

WBS. Discreet work packages will be feshed out against the overall scope o the
project. It is important that all elements o work required to deliver the project
benets capability is included within the schedule. Other aspects to be included
are, assumptions on tasks, duration, sequence, logical dependencies, interaces
(both internal and external) and costs.
Getting a head start can greatly improve your chance o developing a good
schedule; some companies may categorise their projects by discipline or asset
type, which makes the process o using existing data much easier.
It is important to realise that assumptions are simply guesses around the
uture, and thereore can be incorrect. I a specic task is on the critical path, then
this may cause delay or increased cost to the project. Key assumptions around
activities that can have this eect should be assessed or impact and entered into
the risk register. The register should also record the quantied impact in time and
cost (along with the corresponding mitigation strategy) which can assist in getting
additional unds and/or resources.

16.2.8 Social media

With the increasing prominence and continued evolution o the internet and
social media in the workplace, it makes sense to access all planning inormation
available when developing schedules. Caution should be exercised in any
resulting inormation received, particularly with regard to any biases or infuences
generated by the type o audience.

16.3 Resourcing the schedule

Some organisations have to share resources around the projects they undertake.
Consequently the planning o resource usage becomes vital, particularly when
resources are limited due to either general scarcity (perhaps because o the wider
market) or scarcity o specialist skills. In any project, an assessment o the
resources required, and particularly a measure o the quantity o resources
required, will be a check on the validity o plans. For example, a schedule created
using a network analysis method will consider resources to be unlimited. This is
unlikely to be the case in most instances. Introduction o resources to the project
should be planned in a realistic manner – sudden increases in resources are not
easy to achieve or manage. Similarly, it is not likely that a large mass o resources
will suddenly be removed rom the project.

151
For use by APM individual and corporate members only
 Planning, Scheduling, Monitoring and Control

16.3.1 Denition o resources

Resources can be one or more o the ollowing:

• labour;
• plant or equipment;
• materials;
• acilities, such as specialist test sites.

In some cases, e.g. high-level budgeting exercises, you may wish to use money
as a discrete resource which is not aligned to labour, plant and equipment, or
materials. Each o the resources may drive the project pace by constraining the
output that can be achieved – or example, a spending cap to a point in time will
determine how much work can be completed up to that point. Where resources
do constrain the project delivery rate, they are known as ‘critical resources’. It is
likely that the relative importance o each will vary depending on project type,
but also rom project to project.
An important consideration may be the relationship between resources and
project logistics. Resources generally require space within which to operate,
whereas materials need space to be stored.

16.3.2 Purpose o resourcing the schedule

Resourcing o the schedule is a vital stage o the process between creating the
network, running a critical path analysis, and issuing the results as the working
schedule. It is required in order to:

• determine (low or medium density) or validate (at high density) the duration o
each activity;
• promote the consideration o the fow o resources (people, trades or sub-
contractors) within the schedule, which will lead to more realistic and
achievable outputs;
• lead to an understanding o peak resource requirements, including human
resource requirements, unding requirements and peak material supply
requirements;
• ascertain the availability o specialist equipment (which may be actored in by
use o resource calendars) – this may require advance booking;

152
For use by APM individual and corporate members only
 Building the schedule: network analysis

• lead to an understanding o logistical requirements: welare accommodation

or the workorce, adequate working space or labour and plant;
• demonstrate the robustness o the schedule to other parties.

16.3.3 Process o resourcing the schedule

16.3.3.1 Estimate the quantity o resources required
Estimates are made using previous projects, experience or standard outputs, as
required. These techniques are particularly useul at low or medium-density
scheduling. At high-density scheduling, it is more useul to undertake calcula-
tions in line with the ormulae shown in Figure 16.27. This approach means that
the required resources are part o the duration calculation or each activity, and
can be allocated to each activity.

Figure 16.27 Establishing the duration o a task based on resource

16.3.3.2 Team sizes

Optimum team sizes or dierent types o work should be acknowledged when
determining resources. This being particularly relevant where crews are made up
o ront-line production and back-up – bricklayers and their labourers, or
example. Particular sets o circumstances may vary the required make-up o such
gangs. Specialist advice should be sought in these circumstances.

16.3.3.3 Resource allocation

Resources are allocated to each activity within the schedule, so that when this
exercise is complete the sum o all the activities represents the total quantity o
resources in the project (in terms o budget, labour, plant).

153
For use by APM individual and corporate members only
 Planning, Scheduling, Monitoring and Control

16.3.3.4 Resource proles

Resource demand can now be predicted by looking at histograms – peak require-
ments can be established:

Figure 16.28 First drat resources prole

The diagram above (Figure 16.28) shows resource levels peaking at 42, but
the build-up to those peaks does not look realistic in most circumstances; an
exercise is required to smooth the build-up and fow o resources.

16.3.4 Resource smoothing

I, as in the example above, the results do not indicate a sensible ramp up
and down o resources, it may be necessary to consider resource smoothing.
This is the process o smoothing demands so that practical overall levels are
achieved, and also that resources are optimised to fow rom one piece o work to
another.
Resource smoothing needs to be considered on a resource-by-resource basis.
When considering human resource, this may mean analysing the requirements
or individuals, but it is more usual to analyse by resource type – proession or
trade, or example.

154
For use by APM individual and corporate members only
 Building the schedule: network analysis

The smoothing process should start by initially considering those activities

with ree foat, as moving these will not have an eect on other activities. Ater
the ree foat has been considered, it may be necessary to consider the use o
total foat. This exercise will become iterative, as the eects o delaying activities
with no ree foat but some total foat will need to be careully analysed. All
smoothing will need to be done within the early and late envelopes or each
activity; otherwise the project end date is likely to be compromised.
Figure 16.29 shows the same project as Figure 16.28 above, but this time with
optimised resources (resource-levelled chart shown in blue).

Figure 16.29 Resource-smoothed histogram

Other considerations will be the amount o available resources; where

resources are nite, these need to be considered alongside the demand. In Figure
16.30, the orange line indicates the resource limit and shows that, despite the
resource-levelling exercise, demand still outstrips availability or a period o time.
Management action will be required to solve the shortage.
Resource levelling may be achieved by:

• Redening the scope o the activities to be undertaken by the particular

resource concerned. In simple terms, this might mean giving some o the work
to an under-utilised resource.

155
For use by APM individual and corporate members only
 Planning, Scheduling, Monitoring and Control

• Redening the specication. This obviously may compromise the quality o

the nal product.
• Increasing task duration to reduce the overall resource requirements.
• Increasing resources on earlier tasks to bring workload orward, such that
peaks in the uture are reduced. This will have cost, and possibly quality,
implications.
• Delaying non-critical work to reduce demand at peak time – i.e. using ree and
total foat to optimise the schedule.

Figure 16.30 Resource-levelled chart with resource limit

16.4 Horizontal and vertical integration

o schedules
16.4.1 Horizontal integration
Horizontal integration is the application o logic and the checking o logic through
the delivery o products rom one part o the process to another. Eectively, it will
lead rom the start through to the completion o the project. Tracing the schedule
horizontally ensures that:

156
For use by APM individual and corporate members only
 Building the schedule: network analysis

• The schedule is correctly logic-linked.

• The schedule contains all o the scope.
• The schedule identies the interace milestones between dierent parties –
places where a piece o completed work is passed rom one party to another.

16.4.2 Vertical integration

Vertical integration is the process that conrms that the data at dierent levels o
detail is consistent and comprehensive. It should conrm:

• that all schedules cover all the scope (as appropriate to them)
• that all data is consistent between schedules (dates, logic, etc.).

Thus, it allows schedules to be viewed at dierent levels o detail, as is appropri-

ate or each viewer.

16.5 Scheduling interaces and dependencies

Managing project interaces is a undamental part o successul project manage-
ment. Whilst it is relatively straightorward to manage a single schedule and its
associated dependencies, in most cases there will be deliverables by the project
to parties outside the direct control o the project team as well as enabling
products or activities required by the project.
It is also possible that you may need to manage many projects that together
orm an integrated programme or portolio, and dependency management
presents a structured and controlled way o managing change across projects.
It revolves around our key stages:

• identication;
• coding;
• integration and impact analysis;
• impact resolution.

16.5.1 Identication
The project PBS, WBS and RACI will help identiy interaces, as they give
a high-level view o work packages, as well as their interaces with external

157
For use by APM individual and corporate members only
 Planning, Scheduling, Monitoring and Control

departments or projects. They should also include a list o stakeholders outside

the project who may infuence the critical path.
Ensuring that all members o the team are consulted during the identication
phase is crucial, as it only takes one missed dependency to introduce delay to the
project. A group workshop is a good way o generating dialogue, as one person’s
thought process may stimulate another’s.
It is important to note that this process is iterative and should be carried out at
the start o each project lie cycle as more becomes known about the project and
schedule detail is increased.

16.5.2 Coding
Given the size and complexity o modern projects, robust codiying o interaces
is recommended. This could be done with an appropriate activity ID or an activity
code. Careul thought must be given to ensuring the coding and naming conven-
tions. It is best to use abbreviations that are readily understood by those reading
them (i.e. they relate to the project and work package), thus aiding identication
and communication. Given that in a project there will be many hundreds o inter-
aces, this can greatly increase the chances o slippage due to external infuences.
An example dependency code may be:
‘INTPROJ0011.1.1001A’, where:

• INT=Interace;
• PROJ001=Project ID;
• 1.1.1=Related WBS ID;
• 001=Interace No;
• A=’Deliver By’ interace.

In the case o interace IDs it is a good idea to use both A and B, which
denotes whether it is a ‘deliver by’ (A) or a ‘need by’ (B) interace. In the
example given, INTPROJ0011.1.1001A would have a corresponding partner,
INTPROJ0011.1.1001B.
It is important to note that, even though there are two separate interaces, they
are undamentally the same thing, and simply represent two separate points o
view about when a single event will occur or the purpose o managing variances.
Some interaces may also include other activity codes, which may denote
project lie cycle, location and department, but the activity ID will ensure it is
visible on a standard layout and is easily picked out rom the project schedule.

158
For use by APM individual and corporate members only
 Building the schedule: network analysis

16.5.3 Integration and impact analysis

Once all interaces have been identied and the related activities coded, they
need to be integrated within the project schedule. There are two primary methods
o integration – internal and external.

16.5.3.1 Internal integration

Internal integration is where interaces are held within the same project schedule,
usually within a separate WBS node and/or grouped/ltered by their activity
codes. They are logically linked to their corresponding successor or predecessor,
and their orecast date is driven by the use o constraints which are determined
by the other party (Figure 16.31).
As change happens it is directly represented within the project schedule, and
the subsequent impact is modelled throughout the project. When updating
dependency orecast dates in this way, it is important to understand the eect o
each change, so a step-by-step approach is best. However, it is important to wait
until all changes have been made beore nal analysis, due to the inherent inter-
relationships o schedule activities and interaces.
It is important to take a copy o the schedule beore updating, to enable a
comparison to be made. This highlights where the project has been impacted
and where management time and mitigation eorts should be ocused.

Figure 16.31 Internal integration milestones

159
For use by APM individual and corporate members only
 Planning, Scheduling, Monitoring and Control

This method is most useul when dealing with a single project.

16.5.3.1.1 Advantages
• Easy to see the context around the dependency, as it is already within its native
WBS node
• Ease o visibility within the project schedule ocuses the team.

16.5.3.1.2 Limitations
• Impact o changes may be dicult to analyse i the schedule is very large. In
these cases, it may be better to consider the use o the external integration
method.

16.5.3.2 External integration

External integration is where dependency relationships are held within a separate
dependency schedule (Figure 16.32). This method is extremely helpul to the

Figure 16.32 External integration milestones

160
For use by APM individual and corporate members only
 Building the schedule: network analysis

management o interaces. Not only does it provide a clear picture o all inter-
aces, but it also allows variance management and impact analysis to happen
outside the live scheduling environment. This aids schedule stability.
In this method there are a total o our separate milestones representing the
same event. Two are held within each o the project schedules in their corres-
ponding WBS nodes, and two are held within the interace schedule. When
movement occurs in interace ‘A’, the variance can be clearly seen and tracked.
Once all the interaces have been updated, you can then assess the impact by
adding logic to the dependency schedule (Figure 16.33).
It is important to ensure that all the dependences are linked to their corres-
ponding partner beore the critical path is calculated, as one dependency path
can lead through many others. Once the logic linking exercise is complete, you
can then schedule the plan (Figure 16.34).
The driving logic rom Project 1 will now fow through the dependency
schedule and into Project 2 in order to drive the schedule’s critical path. (Most
enterprise scheduling systems will have the ability to logically link across separate
projects, but system capability must be checked, as it is an essential requirement
or this method.)

Figure 16.33 Logic-linked dependency schedule

161
For use by APM individual and corporate members only
 Planning, Scheduling, Monitoring and Control

Figure 16.34 Dependency schedule driving project schedules

This method is primarily or use on very large projects, programmes or

portolios where common resources may be shared. The use o interace
milestones provides a useul way o controlling the impact o one partner’s
programme on the rest o the programme. Thus, it is an important way o
managing collaborative inputs rom dierent parties on a complex project.

16.5.3.2.1 Advantages
• Manages change in a stable and controlled way that will not disrupt the stability
o underlying projects.
• Makes schedule movement and variances easy to identiy.
• Clearly denes dependency management as an important part o the schedule.

16.5.3.2.2 Limitations
• Requires robust data quality control measures.
• Requires dedicated resources to execute and manage.

162
For use by APM individual and corporate members only
 Building the schedule: network analysis

16.5.4 Impact resolution

When dates change, it is important to understand the reason. The rst check will
be that it has not been caused by an error or misunderstanding.
The schedule data is transerred to a dependency report showing key
inormation or discussion with both project teams to ensure that issues are real
and to ocus management eort.
The report contains key inormation about the dependency and is used by the
planner, project manager or dependency manager, depending on the scale o
management required (Table 16.6).

• Dependency ID: Unique ID that only reerences either the ‘deliver by’ or the
‘need by’ event.
• Dependency name: Standard naming conventions as described in this guide
should be adhered to.
• Agreed target date: The date that has been agreed by both projects/parties
and is subject to ormal change control.
• Current orecast: Schedule logic-driven orecast date representing the most
up-to-date position.
• Variance: Dierence between target and orecast. This is compared with
the dependency threshold and rated with a RAG ormat (red, amber and
green) accordingly, to ocus management attention on the most critical
issues.
• Threshold: Number o days + or – that a dependency can move without
causing an issue with the receiving party (this can, in some cases, only apply to
movement one way).
• Reason: Driving issue responsible or the move.
• Mitigation: Action resulting rom the dependency management meeting to
resolve issue.

Table 16.6 Interace impact schedule

Dependency Dependency Agreed Current Variance Threshold Reason Mitigation
ID name target orecast (days) (days)
date

INTPROJ001 Design 16-8-18 30-8-18 -14 5 Resource Additional

1.1.1001A released resource
being
procured

163
For use by APM individual and corporate members only
 Planning, Scheduling, Monitoring and Control

I the movement is real and the project team is unable to mitigate the slippage,
then the receiving project must look to uture work to absorb delay by doing
things dierently or use available project foat. Once this has been agreed by
both projects, the new dependency date can be changed through the ormal
change control process.

16.6 Time contingencies

Time contingency is a duration o time assigned to an activity that takes into
consideration the impact o uncertainty. During the process o developing
planning assumptions, the likely impact o unoreseen events must be taken
into consideration. Sometimes a straightorward way o doing so is to assign a
percentage o the overall activity duration to the end o the activity, e.g. 10%. A
more scientic method might be to use the output o a quantied schedule risk
assessment to apportion time risk to activities.
The assessment o risk is heavily infuenced by the risk appetite o the
organisation undertaking the assessment, and this should be borne in mind.
Attitude to risk may also be very subjective, so it is important to consult as widely
as possible beore attempting to reach a consensus and making due allowances
or time contingencies.

16.6.1 Denition o buers

A buer is the term used to describe a period o time that is built into a schedule
to add greater certainty to the end date (Figure 16.35). There are three types:

• Resource buer: the additional lead time given to critical resources to orewarn
a particular resource that a critical activity is approaching.
• Feeder buer: the additional time allocated at the end o tasks within a
schedule.
• Project buer: the additional time allocated at the end o a project schedule.

16.6.2 Use o buers

Buers may be introduced into the network to provide or time contingency. In
some cases these may have contractual signicance. In certain types o project,

164
For use by APM individual and corporate members only
 Building the schedule: network analysis

Figure 16.35 Dierent buer types

this may help reduce overall project duration by allowing activities to start earlier.
This, in turn, allows the ollow-on activities to start earlier.
It is more commonly used on basic or repetitive types o project, but, with
appropriate care, may be used on all types. Full buy-in o all parties is, however,
essential, and is likely that contract issues will need to be considered. For example,
on NEC3 contracts (NEC – New Engineeering Contract) the use o time risk
allowance is specically mentioned in order to bring realism into the contractors’
schedule. The use o Buers as described is less likely to be useul on those
projects involving a signicant degree o sub-contracting.

165
For use by APM individual and corporate members only
 Planning, Scheduling, Monitoring and Control

16.6.2.1 Advantages o using buers

• It emphasises doing works as early as possible to promote earlier than planned
completion.
• It ocuses on the availability o resources and thus produces a more realistic
schedule than a pure critical path analysis (presuming that only hard logic has
been used in the CPA).
• It promotes emphasis on the critical path.
• It is appropriate or projects with basic or repetitive activities.

16.6.2.2 Limitations o using buers

• It does not recognise the ways that sub-contracts /specialist resources plan
their work. I resources are not on hand, then the advantage o an early start
cannot be made.
• Issues around contract and risk ownership need to be identied and resolved.
• There is potential or additional cost due to delay and disruption to ollow-on
trades.
• There is potential or resources to be unavailable due to workload being
repeatedly re-organised to critical activities.
• It may result in a lot o additional activities to the schedule, e.g. eeder and
resource buers, which can add complexity to the logic.
• In addition, there is a lot o extra work required in creating and maintaining the
additional activities noted above. Consider reading the existing schedule
properly instead!

166
For use by APM individual and corporate members only
 The results o the scheduling may be presented in a number o ways:

• Bar charts (sometimes known as Gantt charts), which provide a graphical

representation and may be used in conjunction with other methods. Originally
considered a method o planning, now more usually seen as an output o
network analysis.
• Line o balance charts that show the fow o resources, and acilitate the
balancing o the same.
• Time chainage charts that introduce a spatial awareness into planning the
project.

17.1 Bar charts

Bar charts are sometimes reerred to as Gantt charts, and oten orm the present-
ation method o the other techniques discussed. Activities are listed with other
tabular inormation, such as dates and durations on the let side with time intervals
over the bars on the right-hand side, where the durations are shown in the orm
o horizontal bars (Figure 17.1).

17.1.1 Presentation considerations

Consideration should be given to the complexity to be displayed and the target
audience. For example, the inclusion o logic links detracts rom the clarity o the
presented chart (as it will on many complex pieces o work). Complex schedules
may benet rom high-level, even simplistic explanations (see Figure 17.2 or an
example).

167
For use by APM individual and corporate members only
 Figure 17.1 A simple bar chart

For use by APM individual and corporate members only

 Figure 17.2 Strategic schedule o a major construction project at low density

For use by APM individual and corporate members only

 Planning, Scheduling, Monitoring and Control

Scheduling sotware may oer seemingly limitless ormatting possibilities, but

consideration must be given to the viewer. Ideally, schedules should have equal
clarity i rendered in ‘greyscale’ (black and white), i this is how they may be
printed.

17.1.1.1 Advantages o bar charts

• Clear, pictorial representation o the plan.
• Generally well understood.
• Relatively simple to create.
• Can be used to show progress.
• Can be used to plan resources.

17.1.1.2 Limitations o bar charts

• On their own, do not show dependencies.
• There is a limit to the size o schedule that can reasonably be read and under-
stood.
• Cannot easily cope with change as a result o progress or scope change.

17.1.2 An Alternative to bar chart reporting

A key part o planning/scheduling is to communicate eectively to a variety
o audiences. When reporting to the projects, programmes and portolio stake-
holders , it is always important to consider the audience o those reports. Certain
individuals are condent with data presented in a bar chart ormat, but there may
be people who preer alternative presentations. This is even more important
when reporting outside the project.
It is vital to get the ‘buy-in’ o the key stakeholders, so alternative means o
communicating the schedule should be sought. Some people can relate more to
a spreadsheet o dates, and some preer milestones. Choosing the right ormat
could be key to getting a point across or getting an important decision made.
Figure 17.3 shows a ormat using milestones.
The legend or all the milestones is shown on the chart; but it should be
noted that the optimistic, realistic and pessimistic dates are all generated rom
quantitative schedule risk analysis.
This milestone ormat can be a clearer way o presenting several dates relating
to one activity.

170
For use by APM individual and corporate members only
 Figure 17.3 Using milestones to give clarity to the schedule

For use by APM individual and corporate members only

 Planning, Scheduling, Monitoring and Control

17.2 Line o balance

Line o balance is a method most suited to the planning and adjusting o repetitive
work. It is particularly used when a series o repetitive units is required, or example
in a manuacturing environment. It ocuses on resources and outputs to achieve a
rate o progress that can be expressed simply and graphically. It is oten thought
to be most appropriate or residential-type projects, or example, but the technique
may equally be applied to repetitive elements o any project. Structural steelwork
is a possible example o a trade suited or planning and monitoring in this way.

17.2.1 Creating a line o balance chart

A line o balance chart is created by plotting the output (in no. o units completed,
m2, etc.) on the y axis, and time on the x axis. Thus, a chart can be produced
(Figure 17.4).
When the plotting o work is complete, it should then be possible to analyse
the trades that are infuencing the overall project duration due to their slower rate
o progress. In the example below, the mechanical & electrical 1st x and partitions
2nd x are progressing at a slower rate. The possibility o optimising the duration,

Figure 17.4 Creating a line o balance chart

172
For use by APM individual and corporate members only
 Communicating the schedule

Figure 17.5 Optimising work fow in line o balance

or example by increasing resources on these two tasks, can be examined and
put into practice as appropriate (Figure 17.5).

17.2.2 Advantages o line o balance

• Encourages the use o resource levelling, giving the trades continuity o work
and a more realistic chance o achieving the plan than a purely logic-driven
schedule would.
• Easier to understand than a bar chart.
• More concise orm o presentation (ewer pages o schedule).
• Can be used to predict completion by extrapolating the progress to date, or
making assumptions about uture progress.
• Can be used as a tool that will identiy modications required to the schedule.
• Will clearly highlight ensuing trades that are catching up with their prede-
cessors, and thereore at risk o running out o work.
• This method demands consideration o expected output and will improve the
quality o the plan.
• May assist in demonstrating delay and disruption in a claim situation (or
rebutting the same).
• Focuses on outputs.

173
For use by APM individual and corporate members only
 Planning, Scheduling, Monitoring and Control

17.2.3 Limitations o line o balance

• It is purely based on outputs and will not recognise out-o-sequence working.
• Does not show exact or logical relationships.
• Unlikely to be acceptable as a contract schedule.
• Not suitable or all projects or all parts o a project.
• Not supported by standard scheduling sotware – though special sotware can
be purchased.

17.3 Time chainage

17.3.1 Denition o time chainage charts
Time chainage charts are used to describe projects that are linear in nature (an
example being road construction). When well designed and drawn, they are a
very useul visualisation tool, oten allowing the whole project to be displayed on
a single chart (Figure 17.6). They can be highly complex, so their design should
take the end-users’ requirements into consideration. Sotware is available that
can convert most standard scheduling sotware into a time chainage chart by
using activity coding to dene the time and distance parameters.

• The diagram below (Figure 17.6) shows the basic elements o a time chainage
chart.

Figure 17.6 Basic elements o a time chainage chart

174
For use by APM individual and corporate members only
 Communicating the schedule

• Time is dened in appropriate periods down the side o the illustrated chart.
The start o the project is usually shown at the top o the chart and the end at
the bottom.
• The distance is shown horizontally in the illustrated chart, and may include the
chainage (location dened in metres) or named geographic locations, as
appropriate.
• At the top o the chart a simple representation or map o the project may be
shown to aid visualisation.
• Sotware is available that allows an automatic update rom standard scheduling
sotware.

Below is a simplied explanation o the build-up o a time chainage chart that

helps illustrate the technique.

17.3.2 Explanation o the time chainage technique

The project being used to illustrate the technique (Figures 17.7–17.11) is a
road project that contains two structures: a retaining wall and a road bridge. In
order to construct these structures it is necessary to construct a ‘haul road’ – a
temporary route that allows construction vehicles to traverse the site with heavy
loads.
The separate bar section across the top shows the work geographically.
The major section o this project is the bridge, so in order to acilitate its
construction; a temporary haul road is required. This is constructed rom each
end o the site as shown.

Figure 17.7 Time chainage task 1

175
For use by APM individual and corporate members only
 Planning, Scheduling, Monitoring and Control

Figure 17.8 Time chainage tasks 2 and 3

The completion o the haul roads allows the construction o both the retaining
wall and the bridge:
The road can commence once the bridge is nearing completion; or the
purposes o this example, we assume this has to be built in one continuous
operation. The rst option considers the operation rom (say) north to south.
However, by reconsidering this operation and constructing it rom south to
north, an earlier start can be made and a month saved rom the overall duration
o the construction schedule.

Figure 17.9 Time chainage task 4

176
For use by APM individual and corporate members only
 Communicating the schedule

Figure 17.10 Time chainage sequencing

17.3.3 Advantages o time chainage

• It is a very clear way o showing physical build against time.
• It will quickly show i there are spatial clashes in the schedule.
• It shows not only the location o the activity but also the direction o progress
and the required progress rate.

17.3.4 Limitations o time chainage

• Only appropriate in certain circumstances – it is particularly useul in geograph-
ically spread projects (which would also be ‘linear’ in character – like a road, a
railway or a high-rise building).
• Individual preerence or visualising the project (it does not suit everyone).

177
For use by APM individual and corporate members only
 Figure 17.11 Example o a time chainage diagram or a new railway

For use by APM individual and corporate members only

 Communicating the schedule

17.4 Schedule narrative

A schedule narrative is a undamental part o any complex schedule. It is used
to explain, illuminate and communicate. It is used especially when issuing a
schedule to a third party, usually or customer approval or acceptance, but is
important or clarity in any event. A narrative will typically include some or all o
the ollowing:

17.4.1 Scope
A description o the work scope should be included, covering design, procure-
ment, development strategy, implementation phase and testing and commission-
ing, as appropriate.

17.4.2 Health, saety and environmental considerations

For example, in construction, whether the site is a ‘green eld’, a city centre, a
nuclear site, a working railway or an airport, etc., as the HSE requirements will
vary considerably.

17.4.3 Risks, opportunities and contingencies

Risks to the time aspects o the project should be identied and discussed. This
would include a discussion on the use o any foat.

17.4.4 Breakdown structures

There should be adequate explanation in the narrative to describe the hierarch-
ical structures used in creating the schedule, or example geographical or physical
work groups.

17.4.5 Project phasing

Project phasing may be driven by other actors, such as nancial planning,
physical constraints or governance gateways. These should be detailed in the
narrative. This is particularly pertinent when these actors are dynamic, or
example in construction-site logistics layouts.

179
For use by APM individual and corporate members only
 Planning, Scheduling, Monitoring and Control

17.4.6 Stakeholders
Any stakeholders’ interest in the schedule should be identied and described.

17.4.7 Resources
Resources used in execution o the schedule should be described in the schedule;
the narrative should note any resource constraints or special resource requirements,
in particular highlighting any scarce resources that pose a threat to the delivery
o the project i they are unavailable. Any special measures required need to be
identied. Resource histograms may be a useul communication tool to indicate the
resources to be deployed:

• labour;
• major items o plant or equipment;
• major items o material.

17.4.8 Critical path(s)

A description o the critical path(s) through the project, possibly with simple illus-
trations to enhance explanation, together with a commentary expanding on any
relevant or pertinent issues relating to decisions, progress, strategies, risks or
other matters pertaining to the critical works in the project.

17.4.9 Assumptions
A description o the key assumptions that aect the management o time, in
order to explain and enhance understanding o the schedule.

17.4.10 Calendars
Calendars which underpin the schedule should be listed and described as part o
the narrative. A summary o those used in the schedule should be provided. It
should reer to the days/hours to be worked, and describe any exceptional
calendars used. For example, there may be separate calendars or:

• normal working hours;

• 7-day working;
• 24-hour working;

180
For use by APM individual and corporate members only
 Communicating the schedule

• night-shit or weekend working;

• planned closures or special works.

17.4.11 Activity codes

Details o all activity and resource codes in the schedule, and reasons why they
are used.

17.4.12 Details o any possessions, shut-downs or other

special working conditions
Working railways usually require possessions or track work to be done.
Factories and production acilities require shut-downs. Nuclear sites may
require special working conditions.

17.4.13 Consents required

Any consents rom third party authorities should be identied either in the
schedule or in the narrative, including the required timing or any application or
approval periods.

17.4.14 Permits and licences

Any permits and licences required should be identied either in the schedule or
in the narrative, including the required timing or any application or approval
periods.
It is noted that the above list, though not necessarily exhaustive, represents a
considerable eort to create and maintain. Common sense must prevail in
determining what is appropriate in dierent circumstances. It may be appropriate
that some o the details listed above orm part o the project procedures or other,
standalone documents. The central purpose o the narrative – to communicate
and explain the schedule – must not be lost in the creation and updating o an
exhaustive narrative document.
The narrative is reviewed, revised and re-issued alongside each submission o
the schedule and associated documents.

181
For use by APM individual and corporate members only
For use by APM individual and corporate members only
 18.1 Denition o schedule review
Schedule review is the process that conrms that the schedule is t or purpose:
i.e. that it can be used to direct and accurately monitor the work. In general, there
are two stages:

• initial review o the schedule to conrm its tness or purpose

• ongoing review o the schedule to ensure that it continues to be t or purpose.

18.2 Purpose o schedule review

Schedule review is undertaken to ensure that the schedule is t, and remains t
or purpose.

18.3 Checking the schedule

Fundamental checks o the schedule should conrm that the ull project scope has
been included; that the schedule describes a practical methodology or delivering
the work; and that all contract deliverables, constraints, key dates and milestones
are included. The ollowing sections detail urther checks that may be made to
test a schedule’s integrity and relevance. There are two categories o checks:

• planning checks;
• scheduling checks.

183
For use by APM individual and corporate members only
 Planning, Scheduling, Monitoring and Control

Planning checks deal with the practicality o the plans to direct the completion o
the project. Scheduling checks check the integrity o the time model, to ensure
that it fows correctly and can be used to orecast accurate dates.
The primary consideration must be the practical content o the schedule, but
some useul integrity checks are also discussed in this section.
In order to review a schedule, it is important to be able to read and interpret it.

18.3.1 Understanding the project schedule

It is important to be aware that a schedule submitted in a sotware ormat will not
necessarily display in the way intended, or as it was viewed on the sender’s
screen. Some sotware will deault to the user’s display settings. It is important to
select the correct layouts and lters beore viewing the schedule. It is, thereore,
normal practice when submitting a schedule to include a copy in a le ormat that
will display the schedule without the need or particular planning sotware to be
installed on the viewer’s screen.

18.3.2 Components o the schedule display

As stated, a schedule may be presented in many and various ways. Figure 18.1
eatures some o the elements that are typically available.

18.3.2.1 Data table

The data table contains inormation about each activity. There is almost a limitless
amount o inormation that can be displayed. The example below shows a airly
standard display or the contents o the adjacent Gantt chart.

• Act ID = activity identiying number.

• Act Name = description o the activity.
• OD = original duration o the activity.
• Start/Finish = start and nish dates o the activity (usually early start and early
nish).
• Total Float is sel-explanatory.
• B/L Start = baseline start date.
• B/L Finish = baseline nish date.

184
For use by APM individual and corporate members only
 Figure 18.1 Components o a schedule or review

For use by APM individual and corporate members only

 Planning, Scheduling, Monitoring and Control

Additional items that could be displayed may include:

• cost and budget data or each activity;

• predecessors and successors o each activity (although this may be dicult to
display and read);
• progress data such as actual dates, percentage complete and remaining
duration.

18.3.2.2 Timescale
The timescale can be used to display calendar dates in various levels o detail,
and/or ordinal dates. The timescale can usually be expanded to aid visibility o
a particular timerame, or contracted to give an overview o a wider portion o
time.
The schedule should also display the data date. The data date is the
point up to which project progress is updated. It is also the point rom
which any network analysis would be calculated when ‘re-scheduling’ the
project.

18.3.2.3 Gantt chart

Typically called the bar chart, this displays bars between pairs o dates (start and
nish dates). A number o bars may be shown, or example based on early dates,
late dates or baseline dates (to visualise progress slippage or recovery). Whilst
the options are many, or clarity the number o bars displayed should be kept to
a minimum.

18.3.2.4 Resource histogram

The resource histogram will graphically display the resource usage that the
schedule calculates to be required to complete the work. It may represent all the
resources, or be ltered to display a particular type o resource, or resources, or
a particular section o works.
A resource limit may be displayed (red line in Figure 18.1). I such a limit has
been set, then any resource requirement over that limit may be highlighted in a
dierent colour (not shown in Figure 18.1).

186
For use by APM individual and corporate members only
 Schedule review

18.3.3 Critical matters not included in the display

18.3.3.1 Understanding the critical path
In reality, tracing the critical path and other network logic in a complex schedule is
dicult on paper (unless specic extracts have been produced, which by their
nature will give limited inormation), and thereore an electronic review is necessary.

18.3.3.2 Calendars
It is important to understand what calendars and work patterns have been used
when building the schedule. (This can be displayed in the data table.) The
calendars used will infuence overall duration o activities (and hence the project),
the ability to accelerate the project, and the understanding o the critical path.

18.3.3.3 Schedule drivers

Similarly to the issue o calendars, schedule duration is also driven by the availab-
ility and quantity o resources used, assumed output rates and productivity rates.
It is, thereore, crucial to know this inormation when checking the schedule.
When reviewing the schedule, it is also vital to be aware o any constraints that
have been used.

18.3.3.4 Filters and layouts

Filters are used to display a specic selection o the schedule at any one time.
Filters may be used to extract a particular area o responsibility, criticality, activity
coding and many others. When reading a ltered schedule, it is important to
understand what element o it is being viewed (and, conversely, what is NOT
being viewed).
Layouts determine how the schedule will be viewed by determining the
contents o the data table, the Gantt chart, the presentation o the timescale, etc.

18.3.3.5 Risk
When reviewing the schedule, it is important to understand the associated risks.
These should be ound in or added to the project risk register.

187
For use by APM individual and corporate members only
 Planning, Scheduling, Monitoring and Control

18.4 Planning checks

18.4.1 Administration
• Check that all headers and ooters are correct, with current date and revision
number.
• It is good practice or the header or ooter to also include elds or layout, lter,
project ID, project name, username, version number, etc. applied to the
printed version.
• Check that the schedule has been checked and approved or issue.
• Presentation: Is the schedule laid out logically and easy to read? (For example,
are contract and key dates shown clearly, perhaps in their own section at the
start o the schedule?)

18.4.2 Management issues

• Achieving ormal buy in rom relevant managers.
• Does the logical sequence o tasks make sense?
• Are adequate lead-in times allowed or material supply, manuacture o
components, etc.?
• What are the main risks to the schedule?
• Are there any onerous requirements placed on the contract?
• Ensure all assumptions regarding durations and sequence are adequately
recorded.
• Does the schedule at high level compare with similar projects?
• Do the activity durations compare avourably on key trades?
• Are any corporate governance/sign-o points included?

18.4.3 Contract requirements

• Does the schedule comply with contract obligations?
• Are the key client milestones included in the schedule?
• Have constraints such as working hours been accounted or?
• Are there multiple handovers? I so, does level o detail refect this, particularly
regarding trade continuity?
• Missing data required by the contract, such as missing activity coding.

188
For use by APM individual and corporate members only
 Schedule review

• I the schedule includes progress, perhaps the most important check o all is
that key or contract dates have not moved, or, i they have, the reasons or
such movement are ully explained in the narrative.
• I required, has time risk allowance been identied against activities?

18.4.4 Scope
• Is the entire scope represented in the schedule, including latest change (up to
a suitable cut-o point)? (This should include reerences to all works by the
client, contractors and third parties.)
• Are all temporary works and other preliminaries covered? The ormer may be
on the critical path or require critical resources.
• Are intermediate milestones identied and meaningul?
• Check that all interace milestones are paired.
• Check that the key/interace milestones or the next 12 months have signed-o
milestone denition sheets and that all have SMART measures (specic,
measureable, achievable, relevant and time-bound).
• Check all activities and milestones or any constrained dates.
• Check or out-o-sequence or missing logic leading to activities on data
date.

18.4.5 Associated documents

Associated documents that may be required or issue at the same time as the
schedule:

• inormation required register;

• procurement schedule;
• assumptions register;
• logistics plans (trac management; hoist and tower crane location plans;
materials storage in various phases);
• additional communication plans, e.g. time-phased layouts.

18.4.6 Planning issues

Consideration should be given to the existence o negative foat or excessive
positive foat and the implications this has or the management o the project.

189
For use by APM individual and corporate members only
 Planning, Scheduling, Monitoring and Control

I schedules with negative foat are presented without showing the negative
foat, they can give a alse impression that the schedule dates can be met.
Where positive foat exists in a network, it means that the work can be delayed
by the associated time and still be completed by the desired date. However, it is
worth checking that ‘excessive’ foat does not exist in the project schedule. This will
be because o missing successor logic. It is always worth checking the logic through
activity networks that seem to have proportionally more foat than seems reasonable.
Check or an excessive number o activities starting early in the programme.
Although the logic may allow this, it may not be a cost-eective approach or the
project.

18.4.7 Progress update

• Have any key dates or other important milestones moved?
• Has physical % been updated (where options exist)?
• Has the correct data date been set?
• Are actual dates recorded correctly?
• Does the remaining duration o the activities roughly align with the progress
achieved within the time elapsed?
• How much foat has been used, particularly on the critical and near-critical paths?
• Are there any uture activities marked as started or complete?
• Are there any activities in the past that are not complete?

18.4.8 Communication o the schedule

• Has a summary plan and explanation been included?
• Are activity descriptions clear and has relevant coding been applied?
• Is the critical path clearly shown?
• Are the associated tracker schedules included in the communication?
• The narrative should highlight key particulars o the schedule and key changes
since the previous issue.

18.5 Scheduling checks

This process looks specically at schedule logic and content that may distort the
natural fow o the schedule, making accurate orecasting more dicult. Similarly,
it reviews over-complexity in the schedule, which may increase the possibility o

190
For use by APM individual and corporate members only
 Schedule review

ailure. It is important to note that the review o technical quality is purely a

mathematical and statistical check and does not take into consideration the
project schedule as a whole. To check or scope inclusion, ‘buildability’ and other
practical concerns, the schedule should be reviewed by suitably experienced
individuals rather than by mathematical checks.
I ormal checks are to be undertaken, it should be noted that these checks
would not useully be applied to summary tasks, LOE-type tasks, milestones, or
activities that are 100% complete. Making changes to the latter should not
generally be encouraged.
A good starting point is to see whether the schedule can be re-scheduled with
no subsequent changes to the start and nish dates. It is also worth reviewing
what changes have been made to the schedule since its previous iteration. Then
consider the ollowing actors.

18.5.1 Activity checks

18.5.1.1 Activity types
Scheduling sotware oers a variety o activities or use in schedules, and these
should be used with caution; or example, WBS summary activities (activities
driven by the start and end dates o other activities):

• should not contain resources, except during the development o schedules;

• should never orm a part o the critical path;
• should be used very sparingly, and then only with a particular use in mind.

18.5.1.2 Activity durations

Activity durations should be achievable under normal conditions, not optimal or
‘stretch’ targets. In order to veriy this, the schedule narrative should clearly state
which output rates have been used. Assumptions related to calculated durations
should also be documented.
Durations should be short enough to acilitate easy assessment o progress. It
is very dicult to be specic regarding a maximum duration or an activity, but, as
a guide, no activity should exceed the duration o two reporting periods. (Do not
consider summary activities in this check.)
A schedule broken into very short durations (around a day or so) is generally
in too much detail (the exception being short-term ‘look ahead schedules’).

191
For use by APM individual and corporate members only
 Planning, Scheduling, Monitoring and Control

Schedules with great detail will demand more requent updates and more
management eort.

18.5.1.3 Review o deleted activities

In general, activities should never be deleted rom a schedule, in order to preserve
the unique numbering system or each activity and thus maintain the history o
the project.
Activities should, instead, be retired and placed in a unique and specic part
o the WBS. They will likely be ltered out o any print or display o the schedule.
All budgets must be removed and re-allocated i appropriate. Coding and logic
should also be removed. However, the logic could be replaced with links to a
dummy start and nish milestone to limit the number o open ends.
In practice, leaving all redundant activities in the schedule may increase the
size o the database to unmanageable proportions. In this instance, it may be
decided to delete activities and introduce checks between successive versions o
the schedule or deletions.
However, where practical, it is good practice to preserve activities, or the
reasons stated above. A compromise might apply in a situation where large
sections o the schedule are to be replaced, when activity deletion may be
accompanied by a change in the structure o activity IDs, so that there is no
possibility o duplication/recycling o the activity ID numbers.

18.5.1.4 Insucient detail

Is the schedule broken down into sucient detail? This could be dened in terms
o the maximum duration o an activity in relation to the overall project duration.
On a project lasting 2 years it may be appropriate to speciy a maximum duration
o 4–6 weeks; on a plant shut-down the appropriate duration may be 1–2 hours.
This should always be a guide rather than a rule, and will not apply to summary
tasks or level o eort activities.

18.5.1.5 Review o calendars used

Calendars used should be kept to a minimum, and only those authorised or use
on the project should be used; they must be attributed to appropriate activities.
Calendars should represent valid working times or the activities and associated
resources.

192
For use by APM individual and corporate members only
 Schedule review

Calendars should be named clearly, should account or holiday periods, and
account or any other restraint on working; actory shut downs in manuacturing
or weather in construction, or example.

18.5.1.6 Review or invalid dates

Invalid orecast dates are those that logically should have already happened, and
are shown in the past, but are not shown as complete.
Invalid actual dates are those that are noted as started or nished, but are in
the uture (i.e. later than the current data date). This is clearly incorrect, and thus
an invalid date.
The examples above can be the result o poor unctionality in various types o
scheduling sotware, or just poor practice by an individual. Either way, both need
to be checked or.

18.5.1.7 Review o WBS

A good work breakdown structure (in line with the advice within this guide) is an
indicator o a good schedule, and vice versa. All activities in the schedule must be
attributed to a part o the WBS.

18.5.2 Logic checks

18.5.2.1 Relationship types
18.5.2.1.1 Finish to start (FS)
The vast majority o activities in the schedule should be nish to start activities.

18.5.2.1.2 Finish to nish (FF)

There may be a limited number o nish to nish relationships in the schedule,
but remember that these require parallel working and the additional resources
that this implies.

18.5.2.1.3 Start to start (SS)

There may be a limited number o start to start relationships in the schedule, but
remember that these require parallel working and the additional resources that
this implies.

193
For use by APM individual and corporate members only
 Planning, Scheduling, Monitoring and Control

18.5.2.1.4 Start to nish (SF)

These relationships must be avoided; they are sometimes used as a convenience
to x activities in a particular moment in time. However, they are illogical and can
distort the fow o the schedule. (Very occasionally there may be exceptions to
this rule.)

18.5.2.2 Number o lags

Whilst the use o lags is common practice within scheduling, they should be used
sparingly, as they can undermine the overall accuracy o the schedule. This is
because they are dicult to progress accurately, and have an inherent lack o
visibility. It is, thereore, good practice to use a dummy task rather than a lag. This
has the added advantage that an appropriate calendar can be applied to the
dummy task.

18.5.2.3 Number o leads

A lead is a negative lag, which should be avoided as much as possible. They
should never be used in high-density scheduling, because they are illogical.

18.5.2.4 Missing or redundant logic

Missing logic reers to activities that have either missing predecessors, missing
successors or both. A high percentage o missing logic will lead to articially
infated foat within the schedule, and will also aect the validity and reliability o
the critical path and subsequent orecasts.
Redundant logic can articially increase the complexity o the schedule without
adding any value.

18.5.2.5 Out-o-sequence activities

Work that is started or completed on an activity beore it is logically scheduled
(beore all its predecessors are complete) to occur is known as out o sequence.
This may show:

• A lack o discipline in the project, as work is being progressed in the wrong

sequence.

194
For use by APM individual and corporate members only
 Schedule review

• Facilities or machinery not being available, so work is jumping to the next

activity instead o being idle.
• A ault in the logic.
• It may also indicate a lack o detail in the schedule.

This check should be used with caution, as schedules should be pragmatic rather
than innitely precise, and some instances o this occurring will be acceptable. In
short, don’t panic i out-o-sequence activities are ound in the schedule, but be
careul.

18.5.2.6 Logic density

The average number o logic links per activity across the schedule. In general, the
minimum number o links per activity is two (one predecessor and one successor);
anything below this shows that the schedule is lacking the logic needed to
provide a robust critical path, and anything excessively above this may lead to
either redundant logic, which may complicate the ongoing maintenance o the
schedule, or an increased level o risk to timely delivery.

18.5.2.7 Logic bottlenecks

Activities with a high number o predecessors (i.e. more than two). This means
that there is an increased threat to delivery o this activity due to its dependence
on the successul completion o many other activities. In Figure 18.2, there is a
high chance that activity D will be delayed, as there are more things that can
delay it; i it does start on time, it has a signicant eect on the schedule i it runs
late, as a number o ollow-on activities would be aected by its running late.

18.5.2.8 Multiple ends

A network should have one start milestone and one nish milestone. All other
activities are connected, directly or via preceding or successor activities, respect-
ively, to the start and nish activity by logic.
Each activity or sequence o activities should, in practice, impact on the
completion date o the project at some stage. For example, the supply o technical
publications is generally an unrelated activity that would not impact the physical
completion o an aircrat. However, any delay in the delivery o the technical
publications may well impact on the handover to the customer; or example, i

195
For use by APM individual and corporate members only
 Planning, Scheduling, Monitoring and Control

Figure 18.2 Logic bottleneck

the contract requirements speciy that a ull suite o technical documentation

and/or spares (sometimes reerred to as initial provisioning) is required or
satisactory ullment o the contract.
In reality, there may be several end events/milestones which are required to
be delivered by a given date. For detailed project control, each deliverable is
managed in its own right, and thereore foat is to be calculated or each delivery,
and not calculated to the last milestone o the overall network.

18.5.3 Float and critical path checks

18.5.3.1 Review o schedule foat
Whilst high levels o foat can be a sign o poor schedule logic, low levels o foat
can mean that the project is unlikely to succeed beore it has even started.
Ensuring that the project has enough foat to accommodate unknowns is unda-
mental to its success.

18.5.3.2 Negative foat

Activities within the schedule that have a total foat value o less than 0 are said to
have negative foat. Logically, the schedule cannot be completed by the required

196
For use by APM individual and corporate members only
 Schedule review

target date. It is not, thereore, acceptable to have negative foat in the rst
schedule, but it may exist in subsequent schedules i progress has been unsatis-
actory. It is then a sign o a threat to the achievability o the schedule.

18.5.3.3 Review activities with high foat

This may be an indicator o missing or inappropriate logic (but note that it may
also indicate an activity that can be undertaken at any time!). It may also suggest
missing activities, or improper sequencing within the schedule.

18.5.3.4 Review o time risk allowance

Durations are uncertain, and thereore time contingency should be allowed or.
This is sometimes reerred to as a time risk allowance. It may be expressly shown
on the schedule, or it may be deemed to be included within each task. Thereore,
the best way to veriy there is adequate contingency is in discussion with the
schedule owner.

18.5.3.5 Hard constraints

This reers specically to the use o constraints that can articially distort the CPM
(critical path method) process and undermine the critical path. A hard constraint
is one which constrains the critical path in both directions; constraints such as
‘start on’, ‘mandatory start’, ‘nish on’ and ‘mandatory nish’ are examples.
Constraints that only aect the critical path in one direction are known as sot
constraints and are more acceptable; however, they should still be used sparingly,
and never in combination to create a hard constraint.
For example, a constraint that means an activity could start on or beore a
certain date would be a sot constraint, as would a date that means an activity can
start on or ater a certain date. But, i used in combination, they eectively
become a hard constraint – a mandatory start date.

18.5.3.6 Critical activities

Does the longest path represent a reasonable critical path or the project? (Pay
attention to the critical path and near-critical paths in reviewing the schedule.)
Review activities and milestones with a total foat value o 0 days or less. (For
longer and more complex schedules, the review might need to be total foat
o less than 1 day or 5 days or more.) High levels o overall criticality in the

197
For use by APM individual and corporate members only
 Planning, Scheduling, Monitoring and Control

schedule can be the result o insucient progress or potentially poor use o hard
constraints.
The critical path should not include LOE or summary activities, leads or lags
unless justied. It should also not include activities scheduled to take place as late
as possible, even i they have zero foat by virtue o coming beore a critical activity.

18.5.4 Resources checks

18.5.4.1 Review o resourcing
The schedule should be checked to conrm that all true activities are resourced
and/or budgeted. The checker should look out or budget and resourcing o
summary tasks (or level o eort bars), as this may indicate a lack o detail in the
budgeting and resourcing elsewhere.
It is also worth checking that only appropriate and approved resources are
assigned to activities.
I there are available norms, it is useul to check the ratio o cost:resource, i.e.
benchmarking.
Resource levels that the schedule requires should be measured against
available resources.

18.5.4.2 Analysis o resource histogram

Resource histograms should be reviewed or practicality. Some o the checks
could include:

• Are there any sudden peaks and troughs?

• Does it look balanced, i.e. are there realistic increases and decreases o labour
and/or sta?
• Does each resource have continuity (unless multiple ‘visits’ are allowed or)?
• What is the peak sta/labour level, and is it practical or this type o project?

18.5.5 Review o schedule risk

Key risks in the project will have been identied as part o the risk management
process. Some risks will have a potential impact on the timing o the project, and
these should be included in the network in order to give a more realistic project
schedule. The allowances or risk should be reviewed as part o the risk analysis
process.

198
For use by APM individual and corporate members only
 19.1 Denition o BIM
BIM is a new approach to dealing with the design, procurement and installation
o an asset as well as its testing and commissioning, its handover, and its operation
and maintenance. It provides inormation to acilitate each o these lie cycle
stages and can be applied to any type o asset.
Enhancements to modelling sotware have given the ability to directly link the
project schedule to the model (3D), to visualise the construction process in real
time (4D), and also to estimate the cost prole (5D).
In essence, BIM consists o a computer aided design (CAD) model o the
asset. This may exist in 2D or 3D ormat. The model has the ability to contain
inormation to build, operate and maintain the asset. In more mature solutions,
this can extend to incorporating the project schedule and cost model. This could
mean a 3D model that can visually demonstrate the build sequence (or, indeed,
the progress o the works.) The BIM database will also contain metadata around
each individual component o the build, such as type, cost, load-bearing capacity,
supplier, etc.
The term is being used worldwide, although in the UK its adoption is mandated
on government-unded projects by the end o 2016, giving it special relevance.
BIM maturity has been dened as dierent levels, as illustrated schematically in
Figure 19.1.
Although the visualisation elements o BIM remain the most recognisable
aspect, it is the integration o scope using a common and consistent language in
order to understand the impact o change that is the key advantage o this
approach.

199
For use by APM individual and corporate members only
 Planning, Scheduling, Monitoring and Control

Figure 19.1 BIM level maturity map

19.2 Purpose o BIM

The BIM approach adds value to all stages o the assets lie cycle because it
provides access to all the elements o inormation associated with the assets
being designed, engineered and, nally, operated and maintained. In delivering
this, BIM has a great potential to promote collaboration between the various
parties and remove some traditional industry barriers.
The use o 3D visualisation sotware is used to de-risk the delivery phase o
a project by modelling the time phasing o construction in three dimensions. This
process shows potential design issues and clashes within the scheduling o
a project, which can then be re-phased accordingly (e.g. running electrical
services beore providing cable management systems).
A computer model conceived with this approach in mind will constitute a
repository o the so-called ‘single version o the truth’, thus minimising misunder-
standings deriving rom working on dierent versions o the model. Multi-
disciplinary coordination and alignment are acilitated by the existence o a single

200
For use by APM individual and corporate members only
 Building inormation modelling (BIM)

model, whereby each specialist adds the specic inormation on an iterative basis
as the design matures.
The involvement o dierent expert representatives o dierent organisations
(asset owner, investor, designers, builders, operators and maintainers) at the very
beginning o the project denition provides an opportunity o taking into account
all the requirements that will accompany the assets to be built throughout their
whole lie cycle.
All the unctions that use the data and inormation that will make the model
richer and richer as the design develops will work together in a much more
ecient manner (i.e. an integrated approach to cost and time is a natural result o
BIM).
The transition o all the records rom the construction team to the Operator
and Maintainer (O&M) will occur in an electronic manner, sometimes reerred to
as ‘digital handover’, without the need or an expensive and time-consuming
period o translation o asset data into a ormat suitable or O&M use.

19.3 BIM technology

The BIM technology has evolved very rapidly in recent times. Some mature
solutions exist, especially in relation to BIM level 2. Sotware houses are collab-
orating more and more in order to oer solutions that acilitate integration in an
increasing manner.

19.4 The BIM culture

Any type o change, in particular one o the magnitude o BIM, will have to deal
with the human actor, by increasing awareness and knowledge o how project
disciplines interact with each other. Spreading the BIM culture both internally
and within interacing organisations is a challenging task. New skills and proes-
sions will be required, currently not part o ormal educational and business
careers.

201
For use by APM individual and corporate members only
For use by APM individual and corporate members only
 20.1 Denition o agile
Agile is a ramework which describes a collection o tools, structure, culture and
discipline to enable a project or programme to embrace changes in requirements.
Agile methods integrate planning with execution, allowing an organisation to
‘search’ or an optimal ordering o work tasks and to adjust to changing require-
ments.
Agile is not a methodology, and does not prescribe a way o working. It seeks
to provide a ramework and a working mindset that helps a team respond
eectively to changing requirements.

20.2 Purpose o agile

Agile rameworks are typically used in sotware development to help develop
sotware which may have uncertain or poorly dened and changing user require-
ments. As unctionality is iteratively developed in short timescales, it must be
tested with the customer, and the requirements rened and agreed as appropri-
ate. Further development is then undertaken to enhance the unctionality o the
end product.
Agile development is not the same as agile project management. Commonly,
and oten disastrously, agile thinking is not applied to the management o agile
development projects; or example, when business users are not embedded in
the team, and change decisions are not delegated to the agile team, but need to
be escalated or approval. This slows down development, hence removing one
o the key advantages.

203
For use by APM individual and corporate members only
 Planning, Scheduling, Monitoring and Control

There are agile methods specic to sotware development, such as Scrum or

XP (eXtreme Programming). However, some agile approaches are starting to be
adopted in more industries outside the sotware development industry.

20.3 Methods
There are many distinct agile processes, which are summarised in Figure 20.1.
Irrespective o which agile process a project chooses to adopt, or i they wish
to adopt more agile thinking, the ollowing principles apply:

• The project breaks a requirement into smaller pieces, which are then priorit-
ised by the team in terms o importance.
• The agile project promotes collaborative working, especially with the customer.
This involves the customer being embedded in the team, providing the team
with constant and regular eedback on deliverables and unctionality o the
end product.
• The agile project refects, learns and adjusts at regular intervals to ensure that
the customer is always satised and is provided with outcomes that result in
benets.

Scrum is the most popular agile process used in sotware development. It is

based on delivering sotware eatures in time-boxed iterations called ‘sprints’

Figure 20.1 Agile processes

204
For use by APM individual and corporate members only
 Sotware industry: the agile approach

Figure 20.2 Illustration o an agile methodology using ‘scrums’ and ‘sprints’

(Figure 20.2). The requirements are written as ‘stories’ that are collated into a
prioritised list called the ‘backlog’. Each story in the backlog is awarded points
based on the level o denition o the requirements. Progress is monitored using
‘burn down’ charts o points; this enables the ‘velocity’ to be calculated, which
can be used to predict the out-turn duration. Points are earned either 0% or 100%,
depending on the acceptance by the client/sponsor at the end o the ‘sprint
review meeting’. The process is overseen by the ‘scrum master’, who makes sure
everyone adheres to the rules. Meetings are reerred to as ‘ceremonies’, the
most requent o which is the daily planning meeting, which identies what has
been done, what is to be done and barriers to success. Continued improvement
is embedded by holding a ‘sprint retrospective’ at the end o each sprint to access
perormance and learn rom experience.

20.3.1 Advantages
• Agile planning ocuses on delivering what is most benecial to the business
rst, identiying quick wins and earlier benets realisation.
• Agile continuously looks or process improvements as part o the ‘retrospect-
ive’ review. As the team become more ecient, they can plan to achieve more
in each sprint. Thus the velocity o delivery increases.

205
For use by APM individual and corporate members only
 Planning, Scheduling, Monitoring and Control

• Agile assumes that changes are normal events; thereore they are managed to
enable greater fexibility.
• Agile scheduling allows a greater level o fexibility in achieving the end result.

20.3.2 Limitations
• The organisation needs to be able to operate in an agile way and be willing
to have a ully empowered team, typically with a ull-time customer represent-
ative.
• A non-agile culture within an organisation will be a blocker on a project imple-
menting an agile ramework.
• Attendance at ‘daily scrum’ meetings is essential to keep abreast o the project
tasks.
• Agile is not appropriate or all types o projects. Where there are signicant
resource constraints, securing suitably qualied teams or the ull duration o
each time box may not be possible in the organisation.
• Agile approaches struggle on larger-scale projects due to the degree o collab-
orative working required by the approach. I team sizes become too big, then
development rates can slow.

206
For use by APM individual and corporate members only
 Part Four

Monitoring and control

‘You may not control all the events that happen to you, but you can decide not to
be reduced by them.’
Maya Angelou

For use by APM individual and corporate members only

For use by APM individual and corporate members only
 21.1 Denition o the project baseline
The project baseline (oten reerred to as the perormance measurement baseline,
or PMB) is an approved plan or the project, against which project perormance
is measured to acilitate management decision making and action. The setting o
the baseline cannot be achieved until scope is dened and agreed, as the baseline
must encompass the entire project scope, schedule and cost.
In practice, a baseline is a stored set o values encompassing

• planned start and nish dates

• planned resources
• planned costs.

At the point o establishing a baseline, each activity in the schedule has a duplicate
set o dates ascribed to it. The duplicate dates are called the ‘Baseline’ dates
and are illustrated in yellow in the diagrams below. Once set, these dates are
not changed through the normal progress o the project, unless there is a
requirement to re-set the baseline. As the project progresses, the plan will be
updated and the current dates, illustrated in green in Figures 21.1–21.6, may
well vary as a result o project perormance, revised sequencing and detail devel-
opment.
The illustration shows the eect on a project schedule o a delayed start
and completion o the rst activity, which has a knock-on eect on subsequent
activities.
The same principle applies to management o resources and costs. A set o
values is recorded as the baseline, and as the work progresses and actual usage

209
For use by APM individual and corporate members only
 Planning, Scheduling, Monitoring and Control

Figure 21.1 Establishment o baseline

Figure 21.2 Baseline ater work starts

o resource or actual costs are incurred, these are recorded or comparison with
the baseline data.
A baseline to measure against is the key requirement or any orm o project
control. Without a baseline, there is nothing to compare the working schedule
with, and thereore there is no way o measuring perormance, meaning that
projects will end up out o control.

210
For use by APM individual and corporate members only
 Baseline

21.2 Purpose o a project baseline

A project baseline is established to enable the perormance o the project to be
understood and controlled. This is achieved by:

• Clear identication o the schedule o the deliverables, activities, milestone

dates, resources and costs.
• Measurement o project perormance: progress and perormance are compared
against the baseline, allowing appropriate action to be discussed, agreed and
taken. Thus, it is essential to apply appropriate project control techniques.

In addition, the baseline serves other purposes:

• It can motivate the project team to deliver to plan, or to mitigate delays.

• It is the contractual or other reerence point rom which to measure and assess
the eect o change.
• It can be used in improving uture estimating.

In order to achieve all o the above, the baseline must be robust, credible and
pragmatic, and must thereore be maintained as changes are made to the working
schedule.
The baseline will oten be reerred to as the perormance measurement
baseline, or PMB. Usually the PMB is the S-curve (or curves – early and late)
derived rom the baseline schedule. The elements o the total project that are
included in the PMB or purposes o measurement must be dened. For example,
risk and contingency may be excluded.
Following the principles below will ensure that the PMB is aligned with the
master schedule objectives and contract milestones. This PMB orms the basis
or measuring all uture progress and perormance.

21.3 Principles o project baselining

• The baseline covers the entire scope o the project and includes all project
breakdown structures (by activity coding or other means).
• The baseline schedule should comply with the principles outlined in this book.
• The baseline covers all stages o the project lie cycle.

211
For use by APM individual and corporate members only
 Planning, Scheduling, Monitoring and Control

• The project delivery team creates controls and executes the baseline. An
appropriate level o authority, as identied in the project’s governance docu-
ment(s), approves the project baseline.
• The baselines should be established at (or beore) the commencement o each
phase.
• The baseline is only changed in accordance with a robust change control
process. Changes to the baseline must be controlled and recorded.
• In addition, the baseline is ‘maintained’ as discussed below.
• The baseline may be ‘re-planned’, as discussed below. A ‘re-plan’ should only
be considered with the relevant level o authority (e.g. client, project manager
or project sponsor, depending on circumstances).
• The baseline may be ‘re-baselined’, as discussed below. A re-baseline is only
considered with the agreement rom an appropriate level o authority (e.g.
client, project manager or project sponsor, depending on circumstances).

21.4 When to set the baseline

• A baseline should be reviewed, updated where necessary, and ormally agreed
beore the project enters into the execution o the next phase.
• I a gateway approach to the project lie cycle is adopted, a baseline may be set
at each gateway phase.
• The level o detail in the baseline or later phases becomes greater as each
phase becomes more imminent.
• The project baseline should only be set when the schedule, budget, resources,
risks and other components o it are robust, i.e. it is agreed that it is possible to
deliver the project to cost, time and quality.
• I a budget is signicantly inaccurate it will not be useul as a measure o time
and cost perormance. An appropriate degree o rigour in setting the budgets
is thus required.

21.5 Establishing the baseline schedule

Baselines should normally be established against early start dates, assuming that
resource levelling has been undertaken to calculate these dates.
In short, a baseline is created rom the rst agreed plans, and should have the
buy-in o the whole project team, senior management and supply chain.

212
For use by APM individual and corporate members only
 Baseline

21.6 Denition and purpose o baseline

maintenance
21.6.1 Denition o baseline maintenance
Baseline maintenance is the routine maintenance o the baseline to ensure that
any new detail in the working schedule is also captured in the baseline. This
would typically include work that has been added to the scope through a proper
change control process. It would also cover the addition o new activities; or
example, adding granularity to the schedule.

21.6.2 Purpose o baseline maintenance

• To maintain a credible schedule to measure against.
• To revise dates, budgets or any other data where they are aected by agreed
change. Only authorised change (ollowing appropriate governance) may be
substituted into the baseline. Unauthorised change must never be added into
the baseline.

21.6.3 Baseline maintenance as a result o schedule changes

Some changes will require baseline maintenance. The principles o this are
described below. Some scheduling sotware will acilitate this process with
ease; others will require a number o steps to establish stored values or new
or changed work. Baseline maintenance consists o changes to the baseline
that enhance rather than detract rom the integrity o the baseline. This includes:

• Change o planning packages into work packages (this may include the
addition o detail to the medium/long term).
• Changes in contractual conditions or work scope. Where change is identied,
it is managed through a change control process, ultimately leading to an
update o the baseline. This will take the orm o an appropriate addition,
omission or revision, and will include the eects o the change on uture
activities. Records o baseline change should be maintained to provide
traceability.
• Changes to descriptive inormation – e.g. activity or coding titles. Typically,
this may be the correction o errors. Note, however, that changes in numbering
o activity IDs should never be permitted.

213
For use by APM individual and corporate members only
 Planning, Scheduling, Monitoring and Control

One example o baseline maintenance would be the addition o more

detail. Figures 21.3–21.6 show how the baseline would be maintained as
a result o doing this, in this instance where concurrent delays have happened
on the schedule. The overriding principle here is that o rolling wave
planning, and the update o the baseline should not be able to compromise
the baseline by masking delays or other changes that have aected the
schedule.
Baseline maintenance or schedule revisions is intended to preserve the
integrity o the baseline, and should have no eect on measurement o schedule
perormance or cost perormance reporting. Baseline maintenance never masks
poor or good project perormance. Project-specic rules or authorising any
changes to budget should be drawn up in the project-specic change control
and/or project control procedures.

21.6.4 Illustration o the principle o baseline maintenance

21.6.4.1 Project planned
The original project plan is shown in green. Once reviewed, veried and agreed,
the baseline can be set. The baseline is shown here in yellow. Each activity has a
minimum o our dates, albeit currently the start dates match, as do the nish
dates.
Work on the activities then commences . . .

Figure 21.3 Baseline maintenance step 1

214
For use by APM individual and corporate members only
 Baseline

21.6.4.2 Project progress and delays ensue

. . . and, as progress is not as expected, delays to the schedule occur. Each
activity now has a duplicate set o dates that dier, except or the start o activity
1, which is shown with an actual start date matching the baseline start date.

Figure 21.4 Baseline maintenance step 2

21.6.4.3 Detail is now developed on activity 2; activity 3 is

re-assessed and reduced
At this stage, activity 3 is examined in more detail and re-planned. It is decided
that it can be executed aster than originally intended. This is entered in the
current schedule, showing the completion o this ragnet on time. There is no
need to do any baseline maintenance as a result o this re-assessment: the
baseline remains valid and is retained.
At the same time, activity 2 is broken down into more detail, as shown in the pink
bars. Since the budgets will also be broken down to this level o detail, it is necessary
to maintain the baseline – i.e. add bars into the baseline to refect the new detail.

215
For use by APM individual and corporate members only
 Planning, Scheduling, Monitoring and Control

Figure 21.5 Baseline maintenance step 3

26.6.4.4 The baseline is now updated with new detail

The baseline is set by adding the new detail into the baseline and linking it with
logic and/or constraints, in the same way that the original activity 2 was linked.
The nal working schedule and baseline schedule will appear as shown: the
original higher-level bars may be retained or deleted, but cannot be used to
measure schedule variances.

21.7 Re-baselining: re-planning

Re-planning is undertaken within the scope, schedule and budget constraints o
the project. This is done by maintaining the current cost variance and typically

216
For use by APM individual and corporate members only
 Baseline

Figure 21.6 Baseline maintenance step 4

eliminating the schedule variance, i.e. the remaining work is re-scheduled with
the current actual cost and earned value retained. The customer should be
advised prior to (and may need to approve) re-planning.
Re-planning should only be considered in two instances:

21.7.1 When to consider re-planning

21.7.1.1 When the client requests it
This may be because o loss o credibility, the client’s own reporting require-
ments or other events under which the client wishes to draw a line. The implica-
tions o re-planning should be discussed and the selection o this option be
mutually agreed, i possible.

217
For use by APM individual and corporate members only
 Planning, Scheduling, Monitoring and Control

21.7.1.2 When the credibility o the original baseline is lost

In practice, project teams are expected to know the current working schedule in
detail. They are measured against a baseline that perhaps moves urther rom
reality, and rom the oreront o the project team’s thoughts.
Thereore, on a project o long duration, the credibility o measuring against
the original schedule may be lost on the project team. In these circumstances it
may be prudent to diverge rom best practice (to maintain the baseline only) and
consider setting a new set o baseline dates. Since this is a divergence rom best
practice, it is recommended that this should not be a regular occurrence, certainly
not more than an annual event, and preerably no more than hal a dozen times
in any project.
It is possible to measure against two baselines (the original and the latest,
perhaps). However, careul consideration should be given to this and to how
widely dierent measurements should be shared. Indeed, the use o dual
baselines would be likely to be o use only to satisy diering requirements or
perormance measurement. On the principle o keeping project controls as
simple as possible, measurement against two baselines is to be avoided.
In conclusion, re-planning as described herein is intended to re-set the baseline
with regard to the timing o operations, and will thereore re-set all schedule
variance reporting. it should, however, have no eect on cost perormance
reporting (i.e. cost variance will remain as it was beore the re-plan).

21.8 Re-baselining: re-programming

Re-programming means setting a completely new baseline or the project,
including both time and budget benchmarks. Basically, this means wiping the
slate clean. Both schedule variance and cost variance are returned to zero.
Re-baselining should only be considered in two instances:

21.8.1 When to consider re-programming

21.8.1.1 When the client insists upon it
This may be triggered by loss o credibility (see below), the client’s own reporting
requirements or other events under which the client wishes to draw a line. The
implications o re-baselining should be discussed and the selection o this option
be mutually agreed, i possible.

218
For use by APM individual and corporate members only
 Baseline

21.8.1.2 When the credibility o the original baseline is lost

In practice, project teams are expected to know, in detail and background, the
current working schedule. At the same time, they are measured against a baseline
that, with the passage o time and changes in the current schedule, will move
urther rom reality, and, more pertinently, rom the oreront o the project team’s
minds.
On a project o long duration, thereore, the credibility o measuring against
the original schedule may be lost on the project team. In these circumstances it
may be prudent to diverge rom best practice (to maintain the baseline only) and
consider setting a new baseline. Since this is a divergence rom best practice, it is
recommended that this should not be a regular occurrence, certainly not more
than an annual event, and preerably no more than hal a dozen times in any
project.
In conclusion, re-baselining is intended to re-set the baseline with regard to
the timing o activities, and will thereore re-set all schedule variance reporting. It
will also re-set the baseline with regard to cost perormance reporting. It is
thereore likely that this option can only sensibly be considered in a cost plus type
contract, or at a point in the contract where a signicant re-negotiation has taken
place.

Table 21.1 Baseline maintenance, re-planning, re-baselining matrix

Re-set intermediate dates

Re-set contract dates

Budget movements*

Additional work*
Additional detail

Re-set budgets

*Authorised change only

Baseline maintenance √ √ √ ×x x× x×

Re-planning √ √ √ √ x× x×

Re-baselining √ √ √ √ √ √

219
For use by APM individual and corporate members only
 Planning, Scheduling, Monitoring and Control

21.9 Notes and rules or schedule

maintenance, re-planning and re-baselining
• Work transer should be accompanied by an associated budget and be agreed
by all stakeholders.
• Do not transer unused budget rom closed work packages to other work
packages or planning packages.
• Do not add additional budget to work packages that are in work unless
otherwise approved by the project manager.
• Transer o budgets should not be used to cover legitimate variances, and the
change control process should check or this.

21.10 The link between change management

and the project baseline
Only authorised change (ollowing appropriate governance) should be included
in the baseline.

220
For use by APM individual and corporate members only
 22.1 Denition o perormance reporting
Perormance reporting is the measurement o progress and spending made to
date compared with the plan. It should inorm management decision making
about steps required to mitigate poor perormance or maximise better than
planned perormance. Thus, it must:

• Measure what has happened:

• Is the project on schedule, ahead or behind?
• Is the project getting value or money?
• Forecast what is likely to happen:
• Is the project going to complete on time, ahead, or late?
• What is the orecast nal cost?
• Is the rate o work sucient, is it decelerating or accelerating?

Perormance reports may take a number o ormats, rom marked-up schedules

through to ormal written reports, though it is increasingly common or dashboard
reports to be produced that combine reporting on all aspects o projects; health
and saety statistics, environmental, commercial, time and cost perormance,
supply chain perormance, and details o key risks and mitigations.
Reporting may include analyses based on a variety o methods. These
may range rom very simple reporting through to critical path analysis and
earned value management. The latter two are considered the best methods
o monitoring and controlling a project, and would be the expectation or any
complex projects.

221
For use by APM individual and corporate members only
 Planning, Scheduling, Monitoring and Control

There are undamentally two types o perormance reporting: variance analysis

(which measures what has happened) and perormance analysis (which also
orecasts what is likely to happen).
Variance analysis includes the ollowing methods, which will be discussed in
this chapter:

• drop line method;

• activity weeks method;
• milestone monitoring;
• line o balance;
• cash-fow monitoring;
• resource monitoring
• cost value analysis
• quantity tracking.

Perormance analysis includes the ollowing methods, which will be discussed in

this chapter:

• network analysis and measurement o foat usage;

• earned value analysis.

In general, the variance analysis techniques are simple to do and understand, but
they are backward-looking, oten with no way o enabling projections and
orecasts. Perormance analysis techniques are harder to set up and run, but do
have these orward-looking qualities. Most sophisticated projects will run both
orms o perormance analysis, as even these are complementary and measure
dierent things. Variance analysis techniques are used to complement and help
communicate where necessary or useul.

22.2 Purpose o perormance reporting

Perormance reporting is undertaken to check whether satisactory progress is
being made and to identiy any corrective actions that may be required. Reporting
is undertaken to communicate the status o the project to those who need to
know. Part o the perormance monitoring regime should ensure that records are
made at the time, and retained in a orm that allows retrieval and analysis in the
uture or contractual or knowledge management purposes.

222
For use by APM individual and corporate members only
 Perormance reporting

Consideration should be given to the various methods o perormance reporting

available, and deploying them as appropriate. It is worth noting that rarely, except
in the simplest o projects, will one method provide a picture o project status that
is accurate and understandable to all stakeholders. Most advanced projects will
use a combination o network analysis and foat usage with an earned value
analysis, but even then additional tools such as quantity tracking (good or commu-
nication) or resource tracking (good or uture resource planning) may be deployed.
A good control system:

• rapidly brings perormance issues to management attention;

• motivates the correct behaviours to improve perormance – on the positive
side by showing what needs to be done and on the negative side by showing
what will happen i nothing is changed;
• integrates time, cost and risk;
• promotes awareness o time, cost and risk;
• summarises data at an appropriate and digestible level o detail;
• enables accurate orecasting and trending;
• is easy to use and understand.

22.3 Evaluating and recording progress

22.3.1 Progress assessment
There are three elements required or any perormance measurement: a
baseline to measure against; actual data (cost, or example); and an assessment
o what has been achieved (a physical percentage complete against an activity).
Progress is best evaluated by those responsible or the work. Progress will be
entered into the schedule – oten by the planner. The planner’s role also includes
the challenge, validation and verication o the progress inormation. The client
or his representative may also wish to veriy the progress reported within the
schedule.

22.3.2 What needs to be recorded in the schedule?

• The date to which the progress is being reported.
• Percentage complete (this measure should be based on the physical completion
o the activity) in order to enable assessment o progress.

223
For use by APM individual and corporate members only
 Planning, Scheduling, Monitoring and Control

• Remaining duration (this is based on the outstanding work on the activity) in

order to acilitate re-calculation o the network (critical path analysis).
• Actual start and actual nish dates, in order to build up the history o the project.

22.3.3 What else needs to be recorded in a report?

• Reasons or any delays;
• Trend curves to display progress.

22.3.4 How oten is progress recorded?

Frequency o progress update will depend on the circumstances. Hourly progress
updating may be used in cases o critical plant shut-downs, but weekly updating
o progress is more appropriate on most projects. On some larger-scale projects,
monthly updating o progress may be considered appropriate. I this is the case,
it is necessary to ensure that the mechanism or recording actual start and actual
nish dates is suitably robust. In addition, any type o trend analysis will take
longer to produce any meaningul results or corrective action.
Critical path analysis and trend analysis should be carried out on each progress
update. It is also useul at this stage to ensure that any emerging trends are
picked up as early as possible. For example, on weekly progress updating a trend
will be available ater 3 weeks, whereas monthly updating will take a minimum o
12 weeks.
Formal progress reporting is generally conducted on a monthly or 4-weekly basis.

22.4 Variance analysis methods o progress

monitoring
22.4.1 Drop line method
A vertical line is drawn at the point o the progress assessment date (sometimes
reerred to as ‘time-now’ or data date) across the bars on the schedule. At each
intersection with an activity, the line is ‘diverted’ to a point on the bar considered
to represent its progress: or example, i a bar represents work that is scheduled
to be complete, but is only 30% complete, the vertical bar is diverted to cross the
bar at the 30% point. This process is repeated to produce what is sometimes
reerred to as a drop line or jagged line (Figure 22.1).

224
For use by APM individual and corporate members only
 Perormance reporting

Figure 22.1 Illustration o the drop line method

I a project is perectly on schedule, then the drop line remains vertical. Thus
the deviations clearly indicate which activities are ahead and which are behind.
Whilst this is a good way o looking at the detail, it is not adequate or complex
logic-linked schedules.

22.4.1.1 Advantages o this method

• Provides a detailed record o each activity’s progress.
• Identies all activities that are behind and may require attention.
• A quick visual interpretation.

22.4.1.2 Limitations o this method

• Static: no re-scheduling o the schedule means eects o delay cannot be
easily assessed, thus ignoring foat and the possibility o avoiding unnecessar-
ily remedial action to get the project back on time.
• Not a very meaningul description o where the project is in overall terms (or
even on a sectional basis).
• Actual start and nish dates are not recorded.
• Will not be o much use in demonstrating delay.

225
For use by APM individual and corporate members only
 Planning, Scheduling, Monitoring and Control

• It is dicult to change the schedule, add data etc. Adding a new activity may
not be shown in a logical position i this is not done in scheduling sotware.
• Ultimately the schedule will not be a tool or proactively managing time, as it
will have become unrepresentative o a realistic approach to the work.
• Becomes even more unrealistic i re-sequencing takes place.
• Activity-based method that does not measure ‘work’.
• It measures time, but has no measure o cost versus value.

22.4.1.3 When can this be used?

Large or complex projects should have a detailed logic-linked schedule. However,
this method could sometimes be used alongside other more sophisticated
techniques such as critical path analysis and earned value analysis.

22.4.2 Activity weeks method

In order to monitor overall perormance on a project, one simple way is to measure
the number o activities each week (Figures 22.2 and 22.3). This does, o course,
take into account all the activities but does not allow ‘weighting’ o the tasks.
This method has been proven to be not only grossly inaccurate, but also
very misleading, sometimes critically so. Consequently it is not recommended as
good, or even acceptable, practice in this guide and is included or completeness
only.
For example, there may be 20 pipe tters perorming one activity and two
painters on the next. Typically, in construction, the mechanical and electrical
activities can comprise 30–40% o the value o the project, so a large part o the
project could be described very briefy on the schedule and would not represent
a air proportion o the work.
It is not untypical or projects, particularly larger ones, to commence with
airly detailed schedules or the earlier stages and less detail or the later
stages. This is known as rolling wave planning. In this instance, activity weeks
could grossly distort the position, as the schedule would be heavily weighted
in avour o the ront end and the project would appear to be ar more complete
than it is.

22.4.2.1 Advantages o this method

• A simple one-page picture o project position, but . . .

226
For use by APM individual and corporate members only
 Perormance reporting

Figure 22.2 Simple ‘activity weeks’ monitoring chart

22.4.2.2 Limitations o this method

• This method gives no certainty about schedule position, and there is no
credible or intellectually supportable approach or projecting the trend
orwards.
• It measures time, but has no measure o cost versus value.

22.4.3 Milestone monitoring

Key interim milestones are set by attributing activities to them. Achievement or
slippage o the milestones is then monitored. Milestones may be used to
determine payment. When used in conjunction with more sophisticated methods,
milestone monitoring can be a complementary means o visualising the achieve-
ments o the project and the uture orecast.

227
For use by APM individual and corporate members only
 Planning, Scheduling, Monitoring and Control

Figure 22.3 Cumulative results rom the ‘activity weeks’ chart

22.4.3.1 Advantages o this method

• A useul way o summarising the project, and attributing responsibility and
personal targets accordingly.
• Focus on key objectives.
• Simple, clear reporting.
• Easy to do and understand.

22.4.3.2 Limitations o this method

• There is a danger o this method being very misleading i milestones are not
clearly dened.
• The milestones do not necessarily cover all the scope.
• It can adversely infuence priorities, particularly when associated with payment
milestones, as undue eort is associated with achieving these milestones as
opposed to the ull critical path.
• It measures time, but has no measure o cost versus value.
• There is a danger o only realising that a milestone has been missed ater the
event, when it is too late to take corrective action.
228
For use by APM individual and corporate members only
 Perormance reporting

Figure 22.4 Recording actual progress in line o balance

• It tends to ocus on activity completion dates to the detriment o activity start

dates.

22.4.4 Progress on a line o balance chart

A line o balance chart with progress to date is shown in Figure 22.4.
Progress is monitored on these charts against the scheduled lines, and action
can then be taken as appropriate. In Figure 22.4 the solid lines represent the
scheduled production o units against time, and the dotted lines represent the
progress recorded against each trade. It clearly demonstrates the required
production rates and that which was achieved.
In this example, the rst activity is shown starting on time but at a slower rate than
scheduled. Eventually it accelerates until it is nearly back on schedule. It then slows
beore accelerating until becoming ahead o schedule. It nally nishes on time.

22.4.4.1 Advantages o this method

• Clear graphical display o progress.
• Productivity is measured, and presented graphically.
• Particularly useul or repetitive work at macro level (e.g. t out o residential
units) or micro level (e.g. monitoring number o pieces o steelwork erected).

229
For use by APM individual and corporate members only
 Planning, Scheduling, Monitoring and Control

22.4.4.2 Limitations o this method

• It is not available in mainstream sotware, although add-on/specialist sotware
is available.
• It measures time, but has no measure o cost versus value.

22.4.5 Cash-fow monitoring

This ocuses only on the nancial spend o a project. Spreadsheets are usually
prepared with planned budgets per week/month. The actual spend is then
monitored against the planned budget gures.

22.4.5.1 Advantages o this method

• Project nancing: i unds are nite, it gives advance warning o impending
shortages.

22.4.5.2 Limitations o this method

• Does not relate spend to physical progress: it tells you nothing about project
perormance (i.e. it cannot be determined whether actual spending above the
planned level means the project is over-spending, or that progress is ahead o
schedule).
• Can be misleading i the early part o the project has a lot o expensive costs,
e.g. purchase o plant or materials. Spending alone cannot be used to
determine the status o the project.
• For these reasons, cash-fow monitoring should not be used in isolation.

22.4.6 Resource monitoring

A simple measure based on scheduled resource usage across a schedule. Actual
resource usage is plotted against planned to give a measure o ‘progress’.

22.4.6.1 Advantages o this method

• I particular resources are critical, then this can be an important measure.
• Can be used to orecast when resources are becoming available or other
works.

230
For use by APM individual and corporate members only
 Perormance reporting

• May be used where environmental concerns limit usage (or example, lorry
movements in built-up areas).

22.4.6.2 Limitations o this method

• Can be misleading, with a lot o man-hours being expended but little actual
progress on the works.
• Provides a measure o eort rather than progress.
• For these reasons, it should not be used in isolation.

22.4.7 Cost value analysis

This process compares cost against value. Cost here means the actual costs
incurred or accrued, while value means the value o the work done (‘earned
value’ or similar). The analysis is undertaken against the agreed cost breakdown
structure (Figure 22.5).
This clearly highlights areas o over- or under-spend, and will provide the basis
or estimates o the nal cost o the project.

22.4.7.1 Advantages o this method

• Ensures project cost inormation is structured, analysed and interpreted.
• Relatively simple to do and understand.
• Highlights areas o poor or good perormance to prompt management action.

22.4.7.2 Limitations o this method

• Does not provide trend data in the way that earned value analysis does.
• Does not require the integration o cost and time.
• Cannot be used as a time-phased nancial orecasting method.

22.4.8 Quantity tracking

The monitoring o key quantities (also known as production curves) is a
useul method or key tasks that are heavily dependent on the quantity o material
deployed, moved or altered, or or tasks that are very numerous and broadly
repetitive. An example o the ormer would be earthmoving in construction;
an example o the latter would be the production o design deliverables (such

231
For use by APM individual and corporate members only
 Figure 22.5 Sample cost value report

For use by APM individual and corporate members only

 Perormance reporting

Figure 22.6 Quantity tracking with production curves

as drawings) in any engineering project, or lines o code in a sotware develop-

ment project.
Note: Although not shown in Figure 22.6, a useul additional line to show
might be the assumed rate at tender or the organisation’s normal output rate: this
may put any peaks or troughs in the daily expected outputs into perspective.

22.4.8.1 Advantages o this method

• Easily and readily understood.
• Highly relevant i key tasks or quantities are chosen.
• Will highlight areas where corrective planning is required.

22.4.8.2 Limitations o this method

• Only really relevant to suitable items o measurement.
• Cannot be aggregated to give a holistic picture o the project.

233
For use by APM individual and corporate members only
 Planning, Scheduling, Monitoring and Control

• Does not give a measure o value or money.

• May be misleading i the quantities reerred to are estimated rather than
accurate, or may otherwise vary when undertaking the work.

22.5 Perormance analysis methods o

progress monitoring
22.5.1 Network analysis and measurement o foat usage
This method ollows the progress update o the schedule and subsequent
network and critical path analysis. This will reschedule activities to where they
are now likely to take place and may thereore aect the end date, sectional
completion dates or sub-contractor schedules. This, in turn, raises such potential
issues as preserving continuity o work, acceleration or deceleration o activities,
parallel working, or delays to activities which will need consideration and
management action.
Once the critical path analysis has been run, the critical path may change,
and dierent foat paths may have been calculated. It is thereore essential
to monitor the use o foat where it exists. This will ensure that there is an
awareness o emerging critical paths, should either under-perormance or,
indeed, accelerated perormance create these.

Table 22.1 Measurement o foat usage

Date Baseline Forecast Float Current Delta Commentary
date date last foat
report

Key date 1 4/2/15 4/2/15 20d 18d –2d

Key date 2 2/4/16 4/4/16 10d –2d –12d
Section date 2/4/17 4/2/17 20d 20d —
Contract completion 2/6/18 2/6/18 30d 28d –2d

22.5.1.1 Advantages o this method

• The critical path is a logical, mathematical model o the project that orces
attention onto important activities.

234
For use by APM individual and corporate members only
 Perormance reporting

• The critical path is always current.

• Eects o delays are more likely to be analysed.
• Actual start and actual nish dates are more likely to be recorded.

22.5.1.2 Limitations o this method

• There is a risk with just monitoring the critical path that managers only look at
the critical activities rather than the near-critical paths.
• The critical path tends to be less relevant at the end o a project. The availabil-
ity o resources to complete the nal activities oten becomes a more critical
actor or project completion.
• It as an activity-based method that does not measure ‘work’ done.
• This is a sophisticated technique, and appropriate skills and time are required
to undertake it.
• It measures time, but has no measure o cost versus value.

22.5.2 Earned value analysis

22.5.2.1 Denition o earned value analysis
Earned value analysis (EVA) is a perormance analysis method that compares the
scheduled amount o work (planned value) with the achieved amount o work
(earned value) at a point in time. It also compares the work achieved (earned
value) with the cost o achieving that work (actual cost). From these three pieces
o data, perormance can be trended and metrics calculated to express the status
o the project.
Furthermore, it has been demonstrated that simple predictive calculations can
be highly indicative o likely project outcome in terms o both time and nal cost,
provided that appropriate care and experience are used in creating the baseline,
gathering data and interpreting the calculations.
A detail exploration o earned value can be ound in the APM’s Earned Value
Handbook (APM, 2013).

22.5.2.2 Purpose o earned value analysis

Earned value analysis (EVA) is a perormance analysis method that, when
used properly, improves the delivery o projects. It does this by shining a light
on perormance issues. Using the data properly means that discussions are

235
For use by APM individual and corporate members only
 Planning, Scheduling, Monitoring and Control

prompted by those who can make a dierence, eecting changes necessary

to improve perormance. Where this is not possible, EVA provides an early
warning o likely outcome in terms o cost perormance and likely completion
date.
EVA brings together the cost and time management o a project. It enables
proactive management o a project, as it gives certainty o project status, produces
metrics that aid project management by allowing visibility o perormance, and
permits remedial action to be understood and taken.
In addition, it reinorces best practice, as it requires a structured approach to
planning. It provides a robust link between time and cost management,
encouraging constructive working relationships. It orces project managers to
consider and address cost and time issues at an early enough point to allow
remedies to be cheaper and more eective.
EVA is a complementary method to robust techniques, in particular critical
path analysis, but replaces the fawed and potentially misleading activity weeks
method, which is to be avoided on all but the simplest projects.

22.5.2.3 Basic terminology

Budget at Completion (BAC): The nal planned budget at completion o the
project.
Planned Value (PV): The approved budget or the work scheduled to be
completed by a specied date. Also known as budgeted cost o work scheduled
(BCWS)
Earned Value (EV): The approved budget or the work actually completed by
the specied date; also reerred to as the budgeted cost o work perormed
(BCWP).
Actual Cost (AC): The costs actually incurred or the work completed
by the specied date; also reerred to as the actual cost o work perormed
(ACWP).

22.5.2.4 Establishing a budget-loaded schedule

The purpose o budget loading the schedule is to establish cost targets or
individual elements o the work. The budget elements are shown in Figure 22.7.
The perormance measurement baseline (PMB) is established by allocating
budget to the plan at activity level. Usually this is in terms o money and man-days/
hours.

236
For use by APM individual and corporate members only
 Perormance reporting

It is important to allocate budget at an appropriate level o detail to acilitate

accurate calculations or planned and earned values: this would normally
mean activities o duration between 4 and 6 weeks, though there will be
exceptions in both directions. Care should be taken with activities o longer
duration than 6 weeks, and i these are used, they should be easy to assess
with an appropriate, objective measure. On the other hand, the greater the
granularity achieved in the schedule the more subjective the assessment
can be, without compromising the essential integrity o the EVA system.
(Greater granularity implies that smaller ‘pieces o work’ are measured, and
the subjective nature o the assessment is thus reduced to an acceptable level
o detail.)
Failure to allocate budgets at an appropriate level in the PMB will lead to
inaccuracies in the calculation o the planned value and earned value.

Figure 22.7 Budget allocation to the plan

22.5.2.4.1 Work packages

The work package is the lowest level at which perormance data is normally
analysed. It will be a node on the WBS. The work package will contain a number
o activities that describe the work, and the budgets must be allocated at
activity level. Attention is required to ensure that an adequate level o detail is
achieved in these activities. Typically they should have a maximum o 4–6-weeks
duration or projects exceeding 12 months, but there will always be exceptions.
However, or longer activities it is important that progress can be easily and
clearly measured.

237
For use by APM individual and corporate members only
 Planning, Scheduling, Monitoring and Control

Management and support activities are included in work packages, and it is

important to measure perormance against budget. They are generally progressed
as level o eort activities, as reerred to later in this section.

22.5.2.4.2 Planning packages

Planning packages is the term used to reer to work packages where detail is not
yet planned, or work is yet to be allocated. They are, by denition, some time in
the longer-term uture, possibly as a part o rolling wave planning.

22.5.2.4.3 Management reserve and contingency

Management reserve is budget allowed or unknown unknowns, and should not
normally be included in the perormance measurement baseline. EVA is not
designed to give any useul measure o perormance against contingency;
separate measurements are appropriate or monitoring its use.

22.5.2.4.4 Risk
Risk is the budget allowed or known unknowns. As noted above, there is no
practical benet in measuring risk budget, as there is not a 100% chance o it
being earned, and so it may distort perormance measurement. However, it is
sometimes required to be included or completeness. There are a number o
ways o spreading the budget or risk. One way is across the remaining project
time, but that requires adjustment at every progress update. Alternatively, it can
be held in a ‘risk pot’ at the end o the project. In any event, risk money cannot be
earned; it can only be transerred into other work packages, in line with the risk
and change process.

22.5.2.4.5 Risk mitigations

Risk mitigations are agreed actions that have resulted rom the risk process.
These should be considered and included in the schedule where relevant – i.e.
where they have an infuence on time and the network o activities (as opposed
to, or example, management actions such as ‘additional sta brought in to
mitigate risk o. . .’), although in all cases any associated budget must be refected
in the perormance measurement baseline. The mitigations will be held in the
relevant work or planning package.

238
For use by APM individual and corporate members only
 Perormance reporting

22.5.2.4.6 Contractor’s ee

As noted above or management reserve, there is no practical benet in measuring
this item, though it is oten required to be included or completeness. It should
be treated as a level o eort activity, such that planned value always equals
earned value. It should be noted that the eect o treating this as a LOE activity is
to skew the overall SPI towards 1.0, as the SPI or a LOE activity is always 1.0.

22.5.2.5 How to deal with infation

Infation will raise the cost o labour and materials during the lie o the project. I
infation needs to be taken into consideration in project budgets, or example i a
project spans multiple years, then a way o dealing with it is required. It is common
to use indexation tables to agree the sums involved. This is to ensure that a
comparison between budgeted gures (in the orm o planned value) and
out-turn gures are like or like. There are two options:

• Add (or deduct!) an allowance into the value.

• Deduct (or add!) an allowance rom the actual costs beore calculating the
actual cost in EVA.

In either case a protocol must be agreed, but the second option is likely to be the
simpler.

22.5.2.6 Setting the baseline

Once the allocation o budget to the schedule is complete, a baseline is set. This
baseline should not then be adjusted without the appropriate change control
process approving such a change.
Once the schedule is suciently developed and stable, it should be set as the
perormance measurement baseline (PMB). This then orms the basis or
measuring all uture progress and perormance.

22.5.2.7 Drawing S-curves with EVA

22.5.2.7.1 Planned value
Once the budget has been allocated (usually refected in the planning sotware), an
S-curve or the planned value over time can be created, as shown in Figure 22.8.

239
For use by APM individual and corporate members only
 Planning, Scheduling, Monitoring and Control

Figure 22.8 Planned value curve

22.5.2.7.2 Measuring progress to calculate earned value

Earned value is the value o the work that has been completed, and is calculated
by collating the percentage completion multiplied by the total budget o each
activity.
As the project is executed, progress is measured periodically, with each activity
assessed or physical percentage complete. (The methods o measurement are
discussed later.) Summation o all the progress recorded enables a progress
curve to be plotted. This is the earned value.
Once the schedule has been updated or progress, the earned value can be
plotted against the planned value, as shown in Figure 22.9. The diagram
represents perormance less than the planned expectation, or earned value less
than the planned value line.

22.5.2.7.3 Recording actual costs

It is important to collect actual costs at the right level o detail, as increased gran-
ularity is very likely to lead to reduced data integrity. They should be collected at
the appropriate level o the WBS (this may also be known as the cost breakdown
structure).

240
For use by APM individual and corporate members only
 Perormance reporting

Figure 22.9 Earned value

Note: It will be necessary to allow or accruals in the cost collection system.
Once the actual costs have been added to the schedule, the cumulative
actual costs can be plotted as shown in Figure 22.10. In the diagram, costs are in

Figure 22.10 Actual costs (ACWP) added

241
For use by APM individual and corporate members only
 Planning, Scheduling, Monitoring and Control

excess o what should be expected which would be parity with the earned
value line.

22.5.2.8 Calculation o variances and key perormance

indicators (KPIs)
Having entered the planned value, earned value and actual cost, there are various
earned value calculations that can be used to analyse this data (Figures 22.11–
22.13).

22.5.2.8.1 Cost variance (CV)

Cost variance (CV) is a cost comparison between what has been earned and
what has been spent (‘Are we under or over budget?’).
Cost Variance = Earned Value – Actual Cost
CV greater than 0 indicates a cost under-run
CV equals 0 indicates on budget
CV less than 0 indicates a cost over-run

Figure 22.11 Earned value analysis: cost and schedule variance

242
For use by APM individual and corporate members only
 Perormance reporting

22.5.2.8.2 Schedule variance (SV)

Schedule variance (SV) is the cost comparison between what has been earned
and what has been budgeted (‘Are we ahead or behind schedule?’).
Schedule Variance = Earned Value – Planned Value
SV greater than 0 indicates that the project is ahead o schedule
SV equals 0 indicates on schedule
SV less than 0 indicates that the project is behind schedule

Cost and schedule variance can useully be charted, either separately or

together (see Figure 22.12)

Figure 22.12 Cost and schedule variance chart

EVA measures schedule perormance in terms o value as seen, but also in terms
o time: time variance can be calculated or read o the graph as in Figure 22.13.
This is the dierence on the time axis between the quantity o work achieved to
date, or earned value, and the corresponding quantity on the planned value curve.
Measuring and expressing delay in this way may help to give an alternative
view o progress. It will also not suer rom the issue, already noted, that schedule
perormance index (SPI) and SV tend towards parity as the project nears

243
For use by APM individual and corporate members only
 Planning, Scheduling, Monitoring and Control

Figure 22.13 Earned value analysis with time variance

completion. (Although it has been stated that this is a faw in earned value
analysis, in reality we should expect project managers to be aware o approaching
completion dates!).

22.5.2.8.3 EVA key perormance indicators

A number o calculations can be made: the two most useul, and the basis or
calculations o uture perormance, are the schedule perormance index (‘How
are we doing against plan?’) and cost perormance index (‘Are we ecient?’).
These are calculated as ollows:

Schedule perormance index (SPI) is an indication o how ar ahead or behind

the planned work is compared with the actual work achieved. A result o 1.0
means that all the planned work was achieved. Its value as an indicator diminishes
towards the end o a project.
SPI greater than 1 indicates that the project is ahead o schedule
SPI equals 1 indicates on schedule

244
For use by APM individual and corporate members only
 Perormance reporting

SPI less than 1 indicates that the project is behind schedule

Cost perormance index (CPI) is the ratio o earned value over actual cost. A
gure greater than 1.0 indicates that the actual cost o the work achieved cost
less than planned.
CPI greater than 1 indicates a cost under-run
CPI equals 1 indicates on budget
CPI less than 1 indicates a cost over-run
SPI and CPI can useully be plotted against each other to create a ‘Bulls eye’
chart, as shown in Figure 22.14.

Figure 22.14 Bulls eye perormance chart

245
For use by APM individual and corporate members only
 Planning, Scheduling, Monitoring and Control

The shading indicates the BRAG rating that may also be allocated to the KPIs,
where
B=Blue: Perormance over that expected (and needs investigating)
R=Red: Perormance seriously below expected (needs immediate corrective
action)
A=Amber: Perormance below expectation (needs planning or corrective action)
G=Green: perormance within expectations (no action required)

22.5.2.9 Forecasting terminology

Estimate to complete (ETC): An estimate o the amount o unds required to
complete all remaining work on the project (‘What will the remaining work cost?’).

Estimate at completion (EAC): The sum o the actual costs to date plus the
estimate to complete (ETC) (‘What is the project likely to cost?’).
EAC = Actual cost + ETC

Figure 22.15 Calculating estimated time to completion

246
For use by APM individual and corporate members only
 Perormance reporting

It has been shown (Webb, Alan (2003, 26) Using Earned Value, Gower) that
mathematically the ormula or EAC can, in act, be simplied to:

Estimated time to complete (ETTC) can be calculated as ollows (Figure 22.15):

Again, It has been shown (Webb, Alan (2003, 26) Using Earned Value, Gower)
that mathematically the ormula or ETTC can, in act, be simplied to:

22.5.2.10 Earned value techniques (EVTs)

The dierent methods o measuring earned value known as earned value
techniques generally vary according to the level o detail in the schedule.
Short-term hourly or daily schedules would probably be progressed daily by site
sta. Very oten customers require dierent reporting techniques. Some examples
are shown in Figure 22.16. It is important to bear in mind the level o reporting
detail required when determining the granularity o the schedule, as detailed EV
reporting is dicult rom high-level summary schedules.

Figure 22.16 Illustration o various earning techniques and appropriate uses

247
For use by APM individual and corporate members only
 Planning, Scheduling, Monitoring and Control

Figure 22.17 Advantages and disadvantages o EVTs

248
For use by APM individual and corporate members only
 Perormance reporting

22.5.2.10.1 Recognised earned value techniques

Figure 22.17 summarises the advantages and disadvantages o EVTs.

22.5.2.11 Advantages o EVA

Below are some o the benets o using earned value analysis on a project:

• Certainty o project position: what work has been achieved against plan; what
it has cost to reach that level o achievement.
• Whether the work achieved represents good value or money (i.e. has been
achieved eciently).
• Gives early warning o whether the project is likely to nish on time and/or on
budget.
• Improved decision making: guides attention to problem areas that need
management decisions.
• Provides the basis or inormed cost and/or time recovery actions.
• Ensures that a robust plan is established at the outset o the project.
• Management o scope creep through the change control system.
• Ensures cash-fow is measured properly and optimised.
• Provides corporate governance (when done across the organisation).
• Business benets include turnover, prot and cash being achieved on time or
as soon as practicable.

22.5.2.12 Limitations o EVA

The view that EVA is best practice in project management is long established, but
earned value management is not the universal panacea o project management,
and ailure can still occur on a project monitored using earned value. One o the
biggest threats is that the project team ocus too much on regularly generating
the data or EVA and ail to take notice o the messages it gives.
Data integrity is also key to making EVA work. With good data, the project
manager has a lot o reliable inormation to assist in managing the project, which
greatly assists in decision making.

249
For use by APM individual and corporate members only
For use by APM individual and corporate members only
 23.1 Denition o cost control
Cost control is the process o collecting actual costs and collating them in a
ormat to allow comparison with project budgets, identiying variances to
inorm decision making and allow action to be taken. In addition, it includes cost
orecasting.
Cost orecasting is the process o using perormance measurement, progress
inormation and risk management to estimate how the costs will be spent going
orward to the end o the project or nancial year and inorm the anticipated nal
cost (AFC).

23.2 Purpose o cost control

Cost control is necessary to keep a record o monetary (and other) expenditure,
or the purposes o:

• minimising cost where possible;

• revealing areas o cost overspend;
• giving sucient detail to allow management decision making to correct unac-
ceptable overspending;
• providing data or lessons learned to inorm uture projects (or phases o the
same project).

251
For use by APM individual and corporate members only
 Planning, Scheduling, Monitoring and Control

23.3 The cost control process

23.3.1 Perormance measurement baseline (PMB)
The initial cost model orms the basis o the cost-loaded perormance measure-
ment baseline and should be aligned with the schedule activities at an appropri-
ate level in order to measure nancial progress, orecast out-turn project costs
and phasing, and acilitate earned value analysis. When updating or re-setting
the baseline, it is important to ensure that the cost inormation is up to date, as
any variances may signicantly aect the project’s ability to highlight and react to
negative trends.

23.3.1.1 Estimates to complete

Estimates to complete (ETC) are prepared as part o the EVA process and are
used to determine how project costs are trending to derive the project Estimate
at completion (EAC).

23.2.1.2 Estimated nal cost

The estimated nal cost (EFC) is prepared as part o the project cost control
process and is used to determine how project costs are perorming against the
authorised project budget. EAC (derived rom EVA data) should be used to
challenge the EFC.

23.3.2 The link between cost control

and change control
It is important to ensure that any changes to project costs and/or budgets
are ormally managed through the project change control process. This not
only acilitates quick and inormed nancial approvals, helping the project to
move orward, but also leaves a much-needed audit trail or the lessons learned
process at the end o the project. Dierent levels o change may require dierent
change control processes, so ensure any change is managed in the appropriate
way.
I the change results in amended scope, then the perormance measurement
baseline must be updated through the appropriate change control process once
it is approved by the project manager or relevant authority.

252
For use by APM individual and corporate members only
 Cost control

23.3.3 Perormance measurement

The most common method o cost perormance measurement is the cost value
report, in which actual costs or work undertaken are compared (usually in a
spreadsheet) against the current budget or the same work. A combination o the
cost value report and orecast uture changes are used to inorm the estimated
nal cost (EFC).
Forecast uture changes may include:

• anticipated scope change via client or supplier ormal change process;

• known or anticipated cost over- or under-spends;
• risks or opportunities;
• infation/indexation;
• exchange rate changes.

These changes will highlight cost variance. This is the dierence between the
assumed costs o the project or activities in the perormance measurement
baseline at the point o reporting, and the actual costs that the project is committed
to at that same point.
A recognised best practice around cost control is through the use o earned
value management where the cost perormance index (CPI) is the key indicator
o project nancial perormance. This process is described in detail insection
22.5.2. It is ideal or identiying where a project is not progressing eciently.

23.4 Learning lessons rom cost control

Cost control inormation is undamental to the lessons learned process, as it can
provide a database o actual costs against activities and work packages that can
be used to inorm uture projects at the inception phase. When dealing with
suppliers, the contract administration process will reveal unoreseen changes to
the project and its costs. Ensuring rigid document control around these changes
can greatly increase uture projects’ chance o success through more accurate
estimating and/or a more inormed risk management process.

253
For use by APM individual and corporate members only
For use by APM individual and corporate members only
 24.1 Denition o short-term planning
The duration o short-term planning may vary depending upon the duration o
the project, but is likely to consist o a 4-week look ahead and a look back at the
previous week’s progress. It would normally be issued weekly. (These durations
would obviously be inappropriate or a weekend shut-down schedule!)

24.2 Purpose o short-term planning

The short-term planning process takes the schedule out o the computer and
puts it into the hands o the site teams supervising the work. It should also refect
current progress, with recovery o slippage i necessary.

24.3 The short-term planning process

Short-term planning should be linked to the schedules as shown in Figure 24.1.
There should also be a link, or a cross-check with the schedules produced at this
level back to the main project schedule(s) to ensure that the strategic require-
ments o the project remain achieved.
Short-term, high-density scheduling consists o our key elements:

• perormance reporting against last week’s planned work;

• reasons or any non-completed work;

255
For use by APM individual and corporate members only
 Planning, Scheduling, Monitoring and Control

Figure 24.1 Short-term schedules in context o other plans

• the work planned over the next 3 or 4 weeks (with a strong emphasis on the
next week);
• the make ready needs or these activities (these are the start criteria or each
detailed task).

The short-term scheduling is undertaken weekly and is owned by the ront-line

sta; in order to acilitate the process an extract o the schedule is produced,
typically a 3-month look ahead. This will then be used to generate the 4-week
look ahead, developing detail to a day-by-day schedule.
Once produced, the schedule will be checked against the strategic
requirements as dened in the current working schedule.
Having produced a 4-week ‘look ahead’, the ollowing are considered:

256
For use by APM individual and corporate members only
 Short-term planning

24.3.1 Make ready needs

Each activity has ‘make ready needs’ identied. Make ready needs are those
things that must be in place to allow an activity to commence. These may include:

• sae working practices;

• material call o or availability;
• other procurement activity;
• method statement and other paperwork in place;
• ofine preparation or task, e.g. in construction the building o ormwork
panels;
• outstanding design inormation or RFIs (requests or inormation);
• completion o works by others (which will eature elsewhere on the look
ahead);
• access requirements.

24.3.2 Coordination meeting

Coordination meetings are held to review the combined schedule, to record
perormance against agreed objectives, and to understand and analyse issues
which hinder the progress o those activities.
All schedules should be issued the day prior to the coordination meeting,
allowing time or review. This is to ensure that maximum benet is gained rom
the meeting. Discipline is required to ensure that schedules are delivered on
time, because the process relies on a large number o people producing their part
o the schedule in a timely manner. Strong chairmanship o the meeting is
essential to ensure ull participation and agreement o the schedule by all.
A key purpose o the meeting is to ensure that all schedules are agreed and
issued at the end o the meeting; schedules can be hand amended – do not wait
or electronic distribution.

24.3.3 Perormance reporting

As part o the meeting, the previous week’s progress should be reviewed, and
any reasons or missed targets are categorised against a predetermined list.
Charts will be produced or analysis outside the meeting (Figure 24.2).

257
For use by APM individual and corporate members only
 Planning, Scheduling, Monitoring and Control

Figure 24.2 Perormance analysis on short-term schedule

258
For use by APM individual and corporate members only
 25.1 Denition o change management
Change management is the ormal process through which changes to the project
are raised, assessed, approved, and introduced or rejected.
‘Changes’ are events and issues that alter the schedule, scope or objectives. In
broad terms, there are two levels o change:

• Signicant additions/omissions rom the schedule scope – these changes will

require amendments to the control budget and related schedules.
• Amendments to the method o delivery where the undamental scope
remains the same. These amendments may be the result o clarication or
development.

Signicant changes may arise rom:

• inside the project, such as risks impacting, adoption o wrong strategy, etc.,
where they will be unded rom management reserve drawdown;
• outside the project, such as a new customer requirement, where they will
require additional unding;
• a change in legislation.

25.2 Purpose o change management

Change management is integral to good project management because it controls
and authorises:

259
For use by APM individual and corporate members only
 Planning, Scheduling, Monitoring and Control

• change in scope;
• changes in budgets;
• changes in timing o the project;
• changes in risks that are managed as part o the project;
• changes in expenditure.

Thus, it ensures that costs are known and that the supply chain receive air
recompense or any additional work that they perorm, whilst protecting the
client rom paying or works that are not perormed.

25.3 Principles o change management

Any proposed change to the project must be ormally controlled in order or it to
be dealt with eciently and airly. The project team, with the support o relevant
stakeholders including the sponsor, should thereore review changes ully beore
their approval and implementation. The impact o changes on all aspects o the
project in terms o scope, budget, time, quality, saety, environment, risk and
opportunity should be ully assessed, as well as their impact on business as usual
and other projects.
The key points o reerence when considering change are the baseline
(budget/schedule plan), and the project execution plan (PEP). The baseline
denes the point against which change is measured, whilst the PEP gives the
detail o how the change process is managed.
All changes should be ully documented and eciently communicated to all
relevant parties.

25.4 Change control

25.4.1 Why change control is needed
• To ensure all parties are clear regarding the scope to be delivered.
• To ensure all parties are clear regarding the schedule to be delivered to.
• To ensure all parties are clear regarding the budgets to be delivered to.
• To ensure clear visibility o movements within published budgets and
schedules as the project progresses.
• To enable early recognition and management o issues that could be infuenced
or the good, i.e. cheaper, quicker, better-quality and more ecient solutions.

260
For use by APM individual and corporate members only
 Change management

• To maintain an audit trail o who authorises or rejects change: what, when,

how, or what cost and why?
• To ensure potential change is identied in a proactive manner.
• To ensure appropriate levels o change review and approval are
implemented.
• To ensure change is reported accurately.
• To ensure all options are considered and evaluated.
• To ensure change is implemented within appropriate time periods.
• To ensure that the project remains under control and can be delivered in an
aordable, protable, value or money manner.
• To ensure that the product delivered meets developing customer needs (i.e. is
not against a requirement that is now obsolete).

25.4.2 Change control considerations

The change control process must also consider:

• Unauthorised change: I an unauthorised change is identied, it must be retro-

spectively put through the change control process.
• Conguration management: Change control is intrinsically linked to congur-
ation management. Any changes need to be ed back into the project’s cong-
uration documentation. This ensures that the most current inormation is used
to deliver the project.
• Change reezes: In certain circumstances, it is appropriate to have a change
reeze on the project whereby no urther changes will be considered, as to do
so would jeopardise the achievement o the project objectives.
• An emergency procedure to enable certain actions (change) to be authorised,
or example in the case o an emerging health and saety issue at a point in
time where usual authorities are unavailable.
• Trending o change against specic areas will help to reveal underlying
problems and/or provide an early warning o increasing costs and areas
requiring management attention.

25.5 Project-level change: process overview

Once the project brie has been agreed, the change control procedures should
commence.

261
For use by APM individual and corporate members only
 Figure 25.1 Process overview – project change control

262
For use by APM individual and corporate members only
 Change management

Change on projects needs to be closely monitored to ensure that cost, time

and quality are eectively controlled and reported. A change control process is
likely to be dierent rom one company to the next. Similarly, it may vary across
dierent industries. The fow chart in Figure 25.1 gives an overview o a typical
change control process.

25.6 Raising a change request

Potential change can be identied by anyone within the project team. The
potential change is reviewed to determine whether a change o project brie or
scope has occurred, in which case a change request needs to be raised.
A stakeholder who is requesting change provides relevant inormation on the
nature o the proposed change. This should include a detailed description o the
change (what, where, when, who and how, etc.) The positive or negative cost
impact o the change and the impact on the schedule should be stated. The
benet(s) o undertaking the change should be made clear i not already evident
rom the oregoing.

25.6.1 Drating a change request

All ormal change requests need to be submitted using a change request orm.
The change request orm is designed to capture the ollowing detail:

• a description o the change;

• a classication o the change;
• the cost impact (positive or negative);
• the schedule impact (positive or negative);
• the approvals required;
• the links to the project risk and opportunity registers.

The change request should be accompanied by all relevant documentation.

25.7 The change log

The change is entered into a Change log, which is a register o all changes that
have been requested, whatever their status, or example pending, approved,

263
For use by APM individual and corporate members only
 Planning, Scheduling, Monitoring and Control

rejected or deerred. It contains a record o each change request and should

include at least the ollowing:

• unique ID number;
• status o the change;
• change description;
• detailed scope o the change;
• category o change;
• created by (the change originator);
• date raised;
• impact assessment – scope/budget/schedule/risk/saety, etc.;
• authority;
• unding/budget;
• decision: (approval/deerral/rejection) and date.

25.8 Initial evaluation o the change request

The change is reviewed to consider whether it is worthwhile evaluating it in
detail. The evaluation o change consumes resources, which in itsel is a deviation
rom the project baseline. The proposed change may be rejected without urther
evaluation.

25.9 Estimating impact o change

Impact analysis o the change and associated cost and time estimates should be
prepared, reviewed and submitted or approval. The estimates should include
direct cost and indirect cost such as management, and risks and opportunities
should be assessed.

25.10 Detailed evaluation o change request

Upon approval o the initial estimate, the change is evaluated in detail to consider
the impact on the project’s baseline scope, time, cost, quality or benets. I the
request is rejected, then the relevant parties are inormed and the change log
updated accordingly. There may be a situation where the request is deerred as

264
For use by APM individual and corporate members only
 Change management

more inormation is required. Once that has been supplied, then the request
re-joins the process at detailed evaluation stage.
Once a change request has got through the initial evaluation, it proceeds into
the detailed evaluation.
This evaluation is usually carried out in a regular change review meeting. The
meetings would be attended by all the relevant parties on the project, but,
importantly, they require the project sponsor or authoriser or the change
request.
There are three possible outcomes or a change request:

• rejected;
• deerred;
• approved.

This section will address rejected and deerred (approved change being dealt
with in the next section).

25.10.1 Rejected request

A rejected change request would be recorded in the change log stating the
reason or the reusal. This is then communicated back to the requesting party.

25.10.2 Deerred request

A deerred request normally requires more inormation to be supplied beore ull
consideration can be given to the request. The team will then carry out a more
detailed evaluation based on the areas where urther inormation is needed. The
results o any investigation may include a revised schedule, indicating the eect
o signicant changes to interaces and summary milestones. Any changes will
need to be reviewed by all parties concerned.
A deerred request may also be optional change, in that the change will only
be approved i the impacts are within certain parameters. Optional change may
also require the consideration o alternative schedule possibilities. In these cases,
‘what i’ or ofine schedules are used to review the dierent options as part o the
change process. There may be more than one ‘what i’ schedule required to
model a number o potential options. It is important that the extra inormation is
returned within the time constraints dened in the contract and perormed in
parallel with the cost investigation.

265
For use by APM individual and corporate members only
 Planning, Scheduling, Monitoring and Control

The extra data provided then goes back into the process or detailed evaluation.
I agreement is not achieved, the schedule eects may need to be re-visited
prior to any urther action.
Again, the change log would be updated and the details o the inormation
required passed back to the requester.

25.11 Approved request

I the change request is approved by the authorised person, then the change log
should be updated. The baseline and budget will also need to be revised.

25.11.1 Change orders

Change orders may also be known as change notices.

25.11.1.1 What does a change order do?

Change orders are used to authorise a change to the project, including a change
o scope or agreement to accept a design solution which is outside the agreed
cost and schedule parameters. Once ormal approval is received or the change,
the cost and schedule baselines are updated.
Change orders are also used to gain ormal approval or additional unding
ollowing a change. They do not, however, change the scope o the project or the
suppliers to action, and must always be supported by an appropriate instruction.

25.11.1.2 Who raises/authorises change orders?

A change order is raised by anyone with authority to do so (as dened in the
project procedures). Once raised, it is endorsed by the project manager prior to
being submitted to the project sponsor or authorisation.
Scope can only be instructed and authorised into or out o the project baseline
by the project sponsor/client, and not the project teams.

25.11.1.3 Commercial signicance

The change order only provides authorisation to change the scope. Funding
approval will also be required beore the ormal instruction or the change can be
issued.

266
For use by APM individual and corporate members only
 Change management

25.11.2 Scope transers

In circumstances where scope is being transerred between teams, a ormal
instruction will be issued to conrm the scope and budget transer. Scope
transers should be mutually agreed by the original owner and the proposed
owner.

25.11.3 Schedule revisions

I the change aects the scope, then it will be necessary to add the change and its
eects into the baseline as well as the working schedule.
Alternatively, i the change is within the existing scope, then the working schedule
should be amended. Where appropriate, the baseline will need to take into
account the updated schedule.
A change request will be required or any change to the project baseline (but
not the working plan).

25.11.4 Corporate governance

In order to maintain an ecient change management process, delegated authority
can be granted to managers at pre-agreed levels (see Table 25.1).

Table 25.1 Example o nancial authority

Responsible Instruction value

Project managers Up to and including £50k

Programme managers Up to and including £75k

Directors Up to and including £500k

Board Over £500k

25.12 Implementing the change

The key part o the change process is to implement the change. The project
manager will issue a ormal instruction to implement the change.

267
For use by APM individual and corporate members only
 Planning, Scheduling, Monitoring and Control

Once change approvals and nancial authorisations are in place, the ollowing
actions should be taken:

• Update the change logs to refect the approved status o changes.

• Issue an instruction i appropriate and record its issue.
• Update reports to refect cost and schedule impacts.
• Update any purchase orders to refect cost and schedule impact.
• Update project execution plans (including risk/opportunity registers) and
project brie.
• Communicate within project team and any interacing teams.
• Update the baseline with the agreed change.

25.12.1 Adjusting schedule in line with change

Change broadly comes in two categories and may be dealt with in dierent
ways: change that is required and change that is subject to urther optioneering
or exploration – i.e. that might not happen. Change will be picked up in the
schedule narrative.

25.12.1.1 Optional change

Optional change should be assessed in ‘what i’ or ofine schedules as part o the
change process. There may be more than one ‘what i’ schedule required to
model a number o potential options. This type o change should only be incor-
porated into the schedule once it has been approved.

25.12.1.2 Required change

Once required change has been identied, it should be refected in the schedule
to ensure that it continues to refect the intended sequence and scope o works
regardless o agreement. This ensures that a realistic schedule is maintained and
the critical path remains robust. Only when the change is authorised will the
budgets contained in the schedule (and elsewhere) be adjusted.

25.12.1.3 Reviewing change

Where supplier’s change has been approved, the supplier/contractor should
submit their schedule with the agreed change incorporated. The planner should

268
For use by APM individual and corporate members only
 Change management

assess the schedule to see whether the change accurately refects the agreed
change. Checks will need to be made regarding:

• key milestone dates;

• key interaces;
• critical path.
• sub (or ‘near’) critical paths.

25.13 Communicating the change

Once a change request has gone through the system, and the change log has
been updated accordingly, it is important to ensure that all relevant parties are
inormed. As change is a critical part o any project, it is important that the change
inormation is quickly read and acknowledged by the key parties.
Sending out the latest version o the change log in an email to all the project
team will not get the message across. The issue o a ormal instruction does meet
most contractual requirements, but it is better to also go over the approved
changes at either a regular project team meeting or, better still, a specic change
review meeting.
It is important to ensure that ALL parties are inormed, as change oten has
ar-reaching impacts. As a rule, it is always better to over-inorm rather than risk
missing people out, e.g. stakeholders or sponsors.
As well as the change log, it is important that the process also picks up the
resulting changes to other key documents, such as: drawings; document control
systems; specications; procurement orders; schedules; cost plans; baselines,
etc.

25.14 Monthly change reporting

requirements
It is important to communicate the status o change to all interested parties on a
regular basis. Figures 25.2 and 25.3 show examples rom a construction project
on change reporting.

269
For use by APM individual and corporate members only
 Planning, Scheduling, Monitoring and Control

Figure 25.2 Example o monthly change reporting

Figure 25.3 Monthly change report

270
For use by APM individual and corporate members only
 Change management

Denitions used in Figures 25.2 and 25.3:

NEC: New engineering contract. Now widely used in the construction industry.
EWN/EON: Early warning notices are used to contractually advise the client or
customer that there could be a potential impact on cost or time (as used within
the NEC contract).
SI: Site instruction. Used on construction projects where a small on-site change
needs to be implemented quickly.
PMI: Project manager’s instruction. The ormal notication given by the
project manager usually ollowing a more detailed review o the impact o
the change.
CO: Change order. These are used to authorise a change to the project, including
a change o scope or agreement to accept a design solution which is outside
the agreed cost and schedule parameters.
BT: Budget transers. Budget transers are made to ormalise the movement o
scope (budget and schedule) rom one part o the project to another, or,
indeed, to move scope into or out o the project.

The Projects shall maintain their own change logs as required according to Figure
25.3, and shall make these available or inspection or challenge rom the schedule
change manager at all times.

25.14.1 Managing the schedule change process

The update o the schedule should be perormed (i possible) in advance o the
monthly reporting cycle to ensure that logic and duration changes do not hinder
the reporting cycle.

271
For use by APM individual and corporate members only
For use by APM individual and corporate members only
 26.1 Denition o risk management
Risk management is the management o threats to the project (negative
impacts) and opportunities (positive impacts). It involves the identication and
management o these issues.
As part o the planning o a project, risk should be considered at all stages.
Risk management techniques will be used to help dene cost or budget
allowances, allowances or schedule risk and, indeed, any other types o risk that
a project aces. Thus, risk management is integrated with all other management
processes and is part o the planning, monitoring and control o a project.
It is worth noting that there is a clear relationship between change and risk:
change inevitably introduces more risk or greater opportunity. In addition, aside
rom identied risk and opportunity, the sheer act o changing scope will add
risk into the schedule, and the greater the amount o change, the more risk is
introduced. There is, thereore, a strong relationship between the management
o risk and change.

26.2 Purpose o risk management

Risk management is required in order to anticipate threats and opportunities, and
manage them to ensure the best outcome o the project. This may be in the
ollowing terms:

• sae execution o the works;

• commercial outcome – the best possible value or money being achieved;

273
For use by APM individual and corporate members only
 Planning, Scheduling, Monitoring and Control

• commercial outcome – no surprises;

• reputational outcome;
• delivery to time constraints;
• quality;
• avoiding events that may delay the planned progress o the work;
• incorporating opportunities to save cost or time;
• including alternative methods to better coordinate the work.

26.3 Risk management plan

A risk management plan sets out how the thorough assessment o risk associated
with the project will be implemented. This process will be undertaken by working
in collaboration with all relevant project stakeholders. The risk management plan
aims to implement this procedure in such a way that:

• risks are minimised;

• opportunities are maximised;
• risks are owned and managed at the appropriate level;
• risk mitigation actions are appropriate and eective;
• mitigation actions are monitored and managed eectively;
• current risks to the project are communicated eectively.

26.4 The risk management process

The key stages o the risk management processes identied in this section are
shown in Figure 26.1 and described more ully in the ollowing sections.

26.4.1 Planning
26.4.1.1 Planning or risk
Beore the commencement o a ormal risk process, a risk management plan
should be created, reviewed and accepted by all relevant parties. Regular risk
workshops and review sessions will be planned and held throughout the lie o
the project.

274
For use by APM individual and corporate members only
 Figure 26.1 Risk management lie cycle

For use by APM individual and corporate members only

 Planning, Scheduling, Monitoring and Control

As part o the preparation or initial risk workshops, project deliverables will be
clearly identied. The documents that might be consulted may include:

• contract documents;
• tender documents;
• project schedule and associated schedules;
• project execution plan and associated documents;
• risk checklists (a list o topics and regularly encountered threats and opportun-
ities or consideration or the workshop);
• the assumptions register.

This inormation will be used to prompt discussion and consideration o potential

threats and opportunities.

26.4.1.2 Risk management through the project lie cycle

During the project, the objectives are as ollows:

• identiy new risks and risk mitigation actions;

• quantiy and assess risks;
• establish risk owners;
• ensure management o risk mitigation actions (undertaken successully and to
schedule);
• ongoing review at all levels;
• monitor and relay the management o risk and risk mitigations.

26.4.2 Risk identication

This step concerns the capture o threats and opportunities to the project objectives.
The ollowing techniques may be used:

• risk workshops;
• interviews with relevant people to benet rom their knowledge and experience;
• risk review meetings;
• time issues that are known about or arise rom progress reporting;
• investigations and surveys;
• lessons learned register/inormation;

276
For use by APM individual and corporate members only
 Risk management

• relevant entries in interacing risk registers;

• risks noted during development o methodology;
• assumptions and exclusions;
• sub-contractor risk registers;
• risks identied as part o the change process.

A detailed description o each key risk is recorded within the risk log, together
with the cause, eect, and owners (Figure 26.2).
Where risks have been identied with owners or actions alling outside the
remit o those present, the relevant stakeholders will be notied.

Figure 26.2 Risk identication in a typical risk log

26.4.3 Risk assessment

To align with the project objectives, individual risks and opportunities will be
considered according to project-specic impact and probability ratings. An
example o what this might look like is shown in Figure 26.3.
Part o the assessment step is stating on the register what the existing control
measures are (i any). These are accounted or in the current/pre-mitigation
impact and probability ratings.
Each cell shown in Figures 26.3 and 26.4 may be given a numerical value; this
is known as the severity rating score, and is used in creating a hierarchy o risks
to highlight those needing the most attention. The criteria or making these
assessments will depend on the type o risk: monetary values or commercial
risks, periods o time or schedule risks, and so on. In the case o these two
examples, there may be an assessment based on three-point estimates and
distribution criteria, discussed later in this section. In other cases, there may be a
set o qualitative statements; or example, a saety risk might be categorised by
the potential or harm to individuals (reportable accidents, or example). These
categories will vary between organisations based on their risk appetite.

277
For use by APM individual and corporate members only
 Planning, Scheduling, Monitoring and Control

Figure 26.3 Risk assessment matrix – severity ratings score

Figure 26.4 Opportunity assessment matrix – severity ratings score

It should also be borne in mind that risks may have a time envelope within
which they may occur, and another way o dening priority will be those risks
likely to occur in the near-term uture, whether these be threats or opportunities.
The assessments thus made may be categorised and entered in the risk log
(Figure 26.5).
It is good practice to capture the justication behind the scoring (the basis o
estimate) – it is oten challenged, particularly where the risk mitigation actions
need a cost–benet analysis.

278
For use by APM individual and corporate members only
 Figure 26.5 Typical risk log (continued rom Fig 26.2), showing current impact and response planning

For use by APM individual and corporate members only

 Planning, Scheduling, Monitoring and Control

26.4.4 Risk response

For each risk, the risk owner must establish a level o mitigation to the satisaction
o the project manager.
Factors causing the risk must be understood to help determine the appropriate
mitigation actions. These mitigations are recorded in the risk register.
I eective mitigations cannot be identied to control the risk, then mitigations
need to be sought to reduce the consequences to an acceptable level. Figure
26.6 summarises risk response options.
Ater taking into account the anticipated eectiveness o the mitigation plan,
it is usual to re-score the risk to provide a target or the reduction o risk and
an assessment o residual risk (which is the element o risk that has not
been mitigated). In eect, this is an assessment o the value o undertaking
the mitigating actions. Mitigations that need unding (i.e. add new scope to the
project’s workload) need to enter the schedule through the change process.

Figure 26.6 Risk response options

26.4.5 Risk review

The review process allows a nal check o the key risks by the project manager.
This review and validation comprises the process by which the project manager
accepts accountability or the risk inormation.
The project manager will undertake review o the risk log regularly through
the lie cycle o the project. This review consists o the ollowing:

280
For use by APM individual and corporate members only
 Risk management

• Detailed review o the most critical risks and opportunities (at least, but not
limited to, those risks deemed to be ‘red’ risks in accordance with the severity
rating score).
• Have the delegated response plans been implemented, progressed or
completed?
• Have existing item scores increased or decreased due to changes in likelihood
or impact?
• Are additional mitigation measures required?
• Can existing risks and opportunities be closed?
• Check and agree whether any draw down o management reserve is required.
• Review the need or any ocused workshops on any o the matters raised in
the review.

26.4.6 Risk reporting

Reporting will be based on the data in the risk log, which will be updated and
reviewed each reporting cycle. As well as the inormation illustrated above,
additional elds may be used to capture tracking data. This will provide risk
management inormation to support reporting requirements (see Figures 26.7
and 26.8).

26.5 Risk draw down

Risk draw down is the movement o budget in the risk pot, usually into the
perormance measurement baseline (PMB). The project should set guidelines
or the drawdown o risk monies and the authority required to do so. It should
be stressed that the contractual situation and budget ownership will dictate

Figure 26.7 Reporting o basic risk data

281
For use by APM individual and corporate members only
 Figure 26.8 Tracking risk perormance over time

For use by APM individual and corporate members only

 Risk management

how this is dealt with; the ollowing are suggested ways o drawing down risk
budget.

26.5.1 When risks are mitigated

When mitigation plans are put in place that involve incurring cost, an appropriate
sum may be drawn down rom the management reserve and attributed to new or
existing activities in the PMB. This is eectively an addition o scope to the
activity as well as budget.

26.5.2 When risks are realised

When risks are realised that involve incurring cost, an appropriate sum may be
drawn down rom management reserve and attributed to appropriate activities in
the PMB. This is eectively an addition o scope to the activity as well as budget.

26.5.3 When risks are closed

When risks are closed, their impact upon the risk exposure will clearly be
refected. However, depending on the contractual situation, risk allowances may
be maintained. There are a number o options or dealing with this allowance:

• Where risk exposure is greater than allowance, retain the allowance in the risk
register, re-allocating to new or emerging risks i appropriate.
• Where risk allowance is greater than exposure, then a portion o risk allowance
may be released to ‘prot’.

26.5.4 When opportunities are realised

When opportunities are realised, the budget will stay in the project. There are a
number o options that may be appropriate, and the project team must consider
the ollowing:

• Move budget rom relevant activities to the ‘management reserve’: in some

cases, the realisation o an opportunity may need to be balanced by the introduc-
tion o a new risk. For example, the relaxation o strict working patterns would be
an opportunity to complete work aster and more cheaply, but the risk that the
relaxation in conditions may not continue in uture should be captured.

283
For use by APM individual and corporate members only
 Planning, Scheduling, Monitoring and Control

• Do nothing – this would result in positive variance in cost or schedule. Care

should be taken that this positive value does not mask poor perormance.
• I unds are used to pay or a mitigation to realise the opportunity, sucient
value to cover this expense would be allocated as appropriate, and there may
also be a release o budget rom the baseline to refect the cost–benet o the
opportunity.

26.5.5 Documenting changes in the risk budget

All movements in the risk budget must be documented or control purposes.
Also, records should be kept o the contingency allowances under lessons
learned, or uture projects.

26.6 Quantitative schedule risk

analysis (QSRA)
26.6.1 Denition o QSRA
Once the schedule has been created, reviewed and veried, a quantitative
schedule risk analysis (QSRA) will apply statistical techniques to test the level o
condence in meeting the completion date.
This analysis looks at the whole schedule and not just the critical path. The
conclusion o this analysis may result in a completely dierent set o linked
activities that determines a ‘most likely’ completion date.
A QSRA relies on Monte Carlo analysis. A Monte Carlo analysis is a set o
calculations that rely on repeated random sampling to obtain a range o results –
a probability distribution. The sampling is based on inormation provided by the
user.
There are two elements to QSRA:

• duration uncertainty (a minimum, most likely and maximum spread o activity

durations);
• risk impact (minimum/most likely/maximum).

In some organisations QSRA is reerred to as timescale risk analysis, but this

guide will use the QSRA term.

284
For use by APM individual and corporate members only
 Risk management

26.6.2 Purpose o QSRA

26.6.2.1 Improve the quality o the project schedule
The best mitigation strategy or risk on a project is to have a robust and logically
sound schedule. It is important to ensure that the ull scope and working methods
are accurately modelled in the schedule. This modelling helps to drive under-
standing and acceptance o the project schedule, and hence commitment to
delivery.
Running a deterministic schedule through a QSRA tool can derive benet by
exposing weaknesses in the original schedule which were not apparent in the
static schedule. The unexpected variations (or lack o them) provoke discussions,
resulting in both an improved understanding o the schedule by the project team
and a better nished schedule.
A QSRA will also highlight which activities and paths are perceived by the
QSRA toolset as being key drivers. These can oten dier rom the paths
associated with the critical path analysis, where more risk is associated with
(originally perceived) sub-critical paths.

26.6.2.2 Model duration uncertainty and risk

The two stages o running a QSRA are described in more detail below; a key
advantage o running a QSRA is the consideration o these two acets o the
schedule and risk prole. In the case o the duration uncertainty, this allows the
project team to express their condence level in the schedule, which may in itsel
expose certain issues.
Reviewing the risks will ensure that these are considered as part o the
schedule, and the implications will be more widely understood as a result.

26.6.2.3 Assess the probabilities o completing the project

on time
The undamental purpose o QSRA is to determine the probability o nishing on
or beore a given point in time. It will determine the condence level o completing
the project to the required date. This can then acilitate urther strategic decision
making.

285
For use by APM individual and corporate members only
 Planning, Scheduling, Monitoring and Control

26.6.2.4 Focus attention on areas requiring mitigation

As a result o undertaking a QSRA, it may be appropriate to consider mitigations
that need to be put in place. This will particularly be the case i the exercise has
identied alternative critical path(s) to the one created during the scheduling o
the project.

26.6.2.5 Setting baselines

The QSRA approach may be used to establish an appropriate target to be used
as a project baseline. Dierent organisations may have dierent risk appetites
and establish targets based on a set probability o achievement. These are oten
known as, or example, ‘P80’ levels, where P means probability and the number
reers to the percentage condence level (80% in this case).

26.6.3 Key requirements or a QSRA

• A robust and ully logically linked schedule where only genuine constraints
remain.
• I the project is in progress, the schedule must be updated to refect current
status.
• Identiy duration uncertainty against all activities (three-point estimate duration
or activities).
• Risks are identied, documented and their impacts assessed and allocated to
schedule activity.
• A sotware application with which to run the Monte Carlo analysis, which
produces appropriate reports.
• Terminal foat or other time contingencies should be removed rom the
schedule prior to running the QSRA.

26.6.4 The stages o schedule risk analysis

26.6.4.1 Schedule quality check
The rst step in running a QSRA is to conrm that the schedule is o the required
quality. Some o the technical checks can be made by QSRA sotware (or
example, open ends, type o logic used). Other matters may be more subjective,
such as the general robustness o the schedule and the surety that all project

286
For use by APM individual and corporate members only
 Risk management

scope is included. Ideally, the schedule should be checked by an independent

party prior to running a QSRA.
Level o eort-type activities should be excluded rom the analysis, as they do
not represent true work.

26.6.4.2 Duration uncertainty

A quick risk analysis can be perormed by setting a narrow uncertainty range
across all activities. The purpose o this is to help highlight key activity drivers in
the schedule and to ensure that the project logic is robust.
For a ull assessment o duration uncertainty, the project team will need to
be consulted to assess ‘minimum’, maximum’ and ‘most likely’ durations or
each activity to eed into the risk analysis. This could be done on an activity-by-
activity basis, but this would be extremely onerous (unless the data is captured
as part o the duration calculation when developing the schedule), so it is usual
to categorise dierent types o work and apply condence actors to each type
o work.
Distribution types that can be applied are discussed below.

26.6.4.3 Monte carlo analysis – rst run

Ater applying the duration uncertainties, it is useul to run a ‘rst pass’, as this
will assist in understanding the nal results – i.e. how much o the nal result is
attributable to condence in the current schedule, and how much due to the
assessment o potential risk events. An understanding o this will assist in
assessing and prioritising mitigation actions. For example, a disproportionally bad
result at this stage may point to the requirement or more planning to urther
develop or mitigate the current schedule.

26.6.4.4 Adding the risks into the analysis

Once the risks have been identied and catalogued in the risk register, those that
have a potential to cause a delay are added into the schedule. Durations, probab-
ilities and distribution types are added to each risk.
The probability is the likelihood o the risk event occurring, and is expressed
as a percentage.
The duration is the expression o the likely eect in terms o time (and may be
a one point value, or a minimum/most likely/maximum range o eects).

287
For use by APM individual and corporate members only
 Planning, Scheduling, Monitoring and Control

26.6.4.5 Monte carlo analysis – second run

This stage assesses the eect o both duration uncertainty and the risk events.
An understanding o this will assist in assessing and prioritising mitigation actions.
For example, an unwelcome or unexpected result at this stage may point to the
requirement or more mitigating actions to be developed, which may include
re-working the network.
It will be necessary to iterate through the two processes, assessing mitigation
options until you have a solution that best meets the needs o the project/
programme.

26.6.5 Distribution types

The distribution type is an expression o the distribution pattern and may include
the ollowing.

26.6.5.1 Normal or bell curve distribution

Symmetrical: values in the middle are most likely to occur (Figure 26.9).
Describes many distributions, such as those around well-understood and
controlled processes or tasks:

• Values in the middle near the mean are more likely to occur than in the
triangular distribution.
• Use when there is moderate condence in three-point estimates.

Figure 26.9 Normal distribution curve

288
For use by APM individual and corporate members only
 Risk management

26.6.5.2 Log normal distribution

Values are positively skewed (Figure 26.10).

• Values are positively skewed, not symmetrical like a normal distribution.

• Used to represent values that do not go below zero but have great positive
potential.

Figure 26.10 Log normal distribution curve

26.6.5.3 Uniorm distribution

All values have an equal chance o occurring (Figure 26.11).

• Useul or estimates that do not appear to show any central tendency.
• Equally likely chance o occurring anywhere within a particular range.
• No ‘most likely’ value.

Figure 26.11 Uniorm distribution

289
For use by APM individual and corporate members only
 Planning, Scheduling, Monitoring and Control

26.6.5.4 Triangular distribution

User sets minimum, most likely and maximum (Figure 26.12).

• Used extensively in risk models.

• Allows skewed estimates to be modelled.
• Use when:
• there is low to moderate condence in three-point estimates
• risk is high or unknown
• global three-point estimates are applied.

Figure 26.12 Triangular distribution – possible options

26.6.5.5 PERT distribution

Like triangular, but minimum/maximum are more likely to occur (Figure 26.13).

290
For use by APM individual and corporate members only
 Risk management

Figure 26.13 PERT distribution

• Values near the mean are more likely to occur than in the triangular or normal
distributions.
• Extremes are not as emphasised.
• Use when there is high condence in three-point estimates.

26.6.5.6 Discrete distribution

Specic values and likelihoods are specied, e.g. ‘There is a 10% chance o
occurrence and there will be an eect o 10 days.’
When undertaking a risk analysis, it is important to understand these
distribution types and the eect they will have on results.

26.6.6 Application o risks to schedule activities

It is important to consider what eect applying risks to activities will have.
A Monte Carlo analysis works by turning the risks on and o at random based
on their probability o occurrence. Each time the risk is ‘on’, an impact will be
applied the activity(ies) that it is linked to. The eect o the risk will vary in line
with the probability distributions described above.
A risk linked to many activities will, when it is ‘on’, aect all the activities that
it is linked to. I the risk was, or example, lack o resources, is it really applicable
to all the activities it is attributed to? The calculation will assume that this is
the case, rather than the lack o resources aecting just one, or some, o the
activities.

291
For use by APM individual and corporate members only
 Planning, Scheduling, Monitoring and Control

26.6.7 QSRA output

26.6.7.1 First analysis: duration uncertainty
As previously discussed, the rst analysis undertaken applies the duration uncer-
tainty calculations. The graphics and statistics in Figure 26.14 detail the outcome
o this on a specic milestone which denes the end date o this section o work.
The results o this analysis can be shown in a probability chart. Charts can be
viewed or the overall project or at a number o key milestones or at other points
throughout the project.
Dierent ‘risk appetites’ are also (or more) dependent on the type o work;
e.g. possessions or shut-downs would commonly want P90, standard construction
work P80 or schedule risk and uncertainty. However, cost risk might well be P50,
which would never be acceptable or the schedule.
Dierent organisations will have dierent risk appetites and choose dierent
percentage points (P) to measure against, but the illustration in Figure 26.14 uses
the P50 and P80 boundaries. P50 means a 50% chance o success; P80 means
there is an 80% chance o success. In the illustration, the required completion
date is 10/02/11; the results show that:

• There is a probability o achieving the current schedule date o 28% (yellow

line).
• The P50 date is shown as 14/02/11 (orange line).
• In addition the P80 date is also shown as 14/02/11 (green line).

The activities that have the most infuence on this outcome can be displayed in a
tornado chart, as illustrated in Figure 26.15.
It is worth analysing the tornado chart prior to proceeding with the exercise to
ensure that the results are meaningul and credible activities are identied as
having the greatest infuence on the result. The example in Figure 26.15 shows
the impact in days, but sometimes this is shown in percentage terms.

292
For use by APM individual and corporate members only
 Risk management

Figure 26.14 Duration uncertainty probability chart

293
For use by APM individual and corporate members only
 Planning, Scheduling, Monitoring and Control

Figure 26.15 Duration uncertainty tornado chart

26.6.7.2 Second analysis: duration uncertainty and risk

Ater adding in the risks the analysis is re-run (based on these risks and the
duration uncertainty as beore), and new output is produced (Figure 26.16).
As with the activities that have the most infuence on this outcome, as seen in
Figure 26.16, the risks can also be displayed in a tornado chart, as illustrated in
Figure 26.17.
Again, it is worth assessing the credibility o these results prior to producing
and publishing a QSRA report.

294
For use by APM individual and corporate members only
 Risk management

Figure 26.16 QSRA probability distribution chart

295
For use by APM individual and corporate members only
 Planning, Scheduling, Monitoring and Control

Figure 26.17 Full QSRA tornado chart

26.6.8 Reporting
A suggested report ormat would include:

• commentary on the scope o the QSRA;

• notes on the method adopted so that the process and inputs are made
clear;
• list o participants and their involvement;
• the results in graphical orm and with written interpretation;
• recommended actions that should mitigate any concerns raised in order to
deliver the most eective project possible;
• appendices o duration uncertainties and the risk register, considered with
details o the risk modelling (i.e. which risks allocated to which activity(ies);
distribution type; minimum, maximum and most likely values).

296
For use by APM individual and corporate members only
 Risk management

26.7 Quantitative cost risk analysis (QCRA)

26.7.1 Denition o QCRA
Quantitative cost risk analysis (QCRA) is oten reerred to as Monte Carlo simu-
lation. (Monte Carlo is the calculation technique used, not the product.) It is a
technique used to understand and quantiy the impact o risk and uncertainty in
cost orecasting models.

26.7.2 Purpose o QCRA

QCRA enables the project to calculate the size o its contingency, thereby
increasing the accuracy o the cost aspect o the project. It can be used on an
ongoing basis to review orecast risk spend against the original budget.
Organisations that consider investing in a new inrastructure or change, in its
broadest meaning, need to evaluate the cost risk involved; once the quantitative
assessment has been completed, the undamental decision o who will take the
risk must be made (The organisation itsel? The suppliers involved?). This
decision will result in dierent contractual arrangements.
Organisations that consider bidding or a job need to carry out a QCRA which
will lead to the ‘bid/no-bid’ decision rst. Subsequently, should the bid be
successul, the contractors need to manage the cost risk in a manner that is
related to the magnitude o the risk identied.
It is also useul to quantiy risk to enhance ‘spend to save’ decision making and
to show the risk retirement orecast to enable the programme to potentially
re-distribute the allocated budget to other projects.

26.7.3 The QCRA process

26.7.3.1 Risk analysis
As previously discussed, risks are identied and assessed. For the QCRA, each
risk is assigned a likelihood and a three-point estimate (minimum cost, most likely
cost and maximum cost) should it occur.
This latter may be based on a triangular distribution, but there are other
distribution methods which could be considered, such as single point (most likely
cost) or a uniorm distribution (minimum and maximum). These are discussed in
the section above on QSRA.

297
For use by APM individual and corporate members only
 Planning, Scheduling, Monitoring and Control

For the Monte Carlo simulation, a random value is selected or each risk,
based on the range o these cost estimates. The result o this is recorded, and
typically the model is run 5,000 times, each time using dierent randomly selected
values. I the risk has a 50% likelihood, then the model would run hal the iterations
as a zero cost out-turn, as it assumes that the risk is not occurring. The remaining
hal o the model would pick random values dependent upon the three-point
estimates.
Just as in the case o the QSRA, the results are plotted and condence levels
or various outcomes are calculated. These are oten reerred to as P values, e.g.
P50 or P80.
This means that, or example, i the P50 is calculated at £5 million, there is only
a 50% chance that the project will cost a total o £5 million or less. The more risk
averse the organisation is, the higher the condence value they may use.
Thereore, they may use a P80, which means that there is an 80% chance that the
project risk will cost a total o (say) £7 million or less.

26.7.3.2 Risk reporting

The above inormation enables an organisation to dene risk budgets or projects
based on a range o possible out-turns. Regular review o the risks during the
project lie cycle means the model can be re-run at regular intervals. This provides
management inormation that the risk prole is remaining within an acceptable
level. The inormation is typically collated on a pre-mitigation (current) state
and a post-mitigation state. The project team can then manage the risks using
mitigations.
Some typical outputs or quantitative analysis include:

• cumulated normal distributions (S-curves) or cost impacts;

• sensitivity (tornado) charts showing how much each risk infuences the
outcome;
• QRA percentiles (percentage rates) value or cost.

26.7.3.2.1 Cumulative normal distributions

The chart o the cumulated normal distribution (S-curve) provides an easy way to
assess the level o condence about the model outcomes. The let-hand axis o
the chart (cumulative probability) is a value between 0 and 1, but can be thought

298
For use by APM individual and corporate members only
 Risk management

o as a percentage o the number o times the model ran – 0 is without running

the model, 1 is when 5,000 iterations o the model have been run.
Tracing a line to intersect the curve and then reerring to the bottom axis o the
chart (cost or time impact values) will indicate the value which, with the given
level o probability, the model ran at or below.
For example, the 0.5 level o cumulative probability, traced to the curve and
translated to the impact axis, will show the value that was not exceeded during
hal the times the model was run (5,000 times in Figure 26.18).

Figure 26.18 QCRA chart

26.7.3.2.2 Sensitivity analysis

Sensitivity analyses show how much a risk aects the result, with the overall
sensitivity o a orecast being the combination o two actors:

• the model sensitivity o the orecast to the risk;

• the uncertainty o the risk.

The ormat o the sensitivity data presented here is termed the ‘contribution to
variance’, and makes it easier to examine what percentage o the variance in the
target orecast is due to a particular risk.

299
For use by APM individual and corporate members only
 Planning, Scheduling, Monitoring and Control

Figure 26.19 QCRA chart

26.7.3.2.3 Cost impact sensitivity (tornado charts)

The sensitivity chart shown in Figure 26.19 illustrates the risks having the greatest
infuence on the outcome o the analysis – the risks that change the outcome o
the analysis most.
Managing these risks will have the most infuence on reducing the orecast
risk costs.
(Risk – O) relate to risks that infuence the model due to their probability
values.
(Risk – I) relate to risks that infuence the model due to their cost values.

300
For use by APM individual and corporate members only
 Risk management

Example:
Risks with an ‘O’ key on the graph indicate that those particular risks appear on
the sensitivity chart mainly due to their high probability, e.g. probability o 75%.
Risks with an ‘I’ key on the graph indicate that those particular risks appear on
the sensitivity chart mainly due to their high value, e.g. £10 million, should they
occur, even i they may have a low probability o occurrence, e.g. 5% likelihood.

26.7.3.2.4 QRA percentiles summary table or cost

Table 26.1 illustrates an example o Pn condence levels.

Table 26.1 QCRA condence levels

Percentile Overall total risk cost (£)

P0 100,637.71

P10 411,602.97

P20 502,275.44

P30 584,376.77

P40 673,217.44

P50 777,270.30

P60 915,880.23

P70 1,091,687.26

P80 1,232,564.58

P90 1,413,591.55

P100 2,702,304.39

26.7.3.3 Conclusions
Like any orecasting model, the analysis is only as good as the estimates made. It
is important to remember that it is a simulation, and basing the estimates on
current assumptions will provide greater condence in the results.

301
For use by APM individual and corporate members only
For use by APM individual and corporate members only
 27.1 Denition o orensic analysis
Forensic schedule analysis reers to the study and investigation o events using
critical path methods or other recognised schedule calculation methods. In
particular, it is the study o how actual events caused delay as measured against a
dened time model.

27.2 Purpose o orensic analysis

The most usual reason or conducting orensic analysis is or the purpose o
building, justiying or rebutting a contractual claim or additional monies. Indeed,
given that it is likely to be an expensive undertaking, it is hard to imagine it being
used or other purposes. Given that such analyses may be used in legal proceed-
ings demonstrating delay and disruption, it is essential that experienced guidance
is sought when undertaking such exercises.

27.3 Methods o orensic analysis

By implication, orensic analysis is carried out ater the event. However, some
contracts provide or the analysis o schedules to be carried out on a prospective
basis. Events are considered at the time they occur and consequent delays are
orecast, or example in the NEC suite o contracts.
A comprehensive understanding o the detailed steps to be undertaken to
ensure these methods are implemented appropriately is required beore using

303
For use by APM individual and corporate members only
 Planning, Scheduling, Monitoring and Control

these techniques. An overview o some o the more common methods o delay

analyses is provided in Table 27.1.

• as-planned versus as-built method (AP v AB);

• impacted as-planned method (IAP);
• collapsed as-built method (CAB) or as-built but or (ABBF);
• time impact analysis method (TIA).

In addition, there ollows a discussion on the windows analysis approach to

investigating the eect o multiple events.

27.3.1 As-planned versus as-built method (AP v AB)

Table 27.1 As-planned vs. as-built method

Method Requirements Advantages Disadvantages Where can it be
description used?

The as-planned v • Good • Relatively • Can only be carried • When as-built

as-built method as-planned simple to out retrospectively. data is
compares the schedule (ideally understand and • Likely to be overly available.
as-planned agreed or present. simplistic and not • Suitable or
schedule or accepted at or • Relatively cheap demonstrate cause simple
baseline at the near the outset to carry out. and eect situations,
outset o a project o the project). • Can be appropriately. projects and
with the as-built • Good as-built appropriate or • Not suited to cases or where
schedule at the data so as to be simple complex projects matters only
end o the project able to establish situations. with multiple critical need to be
(or the latest an as-built • Although the paths. shown at a
schedule updated comparison with schedule would • Not suited to higher level.
with progress). the as-planned normally be a projects that have • Better suited to
This allows the schedule. critical path deviated rom the projects o a
dierences • The works network, this is original as-planned shorter
between the two carried out need not necessarily logic. duration.
schedules to be to closely refect essential. • Does not adequately
observed. the logic Thereore, deal with concur-
contained within planning rency, consequential
the as-planned sotware is not delay, mitigation or
schedule. an absolute acceleration.
requirement in
some cases.

(Continued)

304
For use by APM individual and corporate members only
 Forensic analysis and delay and disruption analysis

Table 27.1 Continued

Method Requirements Advantages Disadvantages Where can it be
description used?

The as-planned v • Delay events • Does not necessarily • Where there is

as-built need to be recognise the order a single clearly
comparison can clearly in which delays dened chain or
be shown either identied. impacted a project. sequence o
activity by activity • The criticality o • Does not deal with activities that
or schedule by delay events the critical path were critical to
schedule. The does not need to changing as a the timely
overall delay is be demonstrated project progresses. completion o a
measured by the i the liability or • Generally assumes project
dierence all the events is all delay is due to throughout.
between the clear and rests one party.
completion dates with one party. • As the analysis
in the two • I there are progresses through
schedules. This issues with the as-planned
delay is attributed liability then the schedule, its
to the delay criticality o the accuracy is likely to
events that have aected diminish.
occurred. activities must • It is unreliable by
be clear. itsel in dispute
resolution.

27.3.2 Impacted as-planned method (IAP)

Table 27.2 Impacted as-planned method
Method Requirements Advantages Disadvantages Where can it
description be used?

The impacted • Good • Can be used • May only show limited • Can be used
as-planned as-planned where the cause and eect. prospectively
method schedule as-planned • Does not take account or
works by (ideally agreed schedule has o progress, resources retrospectively
inserting and or accepted at not been and changes in but . . .
linking delay or near the updated or sequence. • More suited
events into outset o the where there is • It is a theoretical or identiying
the project). limited as-built method and thereore and
as-planned • The works data available. open to criticism. quantiying
schedule. carried out • Can be used • Susceptible to potential
Any change need to closely prospectively manipulation delays rather
in the refect the logic or (unintended or than actual
completion contained retrospectively. otherwise) i only one delays.
date as a within the party’s delays are
consequence as-planned considered.
o the schedule.
(Continued)
305
For use by APM individual and corporate members only
 Planning, Scheduling, Monitoring and Control

Table 27.2 Continued

Method Requirements Advantages Disadvantages Where can it
description be used?

insertion o • The as-planned • Relatively • May ignore • Might be

the delay is schedule needs simple to concurrency. appropriate
attributed to to be understand and • Sensitive to the order or illustrating
the delay networked. present. in which delays are delays at high
event. An • All delaying • Relatively impacted upon the level or or
analysis can events should cheap to carry schedule. negotiating
be carried be identied out. • Less reliable in dispute purposes.
out on a and quantied. • Where as-built resolution than other
step-by-step • I analysis is data is more comprehensive
basis, carried out available, it can methods.
inserting retrospectively, be used to • Relies heavily on the
delay events the results veriy the as-planned schedule
as they arise. should be results. being robust.
veried by • Tribunals generally
as-built data i avour actual methods
available. o delay analysis.

27.3.3 Collapsed as-built method or as-built but or (CAB)

Table 27.3 Collapsed as-built method or as-built but or
Method Requirements Advantages Disadvantages Where can
description it be used?

The collapsed • Good quality, • Does not • Limited prospective • Where there
as-built reliable and require an use. is no
method begins consistent as-planned • The networking o the as-planned
with the as-built data schedule. as-built schedule schedule or it
production o produced in • Based on requires a deep is o poor
a networked sucient actual as-built understanding o the quality.
as-built detail. data. schedule and its logic • Most
schedule. • Requires a • Can and normally requires appropriate
Then activities networked or demonstrate access to the project or
or parts o logic-linked cause and team. retrospective
activities as-built eect. • Expertise required to delay
representing schedule. • Can account or collapse out delays analysis.
delay events concurrency. accurately, otherwise
are removed. the collapsed schedule
may not represent the
true situation but or
the delays.
(Continued)

306
For use by APM individual and corporate members only
 Forensic analysis and delay and disruption analysis

Table 27.3 Continued

Method Requirements Advantages Disadvantages Where can
description it be used?

The change in • Detailed • Relatively easy • Delays to be collapsed • For

the completion understanding to understand in out still require negotiating
date as a o the logic principle and knowledge about how purposes or
consequence and delay explain. long work should have in tribunals.
o the removal events that • More reliable in taken, and can be
o the delay is oten requires dispute subjective.
the overall either resolution than • In practice, can require
delay that is rst-hand some simpler several iterations.
attributed to knowledge or methods o • Can be perceived as a
the delay access to delay analysis. reconstruction o the
event. Delay people with • Can be carried acts without due
events can be rst-hand out prospect- consideration o the
removed on a knowledge. ively or updated as-planned
step-by-step • All delaying retrospectively, schedules.
basis, usually events should but limited • Does not account or
starting with be identied prospective use. acceleration measures,
the latest delay and as these will be implicit
event rst. quantied. within the as-built
schedule.

27.3.4 Time impact analysis method (TIA)

Table 27.4 Time impact analysis method
Method Requirements Advantages Disadvantages Where can it
description be used?

The time impact • Good as-planned • Can be carried • More suited to • Prospectively
analysis method schedule (ideally out quantiying or
provides or the agreed or accepted prospectively or potential rather retrospectively.
updating o a at or near the outset retrospectively. than actual delays. • Benecial to
networked o the project). • Deals with delays • Requires extensive carry out as a
as-planned • The as-planned at the time they records to be kept. project
schedule with schedule and its occur or in • Can be time progresses.
progress to just updates are windows intensive and slow, • Where the
beore the networked. providing clarity. and thereore contract
occurrence o a expensive to requires.
delay event. implement.

(Continued)

307
For use by APM individual and corporate members only
 Planning, Scheduling, Monitoring and Control

Table 27.4 Continued

Method Requirements Advantages Disadvantages Where can it
description be used?

The delay event • Reliable and • Can account or • Can be complicated • For
is then inserted consistent progress progress, and dicult to negotiating
and linked into data in sucient resources, communicate, with purposes or in
the schedule. detail or each time changes in many charts. tribunals.
Any change in period being sequence and • Reliability reduced
the completion considered, which changes in the i schedule and
date as a should also be at critical path. record quality is
consequence o appropriate • Can identiy and poor.
the insertion o intervals. quantiy • Can produce
the delay event • All delaying events acceleration or theoretical results i
is attributed to should be identied mitigation not veried by
that delay and quantied. measures. as-built data, but i
event. • The works carried • Can disentangle carried out
Where out need to closely delays otherwise regularly takes
progress is not refect the logic considered to be account o as-built
recorded at the contained within concurrent. data.
specic date the latest • Can demonstrate • Susceptible to
just beore the as-planned cause and eect. manipulation
impact o a schedule being • More reliable in (unintended or
delay event, the considered. dispute otherwise) i only
latest schedule resolution than one party’s delays
updated or simpler methods are considered.
progress prior o delay analysis. • Accuracy can be
to occurrence • Recommended reduced i the
o the delay method o delay period between
event may still analysis by the progress update
be appropriate Society o and delay
to use. Each Construction increases.
progress Law’s Protocol. • Sensitive to the
update may • Does not require order in which
allow the a complete delays are
schedule to be as-built schedule, impacted upon the
analysed at but as-built data schedule.
discrete assists in
intervals o time veriying results.
or in ‘windows’.

308
For use by APM individual and corporate members only
 Forensic analysis and delay and disruption analysis

27.3.5 Windows analysis

At its highest level, the windows analysis method compares the as-planned
schedule with the as-built schedule during a particular period or time ‘window’.
The as-planned schedule at the start o the window is the schedule updated with
progress at this point. Likewise, the as-built schedule at the end o the window is
the schedule updated with progress at this point. The dierence between the
completion dates at the start and the end o the window is the overall delay that
is attributed to the critical delays that occurred within the window being
considered.
This method o delay analysis can be used to review delays by comparison in
a similar way to the as-planned versus as-built method, but in smaller time
windows; or by extracting out delays in a similar way to the collapsed as-built
method; or or veriying the impacted delays as reasonable rom the time impact
analysis method by comparison with the as-built data.

27.3.6 Other considerations

27.3.6.1 Conditions o contract
The choice o method o delay analysis involves considering various actors,
including the relevant conditions o contract dictating how delay events should
be assessed. It is also quite common that the quality and quantity o schedules
and records will dictate the choice o method o delay analysis. Additionally,
other considerations that need to be accounted or are the values associated with
any delay event or events and the time available to carry out any analysis.

27.3.6.2 Delay analysis in the courts

Theoretical calculations o delay have been ound not to carry avour with the
courts, and methods o delay analysis that rely on as-built data have proved more
reliable in dispute resolution. However, methods o delay analysis should be
considered against a background o their intended use. For example, the simpler
methods o delay analysis might be appropriate or illustrating delays at high level
or or negotiating purposes, whereas the more complex methods might be more
appropriate or use in ormal tribunals where the evidence is subject to more
scrutiny.

309
For use by APM individual and corporate members only
 Planning, Scheduling, Monitoring and Control

27.3.6.3 Considering foat in delay analysis

Float is the period o time by which an activity can slip without aecting other
activities or the project completion date. In particular, ree foat is the period o
time by which an activity can slip without aecting any other tasks or the
completion o the project, whereas total foat is the period o time by which an
activity can slip without aecting the completion o the project.
Terminal foat is normally the period between the planned completion date
and the date or completion as stated in the contract. Who owns the foat within
the schedule can depend upon such actors as the type o foat being considered
and the provisions or foat within the contract. In addition, in order to demonstrate
a delay, it can be seen that the foat attached to an activity will have to be used
beore there is an eect on a ollowing activity. This may mean that, when there
is a delay to an activity, any foat in the schedule is available to whichever party
uses it rst.

27.3.6.4 Concurrency
Concurrency occurs when there is a delay caused by two or more events that are
o approximately equal potency. Although concurrency is oten claimed to exist,
it is actually quite rare, and delay analysis can disentangle the causative delays
and show that one cause o delay was acting beore the other or that one cause
o delay was ar more potent than the other. Where there is true concurrency,
with the customer responsible or one o the delays and the contractor respons-
ible or the other, there has been judicial guidance rom the English courts that
the contractor receives an extension o time but does not necessarily receive
associated prolongation costs unless they can be separated out.

310
For use by APM individual and corporate members only
 Part Five

Record keeping
and learning

‘A learning experience is one o those things that say, “You know that thing you
just did? Don’t do that.”’
Douglas Adams

For use by APM individual and corporate members only

For use by APM individual and corporate members only
 28.1 Denition o record keeping
Records are the physical and digital data that are required to accurately document
the lie o the project. Record keeping is a ormal and disciplined process or
capturing this inormation.

28.2 Purpose o record keeping

The purpose o record keeping is to provide, and preserve, a comprehensive
history o what happened, when and where. In the context o planning, it is the
basis o updating the schedule and o orensic planning, and provides inorma-
tion that will be useul in planning uture projects (productivity data).

28.3 How to record

It is important to dene at the outset what records are necessary and required to
be kept. Since it is not possible to know in advance what records will be required,
it is important to set up appropriate processes and tools to enable the capture o
all relevant inormation.
Record keeping should be undertaken on a regular basis appropriate to the
data being collected. This could be required daily (e.g. weather records), weekly
(e.g. timesheets) or monthly (e.g. progress reports, saety statistics).
Eective record keeping is that which is clearly stated and understood, and
is accessible in the uture. Records should be kept in an appropriate electronic

313
For use by APM individual and corporate members only
 Planning, Scheduling, Monitoring and Control

ormat. Records should be checked where appropriate and authorised where

required (e.g. timesheets). Eective record keeping ensures that this is carried
out on a regular basis, and ensures their authenticity.

28.4 What to record

• Actual start and actual nish dates o every activity in the schedule. This will
eventually build the as-built schedule. It is appropriate to collect this inorma-
tion either daily or weekly, as any longer duration will probably lead to inaccur-
acy. Thus, this is not necessarily related to the progress reporting requency,
which may be urther apart.
• Percent complete o each activity at the point o measurement.
• Remaining duration o each activity at ‘time now’. This should be manually
entered rather than allowing the scheduling sotware to automatically
re-calculate.
• Time issues: it is useul to have the as-built schedule annotated with relevant
details relating to progress and issues encountered. It is particularly important
to build up a picture o time escalation reasons, to inorm uture contingency
allowances.
• Cost issues: it is useul to maintain a log o relevant cost issues encountered.
This will inorm uture contingency allowances.
• Any changes in the change log should be refected in the schedule and
clearly identied.
• I not captured in the project schedule, then the status o inormation (design,
technical and other questions) needs to be retained in the records.
• Timesheets or labour returns that record who worked on what, when.
• Material records: a record o the source and nal location o all materials used
in the project.
• Plant records that conrm plant utilisation and outputs.
• Lessons learned: there is a tendency only to record lessons ater a project has
closed, but processes should be in place to allow collection o learning on a
continual basis.
• Relevant environmental actors that may aect costs or time (e.g. weather in
construction).
• Health and saety records.
• Photographic records.

314
For use by APM individual and corporate members only
 Record keeping

• Delivery records.
• Quality control records.

28.5 Methods o keeping records

• Databases.
• Site diaries.
• Minuted sub-contractor meetings.
• As-built schedules.

315
For use by APM individual and corporate members only
For use by APM individual and corporate members only
 29.1 Denition o document management
Document management is the collection, storage, dissemination and archiving o
documentation in a structured manner. It is a undamental aspect o project
delivery, particularly in supporting assurance processes and the handover o a
project at completion.
Document management also encompasses the process o ‘document control’,
which involves maintaining records o document versions and an audit trail o
documents exchanged with suppliers or other stakeholders. A document control
process should control and be able to trace the fow o all inormation on the project.
The term ‘document’ applies to any ormatted inormation that passes the test
‘Is it in the interest o the schedule or project that this inormation be sae-
guarded?’.
An awareness o current legislation and corporate requirements is important,
as some project documentation, e.g. contracts, may be required to be stored or
a signicant amount o time ater the project has nished. Equally, some may be
required to be stored in a particular manner – or example in a hard copy only, or
in a sot copy only.

29.2 Purpose o document management

Document management ensures that:

• all relevant parties have all the inormation they require to complete their
responsibilities;

317
For use by APM individual and corporate members only
 Planning, Scheduling, Monitoring and Control

• all the inormation used in the project is up to date (i.e. latest revised inorma-
tion is in use);
• out-o-date inormation is no longer accessible or implementation purposes,
but . . .
• all data is available or record purposes.

29.3 Document control systems

The chosen document control system must be accessible, secure and structured
in a logical way that makes project inormation easily retrievable. This may also
include metadata to be attributed to specic documents, i.e. document type,
contract reerence, supplier name, etc. (See also BIM in Chapter 19.)
Thought should be given to levels o sensitivity around particular documents,
and user access rights aligned accordingly.

29.4 Version control

Version control is a undamental part o document control, as it assures that all
parties are working to the correct inormation at the correct time.
Project teams should:

• ensure that all document changes are recorded and documents marked appro-
priately so it is clear that a revision has taken place;
• ensure all project team members use the correct version o each document;
• maintain a tracker, e.g. an appropriate database tool, that shows the status and
revision numbers o each drawing and assurance document, i required by the
project team.

29.5 Handover o documentation

At an early stage, the project team should obtain detailed agreement, usually
rom the sponsor or asset maintainer, as to what documents need to be provided,
in what ormat and when.

318
For use by APM individual and corporate members only
 Project handover and closeout are separate processes but are oten very closely
related in time. Closeout cannot occur until the handover process is complete.
Both processes are vital to the success o the project and oten use nite
resources. The handover process is very likely a part o the critical path o the
project, whilst the closeout process is essential to the nalisation o commercial
accounts, resolution o deects/snagging and transer o the risk process. It will
also include the nal part o the lessons learned process, which is discussed in
Chapter 31. Figure 30.1 outlines the context o handover and closeout.

30.1 Handover
30.1.1 Denition o handover
The handover o a project occurs when the nal project deliverables are handed
over rom the organisation delivering the project to the user or operator o the
asset.
There are many parts to this process, including scope, training and document-
ation, all o which need to be careully planned and resourced.

30.1.2 Purpose o the handover process

A project does not simply end when the works have progressed to 100%. The
project has to be successully handed over to the customer or client. To allow
this, appropriate time must be allocated in the schedule, and appropriate capacity
must exist to eect handover and certication: an example o that capacity being

319
For use by APM individual and corporate members only
 Planning, Scheduling, Monitoring and Control

Figure 30.1 Context o handover and closeout

that there are sucient people available, with the right skills to deliver the
handover process.
The handover process ensures that:

• the project scope has been completed;

• all documentation has been completed;
• all acceptance criteria have been met, and signed o by all parties
concerned;
• end-users have been trained or provided with training manuals as appropriate;
• the project (or product) has been brought into use – or example, a building
can be occupied, a piece o sotware deployed.

30.1.3 Planning handover

The handover stage is a critical stage in the project lie cycle, as an eective
transition to the client’s business environment will ensure that the client starts to
realise the benets o the project.
During the denition stage o the project lie cycle, the project manager will
need to allocate time and resource in the project schedule to ensure that the
project team has sucient time to eectively hand over the project deliverables
to the client.

320
For use by APM individual and corporate members only
 Handover and closeout

The nature o the project deliverables will determine how much time and
resource is allocated to handing them over. The deliverable examples below will
require dierent resources:

• delivery and installation o a new piece o equipment to the client;

• project deliverable/report;
• handing over a process.

The plan or the handover process should also include:

• acceptance o all relevant documentation (containing all specied inormation

useul to the end-user, including guarantees, warranties, instruction or operation
manuals);
• acceptance certicate(s) signed by the sponsor or delegated authority to
conrm acceptance;
• transer o responsibility or the project assets to the sponsor or users;
• ormal transer o ownership.

30.1.4 Issues in the management o handover

The handover process may vary considerably or dierent types o project, but,
to avoid issues, the ollowing principles should be adopted:

• all the project deliverables have been clearly dened and agreed in terms o
documentation required to accompany the physical (or virtual) product o the
project, training requirements and the like;
• the handover process has been clearly dened and agreed;
• the process or dealing with non-conormances or outstanding issues has
been agreed;
• the handover process conorms to organisation guidelines;
• all relevant customer checklists have been used;
• all the signicant stakeholders are appropriately represented at the handover
event.

Poor handover can result in:

• payment delays;
• increased client retentions;

321
For use by APM individual and corporate members only
 Planning, Scheduling, Monitoring and Control

• loss o or reduced prot;

• increased overhead costs (extended insurance, nancing etc.);
• extended resource needs;
• extended warranty requirements;
• delays in equipment availability;
• delays in service to the nal client;
• inecient resource utilisation as work-around solutions are ound;
• worsened client/customer relationship;
• potential penalty costs;
• reduced chance o uture work.

30.2 Project closeout

30.2.1 Denition o project closeout
Project closeout is the nancial closure o the project, including nal settlement
o project accounts and agreement o retentions and warranty periods.

30.2.2 Purpose o project closeout

Project closeout is the part o the project that must resolve the ollowing:

• commercial settlement with the supply chain and all other parties;
• rectication o all deects noted at or since the completion o the handover
process;
• payment o all retained monies resulting rom the above.

It is also best practice to ensure that a project review takes place beore the
project team is disbanded, to ensure that appropriate lessons are learned rom
the things that went well or otherwise in the project. This is covered in the next
chapter o this guide.

30.2.3 The project closeout process

The project closeout process should include:

• demobilisation o the project team, acilities and equipment;

• transer, archive or disposal o relevant sensitive project material or assets;

322
For use by APM individual and corporate members only
 Handover and closeout

• handover to a support organisation (i required);

• closedown o the project on the accounting and management systems.

These processes should be dened in the organisation procedures. Planning the

closeout involves tailoring these procedures or this specic project. Provisional
planning or closeout should be done early in the project lie cycle. The closeout
process should be controlled by maintaining appropriate trackers, or example o
the various steps required to achieve commercial closeout with each supplier.

323
For use by APM individual and corporate members only
For use by APM individual and corporate members only
 31.1 Denition o lessons learned
The lessons learned process captures two types o inormation rom projects:
objective data (acts about perormance and outputs achieved) and subjective
data (such as good and poor practices to be repeated or avoided in the uture).

31.2 Purpose o lessons learned

Capturing lessons learned is important because it will assist in improving
estimating eorts or uture phases or projects. It may help avoid costly errors in
the uture by increasing the accuracy o planning and scheduling. It provides
inormation or benchmarking against success criteria or task durations, costs,
risks and work rate(s). Thus, it improves the quality o decision making and
condence in delivery.
From a planning perspective, there are two types o learning that should be
captured.

31.3 Productivity data

First, there are the actual output rates achieved. These should include not only
the man-hours expended by the resources, but also the costs incurred or these
outputs (Figure 31.1). The quantity and quality o the work should also be noted,
mentioning any mitigating actors aecting perormance. For example, was the
weather unusually cold, or very hot?

325
For use by APM individual and corporate members only
 Planning, Scheduling, Monitoring and Control

Figure 31.1 Example proorma to collect output rates

Similarly, or design work, capturing the total man-hours to produce certain
types o deliverables will give useul productivity data or uture use.

31.4 Qualitative lessons learned

The second type o inormation that it is important to capture is more qualitative
in nature: it is the collection o lessons learned. This will cover things that were
done well and things that could have been improved. This will usually be captured
in a ormal review session and subsequent report.
A learning review is a simple activity which helps project team members to
continually learn ater the completion o a project stage or at the end o the overall
project. It brings together relevant team members and stakeholders and allows
them to evaluate the outcomes o their actions and to draw lessons or the uture.
It is usually conducted with the help o a acilitator, and is a structured method or
prioritising and synthesising lessons learned across the whole project lie cycle.
Lessons learned must be recorded and reviewed throughout the project lie,
and not just at the end o a phase (when many people have let the project to
ocus on other work or new projects). To achieve this, a process or recording
lessons learned must be established and promoted to all members o the project
team.

31.4.1 Stakeholders involved in a lessons learned review

The key stakeholders identied should be representative o the project and be
able to objectively review the project perormance. Below is a suggested generic
list o stakeholders who could be involved in the lessons learned review:

• project sponsor;
• project manager;

326
For use by APM individual and corporate members only
 Lessons learned

• responsible managers (section managers, or control account managers in

deence sector);
• project controls managers;
• unctional heads o departments or subject matter experts;
• client representatives;
• key supply chain representatives;
• people involved in related projects who could contribute to or benet rom the
review.

31.4.2 Considerations
• Lessons should be agreed by all project team members.
• Complete individual lessons learned as soon ater the task/activity/stage has
completed, and try to conduct within a month.
• Focus on uture improvements and re-usability.
• Categorisation o lessons learned is useul to aid uture analysis o both lessons
and actions.
• The document(s) where the lessons learned will reside and the relevant
process (i applicable) where the lessons learned are applied.
• To update the lessons learned action plan to ensure that the lessons have been
captured and the relevant documentation updated in line with the organisa-
tion’s change control process.

An action plan should be created rom the lessons learned exercise and will have
the ollowing headings to help complete the integration o the lessons back into
the organisation:

• unique ID;
• lesson learned element description;
• lesson learned owner;
• lesson learned action;
• signicance;
• relevant control document;
• change control completed.

The unctional leads are responsible or veriying that appropriate personnel are
aware o the learning points in the repository and that any recommendations
have been implemented and any actions are closed out.

327
For use by APM individual and corporate members only
For use by APM individual and corporate members only
 The nal word

The plan, the real world and how the project reacts!
For use by APM individual and corporate members only
For use by APM individual and corporate members only
 Glossary

Accrual A liability that has yet to be invoiced. The timing o payment and
amount o the invoice may be uncertain.
Activity-based cost The estimated time taken to complete the work activity,
multiplied by the composite hourly rate or the personnel, together with additions
or materials and equipment.
Activity weeks method A simple method o monitoring progress by
counting the number o activities in progress each week.
Actual cost Also known as actual cost o work perormed (ACWP). It is the
cost o the work that has been perormed. It may include costs rom accounting
systems with appropriate accruals.
Arrow diagram method (ADM) A method o creating a network with
activities on the ‘arrows’ rather than the ‘nodes’.
Assurance process The process by which one party – usually the customer
– makes sure that another party – oten a contractor – carries out a particular
action, e.g. compliance with standards.
Bar chart See Gantt chart.
Baseline The reerence level against which a project is monitored and
controlled.
Benet realisation review A review o the project outcomes – the analysis
o eedback rom key stakeholders and the reasons or success or ailure o the
realisation o anticipated benets. Actions and recommendations should result
rom the review.
Breakdown structure A hierarchical structure by which project elements
are broken down, or decomposed. Examples include cost breakdown structure
(CBS), organisational breakdown structure (OBS), product breakdown structure
(PBS) and work breakdown structure (WBS).
Budget at completion (BAC) The total budget or the work.

331
For use by APM individual and corporate members only
 Glossary

Budgeted cost o work perormed (BCWP) Earned value.

Budgeted cost o work scheduled (BCWS) Planned value.
Capital costs Costs that come rom capital unds as opposed to unds or
operational costs.
Change log A record o all project changes, whether proposed, authorised,
rejected or deerred.
Change order Authorises a change to the brie, including a change o
scope or agreement to accept a design solution which is outside the agreed
cost parameters.
Conguration management Conguration management encompasses the
administrative activities concerned with the creation, maintenance, controlled
change and quality control o the scope o work.
Constraint date Used to x the start or nish o an activity at a particular
point in time.
Contingency Funds set aside or responding to identied risks.
Cost breakdown structure A hierarchical structure used to organise the
project costs according to category, oten aligning them with the organisation’s
budgeting system. It acilitates tracking the budget perormance o the project.
Cost estimating relationships (CER) Data analysed to nd correlations
between cost drivers and other system parameters such as size, design or
perormance.
Cost variance Cost comparison between what has been earned and what
has been spent.
Cost perormance index (CPI) The ratio o earned value over actual cost.
Critical path method (CPM) A project modelling technique which
determines the longest logical path through a network schedule.
Critical path This is the chain o activities connecting the start o a network
with the nal activity in that network through those activities with zero foat.
There may be more than one critical path in a schedule.
Critical path analysis An analysis o the schedule based on the critical path
technique, including the examination o foat usage.

332
For use by APM individual and corporate members only
 Glossary

Dashboard reports Perormance metrics (normally comprising graphs and

charts) to present the state o a partolio, programme or project.
Deliverables A product, set o products or package o work that will be
delivered to, and ormally accepted by, a stakeholder.

Delphi technique A technique based upon the principle that estimates rom
an experienced and structured panel can provide a useul judgement-based
output.

Dependencies The relationship between activities in a network diagram.

Dependencies can be internal or external. Internal dependencies are those under
the control o the project manager. External dependencies are those outside the
control o the project manager.

Design and build A method to deliver a project in which the design and
construction services are contracted by a single entity.

Drop line method A progress reporting method in which a vertical line is

drawn at the point o the progress assessment date, across the bars on the
schedule.

‘Dummy’ tasks or activities An activity added to a schedule that does not

describe work. Oten used in preerence to adding a ‘lag’ to the schedule.

Early nish The earliest possible date by which an activity can nish within
the logical and imposed constraints o the network.

Early start The earliest possible date when an activity can start within the
logical and imposed constraints o the network.

Earned value (EV) The value o completed work expressed in terms o the
budget assigned to that work. A measure o progress, which may be expressed
in money or labour hours.

Earned value analysis (EVA) A technique or measuring project perorm-

ance and progress.

Earned value management A project control process, based on a structured

approach to planning, cost collection and perormance measurement. It acilit-
ates the integration o project scope, time and cost objectives and the establish-
ment o a baseline plan o perormance measurement.

333
For use by APM individual and corporate members only
 Glossary

Earned value technique (EVT) A technique used to objectively assess the

progress o an activity.
Estimate at completion (EAC) A value expressed in money and/or hours
to represent the projected nal costs o work when completed. (Also reerred to
as projected out-turn cost.)
Estimate to complete (ETC) The orecast o labour hours and costs
required to complete the remaining authorised work. It is based on a bottom-up
analysis o remaining work, and past and uture perormance, along with the
availability o resources, is taken into consideration.
Float Time by which an activity may be delayed or extended without aecting
the start o any succeeding activity. Slack is an alternative term or foat.
Forensic schedule analysis The study and investigation o events using
critical path methods or other recognised schedule or schedule calculation
methods.
Fragnet Template networks or schedules, usually or repetitive sections o
schedules.
Gantt chart A particular type o bar chart used in project management,
showing planned activity against time. A Gantt chart is a time-phased graphic
display o activity durations. Activities are listed with other tabular inormation on
the let side, with time intervals over the bars. Activity durations are shown in the
orm o horizontal bars.
Hammock A ‘summary’ task which can only have start to start and nish to
nish logic to a group o activities. The duration o the hammock is determined by
the total elapsed duration o the activities it is linked to.
Horizontal integration This reers to the application and checking o logic
through the dierent sections o the schedule that are running in parallel (rather
than the sequential logic).
Independent cost estimate Estimate prepared by external or third parties
with the express purpose o validating, cross-checking or analysing estimates
developed by project teams.
Inormation required register A schedule detailing what inormation is
required throughout a project. Usually comprising three sets o dates or each
piece o inormation: planned/orecast/actual.

334
For use by APM individual and corporate members only
 Glossary

Interace Internal interace may relate to the handover o a piece o work

rom one team to another. External interace may relate to deliverables to be
given or received rom a third party organisation.
Issues log Primarily a list o ongoing and closed issues on the project. It is
used to organise the current issues by type and severity in order to prioritise.
Key perormance indicator (KPI) KPIs are measures that provide
managers with the most important perormance inormation to enable them or
their stakeholders to understand the perormance level o the organisation.
Lag In a network diagram, the minimum necessary lapse o time between the
nish o one activity and the start o another. (May also be used with nish to
nish logic, etc.)
Lead A negative lag. By denition an illogical condition.
Level o eort (LOE) An ongoing activity that is carried out to support other
work activities or the entire project.
Line o balance A scheduling technique or delivery o repetitive products
that shows how resource teams move rom product to product rather than the
detail o individual activities.
Logic The links (predecessors or successors) between activities in a schedule
or network diagram.
Logic density The average number o logic links per activity across the
schedule.
Logistics planning The planning o the movement o physical resources
such as materials, plant and equipment.
Make ready needs The things that must be in place to allow an activity to
commence, e.g. designs, approvals, materials, etc.
Management reserve A sum o money held to cover the cost impact o an
unexpected event.
Metadata A term used to describe data about data. Document management
systems contain metadata.
Milestone denition sheet (MDS) This is a sheet to record the details o
a key milestone. Includes description and date, as well as parties involved in
achieving the milestone.

335
For use by APM individual and corporate members only
 Glossary

MOD Ministry o Deence (UK).

Monte Carlo analysis A set o computational calculations that rely on
repeated random sampling to obtain a range o results – a probability distribution.
Network diagram A pictorial presentation o project data in which the
project logic is the main determinant o the placements o the activities in the
network. Frequently called a fowchart, PERT chart, logic drawing, activity work
or logic diagram.
New engineering contract (NEC) A suite o contracts that acilitate the
implementation o many sound project management principles and practices.
They also dene legal relationships.
Optioneering Optioneering estimates are prepared to establish the cost
dierences between two or more strategies in order to arrive at ranking to inorm
an economic decision.
Order o magnitude (OM) Orders o magnitude are numbers o approxim-
ately the same size.
Ordinal dates Where the calendar dates or a project are not yet known, the
schedule can be drawn up against week or month numbers, e.g. week 1, week 2,
week 3, etc.
Organisational breakdown structure (OBS) A hierarchical way in which
an organisation may be divided into management levels and groups, or planning
and control purposes.
Output rate The planning data required to enable the scheduler to work out
the duration o an activity, e.g. cubic metres per hour or excavation.
Parametric estimating This uses a methodology that is based on
elements o cost extracted rom historical data acquired rom similar systems or
sub-systems.
Perormance constraints These are usually determined by the brie or
specication or a project, and may be critical to the business case, e.g. manuac-
turing output rom a actory.
Perormance measurement baseline (PMB) The schedule o all the
work to be perormed, the budgeted cost or this work, and the elements that
produce the deliverables.

336
For use by APM individual and corporate members only
 Glossary

Planned value (PV) The value o work expected to be completed at a point

in time. This may be expressed in money or labour hours.
Planning packages These represent work that is not dened enough to be
included within a work package. Usually used to cover uture work.
Possessions These are times within a schedule when the project has to take
over the work area, thus stopping normal activity. For example, a track possession
stops trains running and allows work to be carried out. Can also apply to works in
actories/manuacturing lines.
Precedence diagram method (PDM) This is a network diagram method
in which the node designates the activity, and the logical interace is represented
by the arrow.
Predecessor An activity that must be completed beore the ollowing activity
can commence.
Prelims ‘Prelims’ is a short orm or preliminaries: the on-cost expenses, sta
costs, site overheads, etc.
Probability chart A chart showing the likelihood o an instance occurring –
or example, the likelihood o the project nishing on a specic date (usually
ound in QSRA).
Procurement strategy The criteria to be considered prior to letting or
purchasing services or a project. Examples are what type o contracts will be
used; how the work will be packaged up; how the project will be unded.
Product breakdown structure A hierarchy o deliverables that are
required to be produced on the project. This orms the base document rom
which the execution strategy and product-based work breakdown structure may
be derived. It provides a guide or conguration control documentation.
Programme manager The manager responsible or a group o projects, or
example a large change programme.
Project brie This denes the customer’s or client’s requirements, and is key
to the design. It is also a undamental element o the business case.
Project execution plan (PEP) The document describing how, when and
by whom a project will be delivered. The targets will include the scope, times-
cales, costs, quality and benets.

337
For use by APM individual and corporate members only
 Glossary

Project lie cycle Four major stages: 1) initiation; 2) planning; 3) execution;

4) closeout/handover.
Project management plan (PMP) Consists o the collection o key project
inormation needed by the project board, project manager and project oce to
manage the project. Will comprise static elements (that are periodically reviewed
but change rarely during the lie o the project) and dynamic elements (that
change oten).
Project schedule The tool that communicates what work needs to be
perormed, which resources will perorm the work and the timerames in which
that work will be perormed.
Project sponsor This is the individual (oten a manager or executive) with
overall accountability or the project. They are primarily concerned with ensuring
that the project delivers the agreed business benets.
Prolongation The term used to cover the amount o time a project duration
extends – usually due to a delay.
Quantitative schedule risk analysis (QSRA) A generic term or
objective methods o assessing risks that cannot be identied accurately.
RACI The RACI matrix is a tool used or identiying roles and responsibil-
ities to avoid conusion over those roles and responsibilities during the
project.
Redundant logic Logic links that are duplicated through an alternative route.
I ‘C’ cannot start until ‘B’ is complete, which cannot start until ‘A’ is complete,
then a logic link rom ‘A’ to ‘C’ would be said to be redundant.
Request or inormation (RFI) The term used – usually in a ormal
contract process – when a project team member requires extra inormation or
clarication.
Requirements management The process o capturing, assessing and
justiying stakeholders’ wants and needs.
Resources A supply o money, materials, sta, labour, equipment or other
asset that can be used to deliver a product or service.
Resource breakdown structure (RBS) The hierarchical breakdown o a
project into resource requirement elements.

338
For use by APM individual and corporate members only
 Glossary

Resource histogram The graphical display o resource requirement or

usage on a project.
Responsibility assignment matrix (RAM) A diagram or chart showing
assigned responsibilities or elements o work. It is created by combining the
work breakdown structure and the organisational breakdown structure.
Risk A signicant, unplanned and uncertain event or situation that, should it
occur, will have an eect on at least one project or schedule activity, or business
objective. A detrimental risk is oten called a ‘threat’, and a benecial risk is called
an ‘opportunity’.
Risk and opportunities register This is a central repository or all risks
identied by the project. Includes inormation such as risk probability, impact,
counter-measures, risk owner, etc. Also contains a section or opportunities,
which can be time or cost-saving options.
Risk log This is a central repository or all risks identied by the project.
Includes inormation such as risk probability, impact, counter-measures, risk
owner, etc.
Risk management plan This sets out how the thorough assessment o risk
associated with the project will be implemented.
Risk pot The und where the money allocated or risk is kept. The money is
‘drawn down’ rom the und as required.
Rolling wave planning This describes the planning density that is achieved
at dierent moments in time. Primarily more detailed planning in the immediate
uture and less detailed towards the end o the project.
Rough order o magnitude (ROM) An estimate o costs and time provided
in the early stages o a project when its scope and requirements have not been
ully dened.
Schedule perormance index (SPI) A term used in earned value analysis.
It is the ratio o work accomplished to work planned or a specied time period.
The SPI is an eciency rating or work accomplishment, comparing work
achieved with what should have been achieved at any point in time.
Schedule variance A metric or the schedule perormance on a project is the
algebraic dierence between earned value and the budget (schedule variance =
earned value – budget). A positive value is a avourable condition, whilst a
negative value is unavourable.

339
For use by APM individual and corporate members only
 Glossary

Schedule visibility task (SVT) Where an activity is dependent on a lead

time, the schedule visibility task represents the elapsed/lead time or the customer
approval time.
Scheduling Sotware Sotware used or project planning, scheduling,
resource allocation and perormance measurement activities. Is also used or
collaboration and communication between project stakeholders.
Scope The sum o deliverables and the work content to produce a project.
S-curves Lines drawn on a graph to express a quantity planned, achieved or
expended across time. Named ‘S-curves’, as there is a usual tendency or them to
commence and complete at a slower rate.
‘Scrum’ Scrum is an ‘agile methodology’ that can be applied to nearly any
project; however, it is most commonly used in sotware development.
Slack (or foat) Slack is the term used by MS Project to describe foat.
SMART Usually relates to specic, measurable, achievable, realistic, and
time-bound (there are other variations).
Specic analogy estimating This method o estimating is based upon
selecting a costed project that is similar or related to the project costs being
estimated.
Stage plan A development o the project schedule that contains enough
detail to allow the project manager to control a portion o the project (the ‘stage’),
usually on a daily basis.
Stakeholder Any individual, group or organisation that can aect, be aected
by or perceive itsel to be aected by the project.
Stakeholder management The systematic identication, analysis and planning
o actions to communicate with, negotiate with and infuence stakeholders.
Statement o work This explains the customer/client needs and require-
ments. It is oten developed in line with the business case. It will then orm the
basis o contractor selection and contract administration.
Steps These are pre-agreed progress measures against which the project will
assess the tasks, to establish per cent completion statuses in a tangible and
objective (rather than subjective) way.

340
For use by APM individual and corporate members only
 Glossary

Strategic schedule The high-level schedule. Oten produced early in the

project lie cycle to help determine the relationship with other projects.
System requirements These dene and drive the work to be completed
within the system design process and subsequent subsystem and component
design.
Successor A successor is an activity whose start or nish depends on the start
or nish o a predecessor activity.
Target date The planned date to complete an activity or project. (May be
earlier than the contract date.)
Three-point estimate An estimate giving the most likely mid-range value,
an optimistic value and a pessimistic worst case value.
Time analysis The process that calculates the timerame in which each
activity can take place. It identies the minimum time in which the network can
be completed, based on the activity durations and the logical links dened.
Time chainage Used to illustrate projects that are linear in nature (an example
being road construction). When well designed and drawn, it is a very useul visu-
alisation tool, oten allowing the whole project to be displayed on a single chart.
Time contingency An approximate duration o time assigned to an activity
that takes into consideration the impact o uncertainty.
Time risk allowance (TRA) Durations are uncertain, and thereore time
contingency should be allowed or in schedules (also see QSRA).
Tornado chart Within a quantitative schedule risk analysis, one o the outputs
is a chart that resembles the shape o a tornado. The activities that have the most
infuence on the overall project end date are displayed in the tornado chart.
Total foat Time by which an activity may be delayed or extended without
aecting the total project duration or delaying a nish date.
Validation and verication requirements matrix This V-shaped model
is useul to map the user requirements and system design, in order to acilitate
the assurance process.
Vertical integration The process that conrms that the data at dierent
levels o detail is consistent and comprehensive throughout the whole length o
the schedule – rom beginning to end.

341
For use by APM individual and corporate members only
 Glossary

WBS dictionary Covers the various WBS sections and denes all the deliv-
erables relating to the scope or statement o work.
Windows analysis This process is used to compare the planned schedule
with the as-built schedule during a particular period or ‘window’ o time.
Work breakdown structure (WBS) Denes the total work to be
undertaken and provides a structure or all control systems. It allows a project or
programme to be divided by level into discrete groups or programming, cost
planning and control purposes. The WBS is a tool or dening the hierarchical
breakdown o work required to deliver the products. Major categories are broken
down into smaller components. These are sub-divided until the lowest required
level o detail is established. The lowest units o the WBS are generally work
packages.
Work calendar Used to dene the amount o working and non-working time
throughout the duration o the project. They are also used to determine when
the work will be carried out, e.g. night working or weekends only.
Work package A discrete element o project scope at the lowest level o
each branch o the work breakdown structure. Collectively, the work packages
speciy all the work and products included in the project.

342
For use by APM individual and corporate members only
 Acronyms

£RAM Financial responsibility assignment matrix

3D Three-dimensional
ABC Activity-based cost estimating
AC Actual cost
ACWP Actual cost o work perormed
ADM Arrow diagram method
AE Apportioned eort
AFC Anticipated nal cost
ATE Actual time elapsed
B/L Baseline
BAC Budget at completion
BCWP Budgeted cost o work perormed
BCWS Budgeted cost o work scheduled
BIM Building inormation modelling
BT Budget transer
CAD Computer aided design
CBS Cost breakdown structure
CER Cost estimating relationship
CO Change order
CPI Cost perormance index
CPM Critical path method
CV Cost variance
DSDM Dynamic systems development method
EAC Estimate at completion
EFC Estimated nal cost
ETC Estimate to complete
ETTC Estimated time to complete
EV Earned value
EVA Earned value analysis
EVM Earned value management
EWN Early warning notice
FF Finish to nish
FS Finish to start

343
For use by APM individual and corporate members only
 Acronyms

HSE Health, saety and environmental

KPI Key perormance indicator
LOE Level o eort
MDS Milestone denition sheet
MOD Ministry o Deence
MoSCoW Must have, should have, could have, won’t have
NEC New engineering contract
OBS Organisational breakdown structure
OD Original duration
OM Order o magnitude
PBS Product breakdown structure
PDM Precedence diagram method
PEP Project execution plan
PMB Perormance measurement baseline
PMI Project manager’s instruction
PMP Project management plan
PV Planned value
QCRA Quantitative cost risk analysis
QSRA Quantitative schedule risk analysis
RACI Responsibility, accountability, consulted, inormed matrix
RAM Responsibility assignment matrix
RBS Resource breakdown structure
RFI Request or inormation
ROM Rough order o magnitude
SF Start to nish
SI Site instruction
SMART Specic, measurable, achievable, relevant, time-bound
SOW Statement o work
SPI Schedule perormance index
SRD Systems requirement document
SS Start to start
SV Schedule variance
SVT Schedule visibility task
TRA Time risk allowance
TV Time variance
WBS Work breakdown structure
WBSD Work breakdown structure dictionary
WI Works inormation
XP Extreme programming

344
For use by APM individual and corporate members only
 Index

£ RAM 65, 70 see also responsibility as-built schedules 105–6, 314

assignment matrix (RAM) assumptions: assumptions list 22, 40, 43, 150,
189, 276; assumptions register 150, 189,
2D BIM model 199 276; project assumptions 27;
3D BIM model 199–202 assurance process 29, 317
4D BIM model 199 audit 30, 252, 261, 317
100% rule 61
BAC (budget at completion) 236
ABBF (as-built but or method) 304, 306–7 backward passes 126–7
ABC (activity-based cost) estimating 82 ‘banana curves’ 86
AC (actual cost) 236, 240–1 bar charts 109, 147, 167–72, 186 see also
acceptance criteria 16–17, 26, 28 Gantt charts
accounting systems 69–70 baseline: setting the baseline 209–20; and
accruals 241 agile planning 48; baseline maintenance
activities: activity checks 191–3; activity coding 213–16; and the business case 17; and
26, 114, 120, 158–9, 192, 213; activity change management 260, 264–5, 266, 267;
descriptions 114; activity durations 191–2; and the contract schedule 102–3; and cost
activity identity numbers (IDs) 113–14, 158, control 252; and earned value analysis
192, 213; and the baseline 211; critical 239; and perormance reporting 223; and
activities 197–8; deleted activities 192; and the planning process 39; and quantitative
earned value analysis 237; out-o- schedule risk analysis 286; re-baselining
sequence activities 194–5; scheduling 216–20; and scheduling 93
113–20; steps 116–17, 323 BCWP (budgeted cost o work perormed)
activity weeks method 222, 224, 226–7, 228, 236 212, 236
ACWP (actual cost o work perormed) see AC benchmarked data 149, 198
AFC (anticipated nal cost) 251 benet realisation review 17–19
agile 47–9, 203–6 BIM (building inormation modelling) 199–202
ALAP (‘as late as possible’ constraint) 138 bottom-up cost estimating 82
analogy estimating 80–1 bottom-up planning 43–7
annual spend proles 16 BRAG ratings 246
AOA (activity on arrow method) 123 brainstorming 22, 57
AON (activity on node method) 122 breakdown structures 22–4, 53–71, 211
AP v AB (as-planned versus as-built method) budgeting: budget transers 84, 87, 220, 267,
304–5 271; and cost control 251–3; and earned
apportioned eort 248 value analysis 242–3; as part o planning
approximate estimating methods 79, 80–1 83–7; and perormance reporting 230,
arrow diagram method (ADM) 122–3 236–7; and risk management 198, 283–4

345
For use by APM individual and corporate members only
 Index

buers 164–6 contingency: and the baseline 211; and the

build method 22 business case 18; contingency budgets 80;
‘Bulls eye’ chart 245 and earned value analysis 238; and
business case 11–19 quantitative cost risk analysis 297; and
business-as-usual estimating 82 record keeping 314; record keeping 284;
time contingencies 51, 164–5, 197, 286
CAB (collapsed as-built method) 304, 306–7 contract schedule 102–3, 174
calendars 116, 118–20, 187, 192–3 contracting strategy 18
capital costs 16 contractor’s ee 239
cash-fow: denition 49; orecasting 18, 84–6; coordination meetings 257
monitoring 222, 230 cost/benet analysis 14, 278, 284
change control processes 260–71; and the cost breakdown structure (CBS) 23–4, 56,
baseline 213, 214, 220; and budget 69–71, 84, 231, 240
transers 87; and cost control 252; and cost budgets 84–6
requirements management 29; and cost control 251–3
scheduling 93; and scope management 22 cost estimating 77–82
change reezes 261 cost estimating relationships (CERs) 81
change log 263–4, 265, 266, 268, 314 cost orecasting 251
change management 259–71 cost management 236
change orders/change notices 79, 266–7, cost perormance index (CPI) 244–5, 253
271 cost value analysis 83, 222, 231, 232
change requests 263–7 cost variance (CV) 216, 218, 242, 253
claims on the contract 106, 303 critical paths: and assumptions 151; building
closeout/handover 14, 201, 319–22 the schedule 121–47; and change
coding interaces 158–9 see also activity management 268; and closeout/handover
coding 319; and constraints 138; critical path
collaborative planning 44, 204 analysis 123–4, 152, 221, 224, 234–5, 285;
common sense 8, 61, 181 critical path method (CPM) 49, 121–47,
communication 32, 167–81 197, 303–9; and interaces 161; and
comparative duration estimations 149 perormance reporting 234–5; planning
competitive tender, alternatives to 18 checks (o schedule) 189–90; and
complex projects: external integration o quantitative schedule risk analysis 286;
interaces 162; organisation breakdown and rolling wave planning 47; and
structure (OBS) 64; rolling wave schedule review 187; and scheduling 41, 43,
planning 45–6 93; scheduling checks 196–8
compliance 26 cumulative normal distributions see S-curves
computer aided design (CAD) 199 customer approval 116, 179 see also closeout/
‘conceptual’/‘pre-conceptual’ estimates handover
78–9
concurrency 310 dashboard reports 221
conditions o contract 309 data date 186, 224
conguration management 261 data table 184–5
consents 181; consents trackers 42 day zero 125, 130
constraints 27, 39, 136–47, 159, 197 deerred change requests 265

346
For use by APM individual and corporate members only
 Index

denitive estimating methods 79, 80, 82 earned value management 221, 249,
delays 74, 103, 107, 225, 243, 303–6 253
deleted activities 192 earned value techniques (EVTs) 247
deliverables: and the 100% rule 61; and the ‘easy to measure’ statistics 17
baseline 211; and budgeting 84; and the ‘economic best t’ 50–1
business case 17; and closeout/handover emergency procedures 261
319, 321; and cost estimating 82; design end-user benets 17
deliverables tracker 109, 111; and the estimating: cost estimating 77–82; estimate
planning process 38, 40; as ‘product’ 57; at completion (EAC) 83, 246–7, 252;
product breakdown structure (PBS) 57; estimate to complete (ETC) 246, 252;
and the RACI matrix 68; and requirements estimated nal cost (EFC) 252, 253;
management 25, 28; and the estimated time to complete (ETCC) 247;
responsibility assignment matrix (RAM) estimating norms 40; estimation o duration
67; rolling wave planning 45–6; and 147–51; air price estimating methods 79;
scheduling 157; and scope management 21 impact o change 264; quantity o resources
Delphi technique 81 153
density o schedules 94–8 ‘events’ ocused (top-down) planning
dependencies: bar charts/Gantt charts 170; 43–4
and breakdown structures 55; coding expert opinion 150
120; and critical path networks 125, 126; external integration 160–2
dependency management 73–4; and the
planning process 38, 40; and requirements acilitated workshops 22, 44, 158
management 26, 27; and scheduling air price estimating methods 79
157–64 eeder buers 164
design and build phase 26 lters (on schedule views) 114, 184, 186,
design deliverable schedules 42 187
design deliverables tracker 109, 111 ‘nish on’ constraint 139, 197
detail density, schedule 94–9 ‘nish on or ater’ constraint 140
development/strategic schedule 101–2 ‘nish on or beore’ constraint 141
dictionaries 30, 61–2 nish to nish relationships 116, 134, 193
‘digital handover’ 201 nish to start relationships 123, 132–3, 193
discrete distributions 291 foat: and budgeting 86; and constraints
document management 317–18 137–40; and critical path networks 122,
drop line method 222, 224–6 124, 127–8, 130–1; and delay analysis 310;
dummy tasks 116, 120, 123, 136, 194 and drop line methods 225; ree foat
duration: duration uncertainty 285–6, 287, 131, 155; measurement o foat usage 222,
292, 294; estimation o duration 147–51 234–5; negative foat 131, 137, 142,
189–90, 196–7; and planning checks
early delivery 104 189–90; and quantitative schedule risk
early nish dates 126, 127 analysis 286; and scheduling 41, 50;
early/late curves 50–1, 85–6, 211 scheduling checks 196–8; shared foat 132
early start dates 126, 212 see also total foat
earned value analysis (EVA) 83, 222, 231, ‘orecast schedule’ 103
235–49 orensic schedule analysis 303–9

347
For use by APM individual and corporate members only
 Index

orward and backward passes 93, 124, internal integration 159–60

125–7 invalid dates 193
ragnets 99, 215 issues log 38
ree foat 131, 155 iterative nature o processes: and agile
‘ull detail’ cost estimating 82 planning 48, 203; and ‘collaborative
unding requirements 16, 83–4, 259, 266 planning’ 44; and foat 155; and logic 123;
and requirements management 26;
Gantt charts 42–3, 66, 123, 167–72, 184–5, scheduling interaces 158; and stakeholder
186 management 32; work breakdown
gate reviews 45–6 structure (WBS) 60
gateways 16, 34, 101, 212
graphical schedules 42 jagged line method see activity weeks
group workshops 158 method

hammocks 115–16 key assumptions management 22

handover and closeout 201, 319–22 KPI (key perormance indicators) 242, 244
hard constraints 197
high-density schedules 44–6, 94–9, 255 lags 116, 120, 123, 135–6, 194, 198
histograms or resource proles 16, 154, 180, latest nish dates 127–8, 137
186, 198 latest start dates 127
holidays and non-working days 118–19 leads 116, 120, 135, 194, 198
horizontal integration 93, 156–7 learning review 326
HSE (health, saety and environment) 75–6, legislative changes 259
261 lessons learned 253, 276, 284, 314, 325–7
human actors/sot issues 2, 40 level o eort (LOE) activities 82, 115, 191–2,
198, 238–9, 248, 287
IAP (impacted as-planned method) 304, levels o schedules see density o schedules
305–6 line o balance 43, 167, 172–4, 222, 229–30
impact analysis 264 log normal distributions 289
impact resolution 163–4 logic: and change management 271; critical
independent cost estimates 79 path method (CPM) 121–47; displaying
infation 239 networks using scheduling sotware 147;
inormation required register 189 level o eort (LOE) activities 115; logic
innovative thinking, need or 37 bottlenecks 195–6; logic checks 193–6;
intellectual property 18 logic density 195; logical networks 125;
interaces: coding 120; dependency logic-linked scheduling 41, 43, 44, 98–9,
management 73–4; handover/hand-back 120; and schedule review 187; and
trackers as 42; horizontal integration 157; top-down planning 43; types o logic linking
milestones 74; planning checks 189; and the 132; work breakdown structure (WBS)
planning process 38, 40; public interaces 60
and HSE 75–6; and requirements logistics planning 40, 152, 153, 189
management 26, 27; and scheduling long-duration projects 45–6
157–64; stakeholder management 32; ‘longest path’ 128, 129, 197–8
WBS dictionary 61–2 look-ahead schedules 105, 191, 255–7

348
For use by APM individual and corporate members only
 Index

make ready needs 256, 257 options analysis 22

management issues: nancial authority or order o magnitude (OM) estimates 79
change 267; and lessons learned 326–7; ordinal dates 120, 125, 186
management reserve 238, 259, 281, 283; organisation breakdown structure (OBS)
planning checks (o schedule) 188; and 23–4, 53, 56, 60, 64–5, 66–7
schedule density 98; senior management out-o-sequence activities 194–5
98; and tracker schedules 109 output rates 91, 187, 191, 325–6
‘mandatory nish’ constraint 142, 197 output summaries 45
‘mandatory start’ constraint 143, 197
master/working schedule 42 P values 286, 292, 298, 301–2
‘measured quants’ cost estimating 82 P0 plan 49
medium-term schedules 105 packages o work see work packages
metadata 199, 318 parallel working 133, 134, 193
method statement schedules 42 parametric estimating (estimating norms) 81
‘mid curves’ 86 ‘parent’/‘child’ relationships in WBS 61
milestones: activity steps 116; as alternative PDM (precedence diagram method) 122
schedule reporting 170–1; and the baseline per cent complete 248
211; and earned value analysis 248; and perormance analysis techniques 222, 234–49
interaces 162; interaces 74; milestone perormance constraints 39
denition sheets 189; milestone perormance measurement baseline (PMB)
monitoring 222, 227–8; and multiple ends 209, 211, 236, 238–9, 252–3, 281, 283 see
195; scheduling checks 191 also baseline
minute-based time units 118 perormance reporting 221–49, 257–8
mission critical projects 12 permits and licences 181
modelling sotware 199 PERT (programme evaluation review
Monte Carlo analysis 148, 284, 286–8, 291, technique) 148, 290–1
297–8 planned value (PV) 49, 236, 239–40
MoSCoW technique 48 planning checks (o schedule) 183–4, 188–90
multiple ends 195–6 planning method statement (schedule
narrative) 43
negative foat 131, 137, 142, 189–90, 196–7 planning packages 93, 213, 238
network analysis 151, 222, 234–5 see also planning strategies 49–51
critical paths planning vs scheduling 41–2, 91, 94
network diagrams 66, 93 possessions 181, 292
network templates 99 post-build schedules 106
New Engineering Contracts (NEC) 165, 271, post-implementation survey 17
303 predecessor relationships 116, 123, 133, 134,
normal distribution curves 288 143, 159, 194, 195
preliminary estimates 79
‘objective criteria’ (steps) 116–17 probability charts 292, 293, 295
‘one version o the truth’ reporting 104, 200 process step schedules 42
opportunities see risk procurement schedules 107–9, 110, 189
opportunity assessment matrix 278 procurement strategy 17–18, 84
optioneering 79, 268 product analysis 22

349
For use by APM individual and corporate members only
 Index

product breakdown structure (PBS) 22–3, project sponsor: and the business case 11;
26–8, 56–8, 60, 157 and change management 260, 265, 266,
production curves 231, 233 268; and lessons learned 326; and
productivity data 313, 325 ‘re-planning’ 212; and requirements
‘programme’ (why book avoids use o term) 42 management 25, 29; and risk 15; and
programme manager 22, 31 scope management 22; stakeholder
progress assessments 223 management 31
progress weightings 116 project vision 48
project benets capability 151 prolongation 310 see also delays
project brie 11, 261–2, 268 PV (planned value) 49, 236, 239–40
project closeout see closeout/handover
project coding 120 QRA percentiles 298, 301–2
project controls system 40, 41, 211 qualitative lessons learned 326
project execution plan (PEP): and the quantitative cost risk analysis (QCRA)
business case 11; and change management 297–301
260, 268; and the planning process 38–9; quantitative schedule risk analysis (QSRA)
and requirements management 27, 29; 51, 93, 284–96
and risk management 276 quantity tracking 222, 223, 231–3
project amiliarisation 33–4
project lie cycle: and the baseline 211; and RACI matrix 67–9, 157
the business case 11, 13–14, 16, 19; and re-baselining 216–20
closeout/handover 320, 323; and cost record keeping 222, 313–16
estimating 77–9; and interaces 158; and recovery schedules 107
lessons learned 326; and project reviews 19; redundant activities 192
and requirements management 25; and redundant logic 194, 195
risk management 276, 280, 298; and relationship management 31–2
stakeholder management 32; and time ‘releases’ (agile planning) 47–8
contingency 51; and top-down planning repetitive schedules 99, 165, 172, 229
43–4 re-planning 216–18, 219
project management plan (PMP) 22 see also re-programming 218–20
project execution plan (PEP) requests or inormation (RFI) 257, 265
project manager 31–2, 115 see also requirements management 25–30
management issues requirements/needs-driven planning 43
project procurement proessional 18 resource breakdown structure (RBS) 23–4,
project reporting system 70 see also record 56, 70–1
keeping resource histograms 16, 154, 180, 186,
project review 19 198
project schedule: and interaces 159; and ‘resource-based estimating’ 82, 150
planning 42; and the planning process 39; resource-levelled schedules 50–1, 173, 212
project buers 164; and record keeping 314; resources: and the baseline 209–10, 211;
and requirements management 29; and budgeting 83; and the business case 14,
resource-levelled schedules 50–1; and risk 16; and calendars 118–19; and change
management 276, 285; and schedule review management 264; and closeout/handover
184; work breakdown structure (WBS) 60 320; cost estimating 77–82; ‘critical

350
For use by APM individual and corporate members only
 Index

resources’ 152; denition 152; organisation scheduling: and budgeting 84–5; building the
breakdown structure (OBS) 65; and schedule 121–64; communicating the
parallel working 134; and planning 37; and schedule 167–82; ‘density’ o scheduling
the planning process 39, 40; and 94–8; orensic schedule analysis 303–9;
requirements management 28; resource high-density schedules 44–6, 94–9, 255;
buers 164; resource coding 120; resource horizontal integration 156–7; master/
monitoring 222, 230–1; resource smoothing working schedule and separate trackers 42;
154–5; resources allocation 153–6; network templates (ragnets) 99, 215; and
resources scheduling checks 198; the planning process 39, 40; planning vs
resourcing the schedule 151–5; and the scheduling 41–2, 91, 94; resourcing the
responsibility assignment matrix (RAM) schedule 151–5; and risk management 285;
67; and scheduling 41, 92; work schedule design 113–20; schedule narrative
breakdown structure (WBS) 60 43, 179–81, 268; schedule review 183–98;
responsibility assignment matrix (RAM) schedule revisions 267; scheduling checks
23–4, 56, 60, 64, 65–7 190–8; scheduling density 94–9; scheduling
risk: and the baseline 211; and the business process 92–3; and short-term planning 255;
case 15, 18; and change management 273; time-based schedules 101–7
and earned value analysis 238; health, scheduling sotware: and activities 191;
saety and environment (HSE) 75–6; activity coding 113, 116, 118; and bar
planning or risk 274–5; and the planning charts/Gantt charts 170; baseline
process 40; review o schedule risk 198; risk maintenance 213; and bottom-up planning
and opportunities register 38; risk 44; and budgeting 85; and constraint
assessment 277–8; risk draw down 281–4; dates 137; display variations 184;
risk management 273–301; risk displaying networks 147; and drop line
management plan 274; risk mitigations 40, methods 226; line o balance graphs 174;
238, 276, 278, 280, 283, 286; risk pot 281; and planning 41, 44; time chainage charts
risk register 150, 187, 268, 277, 280, 296; 174, 175; when not to use 42–3, 103, 107,
risk review 280–1; rolling wave planning 109
45–6; and schedule review 187; and the scope: and the baseline 109; and change
statement o work 30; time contingency management 266; planning checks (o
51, 164 schedule) 189; ‘scope creep’ 21; scope
risk log 277, 279, 280 development estimates 78–9; scope
rolling wave planning 45–6, 214, 226, 238 management 21–4; scope transers 267
rough order o magnitude (ROM) estimates Scrum 204
79 S-curves 51, 85–6, 211, 239–42, 298–9
sensitivity analysis 299–300
saety 75–6 shared foat 132
scenario planning (‘What is’) 107 short-term planning 255–7
schedule perormance index (SPI) 239, 243, short-term schedules 105
244 shut-downs 118, 119, 181, 224, 292
schedule risk analysis 170 single point distributions 297
schedule variance (SV) 216, 217, 218, 219, ‘single version o the truth’ reporting 104,
242–3 200
schedule visibility tasks (SVT) 116 ‘slack’ see foat

351
For use by APM individual and corporate members only
 Index

SMART (specic, measurable, achievable, summary schedule 103

relevant, timebound) 13, 189 suppliers’ works inormation 29–30
social media 151 system requirements document (SRD)
sot issues 2, 40 27–8
sotware: 3D visualisation sotware 199–202;
and quantitative schedule risk analysis tactical planning 76
284, 286; record keeping 315, 318; target dates 163, 197
spreadsheets 84, 103, 107–9 see also target schedules 104
scheduling sotware task analysis cost estimating 82
SOW (statement o work) 27, 30, 60 teamwork: and agile planning 204; and
specialist products 57, 58, 152 ‘collaborative planning’ 44; and planning 38;
specic analogy estimating 80–1 team sizes 153
SPI (schedule perormance index) 239, 243, technical specication 28
244 tender/bid schedule 102
spreadsheets 84, 103, 107–9 three-point estimates 148, 286, 288, 290,
‘sprints’ (agile planning) 47, 204 291, 297, 298
stage plans 57 TIA (time impact analysis method) 304,
stakeholders: and acceptance criteria 17; and 307–8
agile planning 48; and the business case 12; time analysis 124
and change management 260, 263, 268; and time assumptions 15–16
closeout/handover 321; and ‘collaborative time chainage charts 42–3, 167, 174–8
planning’ 44; and communication o the time contingencies 51, 164–5, 197, 286
schedule 170; and interaces 158; and time/cost/scope/quality triangle 104
lessons learned 326; and perormance time management 236
reporting 223; and the planning process 40; ‘time now’ (data date) 224
and the product breakdown structure time risk allowance 165, 189, 197
(PBS) 57; and the RACI matrix 68; and time units 118
re-baselining 220; and requirements time-based schedules 42–3, 101–7
management 25, 27; and the risk timescale 186
management plan 274; and scope timescale risk analysis 284 see also
management 22; stakeholder quantitative schedule risk analysis
management 31–2, 40 (QSRA)
‘start on’ constraint 144, 197 top-down planning 43–4
‘start on or ater’ constraint 145 tornado charts 292, 294, 296, 298
‘start on or beore’ constraint 146 total foat 124, 127–8, 131, 155, 196–7, 310
start to nish relationships 134–5, 194 traceability 28
start to start relationships 116, 133–4, 193 tracker schedules 107–9
statement o work (SOW) 27, 30, 60 trackers, separate 42
steps, activity 116–17, 323 trend analysis 224, 235, 261
strategic t 15 triangular distributions 290, 297
strategic schedule 16, 94, 101–2
sub-contracting 79, 165 uncertainty 45–6
successor relationships 116, 123, 131, 133, uniorm distributions 289, 297
134, 159, 190, 194, 195 ‘unit cost’ estimating 82

352
For use by APM individual and corporate members only
 Index

V model (design and development) 28 work package scope sheet see WBS
validation and verication requirements dictionary
matrix (VVRM) 29 work packages: accountability 66; and
variance analysis 222, 224–34, 242 assumptions 151; and the baseline 213;
version control 318 breaking down into 18, 30, 53; and
vertical integration 93, 157 budgeting 84; and earned value analysis
237–8; and interaces 157; product
WBS dictionary 30, 61–2 breakdown structure (PBS) 57; and
weeks, as time units 118 re-baselining 220; and requirements
‘what i’ 107, 268 management 30; and the responsibility
windows analysis 304, 309 assignment matrix (RAM) 65, 67; rolling
work breakdown structure (WBS): as wave planning 45–6; work breakdown
planning tool 53, 56, 57, 59–63; and structure (WBS) 59–60, 63
budgeting 83, 84; and interaces 157, 159, working schedule/orecast schedule 103
161; and requirements management 26, works inormation (WI) 29–30
28, 30; and the responsibility assignment
matrix (RAM) 65, 66–7; and scheduling 41; XP (eXtreme Programming) 204
scheduling checks 193; and the scope 23–4
work calendars 92 ‘zero ree foat’ constraint 138

353
For use by APM individual and corporate members only
For use by APM individual and corporate members only