Planning, Scheduling,

Monitoring and Control

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

Association for Project Management

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

© Association for Project Management 2015

All rights reserved. No part of this public­a­tion may be repro­duced, stored in a retrieval system, or
trans­mit­ted, in any form or by any means, without the express permis­sion in writing of the
Association for Project Management. Within the UK excep­tions are allowed in respect of any fair
dealing for the purposes of research or private study, or criti­cism or review, as permit­ted under
the Copyright, Designs and Patents Act, 1988, or in the case of repro­graphic repro­duc­tion in
accord­ance with the terms of the licences issued by the Copyright Licensing Agency. Enquiries
concern­ing repro­duc­tion outside these terms and in other coun­tries should be sent to the Rights
Department, Association for Project Management at the address above.

British Library Cataloguing in Publication Data is avail­able.

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 RefineCatch Limited, Bungay, Suffolk
in 11/14pt Foundry Sans
 Contents
List of figures and tables xviii
Foreword xxiv
Preface xxvi
Acknowledgements xxviii
Peer review xxx
Purpose xxxi
The PSMC process map xxxii
1 Overview 1
1.1 Part One: Definition 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 learn­ing 6
1.6 A note on the Contents, Index and Gloss­ary 7
1.7 Management issues 7
1.7.1 Behaviour and resources 7
1.7.2 Processes and tools (schedul­ing soft­ware) 8
1.7.3 Common sense 8

Part One: Definition 9

2 Business case 11
2.1 Definition of the busi­ness case 11
2.2 Purpose of a busi­ness case 11
2.3 Contents of the busi­ness case 12
2.3.1 Structure of the busi­ness case 12
2.3.2 Planning inform­a­tion 15
2.3.3 Funding require­ments 16
2.3.4 Resource require­ments 16
2.4 Acceptance criteria in the busi­ness case 16
2.5 Benefits real­isa­tion in the busi­ness case 17
2.6 Procurement strategy 17
2.7 Project review and assur­ance process of the busi­ness case 19

v
Contents

3 Scope manage­ment 21
3.1 Definition of scope manage­ment 21
3.2 Purpose of scope manage­ment 21
3.3 The scope manage­ment process 22
3.3.1 Defining the scope 22
3.3.2 Describing the scope 22
4 Requirements manage­ment 25
4.1 Definition of require­ments manage­ment 25
4.2 Purpose of require­ments manage­ment 25
4.3 Process of defin­ing require­ments 25
4.3.1 Requirement descrip­tion 26
4.3.2 Factors to consider when defin­ing
require­ments 26
4.3.3 Inputs into require­ments manage­ment 27
4.4 The require­ments manage­ment process 27
4.4.1 Capture and define require­ments from all
stake­hold­ers 27
4.4.2 Link require­ments to the product break­down
struc­tures and work break­down struc­tures
where appro­pri­ate 27
4.4.3 Decompose require­ments 28
4.5 Works inform­a­tion (WI) 29
4.6 Statement of work (SOW) 30
5 Stakeholder management 31
5.1 Definition of stake­holder manage­ment 31
5.2 Purpose of stake­holder manage­ment 31
5.3 Managing stake­hold­ers through the project 31
6 Project famil­i­ar­isa­tion 33

Part Two: Planning 35

7 Introduction to plan­ning 37
7.1 Definition of plan­ning 37
7.1.1 Definition of the plan­ning role 37
7.2 Purpose of plan­ning 38
7.2.1 Benefits of plan­ning 39
7.2.2 Success in plan­ning 40
7.3 The differ­ence between plan­ning and schedul­ing 41

vi
 Contents

7.4 Principal schedul­ing compon­ents 42

7.4.1 Process step sched­ules 42
7.4.2 Time-based sched­ules 42
7.4.3 Schedule narrat­ive 43
7.5 Approaches to plan­ning 43
7.5.1 Top-down plan­ning 43
7.5.2 Bottom-up plan­ning 44
7.5.3 Agile plan­ning in the soft­ware industry 47
7.6 Planning strategies 49
7.7 Allowing for risk 51
8 Breakdown struc­tures 53
8.1 Definition of break­down struc­tures 53
8.2 Purpose of break­down struc­tures 53
8.3 Creating break­down struc­tures 53
8.3.1 Level 1 53
8.3.2 Level 2 53
8.3.3 Level 3 and beyond 55
8.4 Product break­down struc­ture (PBS) 57
8.4.1 What is a ‘product’ in plan­ning terms? 57
8.4.2 Definition of a PBS 57
8.4.3 Purpose of a PBS 57
8.4.4 Constructing a PBS 57
8.5 Work break­down struc­ture (WBS) 59
8.5.1 Definition of a WBS 59
8.5.2 Purpose of a WBS 59
8.5.3 Constructing a WBS 60
8.5.4 Principles of design­ing a WBS 60
8.5.5 WBS diction­ar­ies 61
8.6 Organisational break­down struc­ture (OBS) 64
8.6.1 Definition of an OBS 64
8.6.2 Purpose of an OBS 64
8.6.3 Constructing an OBS 65
8.7 Responsibility assign­ment matrix (RAM) 65
8.7.1 Definition of a RAM 65
8.7.2 Purpose of a RAM 65
8.7.3 Constructing a RAM 66
8.7.4 The step-­by-­step approach to construct­ing
a RAM 67

vii
Contents

8.8 RACI matrix 68

8.8.1 Definition of a RACI matrix 68
8.8.2 Purpose of a RACI matrix 68
8.8.3 Constructing a RACI matrix 68
8.9 Cost break­down struc­ture (CBS) 69
8.9.1 Definition of a CBS 69
8.9.2 Purpose of a CBS 69
8.10 Resources break­down struc­ture (RBS) 70
8.10.1 Definition of a RBS 70
8.10.2 Purpose of a RBS 71
9 Dependency manage­ment 73
9.1 Definition of depend­ency manage­ment 73
9.2 Purpose of depend­ency manage­ment 73
9.3 Interface scope 74
9.4 Schedule impact 74
10 Health, safety and envir­on­mental 75
10.1 HSE issues at stra­tegic level (plan­ning) 75
10.2 HSE issues at tactical level (schedul­ing and method state­ments) 76
11 Cost estim­at­ing 77
11.1 Definition of cost estim­at­ing 77
11.2 Purpose of a cost estim­ate 77
11.3 Cost estim­at­ing and the project life cycle 77
11.4 Estimate types 78
11.4.1 Scope devel­op­ment estim­ates 78
11.4.2 Other types of estim­ate 79
11.5 Contents of an estim­ate 80
11.6 Estimating meth­od­o­lo­gies 80
11.6.1 Approximate estim­at­ing methods 80
11.6.2 Definitive estim­at­ing methods 82
12 Budgeting 83
12.1 Definition of budget­ing 83
12.2 Purpose of budget­ing 83
12.3 Funding and budgets 83
12.4 Producing a cost budget 84
12.4.1 Cost breakdown struc­ture 84
12.4.2 Cash-flow state­ments 84
12.5 Budget trans­fers 87

viii
 Contents

Part Three: Scheduling 89

13 Introduction to schedul­ing 91
13.1 Definition of schedul­ing 91
13.2 Purpose of schedul­ing 91
13.3 The schedul­ing process 92
13.3.1 Steps in estab­lish­ing the sched­ule 92
13.3.2 Once the sched­ule is created 93
13.4 Schedule struc­ture 94
13.4.1 Sched­ule density 94
13.4.2 Detail density: consid­er­a­tions 98
13.4.3 Network templates (frag­nets) 99
14 Types of sched­ule 101
14.1 Schedule types: time-based 101
14.1.1 Development or stra­tegic sched­ule 101
14.1.2 Tender sched­ule (or ‘bid sched­ule’) 102
14.1.3 Contract sched­ule 102
14.1.4 Baseline sched­ule 103
14.1.5 Summary sched­ule 103
14.1.6 Working sched­ule or ‘fore­cast sched­ule’ 103
14.1.7 Target sched­ule 104
14.1.8 Short- and medium-term sched­ules 104
14.1.9 As-built sched­ule 105
14.1.10 Post-build sched­ule 106
14.1.11 ‘What ifs’ (scen­ario plan­ning) 107
14.2 Schedule types: tracker sched­ules 107
14.2.1 Procurement sched­ules 107
14.2.2 Design deliv­er­ables tracker 109
14.2.3 Other tracker sched­ules 109
15 Schedule design 113
15.1 Definition of sched­ule design 113
15.2 Purpose of sched­ule design 113
15.3 Elements of sched­ule design 113
15.3.1 Activity iden­tity numbers (IDs) 113
15.3.2 Activity descrip­tions 114
15.3.3 Different activ­ity types 115
15.3.4 Activity steps 116
15.3.5 Time units 118

ix
Contents

15.3.6 Calendars 118

15.3.7 Project, activity and resource coding 120
16 Building the sched­ule 121
16.1 Creating a crit­ical path network 121
16.1.1 Definition of crit­ical path method 121
16.1.2 Purpose of crit­ical path network 121
16.1.3 Methods of construct­ing a crit­ical path 122
16.1.4 Inputs into a crit­ical path analysis 123
16.1.5 Introduction to creat­ing a network analysis 124
16.1.6 Step 1: Create a logical network 125
16.1.7 Step 2: Forward pass 125
16.1.8 Step 3: Backward pass 126
16.1.9 Step 4: Calculation of total float 127
16.1.10 Step 5: Identification of crit­ical path 128
16.1.11 Training in network analysis: a note 130
16.1.12 Float 130
16.1.13 Types of logic linking 132
16.1.14 Lags and leads 135
16.1.15 Use of constraints 136
16.1.16 Types of constraints 138
16.1.17 Displaying networks on bar charts 147
16.2 Estimation of dura­tions 147
16.2.1 Three-point estim­ates 148
16.2.2 PERT (programme eval­ua­ tion review tech­nique) 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 exper­i­ence 150
16.2.8 Social media 151
16.3 Resourcing the sched­ule 151
16.3.1 Definition of resources 152
16.3.2 Purpose of resourcing the sched­ule 152
16.3.3 Process of resourcing the sched­ule 153
16.3.4 Resource smooth­ing 154
16.4 Horizontal and vertical integ­ra­tion of sched­ules 156
16.4.1 Horizontal integ­ra­tion 156
16.4.2 Vertical integ­ra­tion 157

x
 Contents

16.5 Scheduling interfaces and depend­en­cies 157

16.5.1 Identification 157
16.5.2 Coding 158
16.5.3 Integration and impact analysis 159
16.5.4 Impact resol­u­tion 163
16.6 Time contin­gen­cies 164
16.6.1 Definition of buffers 164
16.6.2 Use of buffers 164
17 Communicating the sched­ule 167
17.1 Bar charts 167
17.1.1 Presentation consid­er­a­tions 167
17.1.2 An alternative to bar chart report­ing 170
17.2 Line of balance 172
17.2.1 Creating a line of balance chart 172
17.2.2 Advantages of line of balance 173
17.2.3 Limitations of line of balance 174
17.3 Time chain­age 174
17.3.1 Definition of time chain­age charts 174
17.3.2 Explanation of the time chain­age tech­nique 175
17.3.3 Advantages of time chain­age 177
17.3.4 Limitations of time chain­age 177
17.4 Schedule narrat­ive 177
17.4.1 Scope 179
17.4.2 Health, safety and envir­on­mental
consid­er­a­tions 179
17.4.3 Risks, oppor­tun­it­ies and contin­gen­cies 179
17.4.4 Breakdown struc­tures 179
17.4.5 Project phasing 179
17.4.6 Stakeholders 179
17.4.7 Resources 179
17.4.8 Critical path(s) 180
17.4.9 Assumptions 180
17.4.10 Calendars 180
17.4.11 Activity codes 180
17.4.12 Details of any posses­sions, shut-downs or other
special working condi­tions 181
17.4.13 Consents required 181
17.4.14 Permits and licences 181

xi
Contents

18 Schedule review 183

18.1 Definition of sched­ule review 183
18.2 Purpose of sched­ule review 183
18.3 Checking the sched­ule 183
18.3.1 Understanding the project sched­ule 184
18.3.2 Components of the sched­ule 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 require­ments 188
18.4.4 Scope 189
18.4.5 Associated docu­ments 189
18.4.6 Planning issues 189
18.4.7 Progress update 190
18.4.8 Communication of the schedule 190
18.5 Scheduling checks 190
18.5.1 Activity checks 191
18.5.2 Logic checks 193
18.5.3 Float and crit­ical path checks 196
18.5.4 Resources checks 198
18.5.5 Review of sched­ule risk 198
19 BIM (Building inform­a­tion model­ling) 199
19.1 Definition of BIM 199
19.2 Purpose of BIM 200
19.3 BIM tech­no­logy 201
19.4 The BIM culture 201
20 Agile 203
20.1 Definition of agile 203
20.2 Purpose of agile 203
20.3 Methods 204
20.3.1 Advantages 205
20.3.2 Limitations 206

Part Four: Monitoring and control 207

21 Baseline 209
21.1 Definition of the project baseline 209

xii
 Contents

21.2 Purpose of a project baseline 211

21.3 Principles of project baselin­ing 211
21.4 When to set the baseline 212
21.5 Establishing the baseline sched­ule 212
21.6 Definition and purpose of baseline main­ten­ance 213
21.6.1 Definition of baseline main­ten­ance 213
21.6.2 Purpose of baseline main­ten­ance 213
21.6.3 Baseline main­ten­ance as a result of sched­ule changes 213
21.6.4 Illustration of the prin­ciple of baseline
main­ten­ance 214
21.7 Re-baselining: re-planning 216
21.7.1 When to consider re-planning 217
21.8 Re-baselining: re-programming 218
21.8.1 When to consider re-programming 218
21.9 Notes and rules for sched­ule main­ten­ance, re-planning and
re-baselining 220
21.10 The link between change manage­ment and the project
baseline 220
22 Performance report­ing 221
22.1 Definition of perform­ance report­ing 221
22.2 Purpose of perform­ance report­ing 222
22.3 Evaluating and record­ing progress 223
22.3.1 Progress assess­ment 223
22.3.2 What needs to be recor­ded in the sched­ule? 223
22.3.3 What else needs to be recor­ded in a report? 224
22.3.4 How often is progress recor­ded? 224
22.4 Variance analysis methods of progress monit­or­ing 224
22.4.1 Drop line method 224
22.4.2 Activity weeks method 226
22.4.3 Milestone monit­or­ing 228
22.4.4 Progress on a line of balance chart 229
22.4.5 Cash-flow monit­or­ing 230
22.4.6 Resource monit­or­ing 230
22.4.7 Cost value analysis 231
22.4.8 Quantity track­ing 231
22.5 Performance analysis methods of progress monit­or­ing 234
22.5.1 Network analysis and meas­ure­ment of float usage 234
22.5.2 Earned value analysis 235

xiii
Contents

23 Cost control 251

23.1 Definition of cost control 251
23.2 Purpose of cost control 251
23.3 The cost control process 252
23.3.1 Performance meas­ure­ment baseline (PMB) 252
23.3.2 The link between cost control and change control 252
23.3.3 Performance meas­ure­ment 253
23.4 Learning lessons from cost control 253
24 Short-term plan­ning 255
24.1 Definition of short-term plan­ning 255
24.2 Purpose of short-term plan­ning 255
24.3 The short-term plan­ning process 255
24.3.1 Make ready needs 257
24.3.2 Coordination meeting 257
24.3.3 Performance report­ing 257
25 Change manage­ment 259
25.1 Definition of change manage­ment 259
25.2 Purpose of change manage­ment 259
25.3 Principles of change manage­ment 260
25.4 Change control 260
25.4.1 Why change control is needed 260
25.4.2 Change control consid­er­a­tions 261
25.5 Project-level change: process over­view 261
25.6 Raising a change request 263
25.6.1 Drafting a change request 263
25.7 The change log 263
25.8 Initial eval­u­ation of the change request 264
25.9 Estimating impact of change 264
25.10 Detailed eval­ua­ tion of change request 264
25.10.1 Rejected request 265
25.10.2 Deferred request 265
25.11 Approved request 266
25.11.1 Change orders 266
25.11.2 Scope trans­fers 267
25.11.3 Schedule revi­sions 267
25.11.4 Corporate governance 267
25.12 Implementing the change 267
25.12.1 Adjusting sched­ule in line with change 268

xiv
 Contents

25.13 Communicating the change 269

25.14 Monthly change report­ing require­ments 269
25.14.1 Managing the sched­ule change process 271
26 Risk manage­ment 273
26.1 Definition of risk manage­ment 273
26.2 Purpose of risk manage­ment 273
26.3 Risk manage­ment plan 274
26.4 The risk manage­ment process 274
26.4.1 Planning 274
26.4.2 Risk iden­ti­fic­a­tion 276
26.4.3 Risk assess­ment 277
26.4.4 Risk response 280
26.4.5 Risk review 280
26.4.6 Risk report­ing 281
26.5 Risk draw down 281
26.5.1 When risks are mitig­ated 283
26.5.2 When risks are real­ised 283
26.5.3 When risks are closed 283
26.5.4 When oppor­tun­it­ies are real­ised 283
26.5.5 Documenting changes in the risk budget 284
26.6 Quantitative sched­ule risk analysis (QSRA) 284
26.6.1 Definition of QSRA 284
26.6.2 Purpose of QSRA 285
26.6.3 Key require­ments for a QSRA 286
26.6.4 The stages of sched­ule risk analysis 286
26.6.5 Distribution types 288
26.6.6 Application of risks to sched­ule activ­it­ies 291
26.6.7 QSRA output 292
26.6.8 Reporting 294
26.7 Quantitative cost risk analysis (QCRA) 296
26.7.1 Definition of QCRA 296
26.7.2 Purpose of QCRA 296
26.7.3 The QCRA process 297
27 Forensic analysis 303
27.1 Definition of forensic analysis 303
27.2 Purpose of forensic analysis 303
27.3 Methods of forensic analysis 303
27.3.1 As-planned versus as-built method (AP v AB) 304

xv
Contents

27.3.2 Impacted as-planned method (IAP) 305

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

Part Five: Record keeping and learn­ing 311

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

xvi
 Contents

The final word 329

Glossary 331
Acronyms 343
Index 345

xvii
 Figures and tables
Figures
1.1 The import­ance of plan­ning and control in project manage­ment 2
3.1 Types and rela­tion­ships of break­down struc­tures 23
4.1 Design and devel­op­ment V model 28
7.1 Top-down vs. bottom-up plan­ning 44
7.2 Rolling wave planning 46
7.3 Agile plan­ning 47
7.4 Setting early and late curves 50
7.5 Interpreting ‘S’ curves 51
8.1 Creating a break­down struc­ture level 1 54
8.2 Creating a break­down struc­ture level 2 54
8.3 Creating a break­down struc­ture level 3 55
8.4 Types and rela­tion­ships of break­down struc­tures repeated 56
8.5 Sample product break­down struc­ture 58
8.6 Work break­down struc­ture 59
8.7 Work break­down struc­ture diction­ary (defence) 62
8.8 Work package content sheet (construc­tion) 63
8.9 Organisation break­down struc­ture 64
8.10 Responsibility assign­ment matrix 66
8.11 Example of a RACI 69
8.12 Cost break­down struc­ture 70
11.1 Cost estim­at­ing process 78
12.1 Time meas­ured in finan­cial periods 85
12.2 Generating a cost fore­cast using a banana curve 86
13.1 The schedul­ing process in the context of plan­ning, monit­or­ing
and control 94
13.2 Relationship of differ­ent dens­it­ies in sched­ules 97
13.3 A hierarchy of plans and plan­ning docu­ments 98
14.1 Distorting the time/cost/quality triangle 105
14.2 Types of time-phased sched­ules and their rela­tion­ship 106
14.3 A sample procure­ment sched­ule 108
14.4 Time-phased procure­ment sched­ule 110

xviii
 Figures and tables

14.5 Design deliv­er­ables tracker 111

15.1 Establishing steps/object­ive criteria 117
15.2 Suitability for steps/object­ive criteria 117
16.1 Example of the preced­ence diagram method (PDM) 122
16.2 Example of the arrow diagram method (ADM) 123
16.3 Typical time analysis coding 124
16.4 Step 1: Create a logical network 125
16.5 Step 2: The forward pass calcu­la­tion 126
16.6 Step 3: The backward pass 127
16.7 Step 4: Calculation of total float 128
16.8 Step 5: Identification of crit­ical path 129
16.9 Longest path calcu­la­tions 129
16.10 The altern­at­ive method of calcu­la­tion in a network 130
16.11 Float types 131
16.12 Finish to start rela­tion­ship 133
16.13 Start to start rela­tion­ship 133
16.14 Finish to finish rela­tion­ship 134
16.15 Start to finish rela­tion­ship 135
16.16 Summary of types of logic and lags 136
16.17 ‘As late as possible’ constraint 138
16.18 ‘Finish on’ constraint 139
16.19 ‘Finish on or after’ constraint 140
16.20 ‘Finish on or before’ constraint 141
16.21 ‘Mandatory finish’ constraint 142
16.22 ‘Mandatory start’ constraint 143
16.23 ‘Start on’ constraint 144
16.24 ‘Start on or after’ constraint 145
16.25 ‘Start on or before’ constraint 146
16.26 Bar chart display 147
16.27 Establishing the dura­tion of a task based on resource 153
16.28 First draft resources profile 154
16.29 Resource-smoothed histo­gram 155
16.30 Resource-levelled chart with resource limit 156
16.31 Internal integ­ra­tion mile­stones 159
16.32 External integ­ra­tion mile­stones 160
16.33 Logic-linked depend­ency sched­ule 161
16.34 Dependency sched­ule driving project sched­ules 162
16.35 Different buffer types 165

xix
Figures and tables

17.1 A simple bar chart 168

17.2 Strategic sched­ule of a major construc­tion project at low density 169
17.3 Using mile­stones to give clarity to the sched­ule 171
17.4 Creating a line of balance chart 172
17.5 Optimising work flow in line of balance 173
17.6 Basic elements of a time chain­age chart 174
17.7 Time chain­age task 1 175
17.8 Time chain­age tasks 2 and 3 176
17.9 Time chain­age task 4 176
17.10 Time chain­age sequen­cing 177
17.11 Example of a time chain­age diagram for a new railway 178
18.1 Components of a sched­ule for review 185
18.2 Logic bottle­neck 196
19.1 BIM level matur­ity map 200
20.1 Agile processes 204
20.2 Illustration of an agile meth­od­o­logy using ‘scrums’ and ‘sprints’ 205
21.1 Establishment of baseline 210
21.2 Baseline after work starts 210
21.3 Baseline main­ten­ance step 1 214
21.4 Baseline main­ten­ance step 2 215
21.5 Baseline main­ten­ance step 3 216
21.6 Baseline main­ten­ance step 4 217
22.1 Illustration of the drop line method 225
22.2 Simple ‘activ­ity weeks’ monit­or­ing chart 226
22.3 Cumulative results from the ‘activ­ity weeks’ chart 227
22.4 Recording actual progress in line of balance 229
22.5 Sample cost value report 232
22.6 Quantity track­ing with produc­tion curves 233
22.7 Budget alloc­a­tion 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 sched­ule vari­ance 242
22.12 Cost and sched­ule vari­ance chart 243
22.13 Earned value analysis with time vari­ance 244
22.14 Bull’s eye perform­ance chart 245
22.15 Calculating estim­ated time to comple­tion 246
22.16 Illustration of various earning tech­niques and appro­pri­ate uses 247

xx
 Figures and tables

22.17 Advantages and disad­vant­ages of EVTs 248

24.1 Short-term sched­ules in context of other plans 256
24.2 Performance analysis on short-term sched­ule 258
25.1 Process over­view: project change control 262
25.2 Example of monthly change report­ing 270
25.3 Monthly change report 270
26.1 Risk manage­ment life cycle 275
26.2 Risk iden­ti­fic­a­tion in a typical risk log 277
26.3 Risk assess­ment matrix: sever­ity ratings score 278
26.4 Opportunity assess­ment matrix: sever­ity ratings score 278
26.5 Typical risk log contin­ued, showing current impact and
response plan­ning 279
26.6 Risk response options 280
26.7 Reporting of basic risk data 281
26.8 Tracking risk perform­ance over time 282
26.9 Normal distri­bu­tion curve 288
26.10 Log normal distri­bu­tion curve 289
26.11 Uniform distri­bu­tion 289
26.12 Triangular distri­bu­tion: possible options 290
26.13 PERT distri­bu­tion 291
26.14 Duration uncer­tainty prob­ab­il­ity chart 293
26.15 Duration uncer­tainty tornado chart 294
26.16 QSRA prob­ab­il­ity distri­bu­tion chart 295
26.17 Full QSRA tornado chart 296
26.18 QCRA chart 299
26.19 QCRA chart (redraw) 300
30.1 Context of handover and clos­eout 320
31.1 Example proforma to collect output rates 326

Tables
2.1 Examples of require­ments and accept­ance criteria 17
6.1 Sources of project inform­a­tion 33
8.1 Explanation of RACI codes 68
12.1 A simple cost budget 84
13.1 Features asso­ci­ated with density of sched­ules 95
15.1 Example of activ­ity descrip­tions 114
16.1 Example of three-point estim­ate 148

xxi
Figures and tables

16.2 Example of PERT calcu­la­tion 148

16.3 Example of compar­at­ive estim­ates 149
16.4 Example of bench­marked data 149
16.5 Example of resource-depend­ent estim­ate 150
16.6 Interface impact sched­ule 163
21.1 Baseline main­ten­ance, re-planning, re-baselining matrix 219
22.1 Measurement of float usage 234
25.1 Example of finan­cial author­ity 267
26.1 QCRA confid­ence levels 301
27.1 As-planned vs. as-built method 304
27.2 Impacted as-planned method 305
27.3 Collapsed as-built method or as-built but for 306
27.4 Time impact analysis method 307

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

xxii
‘Planning is an unnat­ural process; it is much more fun to do
some­thing. The nicest thing about not plan­ning is that failure comes
as a complete surprise, rather than being preceded by a period of
worry and depres­sion.’
Sir John Harvey Jones
 Foreword

Planning has been part of my life for so many years now. I trained as a mech­an­ical
engin­eer, and the last assign­ment of my appren­tice­ship was within the construc­
tion plan­ning depart­ment of British Steel’s piping divi­sion (1974 is a long time ago
now, unfor­tu­nately!). That exper­i­ence captured my imagin­a­tion and I decided to
embark on a career as a plan­ning engin­eer. My many exper­i­ences since have
taught me how vitally import­ant it is to plan how a project, programme, port­fo­lio
or busi­ness will be delivered.
Sir John Harvey Jones’ quote ‘The nicest thing about not plan­ning is that failure
comes as a complete surprise, rather than being preceded by a period of worry
and depres­sion’ reveals a culture still buried deep within many organ­isa­tions’ and
indi­vidu­als’ approach to project or busi­ness deliv­ery today. However, when you
have been involved in the ‘complete surprise’ you realise that if the team involved
had opted for the ‘worry and depres­sion’ this would have promp­ted action and
led to a more success­ful outcome.
Fortunately, my involve­ment in success­fully delivered projects or programmes
far outweighs my failing project exper­i­ences, and, when looking back, success
usually comes down to good defin­i­tion, prepar­a­tion and plan­ning from incep­tion
onwards. The Kuwait recon­struc­tion (1991/1992) and London 2012 Olympic
(2008 to 2012) programmes were two big high­lights in my career, where the
chal­lenge was to achieve deliv­ery within very clearly defined times­cales under
the highest possible level of public scru­tiny.
For these programmes, the creation and main­ten­ance of an integ­rated suite of
plans/sched­ules allow­ing project/programme-level decision making to be
effect­ive was a key part of the deliv­ery success which both comment­at­ors at the
time and histor­i­ans since have recor­ded.
Now, as a result of the consid­er­able efforts of the APM Planning, Monitoring
and Control (PMC) Specific Interest Group (SIG), organ­isa­tions and programme/
project teams will have a guide cover­ing all aspects of plan­ning, from prepar­ing
to under­take a project to execut­ing that project, controlling its safe deliv­ery to
budget, time and quality.

xxiv
 Foreword

I believe that this public­a­tion has captured the best prac­tices for plan­ning and
will become the refer­ence docu­ment of note for organ­isa­tions and their teams
during future project deliv­er­ies.

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

xxv
 Preface

Sir John Harvey Jones said that ‘Planning is an unnat­ural process . . .’ and we all love
this quote, as it says some­thing that we recog­nise about human nature. In this guide
we contend that plan­ning is partly a process, a ‘science’ if you like. But there is also
an art to plan­ning, one which requires good ideas, exper­i­ence, deep thought and
creat­ive think­ing, partic­u­larly around busi­ness plan­ning, consid­er­a­tion of options
and choos­ing meth­od­o­lo­gies. This book discusses the art of plan­ning, but places an
emphasis on the scientific side of plan­ning – the processes of schedul­ing, risk
analysis, manage­ment of change (and so on) – in what we hope is a prac­tical manner.
The guide was conceived after the form­a­tion of the Planning, Monitoring and
Control (PMC) Specific Interest Group (SIG) in late 2010 to fill a gap in published
APM know­ledge. It was inten­ded to cover all plan­ning aspects of prepar­ing to
under­take a project, execut­ing a project, controlling its deliv­ery to budget, time
and quality, and deliv­er­ing it safely. The guide was to be about plan­ning in the
widest sense of the word. Just as with the form­a­tion of the PMC SIG, its aim has
been to bring together differ­ent project special­isms, rather than focus on a
partic­u­lar area of special­ist know­ledge.
After much discus­sion and debate, a basic struc­ture for the guide was agreed
upon, and content started to be written. By late 2013 a large amount of mater­ial
had been gathered but momentum had flagged, so a sub-committee of the SIG
was formed to pull together all the mater­ial and fill the gaps that inev­it­ably still
existed at that point. An intense period of writing and re-writing, as indi­vidu­als
and as a group, followed.

Reading this book

We have covered a lot of mater­ial in this book and realise that it may look a
daunt­ing read – but it has been written as a refer­ence guide to dip into, so we
have provided a compre­hens­ive contents and index that will, we hope, assist in
navig­at­ ion through the book.
We have tried to write this guide in plain English as far as we possibly could,
adopt­ing the ‘Emily test’ to chal­lenge ourselves whenever we slipped into

xxvi
 Preface

‘manage­ment speak’ or other preten­tious 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 daugh­ter, who chal­lenged such language when being
subjec­ted to the drafts of this guide for bed-time reading!)
This book has been written entirely by volun­teers, giving their own and their
employ­ers’ time freely and will­ingly for the purpose of advan­cing and dissemi­
nating know­ledge. The effort and time given by the group were well beyond the
call of duty, and I cannot express my grat­it­ude for the amount of time that already
busy indi­vidu­als were prepared to put into writing and illus­trat­ing the guide.
This book may not be perfect – there surely remains work to be done to make
it so – but we have reached the point where this group has done its best, and we
look to the project manage­ment community to provide the feed­back and
expert­ise to strengthen the guide in what we hope will be future editions in years
to come.

Paul Kidston
Lead author
June 2014

xxvii
 Acknowledgements

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

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

In addi­tion, signi­fic­ant contri­bu­tions were made by the follow­ing members of the

PMC SIG:

Mike Prescott (Head of project control management,

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

Significant contri­bu­tions from outside the SIG were made by:

Franco Pittoni (Technical director – BIM & Project Controls,

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

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

xxviii
 Acknowledgements

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

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

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

xxix
 Peer review

The guide was widely peer reviewed by people with a wide range of exper­i­ence
from outside the SIG, and we are grate­ful to the follow­ing, who provided signi­
fic­ant comments and sugges­tions:
From the Rhead group, Pete Mill, Steve Highfield, John Nixon and Robin
Smoult; Ben Whitlock (Babcock International Group); James Manthorpe, Louise
Arrowsmith and Sarah Cummins, all of Taylor Woodrow. From the Cross Industry
Planning and Project Controls (CIPPC) group, Mark Singleton (Balfour Beatty
Construction Services UK), Franco Pittoni (Parsons Brinkerhoff) and Phil Budden
(Costain) all provided useful sugges­tions.

xxx
 Purpose

The content of this docu­ment iden­ti­fies the scope of plan­ning know­ledge as

under­stood by the Association for Project Management (APM) Planning,
Monitoring and Control (PMC) Specific Interest Group (SIG). This know­ledge
was compiled and discussed in a series of working sessions and reviews
commen­cing in October 2010 and conclud­ing, for public­a­tion purposes, in July
2014.
It provides refer­ence guid­ance for prac­ti­tion­ers and students along with the
study mater­ial required for the forth­com­ing Foundation exam.
This guide covers many topics, but does not attempt to super­sede many other
notable APM public­a­tions; it is hoped that we have achieved a prac­tical guide
that sits along­side them, in partic­u­lar:

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 fore­run­ner of the PMC SIG – the Planning
SIG, which did what its title sugges­ted and provided an intro­duc­tion and a
mani­festo for project plan­ning. Although that book explains the need for plan­ning,
this hand­book is inten­ded to be the prac­tical guide to best prac­tice in plan­ning.
This guide has been written totally by volun­teers. We would welcome any
construct­ive feed­back that may be used in improv­ing future editions of this
guide, which we hope will follow and build on this start­ing point.

Note
Within this guide, text high­lighted in blue means that the term thus high­lighted is
referred to in the gloss­ary.

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

Overview

Effective project manage­ment requires effect­ive plan­ning and control. Effective

plan­ning and control requires:

• the clear defin­i­tion of the project;

• a robust approach to plan­ning the project;
• selec­tion and use of the appro­pri­ate schedul­ing tech­niques;
• rigor­ous monit­or­ing that enables proact­ive control of the project;
• a sound basis for this is good record keeping, which also facil­it­ates the virtu­ous
feed­back and learn­ing cycle.

This book offers tried and tested tech­niques and prin­ciples cover­ing these aspects
of project manage­ment. It intro­duces some lesser-known and emer­ging prac­tices,
some of which will move into main­stream project manage­ment in the years
to come.
The book is struc­tured into five main sections reflect­ing these require­ments,
and a brief intro­duc­tion to each section and chapter follows.

1.1 Part One: Definition

At a stra­tegic level, there are a number of funda­mental ques­tions that need
address­ing:

• Why is the project required?

• What does the customer want the project to deliver?
• How will the success of the project be meas­ured?
• How will the project be procured?
• What is the atti­tude of its custom­ers (or its funders) to risk?
• Similarly, what is their atti­tude to quality (includ­ing scope)?
• When does the client want the capab­il­ity delivered by?

Part One of this guide describes the prin­cipal processes that define the project,
and answers these ques­tions.

1
Planning, Scheduling, Monitoring and Control

The first topic dealt with is the creation of the busi­ness case (Chapter 2). This
is the start­ing point in the life of any project, and it is a vital step in ensur­ing that
the project is viable, afford­able and desir­able. It sets the scene for all that follows
– the plan­ning, schedul­ing, monit­or­ing and control, and, not least, the deliv­ery of
the project.
Assuming the busi­ness case is approved, the scope of the project must be
defined and agreed with all stake­hold­ers (Chapter 3). Defining the scope will
begin the process of making key decisions about the project, defin­ing and
select­ing from various options until a preferred solu­tion is agreed and approved.
Once the scope has been agreed, the details of the require­ments are
determ­ined. See Chapter 4 (Requirements management).
Stakeholder manage­ment (Chapter 5) is dealt with briefly, as the respons­ib­il­ity
for this falls mainly on the project manager (see Soft Issues – Project Management
Time in Figure 1.1).
Chapter 6, the final chapter in Part One (Project familiarisation), is a check­list
of the project docu­ment­a­tion that has been created during the defin­i­tion stage.
These are the key docu­ments that must be read and under­stood to enable the
plan­ning – and subsequent processes detailed in the guide – to be carried out in
an informed way.

Figure 1.1 The import­ance of plan­ning and control in project manage­ment

1.2 Part Two: Planning

The plan­ning phase of the project needs to answer some funda­mental ques­tions,
such as:

2
 Overview

• How much will the project cost?

• How long should the project take?
• Are there bene­fits to finish­ing early, and what are they?
• What are the costs of an earlier comple­tion, and do they outweigh the bene­fits?
• On the other hand, how is funding released, and are there any limits on this?
• How will the perform­ance of the project be meas­ured, through all its phases?
• Can the project be delivered safely?

Chapter 7 intro­duces plan­ning – the team approach to working out how to deliver
the project. After discuss­ing and defin­ing the differ­ence between plan­ning and
schedul­ing (a point worth making to help define the two terms) – these terms
are often used inter­change­ably, but they are two very differ­ent processes and
require differ­ent skill sets – the opening chapter of this section goes on to discuss
the prin­cipal compon­ents that will make up the overall project plan – the various
sched­ules and narrat­ives. It is import­ant to under­stand these at the plan­ning
stage, and, whilst they are intro­duced here, they will be covered in further detail
in Part Four.
Chapter 8 defines and discusses the purpose of the various break­down
struc­tures that are used in project manage­ment. We also propose a method of
creat­ing these struc­tures. Chapter 9 intro­duces the concept of depend­ency
manage­ment. This theme is returned to in Part Four, when the specif­ics of
sched­ule depend­en­cies are defined in greater detail.
A crit­ical concern of all project manage­ment must be the highest stand­ards of
health, safety and envir­on­mental manage­ment (Chapter 10). We cannot do
justice to this topic in a book aimed across all indus­tries, but it is a very import­ant
aspect when plan­ning any project. It will have a funda­mental influ­ence on the
project – how it is planned, designed/engin­eered and construc­ted.
Finally, in Chapters 11 and 12, we discuss the cost-estimating process and the
budget­ing process that follows it. The former is an essen­tial step in the defin­i­tion
and plan­ning (and, indeed, schedul­ing) of the project. The latter is essen­tial in the
creation of targets and baselines that will form the basis of monit­or­ing and control.

1.3 Part Three: Scheduling

A funda­mental ques­tion is: who owns the sched­ule? The answer is, of course,
that it is the project manager, with the support of the whole project team. The
sched­ule is created by collat­ing the thoughts of many people; the special­ist

3
Planning, Scheduling, Monitoring and Control

planner’s role is to form these thoughts into a coher­ent sched­ule, and then to
commu­nic­ate it effect­ively. This will include:

• devel­op­ing logist­ical plans;

• setting up the sched­ule in plan­ning soft­ware;
• decid­ing how the plan is to be presen­ted and commu­nic­ated.

Part Three commences with a chapter (13) setting the scene; it discusses the
purposes of schedul­ing and some of the basic philo­sophies and struc­tures.
Chapter 14 describes the various types and purposes of sched­ules that might be
used on a project.
Chapter 15, entitled Schedule design, details the various elements of a
sched­ule that need to be considered prior to commence­ment of any schedul­ing:
for example, what type of activ­ity should be used, or what coding and other
struc­tures should be applied.
Chapter 16 addresses the construc­tion of the sched­ule. It is this guide’s
conten­tion that all schedul­ing starts with the creation of a logic-linked network.
On simple projects a bar (or Gantt) chart may suffice, but we have chosen to
describe these as outputs, or commu­nic­a­tion tools, rather than schedul­ing tools
in their own right. We believe this is consist­ent with current prac­tice. Within this
chapter we discuss not only networks but also how dura­tions may be calcu­lated,
the import­ance of consid­er­ing and schedul­ing resources, and how sched­ules are
inter­faced with other stake­hold­ers.
Chapter 17 follows with a number of sugges­tions about how the sched­ule is
commu­nic­ated – from the afore­men­tioned bar charts through to line of balance
and time chain­age charts that are useful in partic­ul­ar circum­stances. One very
import­ant and some­times over­looked docu­ment is the sched­ule narrat­ive. This
docu­ment serves to explain and clarify the plan­ning and schedul­ing effort that
has resul­ted in the (suite of) sched­ule(s) that have been created. Without this,
the project cannot be clearly under­stood. We suggest appro­pri­ate contents for
this narrat­ive.
The final part of the generic process is sched­ule review (Chapter 18), describ­ing
the basic and detailed checks that should be made on the plans and sched­ules.
Turning once again to the ques­tion of who owns the programme, the final
two chapters of this part (Chapters 19 and 20) deal with two emer­ging prac­tices
that have an import­ant part to play in sharing the plan­ning and the sched­ule
with the project team: the agile approach, used mainly in soft­ware devel­op­ment,
and the build­ing inform­a­tion model­ling (BIM) approach for use in asset design,

4
 Overview

construc­tion and manage­ment. The latter is mandated for use in all govern­ment
procure­ment activ­ity from 2016, so it is very likely to grow in signi­fic­ance over the
coming years.

1.4 Part Four: Monitoring and control

Once the project is in its deliv­ery phase, there are four funda­mental ques­tions
that project stake­hold­ers will ask of the project manager:

• Where are we?

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

The first ques­tion (Where are we?) may be decom­posed into further ques­tions
such as: Are we on sched­ule? If not, where have the delays occurred? What
caused the delay? Who is respons­ible, and what effect will it have on the project?
Finally, what can be done to recover?
The second ques­tion (What has it cost to get here?) may also be broken down
into similar ques­tions: Where and why did any over or under spend occur? Who
is respons­ible and how will we recover?
The ques­tion ‘Where are we going?’ may be considered in terms of time
(When are we going to finish?), cost (What is it going to finally cost?) and quality
(Will the finished product do what we inten­ded?). The analysis of current trends
will enable fore­cast­ing and/or chal­lenge on these matters.
The fourth and final ques­tion (How can we correct any prob­lems?) also
requires project-specific exper­i­ence and very often innov­at­ive think­ing, topics
that this guide does not, indeed cannot, cover. The monit­or­ing and control
process provides the basis for asking the right ques­tions, and perhaps the basis
for answer­ing them.
The chapter on baselines (Chapter 21) could be a section in its own right, as it
is the pivot between the plan­ning and schedul­ing effort and the processes of
monit­or­ing and control. It is, however, a useful intro­duc­tion to perform­ance
manage­ment, and touches on issues of change and other forms of control that
are dealt with later in this part of the book.
Performance report­ing (Chapter 22) covers the collec­tion of progress and cost
inform­a­tion and how this is turned into useful manage­ment data. Various

5
Planning, Scheduling, Monitoring and Control

report­ing tech­niques are discussed: first, vari­ance reports that simply measure
differ­ences, expos­ing them (hope­fully) to poten­tial manage­ment action; second,
a category that we have called ‘perform­ance analysis methods’ that includes
poten­tially the most valu­able report­ing of all, earned value analysis. As stated in
the earlier purpose section of this guide, this book does not super­sede the APM’s
own Earned Value Handbook, and readers with a further interest in this subject
should refer to that guide. However, this guide does cover the basic prin­ciples of
earned value.
Cost control is given its own chapter (Chapter 23), and, although it is covered
with some brevity, the funda­mental prin­ciples are discussed.
After the project has started, the project needs to react to progress made and
re-plan as neces­sary. This is often the driver of short-term plan­ning (although
break­ing plans into greater levels of detail (or ‘dens­it­ies’) is also a func­tion of
this). In Chapter 24, we outline this process.
Chapters 25 and 26 discuss two processes that will actu­ally be active
through­out the whole life of the project. The former discusses change
manage­ment, and the latter gives an over­view of risk manage­ment. This chapter
provides details of the QSRA and QCRA processes, which are the quant­it­at­ive
analyses of sched­ule and cost, respect­ively (hence the acronyms). These are tools
that check the initial and ongoing robust­ness of the project plans.
The last chapter in Part Four (Chapter 27) discusses forensic analysis and delay
and disrup­tion analysis.

1.5 Part Five: Record keeping and learn­ing

Record keeping (Chapter 28) is vital to provide a compre­hens­ive history of the
project. It forms both the basis of updat­ing the sched­ules and plans for perform­
ance report­ing, and to enable forensic analysis should it be neces­sary. It provides
the basis of much of the learn­ing from the project that can be used to improve
future projects. Document manage­ment (Chapter 29) ensures that this and all
other relev­ant project inform­a­tion is avail­able to those who need it.
The closely allied (but separ­ate) processes of handover and clos­eout of the
project are dealt with in Chapter 30. The handover process ensures that the
project and its oblig­a­tions are complete and signed off; closeout essen­tially closes
down all the support struc­tures and commer­cial settle­ment of the project.
The final chapter of the book deals with another process that exists through­out
the life of the project: lessons learned (Chapter 31). This includes both hard and

6
 Overview

soft data. An example of the former would be productiv­ity outputs achieved; an

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

1.6 A note on the Contents, Index and

Glossary
We have included compre­hens­ive contents and index to facil­it­ate easy
refer­­­en­cing through­out the book. This is in keeping with the belief that this is a
guide to dip into rather than read cover to cover (although the reader is welcome
to try!). Cross refer­en­cing in the book is kept to a minimum, and as a result there
is a small amount of repe­ti­tion, but in general a famili­ar­ity with the struc­ture of the
book will aid navig­a­tion through it. As stated in the preface, we have tried to only
use plain English in this guide. However, when writing about tech­nical subjects,
there are always going to be words used that the reader is not famil­iar with. In
these instances we have high­lighted the word in blue, and added a defin­i­tion in
the gloss­ary.

1.7 Management issues

There are many other factors that an organ­isa­tion needs to consider that cannot
be covered by this guide, but are funda­mental to success­ful deliv­ery of projects;
these include:

1.7.1 Behaviour and resources

The beha­viours within the organ­isa­tion must allow proper recog­ni­tion, time
and resource to allow the plan­ning and control processes to happen. Making sure
that there is a devel­op­ment route for project teams such that the organ­isa­tion/
project has suit­ably qual­i­fied and exper­i­enced people is simil­arly import­ant.

1.7.2 Processes and tools (scheduling software)

Each organ­isa­tion must set down its own plan­ning and schedul­ing processes. As
with all processes, making sure that plan­ning and control processes are audited
to check for appro­pri­ate imple­ment­a­tion is import­ant. Processes must be robust

7
Planning, Scheduling, Monitoring and Control

enough to deliver the project effi­ciently, but scaled to suit the size and complex­ity
of the project as appro­pri­ate.
Some research and effort are required to ensure that the tools used and their
config­ur­a­tion are suit­able for the organ­isa­tion or project and the team who will be
using them. In some industry sectors a big consid­er­a­tion will be client expect­a­
tions, and this cannot be ignored.

1.7.3 Common sense

The most import­ant piece of advice of all is to make sure that the guid­ance in this
book is inter­preted with common sense. Any action or process that is estab­lished
must be appro­pri­ate and must show a benefit that outweighs the cost of its imple­
ment­a­tion. This cost is not just in finan­cial terms, but also in the use of the avail­able
time of the team. Projects of differ­ing complex­ity will require differ­ent imple­
ment­a­tions: the highly complex and risky project will require some­thing close to
everything in this guide! A simple project will only need to apply the prin­ciples,
often in a very informal way. It is up to the skill and judge­ment of the organ­isa­
tion’s senior manage­ment to determ­ine what is relev­ant.

8
 Part One

Definition

‘The begin­ning of wisdom is the defin­i­tion of terms.’

Socrates
2.1 Definition of the busi­ness case
The busi­ness case provides the justi­fic­a­tion for under­tak­ing a project, in terms of
eval­u­at­ing the benefit, cost and risk of altern­at­ive options and rationale for the
preferred solu­tion. Its purpose is to obtain manage­ment commit­ment and
approval for invest­ment in the project.
The busi­ness case summar­ises the ‘why’ of the project and should be reviewed
at the start of each project life cycle stage in order to confirm that the project is
achiev­ing its object­ives. This is to test the ongoing viab­il­ity of a project before
proceed­ing into the next phase of work. It should be read along­side the project
brief (to under­stand ‘what’ is being delivered), and the project execu­tion plan
(PEP) (to under­stand ‘how’ the project will be delivered). Alternatively, the
busi­ness case may determ­ine that the project is not viable and should not
proceed. The busi­ness case is owned by the project sponsor.

2.2 Purpose of a busi­ness case

The purpose of gener­at­ing a busi­ness case is to make the case for a partic­u­lar
project to proceed, and to define and valid­ate, in broad terms, the constraints
within which it may be delivered. In some cases the outcome of the busi­ness case
may be that the proposed project does not proceed. A key part of the busi­ness
case is the commu­nic­a­tion of the resources, commer­cial strategy and capital
invest­ment neces­sary to realise the busi­ness bene­fits that the project is due to
deliver.

11
Planning, Scheduling, Monitoring and Control

2.3 Contents of the busi­ness case

2.3.1 Structure of the busi­ness case
2.3.1.1 Executive summary
This brief intro­duc­tion to the busi­ness case will contain at least the follow­ing
sections:

• descrip­tion of project scope;

• key reasons for proceed­ing with the project;
• conclu­sions of cost/benefit study;
• recom­men­ded option (assum­ing a number of options are avail­able);
• outputs: list of key deliv­er­ables.

2.3.1.2 Strategic case

This key section describes to the spon­sors/stake­hold­ers why the project is
required. It covers the details of the issues to be addressed, or the oppor­tun­ity
that has arisen.

2.3.1.3 Economic options

There are gener­ally three finan­cial aspects to be addressed when consid­er­ing a
new project:

• busi­ness as usual: no project to invest in;

• mission crit­ical: deliver abso­lute minimum of bene­fits to solve the problem;
• compre­hens­ive change: a decision that will lead to a fully scoped project (or
projects in the case of a change programme).

Each of the economic options must be appraised in terms of costs, bene­fits, risks
and oppor­tun­it­ies. Having considered the options, this section should then
clearly present the recom­men­ded option to the spon­sors/stake­hold­ers.

2.3.1.4 Benefits: advant­ages of under­tak­ing the project

The bene­fits of under­tak­ing the project must be made clear. These may include:

12
 Business case

• return on invest­ment;
• improved productiv­ity;
• lower main­ten­ance costs;
• safer oper­a­tions;
• provid­ing essen­tial services;
• train­ing for increased productiv­ity;
• enhanced customer exper­i­ence.

Making the bene­fits SMART (specific, meas­ur­able, achiev­able, relev­ant, time-

bound) will facil­it­ate decision making and, in time, assist with the bene­fits real­isa­
tion analysis.

2.3.1.5 Compromises: disad­vant­ages of under­tak­ing

the project
The comprom­ises that will be required whilst under­tak­ing the project must be
made clear. These may include:

• disrup­tion to the organ­isa­tion or other stake­hold­ers whilst the project is

under­taken;
• drop in productiv­ity;
• capital expendit­ure required and/or finan­cing costs.

Dis-benefits should be analysed as part of the invest­ment appraisal to ensure that

they do not outweigh the expec­ted bene­fits of the project.
As with the bene­fits, the comprom­ises that the organ­isa­tion will have to make
will need to be trans­lated into SMART object­ives to aid the decision-making
process.

2.3.1.6 Timescale
Different parts of the busi­ness case are emphas­ised at differ­ent life cycle stages:

• initi­ation stage: consider the differ­ent options and include a summary of each
option;
• plan­ning stage: the case must be made for the preferred option, with detailed
costs and bene­fits for each to clearly show why the preferred option is
recom­men­ded;

13
Planning, Scheduling, Monitoring and Control

• execu­tion stage: the project progress is compared with the busi­ness case to
ensure that the project contin­ues to deliver the expec­ted bene­fits, and for an
accept­able cost;
• clos­eout/handover: compar­ison between the project outcome and that
defined in the busi­ness case. Have the defined bene­fits of the project been
achieved, or are they going to be achieved?

However, the two key stages are the time over which the project will be run and
the period over which the bene­fits will be real­ised. The former is required to
under­stand cash-flow fore­cast­ing, periods of disrup­tion etc., and the latter to
facil­it­ate the cost/benefit analysis.

2.3.1.7 Cost and perform­ance analysis

This section contains a compar­ison of the bene­fits and dis-benefits compared
with the risks and costs of the project, along with any ongoing oper­a­tional or
main­ten­ance costs.
Financial commit­ment across the whole project life cycle needs to be analysed.
This includes:

• project cost, includ­ing cash-flow fore­casts;

• ongoing oper­a­tions and main­ten­ance costs;
• life cycle revenue;
• one-off and ongoing cost savings;
• value of bene­fits.

Anything that deliv­ers more savings than it costs will produce a posit­ive net
finan­cial effect, and this should be quoted with the relev­ant back-up data.

2.3.1.8 Resources
Ideally, projects should be possible to carry out using exist­ing resources.
Where there are insuf­fic­ ient internal resources to deliver the project, propos­als
must be made to either recruit addi­tional, or acquire external, resources to
complete the work. This aspect can clearly have a major impact on the viab­il­ity
of a project.

14
 Business case

2.3.1.9 Risks and oppor­tun­it­ies

Although this is not the main loca­tion for commu­nic­at­ing or managing risk and
oppor­tun­ity, it should summar­ise the impact on value for money and decision
making. It should include:

• a summary of major risks iden­ti­fied with the project and their likely impact,
includ­ing any mitig­a­tion plans;
• the finan­cial provi­sion for risk, includ­ing the method for its eval­u­ation;
• the finan­cial bene­fits of real­ising oppor­tun­it­ies, includ­ing the method for their
eval­u­ation.

Risks and oppor­tun­it­ies considered in this section should include risks to cost,
time, health and safety, the envir­on­ment, repu­ta­tional damage, the effects on
third parties and so on, as is relev­ant to the partic­u­lar sector or organ­isa­tion.
If the project is considered too risky, then the project sponsor may decide to
not proceed.

2.3.2 Planning information

Planning inform­a­tion is funda­mental in inform­ing and valid­at­ing the busi­ness
case, in partic­ul­ar:

2.3.2.1 Strategic fit within the busi­ness

The plan should demon­strate how the project aligns with the busi­ness strategy.
This will high­light poten­tial rela­tion­ships with other projects, programmes or
port­fo­lios within the busi­ness or extern­ally.
Visibility of the bigger picture could identify constraints or issues asso­ci­ated
with resource avail­ab­il­ity, mater­i­als or funds. Just as large national projects like
the build­ing of new nuclear power stations, or upgrad­ing the UK rail network,
can gener­ate short­ages within the resource market, the same can happen with
the company’s internal resources.

2.3.2.2 Time assump­tions

Time assump­tions may be based on bench­mark data from similar projects,
or learn­ing from exper­i­ence. There may be time constraints around funding

15
Planning, Scheduling, Monitoring and Control

avail­ab­il­ity that may factor into the busi­ness case, such as the ability to
expend money, or other constraints, such as the avail­ab­il­ity of key resources.
In addi­tion, inform­a­tion for inclu­sion in the busi­ness case, such as resource
histo­grams or high-level sched­ules, should be provided.

2.3.3 Funding requirements

The busi­ness case may need to stip­u­late when further funding needs to
be approved – possibly at a key mile­stone or gateway during the project
life cycle.
The spend profile of the capital costs may need to be gener­ated from the
stra­tegic sched­ule. This would enable the project cash-flow to be determ­ined in
line with the key phases or mile­stones of the project. In most organ­isa­tions,
annual spend profiles are import­ant for managing the busi­ness. This will be used
as part of the finan­cial plan­ning of the organ­isa­tion.
The busi­ness case should be reviewed regu­larly until such time as the project
is ‘brought into use’.

2.3.4 Resource requirements

The quant­ity of resources required and the avail­ab­il­ity of these resources is
a key factor in determ­in­ing the viab­il­ity of under­tak­ing the project. The
capa­city to under­take the project intern­ally or the procure­ment of external
resources must be determ­ined and appro­pri­ate options high­lighted in the
busi­ness case.

2.4 Acceptance criteria in the busi­ness case

Acceptance criteria define how the require­ments will be demon­strated to the
customer to determ­ine whether the project is complete. All project outputs must
be delivered fit for purpose, to the stand­ards and specific­a­tion outlined in the
require­ments.
Examples of accept­ance criteria:

16
 Business case

Table 2.1 Examples of require­ments and accept­ance criteria

Requirement Acceptance criteria

Higher productiv­ity 30% increase in manu­fac­tur­ing output within 3 months

Reduced main­ten­ance Planned prevent­at­ive main­ten­ance systems avail­able

within 1 month

Increased oper­a­tional resi­li­ence Back-up systems online

The busi­ness case may contain a summary list of key project mile­stones relev­ant
to stake­hold­ers (accept­ance events).

2.5 Benefits real­isa­tion in the busi­ness case

Project success is partially the achieve­ment of require­ments and is meas­ured by
meeting the accept­ance criteria as iden­ti­fied and agreed in the busi­ness case.
However, it is possible to have a success­fully delivered project that fails to deliver
expec­ted bene­fits, or a project that deliv­ers signi­fic­ant bene­fits but is considered
a failure.
Achievement of project require­ments and end-user bene­fits needs to be
considered together, because it is the creation and use of deliv­er­ables that
produces bene­fits. For this reason, benefit real­isa­tion meas­ures should be
iden­ti­fied and baseline data should be collec­ted before imple­ment­a­tion begins.
This should be presen­ted along­side the project outcomes.
Business case bene­fits are very theor­et­ical, which is why ‘easy to measure’
stat­ist­ics should be collec­ted for benefit real­isa­tion purposes that indic­ate
whether the theor­et­ical bene­fits have been delivered. The post-implementation
survey is simple and proves whether the bene­fits predicted by the model have
been real­ised. If not, there may be various reasons for this, and these need to be
analysed and inter­preted in a benefit real­isa­tion review.

2.6 Procurement strategy

Specifying the procure­ment strategy at the busi­ness case stage allows the project
manager to define the most effect­ive procure­ment scen­ario, so estab­lish­ing a
clear way forward.

17
Planning, Scheduling, Monitoring and Control

The procure­ment strategy should consider the follow­ing, but these will differ
from organ­isa­tion to organ­isa­tion:

• Funding processes: how will funding be obtained for the project, and what
type of approvals will be required and when?
• Contract procure­ment frame­work: will the project require new procure­ment
(because of the size, complex­ity or special­ist nature of the project), or will an
exist­ing frame­work of suppli­ers be used?
• Contract­ing strategy: what type of contracts will be used?
• Finan­cing constraints: are there any constraints on the finan­cing of the project?
If so, cash-flow fore­cast­ing may be required, as will the intro­duc­tion of
spend­ing caps.
• Risk and contin­gency processes: how will the project obtain and draw down
(alloc­ate) risk and contin­gency monies?
• Secur­ity issues: sens­it­iv­ity of inform­a­tion and secur­ity concerns will influ­ence
the procure­ment strategy. Security around intel­lec­tual prop­erty rights may be
a concern.

The busi­ness case should define how the scope of the project will be
procured. For example, if the busi­ness need is for a rapid deliv­ery of the
project it may be appro­pri­ate to select the shortest procure­ment route, single
source procure­ment, exist­ing supply chain frame­work, as opposed to
compet­it­ive tender.
The commer­cial project manager or project procure­ment profes­sional should
both have input into the busi­ness case and under­stand it. Much of the activ­ity
asso­ci­ated with devel­op­ing the busi­ness case will typic­ally be under­taken as part
of the wider project manage­ment process. However, if large or key elements of
the project are likely to be sourced from outside the customer, the role of
procure­ment is to provide support and inform­a­tion, so that informed early
decisions, even if only ‘in prin­ciple’, can be taken.
Project managers must under­stand the devel­op­ment of the project procure­ment
strategy in terms of how to break a project down into pack­ages of work, and what
factors to consider when giving direc­tion on how indi­vidual providers will be
selec­ted, paid and rewar­ded, risks alloc­ated, etc. Investing time in devel­op­ing the
strategy both increases the like­li­hood of the indi­vidual pack­ages being success­ful
and, more import­antly, allows the busi­ness to review how the pack­ages fit together
to deliver the overall bene­fits.

18
 Business case

2.7 Project review and assur­ance process

of the busi­ness case
The busi­ness case may be peri­od­ic­ally reviewed to ensure that the project is on
track to deliver the busi­ness bene­fits, and that the project is still feas­ible. These
reviews will take place through­out the project life cycle, and addi­tional reviews
will take place follow­ing handover and clos­eout to ensure that the bene­fits are
being real­ised by the organ­isa­tion.

19
Scope and require­ments defin­i­tion are the processes that ensure the project
includes all the work required to complete it, and then define that work. They
define the struc­tures that enable the plan­ning, schedul­ing and budget­ing
exer­cises to be under­taken in a struc­tured manner. This will facil­it­ate the control
of the project as it enters its execu­tion phases.
The manage­ment of scope should rigor­ously prevent ‘scope creep’. This is the
collo­quial term given to any scope that is added or under­taken which is not
valid­ated and author­ised via the project’s scope defin­i­tion or change control
process.
These processes control how the project scope is developed and veri­fied.
They clearly define who is respons­ible for managing the project’s scope and act
as a guide for controlling the scope.

3.1 Definition of scope manage­ment

Scope defin­i­tion is the process of devel­op­ing the descrip­tion of the project and
its deliv­er­ables.

3.2 Purpose of scope manage­ment

Scope manage­ment should ensure that all work that is specified, and later done,
is related to the project object­ives. It is also import­ant to clearly estab­lish what is
excluded from the project scope. The busi­ness plan will define the breadth of the
project scope.

21
Planning, Scheduling, Monitoring and Control

3.3 The scope manage­ment process

3.3.1 Defining the scope
The initial part of the process defines the require­ments of the project. This will
include discus­sion with a range of stake­hold­ers, such as poten­tial suppli­ers, to
determ­ine what is possible, research and devel­op­ment areas, policy, legal and
more. To do this, the follow­ing tech­niques can be used:

• build method;
• brain­storm­ing;
• accur­ate/agreed require­ment setting and capture;
• stake­holder/end-user manage­ment (inter­views, analysis);
• key assump­tions manage­ment (creat­ing an assump­tions list);
• product analysis;
• options analysis;
• facil­it­ated work­shops.

The project manager is respons­ible for carry­ing out refine­ment and agree­ment of
the scope with the project exec­ut­ive, sponsor, programme manager, end-user
and other key stake­hold­ers to ensure that the project deliv­ers a relev­ant and
appro­pri­ate solu­tion. It is essen­tial that these key indi­vidu­als sign up to their
agree­ment of scope and that this is recor­ded in the project manage­ment plan.
Once the scope has been agreed it should be put under a formal change
control process, as scope creep and uncon­trolled change are common causes of
project failure.

3.3.2 Describing the scope

When a solu­tion has been iden­ti­fied that meets the stake­hold­ers’ criteria and
require­ments, the scope of work is divided into various hier­arch­ical break­down
struc­tures (see Figure 3.1). These may include:

• Product break­down struc­ture (PBS): Whilst not all indus­tries and sectors
will use a PBS, it can be used as an interim step towards gener­at­ing a WBS. It
is developed at the start of the project when the product or outcomes have
been scoped and agreed. The PBS breaks down all neces­sary outcomes of
a project.

22
 Scope manage­ment

Figure 3.1 Types and rela­tion­ships of break­down struc­tures

23
Planning, Scheduling, Monitoring and Control

• Work break­down struc­ture (WBS): The WBS breaks down or groups all
activ­it­ies within a project. A WBS can be further broken down into work
pack­ages and plan­ning pack­ages.
• Organisation break­down struc­ture (OBS): This is a hier­arch­ical struc­ture
showing organ­isa­tional account­ab­il­ity for the project and does not need to
reflect the organ­isa­tional struc­ture of the company, just the project account­ab­
il­ity. The OBS is defined down to the level of manage­ment control required in
the WBS. Roles are usually used in the OBS rather than names (e.g. engin­eer­
ing manager).
• Responsibility assign­ment matrix (RAM): The RAM desig­nates the respons­ib­
il­ity of work pack­ages to a team or indi­vidual. The RAM is a cross-reference of
the WBS and OBS.
• Cost break­down struc­ture (CBS): The CBS provides a finan­cial view of
the project and splits the project scope into its indi­vidual cost compon­ents.
The CBS often high­lights any finan­cial coding used for the busi­ness account­ing
system and any booking codes asso­ci­ated with each element of the project.
• Resource break­down struc­ture (RBS): The RBS organ­ises the project
resources in a hier­arch­ical list that is used to plan and control the project. The
struc­ture is not usually identical to the CBS, but there will be a rela­tion­ship
between them.

Breakdown struc­tures are dealt with in greater detail in Chapter 8.

To summar­ise: a PBS tells you what the product is; the WBS tells you about
not only the product but the support­ing services and how you deliver them; the
OBS tells you who has project account­ab­il­ity for elements of the WBS; the RAM
shows you the control points for manage­ment; the CBS records the costs; and
the RBS defines the type of resource and resources on the project.

24
4.1 Definition of require­ments manage­ment
Requirements manage­ment is the process of captur­ing, assess­ing and justi­fy­ing
stake­hold­ers’ wants and needs.
It requires the capture of require­ments via a struc­tured process. This process
should incre­ment­ally break down the require­ments in a hier­arch­ical manner,
consid­er­ing differ­ent condi­tions and scen­arios. The require­ments, once defined,
must be valid­ated with the project sponsor and/or key stake­hold­ers to ensure the
full scope has been captured.
Requirements manage­ment is an ongoing process that is main­tained
through­out the project life cycle.

4.2 Purpose of require­ments manage­ment

These require­ments become the prin­cipal project deliv­er­ables. Thus, it helps to
define the project scope. This allows the project team to under­stand the exact
deliv­er­ables of the project and how the work will be struc­tured to meet the
require­ments and deliver the scope.

4.3 Process of defin­ing require­ments

Once the initial iden­ti­fic­a­tion of require­ments has been under­taken, system
analysis can then be under­taken, looking at each require­ment in turn and

25
Planning, Scheduling, Monitoring and Control

analys­ing the risks, assump­tions, inter­faces, depend­en­cies, oppor­tun­it­ies and

constraints asso­ci­ated with the require­ment. This then allows the design and
build phase of the project, which is often the ‘imple­ment­a­tion’ phase of the
project life cycle.
Ideally, each phase would be completed prior to the next start­ing, but in reality
this process is often iter­at­ive and cyclical, with require­ments being continu­ally
analysed and eval­u­ated whilst the design is being final­ised and build has
commenced.

4.3.1 Requirement description

A require­ment must be described in such a way that it meets the follow­ing
criteria:

• It is up to date (e.g. with regard to latest tech­no­logy or to latest legis­la­tion).

• It is relev­ant to the spon­sor­ing organ­isa­tions and bene­fits.
• It does not contra­dict any other require­ment.
• It is concisely, but precisely, described, so that it is not open to differ­ent inter­
pret­a­tions.
• Its achieve­ment can be demon­strated.
• It can be traced from the oper­at­ing need of the organ­isa­tion, through the plan,
to what is delivered.
• Its relat­ive import­ance in rela­tion to other require­ments is under­stood.
• It can be linked to the product break­down struc­ture/work break­down struc­ture
and activ­it­ies in the project, for example by using activ­ity coding.

Satisfying all project require­ments equates to the comple­tion of the project.

4.3.2 Factors to consider when defining

requirements
When defin­ing require­ments, it is import­ant to consider what the accept­ance
criteria will be and how these will be defined. It may be useful to examine
require­ments and accept­ance criteria used for previ­ous projects of a similar
nature.
It is import­ant to take stand­ards, legal acts and regu­la­tions to be complied with
into account when require­ments are defined.

26
 Requirements manage­ment

4.3.3 Inputs into requirements management

• Mature busi­ness case.
• Contrac­tual docu­ment­a­tion contain­ing require­ments where applic­able.
• The current list of project assump­tions and constraints.
• Initial risk register.
• Current state­ment of work.
• Project execu­tion plan.
• Support­ing manage­ment plans, includ­ing bene­fits, quality and risk.
• Applic­able stand­ards.

4.4 The require­ments manage­ment process

4.4.1 Capture and define requirements from all stakeholders
• Defining require­ments requires the iden­ti­fic­a­tion of all stake­hold­ers, then
obtain­ing and docu­ment­ing their require­ments. The docu­ment­a­tion should
list all assump­tions, exclu­sions and constraints and the accept­ance, handover
and clos­eout criteria. When defin­ing the require­ments, it is import­ant to distin­
guish wants from needs.
• Identify the sources of the require­ments. One require­ment may have multiple
sources, but it is import­ant to identify the owner(s) of each require­ment. The
owner(s) will need to under­stand each of the sources’ views on assump­tions,
exclu­sions and constraints, so that a common under­stand­ing of the require­
ment can be met by means agreed with all stake­hold­ers.
• Capture any depend­en­cies between those require­ments within the scope of
work and those at the stra­tegic, programme/port­fo­lio level where this applies.
Consider hori­zontal linkage of require­ments between projects, plus those
require­ments/constraints that have an inter­face/depend­ency with exist­ing
ongoing activ­it­ies.

4.4.2 Link requirements to the product breakdown structures

and work breakdown structures where appropriate
• Identify and define the indi­vidual elements of each user/customer require­
ment that can be linked to indi­vidual elements of the supplier’s system
require­ments docu­ment (SRD), which in turn link to indi­vidual elements of

27
Planning, Scheduling, Monitoring and Control

the tech­nical specific­a­tion, which link to indi­vidual elements of the work

break­down struc­ture and the asso­ci­ated state­ment of work.
• Each product described by the WBS should satisfy an element of the require­
ments.
• The levels of trace­ab­il­ity between require­ments models must be determ­ined
in order to allow for plan­ning the resources and sched­ule implic­a­tions for
managing require­ments.
• The system require­ments drive the work to be completed within the system
design process and subsequent subsys­tem and compon­ent design, so the link
between the system require­ment struc­ture and the work break­down struc­ture
must be estab­lished.

4.4.3 Decompose requirements

Requirements are decom­posed into capab­il­it­ies, features or attrib­utes of the
project’s deliv­er­ables at a suffi­cient level of detail to allow veri­fic­a­tion and
valid­at­ ion (see Figure 4.1).
Once require­ments are defined, the accept­ance criteria for each require­ment
should be approved by the customer. The method of veri­fic­a­tion for the criteria

Figure 4.1 Design and devel­op­ment V Model

28
 Requirements manage­ment

should also be agreed upon. This could include analysis, inspec­tion, demon­stra­
tion or test, or simu­la­tion. A clearly defined require­ment increases the chances of
the project sponsor being able to make a clear decision regard­ing accept­ance
after comple­tion.
Requirements may be traded where appro­pri­ate, to balance time, cost, quality
and safety para­met­ers within the scope of work, using an approved change
control process.
Once require­ments have been clearly defined and agreed, they should be
clearly docu­mented, and the strategy for the deliv­ery of the require­ments should
be detailed within the PEP and the sched­ule.
The require­ments should be baselined before commen­cing the design and
deliv­ery process.
There are a number of design approaches, but for the major­ity of projects a
valid­at­ ion and veri­fic­a­tion require­ments matrix (VVRM) is a useful model to map
the user require­ments and system design, in order to facil­it­ate the project
assur­ance process; compli­ance with require­ments may be achieved by linking
the VVRM to tests, trials, demon­stra­tion, analysis and inspec­tions within the
relev­ant plan and then to the project sched­ule.
Key review points should be iden­ti­fied (for example prelim­in­ary design review,
crit­ical design review), where certain require­ments must be met before the
project proceeds further. At these reviews, require­ments and accept­ance criteria
should be valid­ated prior to testing to ensure that they are still appro­pri­ate. If not,
they can be amended through the relev­ant change process.
The VVRM should be updated as require­ments are met through their
accept­ance criteria.
Handover and clos­eout of all require­ments and assump­tions should be
captured in a formal accept­ance process

4.5 Works inform­a­tion (WI)

The works inform­a­tion is split into two parts: employ­ers and suppli­ers.
Employers’ inform­a­tion specifies the works to be carried out by the supplier,
includ­ing tech­nical inform­a­tion specific­a­tions, system require­ments, draw­ings,
and any constraints relat­ing to the supplier, e.g. safety require­ments, consents
required, etc.
Suppliers will respond with details of how they propose to deliver the works
in line with the custom­ers’ require­ments unless agreed other­wise. In some

29
Planning, Scheduling, Monitoring and Control

indus­tries, the suppli­ers’ response is known as the state­ment of work, as distinct

from the works inform­a­tion.
Each works inform­a­tion item must be linked to the formal require­ment that
gener­ates it. This is to ensure that scope creep is not gener­ated by the creation of
the works inform­a­tion (or, indeed, that scope gaps do not appear).
The sched­ule must contain all the works iden­ti­fied in the works inform­a­tion.

4.6 Statement of work (SOW)

A state­ment of work (SOW) explains in clear language the customer’s needs and
require­ments, and is there­fore often initially drafted at the bid stage of a project
by the customer to facil­it­ate the prepar­a­tion of propos­als from multiple poten­tial
contract­ors. It is often developed in line with the busi­ness case, and the SOW
will then form the basis of contractor selec­tion and contract admin­is­tra­tion.
The SOW defines all the work that is required to be under­taken in order to
develop or produce the outputs of the project, along with work perform­ance
require­ments for the project (e.g. service levels, minimum down-time, specific­a­
tions of build­ing safety, struc­ture, size, etc.). It includes qual­it­at­ive and quant­it­at­ive
design and perform­ance require­ments that can be meas­ured to determ­ine project
success.
Once a contract has been awarded to a supplier and a project commences, the
project team often breaks the top-level SOW into indi­vidual or work package
SOWs, creat­ing a more detailed and lower-level WBS struc­ture than that which
was submit­ted at bid stage. This facil­it­ates clearer defin­i­tion of the work pack­ages,
as the SOW require­ments can be traced through­out the WBS struc­ture, and
owner­ship can be clearly assigned to the work pack­ages.
Relevant parts of the SOWs which are refer­enced in a WBS diction­ary
are then considered along­side the constraints, risks, assump­tions, inter­faces,
depend­en­cies and oppor­tun­it­ies. This produces the scope baseline for the
project team to estim­ate work sched­ules and costs. As sched­ules are worked up,
the basis of estim­ates for dura­tion of activ­it­ies and cost estim­ates is recor­ded for
both project audit purposes, and sched­ule and cost risk assess­ment activ­it­ies.

30
5.1 Definition of stake­holder manage­ment
Stakeholders are the organ­isa­tions or people who have an interest or role in the
project, or are impacted by it. Stakeholder manage­ment is the formal manage­ment
of these interests, includ­ing the manage­ment of the rela­tion­ships and monit­or­ing
the deliv­ery of commit­ments made to the stake­hold­ers.

5.2 Purpose of stake­holder manage­ment

Stakeholders have a key role in setting the criteria used to define the success of
the project, and their involve­ment should not be over­looked. Managing stake­
hold­ers can make the differ­ence between success and failure of a project, and as
such should feature highly on the list of prior­it­ies and be treated with appro­pri­ate
gravity. Whilst the planner assists with this process, the main respons­ib­il­ity for
managing the stake­hold­ers lies with the project manager.

5.3 Managing stake­hold­ers through

the project
Setting the scope will include discus­sion with a range of stake­hold­ers, such as
poten­tial suppli­ers, to determ­ine what is possible, research and devel­op­ment
areas, policy, legal and more. The project manager is respons­ible for carry­ing out
refine­ment and agree­ment of the scope with the project sponsor, programme
manager, end-user and other key stake­hold­ers to ensure that the project deliv­ers

31
Planning, Scheduling, Monitoring and Control

a relev­ant and appro­pri­ate solu­tion. It is essen­tial that these key indi­vidu­als sign
up to their agree­ment of scope and that this is retained for record purposes.
Stakeholders must be iden­ti­fied, their level of interest and power to influ­ence
the project analysed, and plans devised for their manage­ment. Stakeholder
manage­ment is an iter­at­ive process which starts during project concept.
Stakeholders should be managed to ensure that a posit­ive rela­tion­ship with
the project is built and main­tained.
Stakeholder manage­ment becomes more complex when stake­hold­ers’ views
are not consist­ent through­out the life cycle of the project as changes occur in
their opin­ions, roles and views regard­ing the project.
The project’s commu­nic­a­tion plan should be employed as a tool for stake­holder
manage­ment. It may include who the stake­hold­ers are and their commu­nic­a­tion
needs, and who is respons­ible for their manage­ment and planned responses.
Stakeholder manage­ment needs to consider inter­faces with third parties or
outside influ­ences.

32
When approach­ing the plan­ning of a project, it is import­ant to gain a wide appre­
ci­ation of import­ant factors that may influ­ence the project’s success, its approach
or its complex­ity. Although a planner will not be expec­ted to know the finite
tech­nical detail of the project, plan­ners should have an appre­ci­ation of each
element of the project. Areas where the project team typic­ally may need to gain
a high level of under­stand­ing are listed in Table 6.1.

Table 6.1 Sources of project inform­a­tion

Document or source Example of inform­a­tion

Business case • Key dates for funding approval

The contract, espe­cially iden­ti­fied • Key dates, contract dates, risk owner­ship,
risks and key deliv­er­ables restric­tions, limit­a­tions on working condi­tions,
and any other require­ments

Customers’ require­ments • Processes to follow, may include deliv­ery

implic­a­tions and handover or hand-back regimes

Drawings • Scope, implied meth­od­o­lo­gies

Specifications • Standards, meth­od­o­lo­gies

Previous stage sched­ules • Key inter­faces with earlier phases

Meetings, work­shops • Insight into the project, in partic­ul­ar the drivers,

output rates and meth­od­o­lo­gies

Stakeholders • Who are the ‘key players’ that will impact the
success or failure of the project? How does this
influ­ence the plans?
(Continued)

33
Planning, Scheduling, Monitoring and Control

Table 6.1 Continued

Document or source Example of inform­a­tion

Stakeholders (cont.) • Legal agree­ments with third parties (party wall

agree­ments; intel­lec­tual prop­erty rights)

External inter­faces, i.e. those that • Supply of crit­ical resources, e.g. util­it­ies,
will not be covered by the project power supply
sched­ule
Benchmark data – output or • Refer back to previ­ous similar jobs/projects and
productiv­ity guides use real­istic dura­tions in the new sched­ule

Cost estim­ates • Scope veri­fic­a­tion

• Identify provi­sional sums

• Basis for budget loading of the sched­ule

Industry specific • Soil invest­ig­a­tion reports, site visits, weather

records for construc­tion

• Planned clos­ures to enable works

• Capability require­ments in defence

Previous projects of a similar nature • Methods, dura­tions and bench­mark­ing data

Lead-in times • Investigate any mater­i­als that are known to have

long procure­ment times, e.g. lifts or escal­at­ors,
government-furnished equip­ment

Available resource • Check that there are no special­ist resources

required that may be in short supply, e.g.
signalling engin­eers for rail projects

Gateways and stage approvals • Critical to a lot of projects. Find out what
approval stages are required, e.g. for design
or funding

Limitations imposed by relev­ant • Safety legis­la­tion

legis­la­tion
• Security clear­ances required

34
 Part Two

Planning

‘Failing to plan is plan­ning to fail.’

Alan Lakein
7.1 Definition of plan­ning
Planning is the process of identi­fy­ing the methods, resources and activ­it­ies
neces­sary to accom­plish the project’s object­ives. It achieves this by drawing on
the expert­ise, exper­i­ence and know­ledge of organ­isa­tions and indi­vidu­als
(includ­ing the lessons that it has learned from previ­ous projects), and on external
parties if appro­pri­ate, in order to:

• under­stand the need, problem or oppor­tun­ity that the project will address and
the bene­fits that it will deliver;
• define what has to be accom­plished and delivered, typic­ally stated in terms of
scope, time, budgets and quality;
• develop a plan to deliver the project.

Planning is the activ­ity of determ­in­ing how raw mater­i­als and other resources are
delivered into a desired outcome. It is also the process that will deliver a compet­
it­ive edge to organ­isa­tions compet­ing to win contracts to deliver work.

7.1.1 Definition of the plan­ning role

Planning is an art rather than a science; it is based on exper­i­ence, industry or
sector know­ledge and tech­nical skill, and a key ingredi­ent is innov­at­ive think­ing.
Planning is the activ­ity of a team working together to determ­ine the strategy for
deliv­er­ing the project. To achieve this, the project team determ­ines the method
or methods that will be used to deliver the project as well as how the project is to
be procured.

37
Planning, Scheduling, Monitoring and Control

The best plans will be created by a team of project managers, engin­eers,

produc­tion/design managers and commer­cial managers working together.
Specialist plan­ners may guide and facil­it­ate the process. In prin­ciple, plan­ning is
an activ­ity that precedes schedul­ing.
During the plan­ning process, the main inter­faces will be iden­ti­fied. It is
import­ant that during this process the assump­tions made, the risks, oppor­tun­it­ies
and issues are iden­ti­fied and recor­ded.
At the plan­ning stage of the project, it is import­ant that the project control and
report­ing meth­od­o­lo­gies that will be used are defined so that decisions around
the methods of plan­ning effort and tool­sets adopted will be adequate.
The outputs of plan­ning are there­fore:

• overall strategy for the project;

• overall meth­od­o­logy for the project;
• break­down struc­tures for managing the project;
• the iden­ti­fic­a­tion of key depend­en­cies;
• contri­bu­tions to the project risk and oppor­tun­it­ies register and issues log;
• the iden­ti­fic­a­tion of inter­faces.

7.2 Purpose of plan­ning

Planning is used to determ­ine how, when and which project deliv­er­ables must
be achieved in order to deliver the products (or actions) needed for the
project’s success. This includes record­ing any organ­isa­tional or manage­ment
approaches and processes that will be used. The plan­ning discip­line assesses
how and when activ­it­ies need to take place and defines the accept­able stand­ard
required for comple­tion, as well as balan­cing stand­ards and targets within
agreed time, cost and quality para­met­ers. The manage­ment approach inform­a­
tion will be recor­ded within the project manage­ment plan (PMP) – also known
as the project execu­tion plan (PEP) – and the relev­ant timings for the
activ­it­ies iden­ti­fied will be recor­ded within a project sched­ule, included within
the PMP/PEP.
Planning enables the project manager and their team to determ­ine what
methods and tech­niques they intend to use to deliver the required outputs,
products and activ­it­ies. Adding the activ­it­ies to a sched­ule helps to under­stand
the logical rela­tion­ships between activ­it­ies, the impact on resource distri­bu­tion,
the expendit­ure profile and report­ing implic­a­tions. In a well-planned project,

38
 Introduction to plan­ning

the means of achiev­ing the well-defined outputs, to an agreed stand­ard, have

been examined, thought about, optim­ised and recor­ded, and are regu­larly
reviewed.
Planning and schedul­ing are essen­tial to the author­isa­tion of the project
deliv­ery stages. Without a robust and real­istic PMP and sched­ule, advance­ment
through the project stages should not be approved. The approval at each stage
will look closely at the plan and sched­ule and consider whether the project is on
course to deliver its inten­ded busi­ness bene­fits in accord­ance with the busi­ness
case.
Once agreed and author­ised, plans and sched­ules are an essen­tial mech­an­ism
for commu­nic­at­ing the project strategy and the deploy­ment and tasking of staff,
contract­ors and other resources.

7.2.1 Benefits of plan­ning

• A well-planned project will identify and docu­ment the right activ­it­ies and
products to achieve the outputs and will secure the optimum resource level to
support this.
• Planning determ­ines what activ­it­ies and products need to be carried out,
when, to what stand­ard and using which resources, includ­ing monet­ary funds.
Well-planned projects, where the tasks that need to be under­taken, how and
when have been care­fully considered, are much more likely to success­fully
deliver desired outcomes.
• Comprehensive schedul­ing ensures the optimal alloc­a­tion and release of
resource and the effect­ive control of project activ­it­ies within time constraints.
• Planning is central to the control of the project and early iden­ti­fic­a­tion of where
the project might be start­ing to fail.
• Planning is an integ­ral part of problem solving at all stages of the project.
• The project sched­ule, risk and budget are used to form a baseline against
which the posi­tion of the project in terms of cost, time and risk, and there­fore
the perform­ance of the project, can be managed.
• Establishing a baseline enables the project team to check the progress of
the project, to measure success, and to identify and assess the impact of
devi­ation from the baseline. Early iden­ti­fic­a­tion of devi­ation will allow the
maximum time for correct­ive action and assess­ment of impact on other
planned activ­it­ies.
• With good plan­ning, it is possible to predict whether the project remains on
target to deliver its outputs within the time, cost or perform­ance constraints.

39
Planning, Scheduling, Monitoring and Control

• Above all, plan­ning is about commu­nic­at­ing the sequence, method and time
required to complete the project deliv­er­ables.

7.2.2 Success in planning

There are a number of key themes that are required for plan­ning to be a success;
the key consid­er­a­tions are:

• Ensure that the plan­ning exer­cise is prop­erly led, and that all input from the
project team and other stake­hold­ers is considered, reviewed and included as
appro­pri­ate. This should assist in achiev­ing buy-in of the project team. Planning
should never be an isol­ated exer­cise.
• Ensure that the right people are made avail­able to contrib­ute to the plan­ning
process in the manner described above.
• Ensure that a struc­tured approach is taken, so that the full scope of the project
is planned and that it ties back to all the contrac­tual require­ments.
• Ensure that adequate time is allowed to under­take the plan­ning exer­cise.
• Ensure that there is proper under­stand­ing of the scope and all commit­ments,
and that, during the plan­ning exer­cise, all depend­en­cies are iden­ti­fied and
described and all inter­faces are under­stood.
• Ensure all assump­tions are defined, docu­mented and taken into account.
• Ensure that adequate schedul­ing resources such as people and inform­a­tion
(e.g. estim­at­ing norms), along with an adequate project controls system, are
avail­able to convert the plan­ning exer­cises into under­stand­able sched­ules,
reports and other docu­ment­a­tion.
• Planning and control systems will always fail if the human factors are
ignored.
• Ensure that the schedul­ing discip­lines discussed in this guide are applied by
the sched­uler(s) to clearly define, describe and commu­nic­ate the plan, both in
terms of clarity and in terms of appro­pri­ate distri­bu­tion. In prac­tice, no one
tech­nique will likely give a defin­it­ive answer in terms of both plan­ning and
control. Good prac­tices are set up by careful selec­tion of the right tools for the
project.
• Ensure that all factors surround­ing the project are taken into account. This will
include logist­ics plan­ning, stake­holder manage­ment and the avail­ab­il­ity of
suit­ably trained and numer­ous resources.
• Ensure all project risks are under­stood and taken into account, and that any
iden­ti­fied risk mitig­a­tions are included in the sched­ule.

40
 Introduction to plan­ning

7.3 The differ­ence between plan­ning

and schedul­ing
Planning and schedul­ing are closely related subjects, but they are completely
separ­ate processes; however, the terms are often used as if they were inter­
change­able. To add to the confu­sion, many sched­ulers have been given role titles
that include the word ‘plan­ning’. Planners may have both skill sets, but it is
import­ant to be aware of, and for this guide to define, the differ­ence between the
two roles.
Whereas plan­ning has to be done well in order to define the best solu­tion to
deliver the project, schedul­ing needs to be done well to determ­ine the project
para­met­ers: how long the project will take to complete, for example. Furthermore,
it must be done well to commu­nic­ate the project clearly and precisely. It can then
form a sound found­a­tion for project control.
Scheduling is more of a science compared with the art of plan­ning; it usually
involves the input of plan­ning inform­a­tion into schedul­ing soft­ware. Scheduling
uses the WBS as the frame­work on which to build all the project activ­it­ies. It
calcu­lates the dates from the activ­ity/task dura­tions and determ­ines the resources
required. It also defines the logical sequence of activ­it­ies and calcu­lates the
crit­ical path (the path or chain of activ­it­ies which, if delayed, will cause a corres­
pond­ing delay to the overall project comple­tion date). In this process it computes
the start and finish dates and iden­ti­fies the float on all the activ­it­ies. The final
outcome of this process is to determ­ine the feas­ib­il­ity of deliv­er­ing the project to
the required comple­tion dates.
At the outset of a project, plan­ning is the art of decid­ing the best strategy for
design­ing a project, imple­ment­ing a project and bring­ing a project into use. The
key to good plan­ning is effect­ive commu­nic­a­tion of the strategy and method(s)
that are decided upon as the most effi­cient way to deliver the project. Thus, it is
about:

• defin­ing require­ments, scope, purpose and object­ives;

• defin­ing meth­od­o­logy;
• defin­i­tion of deliv­er­ables;
• clarity of organ­isa­tion and organ­isa­tional respons­ib­il­ity;
• the iden­ti­fic­a­tion and manage­ment of risk – both threats and oppor­tun­it­ies;
• support­ing the busi­ness case to gain funding;
• getting agree­ment of all stake­hold­ers in the project;

41
Planning, Scheduling, Monitoring and Control

• defin­ing constraints;
• estab­lish­ing prior­it­ies;
• defin­ing and docu­ment­ing assump­tions.

A key part of plan­ning is creat­ing the project sched­ule. (This is often referred to
as the programme, but, in order to avoid confu­sion with programmes of work
and other uses of the word ‘programme’, it is common to use the term ‘sched­ule’,
and this guide uses this conven­tion.)

7.4 Principal schedul­ing compon­ents

7.4.1 Process step schedules
The sched­ule will usually be presen­ted in a graph­ical format. The sched­ule should
have enough inform­a­tion in it to manage the project and accur­ately model the
impact of change and progress. Information that can be held in a separ­ate tracker
should not be included in the sched­ule. Examples of separ­ate track­ers include:

• design deliv­er­able sched­ules;

• method state­ment sched­ules;
• consents track­ers;
• handover or hand-back track­ers (also known as inter­faces);
• approval chains (managed by special­ist resource – the details of testing and
commis­sion­ing, for example).

Collectively, these docu­ments do all form part of the sched­ule, and links between
these docu­ments and the master/working sched­ule must be actively managed
and updated.
It is not useful to manage all this in the special­ist schedul­ing soft­ware, because
it increases the size of the sched­ule to less manage­able propor­tions (it is likely to
be a high-density level of detail). It would also make it harder for the project
manager to access the data, thus detract­ing from the main purpose of the sched­ule.

7.4.2 Time-based schedules

It is almost certain that, for any project of complex­ity, the sched­ule will be
contained in special­ist schedul­ing soft­ware. This may include Gantt charts, time

42
 Introduction to plan­ning

chain­age charts, line of balance graphs, etc. – these are dynamic, logic-linked,
usually crit­ical path views of the sched­ule for the phys­ical and deliv­er­able works.

7.4.3 Schedule narrative

A sched­ule narrat­ive (some­times known as the plan­ning method state­ment) will
be required to accom­pany a sched­ule of medium to high complex­ity, to explain,
illu­min­ate and commu­nic­ate meth­od­o­logy, timing, and the risks and constraints
on the sched­ule. It should give a clear under­stand­ing to both project and
non-project team members of the way the work has been planned and sched­uled,
with asso­ci­ated assump­tions.

7.5 Approaches to plan­ning

7.5.1 Top-down planning
Top-down plan­ning describes an approach that starts with stra­tegic plan­ning of a
project and is worked into greater detail (and certainty) in paral­lel with the
commence­ment of the project. Top-down plan­ning is ‘events’ focused. It defines
a period of time/work leading up to a key event that occurs at the culmin­a­tion of
a number of project activ­it­ies – for example, a prelim­in­ary design review, which
is an ‘event’ that has much activ­ity leading up to it, and effect­ively valid­ates that
work, thus making it an import­ant ‘event’.
Typically, this top-down approach will define the overall project life cycle
along with key events that will need to happen in order to achieve each
gate review. As the top-down plan is more require­ments driven and needs
driven, it tends not to be date focused, and works instead on estab­lish­ing the
essen­tial logic flows and sequences required for the success­ful comple­tion of
the project.
Bottom-up plan­ning then comple­ments this approach by valid­at­ing the effort
and dura­tion required to deliver the require­ments on the project, and should
result in a resource-driven sched­ule showing the project dates by which key
events can be met. Often, there is then a ration­al­isa­tion 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 times­cales, cost or
quality stand­ards outlined by the customer.
See Figure 7.1 for a compar­ison of top-down and bottom-up plan­ning.

43
Planning, Scheduling, Monitoring and Control

Figure 7.1 Top-down vs. bottom-up planning

7.5.2 Bottom-up planning

Where full details of the scope of work are known, a detailed sched­ule can be
produced, start­ing at the lowest level and usually meas­ured in days. This is
typic­ally a high-density sched­ule, and would be one of the more detailed plan­ning
outputs. Fully logic-linked and usually held in a schedul­ing soft­ware tool, this
approach can be effect­ively util­ised through collab­or­at­ive plan­ning tech­niques.

7.5.2.1 Collaborative plan­ning

‘Collaborative plan­ning’ is a tech­nique that ensures that all key stake­hold­ers are
actively involved in the bottom-up plan­ning of a project, and promotes team
‘buy-in’ to the sched­ule and plan­ning strategy. It is usually under­taken via a facil­
it­ated work­shop, whereby the facil­it­ator will help to guide the team to create a
bottom-up sched­ule of activ­it­ies required to success­fully reach an agreed
end-point. There are multiple ways of facil­it­at­ing plan­ning work­shops – one
effect­ive approach is for all of the team to create task names on sticky notes,
which are then categor­ised and reviewed. Logic, dura­tions, resources and any
constraints are then discussed and agreed until a fully logic-linked sched­ule has
been created. This approach takes a number of iter­a­tions; however, it should
foster a collab­or­at­ive approach and help to ensure that all team members are fully
engaged in the plan­ning process.

44
 Introduction to plan­ning

7.5.2.2 Summarising the output

Once this higher-density sched­ule has been created, the detail is then summar­ised
into larger sections such as design, procure­ment and construc­tion. These items
cover weeks or months. This provides a view of the project useful for brief­ing
new team members, senior manage­ment, exec­ut­ives and/or the customer.

7.5.2.3 Rolling wave plan­ning

If the plan, and hence the sched­ule, is created once all the design is complete,
after all contract­ors and sub-contractors are appoin­ted, and after all meth­od­o­lo­
gies have been agreed, then the creation of a fully detailed, budgeted and
resourced sched­ule will be achiev­able at the outset of a project. If, however,
some or all of these are not in place, some form of rolling wave plan­ning is
required. A rolling wave approach can also be adopted for highly complex
projects, where there is a high risk of change, and/or a project spans multiple
years (e.g. a defence build project), or where there is a reas­on­able degree of
uncer­tainty in the project.
Rolling wave plan­ning describes the schedul­ing density that is achieved at
differ­ent moments in time. Figure 7.2 shows a typical sched­ule in terms of its
current state of devel­op­ment. The project is broken down into ‘waves’, which are
typic­ally anchored to key gate reviews or signi­fic­ant events in the project. The
project then uses the top-down plan and system­at­ic­ally plans each wave to an
increas­ing level of gran­u­lar­ity, start­ing with a high-density sched­ule upfront in
the first wave, and gradu­ally redu­cing the level of density and hence the
require­ment to fully define details which may not be fully avail­able to the project
until a later date.
In large-scale, long-duration projects, it may not be feas­ible to struc­ture the
rolling waves accord­ing to gate reviews, as these may be many years apart.
Where this is the case, the project may choose interim mile­stones or deliv­er­ables
by which the rolling waves should be completed, or, altern­at­ively, may choose a
set number of periods of time (e.g. months) which should have a detailed plan
(typic­ally 3–6 months). Where such an approach is taken, tasks and work
pack­ages should always be fully planned out to their natural conclu­sion,
irre­spect­ive of the ‘cut-off’ of the rolling wave.
As the project moves nearer to the end of the first phase, the second phase
will be planned to a higher level of density and detail, as the project team will
have more inform­a­tion avail­able than at project incep­tion.

45
Planning, Scheduling, Monitoring and Control

Figure 7.2 Rolling wave plan­ning

It should be noted that each wave end-point is a guide, and, when schedul­ing
out work, each work package should be planned to its natural conclu­sion, rather
than cut at a specific point in time to meet the wave end date. The waves may
relate to phases of the project as shown in the illus­tra­tion above.

7.5.2.3.1 Advantages of rolling wave plan­ning

• It allows an incre­mental approach to plan­ning high-density detail, to allow
project ‘unknowns’ to be resolved over time rather than at project incep­tion.
• It reduces the level of upfront plan­ning effort required.
• It is suit­able for projects with chan­ging or emer­ging scope, as scope can be
added or removed from future waves in a controlled way.
• It allows manage­ment of an uncer­tain sched­ule.

7.5.2.3.2 Limitations of rolling wave plan­ning

• Effort to plan next rolling wave may divert crit­ical resources from sched­ule
deliv­ery tasks if not planned correctly and incor­por­ated into the original
estim­ates.

46
 Introduction to plan­ning

• There is the possib­il­ity that, in future rolling waves, the gran­u­lar­ity can be
manip­u­lated to display an inten­ded crit­ical path, rather than the actual crit­ical
path for the project.
• Lack of detail in future phases may hinder adequate risk analysis.
• Critical path activ­it­ies are unclear until detail is fully under­stood in future
waves.
• Thus, there is a high prob­ab­il­ity that the project end date may be affected after
each wave of detail is added.

7.5.3 Agile planning in the software industry

7.5.3.1 Definition and purpose of agile plan­ning
Agile plan­ning is a means of adapt­ing rapidly to changes in a busi­ness envir­on­
ment. An agile approach integ­rates plan­ning with execu­tion almost concur­rently,
allow­ing early and continu­ous deliv­ery. For a full defin­i­tion and purpose state­ment,
see Chapter 20.

7.5.3.2 The agile plan­ning process

Agile plan­ning is similar to rolling wave schedul­ing. Work is planned as time-boxed
iter­a­tions called ‘sprints’. These are typic­ally 2 to 4 weeks in dura­tion. 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 plan­ning

47
Planning, Scheduling, Monitoring and Control

sched­uled later in the future might be shown as single releases, using a longer
dura­tion.
Not all activ­it­ies are constrained to sprints; for example, procure­ment activ­it­ies
or activ­it­ies involving external stake­hold­ers.
There is a common miscon­cep­tion that is it not possible to reli­ably develop and
use a baseline for an agile project, but this is not the case. Welcoming change
does not mean undis­cip­lined or ad hoc deliv­ery. The project still has a vision, a
times­cale in which the vision needs to be achieved, and a budget. The plan­ning
of the sprints is guided by the project vision.
A baseline provides the basis for specify­ing expec­ted outcomes of each
iter­a­tion. As a result, custom­ers have the ability to hold the team account­able to
the project vision at the end of each iter­a­tion and version release.
Being agile means that there is less resist­ance to chan­ging the sched­ule; the
highest prior­ity is to satisfy the customer by early and continu­ous deliv­ery of
valu­able soft­ware. Delivery can be prior­it­ised, using the MoSCoW tech­nique, to
ensure the prior­it­isa­tion of crit­ical aspects of the solu­tion:

• Must have: These are the require­ments that are completely non-negotiable.
Without them, the project will not provide a solu­tion to the customer’s
problem. Wherever possible, these are the require­ments that are developed
first, to gain customer trust and confid­ence in the system, provid­ing early
func­tion­al­ity.
• Should have: These are the require­ments that are still import­ant, but, with
some pain, could in the worst case be taken out; however, there would need
to be ‘work-arounds’ and stake­holder manage­ment and buy-in to remove
these require­ments from the scope of the project.
• Could have: These are the ‘nice to have’ require­ments. Without them,
the project solu­tion will still deliver; however, there is value to adding
these require­ments for a more complete system. These are the require­ments
which, if time or cost becomes tight, are the first to be cut out of the
scope.
• Won’t have (this time): These are the require­ments that have been agreed by
the customer and project team to be non-essential, and are there­fore being
left out of the scope of the project delib­er­ately. This is not to say, however, that
if the project is awarded an exten­sion, or if there is a delay else­where, some of
these non-essential require­ments cannot be added in at a later date if they do
not detract from the main project prior­it­ies.

48
 Introduction to plan­ning

7.5.3.3 Planning require­ments for adopt­ing an agile approach

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

• devel­op­ment of self-organising teams;

• engage­ment of busi­ness resource through­out the project;
• collab­or­at­ive approach – paying atten­tion to beha­viours is crucial;
• deleg­ated author­ity suited to agile change needs to be estab­lished.

7.6 Planning strategies

As part of the busi­ness strategy, it will need to be decided how best to deliver the
project. Some of the factors that may influ­ence an adopted strategy would be:

• best commer­cial solu­tion based on earli­est comple­tion;

• most econom­ical solu­tion based on avail­ab­il­ity of funds;
• the rate at which funds can be commit­ted (some­times referred to as ‘cash-
flow’);
• avail­ab­il­ity of resources (labour and mater­ial);
• the rate at which the project can be mobil­ised;
• external factors such as a rela­tion­ship with other projects.

Once the strategy has been decided upon, it will direct the rest of the plan­ning,
estim­at­ing and schedul­ing efforts of the project, poten­tially impos­ing constraints
and other limit­a­tions on the sched­ule and methods to be adopted.
Different strategies can be described with differ­ing planned value curves. The
basic possib­il­it­ies are based on the crit­ical path method (CPM), which calcu­lates
two sets of dates based on the same sched­ule logic (an early comple­tion and a
late comple­tion for each activ­ity). The combin­a­tion of these forms an envel­ope in
which the works can logic­ally be completed without delay­ing the desired project
comple­tion date (see Figure 7.4).
Relying purely on CPM, the curves produced would not make achiev­able plans:

• The early curve, though logic­ally possible, relies on every aspect going
perfectly to plan, the absence of risk real­isa­tion and the avail­ab­il­ity of unlim­ited
resource. This never happens. This curve is often referred to as the P0 plan, P0
refer­ring to zero percent prob­ab­il­ity of achieve­ment.

49
Planning, Scheduling, Monitoring and Control

• Working to the late curve may be logic­ally achiev­able, but will allow no
devi­ation from plan, as all float has been elim­in­ated. If a delay to an activ­ity
were to occur, deliv­ery on time or to budget with the exist­ing logic and
assump­tions would be impossible. Attempting to work to this curve would
be to assume that no risk will be real­ised.

It is not, there­fore, appro­pri­ate to rely on these sorts of planned values without

further refine­ment, and the use of resource-levelled sched­ules is there­fore
recom­men­ded in this guide (Chapter 16).
Figure 7.5 shows the effect of apply­ing a resource-levelling exer­cise to the
sched­ule. It is part of the plan­ning strategy to decide what resources can be
applied and what limit­a­tions on them are sens­ible to account for in the project
sched­ule.
Figure 7.5 also shows a line denoted the ‘economic best fit’. This is based on
constraints around the avail­ab­il­ity of funds – caps on spend­ing at partic­ul­ar
points, for example. A commer­cial benefit can be achieved from redu­cing
finan­cing costs, but if deliv­ery on time is a prior­ity it will have the effect of adding
risk into the project, as it will be harder to recover from unfore­seen delays.

Figure 7.4 Setting early and late curves

50
 Introduction to plan­ning

Figure 7.5 Interpreting ‘S’ curves

7.7 Allowing for risk

The future is unwrit­ten, that is to say uncer­tain. It is neces­sary to allow for the
unknown when plan­ning for the future. Depending on the stage of the project, it
is advis­able to allow a 10%–20% time contin­gency. The former will be applic­able
at later stages of the project life cycle, such as at the point of going into contract.
Chapter 26 will discuss the assess­ment and manage­ment of risk in general, and
specific­ally in rela­tion to time, under the process of quant­it­at­ive sched­ule risk
analysis (QSRA).

51
8.1 Definition of break­down struc­tures
Breakdown struc­tures are tools used to break down the project into smaller
elements to facil­it­ate the deleg­a­tion of respons­ib­il­ity.

8.2 Purpose of break­down struc­tures

Breakdown struc­tures are used to create discrete pack­ages of work to
define respons­ib­il­ity for deliv­ery and to facil­it­ate project control (see
Figures 8.1–8.3).

8.3 Creating breakdown structures

8.3.1 Level 1
Level 1 of a break­down struc­ture is based on the ulti­mate project output (WBS),
the top of an organ­isa­tion struc­ture (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 struc­ture into more manage­able levels to make
the plan­ning process easier. In the example, the product is now broken down into
phases.

53
Planning, Scheduling, Monitoring and Control

Figure 8.1 Creating a break­down struc­ture level 1

Figure 8.2 Creating a break­down struc­ture level 2

54
 Breakdown struc­tures

Figure 8.3 Creating a break­down struc­ture level 3

8.3.3 Level 3 and beyond

This exer­cise contin­ues until the project team feel that they will be able to define
tasks and logical depend­en­cies which deliver the lowest level of a struc­ture
(node). At this point there is no need to break out the struc­ture any further.
There are a number of differ­ent break­down struc­tures that a project may
employ (Figure 8.4).

55
Planning, Scheduling, Monitoring and Control

Figure 8.4 Types and rela­tion­ships of break­down struc­tures repeated

56
 Breakdown struc­tures

8.4 Product break­down struc­ture (PBS)

8.4.1 What is a ‘product’ in plan­ning terms?
A product is an output which meets the scope or require­ment, some­times
referred to as (a) deliv­er­able(s).

8.4.2 Definition of a PBS

A product break­down struc­ture (PBS) is a key step in a product-based plan­ning
approach. It provides a hier­arch­ical tree repres­ent­a­tion of the rela­tion­ship
between the products and sub-products such as assem­blies, sub-assemblies and
parts, which contrib­ute to deliv­er­ing the scope and object­ives of a project or
programme. It provides the outline frame­work for plan­ning, contract­ing,
budget­ing and report­ing. An example is shown in Figure 8.5.
Some examples of products required to manage the project are reports, test
docu­ment­a­tion, require­ment specific­a­tions and safety certi­fic­a­tions.

8.4.3 Purpose of a PBS

A PBS provides a top-down hier­arch­ical view of all of the products (outputs)
within a project. This makes it easier to ensure that all the outputs have been
iden­ti­fied before going into the detail of identi­fy­ing the work pack­ages or activ­it­ies
within a work break­down struc­ture (WBS). Additionally, the PBS helps create a
common under­stand­ing of the deliv­er­ables in a project, and aids object­ive
progress capture by defin­ing a phys­ical output.

8.4.4 Constructing a PBS

A PBS is developed at the start of a project, once the required scope or require­
ments have been agreed. The PBS provides a break­down of all the neces­sary
products (outputs) of a project, whereas a WBS provides a break­down of the all
work pack­ages or areas of the project.
The PBS should be included as part of the project plan and stage plans, with
progress­ively more detail at each level.
To construct a PBS, first identify those products that meet the client/customer’s
scope or require­ments, such as special­ist products. (A useful approach is to
gather stake­hold­ers together to brain­storm the products needed.)

57
Planning, Scheduling, Monitoring and Control

Figure 8.5 Sample product break­down struc­ture

The next step is to identify the plans and reports needed to manage products
in the project.
A PBS is drawn in a hier­arch­ical struc­ture from the top down. The first
box summar­ises the overall product, with the subsequent branches showing
inter­me­di­ate products such as assem­blies, sub-assemblies and compon­ents or
parts.
It may be useful to break down products into special­ist products, which are
those products required to meet the scope or require­ment, and manage­ment
products, such as reports and plans.

58
 Breakdown struc­tures

8.5 Work break­down struc­ture (WBS)

8.5.1 Definition of a WBS
A work break­down struc­ture (WBS) is a hier­arch­ical break­down of the scope or
require­ment of the project into a series of manage­able work pack­ages or areas
that can be estim­ated, planned and assigned to the appro­pri­ate person or
depart­ment for comple­tion. It can be based on design systems, construc­tion/
install­at­ ion zones or indi­vidu­ally commis­sion­able systems. An example is shown
in Figure 8.6.

8.5.2 Purpose of a WBS

A major benefit of the WBS is that it breaks down the work required within a
project into work pack­ages or areas, which can be assigned to a respons­ible
party. Once a project has been broken into small pack­ages of work, there is a
better chance of under­stand­ing what needs to be done.

Figure 8.6 Work break­down struc­ture

59
Planning, Scheduling, Monitoring and Control

The WBS provides a common frame­work for the devel­op­ment of the plan­ning
and control of a project. It divides work into defin­able work pack­ages from which
a state­ment of work can be developed and tech­nical, sched­ule, cost and resource
report­ing can be estab­lished. Individual work pack­ages or areas of the WBS may
be broken down further to give better sched­ule segreg­a­tion.
A WBS code must be applied in order to identify the work pack­ages within the
project in a logical manner. This then forms the basis for accur­ate report­ing and
mapping of time, cost and resources.
Each section of the WBS or work package can then be assessed to:

• describe what the work is;

• estim­ate how long it will take;
• estim­ate the resources and costs;
• identify who needs to be involved;
• work out the poten­tial threats and oppor­tun­it­ies.

A WBS can be combined with an organ­isa­tional break­down struc­ture (OBS) to

produce a respons­ib­il­ity assign­ment matrix (RAM) showing the respons­ib­il­ity for
each work package.

8.5.3 Constructing a WBS

A WBS is initially developed at the start of the project and is reviewed iter­at­ively
at the begin­ning of each stage as a minimum.
It is good prac­tice to use a WBS when devel­op­ing any project sched­ule.
If a product break­down struc­ture has already been produced, this provides a
good break­down of all neces­sary products and outputs of a project, and can form
the primary input to the WBS.
Note: in the construc­tion sector the WBS is more usually used to identify
geograph­ical areas where work will be carried out. However, the hier­archy
prin­ciple still applies.
The indi­vidual work pack­ages may them­selves be further sub-divided down to
indi­vidual activ­it­ies. The key thing about the WBS is the ability to break down the
project into work pack­ages that can be assigned to a resource.

8.5.4 Principles of design­ing a WBS

There are three prin­ciples that should be applied when design­ing a WBS:

60
 Breakdown struc­tures

8.5.4.1 The 100% rule

The WBS should define the total scope of the project and capture all deliv­er­
ables, both internal and external, includ­ing project manage­ment:

• The sum of the work at the ‘child’ level must equal 100% of the work repres­en­
ted by the ‘parent’.
• The WBS should not include any work that falls outside the actual scope of the
project, i.e. it cannot include more than 100% of the work.

8.5.4.2 ‘Parent/child’ rela­tion­ship

There should be no overlap in scope defin­i­tion between any two elements in a
WBS. Each ‘child’ element of work should only be asso­ci­ated with one ‘parent’.
If not, then you run the risk of duplic­at­ing work in the project execu­tion, and
would there­fore exceed the 100% rule!

8.5.4.3 Use common sense

• Remember the aim is to define the work of the project so that it can be planned,
managed and controlled.
• Therefore, there needs to be a suffi­cient level of detail in the WBS, but:
• Do not decom­pose the WBS to a level beyond that neces­sary to achieve
these aims.

8.5.5 WBS diction­ar­ies

A work break­down struc­ture diction­ary is some­times used on more complex
projects.

8.5.5.1 Definition of a WBS diction­ary

A WBS diction­ary is a tool that helps to clearly define the work content
of each WBS node. This helps to ensure a consist­ent and coher­ent
approach to the project and clearly defines the key deliv­er­ables for each
WBS node.
In construc­tion, the WBS diction­ary is often called the work package scope
sheet, and is a key docu­ment in defin­ing scope and the key inter­faces with other

61
Planning, Scheduling, Monitoring and Control

works. In other words, it is a tool to identify scope gaps or over­laps and assist in
their elim­in­a­tion.

8.5.5.2 Purpose of a WBS diction­ary

WBS diction­ar­ies can be used with the customer to ensure that the scope of
work to be under­taken is agreed by all contract­ing parties. When a project is up
and running, change control of the WBS and asso­ci­ated diction­ar­ies should be
applied. An example of a WBS diction­ary is shown in Figure 8.7.
In addi­tion to the fields illus­trated, addi­tional inform­a­tion may be contained in
a WBS diction­ary, such as clari­fic­a­tion to suppli­ers or sub-contractors of services
or free issue mater­i­als to be provided (or not) to the supplier by the contractor or
client. See Figure 8.8 for an example.

Figure 8.7 Work break­down struc­ture diction­ary (defence)

62
 Breakdown struc­tures

Figure 8.8 Work package content sheet (construc­tion)

63
Planning, Scheduling, Monitoring and Control

8.6 Organisational break­down

struc­ture (OBS)
8.6.1 Definition of an OBS
Within product-based plan­ning, the organ­isa­tional break­down struc­ture (OBS)
is a top-down hier­arch­ical repres­ent­a­tion of the manage­ment struc­ture and
people within a project. It is used to convey the commu­nic­a­tion routes and
report­ing lines within the project. A project’s OBS may differ from that of the
organ­isa­tion. See Figure 8.9 for an example.

8.6.2 Purpose of an OBS

An OBS is a useful tool – in conjunc­tion with the WBS – for plan­ning
projects that inter­face with complex organ­isa­tions. It is used to show the
project organ­isa­tion struc­tured in a hier­arch­ical manner. When used in conjunc­
tion with the WBS, the OBS helps in produ­cing the respons­ib­il­ity assign­ment
matrix (RAM).

Figure 8.9 Organisation break­down struc­ture

64
 Breakdown struc­tures

8.6.3 Constructing an OBS

The OBS is initially developed at the start of the project and is reviewed iter­at­
ively at the begin­ning of each stage as a minimum.
An OBS is created by:

• First, identi­fy­ing the organ­isa­tional struc­ture for the resources involved in the
project.
• This should then be broken out into the areas or depart­ments, sub-areas or
sub-departments and down to the role that will be account­able for a WBS
element.
• This is then drawn out as a hier­arch­ical organ­isa­tional tree, showing the
report­ing lines and commu­nic­a­tion paths.

8.7 Responsibility assign­ment matrix (RAM)

8.7.1 Definition of a RAM
A respons­ib­il­ity assign­ment matrix (RAM) (see Figure 8.10) is a project
manage­ment tool, often depic­ted as a table, that shows the project
organ­isa­tional break­down struc­ture (OBS) in rela­tion to the work break­down
struc­ture (WBS) to ensure that each element of the scope of work is assigned
to a respons­ible team or indi­vidual. Larger projects may define RAMs at
multiple levels.
A high-level RAM defines which group or organ­isa­tional unit or team
is respons­ible for each compon­ent of the WBS. Lower-level RAMs can be
used within teams to assign roles and respons­ib­il­it­ies for specific activ­it­ies to
indi­vidu­als.
(There is an altern­at­ive break­down known as a £ RAM, which is discussed
under the heading of Cost break­down struc­tures, section 8.9.)

8.7.2 Purpose of a RAM

The RAM provides a view of all work pack­ages, or at a lower level, activ­it­ies. It
is used within the project to commu­nic­ate the required work to stake­hold­ers.

65
Planning, Scheduling, Monitoring and Control

Figure 8.10 Responsibility assign­ment matrix

It is used to show the account­ab­il­ity for the various work pack­ages or activ­it­ies
within the project team.
The RAM can form the basis for schedul­ing activ­it­ies and is a key input when
devel­op­ing the network diagram or Gantt chart.

8.7.3 Constructing a RAM

It is developed at the start of a project where there is a complex divi­sion of
respons­ib­il­it­ies, when the scope has been agreed, the deliv­er­ables have been
defined and a WBS and OBS have been created.

66
 Breakdown struc­tures

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 left-hand side and the OBS
resources across the top, marked at the appro­pri­ate inter­sec­tions to indic­ate who
is doing what. (Sometimes the RAM is drawn the other way around, with the
WBS at the top and the OBS at the left.)

8.7.4 The step-by-step approach to construct­ing a RAM

• Define your deliv­er­ables. A WBS is a project plan­ning tool used to break
a project down into smaller, more manage­able pieces of work, called work
pack­ages. Work pack­ages can then be broken down further into indi­vidual
activ­it­ies and their asso­ci­ated deliv­er­ables.
• Identify the people involved. An OBS maps the resources avail­able.
Create a chart of account­able indi­vidu­als at depart­mental or sub-departmental
level. For lower-level RAMs, this can cover indi­vidu­als within the depart­ment
or sub-department.
• Create the respons­ib­il­ity assign­ment matrix. Draw a matrix. The
deliv­er­ables form the row head­ings, and the resources are listed as column
titles. Determine respons­ib­il­it­ies for each item in the WBS. Note that only
one indi­vidual should be account­able for any discrete element of work.
Lower-level RAMs can record respons­ib­il­it­ies for activ­it­ies within a work
package.
• Assign other roles. For each section, work package or activ­ity, a RACI
analysis (see 8.8) can be used to record who is account­able for that work
package or activ­ity, and who should be consul­ted or informed during its
execu­tion. Table 8.1 shows the defin­i­tion for RACI analysis, though there are
other respons­ib­il­ity analysis models.
• Communicate. Ensure all groups and roles are informed of their respons­ib­
il­it­ies.

8.8 RACI matrix

8.8.1 Definition of a RACI matrix
The RACI matrix is a tool used for identi­fy­ing roles and respons­ib­il­it­ies to avoid
confu­sion over those roles and respons­ib­il­it­ies during the project. The acronym
RACI is explained in Table 8.1.

67
Planning, Scheduling, Monitoring and Control

Table 8.1 Explanation of RACI codes

Interest Definition

R = Responsible Conducts the actual work/owns the problem

A = Accountable Approves the completed work and is held fully account­able for it.
Usually one account­able role

C = Consulted Kept fully informed and included in decision making. Primary

support­ive role

I = Informed Kept informed of progress and results

8.8.2 Purpose of a RACI matrix

A RACI diagram is a clear and concise summary of tasks or deliv­er­ables (or,
rather, the specific respons­ib­il­it­ies contained within project proced­ures) and the
level of account­ab­il­ity or contri­bu­tion required from named roles or indi­vidu­als
within the project.

8.8.3 Constructing a RACI matrix

The matrix is developed when the scope has been agreed, the deliv­er­ables have
been defined and a WBS and OBS have been created.

• Define your tasks or deliv­er­ables. Identify all the tasks involved in

deliv­er­ing the project. These are listed on the left-hand side of the chart.
• Identify the people involved. These are defined in terms of roles,
not indi­vidu­als, and are listed along the top of the chart, as shown in
Figure 8.11.
• Create the RACI matrix. Complete the chart showing who has respons­ib­
il­ity, who has account­ab­il­ity and who will be consul­ted and informed for each
task.
• Check for account­ab­il­ity. Ensure that every task has a role respons­ible
and a role account­able for it. No task should have more than one person
account­able.
• Communicate. Ensure that all groups and roles are informed of their
respons­ib­il­it­ies. Agree the RACI with project stake­hold­ers before the project
starts.

68
 Breakdown struc­tures

Figure 8.11 Example of a RACI

8.9 Cost break­down struc­ture (CBS)

8.9.1 Definition of a CBS
A cost break­down struc­ture defines the level at which costs will be collec­ted.
Unlike the WBS, it has no hier­archy as such (or, at least, no partic­u­lar need for
one), as it comprises a list of cost head­ings. It is directly related to the WBS,
possibly at differ­ent levels, as illus­trated in Figure 8.12.

8.9.2 Purpose of a CBS

The CBS will be created and struc­tured at a suffi­cient level of detail to allow
budgets to be set, and costs to be collec­ted, recor­ded, monitored and controlled.
Thus, it must be mirrored in the organ­isa­tion’s account­ing system as well as the
project’s report­ing system. In some organ­isa­tions, the CBS will be set as a

69
Planning, Scheduling, Monitoring and Control

Figure 8.12 Cost break­down struc­ture

stand­ard and therefore imposed upon the project. In prac­tice, this could influ­ence
(or possibly hinder) the project report­ing system, so it needs to be taken into
account in the estab­lish­ment of all break­down struc­tures. Indeed, it may be
neces­sary in these circum­stances to put a project specific cost collec­tion system
in place, which will require serious design and specific­a­tion, as well as new
busi­ness processes and train­ing.
The CBS is some­times known as the ‘£ RAM’, for example in the defence
sector.

8.10 Resources break­down struc­ture

8.10.1 Definition of a RBS
A resource break­down struc­ture (RBS) is a hier­arch­ical struc­ture that groups
resources that are required to deliver the scope by func­tion, type and grade.
Resources may include person­nel (defined indi­vidu­ally or by discip­line), tools,

70
 Breakdown struc­tures

machinery, mater­i­als and equip­ment. Any resource that incurs a cost should be
included in the RBS.

8.10.2 Purpose of a RBS

The RBS will be created and struc­tured at a suffi­cient level of detail to allow the
work to be sched­uled, monitored and controlled.

71
9.1 Definition of depend­ency manage­ment
Dependency manage­ment is the process of monit­or­ing and controlling the key
inter­faces on a project.

9.2 Purpose of depend­ency manage­ment

On a typical project there are many inter­faces. For the smooth and effi­cient
running of a project, interfaces need to be care­fully and regu­larly monitored and
controlled.
At a high level they can be between differ­ent organ­isa­tions:

• suppli­ers;
• discip­lines;
• client;
• third parties;
• sub-contractors;
• other agen­cies (more typic­ally in Ministry of Defence projects).

Within the project, there can be inter­faces for the follow­ing:

• approval gate­ways;
• design reviews;
• client assur­ance reviews;
• consulta­tion;
• discip­line integ­ra­tion/coordin­a­tion.

73
Planning, Scheduling, Monitoring and Control

9.3 Interface scope

It is import­ant that the scope of the inter­face between the parties is defined,
agreed and, if appro­pri­ate, docu­mented. There will be inputs and outputs, and it
is import­ant that these are defined and docu­mented to ensure that they align.
Milestones will be intro­duced into sched­ules to repres­ent each inter­face.
Whilst the funda­mental purpose of the inter­face mile­stone is to high­light the
passing of a section or piece of work to another party, they may also prove to be
a useful way of monit­or­ing progress and perform­ance.

9.4 Schedule impact

Wherever the inter­face is in the sched­ule, it can have a signi­fic­ant impact on
other activ­it­ies. For example, an inter­face may relate to the handover of a piece of
work from one team to another. So, if the ‘giving’ party is late, it could have a
detri­mental impact on the ‘receiv­ing’ party, perhaps causing a crit­ical delay to a
key mile­stone. Consequently, there is a need to commu­nic­ate progress of the
inter­faces between both parties, for example:

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

• Is the piece of work required earlier than origin­ally advised due to chan­ging
circum­stances?
• Are there any other changes affect­ing the scope of the inter­face?

Since the consequences of inter­faces can include delays to the ‘receiv­ing’ party,
or accel­er­a­tion to the ‘giving’ party, there can be expens­ive consequences if they
are not well managed. The creation of a separ­ate sched­ule to enable proact­ive
manage­ment of depend­en­cies is discussed in Chapter 16.

74
Health, safety and environment (HSE) is a key area of risk that needs to be
planned and managed. Since it is import­ant and stra­tegic in terms of project
success, it must be driven from the very top of the organ­isa­tion and be given at
least equal status to other discip­lines when plan­ning a project. Considering HSE
at the plan­ning level allows all activ­it­ies required to complete the project to be
allowed for, and, perhaps more import­antly, safety to be considered when meth­
od­o­lo­gies are derived, such that any unne­ces­sary safety risks are planned out of
the project.
It should be recog­nised that all change must be considered in the light of HSE
concerns, as acci­dents and near misses are frequently caused by last-minute
changes of plan, which by their nature may not have received full consid­er­a­tion
in the way that long-planned activ­it­ies have.
From a schedul­ing point of view, it is import­ant to consider any health, safety
and environmental aspects that will need to be incor­por­ated into the sched­ule.
Whilst this guide is not a compre­hens­ive guide to HSE issues, this section touches
on some import­ant issues to be considered in the plan­ning and schedul­ing of a
project.

10.1 HSE issues at stra­tegic level (plan­ning)

Health and safety should always be the first prior­ity on any project, but there are
some indus­tries where there will be an even greater emphasis: e.g. rail, airports,
nuclear and petro-chem. In addi­tion, any project that has an inter­face with the
public will need to make special provi­sions to ensure the protec­tion of the public.
This is likely to involve consulta­tion with various local author­it­ies and emer­gency

75
Planning, Scheduling, Monitoring and Control

services to ensure that the effect on the public and these services is considered
and their require­ments must be complied with. When design­ing the sched­ule, it
is import­ant to do so with the relev­ant level of safety in mind. For example, the
afore­men­tioned indus­tries would all require labour to have special train­ing/
secur­ity clear­ance prior to being able to work on site.
It is essen­tial that project working areas are estab­lished with a clear set of rules
and respons­ib­il­it­ies:

• Methodology: for example, pre-fabrication off site; sequen­cing to avoid the

need for rework, trades working out of sequence or last-minute changes.
• Time must be allowed in the sched­ule for obtain­ing neces­sary safety permits,
which in some indus­tries may take months.

10.2 HSE issues at tactical level

(schedul­ing and method state­ments)
At tactical level, plan­ning for health and safety is about the sequen­cing of tasks at
a detailed level; some factors to consider include:

• Ensure that safe protec­tion is provided to all work­forces, and safety zones are
created around danger­ous oper­a­tions.
• Ensure segreg­a­tion of work­force and public – in partic­ul­ar, safe access and
egress of large vehicles and plant from construc­tion sites or assembly plants.
• Segregation within the project envir­on­ment is also essen­tial where it can be
managed – for example, the separ­a­tion of machines and people.
• Ensure the secur­ity of the project.

As part of the plan­ning, method selec­tion and schedul­ing process, safety items
should be considered. Any hazards that are iden­ti­fied must be repor­ted to the
relev­ant author­it­ies or line manage­ment.
This guide does not seek to give industry-specific advice, but the prin­ciple of
consid­er­ing HSE in the stra­tegic and tactical plan­ning of work is an oblig­a­tion on
all involved in plan­ning.

76
11.1 Definition of cost estim­at­ing
Cost estim­at­ing is the process used to quantify the cost of services, mater­i­als and
resources required to deliver a project.
An estim­ate should be robust and repeat­able. The estim­ate should contain the
source inform­a­tion used to calcu­late the estim­ate and asso­ci­ated assump­tions.

11.2 Purpose of a cost estim­ate

The purpose of a cost estim­ate is to determ­ine the likely cost of the project. It may
have a number of uses, for example to create budgets, to draft propos­als, to
tender for work or to get approval for research studies. Depending on its purpose,
the scope and detail of the cost estim­ate will vary.

11.3 Cost estim­at­ing and

the project life cycle
Cost estim­at­ing has four main stages, as shown in Figure 11.1.

77
Planning, Scheduling, Monitoring and Control

Figure 11.1 Cost estim­at­ing process

11.4 Estimate types

Estimates are produced at various stages through­out the project life cycle and for
various purposes. The type of estim­ate to be prepared and the meth­od­o­logy to
be employed are depend­ent on the purpose of the estim­ate and the level of
scope defin­i­tion.

11.4.1 Scope development estimates

The types of estim­ate that support the differ­ent stages of scope devel­op­ment
typic­ally fall into three broad categor­ies:

11.4.1.1 Planning
The plan­ning stage is the earli­est stage in scope devel­op­ment. Typically
estim­ates are termed ‘concep­tual’ or ‘pre-conceptual’ and will rely primar­ily
on approx­im­ate methods. Estimates prepared at this stage of the plan­ning
process may be termed order of magnitude (OM) or rough order of magnitude
(ROM).

78
 Cost estimating

11.4.1.2 Preliminary
The prelim­in­ary stage is the next stage in scope defin­i­tion. Preliminary estim­ates
should use defin­it­ive methods for the next stage of scope defin­i­tion; however, it
is accept­able to use approx­im­ate methods for those areas of scope remain­ing
undefined.

11.4.1.3 Definitive
The defin­it­ive stage is the final stage in scope devel­op­ment. Definitive estim­ates
are prepared using defin­it­ive (detailed) estim­at­ing methods.

11.4.2 Other types of estim­ate

Other types of estim­ate prepared at various points in the project life cycle include:

11.4.2.1 Optioneering
Optioneering estim­ates are prepared to estab­lish the cost differ­ences between
two or more altern­at­ive strategies in order to arrive at ranking of altern­at­ives to
inform an economic decision. Both approx­im­ate and defin­it­ive methods are
appro­pri­ate for these types of estim­ates, depend­ing on the level of scope defin­i­
tion. These are described later in this section.

11.4.2.2 Fair Price

A fair price estim­ate is used to determ­ine the reas­on­able­ness of compet­it­ive or
sole source bids received in connec­tion with a proposed sub-contract, and serves
as a control in eval­u­at­ing cost and pricing data in a contract nego­ti­ation. These
estim­ates are used in support of change orders or sub-contract compens­a­tion
event eval­u­ations. The estim­ate should be produced against an identical scope to
that provided to the sub-contractor. Confidentiality of the estim­ate is essen­tial at
all stages of the process.

11.4.2.3 Independent cost estim­ate

Independent cost estim­ates are estim­ates prepared by external or third parties
with the express purpose of valid­at­ing, cross-checking or analys­ing estim­ates
developed by project teams.

79
Planning, Scheduling, Monitoring and Control

11.5 Contents of an estim­ate

Estimates should be estab­lished after the comple­tion of the project defin­i­tion
phase and in conjunc­tion with other elements of the plan­ning phase. That is:

• They should be based on the defined scope and require­ments.

• They should be based on estab­lished codes and stand­ards.
• They should be based on the selec­ted procure­ment plan­ning or contract­ing
strategy.
• They should correl­ate with the sched­ule (i.e. allow­ances for time in the
estim­ate should match those in the sched­ule).
• They should recog­nise the avail­able resources.
• They should be based on any known unit rates, with productiv­ity assump­tions
taken into account.
• They should recog­nise any stated exclu­sions.

An estim­ate should contain both a robust base estim­ate and a real­istic contin­
gency budget.

11.6 Estimating meth­od­ol­o­gies

The estim­at­ing meth­od­o­logy to be employed is directly related to the stage of scope
devel­op­ment. These are typic­ally divided into ‘approx­im­ate’ and ‘defin­it­ive’ methods.
Approximate methods should be used for estim­at­ing projects in the longer
term, with defin­it­ive methods being used as the project moves towards and into
the near term.
Depending on the estim­ate purpose and the scope defin­i­tion, differ­ent phases
of the project may require differ­ent estim­at­ing methods. It is, there­fore, not
uncom­mon to include both defin­it­ive and approx­im­ate estim­at­ing tech­niques
within the same project estim­ate.
The main estim­at­ing meth­od­ol­o­gies within these categor­ies are as follows.

11.6.1 Approximate estim­at­ing methods

11.6.1.1 Specific analogy estim­at­ing
This method of estim­at­ing is based upon select­ing a costed project that is
similar or related to the project costs being estim­ated. It uses the known cost of

80
 Cost estimating

an item/activ­ity used in the prior project as the basis for the cost of a similar item/
activ­ity in the new project. Adjustments are made to account for differ­ences in
relat­ive size/complex­ity of perform­ance, design or oper­a­tional char­ac­ter­ist­ics.
This approach works well for deriv­at­ive or evol­u­tion­ary projects but is unsuit­able
for radical changes or substan­tially differ­ent projects.

11.6.1.2 Parametric estim­at­ing (estim­at­ing norms)

Parametric estim­at­ing uses a meth­od­o­logy that is based on elements of cost
extrac­ted or gleaned from histor­ical data acquired from similar systems or sub-
systems. The data is analysed to find correl­a­tions between cost drivers and
other system para­met­ers, such as size, design or perform­ance, to derive cost
estim­at­ing rela­tion­ships (CERs) that can be scaled and applied to similar systems
in differ­ent projects to determine likely costs. The derived correl­a­tions are
expressed as equa­tions or cost estim­at­ing rela­tion­ships, which can be simple cost
factor ratios or more complex rela­tional equa­tions. The para­met­ric approach
enables costs to be gener­ated quickly from limited data. Care needs to be
exer­cised to ensure that the project being estim­ated is within the bounds of the
CER selec­ted.
The major differ­ence between analogy estim­ates and para­met­ric estim­ates is
that the para­met­ric estim­ates use a data­base of out-turn data from completed
projects upon which to base the cost estim­ate, whereas the analogy estim­ate may
use data from as few as one or two completed projects.

11.6.1.3 Delphi tech­nique

This is a tech­nique based on the prin­ciple that estim­ates from an exper­i­enced
and struc­tured panel can provide a useful judgement-based output. This
approach can be used where analog­ous or para­met­ric data is not avail­able.
Several special­ists are consul­ted in a system­atic manner using a series of ques­
tion­naires, and answers are then refined based upon feed­back from the panel.
The range of answers will gradu­ally decrease until a consensus estim­ate is estab­
lished. Expert judge­ment estim­ates tend to become more accur­ate as more
experts are consul­ted. It is import­ant to note that responses are kept anonym­ous
to ensure impar­tial advice is given.

81
Planning, Scheduling, Monitoring and Control

11.6.2 Definitive estim­at­ing methods

11.6.2.1 Detailed
Generally based upon a specific­a­tion and set of draw­ings which are used to
‘take-off’ meas­ured quant­it­ies of work required to perform each discrete task to
which known or stand­ard unit rates can be applied. Also known as ‘bottom-up’,
‘meas­ured quants’, ‘full detail’ or ‘unit cost’. For a design, engin­eer­ing or services
estim­ate, it should be based on quan­ti­fied deliv­er­ables (draw­ings, reports, safety
cases, etc.) for which estab­lished norms are avail­able.

11.6.2.2 ‘Activity-based cost’ (ABC) estim­at­ing

ABC estim­at­ing is based upon applic­a­tion of a compos­ite all-in rate to a specified
team or crew of workers. This method of estim­at­ing organ­ises the work into
activ­it­ies that will be accom­plished by a specific gang or team of workers. The
estim­ated time taken to complete the work activ­ity is multi­plied by the compos­ite
hourly rate for the gang, together with addi­tions for mater­i­als and equip­ment.
Examples include dismant­ling and decom­mis­sion­ing redund­ant nuclear facil­it­ies.

11.6.2.3 Task analysis

The activ­ity is broken down into discretely estim­ated resource types and
quant­it­ies (labour, mater­i­als, equip­ment, etc.) required to perform the activ­ity,
which is then priced at known or stand­ard unit rates. (Also known as ‘resource-
based estim­at­ing’.)

11.6.2.4 Level of effort/business-as-usual/prelims

Used when a minimum level of support is required regard­less of the number
of tasks to be carried out or in the absence of meas­ur­able or quan­ti­fia­ ble
outputs. This method should be reserved strictly for manage­ment and support-
type activ­it­ies that cannot be assigned to a specific work scope or quan­ti­fi­able
deliv­er­ables.

82
12.1 Definition of budget­ing
Budgeting is the process of alloc­at­ing appro­pri­ate budgets to differ­ent parts of
the work break­down struc­ture. Budgets are often expressed in terms of money,
but may equally be described in terms of other resources such as labour, plant or
mater­i­als.

12.2 Purpose of budget­ing

Budgets are set in order to set cost perform­ance targets for the procure­ment and
deliv­ery of the project. The budget will become the basis for a true compar­ison
with actual costs incurred during the life of a project (either in a cost value report,
or in earned value analysis). In the former case, the budget will produce the
‘value’ numbers. In earned value analysis it will form the basis of the planned and
earned value.

12.3 Funding and budgets

Funds repres­ent the money avail­able for expendit­ure in the accom­plish­ment of
the effort, and must not be confused with budgets; funds are spent, not budgets.
The estim­ate at comple­tion provides the project team with visib­il­ity of the
expec­ted out-turn of costs and there­fore the funds that will be required to
complete the project. Performance against the budget will be used as an indic­ator
of the rate of spend until comple­tion of the project.

83
Planning, Scheduling, Monitoring and Control

A busi­ness’s finan­cial budget is based on iden­ti­fic­a­tion and manage­ment of

project budgets in line with avail­able capital expendit­ure (funds). This is an
iter­at­ive process usually done on an annual basis.

12.4 Producing a cost budget

12.4.1 Cost break­down struc­ture
Cost budgets usually start with a procure­ment strategy, an estim­ate and the cost
break­down struc­ture. Once contracts are let, the cost inform­a­tion is organ­ised by
contract deliv­er­ables and mapped to work pack­ages for the purpose of budget­ing.
Table 12.1 shows an example of a simple cost budget.
When the project’s budget is produced, it is import­ant to ensure that there is
a direct link between the project’s estim­ated costs and activ­it­ies within the
sched­ule (CBS and WBS). Most modern plan­ning tools will provide a cost profile
based on the time-phased activ­it­ies and sched­ule logic. As the project progresses,
it is import­ant to main­tain an align­ment of cost and time so you can fore­cast as
accur­ately as possible, see Figure 12.1.

12.4.2 Cash-flow state­ments

Once budgets have been distrib­uted, it has some­times been tradi­tional prac­tice
to create cost or cash-flow fore­casts in spread­sheets. Often this is done from a
top-down approach, and this is very disjoin­ted from the sched­ule. It is, there­fore,
unlikely that mean­ing­ful results will be achieved, and certainly it is not easy to
adjust and realign these fore­casts as the working sched­ule changes. Thus, it is
preferable to use schedul­ing soft­ware to produce fore­casts. The budgets are
alloc­ated to activ­it­ies (note: not summary bars) in the project sched­ule.

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
 Budgeting

Figure 12.1 Time meas­ured in finan­cial periods

Once the budget is alloc­ated in the schedul­ing soft­ware, ‘S-curves’ can be

drawn. These will most likely be based on the early dates, as this is how schedul­ing
soft­ware usually defaults. In reality, these activ­it­ies may have an element of float
and are subject to unfore­seen change. When attempt­ing to fore­cast costs, it is
import­ant to factor in these vari­ances, other­wise you risk putting an overly
aggress­ive or optim­istic finan­cial view to the project manager and busi­ness.

85
Planning, Scheduling, Monitoring and Control

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

flawed, as it would be hope­lessly pess­im­istic. No project should assume that late
dates are accept­able to work to, as they would make comple­tion on time
unachiev­able – unless the project encoun­ters no risk real­isa­tion, no resource
limit­a­tion and no failure of any other kind. This never happens.
One way to factor in reality is to use a ‘mid curve’ or ‘banana curve’
(Figure 12.2). This process uses sched­ule logic to plot an early and a late curve
and calcu­lates the midpoint between the two. This then allows for a portion
of project float to be consumed and presents a more real­istic cost fore­cast
whilst keeping the sched­ule aggress­ive and the project team focused on early
comple­tion.

Figure 12.2 Generating a cost fore­cast using a banana curve

86
 Budgeting

12.5 Budget trans­fers

Budget trans­fers are made through a change control process to form­al­ise the
move­ment of scope (budget and sched­ule) from one part of the project to
another, or to move scope into or out of the project.
A second­ary reason for budget trans­fer may be the real­loc­a­tion of budgets in
order to correct data errors, but this must be done through a formal change
control process, and it is wise to limit this only to essen­tial major revi­sions.
Budget trans­fers must never be made in order to mask or account for cost
over- or under­spends, either real­ised or anti­cip­ated.
It is good prac­tice to ensure that trans­fers of budget are commu­nic­ated and
mutu­ally under­stood by both donor and recip­i­ent, and accep­ted and docu­mented.

87
 Part Three

Scheduling

‘The key is not to prior­it­ise what’s on your sched­ule, but to sched­ule your
prior­it­ies.’
Stephen Covey
13.1 Definition of scheduling
Scheduling can be seen as a science compared with the art of plan­ning; it usually
involves the input of the plan into schedul­ing soft­ware. It involves the calcu­la­tion
of dura­tion and resources required; it defines the logic and sequence and the
calcu­la­tion of crit­ical path, float, and start and finish dates of indi­vidual activ­it­ies,
and thus determ­ines the feas­ib­il­ity of deliv­er­ing the project within the desired
comple­tion dates and budget.
Scheduling is:

• integ­rat­ing differ­ent parts of the project;

• iden­ti­fic­a­tion and manage­ment of inter­de­pend­en­cies;
• the iden­ti­fic­a­tion of specific activ­it­ies, and the resources required to deliver them;
• devel­op­ing a logical sequence of works based on the plan­ning strategy and
meth­od­o­lo­gies to be adopted;
• estab­lish­ing expec­ted output rates to be used in the calcu­la­tion of dura­tions,
and hence dates for each of these activ­it­ies;
• under­tak­ing these calcu­la­tions;
• identi­fy­ing the crit­ical path and estab­lish­ing prior­it­ies;
• making due allow­ances for risks (risk mitig­a­tion plan­ning) in the sched­ule.

13.2 Purpose of scheduling

The purpose of schedul­ing is to create the follow­ing outputs to enable the
manage­ment of the project:

91
Planning, Scheduling, Monitoring and Control

• the sequence of project tasks;

• the start and finish dates of all project tasks;
• the crit­ical path (the longest path through the project);
• calcu­lated project float;
• a compre­hens­ive under­stand­ing of logical depend­en­cies between tasks;
• the resources required to complete the project;
• a sched­ule that the project team will use to deliver the work. This may include
various sched­ules dealing with inter­faces, key dates etc.;
• diagrams, sequen­cing draw­ings etc. to assist in explain­ing sequences and
timing.

Thus, schedul­ing:

• helps make decisions about strategies and methods considered as part of the
plan­ning process;
• focuses manage­ment atten­tion on the most import­ant issues and activ­it­ies;
• considers work calen­dars;
• considers time contin­gency;
• starts at stra­tegic level and is decom­posed into medium and short-term
schedul­ing;
• defines the sequence of activ­it­ies with which the project goals can be accom­
plished;
• quan­ti­fies the resources required and cost to be expec­ted as a result of project
execu­tion;
• clearly defines the scope of work;
• optim­ises the use of resources.

13.3 The scheduling process

13.3.1 Steps in establishing the schedule

• Review the busi­ness case.

• Review the project require­ments and estab­lish key deliv­er­ables and risks;
define the scope of work.

92
 Introduction to scheduling

• Develop the product break­down struc­ture and work break­down struc­ture

(PBS/WBS).
• Develop an organ­isa­tion break­down struc­ture (OBS) and other project
structures.
• Determine and agree the project control require­ments with all relev­ant
stakehold­ers.
• Create the network diagram: sequence the work (refer­ring to the scope docu­
ment­a­tion), estab­lish tech­nical constraints/logic, estim­ate dura­tions and
identify key mile­stones.
• Ensure consist­ency between differ­ent levels of sched­ule (vertical integ­ra­tion)
and between sched­ules at the same level (hori­zontal integ­ra­tion).
• Develop a sched­ule that meets the project required dates, using activ­it­ies and
mile­stones, which should be fully logic-linked and constraint-free.
• Group the activ­it­ies into work pack­ages and plan­ning pack­ages in accord­ance
with the project struc­tures.
• Assign resources to activ­it­ies (labour, mater­ial, sub-contracts, and other direct
costs).
• Assign budgets to activ­it­ies.
• Run a forward and back­ward pass and ensure that the crit­ical path runs
continu­ously from the first activ­ity to the last activ­ity; check for other crit­ical
paths and the crit­ical path drivers.

See Figure 13.1 for an over­view of the schedul­ing process.

13.3.2 Once the sched­ule is created

• Perform sched­ule integ­rity checks to ensure the robust­ness of the sched­ule.

• Undertake the appro­pri­ate level of quant­it­at­ive sched­ule risk analysis.
• Issue the baseline with the appro­pri­ate level of author­ity and under formal
change control.
• Monitor the progress of deliv­ery of the plan, and control diver­gences from the
original plan.

93
Planning, Scheduling, Monitoring and Control

Figure 13.1 The schedul­ing process in the context of plan­ning, monit­or­ing

and control

13.4 Schedule structure

13.4.1 Schedule density

13.4.1.1 Definition of schedule density

Reference is often made to ‘levels’ of sched­ules or plan­ning; for example, level 1
may refer to the highest-level stra­tegic sched­ule, level 3 may be the working
sched­ule and level 5 the short-term, week-by-week sched­ule. Different organ­
isa­tions have differ­ent defin­i­tions of these, so to avoid confu­sion this guide will
take the lead of the CIOB’s Guide to Time Management in Complex Projects and
refer to schedul­ing ‘density’, where low density means the higher levels or
stra­tegic sched­ules (perhaps simpli­fied sched­ules for commu­nic­a­tion), medium
density means the working sched­ule, and high-density means the week-to-week,
day-to-day or shut-down schedul­ing.

94
Table 13.1 Features asso­ci­ated with density of sched­ules
Density Timescale Activity Typical Budget/ Logic Lags Calendars Cost Contingencies Comment
names activ­ity resource (example) alloc­a­tion
dura­tion loading

Low – the +1 year Will tend Per each Major Logic May be Generic Major Since Adequate level
highest from to be element budget links of included working budget­ary dura­tions will of detail for
level(s) of now elemental, groups various for week with groups be calcu­lated feas­ib­il­ity
sched­ule describ­ing types will illus­trat­ive stat­utory such as using checks only; in
key parts be used purposes; and designer, empir­ical later sched­ules
of the to best negat­ive typical contractor, data, a high appro­pri­ate
project describe lags should industry client costs degree of level of detail
the never be holi­days contin­gency for stra­tegic
sequence used even included is required. over­view
at this level Quantitative picture only
sched­ule risk
analysis may
be applied to
determ­ine

Medium 3months A further Indicative Allocated Mainly Some lags Activity- Cost Risk should Sufficient detail
– 1 year defin­i­tion dura­tion: to finish to may exist, based coding be reduced of alloc­a­tion to
from into key 4–8 activ­it­ies start links though the calen­dars should be with greater partic­u­lar
now parts or weeks. for (FS) will propor­tion estab­ clarity. Clear contract­ors or
products Durations first-pass be used will be lished at iden­ti­fic­a­tion other resources
of the may be baseline much this stage of the risk to allow pricing
project derived reduced (float) owner and resource
from at this level alloc­a­tion
typical
outputs

(Continued)
Table 13.1 Continued
Density Timescale Activity Typical Budget/ Logic Lags Calendars Cost Contingencies Comment
names activ­ity resource (example) alloc­a­tion
dura­tion loading

High – the Next 3 Clear, Indicative Baseline Mainly Rarely Resource- All Clear Adequate for
lowest months unam­bigu­ dura­tion: set and finish to accept­able; based resources iden­ti­fic­a­tion detailed
level(s) of ous and 2–4 weeks not start links gener­ally calen­dars must be of the risk descrip­tion,
sched­ule precise Durations subject to (FS) will replaced in place if iden­ti­fied (float) owner creation of
with will be change be used by activ­it­ies relev­ant and all at this level. day-to-day
refer­ence derived with FS relev­ant Design or sched­ules, and
to specific from links activ­ity vari­ation risks progress
loca­tion or outputs coded should not be report­ing.
resource and required at Detailed design
discus­sion this level is complete and
methods
defined and
agreed
 Introduction to scheduling

Figure 13.2 Relationship of differ­ent dens­it­ies in sched­ules

13.4.1.2 Typical features asso­ci­ated with density of sched­ules

Figure 13.2 shows the rela­tion­ships between the differ­ent levels or density of
sched­ules on a typical project – note the direc­tions of the arrows between the
boxes, which relate to the genesis of each revi­sion or update of the sched­ule.
This diagram, there­fore, repres­ents the rela­tion­ship of various sched­ules in the
execu­tion phase.
It is useful to define a hier­archy of sched­ules that will be used to describe to
the project team (and others) the rela­tion­ship between differ­ent sched­ules that
are (to be) produced. A simple diagram of such a descrip­tion is shown in Figure
13.3, although it will be useful to define which (if any) sched­ules are contained in
the same soft­ware data­base. For example, as shown by the yellow box in the
diagram.

97
Planning, Scheduling, Monitoring and Control

Figure 13.3 A hier­archy of plans and plan­ning docu­ments

13.4.2 Detail density: consid­er­a­tions

Schedules must be produced with the target audi­ence in mind. For example, it is
likely that senior manage­ment will require low-­density sched­ules that explain
blocks of activ­ity and major depend­en­cies and logic links. Management decision
making will require medium-density plans, whilst day-to-day super­vi­sion of
works will require high-density plan­ning and schedul­ing. Schedules with an inap­
pro­pri­ate level of detail may become useless.

13.4.2.1 Schedules with too much detail

Too much detail produces very large sched­ules. Large sched­ules with correct
logic take a long time to produce. When change comes – for whatever reason –
they can be very diffi­cult to revise. A sched­ule that cannot be easily modi­fied
loses its value as a report­ing or manage­ment/decision-making tool. With greater

98
 Introduction to scheduling

levels of detail comes the risk of errors. Complex logic can hide errors, which will
be harder to pick up in a very large sched­ule.
Also, very large sched­ules are less likely to be read and/or used. It is import­ant
to remem­ber the target audi­ence. The sched­ule should be in adequate detail for
the correct monit­or­ing of the project.

13.4.2.2 Schedules with inad­equate detail

Schedules with not enough detail should also be avoided. Too low a density in
plan­ning will create sched­ules that do not fulfil their main purpose – to help
coordin­ate and direct the work. If the activ­it­ies are too large, then import­ant logic
may be missed, and crit­ical tasks over­looked. This could result in a sched­ule that
cannot be used to accur­ately monitor the progress of the work.

13.4.2.3 Detail density: prin­ciples

• At high density, every activ­ity should repres­ent the work of only one resource.
This may mean a single trade or even an indi­vidual.
• Low density may require a more generic defin­i­tion of resource, for example
‘imple­ment­a­tion team’ or ‘civils work’.
• Probably at medium density, and certainly at high density, there should be
suffi­cient detail to allow only finish to start rela­tion­ships.
• All activ­it­ies 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 (frag­nets)

Network templates are usually adopted for repet­it­ive sections of sched­ules, e.g.
floors of a multi-storey build­ing. They can be used to quickly build up a sched­ule
made up of many similar phases or sections. They are copied and pasted into a
sched­ule to enable a repet­it­ive sched­ule to be built up quickly without having to
keep typing in the same activ­it­ies.

99
14.1 Schedule types: time-based
There are a number of differ­ent types of time-phased sched­ule, created at various
stages and by various parties with subtly differ­ing purposes and aims. In order for
a project to have clarity, it is import­ant for these to be limited to the key sched­ules
described below.

14.1.1 Development or stra­tegic sched­ule

This is usually the highest level of logic-driven sched­ule. This will very likely be
created by the customer at the incep­tion of a project. It should incor­por­ate the
major elements of the work and include all the key dates. Development sched­ules
are usually low-density sched­ules.

14.1.1.1 Purpose
• To provide an outline of the project para­met­ers in terms of scope and time.
• To define project gateway stages, includ­ing key ‘go/no-go’ points.
• To illus­trate the approvals required for the project to proceed.
• To incor­por­ate key dates over the life of the project.
• To identify a high-level crit­ical path for the project.
• To show the key integ­ra­tion events and accept­ance points.

101
Planning, Scheduling, Monitoring and Control

14.1.1.2 The sched­ule will include

• Overall comple­tion date.
• Sectional and key dates.
• Details of approval stages through­out the project.
• Third party inputs or outputs.

14.1.2 Tender sched­ule (or ‘bid sched­ule’)

These sched­ules are created by a contractor/supplier or other deliv­ery organ­isa­
tion when tender­ing or bidding for work. They can be crit­ical to winning or losing
a bid for work. Tender sched­ules are likely to be medium-density sched­ules.

14.1.2.1 Purpose
• To assist in the pricing of the tender.
• To identify and commu­nic­ate the meth­od­o­lo­gies and times­cale for deliv­er­ing
the project.
• To demon­strate good prac­tice to the review­ing author­ity/customer/client.
• To show the level of resources required to complete the works.
• To define key tech­no­lo­gies being proposed and their levels of matur­ity.
• To define information-required dates.
• To show inputs required from third parties.
• To show all key inter­faces.
• To make adequate allow­ances for risk and sched­ule uncer­tainty.
• To define the procure­ment strategy.
• To clearly show any works by others.
• To include all util­it­ies and stat­utory under­tak­ings.

14.1.3 Contract sched­ule

This is the sched­ule that has been signed up to in the contract. It should be
agreed at the start of a contract or programme of works. In a hier­archy of import­
ance, this is prob­ably the most import­ant sched­ule. It should cover all the scope,
whether design, procure­ment, install­a­tion or commis­sion­ing. It is the sched­ule
that will form the baseline, and there­fore the progress of the works will be

102
 Types of schedule

meas­ured against it. In all contracts there should always be a ‘current’ contract
sched­ule. There may be changes through­out a project, but, once instruc­ted,
these should be included in the contract sched­ule.
This is the sched­ule against which the cause and cost of any delays are
calcu­lated. It is the sched­ule that is used as the basis for all monthly or period
progress report­ing, so it should be at a suit­able level of detail. Contract sched­ules
are likely to be medium-density sched­ules.

14.1.4 Baseline sched­ule

Generally the first working sched­ule (or contract sched­ule) will be copied and set
as the baseline sched­ule. The baseline should be main­tained as change is
approved. The baseline sched­ule will reflect the density of schedul­ing that it
relates to, and is thus likely to be a medium-density sched­ule.

14.1.5 Summary sched­ule

This is a pictorial, created to explain in very simple terms the sched­ule and its
contents. Whilst it is possible to create such a sched­ule by rolling up activ­it­ies in
the main sched­ule soft­ware, this is unlikely to produce a clear, logical and well-
presented view of the project. It is, there­fore, better created in isol­a­tion and is
often best presen­ted in non-schedul­ing soft­ware. Spread­sheets or present­a­
tional tools are partic­ul­arly good for this type of sched­ule. Summary sched­ules
will always be low-density sched­ules.

14.1.6 Working sched­ule or ‘fore­cast sched­ule’

It is likely that this will be developed from the tender, or other earlier sched­ule. It
should include all activ­it­ies relat­ing to the deliv­ery phase, includ­ing design activ­
it­ies, procure­ment activ­it­ies, install­a­tion and commis­sion­ing tasks. Working
sched­ules are likely to be medium-density sched­ules.

14.1.6.1 Purpose
The working sched­ule directs deliv­ery in the optimum sequence, on time and to
cost. Thus, the purpose is to manage the activ­it­ies that are to be under­taken on
an ongoing basis.

103
Planning, Scheduling, Monitoring and Control

14.1.6.2 The sched­ule will include

• Design.
• Procure­ment sched­ule.
• Approval periods.
• Manu­fac­ture.
• Build.
• Tempor­ary works.
• Traffic manage­ment (and logist­ics).
• Labour and plant resources.
• Integ­ra­tion activ­it­ies.
• Test, commis­sion­ing and accept­ance activ­it­ies.
• Handover and clos­eout process.
• Support activ­it­ies.

14.1.7 Target sched­ule

Some projects run with target sched­ules. These can be set by contract­ors
to chal­lenge the work­force to complete a project earlier than the contrac­ted
date. Target sched­ules will reflect the density of the sched­ule from which
they are created, and are thus likely to be medium-density sched­ules. However,
they may cover the short-­term only, and are thus likely to be created at high
density.

• Advantages:
• easy to do and under­stand;
• focuses the project team on early deliv­ery.
• Disadvantages:
• requires rebal­an­cing of the time/cost/scope/ quality triangle (Figure 14.1);
• requires soft­ware;
• purely tactical, no stra­tegic view;
• distracts from ‘one version of the truth’ report­ing;
• dilutes focus, as there is more than one sched­ule to consider and under­
stand;
• may engender compla­cency if it is known that the target sched­ule is not the
defin­it­ive sched­ule.

104
 Types of schedule

Figure 14.1 Distorting the time/cost/quality triangle

14.1.8 Short- and medium-term schedules

Medium-term sched­ules will typic­ally be extracts of the working sched­ule. The
extracts are made to facil­it­ate day-to-day plan­ning of the works that will become
the short-term sched­ules. They are typic­ally named to reflect the period of time
that they cover. Examples of how they may be named include:
• three-month look ahead (medium-term sched­ule);
• four-week look ahead (short-term sched­ule).
It is very likely that these sched­ules will be high-density sched­ules, espe­cially if
they are weekly ‘look aheads’; monthly ‘look aheads’ may be medium-density.

14.1.9 As-built schedule

This is the sched­ule that will be developed through­out the life of the project, to
provide a record of what actu­ally happened during the course of the project. It will
be useful for learn­ing from exper­i­ence in the lessons learned process, or possibly

105
Planning, Scheduling, Monitoring and Control

employed in the use of making or rebut­ting claims on the contract. ‘As-built’

sched­ules are likely to be created at medium- or high-density schedul­ing.
Additional items that this sched­ule will include:
• baselined or original planned dates;
• actual start and actual finish dates for each activ­ity;
• details of change events;
• details of delay events.

14.1.10 Post-build schedule

The ‘as-built’ sched­ule is created as the project proceeds. In its absence it may
be neces­sary to construct a post-build sched­ule. It is created once the project
has finished. It is built from histor­ical records, but shares the aim of the ‘as-built’
sched­ule, in that it is created to make or rebut claims. This type of sched­ule
would be created as a last resort, as you would expect an ‘as-built’ sched­ule to be
in place; when it is not, this approach may be appro­pri­ate. Post-build sched­ules
are likely to be created at medium-density schedul­ing (see Figure 14.2).

Figure 14.2 Types of time-phased sched­ules and their rela­tion­ship

106
 Types of schedule

14.1.11 ‘What ifs’ (scen­ario plan­ning)

‘What ifs’ are test sched­ules that can be produced to see what impact a scope,
sched­ule or meth­od­o­logy change may have on the contract dates – or baseline
sched­ule. ‘What ifs’ are produced separ­ately from the working sched­ule. They
are only incor­por­ated once all the implic­a­tions have been examined and the
proposed change is agreed.
They may also be used when a crit­ical delay occurs that impacts contrac­tual
dates. This ‘what if’ sched­ule should show how the works will be re-scheduled to
enable the contrac­tual dates to be met. Any addi­tional working hours or resources
should be clearly iden­ti­fied. This is some­times called the recov­ery sched­ule.

14.2 Schedule types: tracker sched­ules

A tracker sched­ule 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 manage­ment process, rather than activ­it­ies that produce a deliv­er­able,
such as a design or a product. A typical example, the procure­ment sched­ule, is
illus­trated in the follow­ing sections. These are gener­ally and most usefully produced
in spread­sheets that can be accessed and updated without special­ist soft­ware.
It is some­times sugges­ted that the time-phased sched­ule should contain every
step required to complete a project. The prob­lems that this causes however,
include the growth of the sched­ule into an unfocused and in extreme cases,
unman­age­able model. Whilst it is true that every step should be repres­en­ted in
the sched­ule, where there are altern­at­ive and better methods of dealing with
detail these should be kept separ­ate, and updated by the respons­ible manager to
keep them as a live docu­ment. They must be linked to the time-phased sched­ule,
and these links regu­larly updated. It is usual, and desir­able, for tracker sched­ules
to be created and held in widely access­ible soft­ware, such as a spread­sheet.

14.2.1 Procurement sched­ules

A procure­ment sched­ule is a tracker docu­ment that covers all the required steps
of the procure­ment process. It is used to monitor each stage of the process to
ensure that it is completed on time. The procure­ment sched­ule must be linked to
the working sched­ule or updated on a peri­odic basis. The project-specific periods
will be defined in the project proced­ures.

107
Figure 14.3 A sample procure­ment sched­ule
 Types of schedule

The spread­sheet example shown in Figure 14.3 has the advant­age that it can
be set up to auto­mat­ic­ally update some of the data. Also, spread­sheets are
gener­ally more access­ible to read and update than bar charts, which require
scheduling soft­ware.
An altern­at­ive way of display­ing the procure­ment sched­ule is to adopt a more
tradi­tional time-phased approach, as illus­trated in Figure 14.4, which is best
displayed in scheduling soft­ware.
However, the choice of which method to adopt is a matter of personal
pref­er­ence.

14.2.2 Design deliv­er­ables tracker

A design deliv­er­ables tracker is a docu­ment that covers the full scope of the
design in a list of defined deliv­er­ables for the purpose of track­ing and monit­or­ing.
This may be used as a supple­ment to the design sched­ule, ensur­ing that detailed
track­ing of indi­vidual items is possible. The progress claimed against the tracker
may be tied to payment. The design deliv­er­ables tracker must be linked to the
working sched­ule or updated on a peri­odic basis. The project-specific periods
will be defined in the project proced­ures.
Figure 14.5 shows a method of monit­or­ing the progress of various design
docu­ments until they are complete.

14.2.3 Other tracker sched­ules

The same prin­ciples as outlined above can be applied to many types of activ­ity
(usually manage­ment effort) that are best kept out of the time-phased sched­ule
to ensure proper focus on that sched­ule and proper focus on manage­ment effort
in the deliv­er­able track­ers. Examples of other track­ers that may be useful to keep
detail out of the sched­ule include:

• method state­ment track­ers;

• quality control inspec­tion track­ers;
• consents track­ers;
• construc­tion or install­a­tion track­ers;
• assur­ance docu­ment­a­tion track­ers;
• commis­sion­ing process track­ers;
• handover process track­ers;
• progress tracker sched­ules.

109
Figure 14.4 Time-phased procure­ment sched­ule
Figure 14.5 Design deliv­er­ables tracker
15.1 Definition of sched­ule design
Schedule design refers to consid­er­a­tions and decisions that are made when
setting up the struc­tures for the project. These consid­er­a­tions must be made
prior to commen­cing any schedul­ing work. The decisions that are made should
be detailed in the project-specific proced­ures.

15.2 Purpose of sched­ule design

Making and writing down the decisions around these struc­tures should help to
ensure that time is not wasted in revis­it­ing sched­ules to correct defects in settings,
struc­tures and other tech­nical aspects of schedul­ing.

15.3 Elements of sched­ule design

15.3.1 Activity iden­tity numbers (IDs)
15.3.1.1 Purpose of struc­tured IDs
Activity IDs provide a unique iden­ti­fier for each activ­ity in the sched­ule. The ID
provides the planner with a quick refer­ence that remains constant through­out
the project’s dura­tion. It can be auto-generated by the schedul­ing soft­ware, and
it is import­ant for forensic analysis of the sched­ule that the activ­ity IDs, once
used, are never changed or re-used.

113
Planning, Scheduling, Monitoring and Control

15.3.1.2 Structure
The struc­ture of an ID may well repeat some or all activ­ity codes, but it
can provide a short­hand that the sched­uler can use, for example, to trace logic.
Care should be taken not to over com­plic­ate the struc­ture and the use of letters
to abbre­vi­ate the names of parts of the project (life cycle stages, geographic
areas, etc.).
Structuring activ­ity IDs can often be tailored to the project; there­fore, it is
recom­men­ded to use abbre­vi­ations that can be under­stood, for example life
cycle stages such as DE, CN, TC for design, construct, and test and commis­sion.
Other struc­tures to consider when gener­at­ing activ­ity IDs are:

• geographic loca­tion;
• section of work;
• who does the work?

To main­tain sched­ule integ­rity, it is import­ant never to correct errors post

formal issue of the sched­ule, and not to recycle an activ­ity ID (use of redund­ant
activ­it­ies).

15.3.2 Activity descrip­tions

Activity descrip­tions should be clear and unam­bigu­ous. Ideally, they should
define the work they are describ­ing completely, i.e. not relying on WBS head­ings
to provide context. This is partic­u­larly import­ant when filters or altern­at­ive views
are applied to the sched­ule so that preci­sion and clarity are main­tained.
Descriptions should avoid using acronyms and should write out the full descrip­
tion clearly, as far as is possible (see Table 15.1).
If this is not possible, then the sched­ule should be struc­tured with addi­tional
filters, flags or outline codes which provide further detail on the tasks in the
sched­ule.

Table 15.1 Examples of activ­ity descrip­tions

Bad descrip­tion Good descrip­tion
Design Design – Earthworks
Ground Floor Slab BUILDING 1 – Formwork, Rebar, Pour Ground Floor Slab Grid 4-7/a-f
RFC to 1 Fl
st
Reinforced concrete slab to 1st floor

114
 Schedule design

15.3.3 Different activ­ity types

15.3.3.1 Tasks
Activities are usually ‘doing’ tasks, and there­fore should include a verb, e.g. DIG
found­a­tions; LAY brick­work; INSTALL steel­work.

15.3.3.2 Level of effort activ­it­ies

Generally support activ­it­ies which must be under­taken to support other project
activ­it­ies, level of effort (LOE) activ­it­ies are typic­ally diffi­cult to fore­cast, or
will not add value to the overall schedul­ing logic. Examples of level of effort
activ­it­ies include:

• Project manager: It is diffi­cult to predict where the PM’s effort will be focused
on a daily or weekly basis, as it is gener­ally focused on areas that need support,
which often change regu­larly. Scheduling these activ­it­ies into a high-density
sched­ule would be very time-consuming and would not add value to the
overall logic struc­ture. It is there­fore appro­pri­ate to assign a LOE activ­ity for
the PM span­ning the life of the project, as they are helping to facil­it­ate the
project’s success.
• Planner/Scheduler: Although there may be repet­it­ive work due to the regular
report­ing cycle which can be predicted and sched­uled, it does not add value
to the sched­ule to itemise these activ­it­ies in a low level of detail; there­fore,
LOE is appro­pri­ate.

Level of effort activ­it­ies should be used spar­ingly within schedul­ing, as they do

not provide object­ive time perform­ance meas­ure­ment through meas­ur­able
outputs. Any LOE activ­it­ies used within the schedul­ing should be clearly
iden­ti­fied and their use fully justi­fied.

15.3.3.3 Hammocks
A hammock is a summary activ­ity that will expand and contract depend­ing on the
activ­it­ies that it is linked to. Hammock tasks are very similar to level of effort
(LOE) tasks, differ­ing only in the follow­ing:

• A hammock task does not have a calen­dar assigned to it, whereas a LOE task can
have a specific calen­dar attached (for example, part-time schedul­ing support).

115
Planning, Scheduling, Monitoring and Control

• Only a start-start and finish-finish rela­tion­ship can be assigned to determ­ine

the start and end points of the hammock, whereas a LOE activ­ity can have any
rela­tion­ship type as a prede­cessor and successor.

15.3.3.4 Dummy tasks

Dummy tasks may also be sched­ule visib­il­ity tasks. If an activ­ity is depend­ent on
a lead time, or a customer approval, for example, it may be bene­fi­cial to utilise a
sched­ule visib­il­ity task (SVT), which is a task entered into the schedul­ing soft­ware
with no resource assigned to it, repres­ent­ing the elapsed time of the lead time or
the customer approval time. This could also be used in a construc­tion envir­on­
ment, for curing time, as an example.
The main advant­age in util­ising SVTs rather than leads or lags in the sched­ule
is primar­ily for visib­il­ity. Often, leads and lags are over­looked or hidden in
stand­ard schedul­ing views created by soft­ware tools, and can be over­looked
by the wider team. Appropriate calen­dars may also be applied – for example,
curing activ­it­ies would always work on a seven-day calen­dar, whereas works
around them may not. Adding SVTs into the sched­ule shows clearly the
impact of the ‘waiting time’ and avoids the need to docu­ment lead and lag
justi­fic­a­tion in the notes of the sched­ule, as this can be captured in the SVT
title (e.g. ‘SVT: six week customer review time for sign-­off of Requirements
Document’).

15.3.3.5 Milestones (start, finish)

A mile­stone is an event in a sched­ule with no dura­tion. Examples may include
signi­fic­ant start dates, includ­ing access dates, the commence­ment and comple­tion
of key phases of the project, and other key or contract dates.

15.3.4 Activity steps

When working on a large-scale project, it is some­times prefer­able to manage the
quant­ity of tasks displayed on the sched­ule. It may be more appro­pri­ate to
convert a series of sequen­tial tasks into one task which is suppor­ted by a number
of ‘steps’ or ‘object­ive criteria’. These steps can have pre-agreed progress
weight­ings to estab­lish progress in an object­ive way (Figure 15.1).
It should be noted, however, that this approach is only suit­able for activ­it­ies
which do not have any external prede­cessors (Figure 15.2).

116
 Schedule design

Figure 15.1 Establishing steps/object­ive criteria

Figure 15.2 Suitability for steps/object­ive criteria

117
Planning, Scheduling, Monitoring and Control

If the schedul­ing soft­ware does not have a step func­tion embed­ded, then it is
advised to capture the object­ive criteria in a notes field held within the tool for
trans­par­ency and visib­il­ity.

15.3.5 Time Units

Time units are a scal­able measure of time used to define the dura­tion of activ­it­ies
and the impact of change within the project sched­ule. Choosing an appro­pri­ate
time unit depends on the nature of work being under­taken; however, it is
import­ant to use only one type when devel­op­ing the sched­ule.
The most common types of time unit are days or hours. These units are
gener­ally suit­able for most projects; however, when plan­ning very long, high-level
projects it may be more appro­pri­ate to use weeks. In certain circum­stances,
which are likely to be high-risk and/or relat­ively short-duration works, it may be
appro­pri­ate to sched­ule in minutes. Typical examples would be shut-downs for
main­ten­ance of a process plant, or a closure on a live railway.

15.3.6 Calendars
Calendars are used to define the amount of working and non-working time
through­out the dura­tion of the project. They are used to determ­ine when the
work will be carried out, e.g. night-working or week­ends only.
Generally, they show the normal working week, e.g. Monday–Friday,
8.00–5.00 with 1 hour for lunch. This would result in an 8-hour day and
40-hour working week. In the UK, the 8 stand­ard bank holi­days would
be included. Industry holi­days are usually 1 week at Easter and 2 weeks at
Christmas.
Consider the level of time unit being used (i.e. an 8-hour day may be used,
whatever the real hours are) and decide what is appro­pri­ate for the project. In
other words, and in general terms only, work is often planned in days regard­less
of the soft­ware that may calcu­late dura­tion in hours.

15.3.6.1 General consid­er­a­tions

• Permitted working hours, e.g. airports, rail­ways etc.
• Differing shift patterns, e.g. night-shifts or 7-day working.
• Restrictions at partic­u­lar times or for partic­ul­ar works: for example, some
works may be under­taken at any time, while some require partic­u­lar times,

118
 Schedule design

e.g. booked or planned shut-downs or engin­eer­ing hours (times when the

current is switched off on a railway).
• Planned shut-downs for routine main­ten­ance.
• Resource working hours or avail­ab­il­ity.
• In addi­tion to the project calen­dar, addi­tional specific calen­dars can be set up
to cater for indi­vidual suppli­ers, specific customer avail­ab­il­it­ies, specific
resources, special­ist facil­it­ies, etc.
• Calendars can define report­ing cycles – for example, rail industry periods.

15.3.6.2 Holidays and non-working days

Consider the country or reli­gious parties involved:

• Calendars should contain the relev­ant bank holi­days and week­ends.

• Where relev­ant, they should include any known factory/site shut-downs. For
example, some Jewish developers/contract­ors may close their sites on key
Jewish holi­days.
• Other reli­gious holi­days to consider could be not only in the Middle East, but
also in Europe, India, the US, etc.
• Be careful when setting up calen­dars. For example, the national holi­days in
France: some of the dates stay consist­ent each year, so that if the date falls on
a Saturday or Sunday it is not a national holiday.

15.3.6.3 Applying to sched­ules

Consider how/whether differ­ent calen­dars are applied to the sched­ule:

• A sched­ule can use multiple calen­dars, for both activ­it­ies and resources.
• Take care that calen­dars are correctly assigned, defined and main­tained.
• It is import­ant to clearly define which activ­it­ies take place on which calen­dar.
• An activ­ity cannot take place on multiple activ­ity calen­dars; if there is a need
to show such working, then the activ­ity needs to be duplic­ated so that
each indi­vidual activ­ity occurs solely on one calen­dar. An example of this
could be a situ­ation where a joint team are working on a piece of work
shared between two nations, say the UK and Spain. The Spanish take
most of August off on holiday, whereas the UK contin­ues to work.
Separate calen­dars, and hence separ­ate activ­it­ies, would be needed to
show this.

119
Planning, Scheduling, Monitoring and Control

• Leads and lags should not have calen­dars alloc­ated to them. If a logic link
needs to be on a specific calen­dar, then this should be an activ­ity (dummy
task).

15.3.6.4 Ordinal dates

In some cases it will be appro­pri­ate to display a number, i.e. Week 1, Week 2 etc.
(ordinal dates), rather than calen­dar dates; for example, when tender­ing for work
with an uncer­tain start date. It will be import­ant in these cases to be aware of the
effect of holiday periods and other working restric­tions on the overall dura­tion of
each deliv­er­able and the overall project.

15.3.7 Project, activ­ity and resource coding

Project, activ­ity and resource codes are a flex­ible and power­ful aid to optim­ise
present­a­tion of the project sched­ule. They are gener­ally used to view and analyse
the sched­ule data in multiple ways depend­ing on the specific needs of the
audi­ence.
Applying project codes such as loca­tion, sponsor, phase, asset group, etc. can
also help to view project and group programme or port­fo­lio data in order to
manage inform­a­tion effi­ciently at an enter­prise level. They can also be usefully
used to identify depend­en­cies and inter­faces.
When defin­ing the project WBS, CBS, OBS and RAM, there will be a need to
sort data by differ­ent groups. By assign­ing values to activ­it­ies, it is possible to
quickly view and analyse data in the most appro­pri­ate way.
Coding can be applied to specific activ­ity resources in order to differ­en­ti­ate
between cost accounts, contracts and resource unit inform­a­tion, i.e. concrete,
track, pipe, cable, etc. This inform­a­tion can then be extrac­ted for monit­or­ing and
control.
It is import­ant to define the level of coding required in the final sched­ule prior
to commen­cing work on the sched­ule. This enables easier regular analysis and
report­ing.
A useful tip is to insist that coding fields are popu­lated against every activ­ity,
using a ‘N/A’ code for those that have no applic­able code. This will mean
omis­sions in coding are easily seen and correc­ted.

120
There are a number of tech­niques of schedul­ing, and these are allied to methods
of present­a­tion. Scheduling is under­taken using logic-linked networks and the
crit­ical path method of analysis. This is based on either the arrow diagram method
or, as is more usual in modern soft­ware, the preced­ence diagram method. The
network methods are central to all others in modern plan­ning; the other
tech­niques discussed here may be considered to be altern­at­ive means of present­
a­tion, albeit they were origin­ally inde­pend­ent tech­niques.

16.1 Creating a crit­ical path network

A network is essen­tially a flow chart which describes the logical sequence of
activ­it­ies.

16.1.1 Definition of crit­ical path method

The crit­ical path (longest path) is a series of activ­it­ies or tasks within a project,
none of which can be delayed without affect­ing the project end date.
It is possible for a network to have more than one crit­ical path if there are
multiple key or sectional comple­tion dates. It is also possible for multiple crit­ical
paths to exist leading to a single comple­tion date.

16.1.2 Purpose of crit­ical path network

The crit­ical path network must allow you to under­stand the logical flow of work
and how the indi­vidual activ­it­ies relate to each other. As a result of the schedul­ing
process, the network will define:
121
Planning, Scheduling, Monitoring and Control

• the start and finish dates of activ­it­ies;

• the comple­tion date of the project;
• total and free float;
• the crit­ical path;
• areas of risk (such as bottle­necks of logic).

16.1.3 Methods of constructing a crit­ical path

Critical paths may be calcu­lated using a number of tech­niques that may
altern­at­ively be known as preced­ence diagrams, logic diagrams, PERT (program
eval­u­ation and review tech­nique), or determ­in­istic network diagram.

16.1.3.1 Precedence diagram method

There are two prin­cipal methods; the first method, which will be more famil­iar to
users of contem­por­ary soft­ware, is the preced­ence diagram method (PDM), in
which the node desig­nates the activ­ity, and the logical inter­face is repres­en­ted by
the arrow (Figure 16.1).
This method is some­times known as AON (Activity on node).

Figure 16.1 Example of the preced­ence diagram method (PDM)

16.1.3.2 Arrow diagram method

The second method, now super­seded, is the arrow diagram method (ADM), in
which the activ­ity is shown on the arrow, as illus­trated in Figure 16.2.

122
 Building the sched­ule: network analysis

Figure 16.2 Example of the arrow diagram method (ADM)

This approach only allows finish to start rela­tion­ships.

‘Dummy’ activ­it­ies are needed to complete the logic in these diagrams. Task D
cannot take place until Tasks B and C have completed; there­fore, a dummy task
is required to link node 4 to the start of node 3.
This method is some­times known as AOA (Activity on arrow).

16.1.4 Inputs into a crit­ical path analysis

Prior to under­tak­ing a crit­ical path analysis, the project needs to be broken into its
constitu­ent parts and defined in terms of the activ­it­ies required. The inter­de­
pend­en­cies between these activ­it­ies must be defined such that all activ­it­ies (apart
from the start­ing activ­ity or mile­stone) have at least one prede­cessor, and each
activ­ity, apart from the final activ­ity or mile­stone, has at least one successor. The
crit­ical path can then be construc­ted, but, in order to calcu­late the overall
dura­tion, the dura­tion of each activ­ity needs to be calcu­lated or other­wise
estim­ated. It is also worth noting the follow­ing:

• Care needs to be taken to correctly define the prede­cessor activ­it­ies and

ensure that the preced­ing activ­it­ies deliver what is required of them.
• Dialogue is required to ensure the logical flow of activ­it­ies is correctly defined.
• Lags can be intro­duced between activ­it­ies to more accur­ately model the reality
of the logic. Lags are to be avoided where possible because they are invis­ible
on the Gantt chart.
• Definition of the project’s logic is often an iter­at­ive process.

123
Planning, Scheduling, Monitoring and Control

16.1.4.1 Time analysis

Time analysis is the process that calcu­lates the time­frame in which each activ­ity
can take place. It iden­ti­fies the minimum time in which the network can be
completed based on the activ­ity dura­tions and the logical links defined.
The termin­o­logy used to describe the time­frame is defined in Figure 16.3.
Time analysis iden­ti­fies the activ­it­ies which are crit­ical to the timely comple­tion
of the network and the latest dates at which activ­it­ies can be completed without
delay­ing the end date of the network. It consists of five steps, but before we go
through this process it is useful to define the termin­o­logy used when under­tak­ing
a crit­ical path analysis.

16.1.5 Introduction to creat­ing a network analysis

The follow­ing para­graphs describe a step-by-step guide to construct­ing a
network.

• Step 1: Create a logical network.

• Step 2: Forward pass.
• Step 3: Backward pass.
• Step 4: Calculation of total float.
• Step 5: Identification of crit­ical path.

Further detail on types of float, logic and constraints follow.

Figure 16.3 Typical time analysis coding

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

124
 Building the sched­ule: network analysis

Project manage­ment teach­ing offers two altern­at­ive methods of calcu­lat­ing

the numbers contained in network analysis. This guide has opted to use the
method used by most plan­ning soft­ware, start­ing from day 1 of the project (which
plan­ning soft­ware usually refer­ences as a date rather than an ordinal date).
Note: An altern­at­ive method used in teach­ing begins with the concept of day
zero, and after the step-by-step guide an illus­tra­tion of a completed network is
shown for refer­ence purposes, in section 16.1.11.

16.1.6 Step 1: Create a logical network

The first steps in build­ing the network are the iden­ti­fic­a­tion of the activ­it­ies
required, and the iden­ti­fic­a­tion of the depend­en­cies, or logic, between them.
The dura­tion that each activity will take must be estim­ated, and it will then be
possible to construct a basic network with this inform­a­tion (Figure 16.4).

Figure 16.4 Step 1: create a logical network

16.1.7 Step 2: Forward pass

The forward pass calcu­lates the earli­est start and finish dates for each activ­ity,
based on the activ­ity dura­tions and their logic. For the follow­ing example, the
diagram below illus­trates this base inform­a­tion (Figure 16.5).

125
Planning, Scheduling, Monitoring and Control

The first activ­ity is given an early start date (Day 1). With the dura­tion, it is then
possible to calcu­late the early finish date (Day 10). Thus, early start + dura­tion
= early finish.
The second activ­ity can start after the first activ­ity has completed (Day 11).
This calcu­la­tion proceeds forward through the network, even­tu­ally calcu­lat­ing
the earli­est possible finish date for the whole network of activ­it­ies.
Note that if an activ­ity is depend­ent on more than one activ­ity, it is import­ant
to remem­ber to ensure that the calcu­la­tions have been completed on all preced­ing
activ­it­ies. The full forward pass will, there­fore, be calcu­lated in Figure 16.5.

• Where two or more depend­en­cies converge at a succeed­ing activ­ity, there

may be a number of differ­ent earli­est finishes (EF) to use to estab­lish the
earli­est start (ES).
• The logic states that all preced­ing activ­it­ies must be complete for the
succeed­ing activ­ity to start, so the highest preced­ing EF is used to determine
the succeed­ing ES.

Figure 16.5 Step 2: the forward pass calcu­la­tion

16.1.8 Step 3: Backward pass

The back­ward pass calcu­lates the latest start and finish dates for each activ­ity,
based on the activ­ity dura­tions and their logic. It is essen­tially the oppos­ite of the
forward pass.

126
 Building the sched­ule: network analysis

Starting from the last activ­ity in the network, the latest finish is set to the same
value to determine the early finish. Then from the late finish the dura­tion is
subtrac­ted to calcu­late the late start date. This calcu­la­tion then proceeds
back­wards through the network. On comple­tion of the back­ward pass, the
result­ing data appears as in Figure 16.6.

• Where two or more depend­en­cies go back to a preced­ing activ­ity, there may

be a number of differ­ent latest starts (LS) to use to estab­lish the latest finish
(LF).
• The logic states that all succeed­ing activ­it­ies must be able to start once the
preced­ing activ­ity is complete, so the lowest succeed­ing LS is used as the
preced­ing LF.

Figure 16.6 Step 3: the back­ward pass

16.1.9 Step 4: Calculation of total float

Having completed the forward and back­ward passes, total float can be calcu­lated
(Figure 16.7); it is simply the latest finish less the early finish, and is expressed in
the relev­ant time unit (number of days, for example).
Once float is calcu­lated, the crit­ical path also becomes appar­ent, as the crit­ical
path is the chain of activ­it­ies with zero float, as illus­trated in Figure 16.8. Thus, in

127
Planning, Scheduling, Monitoring and Control

the example the crit­ical path is Task 1–Task 2–Task 3–Task 6. Any delay to any of
these activ­it­ies will delay the comple­tion of the project.
Note also that, in the example below, a delay of 2 days to Task 4 and/or Task 5
will also delay the project, and will also have the effect of chan­ging the crit­ical
path to Task 1–Task 4–Task 5–Task 6.

Total float = late finish – early finish (TF = LF – EF)

Figure 16.7 Step 4: Calculation of total float

16.1.10 Step 5: Identification of crit­ical path

Once the float has been calcu­lated, the crit­ical path can be iden­ti­fied by tracing
the path with zero days’ float through the sched­ule, as shown in Figure 16.8. It is
usual to high­light the import­ance of the crit­ical activ­it­ies; the crit­ical path activ­it­ies
and crit­ical logic links are shown in red.
There are instances where the crit­ical path may not be defined simply by those
activ­it­ies with zero float. One reason could be that the sched­ule contains a variety
of calen­dars, which will affect the float calcu­la­tions. For example, a 7-day calen­dar
for curing of concrete may be included. Therefore, a better defin­i­tion would be
the ‘longest path’ through the project (Figure 16.9).

128
 Building the sched­ule: network analysis

Figure 16.8 Step 5: Identification of crit­ical path

Figure 16.9 Longest path calcu­la­tions

129
Planning, Scheduling, Monitoring and Control

16.1.11 Training in network analysis: a note

Training of network analysis takes two distinct forms. First, follow­ing the method
outlined above, it is taught that early start + dura­tion – 1 = early finish, to enable the
project to start on Day 1, not Day 0. (Similarly, late start – dura­tion + 1 = late start.)
The second method adopts a more purely math­em­at­ical approach, as follows
(Figure 16.10).
The network commences on Day 0 instead of Day 1, which gives differ­ent
start dates, as illus­trated below. The end dates remain the same. However, Day 0
does not exist, so this method does not prop­erly repres­ent reality. Planning
soft­ware will always work with the Day 1 method.
When trans­fer­ring the classroom teach­ing to plan­ning soft­ware, the prac­tical
calcu­la­tion should be allowed to occur and the absence of a day zero must be
explained.

Figure 16.10 The altern­at­ive method of calcu­la­tion in a network

16.1.12 Float
Float is some­times referred to as ‘slack’, for example in some schedul­ing soft­ware,
but this guide will use the more widely accep­ted term ‘float’. Figure 16.11 illus­
trates float types.

130
 Building the sched­ule: network analysis

16.1.12.1 Free float

Free float is spare time at the end of an activ­ity that can be used without delay­ing
its successor activ­ity.

16.1.12.2 Total float

Total float is the amount of time that an activity can be delayed without affect­ing
the network end date. (It is worth noting that total float is the amount of float that
typic­ally applies to a sequence of activ­it­ies on that path, and, if used up on the
current activ­ity, will not be avail­able for future activ­it­ies on the partic­ul­ar path).

16.1.12.3 Negative float

Negative float occurs in a sched­ule when you do not have enough time to
complete the project by the desired (and constrained) comple­tion date. In order

Figure 16.11 Float types

131
Planning, Scheduling, Monitoring and Control

to achieve the required date, you will need to recover the time in future activ­it­ies/
sequences.

16.1.12.4 Float owner­ship

On some complex projects, it may be appro­pri­ate to share float between teams
(e.g. on an inter­na­tional project the float between US and UK elements of the
sched­ule has a share arrange­ment, with teams obliged to notify each other when
they have used up their element). Extreme care should be taken with this
approach, and acknow­ledge­ment of the owner­ship of float should be in
accord­ance with the contract condi­tions.

16.1.12.5 Monitoring of float

Float use should always be monitored so that there is an aware­ness of the crit­ic­
al­ity of all works; work that is not crit­ical will become so if it is suffi­ciently delayed.
If this is to be the case, sudden shifts in the crit­ical path should not come as a
surprise if the loss of avail­able float has been care­fully monitored and brought to
the atten­tion of the relev­ant people.

16.1.13 Types of logic linking

There are many rela­tion­ship types avail­able for linking activ­it­ies logic­ally. When
devel­op­ing the sched­ule, it is possible to use multiple types of logical rela­tion­
ship. It is import­ant to remem­ber that the purpose of schedul­ing is to fore­cast
accur­ately, and as such choos­ing the correct rela­tion­ship type is crit­ical to build­ing
a sched­ule that is fit for purpose. The most common rela­tion­ship types are:

16.1.13.1 Finish to start rela­tion­ships

This is the prefer­able form of logic: it implies that the sched­ule has been broken
down to an accept­able level of detail, and is the easiest logic to under­stand and
analyse. It creates clear float paths. It is advis­able to use this rela­tion­ship when
devel­op­ing sched­ule logic, as it provides the simplest sched­ule and the most
robust method of determ­in­ing project total float.
In Figure 16.12, a finish to start rela­tion­ship shows that activ­ity 1 has to be
100% complete to allow activ­ity 2 to start. This also means that a delay to activ­ity
1 will have a direct impact on the start date of activ­ity 2.

132
 Building the sched­ule: network analysis

Figure 16.12 Finish to start rela­tion­ship

16.1.13.2 Start to start rela­tion­ships

A start to start rela­tion­ship, as shown in Figure 16.13, shows that once activ­ity 3
has started, activ­ity 4 can also start. This does not neces­sar­ily mean that activ­ity 4
must start on the same day – it means that activ­ity 4 can now start at any time in
the future.
Note: both activ­it­ies will also need a successor, and activ­ity 3 will need a
prede­cessor to complete the logic.
This rela­tion­ship type is used when an activ­ity can only be completed when its
prede­cessor has started; e.g. manu­fac­ture may be able to commence once the
deliv­ery of neces­sary compon­ents has started, but it is not depend­ent upon
the deliv­ery being completed. Once again, paral­lel working oppor­tun­it­ies must be
possible and valid­ated by the project team before being used in the sched­ule.

Figure 16.13 Start to start rela­tion­ship

133
Planning, Scheduling, Monitoring and Control

Care should be taken when using this type of rela­tion­ship. It is not as simple as
the Finish to Start link. If activ­ity 3 starts, but is stopped or slows down for any
reason, can activ­ity 4 really proceed unhindered? Thus these links may often be
used with:

16.1.13.3 Finish to finish rela­tion­ships

A finish to finish rela­tion­ship, as shown in Figure 16.14, shows that once activ­ity
5 has finished, activ­ity 6 can also finish. This means that these tasks can start inde­
pend­ently of each other, but activ­ity 6 cannot finish until activ­ity 5 has completed.
Note: both activ­it­ies will also need a prede­cessor, and activ­ity 6 will need a
successor to complete the logic.
This rela­tion­ship type is used when an activ­ity can only be completed when its
prede­cessor has finished. It assumes that activ­it­ies can proceed without comple­tion
of their prede­cessors and that paral­lel working is possible; e.g. you can start
putting a plan­ning applic­a­tion together whilst site surveys are being under­taken,
but you cannot complete the applic­a­tion until you have all the survey inform­a­tion.
Parallel working can success­fully be used in order to accel­er­ate a project. However,
it is import­ant to remem­ber that paral­lel resources are required as well.

Figure 16.14 Finish to finish rela­tion­ship

16.1.13.4 Start to finish rela­tion­ships

This is a very rare link and should be used with extreme caution, if at all. Its use is
often an indic­ator of poor schedul­ing prac­tice, as it is usually illo­gical (that activ­ity
8 cannot finish until after activ­ity 7 has started) (Figure 16.15). For this reason, it
is normally seen as bad schedul­ing prac­tice to use this kind of linking.

134
 Building the sched­ule: network analysis

Figure 16.15 Start to finish rela­tion­ship

It is diffi­cult to give an example of where such a link could be valid. (An example
some­times given is activ­ity 7 in Figure 16.15 being ‘mix epoxy resin’ and activ­ity
8 being ‘apply epoxy resin’, but it is hard to imagine plan­ning at this level
of detail in most situ­ations.) These types of links are likely to be used as a
conveni­ence rather than a true descrip­tion of logic. For this reason, they should
be avoided.

16.1.14 Lags and leads

A lag is the period of time between activ­it­ies that does not repres­ent any work. It
can be used as part of any type of logical link (finish to start, start to start, etc.).
A lead is a negat­ive lag, and by defin­i­tion illo­gical, as time only runs forward
(so far as we know).
The sched­uler also needs to beware of the effect of calen­dars on lags. An
example could be non-activities such as concrete curing (which is one poten­tial
use of a lag, as no work is repres­en­ted). The calen­dar relat­ing to the lag in this case
would show a 24-hour, 7-day a week work pattern. It is unlikely that the preced­ing
(or follow­ing) activ­it­ies will work to the same calen­dar, and it is worth noting that
not all schedul­ing soft­ware can distin­guish the calen­dar being applied to a lag.
Lags and leads are not activities and should not be used as a substi­tute for an
activ­ity. They are gener­ally used in low-density plan­ning, and as detail devel­ops
they should be removed.
The use of lags and leads should be avoided as far as possible. Whilst use of
lags is common prac­tice within schedul­ing, excess­ive reli­ance on lags, coupled
with their inher­ent lack of visib­il­ity, can make them diffi­cult to status and thus
under­mine the overall accur­acy of the sched­ule. It is there­fore prefer­able to use

135
Planning, Scheduling, Monitoring and Control

a dummy activity rather than a lag. This will have the added advant­age that an
appro­pri­ate calen­dar can be applied to the dummy activity.
The use of lags and leads is therefore, in most cases, poor schedul­ing prac­tice,
and they must not be used in high-density schedul­ing, because as previously
stated they are illo­gical. (Figure 16.16 illus­trates that activ­ity 12 cannot start until
2 days before activ­ity 11 completes, but this is an illo­gical state­ment – the future
is uncer­tain, but for this to work you have to know 2 days in advance that Activity
11 is going to complete on a partic­u­lar day.)

Figure 16.16 Summary of types of logic and lags

16.1.15 Use of constraints

Activity constraints can be used to fix an activ­ity at a partic­u­lar point in time. All
activ­it­ies should ideally be linked by logic, but in some instances this may not be
possible – or desir­able; e.g. the start of some­thing where nothing precedes it.
‘Start on site’ or ‘appoint contractor’ may be examples. Similarly, finish dates may

136
 Building the sched­ule: network analysis

need to be fixed without anything follow­ing them, e.g. sectional comple­tion

dates of various sections of work.
Within schedul­ing soft­ware there is usually a selec­tion of differ­ent ways of
adding a constraint date, as described below:

• as late as possible;
• mandat­ory start;
• mandat­ory finish/dead­line;
• (must) start on;
• (must) finish on;
• start on or after/start no earlier than;
• finish on or after/finish no earlier than;
• start on or before/start no later than;
• finish on or before/finish no later than.

Note: The differ­ent schedul­ing soft­ware may use slightly differ­ent termin­o­logy
for these constraints; for example, tick-boxes; ‘holding pin’; ‘start on a new day’.
It is import­ant to under­stand the ways schedul­ing tools use constraints. This is
partic­u­larly import­ant where you need to import sched­ules from differ­ent sources
into the master sched­ule.
Care should be taken in the use of multiple constraint dates, as they can give
mislead­ing results when the project is sched­uled, espe­cially if used in combin­a­tion.
For example, using ‘start on or before’ and ‘start on or after’ constraints on the
same activ­ity or logical sequence would create a result you might not anti­cip­ate
or notice if you have not appre­ci­ated the combin­a­tion.
It should be noted that if a constraint date is imposed on an activ­ity then float
calcu­la­tions will use that constraint date to calcu­late the ‘late finish’ date for the
activ­ity.
If there is not enough time to do the work and to meet the constraint date,
then a negat­ive float value will be calcu­lated. Conversely, if there is more than
enough time to do the work and meet the constraint date, then a posit­ive float
value will be gener­ated. It is worth noting that differ­ent tool­sets (or schedul­ing
soft­ware) can handle this in differ­ent ways. Problems may arise when moving
data from one soft­ware product to another. Different results are very likely except
in the case of very simple sched­ules.

137
Planning, Scheduling, Monitoring and Control

16.1.16 Types of constraints

In Figures 16.17–16.25, the float calcu­lated assumes we are consid­er­ing the
crit­ical path, or the link into the crit­ical path. This is to simplify the explan­a­tion;
the prin­ciple applies to all float paths.

16.1.16.1 As late as possible constraint: ALAP

ALAP should only be used in circum­stances where an activ­ity should be done –
as the name suggests – as late as possible. It means that any float on that activ­ity
(or mile­stone) will have been used up and there­fore may make the item crit­ical.
(Note: sched­ules should gener­ally be built so that all activ­it­ies, when sched­uled,
show the earli­est dates they can be carried out – as soon as possible). Scheduling
tools typic­ally default to plan­ning tasks as soon as possible unless the user
specifies an altern­at­ive plan­ning approach or constraint.
This type of constraint may also be known as a ‘zero free float’ constraint.

Figure 16.17 ‘As late as possible’ constraint

138
 Building the sched­ule: network analysis

16.1.16.2 Finish on constraint

Holds an activ­ity at the desired comple­tion date. It will be over­rid­den by preced­ing
logic. Total float will be calcu­lated against the constrained date.

Figure 16.18 ‘Finish on’ constraint

139
Planning, Scheduling, Monitoring and Control

16.1.16.3 Finish on or after constraint

Allows the activ­ity to finish later than the date entered, so does not create
a crit­ical activ­ity. But will not permit the activ­ity to finish earlier – even if the
works are completed early. Total float will be calcu­lated against the network
comple­tion date.

Figure 16.19 ‘Finish on or after’ constraint

140
 Building the sched­ule: network analysis

16.1.16.4 Finish on or before constraint

Makes the activ­ity crit­ical if it finishes on or after that date. But will allow it to
finish early.

Figure 16.20 ‘Finish on or before’ constraint

141
Planning, Scheduling, Monitoring and Control

16.1.16.5 Mandatory finish constraint (must finish on)

A rigid constraint that cannot be moved when sched­uled. Can be used to create
a crit­ical path or to show negat­ive float if works are slip­ping or in delay. (Note:
should not be used casu­ally; it is always better to use ‘finish on or after’ or ‘finish
on or before’.) It is often considered to be bad schedul­ing prac­tice to use this
constraint.

Figure 16.21 ‘Mandatory finish’ constraint

142
 Building the sched­ule: network analysis

16.1.16.6 Mandatory start constraint

Makes the activ­ity crit­ical, and consequently the prede­cessor also becomes
crit­ical when sched­uled. (Note: should not be used casu­ally; it is better to use
‘start on or after’ or ‘start on or before’.)

Figure 16.22 ‘Mandatory start’ constraint

143
Planning, Scheduling, Monitoring and Control

16.1.16.7 Start on constraint

As for ‘finish on’, it cannot be moved when sched­uled, and there­fore creates a
crit­ical path through the preced­ing activ­it­ies. (Note: should not be used casu­ally;
it is better to use ‘start on or after’ or ‘start on or before’.)

Figure 16.23 ‘Start on’ constraint

144
 Building the sched­ule: network analysis

16.1.16.8 Start on or after constraint

Allows the activ­ity to start later than the date entered, so does not create a crit­ical
activ­ity. But will not permit the activ­ity to start earlier – even if the preced­ing
works are completed early.

Figure 16.24 ‘Start on or after’ constraint

145
Planning, Scheduling, Monitoring and Control

16.1.16.9 Start On or Before Constraint

Makes the activ­ity crit­ical if it starts on or after that date. But will allow it to
start early.

Figure 16.25 ‘Start on or before’ constraint

146
 Building the sched­ule: network analysis

16.1.17 Displaying networks on bar charts

In schedul­ing soft­ware, the network is created in the way described in the
preced­ing sections, gener­at­ing the start and finish dates, together with any float
values for each activ­ity. It is possible in some schedul­ing soft­ware to display the
sched­ule as a network, and this clearly (if well presen­ted) shows the logical
­relation­ships between the indi­vidual activ­it­ies. A more usual repres­ent­a­tion is
in the form of a bar chart (Figure 16.26), which has the advant­age of giving a
visual­isa­tion of where the activ­it­ies sit in time. Often it is much harder to clearly
display the logic in this view. However, most schedul­ing soft­ware pack­ages give
the users the ability to show or not to show the logic between the activ­ity bars
and mile­stones.

Figure 16.26 Bar chart display

16.2 Estimation of dura­tions

The sched­ule is a model of the future based on the project object­ives and outputs.
This means that, until such time as the sched­ule slowly becomes histor­ical fact,
the project team estim­ates how long it will take to achieve these object­ives, along
with what resources are required and how much it will cost.
To sched­ule work accur­ately and effect­ively, it is import­ant to have a good set
of robust schedul­ing assump­tions. As the project moves forward and things
change, so must the assump­tions. It is this iter­at­ive process that ensures that the
sched­ule is designed to deal with the future needs of the project, redu­cing threats
and the range of possible outcomes.
There are many ways of formu­lat­ing a good set of schedul­ing assump­tions:

147
Planning, Scheduling, Monitoring and Control

16.2.1 Three-point estim­ates

Three-point estim­ates can be used to define minimum, most likely and maximum
estim­ates based on assump­tions and previ­ous exper­i­ence. Actions can arise to
address high vari­ances from this work. Monte Carlo analysis can then be used to
determ­ine prob­ab­il­ity of the outcomes.
In this case, the high vari­ance between the most likely and maximum dura­tion
is such that the cause of the addi­tional time required should be invest­ig­ated. In
the example, this might be due to unseen services running through the earth­works
area. A risk concern­ing this uncer­tainty must be registered, and a mitig­a­tion
developed.

Table 16.1 Example of three-point estim­ate

Activity A B C

Minimum dura­tion Most likely dura­tion Maximum

dura­tion

Dig Foundations 2 weeks 3 weeks 8 weeks

16.2.2 PERT (programme eval­u­ation review tech­nique)

PERT is a recog­nised formula to determ­ine activ­ity dura­tions from the three-point
estim­ate, optim­istic (O), most likely (M) or pess­im­istic (P). It produces a weighted
average leaning to either the optim­istic or the pess­im­istic, depend­ing on the size
of the vari­ance. Once again, signi­fic­ant vari­ances between dura­tion estim­ates
should be explored as poten­tial risks.

Table 16.2 Example of PERT calcu­la­tion

Activity O M P PERT

Minimum Most likely Maximum

dura­tion dura­tion dura­tion

Dig found­a­tions 2 weeks 3 weeks 8 weeks (O+(4*M)+P)/6 3.7

weeks

Note: the PERT calcu­la­tion noted above is the most commonly used, although there are altern­at­ive
calcu­la­tions, such as the three-point estim­ate, which is calcu­lated as (P+M+O)/3.

148
 Building the sched­ule: network analysis

16.2.3 Comparative
Projects of a similar type are used to estim­ate dura­tions, making appro­pri­ate
adjust­ments for scope (i.e. differ­ences in quant­it­ies). Other specific differ­ences
such as logist­ical differ­ences, local climate, and local resource avail­ab­il­ity must be
assessed and adjust­ments made accord­ingly.

Table 16.3 Example of compar­at­ive estim­ates

Activity Area Actual dura­tion

Previous project 2,000 cubic metres 3 weeks

Dig found­a­tions Area Estimated dura­tion

Our project 3,000 cubic metres 4.5 weeks

16.2.4 Benchmarked data

This util­ises an exist­ing data­base of project and activ­ity inform­a­tion regard­ing
times­cales and costs for comple­tion. Using this data, average cost and times­cales
can be applied to a meas­ur­able unit and then multi­plied by the number of desired
units to ascer­tain an approx­im­ate dura­tion. This approach requires a library of
reli­able data and is best applied to projects where local or project-specific
condi­tions do not provide signi­fic­ant reasons for devi­ation. Caution needs to be
exer­cised, as differ­ing circum­stances will apply to all projects, but it could be
used as initial guid­ance.

Table 16.4 Example of bench­marked data

Activity Project Volume Actual dura­tion
Project A 5,000 cubic metres 6 weeks

Project B 5,500 cubic metres 7 weeks

Dig found­a­tions Project C 10,000 cubic metres 10 weeks

Project D 7,000 cubic metres 8 weeks

149
Planning, Scheduling, Monitoring and Control

16.2.5 Resource-dependent
Resource-dependent activ­it­ies, although constrain­ing, are a good way of deriv­ing
robust assump­tions. Here the limit­a­tions are around labour, plant, supply of
mater­i­als, access to site, etc.
The planner or estim­ator uses known outputs for the avail­able resource to
calcu­late the estim­ated dura­tion for an activ­ity (see Table 16.5).

Table 16.5 Example of resource-dependent estim­ate

Activity Volume Resource Average Estimated
avail­ab­il­ity gang output dura­tion

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

found­a­tions metres per
week

16.2.6 Expert opinion

One of the best places for assump­tions is the project team or people who have
expert­ise in the type of work required. Bringing indi­vidu­als together in work­shops
to discuss activ­ity dura­tion, sequence and asso­ci­ated risks can be the best way of
produ­cing a real­istic sched­ule.

16.2.7 Personal exper­ie­ nce

There is no single right way of devel­op­ing plan­ning assump­tions, but one
import­ant element is using as much relev­ant histor­ical data as you can. When
doing so, it is import­ant that you docu­ment your assump­tions compre­hens­ively.
Key project assump­tions should be recor­ded in the risk or assump­tions register,
as getting them wrong may require working in a differ­ent way, which may incur
time delay and increased cost.
It is funda­mental to the plan­ning process that the project team are involved
when devel­op­ing, iter­at­ing and signing off plan­ning assump­tions, as, if done in
isol­a­tion, this can lead to a project sched­ule that has not gained the buy-in of the
project team. This would be worth­less as an effect­ive tool to manage the project
and fore­cast outcomes.
The process of plan­ning work as a team, will quickly derive a set of working
assump­tions against which to base a prelim­in­ary sched­ule, start­ing with the

150
 Building the sched­ule: network analysis

WBS. Discreet work pack­ages will be fleshed out against the overall scope of the
project. It is import­ant that all elements of work required to deliver the project
bene­fits capab­il­ity is included within the sched­ule. Other aspects to be included
are, assump­tions on tasks, dura­tion, sequence, logical depend­en­cies, inter­faces
(both internal and external) and costs.
Getting a head start can greatly improve your chance of devel­op­ing a good
sched­ule; some compan­ies may categor­ise their projects by discip­line or asset
type, which makes the process of using exist­ing data much easier.
It is import­ant to realise that assump­tions are simply guesses around the
future, and there­fore can be incor­rect. If a specific task is on the crit­ical path, then
this may cause delay or increased cost to the project. Key assump­tions around
activ­it­ies that can have this effect should be assessed for impact and entered into
the risk register. The register should also record the quan­ti­fied impact in time and
cost (along with the corres­pond­ing mitig­a­tion strategy) which can assist in getting
additional funds and/or resources.

16.2.8 Social media

With the increas­ing prom­in­ence and contin­ued evol­u­tion of the inter­net and
social media in the work­place, it makes sense to access all plan­ning inform­a­tion
avail­able when devel­op­ing sched­ules. Caution should be exer­cised in any
result­ing inform­a­tion received, partic­u­larly with regard to any biases or influ­ences
gener­ated by the type of audi­ence.

16.3 Resourcing the sched­ule

Some organ­isa­tions have to share resources around the projects they under­take.
Consequently the plan­ning of resource usage becomes vital, partic­ul­arly when
resources are limited due to either general scarcity (perhaps because of the wider
market) or scarcity of special­ist skills. In any project, an assess­ment of the
resources required, and partic­u­larly a measure of the quant­ity of resources
required, will be a check on the valid­ity of plans. For example, a sched­ule created
using a network analysis method will consider resources to be unlim­ited. This is
unlikely to be the case in most instances. Introduction of resources to the project
should be planned in a real­istic manner – sudden increases in resources are not
easy to achieve or manage. Similarly, it is not likely that a large mass of resources
will suddenly be removed from the project.

151
Planning, Scheduling, Monitoring and Control

16.3.1 Definition of resources

Resources can be one or more of the follow­ing:

• labour;
• plant or equip­ment;
• mater­i­als;
• facil­it­ies, such as special­ist test sites.

In some cases, e.g. high-level budget­ing exer­cises, you may wish to use money
as a discrete resource which is not aligned to labour, plant and equip­ment, or
mater­i­als. Each of the resources may drive the project pace by constrain­ing the
output that can be achieved – for example, a spend­ing cap to a point in time will
determ­ine how much work can be completed up to that point. Where resources
do constrain the project deliv­ery rate, they are known as ‘crit­ical resources’. It is
likely that the relat­ive import­ance of each will vary depend­ing on project type,
but also from project to project.
An import­ant consid­er­a­tion may be the rela­tion­ship between resources and
project logist­ics. Resources gener­ally require space within which to operate,
whereas mater­i­als need space to be stored.

16.3.2 Purpose of resourcing the sched­ule

Resourcing of the schedule is a vital stage of the process between creat­ing the
network, running a crit­ical path analysis, and issuing the results as the working
sched­ule. It is required in order to:

• determ­ine (low or medium density) or valid­ate (at high density) the dura­tion of
each activ­ity;
• promote the consid­er­a­tion of the flow of resources (people, trades or sub-
contractors) within the sched­ule, which will lead to more real­istic and
achiev­able outputs;
• lead to an under­stand­ing of peak resource require­ments, includ­ing human
resource require­ments, funding require­ments and peak mater­ial supply
require­ments;
• ascer­tain the avail­ab­il­ity of special­ist equip­ment (which may be factored in by
use of resource calen­dars) – this may require advance booking;

152
 Building the sched­ule: network analysis

• lead to an under­stand­ing of logist­ical require­ments: welfare accom­mod­a­tion

for the work­force, adequate working space for labour and plant;
• demon­strate the robust­ness of the sched­ule to other parties.

16.3.3 Process of resourcing the sched­ule

16.3.3.1 Estimate the quant­ity of resources required
Estimates are made using previ­ous projects, exper­i­ence or stand­ard outputs, as
required. These tech­niques are partic­u­larly useful at low or medium-density
schedul­ing. At high-density schedul­ing, it is more useful to under­take calcu­la­
tions in line with the formu­lae shown in Figure 16.27. This approach means that
the required resources are part of the duration calculation for each activity, and
can be allocated to each activity.

Figure 16.27 Establishing the dura­tion of a task based on resource

16.3.3.2 Team sizes

Optimum team sizes for differ­ent types of work should be acknow­ledged when
determ­in­ing resources. This being partic­ul­arly relev­ant where crews are made up
of front-line produc­tion and back-up – brick­lay­ers and their labour­ers, for
example. Particular sets of circum­stances may vary the required make-up of such
gangs. Specialist advice should be sought in these circum­stances.

16.3.3.3 Resource alloc­a­tion

Resources are alloc­ated to each activ­ity within the sched­ule, so that when this
exer­cise is complete the sum of all the activ­it­ies repres­ents the total quant­ity of
resources in the project (in terms of budget, labour, plant).

153
Planning, Scheduling, Monitoring and Control

16.3.3.4 Resource profiles

Resource demand can now be predicted by looking at histo­grams – peak require­
ments can be estab­lished:

Figure 16.28 First draft resources profile

The diagram above (Figure 16.28) shows resource levels peaking at 42, but
the build-up to those peaks does not look real­istic in most circum­stances; an
exer­cise is required to smooth the build-up and flow of resources.

16.3.4 Resource smooth­ing

If, as in the example above, the results do not indic­ate a sens­ible ramp up
and down of resources, it may be neces­sary to consider resource smooth­ing.
This is the process of smooth­ing demands so that prac­tical overall levels are
achieved, and also that resources are optim­ised to flow from one piece of work to
another.
Resource smooth­ing needs to be considered on a resource-by-resource basis.
When consid­er­ing human resource, this may mean analys­ing the require­ments
for indi­vidu­als, but it is more usual to analyse by resource type – profes­sion or
trade, for example.

154
 Building the sched­ule: network analysis

The smooth­ing process should start by initially consid­er­ing those activ­it­ies

with free float, as moving these will not have an effect on other activ­it­ies. After
the free float has been considered, it may be neces­sary to consider the use of
total float. This exer­cise will become iter­at­ive, as the effects of delay­ing activ­it­ies
with no free float but some total float will need to be care­fully analysed. All
smooth­ing will need to be done within the early and late envel­opes for each
activ­ity; other­wise the project end date is likely to be comprom­ised.
Figure 16.29 shows the same project as Figure 16.28 above, but this time with
optim­ised resources (resource-levelled chart shown in blue).

Figure 16.29 Resource-smoothed histo­gram

Other consid­er­a­tions will be the amount of avail­able resources; where

resources are finite, these need to be considered along­side the demand. In Figure
16.30, the orange line indic­ates the resource limit and shows that, despite the
resource-levelling exer­cise, demand still outstrips avail­ab­il­ity for a period of time.
Management action will be required to solve the short­age.
Resource level­ling may be achieved by:

• Redefining the scope of the activ­it­ies to be under­taken by the partic­u­lar

resource concerned. In simple terms, this might mean giving some of the work
to an under-­u­til­ised resource.

155
Planning, Scheduling, Monitoring and Control

• Redefining the specific­a­tion. This obvi­ously may comprom­ise the quality of

the final product.
• Increasing task dura­tion to reduce the overall resource require­ments.
• Increasing resources on earlier tasks to bring work­load forward, such that
peaks in the future are reduced. This will have cost, and possibly quality,
implic­a­tions.
• Delaying non-critical work to reduce demand at peak time – i.e. using free and
total float to optim­ise the sched­ule.

Figure 16.30 Resource-levelled chart with resource limit

16.4 Horizontal and vertical integ­ra­tion

of sched­ules
16.4.1 Horizontal integ­ra­tion
Horizontal integration is the applic­a­tion of logic and the check­ing of logic through
the deliv­ery of products from one part of the process to another. Effectively, it will
lead from the start through to the comple­tion of the project. Tracing the sched­ule
hori­zont­ally ensures that:

156
 Building the sched­ule: network analysis

• The sched­ule is correctly logic-linked.

• The sched­ule contains all of the scope.
• The sched­ule iden­ti­fies the inter­face mile­stones between differ­ent parties –
places where a piece of completed work is passed from one party to another.

16.4.2 Vertical integ­ra­tion

Vertical integ­ra­tion is the process that confirms that the data at differ­ent levels of
detail is consist­ent and compre­hens­ive. It should confirm:

• that all sched­ules cover all the scope (as appro­pri­ate to them)
• that all data is consist­ent between sched­ules (dates, logic, etc.).

Thus, it allows sched­ules to be viewed at differ­ent levels of detail, as is appro­pri­

ate for each viewer.

16.5 Scheduling inter­faces and depend­en­cies

Managing project inter­faces is a funda­mental part of success­ful project manage­
ment. Whilst it is relat­ively straight­for­ward to manage a single sched­ule and its
asso­ci­ated depend­en­cies, in most cases there will be deliv­er­ables by the project
to parties outside the direct control of the project team as well as enabling
products or activ­it­ies required by the project.
It is also possible that you may need to manage many projects that together
form an integ­rated programme or port­fo­lio, and depend­ency manage­ment
presents a struc­tured and controlled way of managing change across projects.
It revolves around four key stages:

• iden­ti­fic­a­tion;
• coding;
• integ­ra­tion and impact analysis;
• impact resol­u­tion.

16.5.1 Identification
The project PBS, WBS and RACI will help identify inter­faces, as they give
a high-level view of work pack­ages, as well as their inter­faces with external

157
Planning, Scheduling, Monitoring and Control

depart­ments or projects. They should also include a list of stake­hold­ers outside

the project who may influ­ence the crit­ical path.
Ensuring that all members of the team are consul­ted during the iden­ti­fic­a­tion
phase is crucial, as it only takes one missed depend­ency to intro­duce delay to the
project. A group work­shop is a good way of gener­at­ing dialogue, as one person’s
thought process may stim­ul­ate another’s.
It is import­ant to note that this process is iter­at­ive and should be carried out at
the start of each project life cycle as more becomes known about the project and
sched­ule detail is increased.

16.5.2 Coding
Given the size and complex­ity of modern projects, robust codi­fy­ing of inter­faces
is recom­men­ded. This could be done with an appro­pri­ate activ­ity ID or an activ­ity
code. Careful thought must be given to ensur­ing the coding and naming conven­
tions. It is best to use abbre­vi­ations that are readily under­stood by those reading
them (i.e. they relate to the project and work package), thus aiding iden­ti­fic­a­tion
and commu­nic­a­tion. Given that in a project there will be many hundreds of inter­
faces, this can greatly increase the chances of slip­page due to external influ­ences.
An example depend­ency code may be:
‘INTPROJ0011.1.1001A’, where:

• INT=Interface;
• PROJ001=Project ID;
• 1.1.1=Related WBS ID;
• 001=Interface No;
• A=’Deliver By’ inter­face.

In the case of inter­face 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­face. In the
example given, INTPROJ0011.1.1001A would have a corres­pond­ing partner,
INTPROJ0011.1.1001B.
It is import­ant to note that, even though there are two separ­ate inter­faces, they
are funda­ment­ally the same thing, and simply repres­ent two separ­ate points of
view about when a single event will occur for the purpose of managing vari­ances.
Some inter­faces may also include other activ­ity codes, which may denote
project life cycle, loca­tion and depart­ment, but the activ­ity ID will ensure it is
visible on a stand­ard layout and is easily picked out from the project sched­ule.

158
 Building the sched­ule: network analysis

16.5.3 Integration and impact analysis

Once all inter­faces have been iden­ti­fied and the related activ­it­ies coded, they
need to be integ­rated within the project sched­ule. There are two primary methods
of integ­ra­tion – internal and external.

16.5.3.1 Internal integ­ra­tion

Internal integ­ra­tion is where inter­faces are held within the same project sched­ule,
usually within a separ­ate WBS node and/or grouped/filtered by their activ­ity
codes. They are logic­ally linked to their corres­pond­ing successor or prede­cessor,
and their fore­cast date is driven by the use of constraints which are determ­ined
by the other party (Figure 16.31).
As change happens it is directly repres­en­ted within the project sched­ule, and
the subsequent impact is modelled through­out the project. When updat­ing
depend­ency fore­cast dates in this way, it is import­ant to under­stand the effect of
each change, so a step-by-step approach is best. However, it is import­ant to wait
until all changes have been made before final analysis, due to the inher­ent inter­
re­la­tion­ships of sched­ule activ­it­ies and inter­faces.
It is import­ant to take a copy of the sched­ule before updat­ing, to enable a
compar­ison to be made. This high­lights where the project has been impacted
and where manage­ment time and mitig­a­tion efforts should be focused.

Figure 16.31 Internal integ­ra­tion mile­stones

159
Planning, Scheduling, Monitoring and Control

This method is most useful when dealing with a single project.

16.5.3.1.1 Advantages
• Easy to see the context around the depend­ency, as it is already within its native
WBS node
• Ease of visib­il­ity within the project sched­ule focuses the team.

16.5.3.1.2 Limitations
• Impact of changes may be diffi­cult to analyse if the sched­ule is very large. In
these cases, it may be better to consider the use of the external integ­ra­tion
method.

16.5.3.2 External integ­ra­tion

External integ­ra­tion is where depend­ency rela­tion­ships are held within a separ­ate
depend­ency sched­ule (Figure 16.32). This method is extremely helpful to the

Figure 16.32 External integ­ra­tion mile­stones

160
 Building the sched­ule: network analysis

manage­ment of inter­faces. Not only does it provide a clear picture of all inter­
faces, but it also allows vari­ance manage­ment and impact analysis to happen
outside the live schedul­ing envir­on­ment. This aids sched­ule stabil­ity.
In this method there are a total of four separ­ate mile­stones repres­ent­ing the
same event. Two are held within each of the project sched­ules in their corres­
pond­ing WBS nodes, and two are held within the inter­face sched­ule. When
move­ment occurs in inter­face ‘A’, the vari­ance can be clearly seen and tracked.
Once all the inter­faces have been updated, you can then assess the impact by
adding logic to the depend­ency sched­ule (Figure 16.33).
It is import­ant to ensure that all the depend­ences are linked to their corres­
pond­ing partner before the crit­ical path is calcu­lated, as one depend­ency path
can lead through many others. Once the logic linking exer­cise is complete, you
can then sched­ule the plan (Figure 16.34).
The driving logic from Project 1 will now flow through the depend­ency
sched­ule and into Project 2 in order to drive the sched­ule’s crit­ical path. (Most
enter­prise scheduling systems will have the ability to logic­ally link across separ­ate
projects, but system capab­il­ity must be checked, as it is an essen­tial require­ment
for this method.)

Figure 16.33 Logic-linked depend­ency sched­ule

161
Planning, Scheduling, Monitoring and Control

Figure 16.34 Dependency sched­ule driving project sched­ules

This method is primar­ily for use on very large projects, programmes or

port­fo­lios where common resources may be shared. The use of inter­face
mile­stones provides a useful way of controlling the impact of one partner’s
programme on the rest of the programme. Thus, it is an import­ant way of
managing collab­or­at­ive inputs from differ­ent parties on a complex project.

16.5.3.2.1 Advantages
• Manages change in a stable and controlled way that will not disrupt the stabil­ity
of under­ly­ing projects.
• Makes sched­ule move­ment and vari­ances easy to identify.
• Clearly defines depend­ency manage­ment as an import­ant part of the sched­ule.

16.5.3.2.2 Limitations
• Requires robust data quality control meas­ures.
• Requires dedic­ated resources to execute and manage.

162
 Building the sched­ule: network analysis

16.5.4 Impact resol­u­tion

When dates change, it is import­ant to under­stand the reason. The first check will
be that it has not been caused by an error or misun­der­stand­ing.
The sched­ule data is trans­ferred to a depend­ency report showing key
inform­a­tion for discus­sion with both project teams to ensure that issues are real
and to focus manage­ment effort.
The report contains key inform­a­tion about the depend­ency and is used by the
planner, project manager or depend­ency manager, depend­ing on the scale of
manage­ment required (Table 16.6).

• Dependency ID: Unique ID that only refer­ences either the ‘deliver by’ or the
‘need by’ event.
• Dependency name: Standard naming conven­tions 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 formal change control.
• Current fore­cast: Schedule logic-driven fore­cast date repres­ent­ing the most
up-to-date posi­tion.
• Variance: Difference between target and fore­cast. This is compared with
the depend­ency threshold and rated with a RAG format (red, amber and
green) accord­ingly, to focus manage­ment atten­tion on the most crit­ical
issues.
• Threshold: Number of days + or – that a depend­ency can move without
causing an issue with the receiv­ing party (this can, in some cases, only apply to
move­ment one way).
• Reason: Driving issue respons­ible for the move.
• Mitigation: Action result­ing from the depend­ency manage­ment meeting to
resolve issue.

Table 16.6 Interface impact sched­ule

Dependency Dependency Agreed Current Variance Threshold Reason Mitigation
ID name target fore­cast (days) (days)
date

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

1.1.1001A released resource
being
procured

163
Planning, Scheduling, Monitoring and Control

If the move­ment is real and the project team is unable to mitig­ate the slip­page,
then the receiv­ing project must look to future work to absorb delay by doing
things differ­ently or use avail­able project float. Once this has been agreed by
both projects, the new depend­ency date can be changed through the formal
change control process.

16.6 Time contin­gen­cies

Time contin­gency is a dura­tion of time assigned to an activ­ity that takes into
consid­er­a­tion the impact of uncer­tainty. During the process of devel­op­ing
plan­ning assump­tions, the likely impact of unfore­seen events must be taken
into consid­er­a­tion. Sometimes a straight­for­ward way of doing so is to assign a
percent­age of the overall activ­ity dura­tion to the end of the activ­ity, e.g. 10%. A
more scientific method might be to use the output of a quan­ti­fied sched­ule risk
assess­ment to appor­tion time risk to activ­it­ies.
The assess­ment of risk is heavily influ­enced by the risk appet­ite of the
organ­isa­tion under­tak­ing the assess­ment, and this should be borne in mind.
Attitude to risk may also be very subject­ive, so it is import­ant to consult as widely
as possible before attempt­ing to reach a consensus and making due allow­ances
for time contin­gen­cies.

16.6.1 Definition of buffers

A buffer is the term used to describe a period of time that is built into a sched­ule
to add greater certainty to the end date (Figure 16.35). There are three types:

• Resource buffer: the addi­tional lead time given to crit­ical resources to fore­warn
a partic­u­lar resource that a crit­ical activ­ity is approach­ing.
• Feeder buffer: the addi­tional time alloc­ated at the end of tasks within a
sched­ule.
• Project buffer: the addi­tional time alloc­ated at the end of a project sched­ule.

16.6.2 Use of buffers

Buffers may be intro­duced into the network to provide for time contin­gency. In
some cases these may have contrac­tual signi­fic­ance. In certain types of project,

164
 Building the sched­ule: network analysis

Figure 16.35 Different buffer types

this may help reduce overall project dura­tion by allow­ing activ­it­ies to start earlier.
This, in turn, allows the follow-on activ­it­ies to start earlier.
It is more commonly used on basic or repet­it­ive types of project, but, with
appro­pri­ate care, may be used on all types. Full buy-in of all parties is, however,
essen­tial, and is likely that contract issues will need to be considered. For example,
on NEC3 contracts (NEC – New Engineeering Contract) the use of time risk
allow­ance is specific­ally mentioned in order to bring realism into the contract­ors’
sched­ule. The use of Buffers as described is less likely to be useful on those
projects involving a signi­fic­ant degree of sub-contracting.

165
Planning, Scheduling, Monitoring and Control

16.6.2.1 Advantages of using buffers

• It emphas­ises doing works as early as possible to promote earlier than planned
comple­tion.
• It focuses on the avail­ab­il­ity of resources and thus produces a more real­istic
sched­ule than a pure crit­ical path analysis (presum­ing that only hard logic has
been used in the CPA).
• It promotes emphasis on the crit­ical path.
• It is appro­pri­ate for projects with basic or repet­it­ive activ­it­ies.

16.6.2.2 Limitations of using buffers

• It does not recog­nise the ways that sub-contracts /special­ist resources plan
their work. If resources are not on hand, then the advant­age of an early start
cannot be made.
• Issues around contract and risk owner­ship need to be iden­ti­fied and resolved.
• There is poten­tial for addi­tional cost due to delay and disrup­tion to follow-on
trades.
• There is poten­tial for resources to be unavail­able due to work­load being
repeatedly re-organised to crit­ical activ­it­ies.
• It may result in a lot of addi­tional activ­it­ies to the sched­ule, e.g. feeder and
resource buffers, which can add complex­ity to the logic.
• In addi­tion, there is a lot of extra work required in creat­ing and main­tain­ing the
addi­tional activ­it­ies noted above. Consider reading the exist­ing sched­ule
prop­erly instead!

166
The results of the schedul­ing may be presen­ted in a number of ways:

• Bar charts (some­times known as Gantt charts), which provide a graph­ical

repres­ent­a­tion and may be used in conjunc­tion with other methods. Originally
considered a method of plan­ning, now more usually seen as an output of
network analysis.
• Line of balance charts that show the flow of resources, and facil­it­ate the
balan­cing of the same.
• Time chain­age charts that intro­duce a spatial aware­ness into plan­ning the
project.

17.1 Bar charts

Bar charts are some­times referred to as Gantt charts, and often form the present­
a­tion method of the other tech­niques discussed. Activities are listed with other
tabular inform­a­tion, such as dates and dura­tions on the left side with time inter­vals
over the bars on the right-hand side, where the dura­tions are shown in the form
of hori­zontal bars (Figure 17.1).

17.1.1 Presentation consid­er­a­tions

Consideration should be given to the complex­ity to be displayed and the target
audi­ence. For example, the inclu­sion of logic links detracts from the clarity of the
presen­ted chart (as it will on many complex pieces of work). Complex sched­ules
may benefit from high-level, even simplistic explan­a­tions (see Figure 17.2 for an
example).

167
Figure 17.1 A simple bar chart
Figure 17.2 Strategic sched­ule of a major construc­tion project at low density
Planning, Scheduling, Monitoring and Control

Scheduling soft­ware may offer seem­ingly limit­less format­ting possib­il­it­ies, but

consid­er­a­tion must be given to the viewer. Ideally, sched­ules should have equal
clarity if rendered in ‘grey­scale’ (black and white), if this is how they may be
printed.

17.1.1.1 Advantages of bar charts

• Clear, pictorial repres­ent­a­tion of the plan.
• Gener­ally well under­stood.
• Relat­ively simple to create.
• Can be used to show progress.
• Can be used to plan resources.

17.1.1.2 Limitations of bar charts

• On their own, do not show depend­en­cies.
• There is a limit to the size of sched­ule that can reas­on­ably be read and under­
stood.
• Cannot easily cope with change as a result of progress or scope change.

17.1.2 An Alternative to bar chart report­ing

A key part of plan­ning/schedul­ing is to commu­nic­ate effect­ively to a variety
of audi­ences. When report­ing to the projects, programmes and port­fo­lio stake­
hold­ers , it is always import­ant to consider the audi­ence of those reports. Certain
indi­vidu­als are confid­ent with data presen­ted in a bar chart format, but there may
be people who prefer altern­at­ive present­a­tions. This is even more import­ant
when report­ing outside the project.
It is vital to get the ‘buy-in’ of the key stake­hold­ers, so altern­at­ive means of
commu­nic­at­ing the sched­ule should be sought. Some people can relate more to
a spread­sheet of dates, and some prefer mile­stones. Choosing the right format
could be key to getting a point across or getting an import­ant decision made.
Figure 17.3 shows a format using mile­stones.
The legend for all the mile­stones is shown on the chart; but it should be
noted that the optim­istic, real­istic and pess­im­istic dates are all gener­ated from
quantitative sched­ule risk analysis.
This mile­stone format can be a clearer way of present­ing several dates relat­ing
to one activ­ity.

170
Figure 17.3 Using mile­stones to give clarity to the sched­ule
Planning, Scheduling, Monitoring and Control

17.2 Line of balance

Line of balance is a method most suited to the plan­ning and adjust­ing of repet­it­ive
work. It is partic­u­larly used when a series of repet­it­ive units is required, for example
in a manu­fac­tur­ing envir­on­ment. It focuses on resources and outputs to achieve a
rate of progress that can be expressed simply and graph­ic­ally. It is often thought
to be most appro­pri­ate for residential-type projects, for example, but the tech­nique
may equally be applied to repetitive elements of any project. Structural steel­work
is a possible example of a trade suited for plan­ning and monit­or­ing in this way.

17.2.1 Creating a line of balance chart

A line of balance chart is created by plot­ting the output (in no. of 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 plot­ting of work is complete, it should then be possible to analyse
the trades that are influ­en­cing the overall project dura­tion due to their slower rate
of progress. In the example below, the mech­an­ical & elec­trical 1st fix and parti­tions
2nd fix are progress­ing at a slower rate. The possib­il­ity of optim­ising the dura­tion,

Figure 17.4 Creating a line of balance chart

172
 Communicating the sched­ule

Figure 17.5 Optimising work flow in line of balance

for example by increas­ing resources on these two tasks, can be examined and
put into prac­tice as appro­pri­ate (Figure 17.5).

17.2.2 Advantages of line of balance

• Encourages the use of resource level­ling, giving the trades continu­ity of work
and a more real­istic chance of achiev­ing the plan than a purely logic-driven
sched­ule would.
• Easier to under­stand than a bar chart.
• More concise form of present­a­tion (fewer pages of sched­ule).
• Can be used to predict comple­tion by extra­pol­at­ing the progress to date, or
making assump­tions about future progress.
• Can be used as a tool that will identify modi­fic­a­tions required to the sched­ule.
• Will clearly high­light ensuing trades that are catch­ing up with their prede­
cessors, and there­fore at risk of running out of work.
• This method demands consid­er­a­tion of expec­ted output and will improve the
quality of the plan.
• May assist in demon­strat­ing delay and disrup­tion in a claim situ­ation (or
rebut­ting the same).
• Focuses on outputs.

173
Planning, Scheduling, Monitoring and Control

17.2.3 Limitations of line of balance

• It is purely based on outputs and will not recog­nise out-of-sequence working.
• Does not show exact or logical rela­tion­ships.
• Unlikely to be accept­able as a contract sched­ule.
• Not suit­able for all projects or all parts of a project.
• Not suppor­ted by stand­ard schedul­ing soft­ware – though special soft­ware can
be purchased.

17.3 Time chain­age

17.3.1 Definition of time chain­age charts
Time chainage charts are used to describe projects that are linear in nature (an
example being road construc­tion). When well designed and drawn, they are a
very useful visu­al­isa­tion tool, often allow­ing 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’ require­ments into consid­er­a­tion. Software is avail­able that
can convert most stand­ard schedul­ing soft­ware into a time chain­age chart by
using activ­ity coding to define the time and distance para­met­ers.

• The diagram below (Figure 17.6) shows the basic elements of a time chain­age
chart.

Figure 17.6 Basic elements of a time chain­age chart

174
 Communicating the sched­ule

• Time is defined in appro­pri­ate periods down the side of the illus­trated chart.
The start of the project is usually shown at the top of the chart and the end at
the bottom.
• The distance is shown hori­zont­ally in the illus­trated chart, and may include the
chain­age (loca­tion defined in metres) or named geographic loca­tions, as
appro­pri­ate.
• At the top of the chart a simple repres­ent­a­tion or map of the project may be
shown to aid visu­al­isa­tion.
• Software is avail­able that allows an auto­matic update from stand­ard schedul­ing
soft­ware.

Below is a simpli­fied explan­a­tion of the build-up of a time chain­age chart that

helps illus­trate the tech­nique.

17.3.2 Explanation of the time chain­age tech­nique

The project being used to illus­trate the tech­nique (Figures 17.7–17.11) is a
road project that contains two struc­tures: a retain­ing wall and a road bridge. In
order to construct these struc­tures it is neces­sary to construct a ‘haul road’ – a
tempor­ary route that allows construc­tion vehicles to traverse the site with heavy
loads.
The separ­ate bar section across the top shows the work geograph­ic­ally.
The major section of this project is the bridge, so in order to facil­it­ate its
construc­tion; a tempor­ary haul road is required. This is construc­ted from each
end of the site as shown.

Figure 17.7 Time chain­age task 1

175
Planning, Scheduling, Monitoring and Control

Figure 17.8 Time chain­age tasks 2 and 3

The comple­tion of the haul roads allows the construc­tion of both the retain­ing
wall and the bridge:
The road can commence once the bridge is nearing comple­tion; for the
purposes of this example, we assume this has to be built in one continu­ous
oper­a­tion. The first option considers the oper­a­tion from (say) north to south.
However, by recon­sid­er­ing this oper­a­tion and construct­ing it from south to
north, an earlier start can be made and a month saved from the overall dura­tion
of the construc­tion sched­ule.

Figure 17.9 Time chain­age task 4

176
 Communicating the sched­ule

Figure 17.10 Time chain­age sequen­cing

17.3.3 Advantages of time chain­age

• It is a very clear way of showing phys­ical build against time.
• It will quickly show if there are spatial clashes in the sched­ule.
• It shows not only the loca­tion of the activ­ity but also the direc­tion of progress
and the required progress rate.

17.3.4 Limitations of time chain­age

• Only appro­pri­ate in certain circum­stances – it is partic­u­larly useful in geograph­
ic­ally spread projects (which would also be ‘linear’ in char­ac­ter – like a road, a
railway or a high-rise build­ing).
• Individual pref­er­ence for visu­al­ising the project (it does not suit every­one).

177
Figure 17.11 Example of a time chain­age diagram for a new railway
 Communicating the sched­ule

17.4 Schedule narrat­ive

A sched­ule narrat­ive is a funda­mental part of any complex sched­ule. It is used
to explain, illu­min­ate and commu­nic­ate. It is used espe­cially when issuing a
sched­ule to a third party, usually for customer approval or accept­ance, but is
import­ant for clarity in any event. A narrat­ive will typic­ally include some or all of
the follow­ing:

17.4.1 Scope
A descrip­tion of the work scope should be included, cover­ing design, procure­
ment, devel­op­ment strategy, imple­ment­a­tion phase and testing and commis­sion­
ing, as appro­pri­ate.

17.4.2 Health, safety and environmental consid­er­a­tions

For example, in construc­tion, whether the site is a ‘green field’, a city centre, a
nuclear site, a working railway or an airport, etc., as the HSE require­ments will
vary consid­er­ably.

17.4.3 Risks, oppor­tun­it­ies and contin­gen­cies

Risks to the time aspects of the project should be iden­ti­fied and discussed. This
would include a discus­sion on the use of any float.

17.4.4 Breakdown struc­tures

There should be adequate explan­a­tion in the narrat­ive to describe the hier­arch­
ical struc­tures used in creat­ing the sched­ule, for example geograph­ical or phys­ical
work groups.

17.4.5 Project phasing

Project phasing may be driven by other factors, such as finan­cial plan­ning,
phys­ical constraints or governance gate­ways. These should be detailed in the
narrat­ive. This is partic­u­larly pertin­ent when these factors are dynamic, for
example in construction-site logist­ics layouts.

179
Planning, Scheduling, Monitoring and Control

17.4.6 Stakeholders
Any stake­hold­ers’ interest in the sched­ule should be iden­ti­fied and described.

17.4.7 Resources
Resources used in execu­tion of the sched­ule should be described in the sched­ule;
the narrat­ive should note any resource constraints or special resource require­ments,
in partic­u­lar high­light­ing any scarce resources that pose a threat to the deliv­ery
of the project if they are unavail­able. Any special meas­ures required need to be
iden­ti­fied. Resource histo­grams may be a useful commu­nic­a­tion tool to indic­ate the
resources to be deployed:

• labour;
• major items of plant or equip­ment;
• major items of mater­ial.

17.4.8 Critical path(s)

A descrip­tion of the crit­ical path(s) through the project, possibly with simple illus­
tra­tions to enhance explan­a­tion, together with a comment­ary expand­ing on any
relev­ant or pertin­ent issues relat­ing to decisions, progress, strategies, risks or
other matters pertain­ing to the crit­ical works in the project.

17.4.9 Assumptions
A descrip­tion of the key assump­tions that affect the manage­ment of time, in
order to explain and enhance under­stand­ing of the sched­ule.

17.4.10 Calendars
Calendars which under­pin the sched­ule should be listed and described as part of
the narrat­ive. A summary of those used in the sched­ule should be provided. It
should refer to the days/hours to be worked, and describe any excep­tional
calen­dars used. For example, there may be separ­ate calen­dars for:

• normal working hours;

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

180
 Communicating the sched­ule

• night-shift or weekend working;

• planned clos­ures for special works.

17.4.11 Activity codes

Details of all activ­ity and resource codes in the sched­ule, and reasons why they
are used.

17.4.12 Details of any posses­sions, shut-downs or other

special working condi­tions
Working rail­ways usually require posses­sions for track work to be done.
Factories and produc­tion facil­it­ies require shut-downs. Nuclear sites may
require special working condi­tions.

17.4.13 Consents required

Any consents from third party author­it­ies should be iden­ti­fied either in the
sched­ule or in the narrat­ive, includ­ing the required timing for any applic­a­tion or
approval periods.

17.4.14 Permits and licences

Any permits and licences required should be iden­ti­fied either in the sched­ule or
in the narrat­ive, includ­ing the required timing for any applic­a­tion or approval
periods.
It is noted that the above list, though not neces­sar­ily exhaust­ive, repres­ents a
consid­er­able effort to create and main­tain. Common sense must prevail in
determ­in­ing what is appro­pri­ate in differ­ent circum­stances. It may be appro­pri­ate
that some of the details listed above form part of the project proced­ures or other,
stan­dalone docu­ments. The central purpose of the narrat­ive – to commu­nic­ate
and explain the sched­ule – must not be lost in the creation and updat­ing of an
exhaust­ive narrat­ive docu­ment.
The narrat­ive is reviewed, revised and re-issued along­side each submis­sion of
the sched­ule and asso­ci­ated docu­ments.

181
18.1 Definition of sched­ule review
Schedule review is the process that confirms that the sched­ule is fit for purpose:
i.e. that it can be used to direct and accur­ately monitor the work. In general, there
are two stages:

• initial review of the sched­ule to confirm its fitness for purpose

• ongoing review of the sched­ule to ensure that it contin­ues to be fit for purpose.

18.2 Purpose of sched­ule review

Schedule review is under­taken to ensure that the sched­ule is fit, and remains fit
for purpose.

18.3 Checking the sched­ule

Fundamental checks of the sched­ule should confirm that the full project scope has
been included; that the sched­ule describes a prac­tical meth­od­o­logy for deliv­er­ing
the work; and that all contract deliv­er­ables, constraints, key dates and mile­stones
are included. The follow­ing sections detail further checks that may be made to
test a sched­ule’s integ­rity and relev­ance. There are two categor­ies of checks:

• plan­ning checks;
• schedul­ing checks.

183
Planning, Scheduling, Monitoring and Control

Planning checks deal with the prac­tic­al­ity of the plans to direct the comple­tion of
the project. Scheduling checks check the integ­rity of the time model, to ensure
that it flows correctly and can be used to fore­cast accur­ate dates.
The primary consid­er­a­tion must be the prac­tical content of the sched­ule, but
some useful integ­rity checks are also discussed in this section.
In order to review a sched­ule, it is import­ant to be able to read and inter­pret it.

18.3.1 Understanding the project sched­ule

It is import­ant to be aware that a sched­ule submit­ted in a soft­ware format will not
neces­sar­ily display in the way inten­ded, or as it was viewed on the sender’s
screen. Some soft­ware will default to the user’s display settings. It is import­ant to
select the correct layouts and filters before viewing the sched­ule. It is, there­fore,
normal prac­tice when submit­ting a sched­ule to include a copy in a file format that
will display the sched­ule without the need for partic­u­lar plan­ning soft­ware to be
installed on the viewer’s screen.

18.3.2 Components of the sched­ule display

As stated, a sched­ule may be presen­ted in many and various ways. Figure 18.1
features some of the elements that are typic­ally avail­able.

18.3.2.1 Data table

The data table contains inform­a­tion about each activ­ity. There is almost a limit­less
amount of inform­a­tion that can be displayed. The example below shows a fairly
stand­ard display for the contents of the adja­cent Gantt chart.

• Act ID = activ­ity identi­fy­ing number.

• Act Name = descrip­tion of the activ­ity.
• OD = original dura­tion of the activ­ity.
• Start/Finish = start and finish dates of the activ­ity (usually early start and early
finish).
• Total Float is self-explanatory.
• B/L Start = baseline start date.
• B/L Finish = baseline finish date.

184
Figure 18.1 Components of a sched­ule for review
Planning, Scheduling, Monitoring and Control

Additional items that could be displayed may include:

• cost and budget data for each activ­ity;

• prede­cessors and successors of each activ­ity (although this may be diffi­cult to
display and read);
• progress data such as actual dates, percent­age complete and remain­ing
dura­tion.

18.3.2.2 Timescale
The times­cale can be used to display calen­dar dates in various levels of detail,
and/or ordinal dates. The times­cale can usually be expan­ded to aid visib­il­ity of
a partic­u­lar time­frame, or contrac­ted to give an over­view of a wider portion of
time.
The sched­ule should also display the data date. The data date is the
point up to which project progress is updated. It is also the point from
which any network analysis would be calcu­lated when ‘re-scheduling’ the
project.

18.3.2.3 Gantt chart

Typically called the bar chart, this displays bars between pairs of dates (start and
finish dates). A number of bars may be shown, for example based on early dates,
late dates or baseline dates (to visu­al­ise progress slip­page or recov­ery). Whilst
the options are many, for clarity the number of bars displayed should be kept to
a minimum.

18.3.2.4 Resource histo­gram

The resource histo­gram will graph­ic­ally display the resource usage that the
sched­ule calcu­lates to be required to complete the work. It may repres­ent all the
resources, or be filtered to display a partic­ul­ar type of resource, or resources, for
a partic­ul­ar section of works.
A resource limit may be displayed (red line in Figure 18.1). If such a limit has
been set, then any resource require­ment over that limit may be high­lighted in a
differ­ent colour (not shown in Figure 18.1).

186
 Schedule review

18.3.3 Critical matters not included in the display

18.3.3.1 Understanding the crit­ical path
In reality, tracing the crit­ical path and other network logic in a complex sched­ule is
diffi­cult on paper (unless specific extracts have been produced, which by their
nature will give limited inform­a­tion), and there­fore an elec­tronic review is neces­sary.

18.3.3.2 Calendars
It is import­ant to under­stand what calen­dars and work patterns have been used
when build­ing the sched­ule. (This can be displayed in the data table.) The
calen­dars used will influ­ence overall dura­tion of activ­it­ies (and hence the project),
the ability to accel­er­ate the project, and the under­stand­ing of the crit­ical path.

18.3.3.3 Schedule drivers

Similarly to the issue of calen­dars, sched­ule dura­tion is also driven by the avail­ab­
il­ity and quant­ity of resources used, assumed output rates and productiv­ity rates.
It is, there­fore, crucial to know this inform­a­tion when check­ing the sched­ule.
When review­ing the sched­ule, it is also vital to be aware of any constraints that
have been used.

18.3.3.4 Filters and layouts

Filters are used to display a specific selec­tion of the sched­ule at any one time.
Filters may be used to extract a partic­ul­ar area of respons­ib­il­ity, crit­ic­al­ity, activ­ity
coding and many others. When reading a filtered sched­ule, it is import­ant to
under­stand what element of it is being viewed (and, conversely, what is NOT
being viewed).
Layouts determ­ine how the sched­ule will be viewed by determ­in­ing the
contents of the data table, the Gantt chart, the present­a­tion of the times­cale, etc.

18.3.3.5 Risk
When review­ing the sched­ule, it is import­ant to under­stand the asso­ci­ated risks.
These should be found in or added to the project risk register.

187
Planning, Scheduling, Monitoring and Control

18.4 Planning checks

18.4.1 Administration
• Check that all headers and footers are correct, with current date and revi­sion
number.
• It is good prac­tice for the header or footer to also include fields for layout, filter,
project ID, project name, user­name, version number, etc. applied to the
printed version.
• Check that the sched­ule has been checked and approved for issue.
• Presentation: Is the sched­ule laid out logic­ally and easy to read? (For example,
are contract and key dates shown clearly, perhaps in their own section at the
start of the sched­ule?)

18.4.2 Management issues

• Achieving formal buy in from relev­ant managers.
• Does the logical sequence of tasks make sense?
• Are adequate lead-in times allowed for mater­ial supply, manu­fac­ture of
compon­ents, etc.?
• What are the main risks to the sched­ule?
• Are there any onerous require­ments placed on the contract?
• Ensure all assump­tions regard­ing dura­tions and sequence are adequately
recor­ded.
• Does the sched­ule at high level compare with similar projects?
• Do the activ­ity dura­tions compare favour­ably on key trades?
• Are any corpor­ate governance/sign-off points included?

18.4.3 Contract require­ments

• Does the sched­ule comply with contract oblig­a­tions?
• Are the key client mile­stones included in the sched­ule?
• Have constraints such as working hours been accoun­ted for?
• Are there multiple handovers? If so, does level of detail reflect this, partic­u­larly
regard­ing trade continu­ity?
• Missing data required by the contract, such as missing activ­ity coding.

188
 Schedule review

• If the sched­ule includes progress, perhaps the most import­ant check of all is
that key or contract dates have not moved, or, if they have, the reasons for
such move­ment are fully explained in the narrat­ive.
• If required, has time risk allow­ance been iden­ti­fied against activ­it­ies?

18.4.4 Scope
• Is the entire scope repres­en­ted in the sched­ule, includ­ing latest change (up to
a suit­able cut-off point)? (This should include refer­ences to all works by the
client, contract­ors and third parties.)
• Are all tempor­ary works and other prelim­in­ar­ies covered? The former may be
on the crit­ical path or require crit­ical resources.
• Are inter­me­di­ate mile­stones iden­ti­fied and mean­ing­ful?
• Check that all inter­face mile­stones are paired.
• Check that the key/inter­face mile­stones for the next 12 months have signed-off
mile­stone defin­i­tion sheets and that all have SMART meas­ures (specific,
meas­ure­able, achiev­able, relev­ant and time-bound).
• Check all activ­it­ies and mile­stones for any constrained dates.
• Check for out-of-sequence or missing logic leading to activ­it­ies on data
date.

18.4.5 Associated docu­ments

Associated docu­ments that may be required for issue at the same time as the
sched­ule:

• inform­a­tion required register;

• procure­ment sched­ule;
• assump­tions register;
• logist­ics plans (traffic manage­ment; hoist and tower crane loca­tion plans;
mater­i­als storage in various phases);
• addi­tional commu­nic­a­tion plans, e.g. time-phased layouts.

18.4.6 Planning issues

Consideration should be given to the exist­ence of negat­ive float or excess­ive
posit­ive float and the implic­a­tions this has for the manage­ment of the project.

189
Planning, Scheduling, Monitoring and Control

If sched­ules with negat­ive float are presen­ted without showing the negat­ive
float, they can give a false impres­sion that the sched­ule dates can be met.
Where posit­ive float exists in a network, it means that the work can be delayed
by the asso­ci­ated time and still be completed by the desired date. However, it is
worth check­ing that ‘excess­ive’ float does not exist in the project sched­ule. This will
be because of missing successor logic. It is always worth check­ing the logic through
activ­ity networks that seem to have propor­tion­ally more float than seems reas­on­able.
Check for an excess­ive number of activ­it­ies start­ing early in the programme.
Although the logic may allow this, it may not be a cost-effective approach for the
project.

18.4.7 Progress update

• Have any key dates or other import­ant mile­stones moved?
• Has phys­ical % been updated (where options exist)?
• Has the correct data date been set?
• Are actual dates recor­ded correctly?
• Does the remain­ing dura­tion of the activ­it­ies roughly align with the progress
achieved within the time elapsed?
• How much float has been used, partic­u­larly on the crit­ical and near-critical paths?
• Are there any future activ­it­ies marked as started or complete?
• Are there any activ­it­ies in the past that are not complete?

18.4.8 Communication of the sched­ule

• Has a summary plan and explan­a­tion been included?
• Are activ­ity descrip­tions clear and has relev­ant coding been applied?
• Is the crit­ical path clearly shown?
• Are the asso­ci­ated tracker sched­ules included in the commu­nic­a­tion?
• The narrat­ive should high­light key partic­u­lars of the sched­ule and key changes
since the previ­ous issue.

18.5 Scheduling checks

This process looks specific­ally at sched­ule logic and content that may distort the
natural flow of the sched­ule, making accur­ate fore­cast­ing more diffi­cult. Similarly,
it reviews over-complexity in the sched­ule, which may increase the possib­il­ity of

190
 Schedule review

failure. It is import­ant to note that the review of tech­nical quality is purely a

math­em­at­ical and stat­ist­ical check and does not take into consid­er­a­tion the
project sched­ule as a whole. To check for scope inclu­sion, ‘build­ab­il­ity’ and other
prac­tical concerns, the sched­ule should be reviewed by suit­ably exper­i­enced
indi­vidu­als rather than by math­em­at­ical checks.
If formal checks are to be under­taken, it should be noted that these checks
would not usefully be applied to summary tasks, LOE-type tasks, mile­stones, or
activ­it­ies that are 100% complete. Making changes to the latter should not
gener­ally be encour­aged.
A good start­ing point is to see whether the sched­ule can be re-scheduled with
no subsequent changes to the start and finish dates. It is also worth review­ing
what changes have been made to the sched­ule since its previ­ous iter­a­tion. Then
consider the follow­ing factors.

18.5.1 Activity checks

18.5.1.1 Activity types
Scheduling soft­ware offers a variety of activ­it­ies for use in sched­ules, and these
should be used with caution; for example, WBS summary activ­it­ies (activ­it­ies
driven by the start and end dates of other activ­it­ies):

• should not contain resources, except during the devel­op­ment of sched­ules;

• should never form a part of the crit­ical path;
• should be used very spar­ingly, and then only with a partic­u­lar use in mind.

18.5.1.2 Activity dura­tions

Activity dura­tions should be achiev­able under normal condi­tions, not optimal or
‘stretch’ targets. In order to verify this, the sched­ule narrat­ive should clearly state
which output rates have been used. Assumptions related to calcu­lated dura­tions
should also be docu­mented.
Durations should be short enough to facil­it­ate easy assess­ment of progress. It
is very diffi­cult to be specific regard­ing a maximum dura­tion for an activ­ity, but, as
a guide, no activ­ity should exceed the dura­tion of two report­ing periods. (Do not
consider summary activ­it­ies in this check.)
A sched­ule broken into very short dura­tions (around a day or so) is gener­ally
in too much detail (the excep­tion being short-term ‘look ahead sched­ules’).

191
Planning, Scheduling, Monitoring and Control

Schedules with great detail will demand more frequent updates and more
manage­ment effort.

18.5.1.3 Review of deleted activ­it­ies

In general, activ­it­ies should never be deleted from a sched­ule, in order to preserve
the unique number­ing system for each activ­ity and thus main­tain the history of
the project.
Activities should, instead, be retired and placed in a unique and specific part
of the WBS. They will likely be filtered out of any print or display of the sched­ule.
All budgets must be removed and re-allocated if appro­pri­ate. Coding and logic
should also be removed. However, the logic could be replaced with links to a
dummy start and finish mile­stone to limit the number of open ends.
In prac­tice, leaving all redund­ant activ­it­ies in the sched­ule may increase the
size of the data­base to unman­age­able propor­tions. In this instance, it may be
decided to delete activ­it­ies and intro­duce checks between success­ive versions of
the sched­ule for dele­tions.
However, where prac­tical, it is good prac­tice to preserve activ­it­ies, for the
reasons stated above. A comprom­ise might apply in a situ­ation where large
sections of the sched­ule are to be replaced, when activ­ity dele­tion may be
accom­pan­ied by a change in the struc­ture of activ­ity IDs, so that there is no
possib­il­ity of duplic­a­tion/recyc­ling of the activ­ity ID numbers.

18.5.1.4 Insufficient detail

Is the sched­ule broken down into suffi­cient detail? This could be defined in terms
of the maximum dura­tion of an activ­ity in rela­tion to the overall project dura­tion.
On a project lasting 2 years it may be appro­pri­ate to specify a maximum dura­tion
of 4–6 weeks; on a plant shut-down the appro­pri­ate dura­tion may be 1–2 hours.
This should always be a guide rather than a rule, and will not apply to summary
tasks or level of effort activ­it­ies.

18.5.1.5 Review of calen­dars used

Calendars used should be kept to a minimum, and only those author­ised for use
on the project should be used; they must be attrib­uted to appro­pri­ate activ­it­ies.
Calendars should repres­ent valid working times for the activ­it­ies and asso­ci­ated
resources.

192
 Schedule review

Calendars should be named clearly, should account for holiday periods, and
account for any other restraint on working; factory shut downs in manu­fac­tur­ing
or weather in construc­tion, for example.

18.5.1.6 Review for invalid dates

Invalid fore­cast dates are those that logic­ally 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 finished, but are in
the future (i.e. later than the current data date). This is clearly incor­rect, and thus
an invalid date.
The examples above can be the result of poor func­tion­al­ity in various types of
schedul­ing soft­ware, or just poor prac­tice by an indi­vidual. Either way, both need
to be checked for.

18.5.1.7 Review of WBS

A good work break­down struc­ture (in line with the advice within this guide) is an
indic­ator of a good sched­ule, and vice versa. All activ­it­ies in the sched­ule must be
attrib­uted to a part of the WBS.

18.5.2 Logic checks

18.5.2.1 Relationship types
18.5.2.1.1 Finish to start (FS)
The vast major­ity of activ­it­ies in the sched­ule should be finish to start activ­it­ies.

18.5.2.1.2 Finish to finish (FF)

There may be a limited number of finish to finish rela­tion­ships in the sched­ule,
but remem­ber that these require paral­lel working and the addi­tional resources
that this implies.

18.5.2.1.3 Start to start (SS)

There may be a limited number of start to start rela­tion­ships in the sched­ule, but
remem­ber that these require paral­lel working and the addi­tional resources that
this implies.

193
Planning, Scheduling, Monitoring and Control

18.5.2.1.4 Start to finish (SF)

These rela­tion­ships must be avoided; they are some­times used as a conveni­ence
to fix activ­it­ies in a partic­ul­ar moment in time. However, they are illo­gical and can
distort the flow of the sched­ule. (Very occa­sion­ally there may be excep­tions to
this rule.)

18.5.2.2 Number of lags

Whilst the use of lags is common prac­tice within schedul­ing, they should be used
spar­ingly, as they can under­mine the overall accur­acy of the sched­ule. This is
because they are diffi­cult to progress accur­ately, and have an inher­ent lack of
visib­il­ity. It is, there­fore, good prac­tice to use a dummy task rather than a lag. This
has the added advant­age that an appro­pri­ate calen­dar can be applied to the
dummy task.

18.5.2.3 Number of leads

A lead is a negat­ive lag, which should be avoided as much as possible. They
should never be used in high-density schedul­ing, because they are illo­gical.

18.5.2.4 Missing or redund­ant logic

Missing logic refers to activ­it­ies that have either missing prede­cessors, missing
successors or both. A high percent­age of missing logic will lead to arti­fic­ ially
inflated float within the sched­ule, and will also affect the valid­ity and reli­ab­il­ity of
the crit­ical path and subsequent fore­casts.
Redundant logic can arti­fic­ ially increase the complex­ity of the sched­ule without
adding any value.

18.5.2.5 Out-of-sequence activ­it­ies

Work that is started or completed on an activ­ity before it is logic­ally sched­uled
(before all its prede­cessors are complete) to occur is known as out of sequence.
This may show:

• A lack of discip­line in the project, as work is being progressed in the wrong

sequence.

194
 Schedule review

• Facilities or machinery not being avail­able, so work is jumping to the next

activ­ity instead of being idle.
• A fault in the logic.
• It may also indic­ate a lack of detail in the sched­ule.

This check should be used with caution, as sched­ules should be prag­matic rather
than infin­itely precise, and some instances of this occur­ring will be accept­able. In
short, don’t panic if out-of-sequence activ­it­ies are found in the sched­ule, but be
careful.

18.5.2.6 Logic density

The average number of logic links per activ­ity across the sched­ule. In general, the
minimum number of links per activ­ity is two (one prede­cessor and one successor);
anything below this shows that the sched­ule is lacking the logic needed to
provide a robust crit­ical path, and anything excess­ively above this may lead to
either redund­ant logic, which may complic­ate the ongoing main­ten­ance of the
sched­ule, or an increased level of risk to timely deliv­ery.

18.5.2.7 Logic bottle­necks

Activities with a high number of prede­cessors (i.e. more than two). This means
that there is an increased threat to deliv­ery of this activ­ity due to its depend­ence
on the success­ful comple­tion of many other activ­it­ies. In Figure 18.2, there is a
high chance that activ­ity D will be delayed, as there are more things that can
delay it; if it does start on time, it has a signi­fic­ant effect on the sched­ule if it runs
late, as a number of follow-on activ­it­ies would be affected by its running late.

18.5.2.8 Multiple ends

A network should have one start mile­stone and one finish mile­stone. All other
activ­it­ies are connec­ted, directly or via preced­ing or successor activ­it­ies, respect­
ively, to the start and finish activ­ity by logic.
Each activ­ity or sequence of activ­it­ies should, in prac­tice, impact on the
comple­tion date of the project at some stage. For example, the supply of tech­nical
public­a­tions is gener­ally an unre­lated activ­ity that would not impact the phys­ical
comple­tion of an aircraft. However, any delay in the deliv­ery of the tech­nical
public­at­ ions may well impact on the handover to the customer; for example, if

195
Planning, Scheduling, Monitoring and Control

Figure 18.2 Logic bottle­neck

the contract require­ments specify that a full suite of tech­nical docu­ment­a­tion

and/or spares (some­times referred to as initial provi­sion­ing) is required for
satis­fact­ory fulfil­ment of the contract.
In reality, there may be several end events/mile­stones which are required to
be delivered by a given date. For detailed project control, each deliv­er­able is
managed in its own right, and there­fore float is to be calcu­lated for each deliv­ery,
and not calcu­lated to the last mile­stone of the overall network.

18.5.3 Float and crit­ical path checks

18.5.3.1 Review of sched­ule float
Whilst high levels of float can be a sign of poor sched­ule logic, low levels of float
can mean that the project is unlikely to succeed before it has even started.
Ensuring that the project has enough float to accom­mod­ate unknowns is funda­
mental to its success.

18.5.3.2 Negative float

Activities within the sched­ule that have a total float value of less than 0 are said to
have negat­ive float. Logically, the sched­ule cannot be completed by the required

196
 Schedule review

target date. It is not, there­fore, accept­able to have negat­ive float in the first
sched­ule, but it may exist in subsequent sched­ules if progress has been unsat­is­
fact­ory. It is then a sign of a threat to the achievab­il­ity of the sched­ule.

18.5.3.3 Review activ­it­ies with high float

This may be an indic­ator of missing or inap­pro­pri­ate logic (but note that it may
also indic­ate an activ­ity that can be under­taken at any time!). It may also suggest
missing activ­it­ies, or improper sequen­cing within the sched­ule.

18.5.3.4 Review of time risk allow­ance

Durations are uncer­tain, and there­fore time contin­gency should be allowed for.
This is some­times referred to as a time risk allow­ance. It may be expressly shown
on the sched­ule, or it may be deemed to be included within each task. Therefore,
the best way to verify there is adequate contin­gency is in discus­sion with the
sched­ule owner.

18.5.3.5 Hard constraints

This refers specific­ally to the use of constraints that can arti­fi­cially distort the CPM
(critical path method) process and under­mine the crit­ical path. A hard constraint
is one which constrains the crit­ical path in both direc­tions; constraints such as
‘start on’, ‘mandat­ory start’, ‘finish on’ and ‘mandat­ory finish’ are examples.
Constraints that only affect the crit­ical path in one direc­tion are known as soft
constraints and are more accept­able; however, they should still be used spar­ingly,
and never in combin­a­tion to create a hard constraint.
For example, a constraint that means an activ­ity could start on or before a
certain date would be a soft constraint, as would a date that means an activ­ity can
start on or after a certain date. But, if used in combin­a­tion, they effect­ively
become a hard constraint – a mandat­ory start date.

18.5.3.6 Critical activ­it­ies

Does the longest path repres­ent a reas­on­able crit­ical path for the project? (Pay
atten­tion to the crit­ical path and near-critical paths in review­ing the sched­ule.)
Review activ­it­ies and mile­stones with a total float value of 0 days or less. (For
longer and more complex sched­ules, the review might need to be total float
of less than 1 day or 5 days or more.) High levels of overall crit­ic­al­ity in the

197
Planning, Scheduling, Monitoring and Control

sched­ule can be the result of insuf­fi­cient progress or poten­tially poor use of hard
constraints.
The crit­ical path should not include LOE or summary activ­it­ies, leads or lags
unless justi­fied. It should also not include activ­it­ies sched­uled to take place as late
as possible, even if they have zero float by virtue of coming before a crit­ical activ­ity.

18.5.4 Resources checks

18.5.4.1 Review of resourcing
The sched­ule should be checked to confirm that all true activ­it­ies are resourced
and/or budgeted. The checker should look out for budget and resourcing of
summary tasks (or level of effort bars), as this may indic­ate a lack of detail in the
budget­ing and resourcing else­where.
It is also worth check­ing that only appro­pri­ate and approved resources are
assigned to activ­it­ies.
If there are avail­able norms, it is useful to check the ratio of cost:resource, i.e.
bench­mark­ing.
Resource levels that the sched­ule requires should be meas­ured against
avail­able resources.

18.5.4.2 Analysis of resource histo­gram

Resource histo­grams should be reviewed for prac­tic­al­ity. Some of the checks
could include:

• Are there any sudden peaks and troughs?

• Does it look balanced, i.e. are there real­istic increases and decreases of labour
and/or staff?
• Does each resource have continu­ity (unless multiple ‘visits’ are allowed for)?
• What is the peak staff/labour level, and is it prac­tical for this type of project?

18.5.5 Review of sched­ule risk

Key risks in the project will have been iden­ti­fied as part of the risk manage­ment
process. Some risks will have a poten­tial impact on the timing of the project, and
these should be included in the network in order to give a more real­istic project
sched­ule. The allow­ances for risk should be reviewed as part of the risk analysis
process.

198
19.1 Definition of BIM
BIM is a new approach to dealing with the design, procure­ment and install­a­tion
of an asset as well as its testing and commis­sion­ing, its handover, and its oper­a­tion
and main­ten­ance. It provides inform­a­tion to facil­it­ate each of these life cycle
stages and can be applied to any type of asset.
Enhancements to model­ling soft­ware have given the ability to directly link the
project sched­ule to the model (3D), to visu­al­ise the construc­tion process in real
time (4D), and also to estim­ate the cost profile (5D).
In essence, BIM consists of a computer aided design (CAD) model of the
asset. This may exist in 2D or 3D format. The model has the ability to contain
inform­a­tion to build, operate and main­tain the asset. In more mature solu­tions,
this can extend to incor­por­at­ing the project sched­ule and cost model. This could
mean a 3D model that can visu­ally demon­strate the build sequence (or, indeed,
the progress of the works.) The BIM data­base will also contain metadata around
each indi­vidual compon­ent of the build, such as type, cost, load-bearing capa­city,
supplier, etc.
The term is being used world­wide, although in the UK its adop­tion is mandated
on government-funded projects by the end of 2016, giving it special relev­ance.
BIM matur­ity has been defined as differ­ent levels, as illus­trated schem­at­ic­ally in
Figure 19.1.
Although the visu­al­isa­tion elements of BIM remain the most recog­nis­able
aspect, it is the integ­ra­tion of scope using a common and consist­ent language in
order to under­stand the impact of change that is the key advant­age of this
approach.

199
Planning, Scheduling, Monitoring and Control

Figure 19.1 BIM level matur­ity map

19.2 Purpose of BIM

The BIM approach adds value to all stages of the assets life cycle because it
provides access to all the elements of inform­a­tion asso­ci­ated with the assets
being designed, engin­eered and, finally, oper­ated and main­tained. In deliv­er­ing
this, BIM has a great poten­tial to promote collab­or­a­tion between the various
parties and remove some tradi­tional industry barri­ers.
The use of 3D visu­al­isa­tion soft­ware is used to de-risk the deliv­ery phase of
a project by model­ling the time phasing of construc­tion in three dimen­sions. This
process shows poten­tial design issues and clashes within the schedul­ing of
a project, which can then be re-phased accord­ingly (e.g. running elec­trical
services before provid­ing cable manage­ment systems).
A computer model conceived with this approach in mind will consti­tute a
repos­it­ory of the so-called ‘single version of the truth’, thus minim­ising misun­der­
stand­ings deriv­ing from working on differ­ent versions of the model. Multi-
disciplinary coordin­a­tion and align­ment are facil­it­ated by the exist­ence of a single

200
 Building inform­a­tion model­ling (BIM)

model, whereby each special­ist adds the specific inform­a­tion on an iter­at­ive basis
as the design matures.
The involve­ment of differ­ent expert repres­ent­at­ives of differ­ent organ­isa­tions
(asset owner, investor, design­ers, build­ers, oper­at­ors and main­tain­ers) at the very
begin­ning of the project defin­i­tion provides an oppor­tun­ity of taking into account
all the require­ments that will accom­pany the assets to be built through­out their
whole life cycle.
All the func­tions that use the data and inform­a­tion that will make the model
richer and richer as the design devel­ops will work together in a much more
effi­cient manner (i.e. an integ­rated approach to cost and time is a natural result of
BIM).
The trans­ition of all the records from the construc­tion team to the Oper­ator
and Main­tainer (O&M) will occur in an elec­tronic manner, some­times referred to
as ‘digital handover’, without the need for an expens­ive and time-consuming
period of trans­la­tion of asset data into a format suit­able for O&M use.

19.3 BIM tech­no­logy

The BIM tech­no­logy has evolved very rapidly in recent times. Some mature
solu­tions exist, espe­cially in rela­tion to BIM level 2. Software houses are collab­
or­at­ing more and more in order to offer solu­tions that facil­it­ate integ­ra­tion in an
increas­ing manner.

19.4 The BIM culture

Any type of change, in partic­ul­ar one of the magnitude of BIM, will have to deal
with the human factor, by increas­ing aware­ness and know­ledge of how project
discip­lines inter­act with each other. Spreading the BIM culture both intern­ally
and within inter­fa­cing organ­isa­tions is a chal­len­ging task. New skills and profes­
sions will be required, currently not part of formal educa­tional and busi­ness
careers.

201
20.1 Definition of agile
Agile is a frame­work which describes a collec­tion of tools, struc­ture, culture and
discip­line to enable a project or programme to embrace changes in require­ments.
Agile methods integ­rate plan­ning with execu­tion, allow­ing an organ­isa­tion to
‘search’ for an optimal order­ing of work tasks and to adjust to chan­ging require­
ments.
Agile is not a meth­od­o­logy, and does not prescribe a way of working. It seeks
to provide a frame­work and a working mindset that helps a team respond
effect­ively to chan­ging require­ments.

20.2 Purpose of agile

Agile frame­works are typic­ally used in soft­ware devel­op­ment to help develop
soft­ware which may have uncer­tain or poorly defined and chan­ging user require­
ments. As func­tion­al­ity is iter­at­ively developed in short times­cales, it must be
tested with the customer, and the require­ments refined and agreed as appro­pri­
ate. Further devel­op­ment is then under­taken to enhance the func­tion­al­ity of the
end product.
Agile devel­op­ment is not the same as agile project manage­ment. Commonly,
and often disastrously, agile think­ing is not applied to the manage­ment of agile
devel­op­ment projects; for example, when busi­ness users are not embed­ded in
the team, and change decisions are not deleg­ated to the agile team, but need to
be escal­ated for approval. This slows down devel­op­ment, hence remov­ing one
of the key advant­ages.

203
Planning, Scheduling, Monitoring and Control

There are agile methods specific to soft­ware devel­op­ment, such as Scrum or

XP (eXtreme Programming). However, some agile approaches are start­ing to be
adopted in more indus­tries outside the soft­ware devel­op­ment industry.

20.3 Methods
There are many distinct agile processes, which are summar­ised in Figure 20.1.
Irrespective of which agile process a project chooses to adopt, or if they wish
to adopt more agile think­ing, the follow­ing prin­ciples apply:

• The project breaks a require­ment into smaller pieces, which are then prior­it­
ised by the team in terms of import­ance.
• The agile project promotes collab­or­at­ive working, espe­cially with the customer.
This involves the customer being embed­ded in the team, provid­ing the team
with constant and regular feed­back on deliv­er­ables and func­tion­al­ity of the
end product.
• The agile project reflects, learns and adjusts at regular inter­vals to ensure that
the customer is always satis­fied and is provided with outcomes that result in
bene­fits.

Scrum is the most popular agile process used in soft­ware devel­op­ment. It is

based on deliv­er­ing soft­ware features in time-boxed iter­a­tions called ‘sprints’

Figure 20.1 Agile processes

204
 Software industry: the agile approach

Figure 20.2 Illustration of an agile meth­od­o­logy using ‘scrums’ and ‘sprints’

(Figure 20.2). The require­ments are written as ‘stories’ that are collated into a
prior­it­ised list called the ‘backlog’. Each story in the backlog is awarded points
based on the level of defin­i­tion of the require­ments. Progress is monitored using
‘burn down’ charts of points; this enables the ‘velo­city’ to be calcu­lated, which
can be used to predict the out-turn dura­tion. Points are earned either 0% or 100%,
depend­ing on the accept­ance by the client/sponsor at the end of the ‘sprint
review meeting’. The process is over­seen by the ‘scrum master’, who makes sure
every­one adheres to the rules. Meetings are referred to as ‘cere­mon­ies’, the
most frequent of which is the daily plan­ning meeting, which iden­ti­fies what has
been done, what is to be done and barri­ers to success. Continued improve­ment
is embed­ded by holding a ‘sprint retro­spect­ive’ at the end of each sprint to access
perform­ance and learn from exper­i­ence.

20.3.1 Advantages
• Agile plan­ning focuses on deliv­er­ing what is most bene­fi­cial to the busi­ness
first, identi­fy­ing quick wins and earlier bene­fits real­isa­tion.
• Agile continu­ously looks for process improve­ments as part of the ‘retro­spect­
ive’ review. As the team become more effi­cient, they can plan to achieve more
in each sprint. Thus the velo­city of deliv­ery increases.

205
Planning, Scheduling, Monitoring and Control

• Agile assumes that changes are normal events; there­fore they are managed to
enable greater flex­ib­il­ity.
• Agile schedul­ing allows a greater level of flex­ib­il­ity in achiev­ing the end result.

20.3.2 Limitations
• The organ­isa­tion needs to be able to operate in an agile way and be willing
to have a fully empowered team, typic­ally with a full-time customer repres­ent­
at­ive.
• A non-agile culture within an organ­isa­tion will be a blocker on a project imple­
ment­ing an agile frame­work.
• Attendance at ‘daily scrum’ meet­ings is essen­tial to keep abreast of the project
tasks.
• Agile is not appro­pri­ate for all types of projects. Where there are signi­fic­ant
resource constraints, secur­ing suit­ably qual­i­fied teams for the full dura­tion of
each time box may not be possible in the organ­isa­tion.
• Agile approaches struggle on larger-scale projects due to the degree of collab­
or­at­ive working required by the approach. If team sizes become too big, then
devel­op­ment rates can slow.

206
 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
21.1 Definition of the project baseline
The project baseline (often referred to as the perform­ance meas­ure­ment baseline,
or PMB) is an approved plan for the project, against which project perform­ance
is meas­ured to facil­it­ate manage­ment decision making and action. The setting of
the baseline cannot be achieved until scope is defined and agreed, as the baseline
must encom­pass the entire project scope, sched­ule and cost.
In prac­tice, a baseline is a stored set of values encom­passing

• planned start and finish dates

• planned resources
• planned costs.

At the point of estab­lish­ing a baseline, each activ­ity in the sched­ule has a duplic­ate
set of dates ascribed to it. The duplic­ate dates are called the ‘Baseline’ dates
and are illus­trated in yellow in the diagrams below. Once set, these dates are
not changed through the normal progress of the project, unless there is a
require­ment to re-set the baseline. As the project progresses, the plan will be
updated and the current dates, illus­trated in green in Figures 21.1–21.6, may
well vary as a result of project perform­ance, revised sequen­cing and detail devel­
op­ment.
The illus­tra­tion shows the effect on a project sched­ule of a delayed start
and comple­tion of the first activ­ity, which has a knock-on effect on subsequent
activ­it­ies.
The same prin­ciple applies to manage­ment of resources and costs. A set of
values is recor­ded as the baseline, and as the work progresses and actual usage

209
Planning, Scheduling, Monitoring and Control

Figure 21.1 Establishment of baseline

Figure 21.2 Baseline after work starts

of resource or actual costs are incurred, these are recor­ded for compar­ison with
the baseline data.
A baseline to measure against is the key require­ment for any form of project
control. Without a baseline, there is nothing to compare the working sched­ule
with, and there­fore there is no way of meas­ur­ing perform­ance, meaning that
projects will end up out of control.

210
 Baseline

21.2 Purpose of a project baseline

A project baseline is estab­lished to enable the perform­ance of the project to be
under­stood and controlled. This is achieved by:

• Clear iden­ti­fic­a­tion of the sched­ule of the deliv­er­ables, activ­it­ies, mile­stone

dates, resources and costs.
• Measurement of project perform­ance: progress and perform­ance are compared
against the baseline, allow­ing appro­pri­ate action to be discussed, agreed and
taken. Thus, it is essen­tial to apply appro­pri­ate project control tech­niques.

In addi­tion, the baseline serves other purposes:

• It can motiv­ate the project team to deliver to plan, or to mitig­ate delays.

• It is the contrac­tual or other refer­ence point from which to measure and assess
the effect of change.
• It can be used in improv­ing future estim­at­ing.

In order to achieve all of the above, the baseline must be robust, cred­ible and
prag­matic, and must there­fore be main­tained as changes are made to the working
sched­ule.
The baseline will often be referred to as the perform­ance meas­ure­ment
baseline, or PMB. Usually the PMB is the S-curve (or curves – early and late)
derived from the baseline sched­ule. The elements of the total project that are
included in the PMB for purposes of meas­ure­ment must be defined. For example,
risk and contin­gency may be excluded.
Following the prin­ciples below will ensure that the PMB is aligned with the
master sched­ule object­ives and contract mile­stones. This PMB forms the basis
for meas­ur­ing all future progress and perform­ance.

21.3 Principles of project baselin­ing

• The baseline covers the entire scope of the project and includes all project
break­down struc­tures (by activ­ity coding or other means).
• The baseline sched­ule should comply with the prin­ciples outlined in this book.
• The baseline covers all stages of the project life cycle.

211
Planning, Scheduling, Monitoring and Control

• The project deliv­ery team creates controls and executes the baseline. An
appro­pri­ate level of author­ity, as iden­ti­fied in the project’s governance docu­
ment(s), approves the project baseline.
• The baselines should be estab­lished at (or before) the commence­ment of each
phase.
• The baseline is only changed in accord­ance with a robust change control
process. Changes to the baseline must be controlled and recor­ded.
• In addi­tion, the baseline is ‘main­tained’ as discussed below.
• The baseline may be ‘re-planned’, as discussed below. A ‘re-plan’ should only
be considered with the relev­ant level of author­ity (e.g. client, project manager
or project sponsor, depend­ing on circum­stances).
• The baseline may be ‘re-baselined’, as discussed below. A re-baseline is only
considered with the agree­ment from an appro­pri­ate level of author­ity (e.g.
client, project manager or project sponsor, depend­ing on circum­stances).

21.4 When to set the baseline

• A baseline should be reviewed, updated where neces­sary, and form­ally agreed
before the project enters into the execu­tion of the next phase.
• If a gateway approach to the project life cycle is adopted, a baseline may be set
at each gateway phase.
• The level of detail in the baseline for later phases becomes greater as each
phase becomes more immin­ent.
• The project baseline should only be set when the sched­ule, budget, resources,
risks and other compon­ents of it are robust, i.e. it is agreed that it is possible to
deliver the project to cost, time and quality.
• If a budget is signi­fic­antly inac­cur­ate it will not be useful as a measure of time
and cost perform­ance. An appro­pri­ate degree of rigour in setting the budgets
is thus required.

21.5 Establishing the baseline sched­ule

Baselines should normally be estab­lished against early start dates, assum­ing that
resource level­ling has been under­taken to calcu­late these dates.
In short, a baseline is created from the first agreed plans, and should have the
buy-in of the whole project team, senior manage­ment and supply chain.

212
 Baseline

21.6 Definition and purpose of baseline

main­ten­ance
21.6.1 Definition of baseline main­ten­ance
Baseline main­ten­ance is the routine main­ten­ance of the baseline to ensure that
any new detail in the working sched­ule is also captured in the baseline. This
would typic­ally include work that has been added to the scope through a proper
change control process. It would also cover the addi­tion of new activ­it­ies; for
example, adding gran­u­lar­ity to the sched­ule.

21.6.2 Purpose of baseline main­ten­ance

• To main­tain a cred­ible sched­ule to measure against.
• To revise dates, budgets or any other data where they are affected by agreed
change. Only author­ised change (follow­ing appro­pri­ate governance) may be
substi­tuted into the baseline. Unauthorised change must never be added into
the baseline.

21.6.3 Baseline main­ten­ance as a result of sched­ule changes

Some changes will require baseline main­ten­ance. The prin­ciples of this are
described below. Some schedul­ing soft­ware will facil­it­ate this process with
ease; others will require a number of steps to estab­lish stored values for new
or changed work. Baseline main­ten­ance consists of changes to the baseline
that enhance rather than detract from the integ­rity of the baseline. This includes:

• Change of plan­ning pack­ages into work pack­ages (this may include the
addi­tion of detail to the medium/long term).
• Changes in contrac­tual condi­tions or work scope. Where change is iden­ti­fied,
it is managed through a change control process, ulti­mately leading to an
update of the baseline. This will take the form of an appro­pri­ate addi­tion,
omis­sion or revi­sion, and will include the effects of the change on future
activ­it­ies. Records of baseline change should be main­tained to provide
trace­ab­il­ity.
• Changes to descript­ive inform­a­tion – e.g. activ­ity or coding titles. Typically,
this may be the correc­tion of errors. Note, however, that changes in number­ing
of activ­ity IDs should never be permit­ted.

213
Planning, Scheduling, Monitoring and Control

One example of baseline main­ten­ance would be the addi­tion of more

detail. Figures 21.3–21.6 show how the baseline would be main­tained as
a result of doing this, in this instance where concur­rent delays have happened
on the sched­ule. The over­rid­ing prin­ciple here is that of rolling wave
plan­ning, and the update of the baseline should not be able to comprom­ise
the baseline by masking delays or other changes that have affected the
sched­ule.
Baseline main­ten­ance for sched­ule revi­sions is inten­ded to preserve the
integ­rity of the baseline, and should have no effect on meas­ure­ment of sched­ule
perform­ance or cost perform­ance report­ing. Baseline main­ten­ance never masks
poor or good project perform­ance. Project-specific rules for author­ising any
changes to budget should be drawn up in the project-specific change control
and/or project control proced­ures.

21.6.4 Illustration of the prin­ciple of baseline main­ten­ance

21.6.4.1 Project planned
The original project plan is shown in green. Once reviewed, veri­fied and agreed,
the baseline can be set. The baseline is shown here in yellow. Each activ­ity has a
minimum of four dates, albeit currently the start dates match, as do the finish
dates.
Work on the activ­it­ies then commences . . .

Figure 21.3 Baseline main­ten­ance step 1

214
 Baseline

21.6.4.2 Project progress and delays ensue

. . . and, as progress is not as expec­ted, delays to the sched­ule occur. Each
activ­ity now has a duplic­ate set of dates that differ, except for the start of activ­ity
1, which is shown with an actual start date match­ing the baseline start date.

Figure 21.4 Baseline main­ten­ance step 2

21.6.4.3 Detail is now developed on activ­ity 2; activ­ity 3 is

re-assessed and reduced
At this stage, activ­ity 3 is examined in more detail and re-planned. It is decided
that it can be executed faster than origin­ally inten­ded. This is entered in the
current sched­ule, showing the comple­tion of this fragnet on time. There is no
need to do any baseline main­ten­ance as a result of this re-assessment: the
baseline remains valid and is retained.
At the same time, activ­ity 2 is broken down into more detail, as shown in the pink
bars. Since the budgets will also be broken down to this level of detail, it is neces­sary
to main­tain the baseline – i.e. add bars into the baseline to reflect the new detail.

215
Planning, Scheduling, Monitoring and Control

Figure 21.5 Baseline main­ten­ance 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 activ­ity 2 was linked.
The final working sched­ule and baseline sched­ule will appear as shown: the
original higher-level bars may be retained or deleted, but cannot be used to
measure sched­ule vari­ances.

21.7 Re-baselining: re-planning

Re-planning is under­taken within the scope, sched­ule and budget constraints of
the project. This is done by main­tain­ing the current cost vari­ance and typic­ally

216
 Baseline

Figure 21.6 Baseline main­ten­ance step 4

elim­in­at­ing the sched­ule vari­ance, i.e. the remain­ing 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 of loss of cred­ib­il­ity, the client’s own report­ing require­
ments or other events under which the client wishes to draw a line. The implic­a­
tions of re-planning should be discussed and the selec­tion of this option be
mutu­ally agreed, if possible.

217
Planning, Scheduling, Monitoring and Control

21.7.1.2 When the credibility of the original baseline is lost

In prac­tice, project teams are expec­ted to know the current working sched­ule in
detail. They are meas­ured against a baseline that perhaps moves further from
reality, and from the fore­front of the project team’s thoughts.
Therefore, on a project of long dura­tion, the cred­ib­il­ity of meas­ur­ing against
the original sched­ule may be lost on the project team. In these circum­stances it
may be prudent to diverge from best prac­tice (to main­tain the baseline only) and
consider setting a new set of baseline dates. Since this is a diver­gence from best
prac­tice, it is recom­men­ded that this should not be a regular occur­rence, certainly
not more than an annual event, and prefer­ably no more than half a dozen times
in any project.
It is possible to measure against two baselines (the original and the latest,
perhaps). However, careful consid­er­a­tion should be given to this and to how
widely differ­ent meas­ure­ments should be shared. Indeed, the use of dual
baselines would be likely to be of use only to satisfy differ­ing require­ments for
perform­ance meas­ure­ment. On the prin­ciple of keeping project controls as
simple as possible, meas­ure­ment against two baselines is to be avoided.
In conclu­sion, re-planning as described herein is inten­ded to re-set the baseline
with regard to the timing of oper­a­tions, and will there­fore re-set all sched­ule
vari­ance report­ing. it should, however, have no effect on cost perform­ance
report­ing (i.e. cost vari­ance will remain as it was before the re-plan).

21.8 Re-baselining: re-programming

Re-programming means setting a completely new baseline for the project,
includ­ing both time and budget bench­marks. Basically, this means wiping the
slate clean. Both sched­ule vari­ance and cost vari­ance 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 of cred­ib­il­ity (see below), the client’s own report­ing
require­ments or other events under which the client wishes to draw a line. The
implic­a­tions of re-baselining should be discussed and the selec­tion of this option
be mutu­ally agreed, if possible.

218
 Baseline

21.8.1.2 When the cred­ib­il­ity of the original baseline is lost

In prac­tice, project teams are expec­ted to know, in detail and back­ground, the
current working sched­ule. At the same time, they are meas­ured against a baseline
that, with the passage of time and changes in the current sched­ule, will move
further from reality, and, more pertin­ently, from the fore­front of the project team’s
minds.
On a project of long dura­tion, there­fore, the cred­ib­il­ity of meas­ur­ing against
the original sched­ule may be lost on the project team. In these circum­stances it
may be prudent to diverge from best prac­tice (to main­tain the baseline only) and
consider setting a new baseline. Since this is a diver­gence from best prac­tice, it is
recom­men­ded that this should not be a regular occur­rence, certainly not more
than an annual event, and prefer­ably no more than half a dozen times in any
project.
In conclu­sion, re-baselining is inten­ded to re-set the baseline with regard to
the timing of activ­it­ies, and will there­fore re-set all sched­ule vari­ance report­ing. It
will also re-set the baseline with regard to cost perform­ance report­ing. It is
there­fore likely that this option can only sens­ibly be considered in a cost plus type
contract, or at a point in the contract where a signi­fic­ant re-negotiation has taken
place.

Table 21.1 Baseline main­ten­ance, re-planning, re-baselining matrix

Re-set inter­me­di­ate dates

Re-set contract dates

Budget move­ments*

Additional work*
Additional detail

Re-set budgets

*Authorised change only

Baseline main­ten­ance √ √ √ ×x x× x×

Re-planning √ √ √ √ x× x×

Re-baselining √ √ √ √ √ √

219
Planning, Scheduling, Monitoring and Control

21.9 Notes and rules for sched­ule

main­ten­ance, re-planning and re-baselining
• Work trans­fer should be accom­pan­ied by an asso­ci­ated budget and be agreed
by all stake­hold­ers.
• Do not trans­fer unused budget from closed work pack­ages to other work
pack­ages or plan­ning pack­ages.
• Do not add addi­tional budget to work pack­ages that are in work unless
other­wise approved by the project manager.
• Transfer of budgets should not be used to cover legit­im­ate vari­ances, and the
change control process should check for this.

21.10 The link between change manage­ment

and the project baseline
Only author­ised change (follow­ing appro­pri­ate governance) should be included
in the baseline.

220
22.1 Definition of perform­ance report­ing
Performance report­ing is the meas­ure­ment of progress and spend­ing made to
date compared with the plan. It should inform manage­ment decision making
about steps required to mitig­ate poor perform­ance or maxim­ise better than
planned perform­ance. Thus, it must:

• Measure what has happened:

• Is the project on sched­ule, ahead or behind?
• Is the project getting value for money?
• Forecast what is likely to happen:
• Is the project going to complete on time, ahead, or late?
• What is the fore­cast final cost?
• Is the rate of work suffi­cient, is it decel­er­at­ing or accel­er­at­ing?

Performance reports may take a number of formats, from marked-up sched­ules

through to formal written reports, though it is increas­ingly common for dash­board
reports to be produced that combine report­ing on all aspects of projects; health
and safety stat­ist­ics, envir­on­mental, commer­cial, time and cost perform­ance,
supply chain perform­ance, and details of key risks and mitig­a­tions.
Reporting may include analyses based on a variety of methods. These
may range from very simple report­ing through to crit­ical path analysis and
earned value manage­ment. The latter two are considered the best methods
of monit­or­ing and controlling a project, and would be the expect­a­tion for any
complex projects.

221
Planning, Scheduling, Monitoring and Control

There are funda­ment­ally two types of perform­ance report­ing: vari­ance analysis

(which meas­ures what has happened) and perform­ance analysis (which also
fore­casts what is likely to happen).
Variance analysis includes the follow­ing methods, which will be discussed in
this chapter:

• drop line method;

• activ­ity weeks method;
• mile­stone monit­or­ing;
• line of balance;
• cash-flow monit­or­ing;
• resource monit­or­ing
• cost value analysis
• quantity tracking.

Performance analysis includes the follow­ing methods, which will be discussed in

this chapter:

• network analysis and measurement of float usage;

• earned value analysis.

In general, the vari­ance analysis tech­niques are simple to do and under­stand, but
they are backward-looking, often with no way of enabling projec­tions and
fore­casts. Performance analysis tech­niques are harder to set up and run, but do
have these forward-looking qual­it­ies. Most soph­ist­ic­ated projects will run both
forms of perform­ance analysis, as even these are comple­ment­ary and measure
differ­ent things. Variance analysis tech­niques are used to comple­ment and help
commu­nic­ate where neces­sary or useful.

22.2 Purpose of perform­ance report­ing

Performance report­ing is under­taken to check whether satis­fact­ory progress is
being made and to identify any correct­ive actions that may be required. Reporting
is under­taken to commu­nic­ate the status of the project to those who need to
know. Part of the perform­ance monit­or­ing regime should ensure that records are
made at the time, and retained in a form that allows retrieval and analysis in the
future for contractual or know­ledge manage­ment purposes.

222
 Performance report­ing

Consideration should be given to the various methods of performance reporting

avail­able, and deploy­ing them as appro­pri­ate. It is worth noting that rarely, except
in the simplest of projects, will one method provide a picture of project status that
is accur­ate and under­stand­able to all stake­hold­ers. Most advanced projects will
use a combin­a­tion of network analysis and float usage with an earned value
analysis, but even then addi­tional tools such as quant­ity track­ing (good for commu­
nic­a­tion) or resource track­ing (good for future resource plan­ning) may be deployed.
A good control system:

• rapidly brings perform­ance issues to manage­ment atten­tion;

• motiv­ates the correct beha­viours to improve perform­ance – on the posit­ive
side by showing what needs to be done and on the negat­ive side by showing
what will happen if nothing is changed;
• integ­rates time, cost and risk;
• promotes aware­ness of time, cost and risk;
• summar­ises data at an appro­pri­ate and digest­ible level of detail;
• enables accur­ate fore­cast­ing and trend­ing;
• is easy to use and under­stand.

22.3 Evaluating and record­ing progress

22.3.1 Progress assess­ment
There are three elements required for any perform­ance meas­ure­ment: a
baseline to measure against; actual data (cost, for example); and an assess­ment
of what has been achieved (a phys­ical percent­age complete against an activ­ity).
Progress is best eval­ua­ ted by those respons­ible for the work. Progress will be
entered into the sched­ule – often by the planner. The planner’s role also includes
the chal­lenge, valid­a­tion and veri­fic­a­tion of the progress inform­a­tion. The client
or his repres­ent­at­ive may also wish to verify the progress repor­ted within the
sched­ule.

22.3.2 What needs to be recor­ded in the sched­ule?

• The date to which the progress is being repor­ted.
• Percent­age complete (this measure should be based on the phys­ical comple­tion
of the activ­ity) in order to enable assess­ment of progress.

223
Planning, Scheduling, Monitoring and Control

• Remain­ing dura­tion (this is based on the outstand­ing work on the activ­ity) in

order to facil­it­ate re-calculation of the network (crit­ical path analysis).
• Actual start and actual finish dates, in order to build up the history of the project.

22.3.3 What else needs to be recor­ded in a report?

• Reasons for any delays;
• Trend curves to display progress.

22.3.4 How often is progress recor­ded?

Frequency of progress update will depend on the circum­stances. Hourly progress
updat­ing may be used in cases of crit­ical plant shut-downs, but weekly updat­ing
of progress is more appro­pri­ate on most projects. On some larger-scale projects,
monthly updat­ing of progress may be considered appro­pri­ate. If this is the case,
it is neces­sary to ensure that the mech­an­ism for record­ing actual start and actual
finish dates is suit­ably robust. In addi­tion, any type of trend analysis will take
longer to produce any mean­ing­ful results or correct­ive action.
Critical path analysis and trend analysis should be carried out on each progress
update. It is also useful at this stage to ensure that any emer­ging trends are
picked up as early as possible. For example, on weekly progress updat­ing a trend
will be avail­able after 3 weeks, whereas monthly updat­ing will take a minimum of
12 weeks.
Formal progress report­ing is gener­ally conduc­ted on a monthly or 4-weekly basis.

22.4 Variance analysis methods of progress

monit­or­ing
22.4.1 Drop line method
A vertical line is drawn at the point of the progress assess­ment date (some­times
referred to as ‘time-now’ or data date) across the bars on the sched­ule. At each
inter­sec­tion with an activ­ity, the line is ‘diver­ted’ to a point on the bar considered
to repres­ent its progress: for example, if a bar repres­ents work that is sched­uled
to be complete, but is only 30% complete, the vertical bar is diver­ted to cross the
bar at the 30% point. This process is repeated to produce what is some­times
referred to as a drop line or jagged line (Figure 22.1).

224
 Performance report­ing

Figure 22.1 Illustration of the drop line method

If a project is perfectly on sched­ule, then the drop line remains vertical. Thus
the devi­ations clearly indic­ate which activ­it­ies are ahead and which are behind.
Whilst this is a good way of looking at the detail, it is not adequate for complex
logic-linked sched­ules.

22.4.1.1 Advantages of this method

• Provides a detailed record of each activ­ity’s progress.
• Iden­ti­fies all activ­it­ies that are behind and may require atten­tion.
• A quick visual inter­pret­a­tion.

22.4.1.2 Limitations of this method

• Static: no re-scheduling of the sched­ule means effects of delay cannot be
easily assessed, thus ignor­ing float and the possib­il­ity of avoid­ing unne­ces­sar­
ily remedial action to get the project back on time.
• Not a very mean­ing­ful descrip­tion of where the project is in overall terms (or
even on a sectional basis).
• Actual start and finish dates are not recor­ded.
• Will not be of much use in demon­strat­ing delay.

225
Planning, Scheduling, Monitoring and Control

• It is diffi­cult to change the sched­ule, add data etc. Adding a new activ­ity may
not be shown in a logical posi­tion if this is not done in schedul­ing soft­ware.
• Ultimately the sched­ule will not be a tool for proact­ively managing time, as it
will have become unrep­res­ent­at­ive of a real­istic approach to the work.
• Becomes even more unreal­istic if re-sequencing takes place.
• Activity-based method that does not measure ‘work’.
• It meas­ures time, but has no measure of cost versus value.

22.4.1.3 When can this be used?

Large or complex projects should have a detailed logic-linked sched­ule. However,
this method could some­times be used along­side other more soph­ist­ic­ated
tech­niques such as crit­ical path analysis and earned value analysis.

22.4.2 Activity weeks method

In order to monitor overall perform­ance on a project, one simple way is to measure
the number of activ­it­ies each week (Figures 22.2 and 22.3). This does, of course,
take into account all the activ­it­ies but does not allow ‘weight­ing’ of the tasks.
This method has been proven to be not only grossly inac­cur­ate, but also
very mislead­ing, some­times crit­ic­ally so. Consequently it is not recom­men­ded as
good, or even accept­able, prac­tice in this guide and is included for complete­ness
only.
For example, there may be 20 pipe fitters perform­ing one activ­ity and two
paint­ers on the next. Typically, in construc­tion, the mech­an­ical and elec­trical
activ­it­ies can comprise 30–40% of the value of the project, so a large part of the
project could be described very briefly on the sched­ule and would not repres­ent
a fair propor­tion of the work.
It is not untyp­ical for projects, partic­u­larly larger ones, to commence with
fairly detailed sched­ules for the earlier stages and less detail for the later
stages. This is known as rolling wave plan­ning. In this instance, activ­ity weeks
could grossly distort the posi­tion, as the sched­ule would be heavily weighted
in favour of the front end and the project would appear to be far more complete
than it is.

22.4.2.1 Advantages of this method

• A simple one-page picture of project posi­tion, but . . .

226
 Performance report­ing

Figure 22.2 Simple ‘activ­ity weeks’ monit­or­ing chart

22.4.2.2 Limitations of this method

• This method gives no certainty about sched­ule posi­tion, and there is no
cred­ible or intel­lec­tu­ally support­able approach for project­ing the trend
forwards.
• It meas­ures time, but has no measure of cost versus value.

22.4.3 Milestone monit­or­ing

Key interim mile­stones are set by attrib­ut­ing activ­ities to them. Achievement or
slip­page of the mile­stones is then monitored. Milestones may be used to
determ­ine payment. When used in conjunc­tion with more soph­ist­ic­ated methods,
milestone monitoring can be a comple­ment­ary means of visu­al­ising the achieve­
ments of the project and the future fore­cast.

227
Planning, Scheduling, Monitoring and Control

Figure 22.3 Cumulative results from the ‘activ­ity weeks’ chart

22.4.3.1 Advantages of this method

• A useful way of summar­ising the project, and attrib­ut­ing respons­ib­il­ity and
personal targets accord­ingly.
• Focus on key object­ives.
• Simple, clear report­ing.
• Easy to do and under­stand.

22.4.3.2 Limitations of this method

• There is a danger of this method being very mislead­ing if mile­stones are not
clearly defined.
• The mile­stones do not neces­sar­ily cover all the scope.
• It can adversely influ­ence prior­it­ies, partic­ul­arly when asso­ci­ated with payment
mile­stones, as undue effort is asso­ci­ated with achiev­ing these mile­stones as
opposed to the full crit­ical path.
• It meas­ures time, but has no measure of cost versus value.
• There is a danger of only real­ising that a mile­stone has been missed after the
event, when it is too late to take correct­ive action.
228
 Performance report­ing

Figure 22.4 Recording actual progress in line of balance

• It tends to focus on activity completion dates to the detriment of activity start

dates.

22.4.4 Progress on a line of balance chart

A line of balance chart with progress to date is shown in Figure 22.4.
Progress is monitored on these charts against the sched­uled lines, and action
can then be taken as appro­pri­ate. In Figure 22.4 the solid lines repres­ent the
sched­uled produc­tion of units against time, and the dotted lines repres­ent the
progress recor­ded against each trade. It clearly demon­strates the required
produc­tion rates and that which was achieved.
In this example, the first activ­ity is shown start­ing on time but at a slower rate than
sched­uled. Eventually it accel­er­ates until it is nearly back on sched­ule. It then slows
before accel­er­at­ing until becoming ahead of sched­ule. It finally finishes on time.

22.4.4.1 Advantages of this method

• Clear graph­ical display of progress.
• Productiv­ity is meas­ured, and presen­ted graph­ic­ally.
• Partic­u­larly useful for repet­it­ive work at macro level (e.g. fit out of resid­en­tial
units) or micro level (e.g. monit­or­ing number of pieces of steel­work erected).

229
Planning, Scheduling, Monitoring and Control

22.4.4.2 Limitations of this method

• It is not avail­able in main­stream soft­ware, although add-on/special­ist soft­ware
is avail­able.
• It meas­ures time, but has no measure of cost versus value.

22.4.5 Cash-flow monit­or­ing

This focuses only on the finan­cial spend of a project. Spreadsheets are usually
prepared with planned budgets per week/month. The actual spend is then
monitored against the planned budget figures.

22.4.5.1 Advantages of this method

• Project finan­cing: if funds are finite, it gives advance warning of impend­ing
short­ages.

22.4.5.2 Limitations of this method

• Does not relate spend to phys­ical progress: it tells you nothing about project
perform­ance (i.e. it cannot be determ­ined whether actual spend­ing above the
planned level means the project is over-spending, or that progress is ahead of
sched­ule).
• Can be mislead­ing if the early part of the project has a lot of expens­ive costs,
e.g. purchase of plant or mater­i­als. Spending alone cannot be used to
determ­ine the status of the project.
• For these reasons, cash-flow monitoring should not be used in isol­a­tion.

22.4.6 Resource monit­or­ing

A simple measure based on sched­uled resource usage across a sched­ule. Actual
resource usage is plotted against planned to give a measure of ‘progress’.

22.4.6.1 Advantages of this method

• If partic­u­lar resources are crit­ical, then this can be an import­ant measure.
• Can be used to fore­cast when resources are becom­ing avail­able for other
works.

230
 Performance report­ing

• May be used where envir­on­mental concerns limit usage (for example, lorry
move­ments in built-up areas).

22.4.6.2 Limitations of this method

• Can be mislead­ing, with a lot of man-hours being expen­ded but little actual
progress on the works.
• Provides a measure of effort rather than progress.
• For these reasons, it should not be used in isol­a­tion.

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 of the work done (‘earned
value’ or similar). The analysis is under­taken against the agreed cost break­down
struc­ture (Figure 22.5).
This clearly high­lights areas of over- or under-spend, and will provide the basis
for estim­ates of the final cost of the project.

22.4.7.1 Advantages of this method

• Ensures project cost inform­a­tion is struc­tured, analysed and inter­preted.
• Relat­ively simple to do and under­stand.
• High­lights areas of poor or good perform­ance to prompt manage­ment action.

22.4.7.2 Limitations of this method

• Does not provide trend data in the way that earned value analysis does.
• Does not require the integ­ra­tion of cost and time.
• Cannot be used as a time-phased finan­cial fore­cast­ing method.

22.4.8 Quantity track­ing

The monit­or­ing of key quant­it­ies (also known as produc­tion curves) is a
useful method for key tasks that are heavily depend­ent on the quant­ity of mater­ial
deployed, moved or altered, or for tasks that are very numer­ous and broadly
repet­it­ive. An example of the former would be earth­mov­ing in construc­tion;
an example of the latter would be the produc­tion of design deliv­er­ables (such

231
Figure 22.5 Sample cost value report
 Performance report­ing

Figure 22.6 Quantity track­ing with produc­tion curves

as draw­ings) in any engin­eer­ing project, or lines of code in a soft­ware devel­op­

ment project.
Note: Although not shown in Figure 22.6, a useful addi­tional line to show
might be the assumed rate at tender or the organ­isa­tion’s normal output rate: this
may put any peaks or troughs in the daily expec­ted outputs into perspect­ive.

22.4.8.1 Advantages of this method

• Easily and readily under­stood.
• Highly relev­ant if key tasks or quant­it­ies are chosen.
• Will high­light areas where correct­ive plan­ning is required.

22.4.8.2 Limitations of this method

• Only really relev­ant to suit­able items of meas­ure­ment.
• Cannot be aggreg­ated to give a holistic picture of the project.

233
Planning, Scheduling, Monitoring and Control

• Does not give a measure of value for money.

• May be mislead­ing if the quant­it­ies referred to are estim­ated rather than
accur­ate, or may other­wise vary when under­tak­ing the work.

22.5 Performance analysis methods of

progress monit­or­ing
22.5.1 Network analysis and meas­ure­ment of float usage
This method follows the progress update of the sched­ule and subsequent
network and crit­ical path analysis. This will resched­ule activ­it­ies to where they
are now likely to take place and may there­fore affect the end date, sectional
comple­tion dates or sub-contractor sched­ules. This, in turn, raises such poten­tial
issues as preserving continu­ity of work, accel­er­a­tion or decel­er­a­tion of activ­it­ies,
paral­lel working, or delays to activ­it­ies which will need consid­er­a­tion and
manage­ment action.
Once the crit­ical path analysis has been run, the crit­ical path may change,
and differ­ent float paths may have been calcu­lated. It is there­fore essen­tial
to monitor the use of float where it exists. This will ensure that there is an
aware­ness of emer­ging crit­ical paths, should either under-performance or,
indeed, accel­er­ated perform­ance create these.

Table 22.1 Measurement of float usage

Date Baseline Forecast Float Current Delta Commentary
date date last float
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 comple­tion 2/6/18 2/6/18 30d 28d –2d

22.5.1.1 Advantages of this method

• The crit­ical path is a logical, math­em­at­ical model of the project that forces
atten­tion onto import­ant activ­it­ies.

234
 Performance report­ing

• The crit­ical path is always current.

• Effects of delays are more likely to be analysed.
• Actual start and actual finish dates are more likely to be recor­ded.

22.5.1.2 Limitations of this method

• There is a risk with just monit­or­ing the crit­ical path that managers only look at
the crit­ical activ­it­ies rather than the near-critical paths.
• The crit­ical path tends to be less relev­ant at the end of a project. The avail­ab­il­
ity of resources to complete the final activ­it­ies often becomes a more crit­ical
factor for project comple­tion.
• It as an activity-based method that does not measure ‘work’ done.
• This is a soph­ist­ic­ated tech­nique, and appro­pri­ate skills and time are required
to under­take it.
• It meas­ures time, but has no measure of cost versus value.

22.5.2 Earned value analysis

22.5.2.1 Definition of earned value analysis
Earned value analysis (EVA) is a performance analysis method that compares the
sched­uled amount of work (planned value) with the achieved amount of work
(earned value) at a point in time. It also compares the work achieved (earned
value) with the cost of achiev­ing that work (actual cost). From these three pieces
of data, perform­ance can be trended and metrics calcu­lated to express the status
of the project.
Furthermore, it has been demon­strated that simple predict­ive calcu­la­tions can
be highly indic­at­ive of likely project outcome in terms of both time and final cost,
provided that appro­pri­ate care and exper­i­ence are used in creat­ing the baseline,
gath­er­ing data and inter­pret­ing the calcu­la­tions.
A detail explor­a­tion of earned value can be found in the APM’s Earned Value
Handbook (APM, 2013).

22.5.2.2 Purpose of earned value analysis

Earned value analysis (EVA) is a performance analysis method that, when
used prop­erly, improves the deliv­ery of projects. It does this by shining a light
on perform­ance issues. Using the data prop­erly means that discus­sions are

235
Planning, Scheduling, Monitoring and Control

promp­ted by those who can make a differ­ence, effect­ing changes neces­sary

to improve perform­ance. Where this is not possible, EVA provides an early
warning of likely outcome in terms of cost perform­ance and likely comple­tion
date.
EVA brings together the cost and time manage­ment of a project. It enables
proact­ive manage­ment of a project, as it gives certainty of project status, produces
metrics that aid project manage­ment by allow­ing visib­il­ity of perform­ance, and
permits remedial action to be under­stood and taken.
In addi­tion, it rein­forces best prac­tice, as it requires a struc­tured approach to
plan­ning. It provides a robust link between time and cost manage­ment,
encour­aging construct­ive working rela­tion­ships. It forces project managers to
consider and address cost and time issues at an early enough point to allow
remed­ies to be cheaper and more effect­ive.
EVA is a comple­ment­ary method to robust tech­niques, in partic­u­lar crit­ical
path analysis, but replaces the flawed and poten­tially mislead­ing activ­ity weeks
method, which is to be avoided on all but the simplest projects.

22.5.2.3 Basic termin­ol­ogy

Budget at Completion (BAC): The final planned budget at comple­tion of the
project.
Planned Value (PV): The approved budget for the work sched­uled to be
completed by a specified date. Also known as budgeted cost of work sched­uled
(BCWS)
Earned Value (EV): The approved budget for the work actu­ally completed by
the specified date; also referred to as the budgeted cost of work performed
(BCWP).
Actual Cost (AC): The costs actu­ally incurred for the work completed
by the specified date; also referred to as the actual cost of work performed
(ACWP).

22.5.2.4 Establishing a budget-loaded sched­ule

The purpose of budget loading the sched­ule is to estab­lish cost targets for
indi­vidual elements of the work. The budget elements are shown in Figure 22.7.
The perform­ance meas­ure­ment baseline (PMB) is estab­lished by alloc­at­ing
budget to the plan at activ­ity level. Usually this is in terms of money and man-days/
hours.

236
 Performance report­ing

It is import­ant to alloc­ate budget at an appro­pri­ate level of detail to facil­it­ate

accur­ate calcu­la­tions for planned and earned values: this would normally
mean activ­it­ies of dura­tion between 4 and 6 weeks, though there will be
excep­tions in both direc­tions. Care should be taken with activ­it­ies of longer
dura­tion than 6 weeks, and if these are used, they should be easy to assess
with an appro­pri­ate, object­ive measure. On the other hand, the greater the
gran­ul­ar­ity achieved in the sched­ule the more subject­ive the assess­ment
can be, without comprom­ising the essen­tial integ­rity of the EVA system.
(Greater gran­ul­ar­ity implies that smaller ‘pieces of work’ are meas­ured, and
the subject­ive nature of the assess­ment is thus reduced to an accept­able level
of detail.)
Failure to alloc­ate budgets at an appro­pri­ate level in the PMB will lead to
inac­curacies in the calcu­la­tion of the planned value and earned value.

Figure 22.7 Budget alloc­a­tion to the plan

22.5.2.4.1 Work pack­ages

The work package is the lowest level at which perform­ance data is normally
analysed. It will be a node on the WBS. The work package will contain a number
of activ­it­ies that describe the work, and the budgets must be alloc­ated at
activ­ity level. Attention is required to ensure that an adequate level of detail is
achieved in these activ­it­ies. Typically they should have a maximum of 4–6-weeks
dura­tion for projects exceed­ing 12 months, but there will always be excep­tions.
However, for longer activ­it­ies it is import­ant that progress can be easily and
clearly meas­ured.

237
Planning, Scheduling, Monitoring and Control

Management and support activ­it­ies are included in work pack­ages, and it is

import­ant to measure perform­ance against budget. They are gener­ally progressed
as level of effort activ­it­ies, as referred to later in this section.

22.5.2.4.2 Planning pack­ages

Planning pack­ages is the term used to refer to work pack­ages where detail is not
yet planned, or work is yet to be alloc­ated. They are, by defin­i­tion, some time in
the longer-term future, possibly as a part of rolling wave plan­ning.

22.5.2.4.3 Management reserve and contin­gency

Management reserve is budget allowed for unknown unknowns, and should not
normally be included in the perform­ance meas­ure­ment baseline. EVA is not
designed to give any useful measure of perform­ance against contin­gency;
separ­ate meas­ure­ments are appro­pri­ate for monit­or­ing its use.

22.5.2.4.4 Risk
Risk is the budget allowed for known unknowns. As noted above, there is no
prac­tical benefit in meas­ur­ing risk budget, as there is not a 100% chance of it
being earned, and so it may distort perform­ance meas­ure­ment. However, it is
some­times required to be included for complete­ness. There are a number of
ways of spread­ing the budget for risk. One way is across the remain­ing project
time, but that requires adjust­ment at every progress update. Alternatively, it can
be held in a ‘risk pot’ at the end of the project. In any event, risk money cannot be
earned; it can only be trans­ferred into other work pack­ages, in line with the risk
and change process.

22.5.2.4.5 Risk mitig­at­ ions

Risk mitig­a­tions are agreed actions that have resul­ted from the risk process.
These should be considered and included in the sched­ule where relev­ant – i.e.
where they have an influ­ence on time and the network of activ­it­ies (as opposed
to, for example, manage­ment actions such as ‘addi­tional staff brought in to
mitig­ate risk of. . .’), although in all cases any asso­ci­ated budget must be reflec­ted
in the perform­ance meas­ure­ment baseline. The mitig­a­tions will be held in the
relev­ant work or plan­ning package.

238
 Performance report­ing

22.5.2.4.6 Contractor’s fee

As noted above for manage­ment reserve, there is no prac­tical benefit in meas­ur­ing
this item, though it is often required to be included for complete­ness. It should
be treated as a level of effort activ­ity, such that planned value always equals
earned value. It should be noted that the effect of treat­ing this as a LOE activ­ity is
to skew the overall SPI towards 1.0, as the SPI for a LOE activ­ity is always 1.0.

22.5.2.5 How to deal with infla­tion

Inflation will raise the cost of labour and mater­i­als during the life of the project. If
infla­tion needs to be taken into consid­er­a­tion in project budgets, for example if a
project spans multiple years, then a way of dealing with it is required. It is common
to use index­a­tion tables to agree the sums involved. This is to ensure that a
compar­ison between budgeted figures (in the form of planned value) and
out-turn figures are like for like. There are two options:

• Add (or deduct!) an allow­ance into the value.

• Deduct (or add!) an allow­ance from the actual costs before calcu­lat­ing 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 alloc­a­tion of budget to the sched­ule is complete, a baseline is set. This
baseline should not then be adjus­ted without the appro­pri­ate change control
process approv­ing such a change.
Once the sched­ule is suffi­ciently developed and stable, it should be set as the
perform­ance meas­ure­ment baseline (PMB). This then forms the basis for
meas­ur­ing all future progress and perform­ance.

22.5.2.7 Drawing S-curves with EVA

22.5.2.7.1 Planned value
Once the budget has been alloc­ated (usually reflec­ted in the plan­ning soft­ware), an
S-curve for the planned value over time can be created, as shown in Figure 22.8.

239
Planning, Scheduling, Monitoring and Control

Figure 22.8 Planned value curve

22.5.2.7.2 Measuring progress to calcu­late earned value

Earned value is the value of the work that has been completed, and is calcu­lated
by collat­ing the percent­age comple­tion multi­plied by the total budget of each
activ­ity.
As the project is executed, progress is meas­ured peri­od­ic­ally, with each activ­ity
assessed for phys­ical percent­age complete. (The methods of meas­ure­ment are
discussed later.) Summation of all the progress recor­ded enables a progress
curve to be plotted. This is the earned value.
Once the sched­ule has been updated for progress, the earned value can be
plotted against the planned value, as shown in Figure 22.9. The diagram
repres­ents perform­ance less than the planned expect­a­tion, or earned value less
than the planned value line.

22.5.2.7.3 Recording actual costs

It is import­ant to collect actual costs at the right level of detail, as increased gran­
u­lar­ity is very likely to lead to reduced data integ­rity. They should be collec­ted at
the appro­pri­ate level of the WBS (this may also be known as the cost break­down
struc­ture).

240
 Performance report­ing

Figure 22.9 Earned value

Note: It will be neces­sary to allow for accru­als in the cost collec­tion system.
Once the actual costs have been added to the sched­ule, the cumu­lat­ive
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
Planning, Scheduling, Monitoring and Control

excess of what should be expec­ted which would be parity with the earned
value line.

22.5.2.8 Calculation of vari­ances and key perform­ance

indic­at­ors (KPIs)
Having entered the planned value, earned value and actual cost, there are various
earned value calcu­la­tions that can be used to analyse this data (Figures 22.11–
22.13).

22.5.2.8.1 Cost vari­ance (CV)

Cost variance (CV) is a cost compar­ison 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 indic­ates a cost under-run
CV equals 0 indic­ates on budget
CV less than 0 indic­ates a cost over-run

Figure 22.11 Earned value analysis: cost and sched­ule vari­ance

242
 Performance report­ing

22.5.2.8.2 Schedule vari­ance (SV)

Schedule variance (SV) is the cost compar­ison between what has been earned
and what has been budgeted (‘Are we ahead or behind sched­ule?’).
Schedule Vari­ance = Earned Value – Planned Value
SV greater than 0 indic­ates that the project is ahead of sched­ule
SV equals 0 indic­ates on sched­ule
SV less than 0 indic­ates that the project is behind sched­ule

Cost and sched­ule vari­ance can usefully be charted, either separ­ately or

together (see Figure 22.12)

Figure 22.12 Cost and sched­ule vari­ance chart

EVA meas­ures sched­ule perform­ance in terms of value as seen, but also in terms
of time: time vari­ance can be calcu­lated or read off the graph as in Figure 22.13.
This is the differ­ence on the time axis between the quant­ity of work achieved to
date, or earned value, and the corres­pond­ing quant­ity on the planned value curve.
Measuring and express­ing delay in this way may help to give an altern­at­ive
view of progress. It will also not suffer from the issue, already noted, that sched­ule
perform­ance index (SPI) and SV tend towards parity as the project nears

243
Planning, Scheduling, Monitoring and Control

Figure 22.13 Earned value analysis with time vari­ance

comple­tion. (Although it has been stated that this is a flaw in earned value
analysis, in reality we should expect project managers to be aware of approach­ing
comple­tion dates!).

22.5.2.8.3 EVA key perform­ance indic­at­ors

A number of calcu­la­tions can be made: the two most useful, and the basis for
calcu­la­tions of future perform­ance, are the sched­ule perform­ance index (‘How
are we doing against plan?’) and cost perform­ance index (‘Are we effi­cient?’).
These are calcu­lated as follows:

Schedule perform­ance index (SPI) is an indic­a­tion of how far ahead or behind

the planned work is compared with the actual work achieved. A result of 1.0
means that all the planned work was achieved. Its value as an indic­ator dimin­ishes
towards the end of a project.
SPI greater than 1 indic­ates that the project is ahead of sched­ule
SPI equals 1 indic­ates on sched­ule

244
 Performance report­ing

SPI less than 1 indic­ates that the project is behind sched­ule

Cost perform­ance index (CPI) is the ratio of earned value over actual cost. A
figure greater than 1.0 indic­ates that the actual cost of the work achieved cost
less than planned.
CPI greater than 1 indic­ates a cost under-run
CPI equals 1 indic­ates on budget
CPI less than 1 indic­ates a cost over-run
SPI and CPI can usefully be plotted against each other to create a ‘Bulls eye’
chart, as shown in Figure 22.14.

Figure 22.14 Bulls eye perform­ance chart

245
Planning, Scheduling, Monitoring and Control

The shading indic­ates the BRAG rating that may also be alloc­ated to the KPIs,
where
B=Blue: Performance over that expec­ted (and needs invest­ig­at­ing)
R=Red: Performance seri­ously below expec­ted (needs imme­di­ate correct­ive
action)
A=Amber: Performance below expect­a­tion (needs plan­ning or correct­ive action)
G=Green: perform­ance within expect­a­tions (no action required)

22.5.2.9 Forecasting termin­o­logy

Estimate to complete (ETC): An estim­ate of the amount of funds required to
complete all remain­ing work on the project (‘What will the remain­ing work cost?’).

Estimate at comple­tion (EAC): The sum of the actual costs to date plus the
estim­ate to complete (ETC) (‘What is the project likely to cost?’).
EAC = Actual cost + ETC

Figure 22.15 Calculating estim­ated time to comple­tion

246
 Performance report­ing

It has been shown (Webb, Alan (2003, 26) Using Earned Value, Gower) that
math­em­at­ic­ally the formula for EAC can, in fact, be simpli­fied to:

Estimated time to complete (ETTC) can be calcu­lated as follows (Figure 22.15):

Again, It has been shown (Webb, Alan (2003, 26) Using Earned Value, Gower)
that math­em­at­ic­ally the formula for ETTC can, in fact, be simpli­fied to:

22.5.2.10 Earned value tech­niques (EVTs)

The differ­ent methods of meas­ur­ing earned value known as earned value
techniques gener­ally vary accord­ing to the level of detail in the sched­ule.
Short-term hourly or daily sched­ules would prob­ably be progressed daily by site
staff. Very often custom­ers require differ­ent report­ing tech­niques. Some examples
are shown in Figure 22.16. It is import­ant to bear in mind the level of report­ing
detail required when determ­in­ing the gran­u­lar­ity of the sched­ule, as detailed EV
report­ing is diffi­cult from high-level summary sched­ules.

Figure 22.16 Illustration of various earning tech­niques and appro­pri­ate uses

247
Planning, Scheduling, Monitoring and Control

Figure 22.17 Advantages and disad­vant­ages of EVTs

248
 Performance report­ing

22.5.2.10.1 Recognised earned value tech­niques

Figure 22.17 summarises the advantages and disadvantages of EVTs.

22.5.2.11 Advantages of EVA

Below are some of the bene­fits of using earned value analysis on a project:

• Certainty of project posi­tion: what work has been achieved against plan; what
it has cost to reach that level of achieve­ment.
• Whether the work achieved repres­ents good value for money (i.e. has been
achieved effi­ciently).
• Gives early warning of whether the project is likely to finish on time and/or on
budget.
• Improved decision making: guides atten­tion to problem areas that need
manage­ment decisions.
• Provides the basis for informed cost and/or time recov­ery actions.
• Ensures that a robust plan is estab­lished at the outset of the project.
• Management of scope creep through the change control system.
• Ensures cash-flow is meas­ured prop­erly and optim­ised.
• Provides corpor­ate governance (when done across the organ­isa­tion).
• Business bene­fits include turnover, profit and cash being achieved on time or
as soon as prac­tic­able.

22.5.2.12 Limitations of EVA

The view that EVA is best prac­tice in project manage­ment is long estab­lished, but
earned value manage­ment is not the univer­sal panacea of project manage­ment,
and failure can still occur on a project monitored using earned value. One of the
biggest threats is that the project team focus too much on regu­larly generating
the data for EVA and fail to take notice of the messages it gives.
Data integ­rity is also key to making EVA work. With good data, the project
manager has a lot of reli­able inform­a­tion to assist in managing the project, which
greatly assists in decision making.

249
23.1 Definition of cost control
Cost control is the process of collect­ing actual costs and collat­ing them in a
format to allow compar­ison with project budgets, identi­fy­ing vari­ances to
inform decision making and allow action to be taken. In addi­tion, it includes cost
fore­cast­ing.
Cost fore­cast­ing is the process of using perform­ance meas­ure­ment, progress
inform­at­ ion and risk manage­ment to estim­ate how the costs will be spent going
forward to the end of the project or finan­cial year and inform the anti­cip­ated final
cost (AFC).

23.2 Purpose of cost control

Cost control is neces­sary to keep a record of monet­ary (and other) expendit­ure,
for the purposes of:

• minim­ising cost where possible;

• reveal­ing areas of cost over­spend;
• giving suffi­cient detail to allow manage­ment decision making to correct unac­
cept­able over­spend­ing;
• provid­ing data for lessons learned to inform future projects (or phases of the
same project).

251
Planning, Scheduling, Monitoring and Control

23.3 The cost control process

23.3.1 Performance meas­ure­ment baseline (PMB)
The initial cost model forms the basis of the cost-loaded perform­ance meas­ure­
ment baseline and should be aligned with the sched­ule activ­it­ies at an appro­pri­
ate level in order to measure finan­cial progress, fore­cast out-turn project costs
and phasing, and facil­it­ate earned value analysis. When updat­ing or re-setting
the baseline, it is import­ant to ensure that the cost inform­a­tion is up to date, as
any vari­ances may signi­fic­antly affect the project’s ability to high­light and react to
negat­ive trends.

23.3.1.1 Estimates to complete

Estimates to complete (ETC) are prepared as part of the EVA process and are
used to determ­ine how project costs are trend­ing to derive the project Estimate
at comple­tion (EAC).

23.2.1.2 Estimated final cost

The estim­ated final cost (EFC) is prepared as part of the project cost control
process and is used to determ­ine how project costs are perform­ing against the
author­ised project budget. EAC (derived from EVA data) should be used to
chal­lenge the EFC.

23.3.2 The link between cost control

and change control
It is import­ant to ensure that any changes to project costs and/or budgets
are form­ally managed through the project change control process. This not
only facil­it­ates quick and informed finan­cial approvals, helping the project to
move forward, but also leaves a much-needed audit trail for the lessons learned
process at the end of the project. Different levels of change may require differ­ent
change control processes, so ensure any change is managed in the appro­pri­ate
way.
If the change results in amended scope, then the perform­ance meas­ure­ment
baseline must be updated through the appro­pri­ate change control process once
it is approved by the project manager or relev­ant author­ity.

252
 Cost control

23.3.3 Performance meas­ure­ment

The most common method of cost perform­ance meas­ure­ment is the cost value
report, in which actual costs for work under­taken are compared (usually in a
spread­sheet) against the current budget for the same work. A combin­a­tion of the
cost value report and fore­cast future changes are used to inform the estim­ated
final cost (EFC).
Forecast future changes may include:

• anti­cip­ated scope change via client or supplier formal change process;

• known or anti­cip­ated cost over- or under-spends;
• risks or oppor­tun­it­ies;
• infla­tion/index­a­tion;
• exchange rate changes.

These changes will high­light cost vari­ance. This is the differ­ence between the
assumed costs of the project or activ­it­ies in the perform­ance meas­ure­ment
baseline at the point of report­ing, and the actual costs that the project is commit­ted
to at that same point.
A recog­nised best prac­tice around cost control is through the use of earned
value manage­ment where the cost perform­ance index (CPI) is the key indic­ator
of project finan­cial perform­ance. This process is described in detail insec­ti­on
22.5.2. It is ideal for identi­fy­ing where a project is not progress­ing effi­ciently.

23.4 Learning lessons from cost control

Cost control inform­a­tion is funda­mental to the lessons learned process, as it can
provide a data­base of actual costs against activ­it­ies and work pack­ages that can
be used to inform future projects at the incep­tion phase. When dealing with
suppli­ers, the contract admin­is­tra­tion process will reveal unfore­seen changes to
the project and its costs. Ensuring rigid docu­ment control around these changes
can greatly increase future projects’ chance of success through more accur­ate
estim­at­ing and/or a more informed risk manage­ment process.

253
24.1 Definition of short-term plan­ning
The dura­tion of short-term plan­ning may vary depend­ing upon the dura­tion of
the project, but is likely to consist of a 4-week look ahead and a look back at the
previ­ous week’s progress. It would normally be issued weekly. (These dura­tions
would obvi­ously be inap­pro­pri­ate for a weekend shut-down sched­ule!)

24.2 Purpose of short-term plan­ning

The short-term plan­ning process takes the sched­ule out of the computer and
puts it into the hands of the site teams super­vising the work. It should also reflect
current progress, with recov­ery of slip­page if neces­sary.

24.3 The short-term plan­ning process

Short-term plan­ning should be linked to the sched­ules as shown in Figure 24.1.
There should also be a link, or a cross-check with the sched­ules produced at this
level back to the main project sched­ule(s) to ensure that the stra­tegic require­
ments of the project remain achieved.
Short-term, high-density schedul­ing consists of four key elements:

• perform­ance report­ing against last week’s planned work;

• reasons for any non-completed work;

255
Planning, Scheduling, Monitoring and Control

Figure 24.1 Short-term sched­ules in context of other plans

• the work planned over the next 3 or 4 weeks (with a strong emphasis on the
next week);
• the make ready needs for these activ­it­ies (these are the start criteria for each
detailed task).

The short-term schedul­ing is under­taken weekly and is owned by the front-line

staff; in order to facil­it­ate the process an extract of the sched­ule is produced,
typic­ally a 3-month look ahead. This will then be used to gener­ate the 4-week
look ahead, devel­op­ing detail to a day-by-day sched­ule.
Once produced, the sched­ule will be checked against the stra­tegic
require­ments as defined in the current working sched­ule.
Having produced a 4-week ‘look ahead’, the follow­ing are considered:

256
 Short-term plan­ning

24.3.1 Make ready needs

Each activ­ity has ‘make ready needs’ iden­ti­fied. Make ready needs are those
things that must be in place to allow an activ­ity to commence. These may include:

• safe working prac­tices;

• mater­ial call off or avail­ab­il­ity;
• other procure­ment activ­ity;
• method state­ment and other paper­work in place;
• offline prepar­a­tion for task, e.g. in construc­tion the build­ing of form­work
panels;
• outstand­ing design inform­a­tion or RFIs (requests for inform­a­tion);
• comple­tion of works by others (which will feature else­where on the look
ahead);
• access require­ments.

24.3.2 Coordination meeting

Coordination meet­ings are held to review the combined sched­ule, to record
perform­ance against agreed object­ives, and to under­stand and analyse issues
which hinder the progress of those activ­it­ies.
All sched­ules should be issued the day prior to the coordin­a­tion meeting,
allow­ing time for review. This is to ensure that maximum benefit is gained from
the meeting. Discipline is required to ensure that sched­ules are delivered on
time, because the process relies on a large number of people produ­cing their part
of the sched­ule in a timely manner. Strong chair­man­ship of the meeting is
essen­tial to ensure full parti­cip­a­tion and agree­ment of the sched­ule by all.
A key purpose of the meeting is to ensure that all sched­ules are agreed and
issued at the end of the meeting; sched­ules can be hand amended – do not wait
for elec­tronic distri­bu­tion.

24.3.3 Performance report­ing

As part of the meeting, the previ­ous week’s progress should be reviewed, and
any reasons for missed targets are categor­ised against a prede­ter­mined list.
Charts will be produced for analysis outside the meeting (Figure 24.2).

257
Planning, Scheduling, Monitoring and Control

Figure 24.2 Performance analysis on short-term sched­ule

258
25.1 Definition of change manage­ment
Change manage­ment is the formal process through which changes to the project
are raised, assessed, approved, and intro­duced or rejec­ted.
‘Changes’ are events and issues that alter the sched­ule, scope or object­ives. In
broad terms, there are two levels of change:

• Significant addi­tions/omis­sions from the sched­ule scope – these changes will

require amend­ments to the control budget and related sched­ules.
• Amendments to the method of deliv­ery where the funda­mental scope
remains the same. These amend­ments may be the result of clari­fic­a­tion or
devel­op­ment.

Significant changes may arise from:

• inside the project, such as risks impact­ing, adop­tion of wrong strategy, etc.,
where they will be funded from manage­ment reserve draw­down;
• outside the project, such as a new customer require­ment, where they will
require addi­tional funding;
• a change in legis­la­tion.

25.2 Purpose of change manage­ment

Change manage­ment is integ­ral to good project manage­ment because it controls
and author­ises:

259
Planning, Scheduling, Monitoring and Control

• change in scope;
• changes in budgets;
• changes in timing of the project;
• changes in risks that are managed as part of the project;
• changes in expendit­ure.

Thus, it ensures that costs are known and that the supply chain receive fair
recom­pense for any addi­tional work that they perform, whilst protect­ing the
client from paying for works that are not performed.

25.3 Principles of change manage­ment

Any proposed change to the project must be form­ally controlled in order for it to
be dealt with effi­ciently and fairly. The project team, with the support of relev­ant
stake­hold­ers includ­ing the sponsor, should there­fore review changes fully before
their approval and imple­ment­a­tion. The impact of changes on all aspects of the
project in terms of scope, budget, time, quality, safety, envir­on­ment, risk and
oppor­tun­ity should be fully assessed, as well as their impact on busi­ness as usual
and other projects.
The key points of refer­ence when consid­er­ing change are the baseline
(budget/sched­ule plan), and the project execu­tion plan (PEP). The baseline
defines the point against which change is meas­ured, whilst the PEP gives the
detail of how the change process is managed.
All changes should be fully docu­mented and effi­ciently commu­nic­ated to all
relev­ant parties.

25.4 Change control

25.4.1 Why change control is needed
• To ensure all parties are clear regard­ing the scope to be delivered.
• To ensure all parties are clear regard­ing the sched­ule to be delivered to.
• To ensure all parties are clear regard­ing the budgets to be delivered to.
• To ensure clear visib­il­ity of move­ments within published budgets and
sched­ules as the project progresses.
• To enable early recog­ni­tion and manage­ment of issues that could be influ­enced
for the good, i.e. cheaper, quicker, better-quality and more effi­cient solu­tions.

260
 Change manage­ment

• To main­tain an audit trail of who author­ises or rejects change: what, when,

how, for what cost and why?
• To ensure poten­tial change is iden­ti­fied in a proact­ive manner.
• To ensure appro­pri­ate levels of change review and approval are
imple­men­ted.
• To ensure change is repor­ted accur­ately.
• To ensure all options are considered and eval­u­ated.
• To ensure change is imple­men­ted within appro­pri­ate time periods.
• To ensure that the project remains under control and can be delivered in an
afford­able, prof­it­able, value for money manner.
• To ensure that the product delivered meets devel­op­ing customer needs (i.e. is
not against a require­ment that is now obsol­ete).

25.4.2 Change control consid­er­a­tions

The change control process must also consider:

• Unauthorised change: If an unau­thor­ised change is iden­ti­fied, it must be retro­

spect­ively put through the change control process.
• Configuration manage­ment: Change control is intrins­ic­ally linked to config­ur­
a­tion manage­ment. Any changes need to be fed back into the project’s config­
ur­a­tion docu­ment­a­tion. This ensures that the most current information is used
to deliver the project.
• Change freezes: In certain circum­stances, it is appro­pri­ate to have a change
freeze on the project whereby no further changes will be considered, as to do
so would jeop­ard­ise the achieve­ment of the project object­ives.
• An emer­gency proced­ure to enable certain actions (change) to be author­ised,
for example in the case of an emer­ging health and safety issue at a point in
time where usual author­it­ies are unavail­able.
• Trending of change against specific areas will help to reveal under­ly­ing
prob­lems and/or provide an early warning of increas­ing costs and areas
requir­ing manage­ment atten­tion.

25.5 Project-level change: process over­view

Once the project brief has been agreed, the change control proced­ures should
commence.

261
Figure 25.1 Process over­view – project change control

262
 Change manage­ment

Change on projects needs to be closely monitored to ensure that cost, time

and quality are effect­ively controlled and repor­ted. A change control process is
likely to be differ­ent from one company to the next. Similarly, it may vary across
differ­ent indus­tries. The flow chart in Figure 25.1 gives an over­view of a typical
change control process.

25.6 Raising a change request

Potential change can be iden­ti­fied by anyone within the project team. The
poten­tial change is reviewed to determ­ine whether a change of project brief or
scope has occurred, in which case a change request needs to be raised.
A stake­holder who is request­ing change provides relev­ant inform­a­tion on the
nature of the proposed change. This should include a detailed descrip­tion of the
change (what, where, when, who and how, etc.) The posit­ive or negat­ive cost
impact of the change and the impact on the sched­ule should be stated. The
benefit(s) of under­tak­ing the change should be made clear if not already evident
from the fore­go­ing.

25.6.1 Drafting a change request

All formal change requests need to be submit­ted using a change request form.
The change request form is designed to capture the follow­ing detail:

• a descrip­tion of the change;

• a clas­si­fic­a­tion of the change;
• the cost impact (posit­ive or negat­ive);
• the sched­ule impact (posit­ive or negat­ive);
• the approvals required;
• the links to the project risk and oppor­tun­ity registers.

The change request should be accom­pan­ied by all relev­ant docu­ment­a­tion.

25.7 The change log

The change is entered into a Change log, which is a register of all changes that
have been reques­ted, whatever their status, for example pending, approved,

263
Planning, Scheduling, Monitoring and Control

rejec­ted or deferred. It contains a record of each change request and should

include at least the follow­ing:

• unique ID number;
• status of the change;
• change descrip­tion;
• detailed scope of the change;
• category of change;
• created by (the change origin­ator);
• date raised;
• impact assess­ment – scope/budget/sched­ule/risk/safety, etc.;
• author­ity;
• funding/budget;
• decision: (approval/defer­ral/rejec­tion) and date.

25.8 Initial eval­u­ation of the change request

The change is reviewed to consider whether it is worth­while eval­u­at­ing it in
detail. The eval­u­ation of change consumes resources, which in itself is a devi­ation
from the project baseline. The proposed change may be rejec­ted without further
eval­u­ation.

25.9 Estimating impact of change

Impact analysis of the change and asso­ci­ated cost and time estim­ates should be
prepared, reviewed and submit­ted for approval. The estim­ates should include
direct cost and indir­ect cost such as manage­ment, and risks and oppor­tun­it­ies
should be assessed.

25.10 Detailed eval­u­ation of change request

Upon approval of the initial estim­ate, the change is eval­u­ated in detail to consider
the impact on the project’s baseline scope, time, cost, quality or bene­fits. If the
request is rejec­ted, then the relev­ant parties are informed and the change log
updated accord­ingly. There may be a situ­ation where the request is deferred as

264
 Change manage­ment

more inform­a­tion is required. Once that has been supplied, then the request
re-joins the process at detailed eval­ua­ tion stage.
Once a change request has got through the initial eval­u­ation, it proceeds into
the detailed eval­u­ation.
This eval­ua­ tion is usually carried out in a regular change review meeting. The
meet­ings would be atten­ded by all the relev­ant parties on the project, but,
import­antly, they require the project sponsor or author­iser for the change
request.
There are three possible outcomes for a change request:

• rejec­ted;
• deferred;
• approved.

This section will address rejec­ted and deferred (approved change being dealt
with in the next section).

25.10.1 Rejected request

A rejec­ted change request would be recor­ded in the change log stating the
reason for the refusal. This is then commu­nic­ated back to the request­ing party.

25.10.2 Deferred request

A deferred request normally requires more inform­a­tion to be supplied before full
consid­er­a­tion can be given to the request. The team will then carry out a more
detailed eval­u­ation based on the areas where further inform­a­tion is needed. The
results of any invest­ig­a­tion may include a revised sched­ule, indic­at­ing the effect
of signi­fic­ant changes to inter­faces and summary mile­stones. Any changes will
need to be reviewed by all parties concerned.
A deferred request may also be optional change, in that the change will only
be approved if the impacts are within certain para­met­ers. Optional change may
also require the consid­er­a­tion of altern­at­ive sched­ule possib­il­it­ies. In these cases,
‘what if’ or offline sched­ules are used to review the differ­ent options as part of the
change process. There may be more than one ‘what if’ sched­ule required to
model a number of poten­tial options. It is import­ant that the extra inform­a­tion is
returned within the time constraints defined in the contract and performed in
paral­lel with the cost invest­ig­a­tion.

265
Planning, Scheduling, Monitoring and Control

The extra data provided then goes back into the process for detailed eval­ua­ tion.
If agree­ment is not achieved, the sched­ule effects may need to be re-visited
prior to any further action.
Again, the change log would be updated and the details of the inform­a­tion
required passed back to the requester.

25.11 Approved request

If the change request is approved by the author­ised 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 author­ise a change to the project, includ­ing a change
of scope or agree­ment to accept a design solu­tion which is outside the agreed
cost and sched­ule para­met­ers. Once formal approval is received for the change,
the cost and sched­ule baselines are updated.
Change orders are also used to gain formal approval for addi­tional funding
follow­ing a change. They do not, however, change the scope of the project for the
suppli­ers to action, and must always be suppor­ted by an appro­pri­ate instruc­tion.

25.11.1.2 Who raises/author­ises change orders?

A change order is raised by anyone with author­ity to do so (as defined in the
project proced­ures). Once raised, it is endorsed by the project manager prior to
being submit­ted to the project sponsor for author­isa­tion.
Scope can only be instruc­ted and author­ised into or out of the project baseline
by the project sponsor/client, and not the project teams.

25.11.1.3 Commercial signi­fic­ance

The change order only provides author­isa­tion to change the scope. Funding
approval will also be required before the formal instruc­tion for the change can be
issued.

266
 Change manage­ment

25.11.2 Scope trans­fers

In circum­stances where scope is being trans­ferred between teams, a formal
instruc­tion will be issued to confirm the scope and budget trans­fer. Scope
trans­fers should be mutu­ally agreed by the original owner and the proposed
owner.

25.11.3 Schedule revi­sions

If the change affects the scope, then it will be neces­sary to add the change and its
effects into the baseline as well as the working sched­ule.
Alternatively, if the change is within the exist­ing scope, then the working sched­ule
should be amended. Where appro­pri­ate, the baseline will need to take into
account the updated sched­ule.
A change request will be required for any change to the project baseline (but
not the working plan).

25.11.4 Corporate governance

In order to main­tain an effi­cient change manage­ment process, deleg­ated author­ity
can be granted to managers at pre-agreed levels (see Table 25.1).

Table 25.1 Example of finan­cial author­ity

Responsible Instruction value

Project managers Up to and includ­ing £50k

Programme managers Up to and includ­ing £75k

Directors Up to and includ­ing £500k

Board Over £500k

25.12 Implementing the change

The key part of the change process is to imple­ment the change. The project
manager will issue a formal instruc­tion to imple­ment the change.

267
Planning, Scheduling, Monitoring and Control

Once change approvals and finan­cial author­isa­tions are in place, the follow­ing
actions should be taken:

• Update the change logs to reflect the approved status of changes.

• Issue an instruc­tion if appro­pri­ate and record its issue.
• Update reports to reflect cost and sched­ule impacts.
• Update any purchase orders to reflect cost and sched­ule impact.
• Update project execu­tion plans (includ­ing risk/oppor­tun­ity registers) and
project brief.
• Communicate within project team and any inter­fa­cing teams.
• Update the baseline with the agreed change.

25.12.1 Adjusting sched­ule in line with change

Change broadly comes in two categor­ies and may be dealt with in differ­ent
ways: change that is required and change that is subject to further option­eer­ing
or explor­a­tion – i.e. that might not happen. Change will be picked up in the
sched­ule narrat­ive.

25.12.1.1 Optional change

Optional change should be assessed in ‘what if’ or offline sched­ules as part of the
change process. There may be more than one ‘what if’ sched­ule required to
model a number of poten­tial options. This type of change should only be incor­
por­ated into the sched­ule once it has been approved.

25.12.1.2 Required change

Once required change has been iden­ti­fied, it should be reflec­ted in the sched­ule
to ensure that it contin­ues to reflect the inten­ded sequence and scope of works
regard­less of agree­ment. This ensures that a real­istic sched­ule is main­tained and
the crit­ical path remains robust. Only when the change is author­ised will the
budgets contained in the sched­ule (and else­where) be adjus­ted.

25.12.1.3 Reviewing change

Where supplier’s change has been approved, the supplier/contractor should
submit their sched­ule with the agreed change incor­por­ated. The planner should

268
 Change manage­ment

assess the sched­ule to see whether the change accur­ately reflects the agreed
change. Checks will need to be made regard­ing:

• key mile­stone dates;

• key inter­faces;
• crit­ical path.
• sub (or ‘near’) crit­ical paths.

25.13 Communicating the change

Once a change request has gone through the system, and the change log has
been updated accord­ingly, it is import­ant to ensure that all relev­ant parties are
informed. As change is a crit­ical part of any project, it is import­ant that the change
inform­a­tion is quickly read and acknow­ledged by the key parties.
Sending out the latest version of the change log in an email to all the project
team will not get the message across. The issue of a formal instruc­tion does meet
most contrac­tual require­ments, but it is better to also go over the approved
changes at either a regular project team meeting or, better still, a specific change
review meeting.
It is import­ant to ensure that ALL parties are informed, as change often has
far-reaching impacts. As a rule, it is always better to over-inform rather than risk
missing people out, e.g. stake­hold­ers or spon­sors.
As well as the change log, it is import­ant that the process also picks up the
result­ing changes to other key docu­ments, such as: draw­ings; docu­ment control
systems; specific­a­tions; procure­ment orders; sched­ules; cost plans; baselines,
etc.

25.14 Monthly change report­ing

require­ments
It is import­ant to commu­nic­ate the status of change to all inter­ested parties on a
regular basis. Figures 25.2 and 25.3 show examples from a construc­tion project
on change report­ing.

269
Planning, Scheduling, Monitoring and Control

Figure 25.2 Example of monthly change report­ing

Figure 25.3 Monthly change report

270
 Change manage­ment

Definitions used in Figures 25.2 and 25.3:

NEC: New engin­eer­ing contract. Now widely used in the construc­tion industry.
EWN/EON: Early warning notices are used to contrac­tu­ally advise the client or
customer that there could be a poten­tial impact on cost or time (as used within
the NEC contract).
SI: Site instruc­tion. Used on construc­tion projects where a small on-site change
needs to be imple­men­ted quickly.
PMI: Project manager’s instruc­tion. The formal noti­fic­a­tion given by the
project manager usually follow­ing a more detailed review of the impact of
the change.
CO: Change order. These are used to author­ise a change to the project, includ­ing
a change of scope or agree­ment to accept a design solu­tion which is outside
the agreed cost and sched­ule para­met­ers.
BT: Budget trans­fers. Budget trans­fers are made to form­al­ise the move­ment of
scope (budget and sched­ule) from one part of the project to another, or,
indeed, to move scope into or out of the project.

The Projects shall main­tain their own change logs as required accord­ing to Figure
25.3, and shall make these avail­able for inspec­tion or chal­lenge from the sched­ule
change manager at all times.

25.14.1 Managing the sched­ule change process

The update of the sched­ule should be performed (if possible) in advance of the
monthly report­ing cycle to ensure that logic and dura­tion changes do not hinder
the report­ing cycle.

271
26.1 Definition of risk manage­ment
Risk manage­ment is the manage­ment of threats to the project (negat­ive
impacts) and oppor­tun­it­ies (posit­ive impacts). It involves the iden­ti­fic­a­tion and
manage­ment of these issues.
As part of the plan­ning of a project, risk should be considered at all stages.
Risk manage­ment tech­niques will be used to help define cost or budget
allow­ances, allow­ances for sched­ule risk and, indeed, any other types of risk that
a project faces. Thus, risk manage­ment is integ­rated with all other manage­ment
processes and is part of the plan­ning, monit­or­ing and control of a project.
It is worth noting that there is a clear rela­tion­ship between change and risk:
change inev­it­ably intro­duces more risk or greater oppor­tun­ity. In addi­tion, aside
from iden­ti­fied risk and oppor­tun­ity, the sheer fact of chan­ging scope will add
risk into the sched­ule, and the greater the amount of change, the more risk is
intro­duced. There is, there­fore, a strong rela­tion­ship between the manage­ment
of risk and change.

26.2 Purpose of risk manage­ment

Risk manage­ment is required in order to anti­cip­ate threats and oppor­tun­it­ies, and
manage them to ensure the best outcome of the project. This may be in the
follow­ing terms:

• safe execu­tion of the works;

• commer­cial outcome – the best possible value for money being achieved;

273
Planning, Scheduling, Monitoring and Control

• commer­cial outcome – no surprises;

• repu­ta­tional outcome;
• deliv­ery to time constraints;
• quality;
• avoid­ing events that may delay the planned progress of the work;
• incor­por­at­ing oppor­tun­it­ies to save cost or time;
• includ­ing altern­at­ive methods to better coordin­ate the work.

26.3 Risk manage­ment plan

A risk manage­ment plan sets out how the thor­ough assess­ment of risk asso­ci­ated
with the project will be imple­men­ted. This process will be under­taken by working
in collab­or­a­tion with all relev­ant project stake­hold­ers. The risk manage­ment plan
aims to imple­ment this proced­ure in such a way that:

• risks are minim­ised;

• opportunities are maxim­ised;
• risks are owned and managed at the appro­pri­ate level;
• risk mitig­a­tion actions are appro­pri­ate and effect­ive;
• mitigation actions are monitored and managed effect­ively;
• current risks to the project are commu­nic­ated effect­ively.

26.4 The risk manage­ment process

The key stages of the risk manage­ment processes iden­ti­fied in this section are
shown in Figure 26.1 and described more fully in the follow­ing sections.

26.4.1 Planning
26.4.1.1 Planning for risk
Before the commence­ment of a formal risk process, a risk manage­ment plan
should be created, reviewed and accep­ted by all relev­ant parties. Regular risk
work­shops and review sessions will be planned and held through­out the life of
the project.

274
Figure 26.1 Risk manage­ment life cycle
Planning, Scheduling, Monitoring and Control

As part of the prepar­a­tion for initial risk work­shops, project deliv­er­ables will be
clearly iden­ti­fied. The docu­ments that might be consul­ted may include:

• contract docu­ments;
• tender docu­ments;
• project sched­ule and asso­ci­ated sched­ules;
• project execu­tion plan and asso­ci­ated docu­ments;
• risk check­lists (a list of topics and regu­larly encountered threats and oppor­tun­
it­ies for consid­er­a­tion for the work­shop);
• the assump­tions register.

This inform­a­tion will be used to prompt discus­sion and consid­er­a­tion of poten­tial

threats and oppor­tun­it­ies.

26.4.1.2 Risk manage­ment through the project life cycle

During the project, the object­ives are as follows:

• identify new risks and risk mitig­a­tion actions;

• quantify and assess risks;
• establish risk owners;
• ensure manage­ment of risk mitig­a­tion actions (under­taken success­fully and to
sched­ule);
• ongoing review at all levels;
• monitor and relay the manage­ment of risk and risk mitig­a­tions.

26.4.2 Risk iden­ti­fic­a­tion

This step concerns the capture of threats and oppor­tun­it­ies to the project object­ives.
The follow­ing tech­niques may be used:

• risk work­shops;
• inter­views with relev­ant people to benefit from their know­ledge and exper­i­ence;
• risk review meet­ings;
• time issues that are known about or arise from progress report­ing;
• invest­ig­a­tions and surveys;
• lessons learned register/inform­a­tion;

276
 Risk manage­ment

• relev­ant entries in inter­fa­cing risk registers;

• risks noted during devel­op­ment of meth­od­o­logy;
• assump­tions and exclu­sions;
• sub-contractor risk registers;
• risks iden­ti­fied as part of the change process.

A detailed descrip­tion of each key risk is recor­ded within the risk log, together
with the cause, effect, and owners (Figure 26.2).
Where risks have been iden­ti­fied with owners or actions falling outside the
remit of those present, the relevant stakeholders will be noti­fied.

Figure 26.2 Risk iden­ti­fic­a­tion in a typical risk log

26.4.3 Risk assess­ment

To align with the project object­ives, indi­vidual risks and oppor­tun­it­ies will be
considered accord­ing to project-specific impact and prob­ab­il­ity ratings. An
example of what this might look like is shown in Figure 26.3.
Part of the assess­ment step is stating on the register what the exist­ing control
meas­ures are (if any). These are accoun­ted for in the current/pre-mitigation
impact and prob­ab­il­ity ratings.
Each cell shown in Figures 26.3 and 26.4 may be given a numer­ical value; this
is known as the sever­ity rating score, and is used in creat­ing a hier­archy of risks
to high­light those needing the most atten­tion. The criteria for making these
assess­ments will depend on the type of risk: monet­ary values for commer­cial
risks, periods of time for sched­ule risks, and so on. In the case of these two
examples, there may be an assess­ment based on three-point estim­ates and
distri­bu­tion criteria, discussed later in this section. In other cases, there may be a
set of qual­it­at­ive state­ments; for example, a safety risk might be categor­ised by
the poten­tial for harm to indi­vidu­als (report­able acci­dents, for example). These
categor­ies will vary between organ­isa­tions based on their risk appet­ite.

277
Planning, Scheduling, Monitoring and Control

Figure 26.3 Risk assess­ment matrix – sever­ity ratings score

Figure 26.4 Opportunity assess­ment matrix – sever­ity ratings score

It should also be borne in mind that risks may have a time envel­ope within
which they may occur, and another way of defin­ing prior­ity will be those risks
likely to occur in the near-term future, whether these be threats or oppor­tun­it­ies.
The assess­ments thus made may be categor­ised and entered in the risk log
(Figure 26.5).
It is good prac­tice to capture the justi­fic­a­tion behind the scoring (the basis of
estim­ate) – it is often chal­lenged, partic­u­larly where the risk mitig­a­tion actions
need a cost–benefit analysis.

278
Figure 26.5 Typical risk log (contin­ued from Fig 26.2), showing current impact and response plan­ning
Planning, Scheduling, Monitoring and Control

26.4.4 Risk response

For each risk, the risk owner must estab­lish a level of mitig­a­tion to the satis­fac­tion
of the project manager.
Factors causing the risk must be under­stood to help determ­ine the appro­pri­ate
mitig­at­ ion actions. These mitig­a­tions are recor­ded in the risk register.
If effect­ive mitig­a­tions cannot be iden­ti­fied to control the risk, then mitig­a­tions
need to be sought to reduce the consequences to an accept­able level. Figure
26.6 summar­ises risk response options.
After taking into account the anti­cip­ated effect­ive­ness of the mitig­a­tion plan,
it is usual to re-score the risk to provide a target for the reduc­tion of risk and
an assess­ment of resid­ual risk (which is the element of risk that has not
been mitig­ated). In effect, this is an assess­ment of the value of under­tak­ing
the mitig­at­ing actions. Mitigations that need funding (i.e. add new scope to the
project’s work­load) need to enter the sched­ule through the change process.

Figure 26.6 Risk response options

26.4.5 Risk review

The review process allows a final check of the key risks by the project manager.
This review and valid­a­tion comprises the process by which the project manager
accepts account­ab­il­ity for the risk inform­a­tion.
The project manager will under­take review of the risk log regu­larly through
the life cycle of the project. This review consists of the follow­ing:

280
 Risk manage­ment

• Detailed review of the most crit­ical risks and oppor­tun­it­ies (at least, but not
limited to, those risks deemed to be ‘red’ risks in accord­ance with the sever­ity
rating score).
• Have the deleg­ated response plans been imple­men­ted, progressed or
completed?
• Have exist­ing item scores increased or decreased due to changes in like­li­hood
or impact?
• Are addi­tional mitig­a­tion meas­ures required?
• Can exist­ing risks and oppor­tun­it­ies be closed?
• Check and agree whether any draw down of manage­ment reserve is required.
• Review the need for any focused work­shops on any of the matters raised in
the review.

26.4.6 Risk report­ing

Reporting will be based on the data in the risk log, which will be updated and
reviewed each report­ing cycle. As well as the inform­a­tion illus­trated above,
addi­tional fields may be used to capture track­ing data. This will provide risk
manage­ment inform­a­tion to support report­ing require­ments (see Figures 26.7
and 26.8).

26.5 Risk draw down

Risk draw down is the move­ment of budget in the risk pot, usually into the
perform­ance meas­ure­ment baseline (PMB). The project should set guidelines
for the draw­down of risk monies and the author­ity required to do so. It should
be stressed that the contrac­tual situ­ation and budget owner­ship will dictate

Figure 26.7 Reporting of basic risk data

281
Figure 26.8 Tracking risk perform­ance over time
 Risk manage­ment

how this is dealt with; the follow­ing are sugges­ted ways of drawing down risk
budget.

26.5.1 When risks are mitig­ated

When mitig­a­tion plans are put in place that involve incur­ring cost, an appro­pri­ate
sum may be drawn down from the manage­ment reserve and attrib­uted to new or
exist­ing activ­it­ies in the PMB. This is effect­ively an addi­tion of scope to the
activ­ity as well as budget.

26.5.2 When risks are real­ised

When risks are real­ised that involve incur­ring cost, an appro­pri­ate sum may be
drawn down from manage­ment reserve and attrib­uted to appro­pri­ate activ­it­ies in
the PMB. This is effect­ively an addi­tion of scope to the activ­ity as well as budget.

26.5.3 When risks are closed

When risks are closed, their impact upon the risk expos­ure will clearly be
reflec­ted. However, depend­ing on the contrac­tual situ­ation, risk allow­ances may
be main­tained. There are a number of options for dealing with this allow­ance:

• Where risk expos­ure is greater than allow­ance, retain the allow­ance in the risk
register, re-allocating to new or emer­ging risks if appro­pri­ate.
• Where risk allow­ance is greater than expos­ure, then a portion of risk allow­ance
may be released to ‘profit’.

26.5.4 When oppor­tun­it­ies are real­ised

When oppor­tun­it­ies are real­ised, the budget will stay in the project. There are a
number of options that may be appro­pri­ate, and the project team must consider
the follow­ing:

• Move budget from relev­ant activ­it­ies to the ‘manage­ment reserve’: in some

cases, the real­isa­tion of an oppor­tun­ity may need to be balanced by the intro­duc­
tion of a new risk. For example, the relax­a­tion of strict working patterns would be
an oppor­tun­ity to complete work faster and more cheaply, but the risk that the
relax­a­tion in condi­tions may not continue in future should be captured.

283
Planning, Scheduling, Monitoring and Control

• Do nothing – this would result in posit­ive vari­ance in cost or sched­ule. Care

should be taken that this posit­ive value does not mask poor perform­ance.
• If funds are used to pay for a mitig­a­tion to realise the oppor­tun­ity, suffi­cient
value to cover this expense would be alloc­ated as appro­pri­ate, and there may
also be a release of budget from the baseline to reflect the cost–benefit of the
oppor­tun­ity.

26.5.5 Documenting changes in the risk budget

All move­ments in the risk budget must be docu­mented for control purposes.
Also, records should be kept of the contin­gency allow­ances under lessons
learned, for future projects.

26.6 Quantitative sched­ule risk

analysis (QSRA)
26.6.1 Definition of QSRA
Once the sched­ule has been created, reviewed and veri­fied, a quant­it­at­ive
sched­ule risk analysis (QSRA) will apply stat­ist­ical tech­niques to test the level of
confid­ence in meeting the comple­tion date.
This analysis looks at the whole sched­ule and not just the crit­ical path. The
conclu­sion of this analysis may result in a completely differ­ent set of linked
activ­it­ies that determ­ines a ‘most likely’ comple­tion date.
A QSRA relies on Monte Carlo analysis. A Monte Carlo analysis is a set of
calcu­la­tions that rely on repeated random sampling to obtain a range of results –
a prob­ab­il­ity distri­bu­tion. The sampling is based on inform­a­tion provided by the
user.
There are two elements to QSRA:

• dura­tion uncer­tainty (a minimum, most likely and maximum spread of activ­ity

dura­tions);
• risk impact (minimum/most likely/maximum).

In some organ­isa­tions QSRA is referred to as times­cale risk analysis, but this

guide will use the QSRA term.

284
 Risk manage­ment

26.6.2 Purpose of QSRA

26.6.2.1 Improve the quality of the project sched­ule
The best mitig­a­tion strategy for risk on a project is to have a robust and logic­ally
sound sched­ule. It is import­ant to ensure that the full scope and working methods
are accur­ately modelled in the sched­ule. This model­ling helps to drive under­
stand­ing and accept­ance of the project sched­ule, and hence commit­ment to
deliv­ery.
Running a determ­in­istic sched­ule through a QSRA tool can derive benefit by
expos­ing weak­nesses in the original sched­ule which were not appar­ent in the
static sched­ule. The unex­pec­ted vari­ations (or lack of them) provoke discus­sions,
result­ing in both an improved under­stand­ing of the sched­ule by the project team
and a better finished sched­ule.
A QSRA will also high­light which activ­it­ies and paths are perceived by the
QSRA toolset as being key drivers. These can often differ from the paths
asso­ci­ated with the crit­ical path analysis, where more risk is asso­ci­ated with
(origin­ally perceived) sub-critical paths.

26.6.2.2 Model dura­tion uncer­tainty and risk

The two stages of running a QSRA are described in more detail below; a key
advant­age of running a QSRA is the consid­er­a­tion of these two facets of the
sched­ule and risk profile. In the case of the dura­tion uncer­tainty, this allows the
project team to express their confid­ence level in the sched­ule, which may in itself
expose certain issues.
Reviewing the risks will ensure that these are considered as part of the
sched­ule, and the implic­a­tions will be more widely under­stood as a result.

26.6.2.3 Assess the prob­ab­il­it­ies of complet­ing the project

on time
The funda­mental purpose of QSRA is to determ­ine the prob­ab­il­ity of finish­ing on
or before a given point in time. It will determ­ine the confid­ence level of complet­ing
the project to the required date. This can then facil­it­ate further stra­tegic decision
making.

285
Planning, Scheduling, Monitoring and Control

26.6.2.4 Focus atten­tion on areas requir­ing mitig­a­tion

As a result of under­tak­ing a QSRA, it may be appro­pri­ate to consider mitig­a­tions
that need to be put in place. This will partic­ul­arly be the case if the exer­cise has
iden­ti­fied altern­at­ive crit­ical path(s) to the one created during the schedul­ing of
the project.

26.6.2.5 Setting baselines

The QSRA approach may be used to estab­lish an appro­pri­ate target to be used
as a project baseline. Different organ­isa­tions may have differ­ent risk appet­ites
and estab­lish targets based on a set prob­ab­il­ity of achieve­ment. These are often
known as, for example, ‘P80’ levels, where P means prob­ab­il­ity and the number
refers to the percent­age confid­ence level (80% in this case).

26.6.3 Key require­ments for a QSRA

• A robust and fully logic­ally linked sched­ule where only genuine constraints
remain.
• If the project is in progress, the sched­ule must be updated to reflect current
status.
• Identify dura­tion uncer­tainty against all activ­it­ies (three-point estim­ate dura­tion
for activ­it­ies).
• Risks are iden­ti­fied, docu­mented and their impacts assessed and alloc­ated to
sched­ule activ­ity.
• A soft­ware applic­a­tion with which to run the Monte Carlo analysis, which
produces appro­pri­ate reports.
• Terminal float or other time contin­gen­cies should be removed from the
sched­ule prior to running the QSRA.

26.6.4 The stages of sched­ule risk analysis

26.6.4.1 Schedule quality check
The first step in running a QSRA is to confirm that the sched­ule is of the required
quality. Some of the tech­nical checks can be made by QSRA soft­ware (for
example, open ends, type of logic used). Other matters may be more subject­ive,
such as the general robust­ness of the sched­ule and the surety that all project

286
 Risk manage­ment

scope is included. Ideally, the sched­ule should be checked by an inde­pend­ent

party prior to running a QSRA.
Level of effort-type activ­it­ies should be excluded from the analysis, as they do
not repres­ent true work.

26.6.4.2 Duration uncer­tainty

A quick risk analysis can be performed by setting a narrow uncer­tainty range
across all activ­it­ies. The purpose of this is to help high­light key activ­ity drivers in
the sched­ule and to ensure that the project logic is robust.
For a full assess­ment of dura­tion uncer­tainty, the project team will need to
be consul­ted to assess ‘minimum’, maximum’ and ‘most likely’ dura­tions for
each activ­ity to feed 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 of the dura­tion calcu­la­tion when devel­op­ing the sched­ule), so it is usual
to categor­ise differ­ent types of work and apply confid­ence factors to each type
of work.
Distribution types that can be applied are discussed below.

26.6.4.3 Monte carlo analysis – first run

After apply­ing the dura­tion uncer­tain­ties, it is useful to run a ‘first pass’, as this
will assist in under­stand­ing the final results – i.e. how much of the final result is
attrib­ut­able to confid­ence in the current sched­ule, and how much due to the
assess­ment of poten­tial risk events. An under­stand­ing of this will assist in
assess­ing and prior­it­ising mitig­a­tion actions. For example, a dispro­por­tion­ally bad
result at this stage may point to the require­ment for more plan­ning to further
develop or mitig­ate the current sched­ule.

26.6.4.4 Adding the risks into the analysis

Once the risks have been iden­ti­fied and cata­logued in the risk register, those that
have a poten­tial to cause a delay are added into the sched­ule. Durations, prob­ab­
il­it­ies and distri­bu­tion types are added to each risk.
The prob­ab­il­ity is the like­li­hood of the risk event occur­ring, and is expressed
as a percent­age.
The dura­tion is the expres­sion of the likely effect in terms of time (and may be
a one point value, or a minimum/most likely/maximum range of effects).

287
Planning, Scheduling, Monitoring and Control

26.6.4.5 Monte carlo analysis – second run

This stage assesses the effect of both dura­tion uncer­tainty and the risk events.
An under­stand­ing of this will assist in assess­ing and prior­it­ising mitig­a­tion actions.
For example, an unwel­come or unex­pec­ted result at this stage may point to the
require­ment for more mitig­at­ing actions to be developed, which may include
re-working the network.
It will be neces­sary to iterate through the two processes, assess­ing mitig­a­tion
options until you have a solu­tion that best meets the needs of the project/
programme.

26.6.5 Distribution types

The distri­bu­tion type is an expres­sion of the distri­bu­tion pattern and may include
the follow­ing.

26.6.5.1 Normal or bell curve distri­bu­tion

Symmetrical: values in the middle are most likely to occur (Figure 26.9).
Describes many distri­bu­tions, 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
trian­gu­lar distri­bu­tion.
• Use when there is moder­ate confid­ence in three-point estim­ates.

Figure 26.9 Normal distri­bu­tion curve

288
 Risk manage­ment

26.6.5.2 Log normal distri­bu­tion

Values are posit­ively skewed (Figure 26.10).

• Values are posit­ively skewed, not symmet­rical like a normal distri­bu­tion.

• Used to repres­ent values that do not go below zero but have great posit­ive
poten­tial.

Figure 26.10 Log normal distri­bu­tion curve

26.6.5.3 Uniform distri­bu­tion

All values have an equal chance of occur­ring (Figure 26.11).

• Useful for estim­ates that do not appear to show any central tend­ency.
• Equally likely chance of occur­ring anywhere within a partic­u­lar range.
• No ‘most likely’ value.

Figure 26.11 Uniform distri­bu­tion

289
Planning, Scheduling, Monitoring and Control

26.6.5.4 Triangular distri­bu­tion

User sets minimum, most likely and maximum (Figure 26.12).

• Used extens­ively in risk models.

• Allows skewed estim­ates to be modelled.
• Use when:
• there is low to moder­ate confid­ence in three-point estim­ates
• risk is high or unknown
• global three-point estim­ates are applied.

Figure 26.12 Triangular distri­bu­tion – possible options

26.6.5.5 PERT distri­bu­tion

Like trian­gu­lar, but minimum/maximum are more likely to occur (Figure 26.13).

290
 Risk manage­ment

Figure 26.13 PERT distri­bu­tion

• Values near the mean are more likely to occur than in the trian­gu­lar or normal
distri­bu­tions.
• Extremes are not as emphas­ised.
• Use when there is high confid­ence in three-point estim­ates.

26.6.5.6 Discrete distri­bu­tion

Specific values and like­li­hoods are specified, e.g. ‘There is a 10% chance of
occur­rence and there will be an effect of 10 days.’
When under­tak­ing a risk analysis, it is import­ant to under­stand these
distri­bu­tion types and the effect they will have on results.

26.6.6 Application of risks to sched­ule activ­it­ies

It is import­ant to consider what effect apply­ing risks to activ­it­ies will have.
A Monte Carlo analysis works by turning the risks on and off at random based
on their prob­ab­il­ity of occur­rence. Each time the risk is ‘on’, an impact will be
applied the activ­ity(ies) that it is linked to. The effect of the risk will vary in line
with the prob­ab­il­ity distri­bu­tions described above.
A risk linked to many activ­it­ies will, when it is ‘on’, affect all the activ­it­ies that
it is linked to. If the risk was, for example, lack of 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 of resources affect­ing just one, or some, of the
activ­it­ies.

291
Planning, Scheduling, Monitoring and Control

26.6.7 QSRA output

26.6.7.1 First analysis: dura­tion uncer­tainty
As previ­ously discussed, the first analysis under­taken applies the dura­tion uncer­
tainty calcu­la­tions. The graph­ics and stat­ist­ics in Figure 26.14 detail the outcome
of this on a specific mile­stone which defines the end date of this section of work.
The results of this analysis can be shown in a prob­ab­il­ity chart. Charts can be
viewed for the overall project or at a number of key mile­stones or at other points
through­out the project.
Different ‘risk appet­ites’ are also (or more) depend­ent on the type of work;
e.g. posses­sions or shut-downs would commonly want P90, stand­ard construc­tion
work P80 for sched­ule risk and uncer­tainty. However, cost risk might well be P50,
which would never be accept­able for the sched­ule.
Different organ­isa­tions will have differ­ent risk appet­ites and choose differ­ent
percent­age points (P) to measure against, but the illus­tra­tion in Figure 26.14 uses
the P50 and P80 bound­ar­ies. P50 means a 50% chance of success; P80 means
there is an 80% chance of success. In the illus­tra­tion, the required comple­tion
date is 10/02/11; the results show that:

• There is a prob­ab­il­ity of achiev­ing the current sched­ule date of 28% (yellow

line).
• The P50 date is shown as 14/02/11 (orange line).
• In addi­tion the P80 date is also shown as 14/02/11 (green line).

The activ­it­ies that have the most influ­ence on this outcome can be displayed in a
tornado chart, as illus­trated in Figure 26.15.
It is worth analys­ing the tornado chart prior to proceed­ing with the exer­cise to
ensure that the results are mean­ing­ful and cred­ible activ­it­ies are iden­ti­fied as
having the greatest influ­ence on the result. The example in Figure 26.15 shows
the impact in days, but some­times this is shown in percent­age terms.

292
 Risk manage­ment

Figure 26.14 Duration uncer­tainty prob­ab­il­ity chart

293
Planning, Scheduling, Monitoring and Control

Figure 26.15 Duration uncer­tainty tornado chart

26.6.7.2 Second analysis: dura­tion uncer­tainty and risk

After adding in the risks the analysis is re-run (based on these risks and the
dura­tion uncer­tainty as before), and new output is produced (Figure 26.16).
As with the activ­it­ies that have the most influ­ence on this outcome, as seen in
Figure 26.16, the risks can also be displayed in a tornado chart, as illus­trated in
Figure 26.17.
Again, it is worth assess­ing the cred­ib­il­ity of these results prior to produ­cing
and publish­ing a QSRA report.

294
 Risk manage­ment

Figure 26.16 QSRA prob­ab­il­ity distri­bu­tion chart

295
Planning, Scheduling, Monitoring and Control

Figure 26.17 Full QSRA tornado chart

26.6.8 Reporting
A sugges­ted report format would include:

• comment­ary on the scope of the QSRA;

• notes on the method adopted so that the process and inputs are made
clear;
• list of parti­cipants and their involve­ment;
• the results in graph­ical form and with written inter­pret­a­tion;
• recom­men­ded actions that should mitig­ate any concerns raised in order to
deliver the most effect­ive project possible;
• appen­dices of dura­tion uncer­tain­ties and the risk register, considered with
details of the risk model­ling (i.e. which risks alloc­ated to which activ­ity(ies);
distri­bu­tion type; minimum, maximum and most likely values).

296
 Risk manage­ment

26.7 Quantitative cost risk analysis (QCRA)

26.7.1 Definition of QCRA
Quantitative cost risk analysis (QCRA) is often referred to as Monte Carlo simu­
la­tion. (Monte Carlo is the calcu­la­tion tech­nique used, not the product.) It is a
tech­nique used to under­stand and quantify the impact of risk and uncer­tainty in
cost fore­cast­ing models.

26.7.2 Purpose of QCRA

QCRA enables the project to calcu­late the size of its contin­gency, thereby
increas­ing the accur­acy of the cost aspect of the project. It can be used on an
ongoing basis to review fore­cast risk spend against the original budget.
Organisations that consider invest­ing in a new infra­struc­ture or change, in its
broad­est meaning, need to eval­ua­ te the cost risk involved; once the quant­it­at­ive
assess­ment has been completed, the funda­mental decision of who will take the
risk must be made (The organ­isa­tion itself? The suppli­ers involved?). This
decision will result in differ­ent contrac­tual arrange­ments.
Organisations that consider bidding for a job need to carry out a QCRA which
will lead to the ‘bid/no-bid’ decision first. Subsequently, should the bid be
success­ful, the contract­ors need to manage the cost risk in a manner that is
related to the magnitude of the risk iden­ti­fied.
It is also useful to quantify risk to enhance ‘spend to save’ decision making and
to show the risk retire­ment fore­cast to enable the programme to poten­tially
re-distribute the alloc­ated budget to other projects.

26.7.3 The QCRA process

26.7.3.1 Risk analysis
As previ­ously discussed, risks are iden­ti­fied and assessed. For the QCRA, each
risk is assigned a like­li­hood and a three-point estim­ate (minimum cost, most likely
cost and maximum cost) should it occur.
This latter may be based on a trian­gu­lar distri­bu­tion, but there are other
distri­bu­tion methods which could be considered, such as single point (most likely
cost) or a uniform distri­bu­tion (minimum and maximum). These are discussed in
the section above on QSRA.

297
Planning, Scheduling, Monitoring and Control

For the Monte Carlo simu­la­tion, a random value is selec­ted for each risk,
based on the range of these cost estim­ates. The result of this is recor­ded, and
typic­ally the model is run 5,000 times, each time using differ­ent randomly selec­ted
values. If the risk has a 50% like­li­hood, then the model would run half the iter­a­tions
as a zero cost out-turn, as it assumes that the risk is not occur­ring. The remain­ing
half of the model would pick random values depend­ent upon the three-point
estim­ates.
Just as in the case of the QSRA, the results are plotted and confid­ence levels
for various outcomes are calcu­lated. These are often referred to as P values, e.g.
P50 or P80.
This means that, for example, if the P50 is calcu­lated at £5 million, there is only
a 50% chance that the project will cost a total of £5 million or less. The more risk
averse the organ­isa­tion is, the higher the confid­ence value they may use.
Therefore, they may use a P80, which means that there is an 80% chance that the
project risk will cost a total of (say) £7 million or less.

26.7.3.2 Risk report­ing

The above inform­a­tion enables an organ­isa­tion to define risk budgets for projects
based on a range of possible out-turns. Regular review of the risks during the
project life cycle means the model can be re-run at regular inter­vals. This provides
manage­ment inform­a­tion that the risk profile is remain­ing within an accept­able
level. The inform­a­tion is typic­ally collated on a pre-mitigation (current) state
and a post-mitigation state. The project team can then manage the risks using
mitig­a­tions.
Some typical outputs for quant­it­at­ive analysis include:

• cumu­lated normal distri­bu­tions (S-curves) for cost impacts;

• sens­it­iv­ity (tornado) charts showing how much each risk influ­ences the
outcome;
• QRA percent­iles (percent­age rates) value for cost.

26.7.3.2.1 Cumulative normal distri­bu­tions

The chart of the cumu­lated normal distri­bu­tion (S-curve) provides an easy way to
assess the level of confid­ence about the model outcomes. The left-hand axis of
the chart (cumu­lat­ive prob­ab­il­ity) is a value between 0 and 1, but can be thought

298
 Risk manage­ment

of as a percent­age of the number of times the model ran – 0 is without running

the model, 1 is when 5,000 iter­a­tions of the model have been run.
Tracing a line to inter­sect the curve and then refer­ring to the bottom axis of the
chart (cost or time impact values) will indic­ate the value which, with the given
level of prob­ab­il­ity, the model ran at or below.
For example, the 0.5 level of cumu­lat­ive prob­ab­il­ity, traced to the curve and
trans­lated to the impact axis, will show the value that was not exceeded during
half 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 affects the result, with the overall
sens­it­iv­ity of a fore­cast being the combin­a­tion of two factors:

• the model sens­it­iv­ity of the fore­cast to the risk;

• the uncer­tainty of the risk.

The format of the sens­it­iv­ity data presen­ted here is termed the ‘contri­bu­tion to
vari­ance’, and makes it easier to examine what percent­age of the vari­ance in the
target fore­cast is due to a partic­u­lar risk.

299
Planning, Scheduling, Monitoring and Control

Figure 26.19 QCRA chart

26.7.3.2.3 Cost impact sens­it­iv­ity (tornado charts)

The sens­it­iv­ity chart shown in Figure 26.19 illus­trates the risks having the greatest
influ­ence on the outcome of the analysis – the risks that change the outcome of
the analysis most.
Managing these risks will have the most influ­ence on redu­cing the fore­cast
risk costs.
(Risk – O) relate to risks that influ­ence the model due to their prob­ab­il­ity
values.
(Risk – I) relate to risks that influ­ence the model due to their cost values.

300
 Risk manage­ment

Example:
Risks with an ‘O’ key on the graph indic­ate that those partic­u­lar risks appear on
the sens­it­iv­ity chart mainly due to their high prob­ab­il­ity, e.g. prob­ab­il­ity of 75%.
Risks with an ‘I’ key on the graph indic­ate that those partic­u­lar risks appear on
the sens­it­iv­ity chart mainly due to their high value, e.g. £10 million, should they
occur, even if they may have a low prob­ab­il­ity of occur­rence, e.g. 5% like­li­hood.

26.7.3.2.4 QRA percent­iles summary table for cost

Table 26.1 illus­trates an example of Pn confid­ence levels.

Table 26.1 QCRA confid­ence 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 fore­cast­ing model, the analysis is only as good as the estim­ates made. It
is import­ant to remem­ber that it is a simu­la­tion, and basing the estim­ates on
current assump­tions will provide greater confid­ence in the results.

301
27.1 Definition of forensic analysis
Forensic sched­ule analysis refers to the study and invest­ig­a­tion of events using
crit­ical path methods or other recog­nised sched­ule calcu­la­tion methods. In
partic­u­lar, it is the study of how actual events caused delay as meas­ured against a
defined time model.

27.2 Purpose of forensic analysis

The most usual reason for conduct­ing forensic analysis is for the purpose of
build­ing, justi­fy­ing or rebut­ting a contrac­tual claim for addi­tional monies. Indeed,
given that it is likely to be an expens­ive under­tak­ing, it is hard to imagine it being
used for other purposes. Given that such analyses may be used in legal proceed­
ings demon­strat­ing delay and disrup­tion, it is essen­tial that exper­i­enced guid­ance
is sought when under­tak­ing such exer­cises.

27.3 Methods of forensic analysis

By implic­a­tion, forensic analysis is carried out after the event. However, some
contracts provide for the analysis of sched­ules to be carried out on a prospect­ive
basis. Events are considered at the time they occur and consequent delays are
fore­cast, for example in the NEC suite of contracts.
A compre­hens­ive under­stand­ing of the detailed steps to be under­taken to
ensure these methods are imple­men­ted appro­pri­ately is required before using

303
Planning, Scheduling, Monitoring and Control

these tech­niques. An over­view of some of the more common methods of 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 for (ABBF);
• time impact analysis method (TIA).

In addi­tion, there follows a discus­sion on the windows analysis approach to

invest­ig­at­ing the effect of 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
descrip­tion used?

The as-planned v • Good •R  elatively • Can only be carried • W  hen as-built

as-built method as-planned simple to out retro­spect­ively. data is
compares the sched­ule (ideally under­stand and • Likely to be overly avail­able.
as-planned agreed or present. simplistic and not •S
 uitable for
sched­ule or accep­ted at or •R  elatively cheap demon­strate cause simple
baseline at the near the outset to carry out. and effect situ­ations,
outset of a project of the project). •C  an be appro­pri­ately. projects and
with the as-built •G
 ood as-built appro­pri­ate for • Not suited to cases or where
sched­ule at the data so as to be simple complex projects matters only
end of the project able to estab­lish situ­ations. with multiple crit­ical need to be
(or the latest an as-built • Although the paths. shown at a
sched­ule updated compar­ison with sched­ule would • Not suited to higher level.
with progress). the as-planned normally be a projects that have •B
 etter suited to
This allows the sched­ule. crit­ical path devi­ated from the projects of a
differ­ences •T
 he works network, this is original as-planned shorter
between the two carried out need not neces­sar­ily logic. dura­tion.
sched­ules to be to closely reflect essen­tial. • Does not adequately
observed. the logic Therefore, deal with concur­
contained within plan­ning rency, consequen­tial
the as-planned soft­ware is not delay, mitig­a­tion or
sched­ule. an abso­lute accel­er­a­tion.
require­ment in
some cases.

(Continued)

304
 Forensic analysis and delay and disrup­tion analysis

Table 27.1 Continued

Method Requirements Advantages Disadvantages Where can it be
descrip­tion used?

The as-planned v • Delay events •D  oes not neces­sar­ily • W

 here there is
as-built need to be recog­nise the order a single clearly
compar­ison can clearly in which delays defined chain or
be shown either iden­ti­fied. impacted a project. sequence of
activ­ity by activ­ity • The crit­ic­al­ity of •D  oes not deal with activ­it­ies that
or sched­ule by delay events the crit­ical path were crit­ical to
sched­ule. The does not need to chan­ging as a the timely
overall delay is be demon­strated project progresses. comple­tion of a
meas­ured by the if the liab­il­ity for •G  enerally assumes project
differ­ence all the events is all delay is due to through­out.
between the clear and rests one party.
comple­tion dates with one party. •A  s the analysis
in the two • I f there are progresses through
sched­ules. This issues with the as-planned
delay is attrib­uted liab­il­ity then the sched­ule, its
to the delay crit­ic­al­ity of the accur­acy is likely to
events that have affected dimin­ish.
occurred. activ­it­ies must • It is unre­li­able by
be clear. itself in dispute
resol­u­tion.

27.3.2 Impacted as-planned method (IAP)

Table 27.2 Impacted as-planned method
Method Requirements Advantages Disadvantages Where can it
descrip­tion be used?

The impacted •G  ood •C

 an be used •M  ay only show limited •C
 an be used
as-planned as-planned where the cause and effect. prospect­ively
method sched­ule as-planned •D  oes not take account or
works by (ideally agreed sched­ule has of progress, resources retro­spect­ively
insert­ing and or accep­ted at not been and changes in but . . .
linking delay or near the updated or sequence. •M
 ore suited
events into outset of the where there is • I t is a theor­et­ical for identi­fy­ing
the project). limited as-built method and there­fore and
as-planned • The works data avail­able. open to criti­cism. quan­ti­fy­ing
sched­ule. carried out •C
 an be used • Susceptible to poten­tial
Any change need to closely prospect­ively manip­u­la­tion delays rather
in the reflect the logic or (unin­ten­ded or than actual
comple­tion contained retro­spect­ively. other­wise) if only one delays.
date as a within the party’s delays are
consequence as-planned considered.
of the sched­ule.
(Continued)
305
Planning, Scheduling, Monitoring and Control

Table 27.2 Continued

Method Requirements Advantages Disadvantages Where can it
descrip­tion be used?

inser­tion of •T  he as-planned • Relatively • May ignore •M

 ight be
the delay is sched­ule needs simple to concur­rency. appro­pri­ate
attrib­uted to to be under­stand and • Sensitive to the order for illus­trat­ing
the delay networked. present. in which delays are delays at high
event. An •A  ll delay­ing • Relatively impacted upon the level or for
analysis can events should cheap to carry sched­ule. nego­ti­at­ing
be carried be iden­ti­fied out. • Less reli­able in dispute purposes.
out on a and quan­ti­fied. • Where as-built resol­u­tion than other
step-by-step • If analysis is data is more compre­hens­ive
basis, carried out avail­able, it can methods.
insert­ing retro­spect­ively, be used to • Relies heavily on the
delay events the results verify the as-planned sched­ule
as they arise. should be results. being robust.
veri­fied by •T  ribunals gener­ally
as-built data if favour factual methods
avail­able. of delay analysis.

27.3.3 Collapsed as-built method or as-built but for (CAB)

Table 27.3 Collapsed as-built method or as-built but for
Method Requirements Advantages Disadvantages Where can
descrip­tion it be used?

The collapsed •G
 ood quality, • Does not • Limited prospect­ive •W
 here there
as-built reli­able and require an use. is no
method begins consist­ent as-planned • The network­ing of the as-planned
with the as-built data sched­ule. as-built sched­ule sched­ule or it
produc­tion of produced in • Based on requires a deep is of poor
a networked suffi­cient factual as-built under­stand­ing of the quality.
as-built detail. data. sched­ule and its logic •M
 ost
sched­ule. •R
 equires a • Can and normally requires appro­pri­ate
Then activ­it­ies networked or demon­strate access to the project for
or parts of logic-linked cause and team. retro­spect­ive
activ­it­ies as-built effect. • Expertise required to delay
repres­ent­ing sched­ule. • Can account for collapse out delays analysis.
delay events concur­rency. accur­ately, other­wise
are removed. the collapsed sched­ule
may not repres­ent the
true situ­ation but for
the delays.
(Continued)

306
 Forensic analysis and delay and disrup­tion analysis

Table 27.3 Continued

Method Requirements Advantages Disadvantages Where can
descrip­tion it be used?

The change in • Detailed • Relatively easy • Delays to be collapsed • F or

the comple­tion under­stand­ing to under­stand in out still require nego­ti­at­ing
date as a of the logic prin­ciple and know­ledge about how purposes or
consequence and delay explain. long work should have in tribunals.
of the removal events that • More reli­able in taken, and can be
of the delay is often requires dispute subject­ive.
the overall either resol­u­tion than • In prac­tice, can require
delay that is first-hand some simpler several iter­a­tions.
attrib­uted to know­ledge or methods of •C  an be perceived as a
the delay access to delay analysis. recon­struc­tion of the
event. Delay people with •C an be carried facts without due
events can be first-hand out prospect­ consid­er­a­tion of the
removed on a know­ledge. ively or updated as-planned
step-by-step • All delay­ing retro­spect­ively, sched­ules.
basis, usually events should but limited • Does not account for
start­ing with be iden­ti­fied prospect­ive use. accel­er­a­tion meas­ures,
the latest delay and as these will be impli­cit
event first. quan­ti­fied. within the as-built
sched­ule.

27.3.4 Time impact analysis method (TIA)

Table 27.4 Time impact analysis method
Method Requirements Advantages Disadvantages Where can it
descrip­tion be used?

The time impact •G

 ood as-planned • Can be carried • More suited to •P rospectively
analysis method sched­ule (ideally out quan­ti­fy­ing or
provides for the agreed or accep­ted prospect­ively or poten­tial rather retro­spect­ively.
updat­ing of a at or near the outset retro­spect­ively. than actual delays. • B eneficial to
networked of the project). • Deals with delays • Requires extens­ive carry out as a
as-planned •T
 he as-planned at the time they records to be kept. project
sched­ule with sched­ule and its occur or in • Can be time progresses.
progress to just updates are windows intens­ive and slow, • W
 here the
before the networked. provid­ing clarity. and there­fore contract
occur­rence of a expens­ive to requires.
delay event. imple­ment.

(Continued)

307
Planning, Scheduling, Monitoring and Control

Table 27.4 Continued

Method Requirements Advantages Disadvantages Where can it
descrip­tion be used?

The delay event •R

 eliable and • Can account for • Can be complic­ated • F or
is then inser­ted consist­ent progress progress, and diffi­cult to nego­ti­at­ing
and linked into data in suffi­cient resources, commu­nic­ate, with purposes or in
the sched­ule. detail for each time changes in many charts. tribunals.
Any change in period being sequence and • Reliability reduced
the comple­tion considered, which changes in the if sched­ule and
date as a should also be at crit­ical path. record quality is
consequence of appro­pri­ate • Can identify and poor.
the inser­tion of inter­vals. quantify • Can produce
the delay event •A
 ll delay­ing events accel­er­a­tion or theor­et­ical results if
is attrib­uted to should be iden­ti­fied mitig­a­tion not veri­fied by
that delay and quan­ti­fied. meas­ures. as-built data, but if
event. •T
 he works carried •C  an disen­tangle carried out
Where out need to closely delays other­wise regu­larly takes
progress is not reflect the logic considered to be account of as-built
recor­ded at the contained within concur­rent. data.
specific date the latest •C  an demon­strate • Susceptible to
just before the as-planned cause and effect. manip­u­la­tion
impact of a sched­ule being •M  ore reli­able in (unin­ten­ded or
delay event, the considered. dispute other­wise) if only
latest sched­ule resol­ut­ ion than one party’s delays
updated for simpler methods are considered.
progress prior of delay analysis. •A  ccuracy can be
to occur­rence • Recommended reduced if the
of the delay method of delay period between
event may still analysis by the progress update
be appro­pri­ate Society of and delay
to use. Each Construction increases.
progress Law’s Protocol. •S  ensitive to the
update may • Does not require order in which
allow the a complete delays are
sched­ule to be as-built sched­ule, impacted upon the
analysed at but as-built data sched­ule.
discrete assists in
inter­vals of time veri­fy­ing results.
or in ‘windows’.

308
 Forensic analysis and delay and disrup­tion analysis

27.3.5 Windows analysis

At its highest level, the windows analysis method compares the as-planned
sched­ule with the as-built sched­ule during a partic­u­lar period or time ‘window’.
The as-planned sched­ule at the start of the window is the sched­ule updated with
progress at this point. Likewise, the as-built sched­ule at the end of the window is
the sched­ule updated with progress at this point. The differ­ence between the
comple­tion dates at the start and the end of the window is the overall delay that
is attrib­uted to the crit­ical delays that occurred within the window being
considered.
This method of delay analysis can be used to review delays by compar­ison in
a similar way to the as-planned versus as-built method, but in smaller time
windows; or by extract­ing out delays in a similar way to the collapsed as-built
method; or for veri­fy­ing the impacted delays as reas­on­able from the time impact
analysis method by compar­ison with the as-built data.

27.3.6 Other consid­er­a­tions

27.3.6.1 Conditions of contract
The choice of method of delay analysis involves consid­er­ing various factors,
includ­ing the relev­ant condi­tions of contract dictat­ing how delay events should
be assessed. It is also quite common that the quality and quant­ity of sched­ules
and records will dictate the choice of method of delay analysis. Additionally,
other consid­er­a­tions that need to be accoun­ted for are the values asso­ci­ated with
any delay event or events and the time avail­able to carry out any analysis.

27.3.6.2 Delay analysis in the courts

Theoretical calcu­la­tions of delay have been found not to carry favour with the
courts, and methods of delay analysis that rely on as-built data have proved more
reli­able in dispute resol­u­tion. However, methods of delay analysis should be
considered against a back­ground of their inten­ded use. For example, the simpler
methods of delay analysis might be appro­pri­ate for illus­trat­ing delays at high level
or for nego­ti­at­ing purposes, whereas the more complex methods might be more
appro­pri­ate for use in formal tribunals where the evid­ence is subject to more
scru­tiny.

309
Planning, Scheduling, Monitoring and Control

27.3.6.3 Considering float in delay analysis

Float is the period of time by which an activ­ity can slip without affect­ing other
activ­it­ies or the project comple­tion date. In partic­u­lar, free float is the period of
time by which an activ­ity can slip without affect­ing any other tasks or the
comple­tion of the project, whereas total float is the period of time by which an
activ­ity can slip without affect­ing the comple­tion of the project.
Terminal float is normally the period between the planned comple­tion date
and the date for comple­tion as stated in the contract. Who owns the float within
the sched­ule can depend upon such factors as the type of float being considered
and the provi­sions for float within the contract. In addi­tion, in order to demon­strate
a delay, it can be seen that the float attached to an activ­ity will have to be used
before there is an effect on a follow­ing activ­ity. This may mean that, when there
is a delay to an activ­ity, any float in the sched­ule is avail­able to whichever party
uses it first.

27.3.6.4 Concurrency
Concurrency occurs when there is a delay caused by two or more events that are
of approx­im­ately equal potency. Although concur­rency is often claimed to exist,
it is actu­ally quite rare, and delay analysis can disen­tangle the caus­at­ive delays
and show that one cause of delay was acting before the other or that one cause
of delay was far more potent than the other. Where there is true concur­rency,
with the customer respons­ible for one of the delays and the contractor respons­
ible for the other, there has been judi­cial guid­ance from the English courts that
the contractor receives an exten­sion of time but does not neces­sar­ily receive
asso­ci­ated prolong­a­tion costs unless they can be separ­ated out.

310
 Part Five

Record keeping
and learn­ing

‘A learn­ing exper­i­ence is one of those things that say, “You know that thing you
just did? Don’t do that.”’
Douglas Adams
28.1 Definition of record keeping
Records are the phys­ical and digital data that are required to accur­ately docu­ment
the life of the project. Record keeping is a formal and discip­lined process for
captur­ing this inform­a­tion.

28.2 Purpose of record keeping

The purpose of record keeping is to provide, and preserve, a compre­hens­ive
history of what happened, when and where. In the context of plan­ning, it is the
basis of updat­ing the sched­ule and of forensic plan­ning, and provides inform­a­
tion that will be useful in plan­ning future projects (productiv­ity data).

28.3 How to record

It is import­ant to define at the outset what records are neces­sary and required to
be kept. Since it is not possible to know in advance what records will be required,
it is import­ant to set up appro­pri­ate processes and tools to enable the capture of
all relev­ant inform­a­tion.
Record keeping should be under­taken on a regular basis appro­pri­ate to the
data being collec­ted. This could be required daily (e.g. weather records), weekly
(e.g. timesheets) or monthly (e.g. progress reports, safety stat­ist­ics).
Effective record keeping is that which is clearly stated and under­stood, and
is access­ible in the future. Records should be kept in an appro­pri­ate elec­tronic

313
Planning, Scheduling, Monitoring and Control

format. Records should be checked where appro­pri­ate and author­ised where

required (e.g. timesheets). Effective record keeping ensures that this is carried
out on a regular basis, and ensures their authen­ti­city.

28.4 What to record

• Actual start and actual finish dates of every activ­ity in the sched­ule. This will
even­tu­ally build the as-built sched­ule. It is appro­pri­ate to collect this inform­a­
tion either daily or weekly, as any longer dura­tion will prob­ably lead to inac­cur­
acy. Thus, this is not neces­sar­ily related to the progress report­ing frequency,
which may be further apart.
• Percent complete of each activ­ity at the point of meas­ure­ment.
• Remaining dura­tion of each activ­ity at ‘time now’. This should be manu­ally
entered rather than allow­ing the schedul­ing soft­ware to auto­mat­ic­ally
re-calculate.
• Time issues: it is useful to have the as-built sched­ule annot­ated with relev­ant
details relat­ing to progress and issues encountered. It is partic­u­larly import­ant
to build up a picture of time escal­a­tion reasons, to inform future contin­gency
allow­ances.
• Cost issues: it is useful to main­tain a log of relev­ant cost issues encountered.
This will inform future contin­gency allow­ances.
• Any changes in the change log should be reflec­ted in the sched­ule and
clearly iden­ti­fied.
• If not captured in the project sched­ule, then the status of inform­a­tion (design,
tech­nical and other ques­tions) needs to be retained in the records.
• Timesheets or labour returns that record who worked on what, when.
• Material records: a record of the source and final loca­tion of all mater­i­als used
in the project.
• Plant records that confirm plant util­isa­tion and outputs.
• Lessons learned: there is a tend­ency only to record lessons after a project has
closed, but processes should be in place to allow collec­tion of learn­ing on a
continual basis.
• Relevant envir­on­mental factors that may affect costs or time (e.g. weather in
construc­tion).
• Health and safety records.
• Photographic records.

314
 Record keeping

• Delivery records.
• Quality control records.

28.5 Methods of keeping records

• Data­bases.
• Site diaries.
• Minuted sub-contractor meet­ings.
• As-built sched­ules.

315
29.1 Definition of docu­ment manage­ment
Document manage­ment is the collec­tion, storage, dissem­in­a­tion and archiv­ing of
docu­ment­a­tion in a struc­tured manner. It is a funda­mental aspect of project
deliv­ery, partic­u­larly in support­ing assur­ance processes and the handover of a
project at comple­tion.
Document manage­ment also encom­passes the process of ‘docu­ment control’,
which involves main­tain­ing records of docu­ment versions and an audit trail of
docu­ments exchanged with suppli­ers or other stake­hold­ers. A docu­ment control
process should control and be able to trace the flow of all inform­a­tion on the project.
The term ‘docu­ment’ applies to any format­ted inform­a­tion that passes the test
‘Is it in the interest of the sched­ule or project that this inform­a­tion be safe­
guarded?’.
An aware­ness of current legis­la­tion and corpor­ate require­ments is import­ant,
as some project docu­ment­a­tion, e.g. contracts, may be required to be stored for
a signi­fic­ant amount of time after the project has finished. Equally, some may be
required to be stored in a partic­u­lar manner – for example in a hard copy only, or
in a soft copy only.

29.2 Purpose of docu­ment manage­ment

Document manage­ment ensures that:

• all relev­ant parties have all the inform­a­tion they require to complete their
respons­ib­il­it­ies;

317
Planning, Scheduling, Monitoring and Control

• all the inform­a­tion used in the project is up to date (i.e. latest revised inform­a­
tion is in use);
• out-of-date inform­a­tion is no longer access­ible for imple­ment­a­tion purposes,
but . . .
• all data is avail­able for record purposes.

29.3 Document control systems

The chosen docu­ment control system must be access­ible, secure and struc­tured
in a logical way that makes project inform­a­tion easily retriev­able. This may also
include metadata to be attrib­uted to specific docu­ments, i.e. docu­ment type,
contract refer­ence, supplier name, etc. (See also BIM in Chapter 19.)
Thought should be given to levels of sens­it­iv­ity around partic­ul­ar docu­ments,
and user access rights aligned accord­ingly.

29.4 Version control

Version control is a funda­mental part of docu­ment control, as it assures that all
parties are working to the correct inform­a­tion at the correct time.
Project teams should:

• ensure that all docu­ment changes are recor­ded and docu­ments marked appro­
pri­ately so it is clear that a revi­sion has taken place;
• ensure all project team members use the correct version of each docu­ment;
• main­tain a tracker, e.g. an appro­pri­ate data­base tool, that shows the status and
revi­sion numbers of each drawing and assur­ance docu­ment, if required by the
project team.

29.5 Handover of docu­ment­a­tion

At an early stage, the project team should obtain detailed agree­ment, usually
from the sponsor or asset main­tainer, as to what docu­ments need to be provided,
in what format and when.

318
Project handover and clos­eout are separ­ate processes but are often very closely
related in time. Closeout cannot occur until the handover process is complete.
Both processes are vital to the success of the project and often use finite
resources. The handover process is very likely a part of the crit­ical path of the
project, whilst the clos­eout process is essen­tial to the final­isa­tion of commer­cial
accounts, resol­u­tion of defects/snag­ging and trans­fer of the risk process. It will
also include the final part of the lessons learned process, which is discussed in
Chapter 31. Figure 30.1 outlines the context of handover and clos­eout.

30.1 Handover
30.1.1 Definition of handover
The handover of a project occurs when the final project deliv­er­ables are handed
over from the organ­isa­tion deliv­er­ing the project to the user or oper­ator of the
asset.
There are many parts to this process, includ­ing scope, train­ing and docu­ment­
a­tion, all of which need to be care­fully planned and resourced.

30.1.2 Purpose of the handover process

A project does not simply end when the works have progressed to 100%. The
project has to be success­fully handed over to the customer or client. To allow
this, appro­pri­ate time must be alloc­ated in the sched­ule, and appro­pri­ate capa­city
must exist to effect handover and certi­fic­a­tion: an example of that capa­city being

319
Planning, Scheduling, Monitoring and Control

Figure 30.1 Context of handover and clos­eout

that there are suffi­cient people avail­able, with the right skills to deliver the
handover process.
The handover process ensures that:

• the project scope has been completed;

• all docu­ment­a­tion has been completed;
• all accept­ance criteria have been met, and signed off by all parties
concerned;
• end-users have been trained or provided with train­ing manuals as appro­pri­ate;
• the project (or product) has been brought into use – for example, a build­ing
can be occu­pied, a piece of soft­ware deployed.

30.1.3 Planning handover

The handover stage is a crit­ical stage in the project life cycle, as an effect­ive
trans­ition to the client’s busi­ness envir­on­ment will ensure that the client starts to
realise the bene­fits of the project.
During the defin­i­tion stage of the project life cycle, the project manager will
need to alloc­ate time and resource in the project sched­ule to ensure that the
project team has suffi­cient time to effect­ively hand over the project deliv­er­ables
to the client.

320
 Handover and clos­eout

The nature of the project deliv­er­ables will determ­ine how much time and
resource is alloc­ated to handing them over. The deliv­er­able examples below will
require differ­ent resources:

• deliv­ery and install­a­tion of a new piece of equip­ment to the client;

• project deliv­er­able/report;
• handing over a process.

The plan for the handover process should also include:

• accept­ance of all relev­ant docu­ment­a­tion (contain­ing all specified inform­a­tion

useful to the end-user, includ­ing guar­an­tees, warranties, instruc­tion or oper­a­tion
manuals);
• accept­ance certi­fic­ate(s) signed by the sponsor or deleg­ated author­ity to
confirm accept­ance;
• trans­fer of respons­ib­il­ity for the project assets to the sponsor or users;
• formal trans­fer of owner­ship.

30.1.4 Issues in the manage­ment of handover

The handover process may vary consid­er­ably for differ­ent types of project, but,
to avoid issues, the follow­ing prin­ciples should be adopted:

• all the project deliv­er­ables have been clearly defined and agreed in terms of
docu­ment­a­tion required to accom­pany the phys­ical (or virtual) product of the
project, train­ing require­ments and the like;
• the handover process has been clearly defined and agreed;
• the process for dealing with non-conformances or outstand­ing issues has
been agreed;
• the handover process conforms to organ­isa­tion guidelines;
• all relev­ant customer check­lists have been used;
• all the signi­fic­ant stake­hold­ers are appro­pri­ately repres­en­ted at the handover
event.

Poor handover can result in:

• payment delays;
• increased client reten­tions;

321
Planning, Scheduling, Monitoring and Control

• loss of or reduced profit;

• increased over­head costs (exten­ded insur­ance, finan­cing etc.);
• exten­ded resource needs;
• exten­ded warranty require­ments;
• delays in equip­ment avail­ab­il­ity;
• delays in service to the final client;
• inef­fi­cient resource util­isa­tion as work-around solu­tions are found;
• worsened client/customer rela­tion­ship;
• poten­tial penalty costs;
• reduced chance of future work.

30.2 Project closeout

30.2.1 Definition of project closeout
Project clos­eout is the finan­cial closure of the project, includ­ing final settle­ment
of project accounts and agree­ment of reten­tions and warranty periods.

30.2.2 Purpose of project closeout

Project clos­eout is the part of the project that must resolve the follow­ing:

• commer­cial settle­ment with the supply chain and all other parties;
• recti­fic­a­tion of all defects noted at or since the comple­tion of the handover
process;
• payment of all retained monies result­ing from the above.

It is also best prac­tice to ensure that a project review takes place before the
project team is disban­ded, to ensure that appro­pri­ate lessons are learned from
the things that went well or other­wise in the project. This is covered in the next
chapter of this guide.

30.2.3 The project clos­eout process

The project clos­eout process should include:

• demo­bil­isa­tion of the project team, facil­it­ies and equip­ment;

• trans­fer, archive or disposal of relev­ant sens­it­ive project mater­ial or assets;

322
 Handover and clos­eout

• handover to a support organ­isa­tion (if required);

• close­down of the project on the account­ing and manage­ment systems.

These processes should be defined in the organ­isa­tion proced­ures. Planning the

clos­eout involves tail­or­ing these proced­ures for this specific project. Provisional
plan­ning for clos­eout should be done early in the project life cycle. The clos­eout
process should be controlled by main­tain­ing appro­pri­ate track­ers, for example of
the various steps required to achieve commer­cial clos­eout with each supplier.

323
31.1 Definition of lessons learned
The lessons learned process captures two types of inform­a­tion from projects:
object­ive data (facts about perform­ance and outputs achieved) and subject­ive
data (such as good and poor prac­tices to be repeated or avoided in the future).

31.2 Purpose of lessons learned

Capturing lessons learned is import­ant because it will assist in improv­ing
estim­at­ing efforts for future phases or projects. It may help avoid costly errors in
the future by increas­ing the accur­acy of plan­ning and schedul­ing. It provides
inform­a­tion for bench­mark­ing against success criteria for task dura­tions, costs,
risks and work rate(s). Thus, it improves the quality of decision making and
confid­ence in deliv­ery.
From a plan­ning perspect­ive, there are two types of learn­ing that should be
captured.

31.3 Productivity data

First, there are the actual output rates achieved. These should include not only
the man-hours expen­ded by the resources, but also the costs incurred for these
outputs (Figure 31.1). The quant­ity and quality of the work should also be noted,
mention­ing any mitig­at­ing factors affect­ing perform­ance. For example, was the
weather unusu­ally cold, or very hot?

325
Planning, Scheduling, Monitoring and Control

Figure 31.1 Example proforma to collect output rates

Similarly, for design work, captur­ing the total man-hours to produce certain
types of deliv­er­ables will give useful productiv­ity data for future use.

31.4 Qualitative lessons learned

The second type of inform­a­tion that it is import­ant to capture is more qual­it­at­ive
in nature: it is the collec­tion of lessons learned. This will cover things that were
done well and things that could have been improved. This will usually be captured
in a formal review session and subsequent report.
A learn­ing review is a simple activ­ity which helps project team members to
continu­ally learn after the comple­tion of a project stage or at the end of the overall
project. It brings together relev­ant team members and stake­hold­ers and allows
them to eval­ua­ te the outcomes of their actions and to draw lessons for the future.
It is usually conduc­ted with the help of a facil­it­ator, and is a struc­tured method for
prior­it­ising and synthes­ising lessons learned across the whole project life cycle.
Lessons learned must be recor­ded and reviewed through­out the project life,
and not just at the end of a phase (when many people have left the project to
focus on other work or new projects). To achieve this, a process for record­ing
lessons learned must be estab­lished and promoted to all members of the project
team.

31.4.1 Stakeholders involved in a lessons learned review

The key stake­hold­ers iden­ti­fied should be repres­ent­at­ive of the project and be
able to object­ively review the project perform­ance. Below is a sugges­ted generic
list of stake­hold­ers who could be involved in the lessons learned review:

• project sponsor;
• project manager;

326
 Lessons learned

• respons­ible managers (section managers, or control account managers in

defence sector);
• project controls managers;
• func­tional heads of depart­ments or subject matter experts;
• client repres­ent­at­ives;
• key supply chain repres­ent­at­ives;
• people involved in related projects who could contrib­ute to or benefit from the
review.

31.4.2 Considerations
• Lessons should be agreed by all project team members.
• Complete indi­vidual lessons learned as soon after the task/activ­ity/stage has
completed, and try to conduct within a month.
• Focus on future improve­ments and re-usability.
• Categorisation of lessons learned is useful to aid future analysis of both lessons
and actions.
• The docu­ment(s) where the lessons learned will reside and the relev­ant
process (if applic­able) where the lessons learned are applied.
• To update the lessons learned action plan to ensure that the lessons have been
captured and the relev­ant docu­ment­a­tion updated in line with the organ­isa­
tion’s change control process.

An action plan should be created from the lessons learned exer­cise and will have
the follow­ing head­ings to help complete the integ­ra­tion of the lessons back into
the organ­isa­tion:

• unique ID;
• lesson learned element descrip­tion;
• lesson learned owner;
• lesson learned action;
• signi­fic­ance;
• relev­ant control docu­ment;
• change control completed.

The func­tional leads are respons­ible for veri­fy­ing that appro­pri­ate person­nel are
aware of the learn­ing points in the repos­it­ory and that any recom­mend­a­tions
have been imple­men­ted and any actions are closed out.

327
 The final word

The plan, the real world and how the project reacts!
 Glossary

Accrual A liab­il­ity that has yet to be invoiced. The timing of payment and
amount of the invoice may be uncer­tain.
Activity-based cost The estim­ated time taken to complete the work activ­ity,
multi­plied by the compos­ite hourly rate for the personnel, together with addi­tions
for mater­i­als and equip­ment.
Activity weeks method A simple method of monit­or­ing progress by
count­ing the number of activ­it­ies in progress each week.
Actual cost Also known as actual cost of work performed (ACWP). It is the
cost of the work that has been performed. It may include costs from account­ing
systems with appro­pri­ate accru­als.
Arrow diagram method (ADM) A method of creat­ing a network with
activ­it­ies on the ‘arrows’ rather than the ‘nodes’.
Assurance process The process by which one party – usually the customer
– makes sure that another party – often a contractor – carries out a partic­ul­ar
action, e.g. compli­ance with stand­ards.
Bar chart See Gantt chart.
Baseline The refer­ence level against which a project is monitored and
controlled.
Benefit real­isa­tion review A review of the project outcomes – the analysis
of feedback from key stakeholders and the reasons for success or failure of the
realisation of anticipated benefits. Actions and recom­mend­a­tions should result
from the review.
Breakdown struc­ture A hier­arch­ical struc­ture by which project elements
are broken down, or decom­posed. Examples include cost break­down struc­ture
(CBS), organ­isa­tional break­down struc­ture (OBS), product break­down struc­ture
(PBS) and work break­down struc­ture (WBS).
Budget at comple­tion (BAC) The total budget for the work.

331
Glossary

Budgeted cost of work performed (BCWP) Earned value.

Budgeted cost of work sched­uled (BCWS) Planned value.
Capital costs Costs that come from capital funds as opposed to funds for
oper­at­ ional costs.
Change log A record of all project changes, whether proposed, author­ised,
rejec­ted or deferred.
Change order Authorises a change to the brief, includ­ing a change of
scope or agree­ment to accept a design solu­tion which is outside the agreed
cost para­met­ers.
Configuration manage­ment Configuration manage­ment encom­passes the
admin­is­trat­ive activ­it­ies concerned with the creation, main­ten­ance, controlled
change and quality control of the scope of work.
Constraint date Used to fix the start or finish of an activ­ity at a partic­u­lar
point in time.
Contingency Funds set aside for respond­ing to iden­ti­fied risks.
Cost break­down struc­ture A hierarchical structure used to organ­ise the
project costs accord­ing to category, often align­ing them with the organisation’s
budget­ing system. It facil­it­ates track­ing the budget perform­ance of the project.
Cost estim­at­ing rela­tion­ships (CER) Data analysed to find correl­a­tions
between cost drivers and other system para­met­ers such as size, design or
perform­ance.
Cost vari­ance Cost compar­ison between what has been earned and what
has been spent.
Cost perform­ance index (CPI) The ratio of earned value over actual cost.
Crit­ical path method (CPM) A project model­ling tech­nique which
determ­ines the longest logical path through a network sched­ule.
Critical path This is the chain of activ­it­ies connect­ing the start of a network
with the final activ­ity in that network through those activ­it­ies with zero float.
There may be more than one crit­ical path in a sched­ule.
Critical path analysis An analysis of the sched­ule based on the crit­ical path
tech­nique, includ­ing the exam­in­a­tion of float usage.

332
 Glossary

Dashboard reports Performance metrics (normally comprising graphs and

charts) to present the state of a partfolio, programme or project.
Deliverables A product, set of products or package of work that will be
delivered to, and form­ally accep­ted by, a stake­holder.

Delphi tech­nique A tech­nique based upon the prin­ciple that estim­ates from
an exper­i­enced and struc­tured panel can provide a useful judgement-based
output.

Dependencies The rela­tion­ship between activ­it­ies in a network diagram.

Dependencies can be internal or external. Internal depend­en­cies are those under
the control of the project manager. External depend­en­cies are those outside the
control of the project manager.

Design and build A method to deliver a project in which the design and
construc­tion services are contrac­ted by a single entity.

Drop line method A progress report­ing method in which a vertical line is

drawn at the point of the progress assess­ment date, across the bars on the
sched­ule.

‘Dummy’ tasks or activ­it­ies An activ­ity added to a sched­ule that does not

describe work. Often used in preference to adding a ‘lag’ to the schedule.

Early finish The earli­est possible date by which an activ­ity can finish within
the logical and imposed constraints of the network.

Early start The earli­est possible date when an activ­ity can start within the
logical and imposed constraints of the network.

Earned value (EV) The value of completed work expressed in terms of the
budget assigned to that work. A measure of progress, which may be expressed
in money or labour hours.

Earned value analysis (EVA) A tech­nique for meas­ur­ing project perform­

ance and progress.

Earned value manage­ment A project control process, based on a struc­tured

approach to plan­ning, cost collec­tion and perform­ance meas­ure­ment. It facil­it­
ates the integ­ra­tion of project scope, time and cost object­ives and the estab­lish­
ment of a baseline plan of perform­ance meas­ure­ment.

333
Glossary

Earned value technique (EVT) A technique used to objectively assess the

progress of an activity.
Estimate at completion (EAC) A value expressed in money and/or hours
to repres­ent the projec­ted final costs of work when completed. (Also referred to
as projec­ted out-turn cost.)
Estimate to complete (ETC) The fore­cast of labour hours and costs
required to complete the remain­ing author­ised work. It is based on a bottom-up
analysis of remain­ing work, and past and future perform­ance, along with the
avail­ab­il­ity of resources, is taken into consid­er­a­tion.
Float Time by which an activ­ity may be delayed or exten­ded without affect­ing
the start of any succeed­ing activ­ity. Slack is an altern­at­ive term for float.
Forensic sched­ule analysis The study and invest­ig­a­tion of events using
crit­ical path methods or other recog­nised sched­ule or sched­ule calcu­la­tion
methods.
Fragnet Template networks or sched­ules, usually for repet­it­ive sections of
sched­ules.
Gantt chart A partic­ul­ar type of bar chart used in project manage­ment,
showing planned activ­ity against time. A Gantt chart is a time-phased graphic
display of activ­ity dura­tions. Activities are listed with other tabular inform­a­tion on
the left side, with time inter­vals over the bars. Activity dura­tions are shown in the
form of hori­zontal bars.
Hammock A ‘summary’ task which can only have start to start and finish to
finish logic to a group of activ­it­ies. The dura­tion of the hammock is determ­ined by
the total elapsed dura­tion of the activ­it­ies it is linked to.
Horizontal integ­ra­tion This refers to the applic­a­tion and check­ing of logic
through the differ­ent sections of the sched­ule that are running in paral­lel (rather
than the sequen­tial logic).
Independent cost estim­ate Estimate prepared by external or third parties
with the express purpose of valid­at­ing, cross-checking or analys­ing estim­ates
developed by project teams.
Information required register A sched­ule detail­ing what inform­a­tion is
required through­out a project. Usually compris­ing three sets of dates for each
piece of inform­a­tion: planned/fore­cast/actual.

334
 Glossary

Interface Internal inter­face may relate to the handover of a piece of work

from one team to another. External inter­face may relate to deliv­er­ables to be
given or received from a third party organ­isa­tion.
Issues log Primarily a list of ongoing and closed issues on the project. It is
used to organ­ise the current issues by type and sever­ity in order to prior­it­ise.
Key perform­ance indic­ator (KPI) KPIs are meas­ures that provide
managers with the most import­ant perform­ance inform­a­tion to enable them or
their stake­hold­ers to under­stand the perform­ance level of the organ­isa­tion.
Lag In a network diagram, the minimum neces­sary lapse of time between the
finish of one activ­ity and the start of another. (May also be used with finish to
finish logic, etc.)
Lead A negat­ive lag. By defin­i­tion an illo­gical condi­tion.
Level of effort (LOE) An ongoing activ­ity that is carried out to support other
work activ­it­ies or the entire project.
Line of balance A schedul­ing tech­nique for deliv­ery of repet­it­ive products
that shows how resource teams move from product to product rather than the
detail of indi­vidual activ­it­ies.
Logic The links (prede­cessors or successors) between activ­it­ies in a sched­ule
or network diagram.
Logic density The average number of logic links per activ­ity across the
sched­ule.
Logistics plan­ning The plan­ning of the move­ment of phys­ical resources
such as mater­i­als, plant and equip­ment.
Make ready needs The things that must be in place to allow an activ­ity to
commence, e.g. designs, approvals, mater­i­als, etc.
Management reserve A sum of money held to cover the cost impact of an
unex­pec­ted event.
Metadata A term used to describe data about data. Document manage­ment
systems contain metadata.
Milestone defin­i­tion sheet (MDS) This is a sheet to record the details of
a key mile­stone. Includes descrip­tion and date, as well as parties involved in
achiev­ing the mile­stone.

335
Glossary

MOD Ministry of Defence (UK).

Monte Carlo analysis A set of compu­ta­tional calcu­la­tions that rely on
repeated random sampling to obtain a range of results – a prob­ab­il­ity distri­bu­tion.
Network diagram A pictorial present­a­tion of project data in which the
project logic is the main determ­in­ant of the place­ments of the activ­it­ies in the
network. Frequently called a flow­chart, PERT chart, logic drawing, activ­ity work
or logic diagram.
New engin­eer­ing contract (NEC) A suite of contracts that facil­it­ate the
imple­ment­a­tion of many sound project manage­ment prin­ciples and prac­tices.
They also define legal rela­tion­ships.
Optioneering Optioneering estim­ates are prepared to estab­lish the cost
differ­ences between two or more strategies in order to arrive at ranking to inform
an economic decision.
Order of magnitude (OM) Orders of magnitude are numbers of approx­im­
ately the same size.
Ordinal dates Where the calen­dar dates for a project are not yet known, the
sched­ule can be drawn up against week or month numbers, e.g. week 1, week 2,
week 3, etc.
Organisational break­down struc­ture (OBS) A hier­arch­ical way in which
an organ­isa­tion may be divided into manage­ment levels and groups, for plan­ning
and control purposes.
Output rate The plan­ning data required to enable the sched­uler to work out
the dura­tion of an activ­ity, e.g. cubic metres per hour for excav­a­tion.
Parametric estim­at­ing This uses a meth­od­o­logy that is based on
elements of cost extrac­ted from histor­ical data acquired from similar systems or
sub-systems.
Performance constraints These are usually determ­ined by the brief or
specific­a­tion for a project, and may be crit­ical to the busi­ness case, e.g. manu­fac­
tur­ing output from a factory.
Performance meas­ure­ment baseline (PMB) The sched­ule of all the
work to be performed, the budgeted cost for this work, and the elements that
produce the deliv­er­ables.

336
 Glossary

Planned value (PV) The value of work expec­ted to be completed at a point

in time. This may be expressed in money or labour hours.
Planning pack­ages These repres­ent work that is not defined enough to be
included within a work package. Usually used to cover future work.
Possessions These are times within a sched­ule when the project has to take
over the work area, thus stop­ping normal activ­ity. For example, a track posses­sion
stops trains running and allows work to be carried out. Can also apply to works in
factor­ies/manu­fac­tur­ing lines.
Precedence diagram method (PDM) This is a network diagram method
in which the node desig­nates the activ­ity, and the logical inter­face is repres­en­ted
by the arrow.
Predecessor An activ­ity that must be completed before the following activ­ity
can commence.
Prelims ‘Prelims’ is a short form for prelim­in­ar­ies: the on-cost expenses, staff
costs, site over­heads, etc.
Probability chart A chart showing the like­li­hood of an instance occur­ring –
for example, the like­li­hood of the project finish­ing on a specific date (usually
found in QSRA).
Procurement strategy The criteria to be considered prior to letting or
purchas­ing services for a project. Examples are what type of contracts will be
used; how the work will be pack­aged up; how the project will be funded.
Product break­down struc­ture A hier­archy of deliv­er­ables that are
required to be produced on the project. This forms the base docu­ment from
which the execu­tion strategy and product-based work break­down struc­ture may
be derived. It provides a guide for config­ur­a­tion control docu­ment­a­tion.
Programme manager The manager respons­ible for a group of projects, for
example a large change programme.
Project brief This defines the customer’s or client’s require­ments, and is key
to the design. It is also a funda­mental element of the busi­ness case.
Project execu­tion plan (PEP) The docu­ment describ­ing how, when and
by whom a project will be delivered. The targets will include the scope, times­
cales, costs, quality and bene­fits.

337
Glossary

Project life cycle Four major stages: 1) initi­ation; 2) plan­ning; 3) execu­tion;

4) clos­eout/handover.
Project manage­ment plan (PMP) Consists of the collec­tion of key project
inform­at­ ion needed by the project board, project manager and project office to
manage the project. Will comprise static elements (that are peri­od­ic­ally reviewed
but change rarely during the life of the project) and dynamic elements (that
change often).
Project sched­ule The tool that commu­nic­ates what work needs to be
performed, which resources will perform the work and the time­frames in which
that work will be performed.
Project sponsor This is the indi­vidual (often a manager or exec­ut­ive) with
overall account­ab­il­ity for the project. They are primar­ily concerned with ensur­ing
that the project deliv­ers the agreed busi­ness bene­fits.
Prolongation The term used to cover the amount of time a project dura­tion
extends – usually due to a delay.
Quantitative sched­ule risk analysis (QSRA) A generic term for
object­ive methods of assess­ing risks that cannot be iden­ti­fied accur­ately.
RACI The RACI matrix is a tool used for identi­fy­ing roles and respons­ib­il­
it­ies to avoid confu­sion over those roles and respons­ib­il­it­ies during the
project.
Redundant logic Logic links that are duplic­ated through an altern­at­ive route.
If ‘C’ cannot start until ‘B’ is complete, which cannot start until ‘A’ is complete,
then a logic link from ‘A’ to ‘C’ would be said to be redund­ant.
Request for inform­a­tion (RFI) The term used – usually in a formal
contract process – when a project team member requires extra inform­a­tion or
clari­fic­a­tion.
Requirements manage­ment The process of captur­ing, assess­ing and
justi­fy­ing stake­hold­ers’ wants and needs.
Resources A supply of money, mater­i­als, staff, labour, equip­ment or other
asset that can be used to deliver a product or service.
Resource break­down struc­ture (RBS) The hier­arch­ical break­down of a
project into resource require­ment elements.

338
 Glossary

Resource histo­gram The graph­ical display of resource require­ment or

usage on a project.
Responsibility assign­ment matrix (RAM) A diagram or chart showing
assigned respons­ib­il­it­ies for elements of work. It is created by combin­ing the
work break­down struc­ture and the organ­isa­tional break­down struc­ture.
Risk A signi­fic­ant, unplanned and uncer­tain event or situ­ation that, should it
occur, will have an effect on at least one project or sched­ule activ­ity, or busi­ness
object­ive. A detri­mental risk is often called a ‘threat’, and a bene­fic­ ial risk is called
an ‘oppor­tun­ity’.
Risk and oppor­tun­it­ies register This is a central repos­it­ory for all risks
iden­ti­fied by the project. Includes inform­a­tion such as risk prob­ab­il­ity, impact,
counter-measures, risk owner, etc. Also contains a section for oppor­tun­it­ies,
which can be time or cost-saving options.
Risk log This is a central repos­it­ory for all risks iden­ti­fied by the project.
Includes inform­a­tion such as risk prob­ab­il­ity, impact, counter-measures, risk
owner, etc.
Risk manage­ment plan This sets out how the thor­ough assess­ment of risk
asso­ci­ated with the project will be imple­men­ted.
Risk pot The fund where the money alloc­ated for risk is kept. The money is
‘drawn down’ from the fund as required.
Rolling wave planning This describes the plan­ning density that is achieved
at differ­ent moments in time. Primarily more detailed plan­ning in the imme­di­ate
future and less detailed towards the end of the project.
Rough order of magnitude (ROM) An estim­ate of costs and time provided
in the early stages of a project when its scope and require­ments have not been
fully defined.
Schedule perform­ance index (SPI) A term used in earned value analysis.
It is the ratio of work accom­plished to work planned for a specified time period.
The SPI is an effi­ciency rating for work accom­plish­ment, compar­ing work
achieved with what should have been achieved at any point in time.
Schedule vari­ance A metric for the sched­ule perform­ance on a project is the
algeb­raic differ­ence between earned value and the budget (sched­ule vari­ance =
earned value – budget). A posit­ive value is a favour­able condi­tion, whilst a
negat­ive value is unfa­vour­able.

339
Glossary

Schedule visib­il­ity task (SVT) Where an activ­ity is depend­ent on a lead

time, the sched­ule visib­il­ity task repres­ents the elapsed/lead time or the customer
approval time.
Scheduling Software Software used for project planning, scheduling,
resource allocation and performance measurement activities. Is also used for
collaboration and communication between project stakeholders.
Scope The sum of deliv­er­ables and the work content to produce a project.
S-curves Lines drawn on a graph to express a quant­ity planned, achieved or
expen­ded across time. Named ‘S-curves’, as there is a usual tend­ency for them to
commence and complete at a slower rate.
‘Scrum’ Scrum is an ‘agile meth­od­o­logy’ that can be applied to nearly any
project; however, it is most commonly used in soft­ware devel­op­ment.
Slack (or float) Slack is the term used by MS Project to describe float.
SMART Usually relates to specific, meas­ur­able, achiev­able, real­istic, and
time-bound (there are other vari­ations).
Specific analogy estim­at­ing This method of estim­at­ing is based upon
select­ing a costed project that is similar or related to the project costs being
estim­ated.
Stage plan A devel­op­ment of the project sched­ule that contains enough
detail to allow the project manager to control a portion of the project (the ‘stage’),
usually on a daily basis.
Stakeholder Any indi­vidual, group or organ­isa­tion that can affect, be affected
by or perceive itself to be affected by the project.
Stakeholder manage­ment The system­atic iden­ti­fic­a­tion, analysis and plan­ning
of actions to commu­nic­ate with, nego­ti­ate with and influ­ence stake­hold­ers.
Statement of work This explains the customer/client needs and require­
ments. It is often developed in line with the busi­ness case. It will then form the
basis of contractor selec­tion and contract admin­is­tra­tion.
Steps These are pre-agreed progress meas­ures against which the project will
assess the tasks, to estab­lish per cent comple­tion statuses in a tangible and
object­ive (rather than subject­ive) way.

340
 Glossary

Strategic sched­ule The high-level sched­ule. Often produced early in the

project life cycle to help determ­ine the rela­tion­ship with other projects.
System require­ments These define and drive the work to be completed
within the system design process and subsequent subsys­tem and compon­ent
design.
Successor A successor is an activ­ity whose start or finish depends on the start
or finish of a prede­cessor activ­ity.
Target date The planned date to complete an activ­ity or project. (May be
earlier than the contract date.)
Three-point estim­ate An estim­ate giving the most likely mid-range value,
an optim­istic value and a pess­im­istic worst case value.
Time analysis The process that calcu­lates the time­frame in which each
activ­ity can take place. It iden­ti­fies the minimum time in which the network can
be completed, based on the activ­ity dura­tions and the logical links defined.
Time chain­age Used to illus­trate projects that are linear in nature (an example
being road construc­tion). When well designed and drawn, it is a very useful visu­
al­isa­tion tool, often allow­ing the whole project to be displayed on a single chart.
Time contin­gency An approx­im­ate dura­tion of time assigned to an activ­ity
that takes into consid­er­a­tion the impact of uncer­tainty.
Time risk allow­ance (TRA) Durations are uncer­tain, and there­fore time
contin­gency should be allowed for in sched­ules (also see QSRA).
Tornado chart Within a quant­it­at­ive sched­ule risk analysis, one of the outputs
is a chart that resembles the shape of a tornado. The activ­it­ies that have the most
influ­ence on the overall project end date are displayed in the tornado chart.
Total float Time by which an activ­ity may be delayed or exten­ded without
affect­ing the total project dura­tion or delay­ing a finish date.
Validation and veri­fic­a­tion require­ments matrix This V-shaped model
is useful to map the user require­ments and system design, in order to facil­it­ate
the assur­ance process.
Vertical integ­ra­tion The process that confirms that the data at differ­ent
levels of detail is consist­ent and compre­hens­ive through­out the whole length of
the sched­ule – from begin­ning to end.

341
Glossary

WBS diction­ary Covers the various WBS sections and defines all the deliv­
er­ables relat­ing to the scope or state­ment of work.
Windows analysis This process is used to compare the planned sched­ule
with the as-built sched­ule during a partic­ul­ar period or ‘window’ of time.
Work break­down struc­ture (WBS) Defines the total work to be
under­taken and provides a struc­ture for all control systems. It allows a project or
programme to be divided by level into discrete groups for program­ming, cost
plan­ning and control purposes. The WBS is a tool for defin­ing the hier­arch­ical
break­down of work required to deliver the products. Major categor­ies are broken
down into smaller compon­ents. These are sub-divided until the lowest required
level of detail is estab­lished. The lowest units of the WBS are gener­ally work
pack­ages.
Work calen­dar Used to define the amount of working and non-working time
through­out the dura­tion of the project. They are also used to determ­ine when
the work will be carried out, e.g. night working or week­ends only.
Work package A discrete element of project scope at the lowest level of
each branch of the work break­down struc­ture. Collectively, the work pack­ages
specify all the work and products included in the project.

342
 Acronyms

£RAM Financial respons­ib­il­ity assign­ment matrix

3D Three-dimensional
ABC Activity-based cost estimating
AC Actual cost
ACWP Actual cost of work performed
ADM Arrow diagram method
AE Apportioned effort
AFC Anticipated final cost
ATE Actual time elapsed
B/L Baseline
BAC Budget at comple­tion
BCWP Budgeted cost of work performed
BCWS Budgeted cost of work scheduled
BIM Building inform­a­tion model­ling
BT Budget trans­fer
CAD Computer aided design
CBS Cost break­down struc­ture
CER Cost estimating relationship
CO Change order
CPI Cost perform­ance index
CPM Critical path method
CV Cost vari­ance
DSDM Dynamic systems devel­op­ment method
EAC Estimate at comple­tion
EFC Estimated final 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 finish
FS Finish to start

343
Acronyms

HSE Health, safety and envir­on­mental

KPI Key perform­ance indic­ator
LOE Level of effort
MDS Milestone definition sheet
MOD Ministry of Defence
MoSCoW Must have, should have, could have, won’t have
NEC New engin­eer­ing contract
OBS Organisational break­down struc­ture
OD Original dura­tion
OM Order of magnitude
PBS Product break­down struc­ture
PDM Precedence diagram method
PEP Project execu­tion plan
PMB Performance meas­ure­ment baseline
PMI Project manager’s instruc­tion
PMP Project manage­ment plan
PV Planned value
QCRA Quantitative cost risk analysis
QSRA Quantitative sched­ule risk analysis
RACI Responsibility, account­ab­il­ity, consul­ted, informed matrix
RAM Responsibility assign­ment matrix
RBS Resource break­down struc­ture
RFI Request for information
ROM Rough order of magnitude
SF Start to finish
SI Site instruc­tion
SMART Specific, meas­ur­able, achiev­able, relev­ant, time-bound
SOW Statement of work
SPI Schedule perform­ance index
SRD Systems require­ment docu­ment
SS Start to start
SV Schedule vari­ance
SVT Schedule visib­il­ity task
TRA Time risk allowance
TV Time vari­ance
WBS Work break­down struc­ture
WBSD Work break­down struc­ture diction­ary
WI Works inform­a­tion
XP Extreme program­ming

344
 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 for 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 performance reporting 223; and
activities 197–8; deleted activities 192; and the planning process 39; and quantitative
earned value analysis 237; out-of- 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 of work performed)
activity weeks method 222, 224, 226–7, 228, 236 212, 236
ACWP (actual cost of work performed) see AC benchmarked data 149, 198
AFC (anticipated final cost) 251 benefit realisation review 17–19
agile 47–9, 203–6 BIM (building information 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 profiles 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 transfers 84, 87, 220, 267,
304–5 271; and cost control 251–3; and earned
apportioned effort 248 value analysis 242–3; as part of planning
approximate estimating methods 79, 80–1 83–7; and performance reporting 230,
arrow diagram method (ADM) 122–3 236–7; and risk management 198, 283–4

345
Index

buffers 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 fee 239
cash-flow: definition 49; forecasting 18, 84–6; coordination meetings 257
monitoring 222, 230 cost/benefit 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
transfers 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 freezes 261 cost estimating relationships (CERs) 81
change log 263–4, 265, 266, 268, 314 cost forecasting 251
change management 259–71 cost management 236
change orders/change notices 79, 266–7, cost performance 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 interfaces 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 interfaces 161; and
comparative duration estimations 149 performance reporting 234–5; planning
competitive tender, alternatives to 18 checks (of schedule) 189–90; and
complex projects: external integration of quantitative schedule risk analysis 286;
interfaces 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 of contract 309 data date 186, 224
configuration management 261 data table 184–5
consents 181; consents trackers 42 day zero 125, 130
constraints 27, 39, 136–47, 159, 197 deferred change requests 265

346
 Index

definitive 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 fit’ 50–1
business case 17; and closeout/handover emergency procedures 261
319, 321; and cost estimating 82; design end-user benefits 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 final cost (EFC) 252, 253;
management 25, 28; and the estimated time to complete (ETCC) 247;
responsibility assignment matrix (RAM) estimating norms 40; estimation of duration
67; rolling wave planning 45–6; and 147–51; fair price estimating methods 79;
scheduling 157; and scope management 21 impact of change 264; quantity of resources
Delphi technique 81 153
density of schedules 94–8 ‘events’ focused (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 facilitated workshops 22, 44, 158
management 26, 27; and scheduling fair price estimating methods 79
157–64 feeder buffers 164
design and build phase 26 filters (on schedule views) 114, 184, 186,
design deliverable schedules 42 187
design deliverables tracker 109, 111 ‘finish on’ constraint 139, 197
detail density, schedule 94–9 ‘finish on or after’ constraint 140
development/strategic schedule 101–2 ‘finish on or before’ constraint 141
dictionaries 30, 61–2 finish to finish relationships 116, 134, 193
‘digital handover’ 201 finish to start relationships 123, 132–3, 193
discrete distributions 291 float: 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; free float
duration: duration uncertainty 285–6, 287, 131, 155; measurement of float usage 222,
292, 294; estimation of duration 147–51 234–5; negative float 131, 137, 142,
189–90, 196–7; and planning checks
early delivery 104 189–90; and quantitative schedule risk
early finish dates 126, 127 analysis 286; and scheduling 41, 50;
early/late curves 50–1, 85–6, 211 scheduling checks 196–8; shared float 132
early start dates 126, 212 see also total float
earned value analysis (EVA) 83, 222, 231, ‘forecast schedule’ 103
235–49 forensic schedule analysis 303–9

347
Index

forward and backward passes 93, 124, internal integration 159–60

125–7 invalid dates 193
fragnets 99, 215 issues log 38
free float 131, 155 iterative nature of processes: and agile
‘full detail’ cost estimating 82 planning 48, 203; and ‘collaborative
funding requirements 16, 83–4, 259, 266 planning’ 44; and float 155; and logic 123;
and requirements management 26;
Gantt charts 42–3, 66, 123, 167–72, 184–5, scheduling interfaces 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 performance indicators) 242, 244
hard constraints 197
high-density schedules 44–6, 94–9, 255 lags 116, 120, 123, 135–6, 194, 198
histograms for resource profiles 16, 154, 180, latest finish 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, safety and environment) 75–6, legislative changes 259
261 lessons learned 253, 276, 284, 314, 325–7
human factors/soft issues 2, 40 level of effort (LOE) activities 82, 115, 191–2,
198, 238–9, 248, 287
IAP (impacted as-planned method) 304, levels of schedules see density of schedules
305–6 line of 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
inflation 239 networks using scheduling software 147;
information required register 189 level of effort (LOE) activities 115; logic
innovative thinking, need for 37 bottlenecks 195–6; logic checks 193–6;
intellectual property 18 logic density 195; logical networks 125;
interfaces: 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 of logic linking
milestones 74; planning checks 189; and the 132; work breakdown structure (WBS)
planning process 38, 40; public interfaces 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
 Index

make ready needs 256, 257 options analysis 22

management issues: financial authority for order of 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 (of schedule) 188; and 23–4, 53, 56, 60, 64–5, 66–7
schedule density 98; senior management out-of-sequence activities 194–5
98; and tracker schedules 109 output rates 91, 187, 191, 325–6
‘mandatory finish’ 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 of 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 performance analysis techniques 222, 234–49
interfaces 162; interfaces 74; milestone performance constraints 39
definition sheets 189; milestone performance 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 performance reporting 221–49, 257–8
mission critical projects 12 permits and licences 181
modelling software 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 (of schedule) 183–4, 188–90
multiple ends 195–6 planning method statement (schedule
narrative) 43
negative float 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 of 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
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 of 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 benefits capability 151 prolongation 310 see also delays
project brief 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 familiarisation 33–4
project life 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 interfaces 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 for information (RFI) 257, 265
project manager 31–2, 115 see also requirements management 25–30
management issues requirements/needs-driven planning 43
project procurement professional 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 interfaces 159; and ‘resource-based estimating’ 82, 150
planning 42; and the planning process 39; resource-levelled schedules 50–1, 173, 212
project buffers 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
 Index

resources’ 152; definition 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’ of scheduling
the planning process 39, 40; and 94–8; forensic schedule analysis 303–9;
requirements management 28; resource high-density schedules 44–6, 94–9, 255;
buffers 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 (fragnets) 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 software: and activities 191;
safety and environment (HSE) 75–6; activity coding 113, 116, 118; and bar
planning for risk 274–5; and the planning charts/Gantt charts 170; baseline
process 40; review of 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 of 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 of work 30; time contingency management 266; planning checks (of
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 transfers 267
rough order of magnitude (ROM) estimates Scrum 204
79 S-curves 51, 85–6, 211, 239–42, 298–9
sensitivity analysis 299–300
safety 75–6 shared float 132
scenario planning (‘What ifs’) 107 short-term planning 255–7
schedule performance 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 of the truth’ reporting 104,
242–3 200
schedule visibility tasks (SVT) 116 ‘slack’ see float

351
Index

SMART (specific, measurable, achievable, summary schedule 103

relevant, timebound) 13, 189 suppliers’ works information 29–30
social media 151 system requirements document (SRD)
soft issues 2, 40 27–8
software: 3D visualisation software 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 software task analysis cost estimating 82
SOW (statement of work) 27, 30, 60 teamwork: and agile planning 204; and
specialist products 57, 58, 152 ‘collaborative planning’ 44; and planning 38;
specific analogy estimating 80–1 team sizes 153
SPI (schedule performance index) 239, 243, technical specification 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 of the time contingencies 51, 164–5, 197, 286
schedule 170; and interfaces 158; and time/cost/scope/quality triangle 104
lessons learned 326; and performance 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 after’ constraint 145 tornado charts 292, 294, 296, 298
‘start on or before’ constraint 146 total float 124, 127–8, 131, 155, 196–7, 310
start to finish relationships 134–5, 194 traceability 28
start to start relationships 116, 133–4, 193 tracker schedules 107–9
statement of work (SOW) 27, 30, 60 trackers, separate 42
steps, activity 116–17, 323 trend analysis 224, 235, 261
strategic fit 15 triangular distributions 290, 297
strategic schedule 16, 94, 101–2
sub-contracting 79, 165 uncertainty 45–6
successor relationships 116, 123, 131, 133, uniform distributions 289, 297
134, 159, 190, 194, 195 ‘unit cost’ estimating 82

352
 Index

V model (design and development) 28 work package scope sheet see WBS
validation and verification 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 interfaces 157; product
WBS dictionary 30, 61–2 breakdown structure (PBS) 57; and
weeks, as time units 118 re-baselining 220; and requirements
‘what if’ 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 interfaces 157, 159, working schedule/forecast schedule 103
161; and requirements management 26, works information (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 free float’ constraint 138

353
Planning, Scheduling, Monitoring and Control is
a comprehensive guide for anyone involved in
planning, scheduling and controlling projects.

Written to be accessible to all levels – from student

to senior project managers – it gives practical
guidance on all planning aspects of preparing to
undertake a project, executing a project, controlling
its delivery to budget, time and quality, and
delivering it safely.

Association for Project Management

Ibis House, Regent Park Telephone +44 (0) 845 458 1944
Summerleys Road Facsimile +44 (0) 845 458 8807
Princes Risborough Email [email protected]
Buckinghamshire HP27 9LE Web apm.org.uk