Project highlights

TeesRep: Teesside University's Research Repository http://tees.openrepository.com/tees/

This full text version, available on TeesRep, is the final version of this PhD Thesis:

Mackenzie, D. I. (2010) A review of project controls in the UK and methodologies to

improve the processes. Unpublished DProf Thesis. Teesside University.

This document was downloaded from http://tees.openrepository.com/tees/handle/10149/112675

All items in TeesRep are protected by copyright, with all rights reserved, unless otherwise indicated.

http://tees.openrepository.com/tees/handle/10149/112675

i

A REVIEW OF PROJECT CONTROLS IN THE UK &

METHODOLOGIES TO IMPROVE THE PROCESSES

IAN MACKENZIE

A thesis submitted in partial fulfilment of the Requirements of the University of Teesside

For the degree of Doctor in Professional Studies

November 2009

ii

DECLARATION

I declare that this thesis represents my own work, except where due acknowledgement is made, and that it has not previously been included in a thesis, dissertation or report submitted to this University or any other institution for a degree, diploma or any other qualifications. Signed ------------------------------

David Ian Mackenzie

iii

ACKNOWLEDGEMENTS I would like to express appreciation to Prof. Nash Dawood who supervised the research and development of the thesis, Nash,s guidance and support has been of great value in this period of study.

iv

Abstract

The construction industry represents a significant part of the Gross Domestic

Product, (GDP) in the UK. It employs around 1.4 million people and has averaged

around 7.5% of GDP over recent years. Although the industry is of major

importance to the UK economy, it still under achieves. Many projects run over

budget and are completed late to schedule and a lot of resource is invested in

making good defects, repair and replacement and in litigation (Latham 1994).

These shortfalls in the construction industry were investigated by EGAN 1998 in

his report, Rethinking Construction. EGAN proposed five key drivers for change,

these consisted of committed leadership, focus on the customer, integrating the

processes and teams, a quality driven agenda and commitment to people.

Targets were set to gauge the improvements to the UK, these include 10%

reduction in capital cost and construction time, 20% reduction in defects and

accident, 20% increase in productivity and profitability and 10% increase in

predictability of project performance.

This thesis reviews one of the most important drivers, which is the improvement to

integrate construction processes through improved project controls. The aim of the

Thesis was to investigate by a literature review, a questionnaire and survey and

three audits of client‟s processes and work practices how Project Controls was

currently operating to deliver Projects on time and within budget. It was then

necessary to review (how based on best practice) current Project Control

processes and systems could be improved. The improvements are portrayed by

the development a series of “road maps” and “tool kits” demonstrating how

processes and systems could be improved.

This research thesis investigates the status of Project Controls in the UK and

develops methodologies to improve controls.

The investigation of Project Controls is based on five pieces of work, namely;

i) A literature review of current practices;

ii) The development of a questionnaire and survey results;

iii) Three client reports of work carried out by the author.

The five pieces of work were then contextualised to form a commentary of findings

and recommendations for improvement.

v

The recommendations were then linked to a methodology for improvements to the

key elements of Project Controls. The aims of the thesis were achieved in that

many issues of weakness were identified in current Project Control systems and

processes and “road maps” were developed identifying in detail how best practice

should be adopted.

The thesis identifies major weaknesses in control of major projects with examples

such a Pharmaceuticals, Building construction and Road construction industries

demonstrating minimal understanding of the concepts and benefits of effective

control. It could be described as disappointing series of examples of why some of

our Industries fail to deliver to cost and schedule. However, the thesis does layout

via “road maps” how improvements could be made, this knowledge has in part

been shared with some clients in the Pharmaceutical and Road construction. The

thesis therefore does demonstrate a contribution to knowledge and some of its

recommendations are being implemented in practice.

The primary conclusions of the Thesis indicates that with the exception of Oil &

Gas companies there are major gaps between what is accepted as best practice

and what is happening in Industry with regards to Project Controls.

There is a lack of understanding at Project Control engineer and Project Manager

Level. There is a need for additional training in particular for Project Managers as

their understanding and ability to see the benefits is paramount to driving forward

effective planning and control for projects.

Also it is necessary that robust Project Control procedures are established in all

industries to integrate the cost and planning disciplines to ensure a common

approach to best practice is adopted.

vi

Title Page i

Declaration ii

Acknowledgements iii

Abstract iv

Table of Contents vi

List of Figures ix

1 Literature Review

1.1 Introduction 1

1.2 Project Management Bodies of Knowledge (BOK) 2

1.3 The Nature of Project Control 3

1.4 Importance of Project Control 4

1.5 Existing Project Control Processes 6

1.6 Multi-dimensional Project Control System Approaches 7

1.7 4D / 5D CAD Visualisation Technology 8

2 Cultural Aspects of Project Control 10

2.1 How Company Culture Affects the Project Controls Approach 10

2.2 Cultures and Observations in Other Industries 11

3 Results from Project Control Survey 14

3.1 Research Strategy and Design 14

3.2 Protocol and Data Collection 14

3.3 Introduction to Survey Cases 15

3.4 Analysis of Survey Findings 16

4 Transfer of the Oil & Gas Industry Tried and Tested Project Control 30

Methodologies to Other Industries

4.1 Company A Report 31

4.2 Company B Report 50

4.3 Company C Report 67

5 Commentary and Contextualisation of the Survey Paper 92

5.1 Overview 92

5.2 Planning and Schedule Control 92

5.2.1 Schedule Control – How it could be improved 93

5.2.2 Co-ordination and Critical Path Planning 93

5.2.3 Forecasting Completion Dates 93

5.3 Key Observations from the Questionnaire 94

5.3.1 Cost Estimating 96

5.3.2 Cost Control 97

vii

5.3.3 Change Control 97

5.3.4 Reporting of Progress at Project Level 98

6 Summary of Findings and Recommendations 99

6.1 Planning and Schedule Control 99

6.2 Cost Control and Estimating 102

6.3 Change Control 102

6.4 Reporting and Progress Measurement 103

7 Road Maps to Initiate Influences to Project Controls 104

7.1 Road Maps / Toolkits 104

7.2 Integration of Cost and Planning 105

7.2.1 Cost and Planning Integration 105

7.2.2 Cost and Planning Integration – The Benefits 105

7.2.3 Project Control to Meet Cost and Time Objectives 105

7.2.4 Project Control Standard Coding System 105

7.2.5 Project Control Estimate and Schedule Verification 106

7.2.6 Project Control Change Control 106

7.2.7 Project Control Trend and Variance Identification 106

7.3 Road Maps 107

7.4 Schedule Development 117

7.4.1 Schedule Selection – Where do we start? 117

7.4.2 Schedule Selection – Project Requirements 117

7.4.3 Schedule Techniques 117

7.4.4 Schedule the Hierarchy 119

7.4.5 Key Points to Note 122

7.4.6 Activity Coding 124

7.4.7 Work Breakdown Structure (WBS) 124

7.4.8 Activity Coding – Our Approach 124

7.4.9 Activity Coding Structure – Example 125

7.4.10 Activity Coding Definition – Level 4 127

7.4.11 Schedule Techniques – Overview 129

7.4.12 Project Responsibility, Duration and Update Cycle 130

7.4.13 Schedule Types 132

7.4.14 Critical Path Logic Diagram 134

7.4.15 Classic Schedule Bar Chart 136

7.4.16 Resource Forecasting 138

7.4.17 Project Forecast „S‟ Curves 140

7.4.18 Procurement Schedule 142

7.4.19 Time Chainage Diagram 144

7.4.20 Visual 4D Planner 146

viii

7.4.21 Software Tools 148

7.5 Estimate Development 151

7.5.1 Basis of Estimating 151

7.5.2 Estimate Information – Status Definition 151

7.5.3 Estimate Development 153

7.5.4 Estimating Techniques 153

7.5.5 Estimate Accuracy 159

7.5.6 Project on Cost 161

7.5.7 Value Management and Value Engineering 164

7.5.8 Estimate Allowances – Escalation 166

7.5.9 Estimate Allowances – Contingency 171

7.5.10 Risk Management – The Process 174

7.5.11 Estimate Format – By Activity 176

7.5.12 Estimate Format – By Procurement Strategy 179

7.5.13 Estimate Development – Project Budget Responsibility 179

7.5.14 Cash Flow Forecasting – Graphical 181

7.5.15 Cash Flow Forecasting Activity Based 184

7.5.16 Foreign Orders and Currency 186

7.5.17 Estimate and Schedule Verification 189

7.6 Cost Management Process 192

7.6.1 Cost Management – Monitoring Actual Cost 195

7.6.2 Risk Register and Progress 202

7.6.3 Foreign Orders and Currency 204

7.6.4 Clients Cost Ledger Reconciliation 207

7.6.5 Accruals Calculation 210

7.6.6 Cash Flow Forecast – Tracking Cost 213

7.6.7 Tracking Costs – Contingency 216

7.7 Change Control Process 219

7.7.1 Change Control Organisation 222

7.7.2 Change Order – Process Flow Sheet 224

7.7.3 Change Order – Form 227

7.7.4 Change Order Register 230

7.8 Progress Measurement 232

7.8.1 Progress Measurement Technique – Incremental Milestone 233

7.8.2 Progress Measurement Technique – Weighted or Equivalent 237

7.8.3 Progress Measurement – Requirements 241

7.8.4 Progress Record – Milestone Schedule 244

7.8.5 Progress Record – Classic Schedule Bar Chart 246

7.8.6 Progress Record – Period „Look Ahead‟ Chart 248

ix

7.8.7 Progress Record – Schedule Activity Table 250

7.8.8 Progress Record – Resource Histogram 252

7.8.9 Progress Record – Procurement Schedule 254

7.9 Reporting Process 256

7.9.1 Reporting – Team Effort 258

7.9.2 Report Types 260

7.9.3 Report Regularity 262

7.9.4 Project Report – Executive Summary 264

7.9.5 Project Report – Key Items 266

7.9.6 Project Report – Milestone Schedule 269

7.9.7 Project Report – Schedule 271

7.9.8 Project Report – Cost 273

7.9.9 Project Report – Change 276

7.9.10 Project Report – Risk 278

7.9.11 Project Report – Risk Update 279

8 Conclusion 280

8.1 Project Control Survey Questionnaire 281

8.2 Company A Report 282

8.3 Company B Report 282

8.4 Company C Report 283

8.5 Commentary and Contextualisation 284

8.6 Cultural Aspects 285

8.7 The Oil Industry Model 285

8.8 Training/ Future areas of research 286

9 References 288

10 Appendices 291

Figures

Fig 3.1 Chart – Section A: Q1-Q23

Fig 3.2 Chart – Section B: Schedule Control: Q25-Q42

Fig 3.4 Chart – Section D: Reporting: Q48-Q54

Fig 4.1 Process Flow Chart

Fig 5.1 Contextualisation Chart

Fig 7.1 Overview of Project Controls / IDEFO Chart A0

Fig 7.2 Planning / IDEFO Chart A1

Fig 7.3 Estimating / IDEFO Chart A2

Fig 7.4 Cost Management / IDEFO Chart A3

Fig 7.5 Change Control / IDEFO Chart A4

Fig 7.6 Progress Measurement & Reporting / IDEFO Chart A5

Fig 7.7 Schedule Selection – Flow Sheet

x

Fig 7.8 Schedule – The Hierarchy Pyramid

Fig 7.9 Schedule Development Flow Sheet

Fig 7.10 Project Activity Coding Structure

Fig 7.11 Activity Definition Form

Fig 7.12 Scheduling Techniques Summary

Fig 7.13 Milestone Schedule

Fig 7.14 Critical Path Logic Diagram – (PERT Chart)

Fig 7.15 Classic Schedule Bar Chart – (GANTT Chart)

Fig 7.16 Resource Histogram

Fig 7.17 Project Forecast „S‟ Curves

Fig 7.18 Procurement Schedule Example

Fig 7.19 Time Chainage Diagram

Fig 7.20 Visual 4D Planner

Fig 7.21 Checklist – Expectation of Information Availability

Fig 7.22 Estimating Development Flow Sheet

Fig 7.23 Estimating Techniques Summary

Fig 7.24 Estimate Accuracy Checklist

Fig 7.25 Project On Cost Checklist

Fig 7.26 Project Life Cycle – Impact of Change

Fig 7.27 Escalation – Indices for Uplifting Historical Data

Fig 7.28 Escalation – Indices for Future

Fig 7.29 Estimate Allowance – Contingency Checklist

Fig 7.30 Risk Management Flow Sheet

Fig 7.31 Estimate Format – Summary by Activity

Fig 7.32 Estimate Format – Summary by Procurement Strategy

Fig 7.33 Cash Flow Forecasting – Typical Graph

Fig 7.34 Cash Flow Forecasting – Activity Based Summary

Fig 7.35 Foreign Orders and Currency – Estimate Summary

Fig 7.36 Estimate and Schedule Verification Report

Fig 7.37 Cost Management Flow Sheet

Fig 7.38 Projects External Orders – Progress

Fig 7.39 Monitoring Actual Cost – Internal Costs Progress

Fig 7.40 Scoring Matrix

Fig 7.41 Risk Register Excerpt

Fig 7.42 Foreign Orders and Currency Progress

Fig 7.43 Clients Cost Ledger - Reconciliation Report

Fig 7.44 Accruals Calculation – Report

Fig 7.45 Cash Flow Forecasting – Tracking Movements

Fig 7.46 Tracking Costs – Contingency Movement

xi

Fig 7.47 Change Control Flow Sheet

Fig 7.48 Change Control Organogram

Fig 7.49 Change Order – Process Flow Sheet

Fig 7.50 Change Order – Form (Template)

Fig 7.51 Change Orders – Register Progress

Fig 7.52 Progress Measurement – Incremental Milestone

Fig 7.53 Progress Measurement – Weighted or Equivalent

Fig 7.54 Progress Measurement – Project Forecast „S‟ Curves

Fig 7.55 Progress Measurement – Flow Sheet

Fig 7.56 Milestone Schedule – Progress

Fig 7.57 Classic Schedule Bar Chart – Progress

Fig 7.58 Period „Look Ahead Chart‟ – Progress

Fig 7.59 Schedule Activity Table – Progress

Fig 7.60 Resource Histogram – Progress

Fig 7.61 Procurement Schedule – Progress

Fig 7.62 Reporting Flow Sheet

Fig 7.63 Reporting – Team Effort Model

Fig 7.64 Report Types – Schedule

Fig 7.65 Report Issue Dates

Fig 7.66 Project Report – Executive Summary Update

Fig 7.67 Project Report – Key Items Update

Fig 7.68 Project Report – Milestone Achievement Update

Fig 7.69 Project Report – Schedule Update

Fig 7.70 Project Report – Cost Update

Fig 7.71 Project Report – Change Order Update

Fig 7.72 Project Report – Risk Update

1

1 Literature Review

1.1 Introduction

The aim of the thesis is to review how Project Controls in the UK and Europe is

working in the delivery of projects. To establish what works and what does not and

to indicate how the research could help improve Project Controls by developing

processes and systems that supported the delivery of successful projects.

The objectives were to determine from experience, tacit knowledge, a

questionnaire survey, audits of construction businesses and a literature review

how projects were controlled. This data could then be contextualised to determine

areas of strengths and weaknesses in current processes and systems that

controlled projects. The ultimate output/objective from the research was improved

processes, systems and procedures with which to control projects.

The methodology of the research was to initially carryout a major literature review

of relevant documentation such as project management body of knowledge

(PMBOK). Also included in this review were various project management

documents and publications. The underlying aspect of the review concentrates on

what, is working in Project Controls and what is not, and also to consider

innovation, best practice and future methodologies for controlling projects.

Following the literature review it was decided to carryout a Project Controls survey

of a cross section of businesses who were involved in Oil and Gas, Petrochemical,

Building construction, Pharmaceutical, Nuclear and road construction. The survey

was carried out using a series of specifically designed questions to establish how

these industries approached Project Controls and what is working for them as well

a how project delivery was impacted by poor controls.

The next phase was to use Project Control survey reports from three audits carried

out by the author during his employment as a Project Controls Consultant. The

audit reports recorded use of Project Controls in the Nuclear, Road construction

and Pharmaceutical industries.

It was then necessary to contextualise the literature review, the survey and the

three audit reports. This contextualisation indeed demonstrated many common

threads of strengths and weaknesses in the use of Project Controls. From this

2

review we could determine how we could develop road maps to illustrate how

Project Controls could be improved.

Road maps were subsequently developed along with detailed procedures

indicating how improved processes and systems could improve Project Controls.

The road maps have been implemented during the course of this research and

several companies are now showing improvements to their control and delivery of

projects.

A comprehensive ongoing review of Project Controls has taken place during the

course of the D Prof. Research programme.

The literature review has concentrated on “what works and what does not.” it also

looks at innovation, best practice and future methodologies for controlling projects.

A project is defined A Guide to the Project Management Body of Knowledge

(PMBOK Guide) (PMI 2004) as “a temporary endeavour undertaken, to create a

unique product or service.” The term temporary, is defined as every project has a

beginning and an end. Unique is defined as the product or service, is different in

some distinguishing way from similar products or services.

There is a considerable amount of literature on Project Control and it is not the

intention to cover all existing publications.

This review, therefore, looks at discrete areas of Project Control as shown below:

i) Project management bodies of knowledge;

ii) The scope and nature of Project Control;

iii) The relevance and importance of Project Control;

iv) Project Control systems – existing;

v) Future requirements of Project Control.

1.2 Project Management Bodies of Knowledge (BOK)

The two main areas of BOK have been developed by two professional

associations: the Association of Project Management (APM) and the Project

Management Institute (PMI).

3

The main area of discussion around BOK, is that a single methodology does not fit

all kinds of projects, (Shenhar 2001). Shenhar classified a number of projects he

surveyed into four categories. In order to be managed successfully, projects in

each category are handled slightly differently. (Evaristo and Von Fenema P.C)

also took a similar view with regard to the classification of project types based on a

number of projects and sites involved in their study.

The examples of how the single methodology does not fit all kinds of projects are

as follows:-

a) Managing a construction project requires a different approach to that of an

IT related project;

b) Complex projects require a different approach to that of less complex

projects;

c) Different industries will have approaches which reflect their own

approaches, i.e. Pharmaceutical, Oil & Gas, Nuclear and Building

Construction all differ in their approaches.

Other researchers, however, support the BOK assumption of project similarity

(Tatikonda & Rosenthal 2000). They reviewed project management methods used

during the execution phase of new product development projects and found that

companies do indeed balance firmness and flexibility in product development

projects.

It is doubtful, however, that this piece of work by Tatikonda & Rosenthal was a real

test of comparing approaches across other types of projects or industries.

The PMBOK guide does not refer to Project Control as a knowledge area.

According to the guide, projects include segments within the other knowledge

areas, such as Cost Control within the project cost management knowledge area

and Schedule Control, within project time management knowledge area.

The APM BOK section on control which covers many of the recognised tools

associated with Project Control during the project life cycle. This is an important

difference between APM BOK and the PMBOK guide, according to (Rozenes S,

Vikner G and Spraggett S. 2006).

1.3 The Nature of Project Control

4

The traditional view of Project Controls as defined by PMBOK has been cost &

schedule during the project execution phase. Although this view is persuasive in

industry, a more effective Project Controls process can influence and benefit the

whole project life cycle including the following:

Project strategy;

Project organisation;

Project objectives;

Project control systems;

Scope management;

Work breakdown / cost breakdown structures;

Schedule management;

Cost management;

Engineering deliverables;

Procurement and material control;

Construction management;

Control administration;

Change order control;

Estimating;

Risk management;

Progress measurement / reporting;

Cost control;

Earned value reporting;

Productivity;

Trend Analysis;

Cost forecasting;

Schedule forecasting;

Corrective action.

Project Controls systems and processes indicate the direction of change from the

baseline costs and schedule, to the actual performance.

1.4 Importance of Project Control

The successful performance of a project depends on appropriate planning. The

PMBOK Guide defines the use of 21 processes that relate to planning out of the

39 processes for project management, (Globerson & Zwikeal 2002).

5

The execution of a project based on a robust project plan can be achieved through

an effective schedule control methodology.

The development of a suitable Project Control system is an important part of the

project management effort (Shtub, Bard & Globerson 2005). Furthermore, it is

widely recognised that planning and monitoring plays a major role as the cause of

project failures. Despite the continuous evolution in the project management field,

it appears evident that the traditional approach still shows a lack of appropriate

methodologies for Project Control. (De Falco & Macchiaro 1998). There have

been a number of articles published to support the importance of control in the

achievement of project objectives, Project performance can be improved if more

attention is given to the issue of control. (Avison, Baskerville & Myers 2001).

There has been a significant amount of research conducted to examine project

success factors. One such piece of research was carried out by (White & Fortune

2002) who sent out a questionnaire to almost 2,000 project managers. Another

survey covered 200 defence projects conducted by (Sadeh, Duir & Shentar 2000).

A survey was also carried out by (Frick & Shentar 2000), it was related to

organisations with inter / intertrade departmental projects.

The common thread from the surveys was a common checklist representing project success factors. This list included clear goals, management support, ownership, a control mechanism and communicating. (Rozenes, S., Spraggett, S., Vitner, G 2006).

An IBC 2000 Project Control Best Practice Study carried out by IPA indentified that

good Project Control practices reduce execution schedule slip by 15%.

Project Controls cost range from 0.5% to 3% of total project, (including cost

accounting), therefore, to break even, Project Control needs to improve cost

effectiveness by around 2%.

A sample study carried out by the IBC Cost Engineering Committee (CEC) in

1999, showed cost improvements for the projects in the study, was more than

10%. It is noted also that NPV also benefits from schedule improvements.

Success factors are based on good Project Control practices, which result in good

cost and schedule outcomes.

Best practices include: (according to IBC 2000 Project Control Best Practice Study

IBC 2000)

6

Performance estimates with a breakdown suitable for physical progress

measurement;

Owner quantitatively validates detail cost estimates;

Owner cost and Project Controls specialists are on project teams;

Capture actual results for future planning;

Outcomes improve with level of details of estimating, validation, control and

historical data collection;

Strong Project Control practices reduce the effect of project manager

turnover;

Good Project Control practices are a must for reimbursable execution

contract strategies;

Results are strongest for small projects.

1.5 Existing Project Controls Processes

The core of current Project Control process is the Work Breakdown Structure

(WBS). The PMBOK Guide defines a WBS as a deliverable, orientated grouping

of project elements, that organises and defines the total scope of the project. By

using a WBS, it allows the project team to plan a project by means of a

hierarchical structure, by identifying the elements and sub elements. A work

package, usually at the lowest level of a WBS, includes a series of tasks to be

carried out as part of an element of work. The WBS is interfaced with the project

plan and the coding structure within the WBS, allow reporting of cost and schedule

forecasts to deliver the schedule and cost reports. Recent developments have

initiated a Cost Breakdown Structure (CBS), which links to the WBS, but allows

increased details of monitoring and cost control to take place.

The Earned Value (EV) principal, that examines work performed cost versus

budgeted cost, is described in many, many papers and textbooks, e.g. (Sipfer &

Bufin 1997), ( Ruby 2000), (Fleming & Koppelman 1999 & 2000).

Current Project Control systems employ the earned value principles. A 1998

survey carried out by (Deng & Hung) suggested that only a small percentage of

construction projects implemented Earned Value technique. My survey of 24

planning engineers, (which was carried out in number of different industries

indicated that over 70% of companies were using Earned Value techniques.

Risk monitoring and control is a further process which keeps track of identified

risks and indentifies new risks.

7

(Elkington & Smallman 2002) carried out a survey to examine project management

risk practice, in the British utility sector. Findings showed that there was a strong

link between the use of risk management in projects and the level of their success.

A further study by (Miller & Lessard 2001), proposed that managing and controlling

risks reduces the probability of project failure.

In conclusion, the use of risk management enhances the project delivery and

reduce uncertainty in terms of time and budget.

1.6 Multi-dimensional Project Control System Approaches

Previous studies (Regina Gyampoh- Vidogah, Robert Moreton, David Proverb -

2003) suggest that the current control processes and systems are insufficient for

major projects and that a multi-dimensional Project Control system is needed, that

can monitor, measure and control the projects objectives. Also an integrated

system is required, that can measure the projects status during the life cycle of the

work.

A new Project Control methodology was developed by (Rosenes, Vitner &

Spraggett) in 2004. The new methodology was named the Multi-dimensional

Project Control system, (MPCS). The MPCS is an approach whereby deviations

between the planning phase and the execution phase are quantified, with respect

to the Global Project Control Specification, (GPCS). The projects current state is

translated into yield terms, which can be expressed as a gap vector representing

the multi-dimensional deviation from the GPCS. The MPCS allows the project

manager to determine the project status, where problems exist in the project,

where and when to take corrective action and how to measure improvement.

Implementing MPCS methodology does not require extra data collection.

Further work has also been carried out by (Songer A. D, Hays, B and North, C) in

2004 with regards to multi-dimensional visualisation of Project Control data Where

they advise „The construction industry produces voluminous quantitative data.

Much of this data is created during the controls phase of projects and relates to

cost, schedule and administrative information. Recent storage and processing

advances in computers, as well as display capabilities afforded by computer

graphics, increase the opportunity to monitor projects fundamentally different from

existing Project Control systems‟.

8

Visualisation technologies are also playing a part with innovative tools to integrate

digital 3 models, with time and cost information. Thus allowing a virtual reality

project control system, which can efficiently and visually manage the project

implementation process.

The Gantt chart is the commonly used planning tool on projects. The main issues

and problems according to (Dawood N & Mallasi Z 2006) is that the Gantt chart

has not changed for the last 40 years and planners do not use it to usually

communicate the executive strategy of the project.

(Mawdesley et al 1997), states that the Gantt chart technique does not furnish a

communication medium on how the project activities on the construction site are to

be executed. During the construction phase, the format of a Gantt chart does not

capture the visual interaction between the construction activities. As a result, the

Gantt charge is not adequate for rehearsing construction activities.

1.7 4D / 5D – CAD Visualisation Technology

4D construction visualisation has been apparent for some 15 to 20 years. More

recently, however, developments are underway to have 3D CAD linked with

planning software (Time) and the 5th dimension cost, thus giving rise to what is

known as 5D Project Controls. This research and development is being

spearheaded by Company X UK and the research team at Teesside Universities

Centre for Construction & Research department. The objectives of the 5D system

is to allow feasibility studies and impact analysis of technical and logistical

programmes by means of rehearsing the planned construction operations in the

virtual environment. Using these methods, an improved fine-tuning of the

schedule can be achieved, avoiding soft clashes in space management before

they affect project performance. Also by exploiting high quality visualisation

techniques, it is possible to enhance significantly the quality of interaction among

involved stakeholders reducing the intrinsic ambiguity and complexity of Gantt

charts and textual descriptions and time-based 3D views of the plant. Project

delivery can be improved through better understanding of site conditions and

implications of scheduling plans.

The cost and progress control tools and methods included in the development,

guarantees an increased ability to assess the project development status. The

integrated analysis features allow intuitive visual inspection of early warnings to

9

assess the causes of cost or time execution problems and identify and implement

correction actions.

The ability to rehearse and test several alternative scenarios in an information rich,

visual and interactive environment, will allow an improved risk analysis capability

and the choice of the most effective mitigation strategies both at design time and in

response to unexpected events during the construction phase.

The benefits of the 5D system are increased perception and confidence in the

project quality, in its control capabilities and in the communication across the

involved stakeholders, ultimately allowing the development of high quality

collaborative projects and integrated, effective and reliable risk management

strategies.

10

2 Culture Aspects of Project Controls

2.1 How Company culture affects the Project Controls Approach

North Sea Oil project controls are generally seen as the best practice approach,

this is in part due to the culture within the industry. This view was referred to by

HM UK Government in a white paper published in 2003. The white paper was

addressed to the UK Nuclear Industry.

This culture is driven by several factors, for example most projects were in the

£1 billion range and driver by the rate of return on the investment. The return on

the investment is determined by being ready to sell gas / oil to the market on a

specific date. Gas and oil sales are based on gas / oil sale agreements, which

work on a delivery or pay penalty basis. Also, within the construction and

installation phases oil companies need to book in advance heavy lift barges and

install the Jacket and Topsides in the field. Due to the demand on the heavy lift

barges, they must be booked two years in advance, at a cost of around $500,000

per day for periods up to 7 to 10 days. Oil companies cannot miss the pre-booked

dates, therefore schedule and cost control is paramount in the design,

procurement and construction phases. Finally, the projects are supported by

partner oil companies who own percentages of the field development and also the

banks who lend the finance to develop the field.

All of the above factors result in the demand from partners and bankers coupled

with penalties for missing deadlines, which results in a need to have good project

control systems and procedures to help manage the project. The outcome is a

culture within the project team that assures that the development is driven from the

top of the organisation to the bottom with all involved organised to control the cost

and schedule. This culture has been seen in many oil companies, throughout the

1980‟s and 1990‟s during major offshore oil field developments.

The culture ( Marathon Oil UK 1984 Brae Field Developments) resulted in the

development of many systems, procedures and processes being developed to

enhance the control of cost and planning techniques, which have since spread into

construction companies and other industries. The systems include:

a) Planning cost management and estimating procedures;

b) Effective schedule development;

c) Procurement schedules

11

d) Design interface schedules;

e) Four to six weeks look ahead schedules;

f) Progress measurement innovation;

g) Productivity calculations;

h) Reporting techniques developed;

i) Change control procedures developed to include impact statement

on cost and schedule;

j) Improved cost management processes;

k) Estimating techniques integrated with scope definition and cost control;

l) Integration of the contractors‟ procedures and processes.

2.2 Cultures and Observations in other Industries

From personal involvement in several Pharmaceutical companies it was observed

that the culture in the pharmaceutical industry projects division, proved to be totally

different to the oil and gas industry. The reasons for this appear to be based

around a number of factors; firstly the core business of pharmaceutical businesses

is to produce products to sell to markets. The management of projects, although

important to the industry, did not have the focus seen in the oil industry. This lack

of focus was coupled with a lack of understanding of many of the basic

requirements of project management and planning techniques.

It would seem that the pharmaceutical companies we discussed issues with,

regarding project management and planning, saw inefficiencies in their systems

and processes. They seem, however, due to the culture within the project groups,

unable to improve the processes. This in part, could be as a result of the

companies working in the industry being fairly insular and many members of the

project teams having worked in the industry for many years. This resulted in the

lack of best practice, modern methods and systems being introduced into the

business.

Cultures, however, can be changed, although it can be a long process to modify

the culture and improve controls and project delivery. However as a result of

implementing the following approach the culture of the companies did move

towards better control of projects:

a) Carry out a survey of current processes and systems;

b) Compare current processes against best practice;

12

c) Present results, observations and recommendations to

management;

d) Have the client appoint a sponsor to help initiate and introduce

recommendations;

e) Present outline of observations and recommendations to staff in

project team. Make the team aware of what needs to change and get

their involvement

f) Develop a plan to implement change;

g) Review all project plans with project team, develop achievable

plans that are robust and resourced with manpower;

h) Baseline the portfolio of plans;

i) Develop and carry out a progress measurement system;

j) Develop a project reporting system;

k) Set up a weekly progress review meeting and review projects by

exception, i.e. those that are not achieving the planned progress,

plot trends;

l) Record actions from the weekly progress meeting. This meeting

will identify problems or issues that need resolving in order to

improve progress and recover slippage;

m) Develop a change control system that captures changes to projects

and ensures the impact of changes are reflected in the cost and

schedule documentation.

A further example of cultural differences was found in the nuclear industry at a

remote site in the UK.

The site had until fairly recently been a provider of electricity, but was now in a

decommissioning phase. This phase, however, resulted in a portfolio of projects

required to decommission the site.

The site had a legacy of producing electricity; its management was a production

orientated team with relatively low experience of controlling projects.

The result of the lack of expertise in managing and controlling projects resulted in

poor control of projects.

13

The culture of the site resulted in site management not being aware what best

practice for project controls was and not understanding the need for effective

controls.

Examples of this were the lack of a common WBS or coding structure, cost

planning and estimating skills not integrated, portfolio / programme management

not being utilised.

The lack of basic understanding of Project Controls was a direct result of the

culture of the organisation that was not aware of how they should manage the

project.

The management team who generally operated as an operational unit and had not

moved its cultural view to being a project orientated management.

14

3 Results from Project Control Survey

3.1 Research Strategy and Design

The literature review of current practice in project planning and control as

described in Section 2, determines how the theory of the processes are generally

performed. The knowledge gained from the review, however, has to be tempered

with real life and a qualititive survey questionnaire study was chosen as the key

methodology to confirm and gain understanding of current practices.

3.2 Protocol of Data Collection

The first step was to develop a questionnaire to help understand how project

controls is operated in various industries, (see Appendix 1).

The questionnaire was developed from the authors experience in project controls

over a 30 year period. However, it also drew on literature from the PMBOK 2004

Guide, APM and The University of Leeds Guide to Design of Questionnaires

(2006). The questions were reviewed by a peer group of professional cost,

planning and estimating managers, some modifications and enhancements were

made to the questionnaire at this review stage.

A pilot study of the final questionnaire was then carried out on a small target group

of colleagues and this proved that there was a meaningful document in place to

move forward with the research.

The questionnaire in this research used both open and closed question formats to

collect the information from the research participants.

The next task was to carryout interviews with the participants. The interviews were

generally face to face; however, in the case of some European based projects

telephone interviews took place. Face to face interviews were the preferred

method as this method achieves the best return from participants, ( Czaja and

Blair, 2005)

The questionnaire was used to carry out interviews with project planners, project

control engineers and planning engineers.

The industries where the surveys were carried out included:

15

i) Oil & gas;

ii) Pharmaceutical;

iii) Nuclear;

iv) Building & construction;

v) Transport & utilities;

vi) Chemical / petrochemicals.

A total of 21 interviews were carried out, split across the various industries as

shown below;

i) Oil & gas 4 responses;

ii) Pharmaceutical 3 responses;

iii) Nuclear 4 responses;

iv) Buildings & construction 4 responses;

v) Transport & utilities 3 responses;

vi) Chemical / petrochemicals 3 responses.

The value of the projects being managed was over £4 billion.

3.3 Introduction to Survey Cases

Oil & Gas

The total value of the projects was £855 million and included:

a) Norwegian sector Brownfield offshore development;

b) UK North Sea offshore upgrade of facilities;

c) A major LNG development based in Spain;

d) A UK Oil Platform upgrade

Pharmaceutical

The total value of the projects was £55 million. The three companies were all UK

based and each managed a series of project value between £10m and £25m. The

projects were individually valued at between £50,000 and £3 million, each

company had a portfolio of projects in the range of 50 to 80 projects per company.

Nuclear

16

The total value of the projects was £180 million, the projects were new builds,

refurbishments and shutdown related work.

Building and Construction

The total value of the projects was £160 million with University buildings, new

office blocks and property developments amongst the projects being constructed.

Transport and Utilities

The value of the work was over £1 billion, the projects covered road building, rail

and water projects.

Chemical and Petrochemical Projects

The value of the projects was in the order of £800 million and was based on

projects based in Germany and the UK.

3.4 Analysis of Survey Findings

The questionnaire and survey questions were arranged in sections A to D.

Section A - covered issues such as cost control and estimating.

Section B - covered issues such as schedule development and control, critical

paths, forecasting completion dates.

Section C - covered issues around change control.

Section D – covered the reporting system and processes.

Structure of Questions

Interviews took place on the specific questions and answers were recorded using

the following conventions for example:

Q) Are work breakdown structures A B C D NE

17

established and all budget costs coded?

Legend

A) Always;

B) Sometimes;

C) As and when necessary;

D) Control impaired as a result;

NE) No experience.

What we learnt from the results by section is as follows:

Section A – Cost control and estimating (which covered questions 1 to 23 on the

questionnaire)

.

The chart below indicates the responses:

Fig 3.1

Section A: Q1 - Q23

46%

16%

21%

9%

8%

Alw ays

Sometimes

As and w hen Necessary

Control Impaired as a

Result

No Experience

18

If we consider that the topics / issues in the questionnaire represent best practice,

then only 46% of the sample always follows best practice. Analysis also indicates

that 16% of the sample sometimes adopted best practice with 21% using best

practice when they felt it necessary, with 9% of the sample having a view that

control was impaired as a result of not adopting best practice issues.

Feedback from the sample on how processes could be improved to help controls

is shown below:

Estimating

“Could refine the processes to correct best practice.”

“Consistently apply best practice.”

“Could be logic links between accounts and construction.”

“By portfolio availability, (procedures not integrated with cost / planning).”

“Require higher level of detail.”

“By benchmarking previous projects and establishing norms and preparing the

estimate at the lowest level and rolling up the values rather than a high level

guesstimate.”

“Central estimating with real benchmarking. Budgets are often met, but only

because costs are booked elsewhere. Estimating is often bespoke or carried

out by EPC, PMs or specialise departments. A new standardised WBS is to be

introduced.”

“By utilising project schedule to show where possible over spending may occur

during the project life cycle. All project estimates only change when a project

manager has ran out of money, therefore poor cost forecasting by the PM.”

“Could be improved, analysis actuals to improve future project estimates, no

formal estimating done.”

“A more integrated tender and approval process. Currently no formal

programme challenges, the review of estimates are financial and take no

cognisance of value, thus performance has been impaired. A team is being

formed to tackle estimates challenge. Current system is fair and transparent.”

“Elements of estimate used weight rather than contractor submitted values.”

Costs

Control of Reimbursable Resource

The following comments indicate how some companies‟ staff would like to improve

the process:

19

“Yes it works. Level of sign off could be improved.”

“Works fine. Client cost engineers control this work.”

“System works.”

“Doesn‟t work because of the fear factor, i.e. don‟t want to be blowing the

budget.”

“Yes the system works, but could be improved by any changes being reviewed

by project controls dept prior to implementation (i.e. prior warning and not just

sprung on project controls dept).”

“Increased frequency of updating for better control.”

“No cost controls in place. Could be improved by having the project controls

manager responsible for the forecast costs, rather than a corporate cost

engineer.”

“Scope changes poorly documented, therefore some cost surprises.”

“The current system works due to the functionality of SAP.”

“No room for improvement, good clear control system in place. Planners and

cost personnel to work more closely.”

“Yes.”

“The system is inefficient. Cost handling and reporting is by the finance dept

and is not managed by the PMs (not that any PMs are employed).

“System is robust and works well in practice.

“Yes it could.”

“It needs to improve.”

Section B

This section covers schedule control and schedule development, critical path

planning and forecasting completion dates.

The chart below indicates the responses:

Fig 3.2

20

Section B - Schedule Control: Q25 - Q42

51%

19%

14%

14%

2%

Alw ays

Sometimes



Result

No Experience

It is interesting to note that 14% of the sample advised that project control was

impaired as a result of inadequate schedule control.

The following comments were gleaned from clients as how improvements to major

aspects of schedule control could be achieved:

Schedule Control – How we could improve the current model

“Only high level programme from the contractor.”


“Require client buy-in.”

“4D planning. Filters to advise who does work via foreman / supervisors.”

“Honest appraisals / estimates / accuracy.”

“Lump sum therefore client has an overview and the risk is with the contractor.”

“Various departments throughout the UK need to buy into the programme.”

“Earlier release of engineering data to define scope.”

“By detailed integration with the design and procurement deliverables, and

alignment with the availability of key resources, plant and equipment.”

“At our company simple changes such as creating and monitoring against a

baseline would help improve performance. At our company no baselines are

set and therefore they are always on plan!!! This is not the way to manage

projects in my opinion.”

“Plans not usually used to drive work, culture not right for the plans to be driven

the way they should be.”

“N/A.”

21

“Create work schedules for all projects.”

“Greater and more accurate detail of tasks is required. Scope is developed but

is unstable without management support to control it. Lack of PM means the

validity of the scope is questionable. Logic with P3e with greater cross links

will be utilised.”

“Continuous review of programme with client and contractors.”

“Contractors use a standard scheduling tool. Level 1 & 2 schedules used to

control with project, with contractors using level 3, 4 and / or 5.”

“There were large gaps. Some inexperienced people were developing the

plans.”

“Professional planning support required. Planning usually left to contractors no

checks by client.”

“Good schedule.”

“Establish items 26, 27 & 28.”

“Implement all on programme.”

Co-ordination and Critical Path Planning

“Need to baseline / CP shown on schedule.”


“The CMS is broken down into detail.”


“Yes, more detailed assessment of the subcontractors schedules. Is not

happening because PM doesn‟t see financial control more important than its

physical worth.”

“No.”

“Recognition by project management that they are the owners of the plant.”

“By educating the end users of the benefits of planning ahead rather than

planning by default. P3 is in house, but sub-contractor not co-ordinated, using

different systems.”

“Using a standard software which can be used by all.”

“Our company should look at all projects the same way using the same

methods all of the time. Our company should have a standard reporting and

monitoring system so all projects are analysed the same way. Additional

training for PMs as only 10% understands critical path, etc.”

Could have more detail in the review.”

“Currently it is good.”

“Create planning awareness for scheduling, etc.”

22

“The use of PMs. Al sub-projects have a critical path; the overall path is also

identified. Bulk work is tightly controlled. For next execution more thorough L2

plans are being created to drive the project. Use of PMs would improve quality

of info.”

“Some contractors should actually use the software to schedule the plan rather

than making a nice picture.”

“MSP being used whilst P3 should be.”

“Inexperienced planners. PM not reviewing or involved, SAFRAN software v3

inappropriate for the project.”

“Professional planning control procedures. MBP software not up to the job.”

“Good.”

“Programme control management introduce planning experience to project

team.”

Forecasting Completion Dates

“Need a baseline / CP shown on schedule.”

“Always room to improve.”

“Better site record of changes and progress based on physical progress, could

be better but resources are an issue.”


“Yes – management of sub-contractors can be improved not all contractors

have planners all done in MSP by sub-contractors, therefore need to convert.

Weekly reporting focuses more on the site works.”

“Process established and agreed additional planning resources would improve

development time.”

“Improvements here are part of a gradual process of „teaching dogs new

tricks.‟ i.e. when a company emerges from a small design environment to a

project team environment, the change process can be frustratingly slow.”

“Introduction of Primavera.”

“Going back to basics, i.e. basic project management training for all project

managers so they can learn what to look for and understand the project

programme and how important it is to create a monitoring plan, and progress /

performance and resources.”

“39 is weak in some cases.”

“Currently good.”

“As above „planning‟.”

“Reports are daily. Resource levelling takes place prior to baselining; the

changes to resource are handled individually.”

23

“No system works well.”

“No major buy-in from senior managers who do not see the advantage of

project control.”

“Yes.”

“As above, „planning‟.”

“Lacking in site liaison.”

“Yes, items 38, 40 & 42 required to be improved upon.”

“Yes, create resource loaded programmes.”

Section C – Change Control

This section covers whether there is a change order system in place and whether

the impact of changes are reflected in the costs and schedule.

Fig 3.3

Section B - Schedule Control: Q25 - Q42

51%

19%

14%

14%

2%

Alw ays

Sometimes



Result

No Experience

It is interesting to note that most clients, (51%), used a change control system in

some form.

We asked the clients to advise how the change order system could be improved,

the following comments were received:

Change Order System – Does it work? Could it be improved?

“Standard system works.”

“It works. Essentially follow clients‟ procedural requirements.”

“Works. Forecast cost could be given IT use.”

“Honest appraisal / estimates / accuracy.”

“Only when applied correctly, particularly financial changes.”

24

“Change control with an appropriate tracking register, controlled by project

controls manager would be an improvement.”

“New scope change or CO system to be introduced. The design (EPC)

contractors have good change order systems, however, the contractor

systems are not integrated into our systems and the CO system has not yet

been fully implemented.”

“Yes. The change order process is primarily utilised for costs and it is up to

the skill of the planning engineer to find out what the change is and how it

affects the project as the PMs are only concerned with cost!!!”

“Good GSK system.”

“Not involved.”

“A more thorough system is being developed. COs are not diligently

controlled historically and unnecessary work is admitted.”

“Recording of change could be improved.”

“CO system not fully implemented.”

“Partially.”

Section D – Reporting of the Project / Projects

This section covers issues such as, “is there a reporting system in place?”, “is

performance measured and reported?”, “are risks identified, are trends identified

and are corrective actions being undertaken?”

The following chart indicates the results:

Fig 3.4

25

Section D - Reporting: Q48 - Q54

49%

19%

21%

8%3%

Alw ays

sometimes

As and When Necessary

Control Imparied as a

Result

No Experience

It is interesting to note that only 49% of those questioned had a regular reporting

process and that 8% of respondents indicated that control was impaired as a result

of inadequate reporting.

Clients were asked to advise if the reporting process could be improved, the

following comments were received:

“Not a bad report, but no baseline.”

“Always room to improve.”

“Benefits identified. Could be improved with additional resources.”

“Yes.”

“By lots of duplication in current reports. Cost reports, time reporting and

planning progress all using different cut-off dates.”

“Yes.”

“As the project has evolved, report volume has increased. Could be

streamlined to be more effective.”

“The reporting process could be improved by a precise edition issued to the

project team and a detailed version maintained for the inevitable claim at the

end of the project.”

“Yes. Cost / performance reports only carried out by 30-40% of projects,

therefore data is useless. Cash flow is reported to accounts separately for all

projects. EPC contractor reports not linked to BP systems. Reporting should

be linked to controlling system.”

26

“I believe that by standardising the current reporting procedure GSK would

benefit as at the moment they change their reports more or less each month.”

“51 is only milestones % completed or achieved man hours are not used.”

“Yes. Not enough time allocated to interrogate programme progress reports.”

“More automation and more integration would improve. Reporting will change

with P3e.”

“Standard reports needed for all contractors. New reporting system currently

being implemented.”

Clients were also asked if key performance indicators and gained value analysis

were important benefits to project controls.

The following comments were received:

“KPIs yes. EVA benefits to control.”

“Yes. Client cost engineers control this work.”

“Only way to control.”

“Yes.”

“Yes.”

“Yes. EVA and KPIs give a standardised method of measuring the project

progress.”

“Yes.”

“EVA cost values should never be confused with progress % complete. KPIs

are beneficial as a yardstick measure.”

“Only when well defined and understood.”

“I believe EVA and KPIs are an absolute must in all aspects of project

management, as they enable the project team to understand what the

consequence of poor performance and control will have on the project budget

and timescale.”

“KPIs not driver and actioned. Top 20 projects are concentrated on and those

need to happen.”

“Yes.”

“Yes.”

“No. The KPIs are not relevant.”

“Yes.”

“EVA should be used and contracts incentivised.”

“Yes.”

“Yes. Client improving cost management.”

27

The questionnaire was discussed with some 24 different companies and the

statistical analysis derived from the results gives a general view from the sample

taken, However, there could be an element of bias in the results from the sample

taken. The 24 companies could be described as a low figure on which to base

discrete results; therefore we need to treat the statistical analysis results with a

level of caution when considering the sample size.

The questionnaire was also used to gain tacit knowledge from the project control

personnel interviewed and this feedback provides comments regarding the

effectiveness or otherwise of the project control processes being surveyed

Oil Industry Best Practice

Comparison of Results between Different Industries

The oil and gas industry was proven to be the most advanced industry in terms of

utilising best practice systems and processes with regards to project controls. The

systems and processes were developed during the late 1970s and 1980s during

the major investments to extract oil from the North Sea. With major investment to

design, construct, install and commission the oil and gas installations, which cost

in the region of £1 billion, it is necessary to have robust project control systems in

place. The major investments coupled with gas and oil sales agreements, which

meant delivering oil and gas products to a predetermined date focused

management to deliver on time and within budget. The major operations in the

North Sea, such as Exxon, Shell, BP, Marathon and many of the major contractors

such as Bechtel, Fluor and Amec were also responsible in driving best practice

project controls processes.

In essence the model for major projects in the North Sea was based around

certain key criteria.

a) Suitably resourced planning engineers who were experienced in oil and

gas, with engineering qualifications;

b) Suitable planning software to develop plans and reporting procedures;

c) Procedures for planning, progress measurement and reporting developed

and in place;

d) Planning, progress measurement reporting requirements specified in the

ITT to contractors;

28

e) Prior to the bid being assessed for constructability, durations, logic and

resource levels. Develop in-house schedule for comparison with

contractor‟s bids;

f) After award, ensure the contract master schedule is submitted by the

contractor six weeks after award date, tie in a financial reward or penalty to

that submission. The client‟s works with the contractor to develop /

approve the schedule;

g) Following agreement of the contract master schedule and its baselining, a

weekly progress measurement and reporting process was put into place;

h) The contract master schedule, (CMS), is developed from around a 400

activity network (level 2 / 3); this includes a level 2 summary schedule and

a level 1 executive summary. Also included, is a resource histogram and

„S‟ curve by overall and by area and discipline;

i) man-hour estimating based on an agreed set of norm values. Estimates

and scope of work were agreed between client and contractor;

j) A robust change control system in place, that addressed the impact of

changes against the schedule impacts agreed between client and

contractor;

k) Following the weekly progress measurement exercise, the achieved

manhours and percentage progress calculations at discipline level was

calculated. Disciplines included:

Structural fabrication / erection

Piping fabrication / erection / testing;

Electrical;

Instrumentation;

Fire proofing

Insulation;

Architectural;

Equipment.

Each disciplines expended hours were captured used and productivity

calculations determined. Productivity is based on the ratio of output/ input /

input..

k) Following the weekly progress measure, a weekly progress meeting would

review progress data. The progress by disciplines would be reviewed and

variances in planned versus actual progress and productivity would be

29

discussed and where necessary, recovery plans developed to improve

progress and productivity. Lack of progress and productivity could be due

to several factors:

Insufficient supervision;

Material shortages and delays;

Wrong trade mix;

Incorrect sequencing of work;

Incorrect estimates of work scope;

Client changes;

Physical changes;

Physical clashes;

Weather.

It was, therefore, necessary to determine reasons for progress slippage,

once this had been established it was then possible to put into place

corrective actions to improve progress and productivity.

30

4 Transfer of the Oil and Gas Industry Tried and Tested Project Control Methodologies to Other Industries

During more than 20 years in project controls, the author has been able to offer

advice to clients in other industries and the chance to introduce the oil and gas

methodology into other sections of industry.

It is notable to point out, that the North Sea oil and gas methodology was referred

to by the Government in the scope of a white paper addressed to the nuclear

industry. The white paper advised the nuclear industry that they needed to follow

the project controls, (estimating, cost management and planning) methodology as

used by North Sea oil and gas companies in the 80s. The nuclear industry in the

early 2000‟s did improve their systems and processes to introduce better controls.

The author was invited by a major nuclear industry to review how cost planning

and estimating processes were integrated on a portfolio of projects valued at over

£1 billion.

31

4.1 Company A Report

Comments on the attached report.

Company A invited the author to review their planning, cost management and

estimating processes and how they interfaced as groups within the Dounreay site.

This audit was carried out in March 2003.

The reason why Company A wanted this audit carrying out, was that the NDA

(Nuclear Decommissioning Authority) were to come to site in the following months

and Company A wanted to establish where they stood in relation to best practice

and project control standards.

My company, (Company X), were at that time managing the planning engineering

functions and also some of the cost and estimating roles.

It is interesting to note that in 2002, Company A had been advised by the author

that the planning system adopted by Company A was flawed and that a

hierarchical system of „rolling‟ of project plans to the Dounreay restoration plan,

should be adopted. This advice was ignored at that time, but was implemented

following the NDA visit later that year.

Another key observation from this audit was the inconsistent approach to planning,

estimating and cost control, with different WBS being used in some areas. It

appeared that Company A placed personnel into the different areas of the plant

without any agreed procedures at the different specialist level and also with no

guidance of how the specialist in cost, planning and estimating should interface

with each other.

A further observation was that the culture of the Company A site was such that

there was little understanding of the project controls processes. This in part was

due to the fact that the site was, until fairly recently, a nuclear producer of energy

and many of the decommissioning managers had worked as operation managers

and were now responsible for managing projects. The project management role is

far different from that of operations manager and different skills, such as cost

management, planning and estimating skills / knowledge are needed to manage

projects. This lack of understanding was a major factor in why the project control

disciplines were not operating effectively.

32

Finally, it is worth pointing out that the recommendations in the report were largely

implemented by Company A and a much improved project controls system was

introduced, to help manage the £4 billion decommissioning of the Dounreay site.

33

4.1 Company A

Dounreay Project Controls Review

April 2003

34

1.0 INTRODUCTION

1.1 Company A have requested that Company X carry out a survey of their

planning and cost engineering services, to ensure compliance with existing

standards and practices and to identify areas of improvement.

1.2 There was also a requirement to review the integration of planning and cost

engineering.

1.3 The survey was carried out between 24 – 27 March 2003.

1.4 The report will cover the following aspects of the audit:

1.4.1 Review the planning systems, guidelines and processes across the

site;

1.4.2 Review the cost control systems, guidelines and processes across the

site;

1.4.3 Review the integration of planning and cost control site-wide.

1.5 Discussions were held with eight planning engineers, six cost engineers and

10 project managers / senior project managers. The planning engineers were

an amalgam of Company A and Company X staff. The cost engineers were a

mix of Company A and various other companies.

2.0 METHODOLOGY OF AUDIT

2.1 Prior to the audit, Company X had developed a 100 point check list, which was

used as a guide to audit the planning and cost teams against current best

practice.

2.2 The Dounreay planning guide, (developed by Company A), was also used as a

method of assessing if a common approach was being utilised across the site.

Company X‟s planning toolkit also supports the Dounreay planning guide and

this was also referenced during the audit.

35

2.3 The PRICE system procedure, project sanctioning procedure (DP/PJM/003),

Dounreay Project Management Manual Issue 3 and the EARNED Value

Analysis and Reporting guideline company (A/GN/A45) were used as

reference points to conduct the cost control audit. The 100 point check list was

also used to assess a common best practice approach.

2.4 Discussions took place with planning engineers, cost engineers and project

managers. The planning engineers and cost engineers where interviewed

regarding how they operated against the available Dounreay procedures /

guidelines and the Company X 100 point check list. The project managers

were asked for their views of how planning and cost engineering worked in

practice and was there room for improvement.

3.0 AUDIT FINDINGS PLANNING

3.1 Schedule Development:

3.1.1 All planning groups interviewed develop levels 1 to 3/4 planning

documentation. They also develop look-ahead schedules to drive the

work through the supervisors / project engineers. There is some

evidence, however, of inconsistencies in the layout of the schedules,

i.e. different colours used in presentation, logos not applied, revision

boxes not shown, etc. From discussions, none of the planning groups

have resources shown on the look-ahead schedules; this is a

requirement on the planning guidelines.

3.2 Applying resources to schedules / resource coding:

3.2.1 Standard Resource Codings

There has been a standard resource code determined which should be

used site-wide. Very few planners, however, are using it; most are

using their own resource codes.

3.2.2 Applying Resources to Schedules

Resourcing is done by approximately 50% of the planners. Some

areas partly use resourcing and three areas do not apply resources at

all.

36

3.3 Resource Levelling

Only two areas have applied resource levelling to schedules. Six areas do not

apply levelling techniques.

3.4 Planning Involvement with Invitation to Tender Process

Approximately 50% of the planners are totally involved in developing

milestones, setting standard planning requirements and guidance on the

software required by contractors in the ITT. All planners are involved in

reviewing the schedules submitted by contractors. Part of the reason why only

50% are involved in the ITT process is that some areas do not have a

requirement to issue tenders.

3.5 Progress Measurement Techniques, „S‟ Curves / Earned Value

All planning engineers have a form of progress measurement which is

acceptable, i.e. direct measurement, information from project engineers,

measures by contractors and spot checks. Just over 50%, however, use „S‟

curves to compare planned versus actual progress. Only two areas use the

Earned Value method of measurement. Progress measurement is carried out

on a monthly basis in all areas and progress data is used to develop monthly

reports for the project managers.

3.6 Standard Activity Codings and WBS

There are no standard activity or resource codings used across the site. A

WBS is being used in 50% of the areas visited.

3.7 Baseline Planning

Approximately 50% of the planning engineers baseline the plans. Less than

50% keep a log of how and why the schedule has slipped over time.

3.8 Change Control

Over 50% of the planners are aware and use a change control system, which

provides a mechanism for approving major changes and milestone movement.

37

There is no evidence of change control at a lower level which would allow

changes of scope to be monitored and tracked.

3.9 Planning and Cost Interface

The range of interface between the two groups varies between cost and

planning going their separate ways to 100% integration. In most areas,

however, there is some form of integration which is through a WBS / CBS

structure.

3.10 Schedule Risk Analysis

This is carried out in-house or by consultants in many areas, but is not 100%

across the site. There is also evidence of regular updates carried out in some

areas.

3.11 Project Manager‟s View of Planning

The general view was that the planning engineers did a good job. There were,

however, two observations made in one area, which suggested there was

room for improvement in that area. This has been discussed with the BSG

planning manager.

There were also some concerns regarding how data was transferred from

projects to update the DSRP schedule and the accuracy of some of the DSRP

scheduled dates.

3.12 General Observation by Auditor

The general perception is that the planning teams are a conscientious group

who are trying to provide a good service to their project teams. Their efforts,

however, are not being applied in a consistent manner. If Company A are to

develop an integrated site plan which captures all projects and site resource

requirements then common activity and resource codings and commonality of

approach are mandatory.

Several times through the audit, planners advised that some project managers

were only looking for “simple bar charts” and that planning was only paid a “lip

service” in some areas. This was perceived as an issue that should be

38

resolved, but it is in isolated areas. There were also issues regarding project

managers not fully understanding the requirements of planning and control

systems and this is an area where improvements could be made.

4.0 AUDIT FINDINGS COST CONTROL

4.1 Cost Engineering Procedures.

Whereas Company A have developed the Dounreay Planning Guide as a basis

for implementation of the planning process throughout the site, to date it

appears that no similar guidelines exist for the cost engineering discipline. The

following reference documents were however tabled.

Parametric cost estimating system (PRICE) to provide guidance with

regard to preparing estimates for decommissioning works;

Dounreay Procedure (DP/PJM/003) Project Sanctions;

Guidance note for Earned Value Analysis and Reporting;

Dounreay Project Management Manual.

4.2 Cost Engineering Findings

Estimating Process and Application

Main indications were that initial estimate preparation is undertaken by „stand

alone‟ estimators in conjunction with project managers, with cost engineer‟s

involvement essentially being „post sanction‟ although individual managers did

utilise the cost engineer to validate / sanity check the estimates as they felt

necessary.

Individual cost engineers did get involved with preparation of „one-off

„estimates, but there did not appear to be a strict regime with regard to the

basis of the estimate, labour-norms / historical data / on-costs etc.

The estimates as produced, essentially reflected the categories within the

Work Breakdown Structure and cost engineers recognised the requirement to

align the actual WBS with a suitable cost breakdown structure and current

39

Company A account codes, although opinions were expressed that the site

does not currently have a fully integrated system.

There was also a difference of opinion as to whether the cost breakdown

structure whilst aligning with the WBS, correlated directly with activities within

the project programme, a fundamental requirement if these two disciplines are

to be used as an effective control process.

It was not possible to interview estimators or interrogate any estimates, or

ascertain the basis of local inflation factors / cost data information.

Concerns were expressed with regard to inclusion within the estimates for

operational costs of maintaining redundant building fabrics. Indications were

that estimates essentially make provision for routine inspections etc, but do not

allow for the actual cost of the structure, whereas these costs are ultimately

charges against the sanction sums.

Fundamental to the development of the original sanction is the establishment

of „risk provision‟ and the regular monitoring of the same. This is considered

separately within this report, albeit that the personnel interviewed were aware

that the risk process was implemented, but were not fully conversant with the

actual methodology used or the interpretation of the data produced.

Concerns were expressed with regard the periodic review of estimates to

reflect either general development / changes in circumstance / risk

management.

4.3 Contract / Project Strategy / ITT Documentation

The Dounreay project management manual identifies within the project

planning and initiation phase, the requirement to develop a structured project

and contract strategy, to ascertain the most beneficial route. The PMM states

that the contract strategy meeting may be held at a joint project strategy

meeting.

From the personnel interviewed, it appears that the cost engineer / planning

engineers do not get involved in the contract strategy workshops. We consider

that it would be prudent to involve such personnel, particularly at the contract

strategy meetings, given that the planning engineer will have an active role in

40

ascertaining key deliverables and the cost engineer should be aware which

format of contract implementation will best deliver the works with the balanced

ownership of risk / liability.

The PMM identifies the requirement for a structured tender assessment

methodology prior to tenders being evaluated. What the PMM does not

identify is whether actual scoring criteria / matrices are agreed and lodged with

the contracts department prior to the date for return of tenders, together with a

pre-determined „model‟ for the assessment of „Compensation Events‟

(variations), which may influence the overall commercial standing of the

submitted tender.

The cost engineers interviewed did not get involved with any „pre-tender return‟

pro-formas, the actual evaluation / modelling being done as part of the overall

process. Technical and commercial issues are addressed separately and

drawn together into an overall assessment, although we were unable to

examine a standard „tender report‟.

The PMM makes no reference as to whether cost risk analysis is undertaken

as part of the tender appraisal, although it is acknowledged that any such

exercise should be rigidly administered against all tenders and not used as a

method of „skewing‟ financial outputs, (specific queries should be resolved with

individual tenderers as part of the tender review process and not addressed

subjectively by the reviewing authority), to ensure transparency of the process.

4.4 Value Management

The nature of the bulk of the works currently being undertaken relates primarily

to front end engineering / scope of requirements development and as such,

traditional value management techniques have not been adopted.

4.5 Cash Flow Planning

Sanction values are essentially split into annual budget forecasts and costs are

monitored against these individual sums. Indications were that these budgets /

spend profiles are generally developed from the activity schedules within the

individual project programme.

41

We understand that any under-spend within a particular annual budget is not

generally made available for transfer within subsequent years, albeit that the

actual sanction value still retains these sums.

4.6 Cost Monitoring / Control of Resources

Actual cost reports were essentially prepared on a regular basis (determined

by the project manager) but there does not appear to be a standard pro-forma

or layout for the basis of the report. Whilst the individuals essentially

recognised the requirement to align the report with the WBS and the

accounting process, the actual required out-puts from the report appeared to

be with different cost engineering / project manager teams.

General indications were that major changes in out-turn cost / revised spend

profiles are detailed within the narrative of the report.

The current format of data collection retrieval is via hard copy and manual input

into „Excel‟ spreadsheet, although a system has been developed for the

administration of the overall „Alliance‟ contracts whereby the individual alliance

contractors input data direct into protected fields within a fully integrated cost

system, generating value of work done / linked to accounts and planning data,

whereby cost reports / earned value can be developed with the minimum

number of manual transfer / potential errors.

Sanction values detailed within the reports are determined from:

Base estimate for main works / contractor / agency resource;

Internal charges (personnel) established using standard charge out day

rates and estimated resource requirements.

Indications from the cost engineers were that whist such internal charges are

detailed within the original sanction sum; these costs are not actually charged

to the project, (as a central overhead) and hence cannot be monitored against

the sanction sum. We were informed that with effect from 1 April 2003, internal

charges will be identified and the cost engineer will have the facility to query

levels / costs allocated against individual projects / budgets.

42

Such revision to the cost procedure will enable closer monitoring of the overall

sanction amount from ‟time-now‟ but will not address any apparent over / under

spend up to this point.

Company A guidance note (GN/A/45) Earned Value Analysis and Reporting,

identifies the procedures to be adopted in preparing Earned Value reports,

although the note in its introduction recognises that such reporting is not

mandatory within the organisation.

The cost engineers interviewed incorporated Earned Value reports within the

monthly reports and these primarily reflected the main activities within the

programme.

There did, however, appear to be differing opinions as to whether Earned

Value should monitor against invoiced amounts or actual committed value.

In all but one instance, no cost engineering resource applied KPI techniques to

monitor project performance, the exception recognising the benefit in aligning

overall performance / release of target sums with contract milestones.

4.7 Risk Management Process

Risk analysis techniques are applied at „approval estimate‟ stage, as part of the

project sanction process. This essentially identifies the P10, P50 and P90

percentiles, the latter being incorporated within the sanction paper.

The risk process is a dynamic process, which if to be used as an effective

management tool, should be reviewed on a regular basis, as not only a cost

and programme aid, but as a general vehicle for communication / delegation of

roles and responsibilities.

All parties recognised the need for ongoing / regular reviews, but the actual

practice differed greatly from the theory. Responses ranged from the

consensus that once the sanction had been set, there was no need to revisit

and re-run the model, to the recognition of the need to actively drive / manage

risks out of the process, including where risks had passed, re-running the

model to identify possible release of funds for other works within the sanction

amount (contingency draw down) or, conversely identifying new risks /

changes in impact with a potential cost over-run.

43

The general consensus was that regular reviews should be done, but there did

not appear to be any structured approach.

Given that the individual projects all feed from „the bottom-up‟ into the overall

de-commissioning programme, there appeared to be no lateral relationship

between individual projects, in so far as the impact of particular events on one

project may feed into critical areas of another. This issue was also noted with

particular regard to planning interface of separate projects, (see planning).

We were unable to ascertain the level of detail incorporated within the risk

process, whether correlation was considered or criticality / sensitivity analysis

was undertaken.

4.8 Interface between Cost and Planning Engineers

All interviewees recognised the importance in developing a close working

relationship between both disciplines and there are individual projects where

these act as part of an integrated team sharing office facilities. This is

paramount if close dialogue and hence, regular dissemination of information

maintained.

There are, however, still areas where the two disciplines work remotely and

this ultimately leads to breakdown in information exchange / different

interpretation / reporting structures.

4.9 Change Control

Fundamental to effective project control, is an effective change control

procedure. Company A are currently developing a suit of procedures

covering:

Project change control-sanction impact;

Milestone change control;

Budget change control.

Procedure 105-project change control has already been rolled out and is

operational. Indications are, however, that whilst individuals are aware that the

procedures exist, their implementation is piecemeal, with individual personnel

having only a high level awareness of their existence, but not implementation.

44

There does not appear to be a standard procedure for „project‟ change control

at actual „workface level‟, to address constructional change, which in isolation,

may not appear to impact upon the overall sanction, but which could

cumulatively have such an impact or impact on phasing budgets.

5.0 RECOMMENDATIONS

5.1 Planning

5.1.1 It is essential that an integrated Dounreay site plan (IDSP) is

developed. This will incorporate operations, decommissioning, projects

and site services. Near term work plans (2-3 years) will be developed

for all sections. These near term work plans would then automatically

roll up in Primavera P3 to form an IDSP. This would take the form of a

fully interfaced, resourced plan showing detailed work schedules over

the next 2-3 years. Outputs from the plan would be resource

requirements to support the plan, integrated schedules, „S curves and

Earned Value reporting.

5.1.2 In order that an IDSP is possible, however, it is necessary to develop a

site-wide activity and resource coding system. This is mandatory to

ensure an IDSP can be developed. Historically, this can cause a lot of

effort / discussion, but it is necessary if an integrated plan is to be

developed.

5.1.3 All near term work plans to be fully resourced by site planners.

5.1.4 Resource levelling techniques to be applied to near term work plans.

5.1.5 In order that the IDSP can be managed it will be necessary to have a

programme manager with a staff of 2-3 planners. They will receive the

individual plans from the individual site planners and integrate the

schedules, develop outputs, manage the monthly progress reports from

the site planners, review overall site resources and determine priorities.

5.1.6 Planning engineers need to be additionally involved in the ITT

documentation and review of tender schedules.

45

5.1.7 The use of „S‟ curves and Earned Value reporting needs to be

encouraged.

5.1.8 Baseline planning techniques need to be encouraged at site planning

level.

5.1.9 Change control methodologies need to be incorporated on a site-wide

basis. There are currently two change control procedures in use by

Company A. The planning and cost teams need to be aware of the

systems.

We would also advise that a change control procedure is developed to

capture scope changes, e.g. revised drawings, site clashes, revised

methods, etc. Although these changes can be small they can be

significant when reviewed cumulatively. The capture of these changes

ensures the plan is dynamic and the correct level of resources is

applied to the works. We would recommend that change control

workshops are initiated for planners to get the message across

regarding the importance of Company A‟s procedures.

5.2 The interfaces between cost and planning are not consistent across the site.

In some areas it works very well, in others there is a divergence. In those

areas where there are problems we need to carry out some training /

integration processes in order that we quickly resolve the problem areas.

5.2.1 There is a misunderstanding of the planning process by some project

engineers and project managers. We would recommend training in

those areas of the capability of P3 and the planning process. Company

X could carry out such training if required. This training could also be of

use to the cost engineers and give them an appreciation of the P3

planning system. We have applied this 2-3 hour course in other

nuclear facilities with good effect.

5.2.2 The planning guidelines developed in 2002 need revising to reflect the

LMU requirements, WBS, an IDSP approach, common coding

structures, cost integration and change control.

5.2.3 We would recommend also that to aid the drive to reinforcing a

common approach, a Company A planning processes folder is

46

developed. This would take a similar form as the Company X‟s

planning toolkit, but would concentrate on the following:-

(a) P3 standard presentation charts, colours, logos, revision box. This

will allow one common output, and if the planners are transferred

from one group they will pick up a standard approach across the

site;

(b) The Company A standard activity codes;

(c) The Company A standard resource codes;

(d) The basis of the change control procedure including site changes;

(e) Earned Value Analysis Company A standard approach;

(f) Progress Measurement, Reporting Company A standard

Reporting / weightings;

(g) Risk analysis guidelines;

(h) Milestone scheduling;

(i) Estimating data – data availability;

(j) ITT requirements;

(k) LMU approaches / guidelines;

(l) Close out data.

5.2.4 In order that the revised guidelines and the planning process

documentation are being applied in a consistent manner, we would

recommend that an internal or external audit system is introduced. This

would lead to planners being audited against the procedure and

process and non-conformance notes issued where appropriate. This

policing of the systems would lead to conformity across the site.

5.3 Cost Engineering

47

Conclusion and Recommendations.

From the discussions held between individual cost engineers and project

managers, there would appear to be marked differences with regard to what

individuals require / expect from the project team. There does not appear to be

any level of consistency of approach with regard to the day to day contract

administration of individual projects / the decommissioning project overall with

regard to:

Cost reporting-frequency / cut off dates / reporting format / presentation;

Involvement with regard to development of / or validation of estimates;

Tender appraisal-cost engineer / planning engineer involvement;

Risk analysis namely: periodic review, probabilistic modelling, proactive

management of risk, identification of new issues;

Integration of cost and schedule analysis.

Initial examination suggests that the following need to be implemented as a

matter of urgency.

Development of a „generic „cost engineering procedure addressing:

a) Cost reporting format / layout / timetable - the intention should be that

individual cost engineering / planning personnel should be able to migrate

from one project onto another and following a brief introduction into the

status of the project, pick up and run with the process with the minimum of

disruption, following a common format and within a rigid timeframe to meet

the overall „decommissioning plan‟.

b) Sanction / budget base-line and re-phasing- procedures should identify if

and when current / forecast expenditure profiles are underachieved or

exceeded with revised spend profiles against the individual budget /

sanction amounts. Reports should detail variance in month over forecast

spend / effect on overall forecast, with reasons for major changes in the

period.

a) Change control - it is acknowledged that change control procedures are

currently in development and it is essential that these are rolled out and

implemented to ensure full traceablity throughout the project process not

only identifying main reasons for changes to project budget / sanction

48

values, but also identifying cumulative impacts of change on not simply

levelling reasons for revised forecast / sanction values at the „last event in

the line‟.

Risk management process - there needs to be a structured approach to

effectively identifying and managing risk including details of:

Stages of workshops / reviews-including:

Design development;

Sanction;

Pre-contract;

Construction-periodic or at major changes;

Preparation for workshop-develop pre-workshop handbook outlining aims

and objectives, on the day / post event / input required on the day /

attendees required;

Frequency of qualitative / quantitative reviews;

Management action plans and implementation;

Probabilistic modelling to be undertaken, data output required / sensitivity

analysis-identification of key issues.

Interface between cost and planning engineer - both disciplines to form part of

an integrated team to ensure dissemination of information and a common

reporting process. Consideration should also be given to combining roles

within a cost and planning remit.

Possible development of a cost engineering „tool-box‟ - the generic process

detailed above should identify the procedures and timetables to be adhered to

such that as stated any cost engineer should be able to identify with any

project with the minimum of handover. It is however, acknowledged that actual

accounts procedures / output requirements within the Dounreay

decommissioning project may not necessarily reflect those issues identified

within the traditional construction industry. Consideration should, therefore, be

given to developing a separate „tool-box‟ identifying those methodologies

adopted, to ensure compliance with the generic procedures.

Periodic audit – It should be acknowledged that whilst specific procedures /

processes may be introduced, these are only effective if strictly adhered to.

We would therefore, suggest that spot audits of individual projects from

49

feasibility to implementation stage, to address implementation of generic

procedures „in the field‟.

6.0 ESTIMATING

6.1 We are mindful that in order to populate the new term work plans and the long

range plans with manhours and cost estimating data, (as required by the LMU),

an estimating system will have to be in place.

6.2 Whilst recognising you have estimating staff and without wanting to appear that

we are selling our skills, we do have 20 years experience developing estimates

for other companies. Also we have many different forms of estimating tools

including a suite of manhour norms for piping, electrical, mechanical, structural,

etc., many of which have been shared with our / your planning staff at

Dounreay.

6.3 Estimating is an area, therefore, where we could provide some assistance if

required.

50

4.2 Company B Report

The author was also invited to review how project planning was operating in two

major pharmaceutical companies. Both companies managed a portfolio of

projects valued at around £15 – £20 million per annum.

Notes of Experiences / Tacit Knowledge

Company B requested we review how they carried out project planning, as they

were uncomfortable with current processes and planning engineering. The client

wished to improve the present processes, but was unsure how to carry this out

and effect change and improvements.

Observations

The client was managing approximately 60 projects with an annual budget of

around £15 million. The work was managed by around 20 engineers and

managers, the projects were major improvements to a pharmaceutical plant

involving civil, construction, mechanical and electrical works. Project plans were

being developed in Primavera P3, however little care was being taken to phase the

projects, with the result that many projects were commencing on the same day

and resource levels were insufficient to execute the work. Progress measurement

was not carried out in a formal manner and the management team had no real

idea if a project was on schedule or late. Finally, apart from the senior managers,

it appeared that most people were not interested in the project status.

Actions

A meaningful schedule was developed, agreed with the staff and baselined. This

became the control schedule and as new projects were added they became part of

the revised schedule. Resources were added to the schedule and resource

levelling took place to determine if sufficient staff was available to complete the

work as planned.

Progress measurement procedures were developed and agreed, this resulted in a

monthly measure with progress reports issued, indicating actual versus planned

achievements at project and overall levels. The results of the progress measure

were reviewed at a monthly progress meeting. This meeting then allowed the

engineers and managers to explain why the slippage to their projects had

51

occurred. Although the engineers and managers were not used to explaining why

the schedule had slipped, most did after some time understand that it was

necessary to understand why. The analysis of achievement indicated that only

around 25% of milestones were being achieved prior to implementation of a

revised planning and progress system. During the implementation, analysis of the

progress measurement indicated that milestone achievements were generally not

achieved, as a result of 6-7 repeated major factors, i.e:

Lack of QA resource;

Material shortages;

Owners failing to sign off project closure;

Facility not available to carry out tasks;

Lack of facility resource to support project teams.

Having, therefore, identified the problems that repeatedly prevented milestones

and programme delivery being effective. A series of improvements were put into

place to solve the problems. Among these were:

Additional QA resources;

Improved material delivery;

Agreements from owners to sign off project closure reports;

Improved interfaces with facilities to gain access and support.

Going forward, the monthly progress review meeting continued to identify other

problem areas and an action plan developed to solve the problems as they were

identified. The outcome of installing improved schedule, carrying out a progress

measurement process / reporting, identifying issues that impacted the plan,

resolving those issues resulted in achieving 85% of the milestones, as opposed to

25% achievement.

52

The process is shown below:

Fig 4.1 Process Flow Chart

Progress

measurement

Improved performance

Report

Progress meeting

Issues resolved

Feedback loops

Feedback loops

Scope of

work / project

Plan developed

cost / resources

Baseline planProgress

measurement

Improved performance

Report

Progress meeting

Issues resolved

Feedback loops

Feedback loops

Scope of

work / project

Plan developed

cost / resources

Baseline plan

53

4.2 Company B

Change Projects Planning Review

February 2003

54

Contents

1 Introduction

2 Report Approach

3 Management Overview

4 Present Status

5 The Way Forward

6 Software Recommendation

7 Outsourcing Strategy Discussion

8 Training

9 Proposal to Provide Planning and Cost Services

10 Report Conclusions

11 Proposed Implementation Strategy

55

1 Introduction

Pharmaceutical products have been produced at the Avlon Works for a number of

years, under a series of guises, but more recently into the present production

company, Company B. As part of their continuing philosophy towards customer

satisfaction, high management levels now wish to raise the level of expectancy

with respect to project planning and reporting.

A presentation to the capital projects department (Change Projects) in January

2003 by Company X, put forward the suggestion of a review of the in-house

planning procedures. This review, over a two week period would look at how the

current set-up is working, highlight problem areas and put forward viable solutions

to improve and raise the profile of the planning function. Key areas to review are

as follows: -

Review the planning process within the department;

Develop an impression of how the planning group is performing from other

parties within the capital projects department;

Propose where improvements could be made in terms of efficiency,

effectiveness and content of developing programmes;

Recommend a planning software package that will enhance the

department and bring it up to speed with current practices.

As a follow-up, the findings of this report can be presented at Company B‟s Avlon

Works offices. It is also hoped to take advantage of this opportunity to offer advice

on how Company X can assist with Company B‟s target of upgrading their

planning capabilities.

This report is intended for Company B‟s senior management, however, there is no

reason why it should not be shared with all levels, as it is the same people who

have contributed and assisted in its preparation.

2 Report Approach

This report has been developed with assistance across the full spectrum of

professionals, within the change projects organisation. All levels of managers,

engineers, designers and co-ordinators have been included to broaden the debate

as to the way forward.

56

Understanding what and how information is generated, leads on to how effectively

it is used. It is the so-called “lower levels” where key issues are found which will

inevitably have a knock-on effect throughout the higher management levels.

I would like to thank all concerned who have given me time to make this report

possible.

3 Management Overview

Primarily there is a need to improve the planning service to managers, project

engineers and those who support the work in the field – the

co-ordinators. There is no doubt the profile of the “planning function” has to be

raised.

Throughout discussions, at all levels, there are issues that are raised over and

over, namely: -

Simplicity – any recommendations must be relatively easy to implement.

The majority of the capital projects are for approximately £100,000 and do

not require an over-complicated approach.

Efficiency – all parties are aware of the typically generated information –

but not all have actually seen what is available. There is the opportunity to

streamline, in particular summary type information.

Flexibility – due to the range and nature of the projects, any new „system‟

would have to provide an understanding and level of detail, in keeping with

both the individual project and overall summary data requirements.

Company B have recently had a bad experience trying to introduce Primavera‟s P3

planning software. The basic reasons of failure have been put down to server

problems and user competence; however, there will no doubt have been further

factors, such as over complexity, over reliance issues and probably running costs.

This has no doubt contributed to the present „lack of enthusiasm‟ whenever the

subject of „planning‟ is discussed.

There is excellent information already available within the office. The method of

estimating costs and in-house resources is first rate, as is the recently developed

project flow chart. A little „tweaking‟ can provide estimated man-hours for

Company B‟s term contractors. There is a welcome openness to cost and

57

estimation information within the office; though I believe the data could be used

more effectively.

For example, there is no method to view upcoming term-contractor work scope, all

the information is there but requires some investigation. Applying estimation data

to regularly updated programmes provides this type of data simply and effortlessly.

The emerging opinion of a downturn in term-contractor work makes this

information even more critical. Contractors have spoken about redundancies;

resulting in the loss of experience within the workforce should they not return when

work becomes more evident.

Summary reporting exists in a series of spreadsheets across various managers.

Duplication of information is apparent and there is a danger of managers „doing

there own thing‟ if ground rules aren‟t re-established and understood. There is

also a danger of misinformation being generated, as the spreadsheets are updated

manually and independently, rather than from a central source.

The bottom line is therefore, to develop a consistency of reporting based on

regularly updated and resourced programmes. In addition, the introduction of

more up-to-date software promotes a challenge to develop the available data, to

provide a visible and consistently useful information centre.

4 Present Status

When asked, “Do you see the need for planning of your projects?” all those

questioned agreed there was a requirement to have some sort of visibility of how

to execute their projects, however, when asked the question “Do you see the need

for regular updating of the programme?”, a good proportion could not see a direct

positive benefit. Almost all had never seen a resourced programme put to use.

Presently, consensus is that there will be a downturn in work by May/June this

year, yet there is no visible information to confirm this. In fact, most of those

questioned do not understand how this situation has arisen. Whilst there has been

some delay to establishing this years capital spend, budgets are broadly similar to

last year and it is last year‟s projects, which the term contractors should now be

working on.

This is, I believe, the first time this situation has occurred in some years. It is also,

in itself, a major reason why the planning role needs to be re-addressed to develop

58

the visibility that all parties, including term contractors deserve, especially if there

is any possibility of budgets being restricted over the next two to three years.

The underlying impression is that confidence levels are low with respect to the

planning role and this also applies to the planners themselves. The unfortunate

recent experience of trying to introduce Primavera P3, has contributed to the

current state of affairs. Reporting and planning requirements need to be

re-addressed and directed from the top down. Managers, engineers and

co-ordinators mostly see the planning role as simply a required „ad-on‟. Yet all

would like to have access to a programme that provides a view of current status

and forecast of future activities.

Good information already exists within the office and all managers and engineers

are fully familiar with the estimation spreadsheets. The planners however, have

only had access quite recently (within the last month or so). The excellent project

flow chart provides all the steps through; for example, detail design, yet the

co-ordinators can still, at times, faced with some hidden surprises.

As mentioned earlier, summary information exists in a variety of guises, mostly

Excel based spreadsheets which are updated manually. In themselves, this is not

misguided, but taken as a whole represent duplication and more importantly the

opportunity to present misinformation, as the update are not from a central source.

The existing high level reporting tool, the OML Report, is to a large extent,

subjective. Additional information, such as planned versus actual percent

complete and a highlighting of slippage, would direct focus onto problem projects

and having back-up data with respect to status.

The current planning software has now reverted back to Project 98 and includes

an attempt to provide an overall company project overview. Unfortunately, the lack

of consistent regular updates allied with no resource data, has reduced its

effectiveness to not much more than a bit-part roll.

The larger type projects do generally have more detailed programmes. The level

of detail seems to be in line with managers‟ requirements, though the detail for

shutdowns are contradictory with the maintenance department, who provide a

much lower detail programme than change projects. This may well be due to the

seemingly more relaxed attitude towards shutdowns, compared to the

petrochemical industry for instance. This is probably due to the different

processes involved, batch as here in Company B and continuous, as in a refinery.

59

There is however, an ad-hoc approach to updating, usually prompted by the

project manager. The approach to updating should be regular and „active‟, rather

than simply historical and passive. Updating should provide a timely forecast, as

well as gathering data and the project manager should be looking at a current

programme and be able to analyse the results.

Not all those interviewed are familiar with the procurement process. Ordering via

SAP is normally done by one the QS personnel, whilst this is acceptable; it‟s the

expediting of materials that may have a potential problem. For instance realising a

late delivery is going to impact a project and this usually occurs when it‟s too late

to do any corrective action.

5 The Way Forward

The points raised in this section are similar to those presented at the pre-report

review meeting which took place on Thursday 20 February 2003, namely;

Appoint a sponsor and re-establish the ground rules. Put forward clear and

precise requirements from the top down. Re-confirm the project managers

are the owners of their programmes and there is, (or will be), minimum and

consistent reporting requirements. It may well be an idea to select one of

the three business sectors as a trial run;

Re-visit the current „project template‟ to break it down into slightly more

detail. Without over complicating, even the smallest of projects deserves

an understanding of discipline requirements within phases. The

information is known, therefore, it would be wise to use it;

There would also be a recommendation to place additional milestones

within the design phase, in line with the project flow chart. It takes longer

to design a project than it does to construct, yet the forecasting of design

completion dates seems to be by word of mouth, rather than implementing

a system which has a visible understanding of when design packages will

be available;

Introduce the requirement of a regular programme updating procedure,

which should be done ahead of the main monthly project review meeting.

The intention is to discuss only problem projects within the meeting rather

than wasting time going through all projects. It is advisable to ask more

questions when updating, typically;

60

What is the progress in terms of physical progress?

How long is the activity going to take to complete?

Confirm the target-estimated man-hours, re-estimate if required;

What is the procurement status in terms of placing purchase orders and

forecast deliveries?

Are the required resources in place to meet the required programme?

What do we expect to achieve in the next month?

Due to the large number of projects, (50-60 active at any one time)

managers and engineers would be expected to provide updating

information to the planners to allow them time to update via the software.

The long-term aim would be for the managers to update their own

programmes, leaving the planners to concentrate on the larger more

complex ones.

Introduce the requirement for inputting resources into the programmes, as

again this information is known. This brings with it the following:

A double check against the current (and impressive) excel based

forecasting tool, with respect to the in-house resource requirements;

Visibility of site based term contractor resource requirements;

A more rigorous approach to understanding project status would be

possible, in terms of achieved hours and thus percent complete by

project or even phase within project if required;

In the longer term, this could also form a basis of conducting a

productivity analysis across disciplines or phases as required.

Re-visit the development of the various summary spreadsheets presently in

existence. Currently there are three in existence, all containing very similar

information. There has to be an opportunity to stop duplication by looking at

each and developing one source. In any case, the updating of forecast dates

and project status has to be controlled, preferably automatically, from the

programme updates. It may be worthwhile to consider the set-up of a simple

MS Access database that will be open to all.

Many of the points above can be achieved using the currently used software

of Project 98. There are, however, advantages to looking more closely at

Microsoft‟s latest release of Project 2002, see below for more information.

61

6 Software Recommendation

One of the more surprising aspects of this study has been with respect to the

failure of P3 to establish itself within Company B‟s organisation. This unfortunate

experience does not, in itself, necessarily promote the recommendation of different

software. Company X often promotes the use of P3 or SureTrak as they are

generally regarded as the market leaders. Software does not standstill however,

and the recommendation to Company B is to upgrade their current Microsoft

Project 98 software to the newly released Project Professional 2002, combining

this with the Microsoft Project Server.

There are obvious advantages to this, not limited to the following: -

Familiarisation – most parties within the office already have access to Project

98 and a good proportion have „practised‟ using it;

Evolution rather than revolution is the hypothesis here. Project Professional

2002 brings with it stepped improvements over the 98 version, which may not

be readily apparent to the end user, namely: -

The ability to set-up a „company framework‟ that allows direct

interrogation of both individual and groupings of planning and schedule

data. This, in itself, dictates the set-up of standardised coding,

essential for data access;

The introduction of „outline codes‟ offers easier sort and selection

capabilities;

Differing calendar codes can now be applied at activity level, as well as

resource level, which was the only method on the 98 version;

The planner more readily controls resource levelling algorithm and

there is the opportunity to resource level by priority, if required;

The present WBS coding can also be incorporated within the

programme data. This can then be used to transfer dates automatically

to the cost system, providing programme based cash flow analysis;

Project Professional combined with Project Server brings further

capabilities, particularly on the resource management functions, such

as resource pooling and sharing.

Project 2002 also brings with it risk analysis capabilities with respect to schedule

and timing. This feature in itself may offer the opportunity to highlight problem

62

projects early in the project life. This may be unwelcome news, but at least

potential problems are known, quantified with back-up data and can be managed

out.

It is worth pointing out at this early juncture that the introduction of Project 2002

will not be to simply purchase a disc and load the software, the introduction of any

new software has to follow the development of a requirements spec or definition.

This is further progressed by developing the configuration and customising of the

software, testing and proving the software will allow the introduction to a pilot area.

Training should precede a controlled deployment to desktops.

This structured approach to introducing new software, will take away confusion

and tailor the software capability to the maximum customer benefit. The lack of it

may have contributed to the demise of P3.

Throughout discussions, it was becoming increasingly apparent that there was a

lack of visibility, regarding the work being done by contractors on behalf of

Company B. The contractors are used when peak workloads are apparent, due to

the lack of resourced schedules. It is not possible to forecast when the peaks are

likely to occur, however.

There are further considerations to be made, especially when a design or term

contract is about to be awarded: -

What is the governing factor of why a particular project has been

outsourced? Is it simply because we do not have enough internal

resources and taking on this project would create on overload situation?

Can we delay until a later date to meet resource availabilities, or is it

imperative to make a start?

If the answer is simply, because our resources cannot cope then are we

outsourcing the correct project? Do we have a better defined project that

could be outsourced instead? The reasoning here, is that outsourcing a

project with a poor definition of workscope will ultimately cost more than

one, which has workscope more clearly understood.

When a project is outsourced, are we asking for reasonable project

controls to be put in place, providing Company B with the progress visibility

required, promoting confidence of quality and completion status?

63

Programmes are being produced, though none are resourced. In the

future programmes may have to be coded in line with Company B‟s

requirements, to facilitate easy merging and reporting;

We believe updates are only done on an „adhoc‟ basis, rather than

every month;

We recommend that Company B insist on which planning software is to

be used by contractors and that the system is consistent with the

clients‟ own system;

Provide any other reports in keeping with the complexity of the project,

for example, progress S-curves, narrative reports, four week

look-ahead etc.

There are enough points above to add to the discussions already taking place. I

believe an openly known outsourcing strategy would assist all those concerned.

8 Training

Training of the current planning team would come from two aspects, firstly from

Company X‟s Planning Team in Stockton. This would cover the new processes

and methodologies necessary to introduce the revised planning system.

With regard to MSP 2002, training could be from one of several sources i.e.

Company X carry out training, onsite training via distance learning, (including

assessments), this has the advantage of keeping personnel on site, training can

also be offered offsite at a suitable training company.

9 Proposal to Provide Planning and Cost Services

Company X welcome the opportunity to provide the total service, including cost

and planning, we see that there are many benefits to Company B, namely an

integrated team, which will allow cross fertilisation of data, a common WBS / CBS,

one progress measure, one estimate, and allow comparisons of progress

achievement with expended costs.

Informal discussions have taken place with Company B‟s planning engineers and

both have expressed an interest in joining Company X.

The details of how we take over (including the commercial terms) the existing

planning team are the responsibility of Company X‟s Bristol office.

64

10 Report Conclusions

There are no major problems in this report; there are simply a number of areas

where improvements towards project control can be enhanced. Company B could

continue as they are now, with their almost relaxed approach with regard to

planning. There are many positives to be found, the cost and workflow procedures

are second to none within my experience. It is the benefits to maximise the use of

the existing information that this report attempts to explain.

Obviously, there is a balancing act to be achieved. Whilst no one wants to

overcomplicate anything, it is possible to be too simplistic, to remove the

effectiveness and under-utilise the data that all projects naturally generate.

Understanding workscope and getting to the correct level of detail are the most

difficult aspects of planning and only two-way dialogue between planner and

manager can resolve this.

Company B now has the perfect opportunity to introduce the next step to raising

the profile of the planning function. Their recently completed new office not only

affords pleasant working conditions, but also offers the environment of easy

communications and interaction, engineers, designers and those who manage the

construction are not often all found within a few metres of each other.

The proposal of bringing the present planning roles under the Company X banner

provides additional advantages:

Back up of experienced planning team from Stockton Office;

Transfer of pharmaceutical planning knowledge to Company B;

Access to Company X‟s manhour norms / procedures / planning

methodologies;

Training;

Best practice techniques;

Part of Company X‟s commercial team at Company B, Bristol;

Transfer the planning administration and organisational responsibilities

from Company B.

The major target has to be moving towards consistency of project reporting allied

to a regular and meaningful updating regime. Add to this, the benefits of applying

65

resources to the programmes and the results will reflect an understanding of

project status and forecast of requirements. Taken to its conclusion, a view will be

able to be analysed for both internal and external resource requirements.

11 Proposed Implementation Strategy

Detail discussion of recommendations is contained within the various sections on

the report; this section will highlight only the major issues and propose a way

forward to introduce the stated recommendations.

Effective change depends on management levels agreeing with the required aims

prior to starting, stage one is therefore to agree and develop the principles.

STAGE 1 – ESTABLISH GROUND RULES – short-term timeframe of within

one month:

1. Agree the need to move towards a more rigorous approach, in relation to

project reporting;

2. Develop the minimum reporting requirements for both in-house and

outsourced projects;

3. Re-visit the „project template‟ to include a greater level of detail;

4. Formalise updating regime, e.g. monthly, ahead of the review meeting;

5. Develop the method of producing an overview report. Placing all the

projects into a single project is clearly not sensible. A possible approach

could be to split projects into their business areas and utilise Excel, to

produce a combined view of resources;

6. Accept the need to raise the awareness of the planning role;

7. Develop an initial method of applying resources to programmes;

8. Appoint sponsor;

9. Agree to migrate from MSP 98 to 2002;

10. Transfer planners to Company X with commercial approval form

Company B.

STAGE 2 –PROJECT 2002 IMPLEMENTATION STRATEGY - medium terms of

two to three months:

66

1. Develop system project control specification and requirements. This will

include coding and reporting requirements, as well as customisation and

integration to existing systems;

2. Develop and review software costs, including training requirements;

3. Develop an implementation programme;

4. Purchase, develop and test, via an „evaluation kit‟, if possible;

5. Prove concept and run pilot area;

6. Decide to progress with software deployment.

STAGE 3 – INTRODUCTION & CONSOLIDATION – medium to long term –

three to six months:

1. Rollout Project 2002 to all users, complete with one-on-one training, if

required.

2. Post implementation review, re-assess success areas and learn lessons for

the next deployment, if required.

Company X can offer the services of „facilitator‟ between the various personnel

and departments. It as envisaged the role would be full-time for a period of three

to four weeks, to establish a basis of understanding of the objectives. After this,

only a part-time involvement would be required, to implement the

recommendations agreed by Company B‟s management.

In order that the changes are introduced, it is necessary to have a sponsor from

Company B, these needs to be senior person within the Company B management,

who can take action if non-compliance to the changes was an issue.

The above does not represent anything that cannot be attained within

approximately six months. Evolution, rather than revolution, provides consistency

and continuity that an international company with the reputation of Company B

demands.

The author would like to again thank all those who gave up their valuable time in

contributing to this review paper.

67

4.3 Company C Report

Company C requested that my company review the current methodology of

controlling cost and time within a portfolio of road construction projects.

The report indicates the findings and recommendations to improve project

controls.

68


On Application of an Enterprise System

30 March 2005

69

Contents

1. Executive Summary

2. Introduction

3. Report Approach

4. Present Position

4.1 Internal Controls

4.2 Consultants

4.3 Contractors

4.4 Overall

5. Pilot Study

5.1 Costs

5.2 Summary

5.3 Programme Management

6. Recommendations

7. Enterprise Project Management Software

8. Training

9. Costs

10. Conclusions

11. Way Forward

List of Figures

Fig1 HA Project Flowchart

Fig2 TPI Reporting Spreadsheet Sample

Fig3 The Current System

Fig4 Pilot Study EPS

Fig5 Pilot Study OBS

Fig6 Pilot Study WBS

Fig7 P3e Gant Chart

Fig8 P3e Tracking

Fig9 Interim System

Fig10 Final System

70

1. Executive Summary

Report Approach

This report has been developed with Company C assistance, team leaders, project

sponsors, CFADS contractors and consultants, along with Company X‟s project

control experience. The main objective of the pilot study was to determine the

feasibility of creating a portfolio of projects, from the myriad of different approaches

to project planning and cost forecasting.

Present Position

Contracts are of an ECC type, where the consultants and contractors have free

reign of the planning tools and methodologies

Internal controls

There is budgetary control of work provided by the CASCADE system, an

in-house financial recording database, and Microsoft Project (MSP) is currently

available. Once the project is in the control of the consultant and employer‟s agent

there is little in-house monitoring, and even less consistency, other than progress

indication via the TPI sheets. The monitoring is the responsibility of the consultant

and then the consultant acting as employer‟s agent. Source: Company C TPI

reporting excel spreadsheet. The employers agent is in a position to monitor the

contractor as well as other duties; there is however little confidence that this is

done effectively. Favouring ASTA PowerProject for its construction bias and

graphical capabilities, the contractors in general, effectively monitor and drive

projects by the plan; it is in their interests to be efficient.

Pilot Study

In the creation of the pilot programme an enterprise project structure was created.

Programmes were imported from consultants and contractors, the lack of a

consistent structure meant it was necessary to develop a WBS to allow

comparison. Tracking and progress monitoring can be done at a high level or at a

grass roots level, the earned value, projected costs and monthly projections are

available at the touch of a button. This system combines all present parallel

packages into a concise work envelope; monthly and annual budgets can be

71

monitored against accruals and progress to give earned value information, SPI and

CPI.

Recommendations

Contracts and briefs should be amended to include the project controls system

and reporting requirements and a defined WBS structure attached. There is no

existing software in Company C that can handle a portfolio of projects and a move

to an Enterprise project management tool, as discussed in the coming section. A

total shift to Primavera is recommended with contractors and consultants utilising

Primavera Contractor or similar, to draw information in and pass up to a hub in

Company C, integrating with Cascade, for a full accounting capability. We believe

as a result of improved visibility, monitoring and staff accountability through an

Enterprise system, there could be savings of between 5 and 10% per annum.

Training

It is recommended that all project sponsors are trained in project controls, for

most, one would assume this is refresher training. It is also recommended that

project sponsors undergo Primavera P3e training to advanced level regardless of

the level they are anticipated to use the system to; it is considered that any lesser

training would make the system vulnerable to poor manipulation. The training

requirements for the consultants and contractors are varied as their resources are

unknown.

Way forward

Enterprise system costs are discussed and a way forward is proposed in the main

body of the report; see section 17.

2. Introduction

Company C, established in 1994, is an executive agency of the Department for

Transport. The Secretary of State is responsible for overall Government policy on

motorways and trunk roads in England and determining the strategic framework

and the financial resources within which it operates.

Company C‟s purpose is to provide safe and reliable long distance journeys on

strategic national routes by managing the traffic using roads as well as

http://www.dft.gov.uk/

http://www.dft.gov.uk/

72

administering the network as a public asset. The English strategic road network is

valued at over £65bn and comprises some 5,130 miles / 8,255km of trunk roads

including motorways. The major projects division handles construction projects

and high value maintenance, over £5m. This project was instigated by and

focuses upon the Major Projects Division. Following a business report from

Medley and a Government drive to increase efficiency within its agencies, the

need for a further project controls review was apparent. Following a meeting on

the 25 January 2005 between Company C and Company X a project was

embarked upon to investigate the possible application of a portfolio / Enterprise

management tool. Deliverables were defined as:

Pilot programme to be developed in Primavera P3e, with the following

objectives:

o Focus on high level management, but include draw from front end

information to provide an effective communication with the client;

o To demonstrate system capabilities and the power of an effective

enterprise package to Company C‟s board;

o Illustrate in familiar terms and projects the effective and efficient

handling of portfolio projects for effective management and reporting;

o Improve cost and time management for project work.

Research, review develop and agree WBS coding for ease of data

collation;

Review current planning and progress reporting systems;

Develop finalised report with recommendations for improvement;

Ensure a constant thread of communication is maintained with the project

sponsor and provide regular review meetings.

The findings enclosed in this report, along with project controls awareness, are to

be presented to Company C early April 2005. This report is intended for senior

management of Company C

3. Report Approach

This report has been developed with Company C‟s assistance, team leaders,

project sponsors, CFADS contractors and consultants, along with Company X‟s

project control experience. Understanding the process and information flows

within Company C‟s structure and procedures, their development over time and

73

the current philosophy allowed for a full understanding and professional review.

Company X thanks all contributors in this process of rapid learning. The key aim

of the pilot study was the collation of existing projects into a single Enterprise

package; extensive experience of planning packages was a prerequisite to enable

integration of individual projects into a portfolio scenario. It was also required, that

forecast costs were to be applied to the programmes with the ability to roll up all

forecast costs to a total forecast cost curve / table, that could be viewed and „what

if‟ scenarios developed.

4. Present position

Following many changes over the life of Company C and its previous guises there

are many projects that carry legacies of previous systems. It is therefore worth

taking note, that Company C was formed in its present state in 1994, some

projects have been in process for some 30 years. The work flow in the present

system is illustrated in figure 1, overleaf.

There have been many previous contracts and philosophies in work flow and

subcontractor involvement, varying contractually within the ECC form in recent

years from:

In house design and contractor tendering on a construction basis, held

under an ECC type A contract, with contractors selected by a mix of quality

and value;

In-house design through public consultation and early design and build

inclusion of the contractor through an ECC type C contract, with

contractors selected on a schedule of rates and quality;

Early contractor involvement, the most recent initiative whereby contractors

are brought in for the earliest stages of design. The contract for this format

is ECC type C ECI, where the contractors and associated consultants are

selected from a predefined listing, CFADS; they are selected on 100%

quality.

At present there are many complementary / parallel systems in operation, there is

little confidence in the consistency of information, especially with the quantity of

manual updates from system to system. The flow chart, figure 1, overleaf shows

the present position

74

Fig1: Company C project flow chart

75

4.1 Internal controls

There are a set of deliverables to be met prior to any consultant

commencing work and long before TPI entry. These are purely

deliverables with a possible end date that would facilitate TPI entry, there

are no pre defined durations or responsibilities. There is no programme of

work created in most teams at this stage; however, there are sure to be

exceptions.

This stage of work is also infrequent as projects may have a life spanning

decades, it can also be somewhat disjointed due to ministerial and

budgetary halting and similar. There is budgetary control of work provided

by the CASCADE system, an in-house financial recording database, and

Microsoft Project (MSP) is currently available. Once the project is in the

control of the consultant and employers agent, there is little in-house

monitoring, and even less consistency, other than progress indication via

the TPI sheets; the TPI system being a 100 point, 32 entity (weighted)

system to indicate progress and report when sections are complete and

claim funding accordingly. An example section taken from a TPI sheet is

shown in figure 2, overleaf.

The monitoring is the responsibility of the consultant and then the

consultant acting as employer‟s agent. The general duties of the

consultant are project specific and, to a point, team specific as there are

sections of work that can be held within Company C or delegated.

Individual and overall monitoring is attempted predominantly in Excel with

manual input, update and transfer. The result being a labour intensive

system that is prone to errors.

76

Fig2: TPI Reporting Spreadsheet Sample

Source: Company C TPI reporting Excel Spreadsheet

Uniformity has been achieved in recent times within the TPI sheets;

however data is from a myriad of packages and inputted manually with no

set access rights.

4.2 Consultants

The role of the consultant, in the early stages, is to act on behalf of

Company C in the surveying, design, economics and „in confidence‟ works.

In general, consultants also have available MSP, however the general

consensus, even within some consultants, is that it is not used effectively

for progress monitoring and some of the consultants interviewed seemed to

have little knowledge of progress monitoring in this regard, however, other

consultants are very capable at progress monitoring, but due to „budgetary

constraints‟ they limit the monitoring.

Once there is a contractor allocated to the project, the role of the consultant

shifts to that of employer‟s agent; there is occasionally a change of

consultant at this stage, depending on CFADS group requirements. The

employer‟s agent is in a position to monitor the contractor as well as other

duties; there is, however, little confidence that this is done effectively on a

KEY PROJECT EVENTS

Po

ints

Pa

st

Ac

hie

ved

in Y

ea

r

Ba

selin

e

in Y

ea

r

Ac

hie

ved

in Y

ea

r

Fo

reca

st

Fu

ture

Fo

reca

st

ACHIEVED (MM/YY)

F/CAST (MM/YY)

HA Commissioned/Project Commencement 1 Jun-03

Strategic Assessment Complete (LGC 0) 1

Consultant Selected and Briefed 1

Public Consultation options selected 1

Value Management Completed 1

Reports and Estimates Approved 1

Business Case Approved (OGC1) 1

Procurement Strategy Confirmed (OGC2) 1 Sep-03

Public Consultation Start 2

ECI Tenders Invited 1 01/07/03 Single

Tender Assessment Completed 1

Preferred Route Selected 3

DfT / Ministerial Approval 2Preferred Route Announcement 2

Value Engineering Completed 4

Investment Decision Confirmed (OGC3) 2 Sep-03

ECI Contract Awarded 3 Aug-03

Preliminary Designs & Consultations completed 3

Reports and Estimates Approved 3

Stage 3 Assessment Report approved 3

Draft Orders and ES Published (OGC 3A) 5

End of Objection Period 3

PI Notice Issued 3

Public Inquiry Start 4

Post Inquiry Risk Assessment Completed 2

Imspector's Report Received 2

Secretary of State's Decision Announced 2

Orders Made 2

End of High Court Challenge Period 2

Works Price Reviewed/Confirmed (OGC3B) 2

Works Commitment Approval 2

Notices to Treat and Enter Served 1

Land Entry Secures 1

Start of Works 1 Oct-03

Road Opened 26 Dec-04

Business Confirms Readiness for Service (OGC4) 1 Spring-05

Handed into Maintenance 1

Noise Appeals Completed 1

First Pt 1 Claims Notice Published 1

Maintenance Certificate Issued 1

Benefits Evaluation Review Complete (OGC5) 0

Financially Closed 0

PROGRESS 100 0 0 0 0 0AGREED

TARGETFORECAST

Start of Year (Achieved in preceeding Year)

Current Position

End of Year (March)

TOTAL N/A N/A

IN-YEAR BUDGET CONTROL (excluding Land)

In-Year Budget (Fixed for Year) - [C]

Last Month's FYF - [D]

This Month's FYF - [E]

In-Month Variance - [E-D]

Variance to Budget - [C-E]

TOTAL PROJECT EXPENDITURE (excluding Land)

Historical Spend (post Apr 01/TPI entry)

In- Year Spend

Future Years Spend

TOTAL

30.500

26.863

28.862

1.999

53.020

AMOUNT £m

18.617

5.541

28.862

1.638

AMOUNT £m

77

project planning basis. The agents in general, utilise different packages,

also through interview it was apparent that some reported information

directly from the contractors‟ programmes and some carried out reviews of

the logic at regular intervals. These consultants tended to have a higher

level of understanding of project controls whilst some have contract

specialists in their employ, however it was not feasible to produce a

thorough base lined programme, that would be used to monitor the

contractors programme and to verify progress. This is not to say that the

employer‟s agents do not fulfil their brief, it is more reasonable to say they

do not use project control methodology to monitor the cost and schedule

performance of the contractor to full effect.

4.3 Contractors

Favouring ASTA PowerProject for its construction bias and graphical

capabilities, the contractors in general, effectively monitor and drive

projects by the plan. There is, on the whole a capability, however not

exploited to provide earned value information. Currently such information

is seldom provided, however, some project sponsors are more aware of the

power available and request information of this level. There is no set WBS

structure in the contract provided and as such the contractors programme

is purely the route to the deliverables, it is acknowledged by the contractors

that it would be easier for reporting and internal comparison if there were a

more rigid structure provided. It is also understood that with the shift to

ECI, there was a reduction in the structure provided to the contractors. Not

all contractors use ASTA, with some utilising MSP. It is worth mentioning

that there are fundamental and potentially problematic differences in ASTA,

it uses different algorithms and as such, allows what could be termed as

„bad practice‟, such as logic loops. ASTA would be well described as a

scheduling tool rather than a planning tool, depending on how it is utilised.

It is also worth remembering that a poor tool used well is more powerful

than a good tool used badly! The current system for information flow and

systems usage is shown in figure 3 over leaf.

Fig3: The Current System

78

4.4 Overall

Within Company C, in general, the project leaders transfer ownership to the

employer‟s agent, thus acting more as project sponsors. The monitoring

and financial decisions within Company C are made from TPI progress,

monthly spend and annual budget achievement, backed up by a TPI points

target for the year. The minority of project leaders who act as project

managers obtain schedule and cost performance information, and often

build spreadsheets on which to monitor progress, additional to cost and

reporting spreadsheets. The consultants have also a wide spread of

capability on the project controls side with some having no knowledge of

using baselines and other simple practices to monitor work, it is no surprise

to report that it is these consultants, who while working as employers

agents, have little physical and logical checking of contractors plans.

Again, the other extreme is the consultant who monitor themselves as

efficiently as possible within the budget. It is realistic to say that the spread

of capabilities is as a result of the lack of definition in the brief and

subsequent contracts. The contractors‟ capabilities are more uniform, to a

suitably high level, however, not targeted to the reporting which would be

considered desirable; their favoured package is chosen on a cost and

capability basis and would possibly not be considered ideal for the

reporting desired. Again, there is no definition within the contract and the

Company C

79

contractor plans / schedules his work to ensure completion, not to report to

Company C‟s TPI or defined deliverables.

5. Pilot Study

The industry standard planning software, Primavera P3e was chosen for the study,

various other corporations also use the software. The package could be described

as an Enterprise Planning tool. Previous planning systems have been used to

good effect on high value portfolio projects, including the predecessor to

Primavera P3e; P3, in fact Primavera P3 was sighted as the best planning tool on

the market in an independent study carried out by NASA, (available on the World

Wide Web), prior to the development of Primavera P3e. The Enterprise capability

of P3e means it is now built around portfolio projects, but more over, is also built to

take in the entire business structure. In the creation of the pilot programme an

Enterprise Project Structure was created see below:

Fig 4 Pilot Study EPS

This is essentially the structure of the organisation, it can be as detailed as

required, and for the pilot study a brief high level approach was maintained,

80

including only major projects, northern area. It is used to allow summaries and

reporting by areas and to set access limits, if required. The organisational break

down structure for the associated area was also included; this is the „Family Tree‟

for the organisation, allowing the „pick list‟ for assigning responsible managers, or

in Company C terms, project leaders; illustrated below.

Fig 5 Pilot Study OBS

Another grouping technique can also be installed, which is a portfolio. A good use

for a portfolio would be a road such as the A1, where it crosses areas and teams,

a portfolio would collate all of the projects into one group and allow for clear

overviews and progress. Programmes were imported from consultants and

contractors alike, the lack of a consistent structure meant it was necessary to

develop a WBS to allow comparison. See recommendations section. The WBS

has further validation to undertake, prior to full time use. Two Levels are shown

overleaf:

81

Fig 6 Pilot Study WBS

From the various subcontractor packages, programmes were imported, for the

pilot they were converted into the WBS, if implemented they should arrive in an

appropriate WBS and updates should be provided on a regular basis, also in the

WBS. Included below are screen shots of the overview Gant charts.

82

Fig 7 P3e Gant Chart

5.1 Costs

Where costs were available they were installed, along with actual costs;

this allows the system to automatically generate earned value reports and

accruals. This could be set against a spending plan for true budgetary

control of the project environment.

Tracking and progress monitoring can be done at a high level or at a grass

roots level, the earned value, projected costs and monthly projections are

available at the touch of a button. Comparative and composite views are

available

83

Fig 8 P3e Tracking

Further uses are the installation of critical resources, that way the workload

can be assured and delays avoided. Other outputs include presentation

quality graphical exports, charts and integration with other database

software.

5.2 Summary

This system combines all present parallel packages into a concise work

envelope; monthly and annual budgets can be monitored against accruals

and progress to give earned value information and much more. The

financial, progress management and executive reporting and interrogation

should ease the workload on area teams, reduce input errors and report

directly or via cascade, by data links to envelope the full project and cost

management.

5.3 Programme Management

The system enables programme management to be implemented and

allows; a forward capital programme to be created, all projects managed

84

within funds available, a prioritisation process with projects aligned to

strategic objectives and a co-ordinated reporting system.

6. Recommendations

1. Company C agree to move forward to a more rigorous approach to

project controls using P3e software;

The current systems lack structure and a co-ordinated view, reducing

visibility of data and limit the effectiveness of tracking and budget controls.

A move to a portfolio project planning package will rectify this.

2. Develop and agree WBS / Coding Structures (client & contractors);

WBS structure should be agreed. It is suggested that the pilot WBS be

used for the basis of further works, it can be enhanced and WBS

milestones set, for key data such as TPI progress data. The WBS is the

backbone of successful project controls

3. PM’s / projects sponsors trained in effective project controls;

It will be necessary to train current staff in project controls; this would

assure a standardised approach.

4. Contractors briefed in requirements to support Company C ITT –

contract documents amended to suit;

Contracts should be amended to include the project controls system

and reporting requirements and a defined WBS structure attached.

5. Procedures for effective project controls to be developed;

To extract the best from the system a set of procedures for schedule

development, updating, change control, reporting etc. to encompass the

whole works.

85

6. Raise awareness of the project controls role;

The change to a more rigorous approach to project controls will be a major

cultural change and regular forums with staff will be required. The forums

will advise staff of the aims of an effective system.

7. Introduce a project controls resource to oversee implementation;

Such a resource would carry the experience to ensure a smooth change

over and ensure the installation and translation of the information was

successful. This resource would also be a valued asset in the ongoing

learning for existing Company C personnel. This resource would also

reduce the stress placed on teams around the TPI reporting.

8. Reporting via SPI, CPI & earned value;

It is recommended that earned value or schedule and cost performance, be

used as a measure of progress rather than „Spend against budget.‟

9. Integration of Enterpise package with CASCADE;

It will be necessary to review the outputs of cascade and align P3e to

Oracle and Cascade systems; this assumes that Cascade will remain

the financial reporting tool.

7. Enterprise Project Management Software

Currently Company C has Microsoft Project 1998 installed, consultants

also favour this package for its apparently user friendly interface and low

price. It is commonly accepted that the older versions of MSP such as this

are „below par‟ for complex planning methodologies, also because of the

Microsoft GUI (Graphical User Interface) it is believed easy to use. The

package driven by a user without appropriate experience, however, can be

very problematic.

The latest version of MSP 2003 Professional is an Enterprise system

however, Company X are not recommending a shift to this package;

although it can handle the portfolio of projects it has limitations and

Primavera P3e surpasses it in many aspects, importantly MSP2003 lags

86

behind its competitors in resource and cost reporting. Other limitations are

the communications with Oracle systems and the poor technical support

available from Microsoft.

ASTA, favoured by the construction sector, mainly for its graphical

capabilities is evolving to handle portfolio projects, however it utilises

algorithms that could be categorised as deviating from the fundamental

views on project planning, this methodology makes critical path analysis a

harder task. Also ASTA is not designed to work around a traditional WBS

structure, thus creating problems in the comparability of programmes.

The recommendation is that Primavera P3e is installed in a phased

implementation.

Primavera is a continually developing programme that can communicate

with other Oracle databases and thus full integration is possible, integration

with CASCADE would provide a full accounting capability taking monthly

budgets and accruals from P3e. Primavera P3e was developed in

association with SAP and with influence from Microsoft. It can draw in from

MSP and ASTA among many other planning systems. Importantly P3e

allows for a traditional WBS to be formed and even resource sharing, so

critical resources can be seen across the board. An interim system utilising

existing consultant and subcontractor packages is displayed as an interim

system in figure 9.

Ideally, a long term objective of a total shift to Primavera is recommended

with contractors and consultants utilising Primavera Contractor or similar,

to draw information in and pass up to a hub in Company C. Although it is

possible to fully automate this installation, it is suggested that a planning

representative is employed to ensure the smooth transfer of information.

This work system is illustrated in figure 10, as a final system.

87

Fig9: Interim System

88

Fig10: Final System

89

8. Training

It is recommended that all Company C project sponsors are trained in project

controls, for most, one would assume this is refresher training. It is also

recommended that project sponsors undergo Primavera P3e training to advanced

level, regardless of the level they are anticipated to use the system to; it is

considered that any lesser training would make the system vulnerable to poor

manipulation.

The training requirements for the consultants and contractors are varied as their

resources are unknown. This would be their responsibility.

9. Costs

Enterprise system costs are:

P3e £2,430+VAT per License

Primavera Charts £280+VAT per license

Primavera Chart Developer £580+VAT per license

Training Costs:

Training £480+VAT per day for 6 people:

Courses are tailored to suite client‟s requirements. Courses available

include:

Project Planning,

Primavera P3e,

Primavera P3e advanced,

Report development,

Importing and structuring of programmes,

Risk.

And many more covering all aspects of project management and planning.

Server costs:

90

These costs vary massively due to the band width requirements and

requirements if the server is required to be a stand alone server, or

combined in an existing server. A guide price is £7k + installation + setup.

Additional:

It is recommended that an ORACLE and JAVA specialist is employed on

an ad-hoc basis to ensure full empowerment and exploitation of the

system.

10. Conclusions

The current system and processes used by Company C to manage project

controls, (planning, cost forecasting and monitoring) are insufficient to allow

effective management of a portfolio of projects.

There is a need to move over to a system and processes which allows an

improvement to how projects are managed within funds available, by a

co-ordinated reporting system, planning process and aligned to strategic plans.

We would propose that the Primavera P3e system is implemented in the North

region, initially to demonstrate how improvement can be realised.

The system allows the plan and the costs to be aligned, „what if‟ scenarios can be

readily generated; earned value curves developed and all presented by a

professional reporting tool in P3e. This allows management visibility of a portfolio

of projects on an ongoing basis and allows decisions to be made on the basis of

factual and dynamic data.

Any variation in the schedule and costs can be identified early and corrective

action put in place, to recover programme slippage and projected cost overruns.

The resulting impact of these revised systems would provide an informed

programme, delivering better cost forecasting and control; ultimately cost savings

would be realised as a result of better controls and increased accountability, an

anticipated annual saving of around 5 to 10 % could be made.

91

Integration, through an oracle interface, with CASCADE would provide the link

between the P3e project accruals, progress and monthly budgets with Cascades

“actual spend” to provide a full accounting solution to the portfolio.

11. Way Forward

Phase I 0 – 6 months;

• Agree to move to P3e;

• Set up project controls department;

• Define project scope;

• Develop robust plans / cost estimates;

• Develop WBS / coding structures;

• Contractor buy in / education;

• Develop master schedule (all project);

• Initiate contractual changes;

• Commence P. C. Training for Company C;

• Start reporting SPI & CPI.

Phase II 7 – 12 months;

• Continue training;

• Develop procedures;

• Standardise systems;

• Test system & fine tune.

Phase III 13 – 20 months

• Handover to Company C;

• Monitor works;

• Get buy in from other areas.

92

5 Commentary and Contextualisation of all results/findings

5.1 Overview

The commentary will contextualise and link the relevant reports from real life client

reviews / audits. The questionnaire results, the literature review of project

controls, tacit knowledge and cultural aspects.

The commentary will compare the findings and results of the above work and link

them by areas of project controls and the various industries. This will allow a

determination of correlation between the different pieces of work carried out. It will

also establish if there is a common thread of understanding of methods to improve

processes of project control, by analysis of the three pieces of work. These

improved methods will take the form of road maps, which identify improved

processes and procedures

The following chart 5.1 illustrates the interfaces between the various pieces of

work that form the contextualisation process:

Fig 5.1 Contextualisation Chart

5.2 Planning / Schedule Control

The questionnaire results indicated that 14% of companies interviewed advised

that control of projects was impaired, as a result of ineffective planning. It was

93

also noted that only 51% of companies indicated that planning was taking place on

a regular basis.

The main comments and areas of improvements recommended by the

questionnaire recipients were:

5.2.1 Schedule Control – How it could be improved

a) Clients relied upon high level schedule from contractors;

b) Recommend that multi-dimensional planning is used;

c) Lump sum contract, therefore client only given high level schedule;

d) Lack of buy-in across the whole industry;

e) Better definition of scope required from engineering;

f) Failure to baseline plans;

g) Plans not used to drive projects, culture of business incorrect;

h) Not all projects covered by plans;

i) Lack of detail within schedule;

j) Lack of logic links within schedule;

k) Failure to regularly review schedule content;

l) Lack of professional planning engineers.

5.2.2 Co-ordination and Critical Path Planning

i) Failure to baseline schedule;

ii) Failure to manage contractors‟ plans;

iii) Client more interested in controlling costs, fails to control time / schedule;

iv) Failure of project managers to own plan;

v) Better training for project managers;

vi) Contractor using different / inferior systems to client;

vii) Development of procedures to standardise approach.

5.2.3 Forecasting Completion Dates

a) Change control not approved which makes forecasting difficult;

b) Poor reporting processes;

c) Wrong planning software used to forecast;

d) Insufficient planning resources to support forecasting data;

e) Culture of business is preventing accurate forecasting data;

f) Additional training for project managers;

94

g) Lack of senior management buy-in.

5.3 Key observations from the questionnaire

The planning engineer usually reports to the project manager, there are a

significant number of occasions which suggest that project managers lack training

in planning and project controls. If lack of understanding of the project control

process is apparent, then the planning engineer will have difficulties getting across

the benefits and advantages of such systems and project delivery will suffer.

Use of the incorrect planning software is a common reason for effective control.

Clients leave planning to contractors and have a hands off approach. Contractors

however, have different drivers to owners, their key driver is to maximise returns

for their business and / or stakeholders. This can have the effect of schedules

being developed and skewed to maximise returns, without totally reflecting clients‟

milestones and needs.

The questionnaire results are consistent with the real life studies / audit carried out

with Company A, Company B and Company C.

The survey of the Company B facility indentified that in an environment where up

to 60 – 70 projects were being managed at any one time, project planning was

poorly managed. Microsoft Project was being used by some project managers,

whilst other managers used Excel spreadsheets to develop project schedules.

Updating of schedules was done on an „adhoc‟ basis with no regular cut-off for

progress measurement being adhered to. The impact of this methodology was

that the senior project manager was unable to determine, from analysis, what the

status was of each project at any given time, (e.g. month end). Also there was

only a given resource availability by trade or discipline and the senior project

manager was not aware if he had enough to support the work, or too many. The

way forward for Company B was to implement a schedule development process

that captured all 60 – 70 projects with a common planning software tool and due to

the culture of the organisation, it was agreed to use Microsoft Project. Robust

accurate and meaningful schedules were then developed for all of the projects with

resource requirements and manhour estimates identified and incorporated into the

schedules. This then allowed a portfolio planning tool to be developed, which

allowed total resource requirement for all projects to be determined. A progress

measurement system was then initiated, which portrayed progress at activity level

95

for each project. The progress was reviewed at a weekly or monthly meeting and

issues, concerns and actions were addressed to ensure project delivery was

maintained and / or corrective action put in place for recovery.

Similar issues were observed within the Company C‟s transport planning

processes. The current operating process at the time of the study in 2005 / 2006

was to control projects via a milestone achievement list that was updated on a

monthly basis. The list did not carry dates of when milestones should be carried

out / achieved; therefore it merely monitored events and played no realistic part in

managing the delivery of projects. As projects were approved for design and

construction they were handed over to consultants and employers agents to

implement the scheme / develop. Once the project was in the hands of the

consultant and employers agent, there was little Company C monitoring, other

than the passive milestone monitoring sheets. The cost forecast and actual

expenditure are monitored on Excel spreadsheets by Company C‟s project

managers; however, little or no determination of project delivery via a schedule is

attempted.

The role of the consultants in the early stages is to act on behalf of Company C in

the surveying, design, economics and in „confidence‟ works. In general the

consultant used Microsoft Project software; however, the general view was it was

not used effectively for progress measurement. Of more concern was that many

of the consultants were not aware of the benefits and need to carry out progress

measurement.

The employer‟s agent was also found to be less than effective with regards to

project planning. The employer‟s agent used a wide variety of planning software

and many used information received from the contractors. Although employer‟s

agents had an understanding of project controls, the basics of determining a

baseline schedule and monitor and report progress achievement, on a regular

basis were not apparent.

The contractors involved in the design and construction phases had an interest in

the need to have effective planning in place; however, it was observed that there

was no recognised WBS, or reporting structure. Contractors used a variety of

software to develop their plans. The survey of Company A indicates similar issues

with regards to project planning.

96

The survey indicates that there was no standard approach, with some 20+

planning engineers engaged in the works, a large inconsistency of approach was

observed.

Examples of this were:-

No standard use of a WBS;

WBS not aligned to the CBS (Cost Breakdown Structure);

Only 50% of the planning used baseline planning techniques;

Inconsistencies in progress measurement techniques;

Only 50% of the planning team applied resources to the schedules;

Standard activity and resource were not applied across the site;

Only 25% of the planning team utilised resource levelling techniques;

Little involvement by the planning team to advise contractors in the Invitation to

Tender stage, of requirement in the contract for schedule development,

software systems and control.

5.3.1 Cost Estimating

The survey and questionnaire results indicated that only 46% of the companies

surveyed followed best practice processes. Results of the survey also indicated

9% of the sample stated that poor control of cost and estimating was impairing

controls.

Comments from the surveyed companies included:-

Processes to be improved to align the best practices;

Require logic links between cost accounts and construction;

Procedures not aligned between cost and planning;

Benchmark previous projects and develop norms;

Central estimating with benchmarking was recommended;

Align cost forecast to schedule;

Analysis of actual costs to improve forecasts in the future;

Estimates not aligned to contractor‟s submitted estimates.

Similar issues were discovered with Company A, whereby there was no strict

procedure with regards to the basis of the estimate.

97

Also at Company A there was no relationship between the WBS / CBS and the

method of estimating. There was therefore, no connection between the planning

system cost control and estimating process. The impact of this was a lack of

control with which to compare estimates, cost control and progress of the plan.

Estimates were not reviewed to reflect change management processes.

5.3.2 Cost Control

Comments for the questionnaire included the following:-

a) Lack of change control system impacts the cost forecast;

b) Impacted control could be achieved by regular reviews of change;

c) System works well, cost and planning engineers integrated;

d) Wrong skill resource managing cost control.

Similar issues were determined in the clients review reports and these included:-

i) Lack of consistent cost reporting system;

ii) Reports not aligned to a WBS / CBS;

iii) Better collaboration between cost and planning engineers;

iv) The need for a change control procedure;

v) Recommendation to carry out periodic audits of cost control system;

vi) Recommendation to include risk analysis within the cost management

process;

vii) The need to have a systematic procedure to manage cost control.

5.3.3 Change Control

The review from the questionnaire indicated that 54% of companies used a

change control process, to monitor capital cost and schedule changes. It is

necessary to capture changes, in order that the schedule reflects the true scope of

work and the cost forecast is based upon the scope of work including agreed

changes. Although 54% did use change control, it is also a fact that 46% of

companies only used change control sometimes, or when necessary.

Comments from companies who took part in the questionnaire included:-

i) The need for a change control procedure, including a tracking register;

98

ii) Change control process only tracks changes to costs, planning / schedule

changes not included;

iii) The need to improve change control processes;

iv) System is only partially implemented.

There is a close correlation between the questionnaire findings and the audit

review at Company A.

Company A‟s planning team‟s audit identified that only 50% of the planning

engineers captured changes in the schedule. The cost engineers reviewed during

the audit also advised that although a procedure was being implemented, not all

cost engineers captured and tracked changes.

5.3.4 Reporting of Progress at Project Level

Methods to improve reporting were asked of the respondents and the following

summarises the findings:-

i) Cost and planning reports using different cut off dates, therefore unable to

compare cost versus plan;

ii) Too much detail included in the report;

iii) Not all projects covered by the report;

iv) No reporting procedure in place;

v) Information from the reports was not analysed or used to improve

performance;

vi) Reporting process needs more automation and integration between the

various control disciplines.

It is interesting to note from the questionnaire results indicated that only 49% of the

companies interviewed consistently used a reporting structure, 40% of companies

carried out intermittent progress reporting and 8% of interviewees advised that

control was impaired as a result of inadequate reporting.

Similar concerns were identified in the questionnaire observations, e.g. Company

A‟s report indentified that although there was an element of reporting, there was no

procedure in place and reporting was carried out in an ad-hoc way.

The managers were using different forms of spread sheets to report progress of

individual projects and duplication of information was apparent. The

99

recommendation of the audit team was that a central source of capturing the

progress information should be established and a progress reporting procedure be

put in place.

6 Summary of Findings and Recommendations

6.1 Planning and Schedule Control

The questionnaire results indicated that 14% of project delivery was impaired by

lack of control and that 49% of project planning was only taking place on an

ad-hoc basis.

The questionnaire results were in common with findings at Company A, Company

B and Company C, where it was established that poor planning was inherent in the

facilitator. These observations are in line with (Shub, Bard & Globerson 2005).

(Globerson & Zwikael et al) who indicated that it is widely recognised that planning

and monitoring plays a major part as the cause of project failures. (Oden &

Battainech 2002) also advised that improper planning was one of the major

reasons why projects failed.

Key observations from survey and questionnaire are:-

a) Better training for project managers in the planning techniques;

b) Clients relying on high level plans from contractors and failure to manage

the contractors‟ plans;

c) Failure to baseline/agree plans;

d) Failure to cover all projects in the planning process;

e) Lack of professional planners;

f) No standard procedures available to maintain an acceptable approach to

planning.

Lack of experience in project managers, with regards to effective planning and

controls, is a key factor with regards to failure to control the project. A study of

project mangers by (Jiang and Klein 2000), revealed that project effectiveness was

impacted by two major risks:-

a) The teams lack of general expertise among team members;

b) Lack of clear role for team members.

100

A further study was undertaken a year later, when project management institute

members were surveyed and re-confirmed the crucial role of the project manager

is project success, implying that companies should involve their project managers

as early as possible, (Jiang, Klein & Chen 2001).

It is fundamental therefore, that the project manager is qualified with the right level

of skills to enable him to establish and understand control systems, that ensure

project success.

(Rozenes, Vitner & Spraggett 2006) indentified the following factors that affected

the success of a project:-

Project control systems;

Project mission and goals should be well defined;

Total management support;

A detailed project planning system that covers the total project client

consultation and acceptance, during the project life cycle;

Competent project team members that supports project aims and objectives;

Technical abilities of the project team;

Project team should have trouble shooting capabilities;

Collaboration between owner and project manager;

The project manager should have the flexibility to deal with uncertainty;

The project owner should take an interest in the project performance.

The issue of clients‟ failure to obtain acceptable plans from contractors and clients

there inability to manage contractors planning is a common theme in construction

planning. One of the key requirements is to ensure that robust schedules are

developed by contractors. This can be established by including the planning

requirements in the Invitation to Tender (ITT) documents. This will indicate to

potential contractors the planning and scheduling requirements that he will have to

allow for in his tender for the works. As part of the tender, he will be requested to

outline his approach to planning progress measurement and reporting. Also in the

ITT, the client can outline his requirement for planning software, i.e. Primavera,

Microsoft Project etc. Clients can also pre-determine the level of detail, WBS,

change control procedures and progress measurement and reporting

requirements.

Once the contractor has submitted his tender and agreed to a clients requirement,

clients can then, during bid clarification meetings, (prior to contract award), fine

101

tune their understanding of contractors submission. This then allows a contract to

be awarded to a contractor who has complied with the planning and scheduling

requirements.

Other contracting techniques can be applied to ensure effective planning, these

include:-

a) Making a planning engineer a key resource and the client has to approve

the capability and skills before employment;

b) Contractors unable to change planning engineer without client approval;

c) Penalties for not providing correct calibre of resource;

d) Penalty in contract to penalise contractor for non-conformance of planning

function.

A further common theme has been the failure to baseline the schedule. This

failure is due to two main factors, firstly many of the companies surveyed and the

findings from the audit papers, indicated that clients were unaware of the need and

importance of baselining. The second reason for not baselining was failure of

client and contractor to agree a baseline schedule.

The fact that many companies are unaware of the baseline process and its

importance can only be overcome by having competent planning engineers in

place and this process being utilised.

Failure to agree baselines is usually as a result of:-

i) The scope not been captured in the schedule;

ii) Failure to agree schedule logic;

iii) Disagreement over level of detail between client and contractor.

Issue (i) to (iii) above could be alleviated by specifying the requirement in the ITT

and contract documents. Also an agreed set of planning procedures would

alleviate these issues.

The lack of a planning procedure has also been a common theme in how to

improve the planning process. It is intended that this will be addressed in Section

7 „Road Maps‟ to initiate improvements.

102

The issue of lack of professional planning has been cited as a reason for

inadequate planning. While this is accepted as a reason for inadequate planning,

this report will not offer reasons for this, but will outline some possible solutions to

the problem.

Possible solutions:-

a) Additional training within industry;

b) NVQ qualifications;

c) Recognition of the planning discipline as a profession – as for the Royal

Institute of Chartered Surveyors;

d) Minimum standards of qualifications to enter the planning discipline.

6.2 Cost Control and Estimating

The key message from the review of estimating and cost control was:-

1) Limited use of WBS / CBS;

2) Failure to link the cost and planning disciplines;

3) Failure to manage changes;

4) Lack of adequate procedures for estimating and cost control;

5) Capture of actual costs to allow future estimates.

All of these issues are recommended as areas of improvement. The Road Maps /

Tool Kit to implement changes are shown in Section 7 improvements.

6.3 Change Control

The key issues arising from review of change control are:-

1) Lack of a change control procedure;

2) Change control only applied to costs schedule not included;

3) Improvements to change control processes necessary to make it effective.

The road maps / tool kits indicate recommendations and improvements in the

change control process. These improvements are shown in Section 7.

103

6.4 Reporting and Progress Measurement

The key issues arising from the reviews carried out include:-

1) Lack of a reporting process / procedure;

2) Lack of integration between cost and planning date;

3) Failure to use progress reporting data to enable management decisions.

Recommendations to improve progress reporting are shown in Section 7 Road

Maps / Tool Kit.

104

7 Road Maps to Initiate Influences to Project Controls

7.1 Road Maps / Tool Kits

The Road Maps represent the culmination of the research study and provide

guidance in establishing best practice methodologies for each of the major

elements of project controls. The Road Maps demonstrate what are the significant

inputs, controls, mechanisms and outputs for each element of control. The

elements being planning, cost control, change control, estimate development,

progress measurement, reporting and the integration of cost and planning

disciplines.

Testing of the Road Maps has been carried out and they were used successfully to

implement best practice in project controls and they have helped to improve

delivery of projects within budget and on time.

To provide additional detail to the key elements of project control a series of Tool

Kits have also been developed. The Tool Kits expand and clarify the inputs,

control, mechanisms and outputs within the Road Maps and they may be used to

provide a standard approach to project control systems. .

105

7.2 Integration of Cost and Planning

7.2.1 Cost and Planning Integration

Integrated cost and planning presents an interfaced cost and schedule system by

cross referencing activities in a uniform and standard approach. Effort will be

required to undertake activities in concept, design development and construction

phases, but should be founded upon and be a development of, the basic approach

agreed during the feasibility phase of project development.

7.2.2 Cost and Planning Integration - The Benefits

Standardised approach to coding throughout the „life‟ of a project;

Avoids confusion by project control teams in referencing workpacks

/activities;

Changes to a scope, cost or time can be efficiently assessed and options

considered for action;

Data gathering on completion is used for future work;

The „learning curve‟ of resources, understanding project procedure is reduced

by standardisation;

Providing a flexible approach to differing project circumstances is maintained.

7.2.3 Project Control - To Meet Cost and Time Objectives

„We recommend that projects are controlled for cost and schedule objectives using

the following approach.‟

7.2.4 Project Control - Standard Coding System

By using a standardised coding system, (see schedule development), throughout

the project, all phases will benefit from a uniform referencing approach. It is

therefore, important during the feasibility phase, to code the project activities with

the cost and schedule coding system. The codes created here will be the format

and referencing that will be used throughout the life of the project. Changing or

coding after this stage will lead to confusion as parties to the project will have

already started using their own method of referencing their deliverables and they

will be probably incompatible and reluctant to change.

106

7.2.5 Project Control - Estimate and Schedule Verification

It is essential that the necessary checks are completed at this milestone to ensure

that the project cost and time objectives are in compliance with project procedures.

Details of the approach that we use are contained in „Estimate Development.‟

There should be an independent resource appointed to audit this activity.

7.2.6 Project Control – Change Control

It is essential that any change to the agreed scope of work against which the

original estimate and schedule was prepared and verified is fully assessed for cost

and time implications and the change agreed by the relevant responsible parties.

Details of the approach that we use are contained in the „Change Control‟ section.

There should be a dedicated resource appointed to audit this activity.

7.2.7 Project Control – Trend and Variance Identification

It is essential that any trend of, or any variance in actual cost or schedule, is

identified as early as possible and reported to the relevant project resources in

order that remedies can be identified, assessed and instruction made. Details of

how the cost and schedule information is gathered and presented are contained in

„Progress Measurement‟, „Cost Management‟ and „Reporting.‟

107

7.3 Road Maps

In order to promote best practice within the project control disciplines, the following

IDEFO charts identify the required methodologies to ensure effective controls.

Chart IDEFO A0 identifies an overview of the key aspects of project controls,

which in turn can lead to successful projects.

Fig 7.1

Chart IDEFO A1 Planning indicates the best practice process for project planning

and schedule development. The key input for the development of a robust

schedule is:-

Planning

A2

A1

A3

Progress Measurement &

Reporting

A5

Project Control Successful ProjectPlanning

Estimating

Cost Management

Change Control

A4

A3

A2

A1

108

Fig 7.2

a) An activity detail sheet that describes the work to be carried out at activity

level and the objectives of the activity with resource requirements;

b) A method statement that describes construction sequence including

methods to build the plant or facility;

c) Manhour estimates which are developed by work breakdown structures

and activity see (IDEFO chart A2);

d) Materials and equipment required to build the plant / facility;

e) Approved for construction (AFC) drawings, required to build the plant /

facility;

f) A list of who is responsible for each activity;

Key controls are described as:-

Change Control

Estimates

Activity Detail

Schedule DevelopmentProgress

Measurement

A1

A5

A4

A2

Resource Requirements

Materials

Standards

Equipment

Description

Objectives

Responsibility

AFC Drawing

Construction Sequence

Milestone Requirement

WBS

Software Procedure

Team Agree Schedule

Coding Structure

Baseline

Schedule

Risk

/HSE

109

i) Milestone requirements that must be met, for example, start construction,

design complete and first oil production;

ii) A work breakdown structure;

iii) An activity and resource coding structure that is applied in a uniform

manner across the schedule development. This allows work to be

reviewed at pre-set levels of sorting and filtering, these „drill down‟

capabilities are essential to providing visibility and for example,

discipline area, phase, priority, etc.

iv) Risk analysis, risk register and risk management

The key mechanism of the development of the schedule include:-

1) Appropriate software for the planning process;

2) Procedures in place to ensure consistent planning across a variety of

schedules;

3) The schedule will require approval from the project team.

The output of the schedule development process in an agreed baseline schedule

that is now ready to be used as the project control tool and progress measurement

can commence to compare actual versus planned progress.

Fig 7.3 IDEFO Chart A2 Estimating

The key inputs to the estimating process are the design drawings material take

offs and norm values used to estimate the manhours and costs of the design

information. The controls of the process are:-

Estimating Process Cash Flow Forcasts

A1 Planning

A2

A3

A1WBS / Schedule Activities

Estimating Technique

Project Allowance Guideline

Design Drawing

Norm values

Values

Material Take off

Contingency / Escalation Anticipates Degree of Accuracy Allowed Estimating Procedures Risk Allowing

Man hours / Costs

Estimated Cost

Man hours

110

1) Anticipated degree of cost accuracy, which generally is based on the

project stage, i.e.

Stage Accuracy Level

Feasibility +/- 25 – 50%

Concept design +/- 15 – 20%

Detail design +/- 5 – 10%

Construction +/- 1 – 10%

Handover +/- 100%

These degrees of accuracy are based on information available to carry out

the estimate;

2) Control is also provided by estimating procedures and guidelines;

3) Agreement of contingency, escalating and risk allowances, also play a

major part in controlling the final estimate.

The mechanisms which feed into the process are seen as:-

1) The estimates need to be developed around the WBS and schedule

activities in order that the information developed by the estimating team

can be used by the planning and cost management teams, who have

developed their systems around the WBS and activity breakdowns. This

allows, at the beginning of a project, total integration between the

estimating, planning and cost teams through an agreed WBS / CBS and

schedule activity system.

2) Estimating techniques used in the process are as follows:-

i) Unit cost – the estimate would multiply the cost of a particular unit

by the number of units required. The unit cost technique of

estimating requires analysis of previously completed similar

projects;

ii) Manhour Resource – where the individual project principally

involves a large amount of resource time, e.g. preparation of

validation documents, it is prudent to calculate the estimate cost

from a resource manhour forecast. A resource plan can be

established by listing all the activities involved. Key personnel

should estimate the time required to complete each activity; they

are responsible for establishing the overall manhour requirement.

111

Historical data for work under similar circumstances should be used

if available. Where manpower costs are significant on a project,

manhour resource estimating should be used to check the estimate;

iii) Factorial – The estimator can develop a total project cost, albeit for

the earlier stages of a project. By applying a factorial estimate to

those elements of the whole project where only certain elements

have been considered, the whole project estimate can be produced.

The technique is particularly useful when used in association with

unit cost and process module techniques. The techniques rely

upon a database or previously completed projects which have been

analysed for the factorial relationships between the elements;

iv) Material Take Off – The estimate is generated for all elements of

work from the quantities measured from the design information.

The design information used could be either the detail dimensions

with a standard or particular specification. Services are estimated

using approximate linear metreages, sizes and material

specification by applying a composite rate per metre. A factor is

applied to reflect the complexity of the service installation, but

requires definition of the complexity. The technique is an intensive

estimating exercise used when a high degree of accuracy is

required, but needs detailed design information;

v) Building Cost by Floor Area (m2) – The estimated cost of a building

and civil works is calculated by multiplying the gross floor area of

the particular construction work, by an appropriate rate. The

method requires a database of information for previously completed

similar work analysed by floor area (m2). The floor area method is

used where the particular specification for construction materials

and workmanship has not been fully developed. A detailed

specification description however, can be generated to support the

estimate as the estimate is produced, stating the assumptions

made. Costs for „services‟ can be estimated for using historical

data, (if available), but these linear and unit elements should only

be used as a comparison. Floor area estimates for this work can

prove misleading unless work is of an identical nature;

vi) Building Cost by Volume (m3) – The cost of a building is estimated

using the required spacial volume. The volume is multiplied by a

cost for each cubic metre of internal space. The estimate would

include building services contained within the structure. The

method requires a database of information from work of a similar

112

nature analysed by volume (m3) and is used solely for building

works with a general level of material specification.

The outputs from the estimating process are cost estimates, which feed into the

cost management system, to generate cost estimates. The cost estimates could

also be linked to the planning process and inputted into Primavera P3e software,

which can also generate cost forecasts linked directly to the schedule activities.

The manhour estimates generated from the estimating process can be

downloaded, at activity or WBS level, directly into the planning process to allow the

development of manpower histograms at trade of discipline level.

113

Fig 7.4 IDEFO Chart A3 Cost Management

To allow effective cost management to take place the inputs to the system are the

cost estimate and the actual costs at any given time.

Control of the process is applied by having in place a change control process, (see

IDEFO chart A4) change control, which incorporate approved costs into the cost

management process.

Auditing and monitoring actual costs against value of work done, (VOWD) is

essential to good controls and techniques such an earned value analysis is often

used to establish control.

The WBS and CBS (Cost Breakdown Structure) are methods of control to ensure

costs are allocated and measured, against agreed structures and earned value.

Calculations can be determined at required levels of detail.

Mechanisms that feed into the process are budget reviews which identify any

variation in anticipated final cost, (AFC), of each component as early as possible,

in order that actions can be taken to provide corrective action. Trend analysis and

contingency run down are also key mechanisms to the control of cost

management.

The outputs from the cost management process are anticipated final costs and

robust control of the cost of final out turn cost. Historical data can also be

captured from the cost management tool which allows forecasting of similar

projects to be established and bench marking data to be obtained.

Change Control

Progress Me

Measurement

Cost Management

Cost Estimate

A4

A2 A3

A5

Actual Cost

Budget Review Trend Analysis Contingency Run Down

Actual Costs / Vowd Auditing Monitoring

WBS / CBS

Anticipated Actual Cost

Historical Data

Control Over Cost

114

Fig 7.5 IDEFO Chart A4 Change Control

The management of change is fundamental to the success of a project, if changes

are allowed to be incorporated into a project without control, then the budget and

schedule are at risk.

The change control process input is the change order request, which is originated

by a project team representative.

Control of the process is in the change order form procedure and the authorisation

of the change from the project representative. The outputs of the change control

process is the impact on the budget and schedule. Once the impact has been

determined, the change order can be approved and the budget schedule modified

to affect the change. Following final approval, the change order is then added to

the change order register in order to provide an audit trail with regards to changes

within a project.

Change Control

Change

Order

Approval

Cycle

Change

Order

Register

Schedule

Impact

Budget

Impact

Approval

A4

Change Order Request

Reasons for change

(safety operations

Material)

WBS

Authorisation Change Order Procedure Change Order Form Sign Off

115

Fig 7.6 IDEFO Chart A5 Progress Measurement and Reporting

Process

Measurement

Reporting

Process

Change control Data

Cost Management

Physical Process

Schedule Baseline

Frequency of Measure

Process Measurement Procedure

WBS

Man hour Estimate

Method Of Measurement i.e.

1.Welding Dia. Inches

2.Linear Weld Deposited

3.Volume of weld Deposited

A5

Cost Data

Cut Off Date Distribution List

Issue

Report

Reporting ProcedureFrequency of Reporting

Risk Report

A5 A5

Schedule Baseline

A1

Cost Management

A3

Progress

Effective progress measurement and reporting is a basic need within project

controls and it is to establish where we are against the schedule and costs and

what is left to do. It is of paramount importance, therefore, that once the costs and

schedule are baselined, we then measure performance against the agreed

baseline. The measurement of progress and cost expenditure is then monitored

and any deviances to agreed rates of progress and costs can be detected and

corrective action put into place at an early stage during the execution of the

project.

The inputs to the progress measurement process are an agreed schedule and cost

baseline and the physical progress of the work being carried out.

Controls of the process are the agreed measure e.g. weekly or monthly, an agreed

progress measurement procedure that outlines in detail how the measurement

should be undertaken. Finally, the process for determining earned value

calculations should be established. The mechanisms for the process are methods

of measurement and the manhour / cost estimates for the work scope. The

outputs of the progress measurement process are an agreed progress measure of

the status of the project / projects. This measure will take the form of percentage

complete and earned manhours at overall, discipline and WBS level.

The reporting process is the method by which the progress measurement system

is reported to clients, management and the project team. The inputs to the

reporting process are therefore, the progress measurement data, cost data,

116

change control data and the risk report / log information. Control of the reporting

process is through the reporting procedure, which establishes what details will be

reported and the overall format of the reports. Frequency of reporting also

provides control for the process; this is normally carried out on a weekly or monthly

basis. The mechanics of the process are driven by the agreed cut off date for

reporting, e.g. the last Friday in the month or each Friday, in the case of weekly

reporting. The distribution list is also important to ensure all interested parties are

made aware of the project status on a regular basis.

Finally, the output from the reporting process is the issue of the progress report.

The following are developed, detailed road maps / tool kits for the key sections of

project controls:-

Schedule development;

Estimate development;

Cost management;

Change control;

Progress measurement,

Reporting.

117

7.4 Schedule Development

7.4.1 Schedule selection

The Schedule development section of these guidelines describes the preparation

of the project by identifying activities and application of time scales. The initial

schedule to be produced is a milestone schedule that captures all the key activities

and their anticipated durations. In the first instance at feasibility stage, the key

milestones may only be the project‟s start and finish dates. The milestone

schedule records the key information to start production of any other schedule and

is derived from the project scope documentation. The milestone schedule

document can be used to record and monitor progress of the key events

throughout the life of the project.

7.4.2 Schedule Selection – Project Requirements

The flow sheet overleaf Figure 7.7 provides a guide to the questions that should to

be considered when deciding the level and hierarchy of the schedules, to be

produced for the particular project and if they are required to be used in the life of

the project.

The critical questions that need to be considered for each project are:-

What is the scope of work?

What is the complexity of and the number of activity interfaces?

Will progress assessment be needed?

Will periodic reporting be needed?

7.4.3 Schedule techniques

Schedule Development considers the various scheduling techniques universally

used in the construction industry and advises on the practicalities of using these

techniques for the particular project. The use of schedule techniques will be

determined by the knowledge and experience, both of the people preparing each

schedule and those who are required to understand the end product. It would be

wasting time and effort, if the schedules produced are not used as management

tools during Progress Measurement, Cost Management and Reporting for which

they were designed because of the lack of knowledge by the project team.

118

Fig 7.7 Schedule Selection – Flow Sheet

119

7.4.4 Schedule – The Hierarchy

The schedule hierarchy is represented typically by use of a „pyramid‟, to depict the

various levels of detailing the project.

These levels are:-

Level 0 information is the highest level of any schedule. It is associated with the

project overview and can be presented as a single page milestone schedule or bar

chart schedule. It should outline the main design, procurement, construction and

commissioning activities. This schedule is used mainly as a management tool, by

the client‟s steering committee, especially where multiple projects are involved.

Level 0 - High level project strategy;

- Overall schedule duration;

- Shows multiple projects (bar chart only);

- Critical key dates / milestones.

Level 1 information should be as a bar chart schedule and show major activities

by phase, area and discipline for a single project. This is the project manager‟s

overview management tool.

Level 1 - Single project;

- Procurement strategy and contract plan;

- Critical key dates / milestones;

- Main activities.

Level 2 information details each level 1 activity, by using logic network techniques

or linked bar chart. A network or linked bar chart are diagram showing the logical

relationship and dependencies between individual activities. This is the main

working level and as such, should accurately represent the project logic. The

information will be used to instruct the project team to undertake the scope, in the

relevant time scale and to the agreed budgeted cost. The information will be used

by the project team to advise the project manager of changes or variances and

provide options to the achieved project objectives.

Level 2 - Network – logic schedule;

- Overall manpower allocation;

- Work breakdown structure (WBS).

120

Level 3 information, details the scope of individual packages of work. The network

logic schedule is used with detailed information. It will be used to provide the

individual discipline team leaders with viable alternatives to resolve problems. The

information is used to advise the activities, scope, time scale and budget cost of

each element of work. The information is used by the individual discipline team

leader to consider options, identify change or variance and to assist in preparing

option studies to achieve project objectives.

Level 3 - Detailed network – logic schedule;

- Individual sub contract details;

- Individual resource and costing elements;

- Detailed progress and costing assessments.

Level 4 information, details the break down of each level 3 activity into

cost/time/resource (CTR) sheets. Each CTR package of work should contain

detail to be stand-alone and enable a project resource to complete the activity with

the minimum of supervision.

Level 4 - CTR activity sheet;

- „Nuts and bolts‟ design details and specification;

- Materials;

- Risk assessment and method statement.

121

Fig 7.8 Schedule – The Hierarchy Pyramid

At the start of Schedule Development the project can be defined by identifying the

key milestones, the required estimate stage and the current procurement plan.

The first step in Schedule Development is to consider the high level project

activities, their relationships and to apply a suitable coding structure.

Subsequently planned durations, constraints and calendar details can be input into

the selected detail scheduling technique, and where necessary amplifying the

coding structure.

122

Before completion of the Schedule Development stage, the scheduling techniques

should be analysed for „levelling‟ of resources (see resource histograms).

Excessive resource peaks and troughs can be smoothed by redefining activity

start and finish dates.

Before the planned schedule information is sanctioned as part of the project

deliverables it must be validated and agreed. Schedule validation should be

undertaken simultaneously with the estimate verification exercise described in

Estimate Development and using the same basis of estimate checklist and detail

information, provided a report on the likely accuracy of both schedule and estimate

can be made.

Once the schedule information is sanctioned it can be „baselined‟ and issued as

the project execution schedule, using the scheduling techniques selected.

The Schedule Development - flow sheet presents a systematic approach to the

development of project schedules, from early scope definition to sanction and the

regular review of each working document.

The Schedule Development - flow sheet has been constructed to be used at any

stage of a project within Schedule Development, thus ensuring consistent

documentation. At each stage of Schedule Development appropriate schedule

techniques have been identified together with the relevant information or actions

that need to be provided and completed.

7.4.5 Key points to note

Creating an excessive number of activities can result in considerable effort being

required to maintain the schedule on activities that have little or no individual

impact on the project. Selection of those key activities against which to monitor

progress is the way to project success.

Schedule outputs should identify the critical path, and check for loops in logic

networks, negative float, and for over allocated resources.

123

Fig 7.9 Schedule Development Flow Sheet

124

7.4.6 Activity coding

The coding structure of the project‟s activities is generated from the order in which

the activities are required to be sorted into the scheduling software. The activity

coding and their order should be created from the experience of the project‟s

planning resource, to produce a structured approach. Activity codes are used to

enable project activities to be referenced and could be sorted in a variety of

different ways to satisfy the requirements of a particular project.

The use of activity coding is a flexible approach to presenting project events.

Examples of this flexibility is to present the project activities by:

Discipline - where all component disciplines of a project are individually

listed;

Geographical location - where more than one location forms part of the

whole project, but with the same component disciplines in each location.

7.4.7 Work Breakdown Structure (WBS)

The coding of the project‟s activities using WBS is a rigid system to coding that is

predetermined for a standardised approach to presenting all projects. The WBS.

is used to detail the scope of works for a project into manageable and controllable

components, but in a standard approach. The WBS. code for a particular activity

on any project at the management and project level is, therefore, identical for all

projects. The benefits are a standard system of establishing schedules and

reporting progress for a series of projects to a central body.

7.4.8 Activity coding - Our Approach

It is usual for larger projects to use a combination of both WBS. and activity

coding. The higher level coding structure using the standardised WBS. coding and

to maintain the demands of flexibility. Activity coding is used to sort the detail

levels. The selection of detail activities can, therefore, be presented in a variety of

ways to suit requirements of the project team and higher levels are used to plan

and report progress to satisfy the project management requirements. The choice

of the activity coding structure, plus the WBS at high level, will create the coding

structured for the project and to be referenced on all cost and schedule

documents.

125

Schedule Development involves taking the overall scope of work and applying the

Work Breakdown Structure (WBS) to the high level activities. The activities will be

categorised and coded into manageable work packages with responsibility

assigned. Designing the activity coding involves discussion with the project team

and considering the project‟s procurement strategy, to anticipate work elements

into which the activities will be divided. The selected structure should be agreed

by project team members. Activity coding allows for the adoption of a detailed

filtering system, providing flexibility for reporting against, geographical site areas,

various job phases, types of work, trade groups, material types etc.

7.4.9 Activity Coding Structure – Example

With reference to the coding structure provided on the opposite page, the code for

construction, mechanical, area 2 at level 4 within the hierarchy would be:

The coding system, with a „three digit‟ code, has been applied to templates

throughout these toolkits to show a standard approach.

Within the coding system a „0‟ should be used as the default or where there is not

a supporting activity. Levels 0, 1, 2 and 3 would use coding from a client‟s

standard system. Level 4 is project specific requirement.

0. 1. 5. 3. 2.

Level 4 - Area location

Level 3 - Discipline

Level 2 - Project phase

Level 1 - Project title

Level 0 - Programme of projects

= Four digit code (optional five digit code if multiple

projects are part of a programme)0. 1. 5. 3. 2.

Level 4 - Area location

Level 3 - Discipline

Level 2 - Project phase

Level 1 - Project title

Level 0 - Programme of projects

= Four digit code (optional five digit code if multiple

projects are part of a programme)

126

Fig 7.10 Project Activity Coding Structure

127

7.4.10 Activity Definition – Level 4

The activity definition form template should be used to instruct project resources

on how to complete a specific activity of the project providing information on what

is required, the resources needed and the method of reporting progress and

achieving completion.

Activity description The activity description is the concise written explanation of the

required tasks that can be readily understood by recipient and

all labour resources involved.

Activity code The activity code is created using the technique described

previously and is used as the required digit reference number of

the project for the activity description.

Inputs Description and identification of all previous activities that are

needed to be completed by the project to enable the activity to

start.

Process Method statement and H&S plans of how the project plans for

the activity to be carried out. The method statement should

recognise the risks associated with the new materials provided

or the existing materials to be encountered and managed and

the manual handling risks involved in undertaking the activity.

Standards Identification of the quality and / or workmanship standards

expected to be achieved as the work proceeds and on

completion.

Outputs Description of the tangible result which determines the

completion of the activity.

Review process Description of how the quality and requirements of the output

that will be audited both during progress and on completion.

Resources Description of the resources (labour and equipment) that will be

required to undertake and complete the activity. The

description should define the skills and experience needed to

carry out the activity.

Responsibility Identifies the project resource responsible for the activity being

completed.

Effort Estimation of the quantity of resources (labour, materials and

equipment) and durations involved in carrying out the activity.

Progress control Description of the progress measurement technique that is to be used to monitor activity progress and the information needed to be provided and recorded.

128

Fig 7.11 Activity Definition Form

129

7.4.11 Scheduling Techniques

Scheduling Techniques – Overview

Table 7.12 provides an overview of the types of scheduling techniques that are

used to present activity and calendar information for a project. The overview is

intended as a guide to those schedules that may be appropriate for each of the

various levels of information required within a hierarchy.

The overview of schedules table comprises:

Schedule Hierarchy

Reference should be made to schedule – the hierarchy for explanation of each

level.

Schedule Activity Numbers

The hierarchy level of the project should be used to identify the approximate

number of activities that should be considered and reported to the relevant project

resources, from the relevant band of information. Levels 1 and 2 indicate the

approximate number of project activities thought appropriate to report.

Schedule name and type

The appropriate schedule to be used to present the project information should be

selected from the table by identifying the hierarchy level. The levels 1 and 2

indicate a variety of differing techniques that could be appropriate to present and

report the schedule information. The name of each schedule is provided with its

schedule type, typically a bar chart, spreadsheet or network diagram.

Project Information Needed

The description of data needed to complete each schedule type is provided for

each schedule name, with a list of minimum information needed to be available.

The information is to be collated by project resources to prepare base lined

schedules and to monitor and report progress throughout the duration of the

project.

130

7.4.12 Project responsibility, duration and update cycle

The project resources responsible for the production of the information are listed.

The part of the project duration, together with the update cycle, is provided to give

an indication as to when each schedule should be used to the benefit of the project

execution.

A list of the most commonly used scheduling techniques is provided on the next

pages of this section.

131

Fig 7.12 Scheduling Techniques - Summary

132

7.4.13 Schedule Types

The most commonly used schedule types are listed below and described in detail:-

1. Milestone schedule;

2. Critical path logic diagram;

3. Classic schedule bar chart;

4. Resource forecasting;

5. Project forecast „S‟ curve;

6. Procurement schedule;

7. Time chainage diagram.

Notes.

The data used in all of the charts and diagrams in Schedule Development is

consistent to enable a comparison to be made to select the most appropriate

technique to be used on a project to meet the project team‟s requirements.

The same base project information has been used to present the charts and

diagrams as the project progresses in measurement, reporting and completion and

is used to compliment cost management techniques.

1. Milestone schedule

A milestone schedule is produced to record the key events in a project life-

span. This schedule is produced in tabular format, and should be consistent

with all levels of activity coding. The information contained in the milestone

schedule is commonly used for management level. This is a useful

management tool that provides a clear presentation of project plan and

progress when pure logic definition is not required.

The milestone schedule includes activity code, activity description, planned

date for completion, responsible authority and comments. It is particularly

important to stress the need for a responsible authority to be assigned

against each milestone.

133

This particular schedule and example of a milestone schedule will be referred

to in:

Progress Measurement - milestone progress;

Reporting - milestone report.

7.13 Milestone Schedule

134

7.4.14 Critical Path Logic Diagram

The critical path logic diagram is the process of recording and presenting the

logical interfaces between schedule activities. A more common name for this type

of diagram is a PERT chart; which is short for Programme Evaluation Review

Technique.

The critical path logic diagram is created as a series of schedule activities

represented by „a box‟ for each activity. Each activity box is linked to its

dependencies by lines with arrow heads to show the sequence of the

dependencies. The activity description is included in the information for each box.

Traditionally the activity boxes and arrows are presented starting on the left and

ending on the right. The completed series of activities and dependencies is the

„precedence network‟.

The PERT chart facilitates the review of relationships without respect to time and

is used particularly during project schedule development to confirm and revise

logic.

A pure „logic diagram‟, as the example shown, may be developed by hand or by

the use of software tools such as Primavera P3 / SureTrak / Microsoft Project.

Using any of these tools, the full network of activities are input systematically to

allow logical considerations to be reviewed, with respect to each activity.

The „logic diagram‟ will be populated with durations, assessed as reasonable

allowances for each activity, and if practical start and finish dates. After inputting

all the activity durations, the network can be processed to identify the route

between those activities from start to end of the project that will provide the least

duration of the project. This duration and the path highlighting those activities,

represents the critical path for the project. The importance of the critical path is

that if any progress measurement reports the failure of an individual activity to be

completed in the allowed duration, will result in the whole project failing to

complete in the required time scale.

The critical path should be closely monitored for progress. A failure of an activity

on the critical path to meet its completion date may, however, change the

subsequent sequence of activities that are the critical path, and the logic diagram

should be processed in such an occurrence to confirm the current critical path and

the component activities.

135

The populated „logic diagram‟ can be used to explore and select from „option

plans‟ and „what if‟ scenarios by altering durations of individual activities, to reflect

alternative procurement strategies or construction processes.

Fig 7.14 Critical Path Logic Diagram – (PERT Chart)

136

7.4.15 Classic Schedule Bar Chart

A classic schedule bar chart is the standard form of presenting schedule

information. This schedule type is often referred to as a Gantt chart.

A Gantt chart is essentially a bar chart of information. The activities that comprise

the whole project are listed individually in a systematic approach, from the start of

the project at the top of the schedule to the completion of the project at the bottom.

A single horizontal line is devoted to each activity that contains the brief

description and individual code for the activity. Each activity line is presented as a

bar, with the planned early start and finish dates for each activity in the project

plotted against the overall project duration.

The information used in the compilation of this chart comes from the „logic

diagram‟, but it is not dependent upon the creation of such a chart. The more

complex the project for activities and dependencies, the more relevant is the use

of the logic diagram.

Schedule Baselining – Classic Schedule Bar Chart

This form of chart is the common presentation technique against which schedule

information for a project will be progress measured and reported. It is used to

present the initial schedule information against which the project will be

sanctioned. Acceptance of the scheduled approach to project execution as part of

the sanctioning approval will signal the start of progress monitoring. In order to

effectively report progress and consider option remedies for variances to the

sanctioned schedule the programme should be „baselined‟. The schedule bar

chart will be „frozen‟ and as progress is achieved the information will be reported

as a „shadow‟ of the planned activity bar.

All planning software is capable of producing the classic schedule bar chart.

The example shown on the opposite page has been prepared using P3 software

and has been developed as the examples in the following sections.

Schedule progress (Progress Measurement);

Lookahead charts (Progress Measurement);

Schedule report (Reporting);

Schedule closeout (Completion).

137

The example shown is a Primavera P3 template and shows WBS levels 1 – 3.

Fig 7.15 Classic Schedule Bar Chart – Gantt chart

138

7.4.16 Resource Forecasting

Resource forecasting is required to assess the level of labour and equipment

resources needed over a particular duration of the project, to complete an activity.

The total quantity of resources needed to undertake the particular activity is

evaluated and then distributed over the period allowed in the project time scale.

The practical execution of the activity should be reflected in the resource levels for

each period interval.

The resource histogram is a graphical representation of the planned deployment of

resources against WBS coded activities, with respect to intervals of time. The

chart shown opposite is displayed as a stacked summation of resources. Multiple

resources can also be shown as a number of individual stacks shown either

horizontally or vertically over a specific duration, with resources shown at regular

intervals.

Interrogation of the resource histograms can show potential periods of maximum

or over capacity. Adjustment can be made to reduce those durations of over

capacity and transfer work to periods of less demand. The adjustment must be

undertaken in conjunction with a populated classic schedule bar chart, to ensure

that the realignment of resources (levelling) can in fact be practically achieved and

that other linked activities are not compromised.

A resource histogram is created by calculating the number of resource man hours

to complete each activity that are then allocated per period of time, against the

planned timescale for the activity. Although it is possible to develop a resource

histogram manually, it is more practical to use planning software that will allow

additional resources and amendments to be made more readily as changes occur.

Schedule Baselining – Resource Histograms

Resource histograms are used in Schedule Development to plan the resource

requirements and are used following „baselining‟ during the project to;

Record progress and identify variances, used in conjunction with other

progress measurement tools;

Present options to consider recovery of slippages and reallocation of

resources;

139

Record progress during the project and used on completion as historical

information.

Other advanced methods of presenting resource histograms are:

Cumulative histograms,

Double graph (standard and cumulative) histograms.

Fig 7.16 Resource Histogram

140

7.4.17 Project Forecast „S‟ Curves

The project forecast „S‟ curve should be prepared from the information contained

in the classic schedule bar chart, (Gantt chart), populated with resource data.

A project forecast „S‟ curve could be generated for each level within the project‟s

coding structure. The total project „S‟ curves should „roll up‟ such that the curve

generated at the highest level in the hierarchy is the cumulative figure of those at

the lower levels.

The information provided for each project activity is used to generate two curves

showing the earliest and latest start dates for the activities considered. The graph

will therefore identify an „envelope‟ between these two projected curves and is the

difference between the earliest and latest start dates. Actual progress should

be recorded and monitored for containment within the limits of the envelope

without concern that final completion will be achieved as planned.

Schedule Baselining – Project Forecast „S‟ Curves

The baselined project forecast „S‟ curve should be created using the resource

hours, corresponding with the project activity sequence and content, presented as

the approach granted sanction approval.

The base lined project forecast „S‟ curve is presented as the sum of the estimated

total of resource man hours for each discipline. The information will be expressed

as the sum of all discipline resources for each time period over the duration of the

project. Each discipline that will be involved is presented either;

divided by the intervals

Or

allocated for planned performance as a percentage completion, from

historical data.

The baselined project forecast „S‟ curve should be a management tool against

which progress will be monitored and recorded.

Project forecast „S‟ curves are used in Schedule Development to plan the

anticipated performance. The project forecast „S‟ curves are used following base

lining during the project to:-

141

Record progress during the project;

Record data for historical information.

Other advanced use of project forecast „S‟ curves are:

Earned value;

Percentage efficiencies.

Fig 7.17 Project Forecast ‘S’ Curves

142

7.4.18 Procurement Schedule

The procurement schedule should be used to present information on items that are

needed to be available at key milestones during the project duration to achieve

completion as the project delivery requires. The information included in the

procurement schedule is obtained from other scheduling techniques. The details

scheduled should be used to review only the critical information on selected key

issues for those items identified as crucial to project success.

Construction materials;

Process equipment;

Construction / installation contracts.

The procurement schedule should be populated with information on;

Plant item equipment description and number (where practical or

provisional);

Project requisition number based upon the contractor‟s or client‟s numbering

system;

Planned enquiry date when tenders will be sought;

Suppliers from whom the tenders will be sought;

Planned order date when submitted tenders will have been evaluated, a

suitable supplier, contract figure and contract conditions agreed and, if

relevant, the date the order was placed;

Planned delivery date when the particular item is required to be available for

installation in the project programme.

As the project develops the procurement schedule should be updated to register

progress against the planned enquiry, order and delivery dates.

This particular example of using a procurement schedule will be used in:

Procurement schedule – (Progress Measurement).

143

Fig 7.18 Procurement Schedule Example

144

7.4.19 Time Chainage Diagram

The time chainage diagram could be used during Schedule Development on

specialist projects that require consideration of a complexity of activities where the

nature of construction has to be completed in a short time period and over a

significant footprint length.

The time chainage diagram is a representation of the linear construction work for a

project either complete, or in part, showing over a period of time, the various

activities, their location and duration.

The component parts of the time chainage diagram are:

Time Period of equal time intervals considered relevant for the scope;

Linear location The physical length of the scope of work on the ground;

Activity Individual items of work that are involved in the scope;

Duration Cumulative time internals.

Time is expressed as the „x‟ axis and linear location is plotted as the „y‟ axis of the

two dimensional diagram. All the activities of the scope in consideration are each

plotted for their start and finish involvement, against the graphical location on the

ground.

The purpose of this representation is to clearly identify during Schedule

Development;

Those activities that in the same location are to be undertaken

simultaneously thus causing a clashing of effort. By identifying the potential

clash a restructuring of the plan can be made;

Realise early release of those areas over the whole length that could be used

for execution of subsequent activities when a linear activity is reported as

only partially completed.

145

This scheduling technique should be used during Progress Measurement to;

Readily reassess areas of potential clashes if precedent activities are not

completed in their allocated time.

Fig 7.19 Time Chainage Diagram

15

16

17

18

19

20

21

22

23

24

25

15

16

17

18

19

20

21

22

23

24

25

02

NOV

02

NOV

501.0

1

501.0

2

501.0

3

501.0

4

501.0

7

501.0

8

501.0

9

501.1

0

501.1

1

Incom

ple

te

501.0

1

501.0

2

501.0

3

501.0

4

501.0

7

501.0

8

501.0

9

501.1

0

501.1

1

Incom

ple

te

Re-ballast (

Dn)

Re-ballast (

Up)

Re-ballast (

Dn)

Re-ballast (

Dow

n)

Track M

ainten

ance

DBP1 U

B32A B

rickw

ork R

epairs

DBP1 U

B32A B

rickw

ork R

epairs

Track Maintenance

Trac

k Maint

enan

ce

DBP1 UB42

Demolish & Infill

Renew

S&C

Re-ballast (

Dn)

Re-ballast (Up)

Re-ballast (

Up)

Trax- R

eballast (

Dn)

Trax- R

eballast (

Dow

n)

Follow

up T

am

p (

Up)

Tim

e

Chainage

146

7.4.20 Visual 4D Planner

Visual 4D Planner - What is it?

The visual 4D (3D plus time) planner is an application that allows planners to

visualise the status of a construction project at any stage. The tool combines

commonly used CAD and project planning (such as Primavera and MS Project)

software to provide planners with the ability to evaluate visualise and optimise

construction tasks, prior to execution on site.

Viewing products and processes in a virtual reality environment provides improved

communication between all parties of a project.

The tools and concepts have been developed from a three year collaborative

research project with nine industrial partners. The industrial partners provided the

following case studies to develop and evaluate the tools:

School of Health, University of Teesside;

West Morland Primary School, Stockport;

Construction of heavy civil engineering projects in the UK.

Visual 4d Planner - What can it do?

The benefits of the tools have shown:

the ability for the client/planner/contractor to view the constructability of a

project;

the ability to communicate the project, at layman and technical, level to all

parties;

improved project certainty and reduced risk, in terms of cost, time, quality

and safety;

a reduction in construction errors;

work can be rehearsed on screen prior to actual work on site;

positioning of cranes and lay down areas can be reviewed for practicality

the most productive construction approach can be maximised.

The tools are currently being developed on existing projects, with large UK

construction companies.

147

Fig 7.20 Visual 4D Planner

Visual 4D plannerVisual 4D planner

Visualise a construction project

at any stage

Visualise space and product

conflicts

View the construct-ability of a

project

Affordable/quick real-time VR

walkthroughs to detect logical

errors and spatial conflicts

148

7.4.21 Software Tools

Microsoft Word

Microsoft Word is a word processing software package used to compile office

documentation. The specific applications used in this cost and schedule toolkit are

listed on the opposite page.

Microsoft Excel

Microsoft Excel is a spreadsheet software package used to compile mathematical

calculations with standard presentation templates in appropriate forms. Excel can

be used to show graphical representation of the mathematical calculations, as

curves, stacked bar charts etc. The specific applications used in this cost and

schedule toolkit are listed on the opposite page.

Microsoft Project

Microsoft Project is a simple to use scheduling package. It is designed specifically

for the „Windows‟ environment. This package can produce high quality

presentation style graphics and perform normal time – analysis calculations. This

package should be used on small (low number of activities) projects, or as a

presentation tool.

Primavera Project Planner (P3)

Primavera Project Planner (P3) is also a simple to use scheduling package. With

an interface that simplifies project scheduling and control without diminishing its

capability as a powerful project management software package, it is also designed

for use in the „Windows‟ environment.

Primavera Enterprise Planner

Primavera P3e/c is the project management standard management tool designed

specifically for the construction industry. Staying on budget and on schedule

means staying in control. Projects must be planned quickly and well to seize

business opportunities and to keep costs down. P3e/c empowers engineering and

construction professionals to mitigate project risk through powerful schedule

analysis, accurate cost forecasting and streamlined coordination.

149

Primavera SureTrak

SureTrak is a development of Primavera (P3) designed primarily for use in stand

alone site situations. The outputs and systems are similar to P3. This package

could be used on large projects.

All Primavera products can be installed on a local area network (LAN) for multi

user access, or it can be used as stand-alone system. The features of the system

include:-

Multi project scheduling;

Project scheduling;

Resource scheduling;

Multi calendar variations;

Filter report capability.

The software is also compatible with Microsoft Excel and can be used to produce

high image quality reports by exporting the Primavera information. This package

can be used on both large and small projects or programme of projects to suit the

requirements of the project or projects.

Microsoft Word

Uses of Microsoft Word in connection with the Toolkit are:-

Checklists (Project Management);

Checklists (Schedule Development);

Checklists (Estimate Development);

Executive summary (Reporting);

Checklist (Supply Chain Management).

Microsoft Excel

Uses of Microsoft Excel in connection with the Toolkit are:-

Schedule Development (Overview of schedules);

(Milestone schedule);

(Resource histogram);

(„S‟ curve).

150

Estimating Development (Basis of estimate checklist);

(Escalation calculations);

(Currency statement);

(Risk analysis form);

(Estimate formats);

(Cashflow „S‟ curve).

The listed initial applications of Microsoft Word and Excel are also used to

produce:

Imported „S‟ curves from scheduling software;

Progress statements;

Cost management presentations;

Change control register and forms;

Reports.

151

7.5 Estimate Development

7.5.1 Basis of Estimating

The project is expressed in eight specific stages. The design and management

requirement issues of the project have been identified by 15 elements of the scope

of work. The matrix on the opposite page provides a checklist of that information

expected to be considered in order to compile a valid estimate at each appropriate

project stage.

When preparing an estimate, it is advisable to review the available information for

each of the elements of works and apply the estimate information - status

definition, to review the stage of the project that is currently being estimated. The

estimate information - status definition is seen as being a minimum requirement at

each project stage.

7.5.2 Estimate information - status definition

Not available: no consideration has been made to any aspect of the element of

work. Whilst no detailed information is available, the estimate for

this element can be made on a factorial basis using basic outline

data if other elements of work have been outlined.

Basic outline: consideration has been made to identify global or approximate

levels of requirements or performance based upon information

provided from the client.

Agreed outline: the basic outline information has been considered and developed

into an outline brief which has been discussed with the project

sponsor.

Agreed scope: the agreed outline information has been further developed and

agreed with the project sponsor, in order that design can be made

available to produce the agreed detail.

Agreed detail: the agreed scope has been fully designed in order that the

construction of a particular area can be completed. The design

detail has been agreed with the project management team and the

project sponsor.

152

Detail complete: the agreed detail has been designed and construction has been

completed.

Achieved scope: the detail complete has been accepted by both the project

management team and the client. Handover is achieved by the end

user‟s acceptance of completion.

Fig 7.21 Checklist – Expectation of Information Availability

Co

nc

ep

t D

es

ign

3

Ag

ree

dS

co

pe

Ag

ree

d

Ou

tlin

e

Ag

ree

d

Ou

ltin

e

Ag

ree

dS

co

pe

Ag

ree

d

Ou

tlin

e

Ba

sic

Ou

tlin

e

Ba

sic

Ou

tlin

e

Ba

sic

Ou

tlin

e

Ba

sic

Ou

tlin

e

Ag

ree

dO

utl

ine

Ag

ree

dS

co

pe

Ba

sic

Ou

tlin

e

Ag

ree

dO

utl

ine

Ba

sic

Ou

tlin

e

Ba

sic

Ou

tlin

e

1P

roc

es

s D

efi

nit

ion

2P

roc

es

s E

qu

ipm

en

t

3P

roc

es

s S

erv

ice

s

4S

ite

Lo

ca

tio

n

5S

pa

cia

lR

eq

uir

em

en

ts

6B

uild

ing

En

ve

lop

e

7B

uild

ing

Se

rvic

es

8In

fra

str

uc

ture

Se

rvic

es

9E

xte

rna

l W

ork

s

10

Ex

tern

al C

on

str

ain

ts

11

En

vir

on

me

nta

l C

rite

ria

12

Pro

cu

rem

en

t S

tra

teg

y

13

Pla

n -

Ta

rge

t D

ata

14

Va

lue

En

gin

ee

rin

g

15

Ris

k A

ss

es

sm

en

t

Fe

as

ibilit

y

1

Ba

sic

Ou

tlin

e

Ba

sic

Ou

tlin

e

No

tA

va

ila

ble

Ba

sic

Ou

ltin

e

No

tA

va

ila

ble

No

tA

va

ila

ble

No

tA

va

ila

ble

No

tA

va

ila

ble

No

tA

va

ila

ble

No

tA

va

ila

ble

Ba

sic

Ou

tlin

e

No

tA

va

ila

ble

Ba

sic

Ou

tlin

e

No

tA

va

ila

ble

No

tA

va

ila

ble

Ma

ste

rP

lan

2

Ag

ree

d

Ou

tlin

e

Ag

ree

d

Ou

tlin

e

Ba

sic

Ou

tlin

e

Ag

ree

d

Ou

tlin

e

Ba

sic

Ou

tlin

e

Ba

sic

Ou

tlin

e

No

tA

va

ila

ble

No

tA

va

ila

ble

No

tA

va

ila

ble

Ba

sic

Ou

ltin

e

Ag

ee

dO

utl

ine

No

tA

va

ila

ble

Ba

sic

Ou

tlin

e

No

tA

va

ila

ble

No

tA

va

ila

ble

De

sig

nD

ev

elo

p-

me

nt

4

Ag

ree

dD

eta

il

Ag

ree

dS

co

pe

Ag

ree

dS

co

pe

Ag

ree

dD

eta

il

Ag

ree

dS

co

pe

Ag

ree

dO

utl

ine

Ag

ree

dO

utl

ine

Ag

ree

dO

utl

ine

Ba

sic

Ou

tlin

e

Ag

ree

dS

co

pe

Ag

ree

dD

eta

il

Ag

ree

dS

co

pe

Ag

ree

dS

co

pe

Ag

ree

dS

co

pe

Ag

ree

dS

co

pe

De

taile

d

De

sig

n

5

Ag

ree

dD

eta

il

Ag

ree

dD

eta

il

Ag

ree

dD

eta

il

Ag

ree

dD

eta

il

Ag

ree

dD

eta

il

Ag

ree

dD

eta

il

Ag

ree

dD

eta

il

Ag

ree

dD

eta

il

Ag

ree

dO

utl

ine

Ag

ree

dD

eta

il

Ag

ree

dD

eta

il

Ag

ree

dD

eta

il

Ag

ree

dD

eta

il

Ag

ree

dD

eta

il

Ag

ree

dD

eta

il

Co

mm

is-

sio

nin

g

7

De

tail

Co

mp

lete

Ac

hie

ve

dS

co

pe

Ac

hie

ve

dS

co

pe

Ac

hie

ve

dS

co

pe

Ac

hie

ve

dS

co

pe

Ac

hie

ve

dS

co

pe

Ac

hie

ve

dS

co

pe

Ac

hie

ve

dS

co

pe

De

tail

Co

mp

lete

Ag

ree

dD

eta

il

Ag

ree

dD

eta

il

De

tail

Co

mp

lete

De

tail

Co

mp

lete

Ac

hie

ve

dS

co

pe

Ag

ree

dD

eta

il

Ha

nd

ov

er

8

Ac

hie

ve

dS

co

pe

Ac

hie

ve

dS

co

pe

Ac

hie

ve

dS

co

pe

Ac

hie

ve

dS

co

pe

Ac

hie

ve

dS

co

pe

Ac

hie

ve

dS

co

pe

Ac

hie

ve

dS

co

pe

Co

ns

tru

c-

tio

n

6

De

tail

Co

mp

lete

De

tail

Co

mp

lete

De

tail

Co

mp

lete

De

tail

Co

mp

lete

De

tail

Co

mp

lete

De

tail

Co

mp

lete

De

tail

Co

mp

lete

De

tail

Co

mp

lete

Ag

ree

dD

eta

il

Ag

ree

dD

eta

il

Ag

ree

dD

eta

il

De

tail

Co

mp

lete

De

tail

Co

mp

lete

De

tail

Co

mp

lete

Ag

ree

dD

eta

il

Sco

pe o

f

Wo

rks

Es

tim

ate

Sta

ge

Co

nc

ep

t D

es

ign

3

Ag

ree

dS

co

pe

Ag

ree

d

Ou

tlin

e

Ag

ree

d

Ou

ltin

e

Ag

ree

dS

co

pe

Ag

ree

d

Ou

tlin

e

Ba

sic

Ou

tlin

e

Ba

sic

Ou

tlin

e

Ba

sic

Ou

tlin

e

Ba

sic

Ou

tlin

e

Ag

ree

dO

utl

ine

Ag

ree

dS

co

pe

Ba

sic

Ou

tlin

e

Ag

ree

dO

utl

ine

Ba

sic

Ou

tlin

e

Ba

sic

Ou

tlin

e

1P

roc

es

s D

efi

nit

ion

2P

roc

es

s E

qu

ipm

en

t

3P

roc

es

s S

erv

ice

s

4S

ite

Lo

ca

tio

n

5S

pa

cia

lR

eq

uir

em

en

ts

6B

uild

ing

En

ve

lop

e

7B

uild

ing

Se

rvic

es

8In

fra

str

uc

ture

Se

rvic

es

9E

xte

rna

l W

ork

s

10

Ex

tern

al C

on

str

ain

ts

11

En

vir

on

me

nta

l C

rite

ria

12

Pro

cu

rem

en

t S

tra

teg

y

13

Pla

n -

Ta

rge

t D

ata

14

Va

lue

En

gin

ee

rin

g

15

Ris

k A

ss

es

sm

en

t

Fe

as

ibilit

y

1

Ba

sic

Ou

tlin

e

Ba

sic

Ou

tlin

e

No

tA

va

ila

ble

Ba

sic

Ou

ltin

e

No

tA

va

ila

ble

No

tA

va

ila

ble

No

tA

va

ila

ble

No

tA

va

ila

ble

No

tA

va

ila

ble

No

tA

va

ila

ble

Ba

sic

Ou

tlin

e

No

tA

va

ila

ble

Ba

sic

Ou

tlin

e

No

tA

va

ila

ble

No

tA

va

ila

ble

Ma

ste

rP

lan

2

Ag

ree

d

Ou

tlin

e

Ag

ree

d

Ou

tlin

e

Ba

sic

Ou

tlin

e

Ag

ree

d

Ou

tlin

e

Ba

sic

Ou

tlin

e

Ba

sic

Ou

tlin

e

No

tA

va

ila

ble

No

tA

va

ila

ble

No

tA

va

ila

ble

Ba

sic

Ou

ltin

e

Ag

ee

dO

utl

ine

No

tA

va

ila

ble

Ba

sic

Ou

tlin

e

No

tA

va

ila

ble

No

tA

va

ila

ble

De

sig

nD

ev

elo

p-

me

nt

4

Ag

ree

dD

eta

il

Ag

ree

dS

co

pe

Ag

ree

dS

co

pe

Ag

ree

dD

eta

il

Ag

ree

dS

co

pe

Ag

ree

dO

utl

ine

Ag

ree

dO

utl

ine

Ag

ree

dO

utl

ine

Ba

sic

Ou

tlin

e

Ag

ree

dS

co

pe

Ag

ree

dD

eta

il

Ag

ree

dS

co

pe

Ag

ree

dS

co

pe

Ag

ree

dS

co

pe

Ag

ree

dS

co

pe

De

taile

d

De

sig

n

5

Ag

ree

dD

eta

il

Ag

ree

dD

eta

il

Ag

ree

dD

eta

il

Ag

ree

dD

eta

il

Ag

ree

dD

eta

il

Ag

ree

dD

eta

il

Ag

ree

dD

eta

il

Ag

ree

dD

eta

il

Ag

ree

dO

utl

ine

Ag

ree

dD

eta

il

Ag

ree

dD

eta

il

Ag

ree

dD

eta

il

Ag

ree

dD

eta

il

Ag

ree

dD

eta

il

Ag

ree

dD

eta

il

Co

mm

is-

sio

nin

g

7

De

tail

Co

mp

lete

Ac

hie

ve

dS

co

pe

Ac

hie

ve

dS

co

pe

Ac

hie

ve

dS

co

pe

Ac

hie

ve

dS

co

pe

Ac

hie

ve

dS

co

pe

Ac

hie

ve

dS

co

pe

Ac

hie

ve

dS

co

pe

De

tail

Co

mp

lete

Ag

ree

dD

eta

il

Ag

ree

dD

eta

il

De

tail

Co

mp

lete

De

tail

Co

mp

lete

Ac

hie

ve

dS

co

pe

Ag

ree

dD

eta

il

Ha

nd

ov

er

8

Ac

hie

ve

dS

co

pe

Ac

hie

ve

dS

co

pe

Ac

hie

ve

dS

co

pe

Ac

hie

ve

dS

co

pe

Ac

hie

ve

dS

co

pe

Ac

hie

ve

dS

co

pe

Ac

hie

ve

dS

co

pe

Co

ns

tru

c-

tio

n

6

De

tail

Co

mp

lete

De

tail

Co

mp

lete

De

tail

Co

mp

lete

De

tail

Co

mp

lete

De

tail

Co

mp

lete

De

tail

Co

mp

lete

De

tail

Co

mp

lete

De

tail

Co

mp

lete

Ag

ree

dD

eta

il

Ag

ree

dD

eta

il

Ag

ree

dD

eta

il

De

tail

Co

mp

lete

De

tail

Co

mp

lete

De

tail

Co

mp

lete

Ag

ree

dD

eta

il

Sco

pe o

f

Wo

rks

Es

tim

ate

Sta

ge

153

7.5.3 Estimating Development

Estimate Development - Flow Sheet

The flow sheet on the opposite page shows the inter relationships between

activities, inputs, decisions and outputs involved with Estimate Development. The

techniques used in estimating development are listed below.

Estimating Techniques

Listed on the next few sheets are the techniques that could be used when

preparing an estimate. Each technique is briefly described to help identify:-

The estimate stage at which the particular technique should be used as a

valid method;

The basic design information that is required to use each technique.

Reference should be made to the information status definition listed

previously.

It is recommended that at least two alternative estimating techniques are used at

each stage to compare budget estimates throughout the life of the project.

Estimating Technique - Unit Cost

The estimator multiplies the cost of a particular unit, by the number of units

required. The unit cost technique of estimating requires analysis of previously

completed similar projects. The cost of the particular unit is quantified with a

detailed description of the component parts with sizes, specification and the base

date. The technique relies on the expertise of the resource compiling the

information and is particularly relevant to repetitious work.

Estimating Technique - Factorial

The estimator can develop a total project cost, albeit for the earlier stages of a

project, using this technique. By applying a factorial estimate to those elements of

the whole project where only certain elements have been considered, the whole

project estimate can be produced. The estimating technique, factorial, is

particularly useful when used in association with unit cost and process module

estimating techniques. This technique relies upon a database of estimating

154

information from previously completed projects which have been analysed for the

factorial relationships between the elements

Estimating Technique - Process Module Unit

Is a development of the estimating technique - unit cost where the number of units

is multiplied by the cost of a defined process module. The analysis of the process

module unit, however, is prepared as an estimate for a complex multi discipline

equipment item and its support services. The process module unit detail can be

adjusted in estimated cost to reflect changes in the support services.

Modifications to the arrangement of the module can be easily made to provide

estimates when feasibility estimates are needed.

155

Fig 7.22 Estimating Development Flow Sheet

156

7.5.4 Estimating Techniques

If the project scope of works principally involves a large amount of labour resource

time, e.g. preparation of validation documentation, the estimate could be

calculated from a resource man hour forecast. A resource man hour forecast can

be established using a resource histogram and listing all the activities involved.

Project team resources should estimate the time required, to complete the

activities they are responsible for and to establish the overall man hour

requirement. Historical data for work of similar involvement should be used if

available. Where the manpower costs are significant for a project, the man hour

resource technique should be used, to check the estimated cost produced by

another estimating technique.

Estimating Technique – Building Cost by Volume (m3)

The cost of a building can be estimated using the spatial volume of the proposed

design. The spatial volume is calculated and the quantity multiplied by the

estimated cost for each cubic metre of internal space. The cost would include for

the building services contained within the structure. The method requires a

database of information from work of a similar nature analysed by volume (m3) and

is used solely for building works with a generic material specification. Used as a

check against another estimating technique or for early stage project estimating.

Estimating Technique – Building Cost by Floor Area (m2)

The estimated cost of a facility is calculated by multiplying the gross floor area of

the proposed construction, by an appropriate rate. The method requires a

database of information for previously completed similar work analysed by floor

area (m2). The floor area method is used where the particular specification for

construction materials and workmanship has not been fully developed. A detailed

specification however, can be generated to support the estimate stating the

assumptions made. Costs for building services can be estimated for using

historical data, (if available), but linear and unit elements should only be used for

comparison. Floor area estimates can prove misleading if information is not based

upon similar work.

157

Estimating Technique – Material Take Off

The estimate is generated from the scope of works by quantifying the design

information. The design information used should be the overall dimensions for key

components, with either a standard or particular specification for materials.

Building services are estimated for by using approximate metreages, sizes and

material specification and applying a composite rate per linear metre. A factor

must be applied to reflect the complexity of the service installation, with a definition

of the complexity assessed. This technique requires an intensive measurement

exercise and is used when a high degree of accuracy is required, and only when

the detailed design information is available.

Estimating Technique - Quotations

The estimate is compiled with quoted costs for specific scope of work from a

contractor or supplier. The cost will be for a particular scope of work including the

performance and material specification as detailed by the designer. The

contractor or supplier should be a specialist provider of the deliverable. The

quotation provided could be in the form of either a contractual commitment (see

Supply Chain Management) or an indication of the likely cost (budget). A number

of alternative quotations from competitive contractors or suppliers should be

obtained to confirm the level of pricing. Estimating technique quotations would

have precedence over any other estimating technique as the design will have been

thoroughly detailed to enable the quotation to be produced. Confidence in the

estimated project cost is increased, having obtained an indication of the cost for

the project scope of works from specialists reflecting the current market conditions,

rather than being based upon historical data.

158

Fig 7.23 Estimating Techniques Summary

159

7.5.5 Estimate Accuracy

Cost Estimate - Classification

The development of the project has been classified into eight specific stages. The

stages are listed in chronological order from earliest at the top of the list. These

classification stages are recognised as being started and completed at specific

milestones of project development. There is a direct link between these

milestones and the status of project design development. The completion of each

stage represents the point at which agreement on the status of the design between

client and project management team can be measured, against anticipated project

design development. The stages are used as the project milestones when funding

can be released to enable the project team to progress. Funds are released by

sanction from the client or the client‟s steering committee, based upon estimates of

cash flow expenditure to complete the future stages.

Funding Stages

For major projects it may be appropriate that three milestones of project

development are planned at which funding is released (i.e. stages 2, 3, and 4

listed in the table opposite). For most projects, typically only two stages are

required i.e. „pre-spend‟ and „full funding‟ (i.e. stages 3, and 4). Stage 4 – design

development, is recognised as the appropriate stage for sanctioning and providing

„full funding‟. Reference should be made to Project Management section of this

toolkit for funding arrangements.

Accuracy – Anticipated Level

The stages of project development have each been analysed for the accuracy of

estimates against achieved project costs. The historical data is presented for the

anticipated level of accuracy for each estimate at each stage. The accuracy of the

estimate can only be achieved if the information required at each relevant stage

has been provided and used.

The accuracy – anticipated level for each stage is presented as a band that

indicates the limits, in financial terms, of the acceptable difference between total

actual costs against the estimated costs for the project.

160

It is implicit that the additional accuracy allowance included in an estimate should

not be expended, as the client‟s requirement is to have the project objectives

delivered at the project‟s estimated figure before addition of this accuracy

allowance. It is equally possible that the final actual cost will, due to good project

management, be below the project estimate figure. The accuracy allowance is

purely a need for a fund that the client should recognise, but may consider using

elsewhere in his business operations.

Fig 7.24 Estimate Accuracy Checklist

161

7.5.6 Project on Cost

The total project estimate should include for all specific costs that are directly

associated with the delivery of the project. The project on cost checklist is

provided as a list of additional costs that are generally included in project costs

when capitalised by the client and are over and above the prime cost items.

Project on Cost - Design and Management

The project on cost for design and management are the costs associated with the

provision of:

This work could be undertaken directly by the client‟s own organisation, personnel

or consultants, either supporting the client‟s resources or completing the work as a

separate appointment. The client should consider the available contractual

recourses if the contractor fails to complete or does not perform, when entering

into any sub letting arrangement for any such work. The effort required should be

considered for the delivery of the whole project.

Design Resource responsible for detail dimension drawings,

information, preparing material and performance

Specifications, for process and facility to enable the

construction of the works to be completed to project

cost, time and quality objectives.

Project Management Resource responsible for the delivery of the completed

project to meet cost, time and quality objectives.

Construction Management Resource responsible for the construction of the works

to be completed to cost, time, and quality objectives

safely.

Health & Safety Resource responsible for the health, safety and

environmental issues associated with the project are

completed throughout the project duration.

Inspection Resource responsible for onsite and offsite inspection of

the quality of the deliverables that will be included in the

works.

Specialist Consultancy Resource responsible for undertaking specialist work

associated with the project, not included in other

elements of design and management.

162

This work could be undertaken directly by the client‟s own organisation, personnel

or consultants, either supporting the client‟s resources or completing the work as a

separate appointment. The client should consider the available contractual

recourses if the contractor fails to complete or does not perform when entering into

any sub letting arrangement for any such work. The effort required should be

considered for the delivery of the whole project.

Project on Cost - Project Specific

The project specific costs associated with the location of the construction site,

such as land purchase, labour and materials and import duties, carriage etc. The

listed items are not part of the prime cost and design and management costs, but

may include operational, revenue and start up costs, which the client will capitalise

as part of the overall project cost.

Discussion with the client‟s accountancy team should identify those costs that are

to be attributed directly to the project and included in the summary of project costs.

Project on Cost – Project Allowances

Allowances must be included for escalation and contingency costs. Information for

both of these allowances is considered in detail later in this section.

163

Fig 7.25 Project on Cost - Checklist

164

7.5.7 Value Management and Value Engineering

Value Management

Value management is a proactive, creative, problem solving (or problem seeking)

service, that maximises the functional value of a project by managing its

development from concept to use.

Value management is not a single method, but a framework within which proven

methods are systematically brought together to identify best value from projects,

products and services. The graphical representation opposite indicates some of

the different methods that could be employed at the various stages throughout the

project life cycle.

Value management service works by managing the development through audit of

all decisions, against a value system determined by the client at the start of the

project life cycle. The best time to implement the first value management

workshop is at concept design stage, when the major decisions are still to be

made.

The team for the value management study should comprise the key stakeholders

and a facilitator. If the key stakeholders are involved at an early stage, decisions

made will reflect, at least to some extent, their interests. Their involvement at this

stage should increase their commitment to ensuring the success of the project.

The facilitator is essential in managing the process of achieving consensus.

The main purpose of value management is to achieve a shared understanding of

the design problems and objectives.

Value management - benefits:

Improved value for money;

Improvements in function, performance and quality;

Improved business procedures, process and project lead times.

Value Engineering

Value engineering is an integral part of value management and is an organised

approach to providing the required functionality at the lowest cost.

165

It is a common misconception that the purpose of value engineering is to reduce

costs. Costs may well be reduced in the process of increasing value, but cost

cutting is not the main purpose, it is the elimination of unnecessary cost.

Value Management and Value Engineering - The Differences

„Value engineering exercise cannot be logically undertaken, until you have a clear

understanding of the nature of the problem and what you are trying to achieve.‟

„Value management is all about how you achieve this understanding.‟

Fig 7.26 Project Life Cycle – Impact of Change

Cost

Redu

ctio

n

Pote

ntia

l

Conc

ept

Deve

lopm

ent

Desi

gnCo

nstru

ctio

nO

pera

tion

&

Mai

nten

ance

Repl

acem

ent

Cost

Tim

e &

Life

Cos

ts

Valu

e Pl

anni

ngVa

lue

Man

agem

ent

Valu

e En

gine

erin

gVa

lue

Revi

ewCost

to

Chan

ge

Resi

stan

ce

To C

hang

e

Cost

Redu

ctio

n

Pote

ntia

l

Conc

ept

Deve

lopm

ent

Desi

gnCo

nstru

ctio

nO

pera

tion

&

Mai

nten

ance

Repl

acem

ent

Cost

Tim

e &

Life

Cos

ts

Valu

e Pl

anni

ngVa

lue

Man

agem

ent

Valu

e En

gine

erin

gVa

lue

Revi

ewCost

to

Chan

ge

Resi

stan

ce

To C

hang

e

166

7.5.8 Estimate Allowances - Escalation

Escalation is the calculation of the movement in finance needed to buy an item

between two points in time. The record of cost of an item at a specific point in time

can be presented as a factor of the actual cost, of that same item at a base date.

The factor is presented as indices for each point in time. A number of national and

international agencies publish indices for specific elements of activity both

materials, labour, plant and more complex work. Estimate allowance escalation, is

calculated by the use of indices to provide an allowance usually expressed as a

percentage to be applied to the base cost information.

Estimate allowances escalation, are used for two distinct elements of estimating:-

1. Uplifting historical cost data to current (base date) pricing levels;

2. Uplifting current (base date) pricing levels to when the cost will be incurred.

Estimate Preparation - Current Base Date

The following project elements should be estimated at current prices stating the

„base date‟ of the estimate, as the month or quarter of the year in which the

estimate has been prepared.

Prime cost;

Design and management;

Project specific costs.

Uplifting Historical Data

If the cost data to be used in the estimate is historical in nature, an escalation

allowance should be used to update the original data to the current base date, by

use of the indices graphs opposite. The information provided uses UK data and

the indices graphs shown are for:-

civil and building work source – BCIS;

mechanical and electrical materials and equipment source – ICE

(DTI - national

stats);

labour only work (Retail Price Index) source – DTI

(national stats).

167

Stage one, is to identify the relevant base dates for the original data and the

estimate. Both dates will have an index that can be retrieved from the relevant

graph opposite. Stage two, by subtracting the historical data index from the

current date index, will provide the index difference. Expressing the index

difference as a percentage of the historical data date index, will give the uplift

percentage to be applied to increase the historical data to current prices. The

current price should be used in the estimate and stated in presenting all cost

information.

Uplifting historical data – calculation

(Current data index - Historical data index)

Historical data index

Escalation =

Uplift Factor

x 100

1 (%)(Current data index - Historical data index)

Historical data index

Escalation =

Uplift Factor

x 100

1 (%)

168

Fig 7.27 Escalation – Indices for Uplifting Historical Data

169

Uplifting Current (Base Date) Pricing Levels

The estimate of costs should be compiled with all costs presented for prime cost,

design and management and project specific costs at current (base date). An

additional allowance for escalation should be made for the increase in costs,

anticipated between the current estimate base date and when the work will

actually be done and expenditure incurred. There will be cost differences due to

inflation and other economic influences. The escalation allowance used to uplift

the base date estimate cost is calculated from the forecast indices graphs opposite

and the information is provided for:

Civil and building work source – BCIS;

Mechanical and electrical materials and equipment source – I C E

(DTI - national

stats);

Labour only work (Retail Price Index) source – DTI

(national stats).

The relevant date for the uplift to be calculated to is generally taken at a point in

time two thirds through the anticipated construction period, i.e. when total cost

expenditure curve is at its steepest. The relevant date will have an index read

from the graph. Subtracting the base date index of the estimate from the relevant

uplift date index, will give the index difference.

Expressing the index difference as a percentage of the estimate‟s base date index,

will give the percentage to be applied to the prime cost, design development and

project specific costs elements. The estimate allowance escalation should be

included as a separate allowance in the overall project estimate summary. Any

future change in the construction period and thus any adjustment of the escalation

allowance can be easily calculated.

(Current data index - Forecast data index)

Current data index

Escalation =

Uplift Factor

x 100

1 (%)(Current data index - Forecast data index)

Current data index

Escalation =

Uplift Factor

x 100

1 (%)

170

Uplifting Current (Base Date) Pricing Levels - Calculation

Estimate Allowance - Escalation Post Sanction

Note. Escalation allowance calculation after sanction included in reports, should

reflect the actual progress of the project. As the project progresses, work will be

completed. The cost of the completed work will have used part of the escalation

allowance and will have been included in actual costs. The calculation of the

escalation allowance still to be incurred on the project should also use the same

uplift calculation method, but applied only to those activities still to be undertaken.

Fig 7.28 Escalation – Indices for Future

171

7.5.9 Estimate Allowance - Contingency

Contingency allowance should be included in estimates for those unforeseen items

that may have a cost and or schedule impact, but have not been included for

elsewhere in the estimate. At each stage of project and estimate development, the

expected maximum percentage addition allowances have been realised and

recorded through analysis of previously completed projects. The analysis

comprised comparing final actual project costs against the estimate, before

addition of contingency allowance, for each stage of estimate.

The percentage addition table and relevant contingency allowance stated should

only be considered as a check against the proposed allowance calculated from

assessment of all likely risks that could be incurred during the project. The forum

for assessment of all risks should be conducted through a risk meeting (see risk

assessment). The contingency allowance included in the estimate should be

expressed as a percentage that is supported in detail estimate information by the

risk evaluation register, fully populated for cost and time and used in a simulation

calculation. The estimate allowance contingency, used should be within those

bands of acceptable percentage additions, as tabled. If the allowance falls outside

of the relevant band, the estimate stage has not been achieved and further work

needs to be completed.

Contingency Allowances – Inclusions and Exclusions

As part of the estimate presentation at each stage of the project, there should be a

statement of whether those items that are optional and have been considered as

part of the risk assessment, are included or not. The checklist of contingency

allowances, inclusions and exclusion items that should be allowed or disallowed

when calculating the contingency allowance, is tabled on the opposite page.

Notes: Contingency allowances should be managed as a budget element and be

fully documented for each funding request. The manager of this budget is

generally the project manager. Contingency allowance should be used in

accordance with project change control.

Estimate Allowances – Risk Evaluation of Contingency

The estimate allowance contingency calculation should be reviewed at each stage

of estimate classification, as the project develops. The estimate allowance

172

contingency calculation, at initial stages would comprise only a basic outline

consideration of likely risks to the project. As the project progresses a more in-

depth consideration of the likely risks should be made by the project team. The

recommended detail assessment for risk evaluation reviews is included in the

table, for each stage of the estimate.

Estimate Allowance – Design Development

Design development is a „growth‟ allowance made when estimating the prime

costs of the project. The design development allowance is the estimator‟s

assessment of how much the design is likely to grow, when the actual construction

design is detailed against the current status of design. Growth can be either in

quantity, performance or specification quality. The design development allowance

should be included in the estimate - prime cost quantities or rates. Historical

analysis has shown that the „growth‟ in design from detail design stage can

increase by up to 10% due to missing detail, information or specification provided

for estimate production.

Design development is an allowance for the current shortfall in design for the

known scope and whilst the spatial arrangements are static, the contingency is a

separate estimate allowance for unforeseen occurrences or additional changes to

the scope of the project.

173

Fig 7.29 Estimate Allowance – Contingency Checklist

174

7.5.10 Risk Management – The Process

Risk is the uncertainty inherent in plans and the possibility of something happening

that can affect the prospects of achieving the project‟s objectives. Failure to

identify and implement a suitable mitigation strategy could result in:

Unexpected financial loss;

Unexpected schedule delay;

Reduced quality, performance or acceptability;

Impaired safety (design, construction, end use);

Potential for prosecution.

In general terms, the risk management process comprises:

Identification of all potential risks to the successful completion of the

project;

Assessment of the consequences and impacts of the risks should they

occur;

Identification and the key project risks;

Classify each risk so that they can be grouped together for easier

management;

Development of a mitigation strategy to reduce or eliminate each key risk as

far as possible;

Assessment of how much, in time and money, it will cost to reduce or

eliminate each risk, i.e. is mitigation cost effective?

Estimation of optimistic, most likely and pessimistic cost and time ranges for

each significant risk, for use in simulation modelling;

Assessment of whether the risk can be transferred to other project parties;

Develop a plan to manage the residual risk and ensure identification of any

new risks and retirement of old risks;

Assign an owner to each risk. The owner will be responsible for managing

the risk.

The process must ensure that:

All identified risks must be listed;

All relevant information in respect of each risk is recorded;

A method for sorting risks in terms of priority is available;

Mitigation plans are recorded for each risk;

175

The „owner‟ of each risk is recorded;

Quantified cost and time impacts are recorded;

An auditable record of all relevant information for each risk is recorded.

A generic diagrammatic flow sheet of the risk management process is shown

opposite and should be considered throughout the whole project process.

From the initial risk evaluation workshop, preferably undertaken before calculating

a contingency allowance in any estimate, the initial model simulation, inclusive of

the detailed estimate information, should be completed and considered against the

estimate allowance contingency factor, to be included in the estimate.

Fig 7.30 Risk Management – Flow Sheet

176

7.5.1 Estimate Format – By Activity

Estimating Formats

Estimates should be presented throughout the development of the project in a

standardised approach. There are however, two methods of presentation to suit

the cost information available at the point in time and are determined by the

progress of the procurement strategy. Both standard approaches are presented

as templates in this section of the toolkit.

Estimating format by activity is used when the procurement strategy and the

contract scopes have not yet been agreed. By activity approach is used in initial

stages of Estimate Development, using the standard format presenting the cost

information and where possible, used throughout the project and reconciled as

historical data as recorded in the Completion section of this Toolkit.

Estimating format by procurement strategy is used when the procurement strategy

and scope of work for each contract is agreed. The project team may prefer to

review cost progress by these contracts and thus, the estimate summary by

procurement strategy and summary cost report, have been prepared to reflect the

contracts rather than the discipline activity content. The information presented in

this form reflects the procurement strategy for the project which is more than likely

unique. The historical data representing the procurement strategy requires

significant interpretation with potential for mistake and thus, should be avoided and

presented as estimating format by activity. The contracts are activities that can be

coded in accordance with the activity coding system to be used on the project.

Estimate Components

Each project should be considered for the following estimate components:-

Prime costs… see below;

Design and management… see project on cost;

Project specific… see project on cost;

Project allowances… see project on cost.

177

Estimate Component - Prime Costs

The estimate component prime costs, comprises those activities listed as

deliverables in the project objectives and includes the associated labour, plant and

material used to produce these items. Included in the prime costs should be an

allowance for the contractor‟s or supplier‟s indirect costs for supervision,

management, construction, plant and head office overheads and profit needed to

complete the activity.

Additional prime costs may be provided by clients own labour etc. and should be

considered as a contractor or supplier. The calculation of the estimate component

- prime cost should be undertaken using the estimating techniques listed earlier in

this section of the toolkit.

178

Fig 7.31 Estimate Format – Summary by Activity

179

7.5.12 Estimate Format – By Procurement Strategy

Estimate component prime costs, should be allocated into the following elements:

Process Module Items of process equipment and their directly

associated services, which are identified as

specific modules and together are the whole

process.

Module Support Services linking the individual process modules

into the whole process.

Building Envelope The structure and or building required to enclose

the whole process inclusive of „building services‟.

Infrastructure Services and external works within the boundary

of the construction site needed to complete the

project.

Temporary Construction Works Items of a temporary nature needed to install the

permanent prime cost items to complete the

works, inclusive of temporary accommodation

and service requirements of the project team

during construction.

Estimate component - prime costs should be presented as discipline costs, listed

in columns A – I.

7.5.13 Estimate development – project budget responsibility

After approval by the client or the client‟s steering committee, the sanctioned

estimate will become the project budget for completing the project. The overall

project budget will be the cost against which the project manager will be monitored

and judged for success in meeting or not exceeding the project objective for cost.

In turn, the component elements of the project budget will be the cost against

which the project team resources responsible for each particular activity will be

monitored and judged for success.

It is therefore, important that the responsible project team resources are involved

in preparation of the estimate and acknowledge that they are responsible for the

delivery of their activities to the required cost, time and quality requirements.

180

The estimate information is important throughout the whole project duration. It is

this information that is regularly reviewed and updated during estimate

development and subsequently used in preparation of budgets. The budget

information is the basic details that Progress Measurement, Cost Management

and Reporting are monitored against and for effective Change Control, adjusted

during the remaining phases of the project after approval.

Fig 7.32 Estimate Format – Summary by Procurement Strategy

181

7.5.14 Cash Flow Forecasting - Graphical

Cash Flow – Forecasting

As part of Estimate Development the client will require information on when

expenditure is likely to be incurred. The client will need this information to advise

financing bodies of the need to provide funds at specific times throughout the

project duration, to satisfy the needs of contractors and suppliers. In fact, the

availability of funds may dictate when activity can take place or impact on the

nature of the procurement strategy. The calculation and presentation of project

cash flow forecasting can be completed by a number of techniques. The

forecasting of expenditure may also be required on regular monthly or annual

(financial) periods to accommodate client‟s accountancy requirements. Either of

the following methods of presenting the costs to be expended over the duration of

the project can be used, but are dependant upon the information available.

The cash flow forecast is calculated and presented as a function of expenditure at

regular intervals. For purposes of the example, the interval is provided as monthly.

Graphic representation - used when project schedule milestones have

not yet identified other than start and finish dates. Using an industry

accepted graphical method of calculating how the cumulative cost will be

expended;

Activity based - used where project schedule milestones and detailed

estimates for activities have been identified.

Graphical Representation

A typical cash flow forecast graphical representation („S‟ curve), is shown opposite

and can be used to calculate the information for the client‟s initial requirements.

The information needed to produce this graphical representative is the overall

project start and finish dates and the overall project cost estimate.

The project duration is calculated as the difference between the project start

(significant expenditure commences) and anticipated completion date (all costs

have been incurred). The project duration is used to adjust the timescale („y‟ axis)

of the graph. The overall project cost estimate is used to adjust the cost scale („x‟

axis) of the graph.

182

By entering the two variables of project duration and project cost estimate, a

typical graphical representation will be generated from the percentage allowances

for time inbuilt into the traditional „S‟ curve graph. The graph assumes that

funding is being expended at the steepest gradient at a point in time two thirds

through the construction period.

Creating a project profile from the example graph shown on the opposite page

should be used as follows:

The project duration should be calculated using the start and completion dates and

calculating the duration between them, expressing this duration in equal intervals

as required.

The user should insert the start date in the appropriate spreadsheet cell. The start

date will automatically register in the data table. The table should be manually

adjusted for the number of equal intervals. The table should be manually adjusted

to fill in the interval labels that will appear on the project duration axis. The table

should be manually adjusted to fill in the percentage figures, if the overall duration

changes. The percentages should be used to create the project graph of an

identical gradient as the example. The formula to calculate the sum for additional

intervals in the data should be copied from the existing data table.

The project cost estimate should be inserted in the appropriate cell of the table.

The graph will be automatically calculated from the information provided.

183

Fig 7.33 Cash Flow Forecasting – Typical Graph

184

7.5.15 Cash Flow Forecasting – Activity Based

As the project develops the estimate and schedule information is improved and

details of activities become available, cash flow forecasting using project activities

and their information should be used. The information used to create the cash

flow forecasting – activity based method, is a more accurate method of presenting

the forecast of expenditure for a project, than the graphical calculation. This

method is usually undertaken at the completion of the design detailing phase of a

project, when the detailed cost and schedule information is available.

The cash flow activity based forecast template opposite, can be used by

populating the spreadsheet with detailed information for all the activities of the

project. The number of activities to be considered in the spreadsheet is dependent

upon the degree of accuracy required, and the information available. Each activity

is considered for its estimated cost (exclusive of escalation and contingency

allowances) and the timescale over which costs will be incurred. A profile of

forecast progress at required regular intervals throughout the project should be

used to allocate cost for each interval for each component. The profile of forecast

progress for each component can be calculated from a typical graph, or if specific

milestones are known, the relevant interval costs.

The spreadsheet should be reconciled by comparing the sum of the cost allocation

for each interval, against the anticipated final cost for each component. Any

variation that is identified between the sum of the interval costs and the component

cost should be considered and the allocation of costs reviewed and adjusted, until

the figures match.

Estimate allowances for both escalation and contingency should be allocated and

added to the components cost total, by multiplication of the likely estimate

allowance percentage for each interval. The sum of the interval allowances should

not exceed the total allowance. Review and adjustment should be made to

reconcile any difference.

The cash flow activity based forecast, calculated using the spreadsheet, could be

presented as a graphical representation, using the total interval costs for the

project to populate the data table of the typical graph described on the previous

page. An example with stacked bar chart for both monthly and cumulative

expenditure is attached to the cash flow activity template.

185

Fig 7.34 Cash Flow Forecasting – Activity Based Summary

186

7.5.16 Foreign Orders and Currency

Projects that have contractors or suppliers located outside of the immediate

country in which the project is to be constructed, or where payments are to be

made in differing currencies to the currency of the estimate, need to be tracked for

any changes. When there is any opportunity for variation in foreign currency to

impact on the overall project cost it is important to monitor any fluctuations for the

movement of exchange rates and payments to be made throughout the project

duration. At any stage in development, the estimate may well be based upon

techniques that involve foreign currency data or contractors and suppliers. The

estimate documentation at that stage should include a statement with respect to

those items that will be paid for in other currencies, to the currency of the estimate.

The foreign orders and currency statement will show the current information

included in support of the estimated cost. The foreign orders and currency

statement should identify all those items for each activity expressed in the

currency of the estimate. The objective of the foreign orders and currency

statement is to realise the exposure to currency fluctuation and to plan how such

costs will be tracked as the project develops.

The information required for the tracking of the foreign orders and currency is as

follows:-

The valid date of quotation;

Currency of the tender;

Quotation (in currency of payment);

The exchange rate used;

Value in currency of estimate.

The spreadsheet opposite can be used to calculate the value in currency of

estimate, by entering the value of the tender in the quoted currency and the

current exchange rate.

The foreign orders and currency statement will be completed by referencing with

the WBS. code, quotation reference, supplier and description of the item or

activity. A column is provided on the statement to add any further comments

relevant to each order. (i.e. request status for early acquisition of monies in the

currency of payment).

187

Foreign Orders – Contractual Arrangements

The contractual arrangement between client and contractor or supplier is a binding

agreement and should state the agreed cost or the method of calculating payment

in a particular currency. If the payment for work or items to be supplied are in the

currency of estimate for a fixed price, it will be the contractor or supplier who is at

risk in the event of exchange rate fluctuation. It is worth monitoring the impact of

exchange rate fluctuation on such items, as the information may be a pointer on

the performance of the contractor or supplier.

With the information on foreign orders and currencies prepared, the overall

exposure in the event of exchange rate fluctuation can be assessed. The options

open to the client are to:

Alter terms of payment in conditions of contract, to benefit forecast exchange

rate fluctuations;

Buy foreign currency early to pay for work to be completed later;

Pay in local currency only.

188

Fig 7.35 Foreign Orders and Currency – Estimate Summary

189

7.5.17 Estimate and Schedule Verification

Throughout the development of any project, estimates and schedules will be

produced using a variety of techniques, as described earlier in this section. In

order to assess the validity of the estimate or schedule at each stage of the

project, it is useful to employ a structured approach to demonstrate the basis of

information available and the approach used in producing the estimate. The

estimate and schedule verification report provides such a structured approach.

The templates shown opposite are:

Estimate and schedule verification report – draft cover sheet;

Estimate and schedule verification report – draft contents list.

The estimate and schedule verification report draft contents list is an example of

the elements that should be considered in the report.

Section One – Introduction

Should include background to the project, terms of the appointment, initial

discussions with relevant resources, objectives of the assessment, i.e. extent of

the scope, planned timescales and execution plan to review the information that is

to be provided.

Section Two – Basis of Estimate Information

Using the 15 item checklist basis of estimate, shown earlier in this section of the

toolkit, to assess the estimating stage from the information available. Conversely

the confidence level of the anticipated stage of project development can be

reviewed by assessing actual information made available against those planned.

Section Three – Basis of Estimate Verification Production

Describes the structure of the estimate, the elements of the scope, basis of

expressing the estimate in cost and man hours and how the labour, plant,

equipment and materials should be demonstrated when reviewed in assessment.

190

Section Four - Commentary on Detail of Estimate Verification

Describes, in detail, the information that was made available, used in estimating

each element of the project scope, and the technique used in quantifying each

element from the information made available. In addition, a review should be

made that the proposed method of calculating cost and man hour content and the

quantification technique, have in fact been applied.

Section Five – Confirmation of Inclusions and Exclusions

Details of those items that have been included or specifically excluded from the

estimate. The initial source of how these items have been considered should be

provided by the estimating contractor or consultant. Items that need to be stated

as to how they have been treated in the estimate are those that have, by

experience, been avoided or missed from previous estimates, but recognised as

requiring consideration in the full scope of this estimate. By including this

statement, the status of such items, are clearly identified as to their inclusion or

exclusion. If such items have been excluded by the contractor the client will need

to take account if such items need to be included in his overall estimate for the

project.

Section Six – Conclusions and Recommendations

Details of the findings of the estimate and schedule verification exercise and the

agreed project team‟s recommendations, as to immediate or future actions of how

to improve the status of the estimate and schedule, to meet the project‟s

objectives.

191

Fig 7.36 Estimate and Schedule Verification Report

192

7.6 Cost Management Process

Cost Management Process – Flow Sheet

The cost management process flow sheet shows the inputs, actions, decisions and

outputs associated with the Cost Management activity.

The key to successful cost management is preparation and an appreciation of

what is wanted at schedule and estimate development and initial supply chain

management stages of the project. The requirements to be provided by the

project team resources can, therefore, be described in project execution

procedures and used in contract preparation, to request the information needed for

cost management. This will avoid project team resources wasting effort on

providing information that is not needed, or having to demand information during

the project that will require additional effort than that budgeted for, or resources

having to change their information production techniques.

Cost Management Process

The purpose of cost management is to ensure that „value for money‟ is considered

together with the cost objectives throughout the project. The project‟s cost

management system should be forward looking and not just a mechanism for

monitoring those costs that have already been expended. The cost management

system to be used on a project is the selection of those techniques thought, by the

project team, needed to:

Manage budgets,

Monitor actual cost,

Forecast future costs,

Manage risk.

The process of cost management is a combination of these four components:

Cost Management – Budget

Original budget

This is the estimate figure sanctioned by the client, as the approved maximum cost

to be expended for the project as a whole and its component elements. Clear

193

definition is important to identify the responsibilities of all project team resources

and what is to be included for their particular budget and scope of works. A clear

definition of requirements should be included in project execution procedures.

Current Budget

The original budget is adjusted for the impact of any approved changes as the

project develops in accordance with the project change control procedures

Budget Review

Current budgets should be reviewed throughout the life of a project to identify any

variance between current budget and the anticipated final cost of each component

or activity. It is important that there is an understanding by the project team

resources of the work completed to date and remaining project activity, within the

scope of work.

Control Budget

At specific milestones in the development of the project, the current budget may be

required to be formally reviewed to reassess the sanctioned budget, if approval

had been made too early in the project‟s development. The estimating milestones

are generally at points in time in the development of the project to request further

funding from the relevant approval authority. On receiving approval of the relevant

funding, the budget is „frozen‟ and the responsible project team resource should

control the expenditure of funds against the new budget.

194

Fig 7.37 Cost Management Flow Sheet

195

7.6.1 Cost Management – Monitoring Actual Cost

Actual Cost

These are those costs that have been paid or are currently required to be paid as

part of the project by the client, for work completed. These costs may be

payments to contractors, suppliers, etc. or as transfers for work completed by own

organisation, and are to be recorded as project cost.

Original scope award

The original order value awarded by the client to the consultant, contractor or

supplier for the particular element of work. The order value should be the same as

the contract award value.

Agreed Variation Orders

The variations to the original scope award agreed between the consultant,

contractor or supplier and the client‟s authorising party to the order. The variations

are agreed when the cost of the change has been evaluated and accepted by both

parties to the contract.

Current Scope Award

The summary of the original scope award and the agreed variation orders. The

current scope award is, therefore, the current anticipated cost to the client if the

consultant, contractor or supplier was to complete the activity.

Auditing

The process of selecting a reported cost item and examining the supporting detail

information to confirm that the claimed amount for that particular item is correct.

Sampling

The cost management technique that involves examining a portion of the current

design to review the current „growth factor‟ (design development allowance, see

Estimate Development) and is considered against the original estimate allowances

196

for quantity and cost. By assessing a portion of the design, sampling can be

undertaken throughout project development.

Trending

This compares the anticipated plan for costs and resources against actual, by

graphically plotting cost statistics over regular time intervals for the project.

Progress, in financial expenditure, to a point in the project, can then be compared

against the anticipated planned expenditure to that date to identify trends and

variances. The graphical presentation should be considered for the reasons why

there is a trend or variance.

Cost Management - Project‟s External Orders

The purpose of monitoring actual costs against budget forecasts is to advise the

project team of the progress of orders or activities against what was anticipated to

have been expended, at that point in time. The exercise should involve a regular

formal review of the anticipated final cost (AFC) forecast for each order or activity,

by collating all the relevant information.

The template opposite should be used to complete the presentation of project‟s

external orders information. The information to be provided should be agreed with

the project team and prepared for the particular budget under consideration. The

template is flexible, in that it can be used to reflect the detail of the project by either

contracts or areas.

The template should be populated with information referencing the project order

number, the name of the appointed consultant, contractor or supplier, with a brief

description of the work for each budget area. The template should include work

that is still to be ordered for the budget area to reflect the whole project status.

197

Fig 7.38 Project’s External Orders – Progress

198

Cost Management – Value of Work Done

Value of work done (VoWD) - is the assessment in cost terms of the current „value‟

of the work completed at that point in time. The calculation of „value‟ can be either

undertaken using the techniques listed in Progress Measurement and converted

into cost, or evaluated from invoices, or interim assessments. The contractual

agreement with suppliers and contractors etc., should state how the work will be

evaluated at interim milestones in the contract time scale. The contractual

entitlement and the value of work done (V o W D) at interim assessment reviews

will generally differ. To complete the assessment of „value‟, consideration should

be made for the „real cost‟ by assessing the benefits that an activity contributes to

the project objectives. The assessment of these benefits is made by project team

resource opinion, rather than fact. Some contracts make payments for only

completed activities and unless progress information is provided on all activities,

the payment route will not reflect the overall progress performance. VoWD.

progress assessment is an important measure of how the activity and the project is

performing. The exercise of calculating V o W D requires significant information

and effort to complete. There is a time delay in calculating the V o W D from the

cut off date for each project interval, as there are resource interfaces and

numerous documents to be created and collated. The V o W D cannot without

significant manipulation and further effort be used to compare man hour

performance, (earned value). The effort required for gathering information should,

however, be coordinated between cost and schedule representatives.

Monitoring actual cost and budget cost templates are provided for the project‟s

external orders, client‟s internal costs, and details of foreign orders that should be

used to compare actual and budget costs.

Monitoring actual cost and value of work done is specifically provided to give

the client reconciliation between costs reported by the project and those contained

in any accountancy system.

Cost Management - Client‟s Project Costs

The client‟s own resources may undertake the following scope of the project work:

some or all of the construction activities;

some or all of the commissioning activities;

operational works in the vicinity of the execution of the project;

199

some or all of the materials;

some or all of the project construction management.

The costs associated with this content of the project work, as listed above, may be

acceptable for „capitalisation‟. The client‟s accountancy team should advise what

elements can and cannot be capitalised. The method of recording the cost as

client‟s project costs will probably be by internal transfer. To present and monitor

progress for the whole project cost at interim assessment, all costs will need to be

provided.

The template should be used to record allocation of client‟s project costs and the

make up of the information is identical to the project‟s external costs template, for

information to be provided.

200

Fig 7.39 Monitoring Actual Cost – Internal Costs Progress

201

Cost Management – Forecast Future Cost

Techniques used to forecast future cost are the same techniques used to prepare

estimates, as listed in Estimate Development. The technique to be used depends

upon the information available. It is anticipated that the information used to

forecast future costs will be based upon information with greater detail and

accuracy, than provided at budget estimate stage. In addition, sampling and

trending techniques considered earlier in this section, can be used to calculate and

make graphical presentation of any changes since budget approval. The

important aspect of forecasting future cost is realising the full impact of any change

on the original plan.

Anticipated final cost (AFC) is the current forecast of future cost plus cost to

date, this will give the anticipated final cost of an element or project as a whole and

should make provision for :-

Change orders that are to be approved, but are yet to be agreed;

Site or field instructions made, but are not yet agreed;

Future site instructions, allowance for unknown;

Claims for additional payments, but are not yet agreed.

Forecast spend to date – is the forecasted cost to be incurred against an activity

at the particular point in time. The forecasted cost will be based upon the original

budget and cash flow expenditure calculation prepared in Estimate Development.

The forecast spend to date should be revised at each regular review to reflect the

current approved budget that includes the approved additions for the project and

activities. The forecast spend to date should be compared against VoWD. to

monitor progress. Differences between the two figures showing financial variance

in anticipated progress.

Anticipated variation orders – are a record of additional cost information relevant

to a particular activity for variation in work that is known about, but has currently

not been dealt with formally. The anticipated variation orders should be kept to a

minimum and are a reflection on the inefficiency of the project to manage change.

Anticipated final cost – is the summary of the current scope award and the

addition of the anticipated final cost. The anticipated final cost is the current

forecast of the final cost of all activities. The anticipated final cost should be

compared against the approved sanctioned budget. The differences between

202

these two figures showing the accuracy of the approved budget and the

outstanding costs that are not fully managed.

Cost Management - Management of Risk

The system employed for Estimate Development to manage risk should be

maintained throughout the project. The project team should arrange to consider, at

regular intervals, the relevance of previously identified risks, if other risks are

materialising and to review the progress of agreed mitigation strategies used to

offset potential risks. As part of the review, the project team should consider the

potential cost and time implication if a risk is realised. The assessment review of

each item should be used to re-evaluate the current contingency allowance, to be

retained as the required funding for the project. The contingency allowance should

be included in regular cost reports.

Rundown of contingency is the presentation of risk and contingency allowances

as the project develops. The information can be presented in two ways as follows

and explained in detail later in this section:

Contingency expenditure tracking the cumulative expenditure of additional

work costs summarised from change control;

Risk rundown tracking the contingency allowances still retained on

a project, expressed as a percentage of the current

AFC.

7.6.2 Risk Register and Progress

The output from the risk workshop is the risk register. The impact assessment for

each risk is considered using a matrix with the ranges specifically agreed for the

individual project. An example of which is tabled below. The matrix is used for

each review at these regular workshops.

Fig 7.40

Score Cost Time

5 Very High 71% - 100% > £65k > 10 wkg days

4 High 51% - 70% £40k - £65k 7 - 10 wkg days

3 Medium 31% - 50% £15k - £40k 4 - 7 wkg days

2 Low 11% - 30% £5K - £15k 2 - 4 wkg days

1 Very Low 0% - 10% < £5k < 2 wkg days

Probability

Scoring Matrix

203

The risk register comprises:

Risk ID The discrete risk identification number.

Risk Description The specific description of the risk.

Category The allocated discipline for each risk item.

Cause The potential cause of the risk concerned.

Effect The anticipated impact resulting from the risk.

Mitigation

Strategy

The agreed strategy to be implemented to cope with or

avoid the specific risk.

Risk Owner The designated owner of the risk and responsible for

implementing the mitigation strategy.

Likelihood and

Ranking

The project team‟s assessment of the likelihood of the risk

happening.

Cost Impact The assessed cost impact if the risk was to occur

expressed optimistically, most likely and pessimistically.

Time Impact The assessed impact to the project plan if the risk was to

occur expressed optimistically, most likely, pessimistically.

Fig 7.41

7.6.3 Foreign Orders and Currency

Projects that have contractual arrangements with payment terms that are subject

to fluctuations in foreign currency exchange rates require regular monitoring for

assessment of any cost variance. The nature of projects now has numerous

1 Unforeseen poor ground conditions Civils Surveys miss pockets of

contaminated ground

Additional costs and for the

removal and disposal of

contaminated ground

Carry out additional boreholes and trial

pits. Review all available historical

information

2 Insufficient skilled client resources Mgt Other similar projects stretches

the clients available resources

Potential delays and additional

costs to bring in external

resources

Review roles and responsibilities and

assign known personnel to identify gaps

3 Risk of finding unknown services in the

proximity

Civils Drawings are accurately Additional costs for testing and

isolation, removal and disposal

Review all available historical

information. Hand dig trial pits in

suspect areas

Risk ID

NoCat. CauseRisk Description Effect Mitigation Strategy

Risk

Ranking

Risk

RankingOptimistic ML Pessimistic Optimistic ML Pessimistic

DGH 80% 4 2 High Medium Cost High £52,300 £64,290 £77,000 1w 2w 4w

DFS 50% 2 5 Medium High Time High £26,500 £34,800 £46,000 2w 5w 8w

RHG 20% 2 3 Low Medium Time Medium £23,900 £39,800 £78,500 2w 4w 10w

Cost Time Time Impact

Combined Ranking

Cost Impact

Cost

Likeli

hood

%

TimeOwner


contaminated ground



contaminated ground



information





resources




proximity





suspect areas

Risk ID


Risk

Ranking

Risk






Combined Ranking

Cost Impact

Cost

Likeli

hood

%

TimeOwner


contaminated ground



contaminated ground



information





resources




proximity





suspect areas

Risk ID


Risk

Ranking

Risk






Combined Ranking

Cost Impact

Cost

Likeli

hood

%

TimeOwner

204

contracts, undertaken as a complexity of foreign country and currency

involvement. To avoid significant additional funding when bills are to be paid it is

important to regularly consider the current anticipated outturn costs compared

against planned budget costs.

Estimate Development prepared an initial statement of those orders that fall in this

category and budget allowances are included in the overall project estimate. The

template on the opposite page is a development of the statement previously

prepared. The following information should be complied for each order at regular

intervals, as agreed with the project team.

Foreign Orders and Currency – Information

Supplier Provide details of the client‟s order number or reference, the name of the

supplier and brief description of the work referenced against the particular

project activity code.

Budget Provide the following details of the particular activity or work element:

Value in Currency of Payment - is the original estimated cost of the work

element to be paid to the supplier. This cost estimate may in fact have

been a quotation from the supplier. The budget value should be the work

content included in the project estimate original budget for this activity.

Valid Date of Quotation - is the base date at which the original budget

estimate was prepared, and if the estimate used a quotation, the date of

the quotation should be the estimate date.

Exchange Rate at Estimate Date – is the relevant exchange rate

between the currency of payment and the currency of estimate and should

be included. The information provided by an approved source.

Value in Currency of Estimate – is the value included in the original

budget for the work activity. The original budget should be the value in

the currency of payment, multiplied by the relevant exchange rate.

Current provide the following details for the „cut off‟ date:

Current Exchange Rate is the relevant exchange rate as advised by an

approved source for the „cut off‟ date.

Anticipated Final Cost is the recalculation of the original budget

multiplied by the current exchange rate and is the current estimate of the

funds that the client will need to pay for the completed work, expressed in

the currency of the project budget.

Variance is the difference between the original budget and the current

anticipated final cost.

205

Notes: Each change to the original budget scope of work should be subject of a separate

calculation with reference made to the estimate, quotation date, and the relevant

exchange rate.

The variance of the trend between the two currencies involved is seen to be a deficit, but

could be offset by purchasing foreign currency earlier than required.

206

Fig 7.42 Foreign Orders and Currency - Progress

207

7.6.4 Client‟s Cost Ledger - Reconciliation

Client‟s Cost Ledger

The client will use an accountancy system that will produce internal cost reports.

Experience has shown that the client‟s system may contain different cost

information from that known and reported to the project team. The client‟s

information should at any point in time be interrogated, in either electronic or hard

copy form, as a document referenced as the client‟s cost ledger.

The client‟s cost ledger may differ from project team‟s knowledge due to a number

of reasons:

Delay in the client‟s system of recording cost information in connection with

placement of orders, stating order value and current anticipated final cost.

The template on opposite page excludes this information;

Delay in recording interim evaluation of work done. Interim evaluation

involves assessment and „cut off‟ dates before the formal interim payment

date, an invoice is then raised and payment made. The period of time from

„cut off‟ to payment can be between four to eight weeks depending upon the

contractual agreement. The client‟s system will probably only record cost

information for the payment as a cheque is paid to the relevant party

which will be after the cost information is expected to be reported to the

project;

The project‟s cost management system may require that information is

produced for inclusion in progress reports that reflect the most up to date

cost position. The basis of the progress report will be based upon more up to

date information than costs associated with interim evaluation. The required

information will be produced from using progress measurement techniques

that will assess actual work completed at a point in time later than the date

used for payment;

The contractual arrangement between the client and supplier may contain

conditions with regard to payment, which are not related to interim

evaluation, but are governed by stage or milestone achievements. Payments

recorded for such contractual arrangements on the client‟s system do not

reflect cost progress;

Error inputting entry of cost information in the client‟s system.

208

Client‟s Cost Ledger - Reconciling

The elements that should be considered are as follows:

The work is the detailed activity against which the project team have

selected to collate cost information. Cost information will be a series of

instructions to resources to undertake the activity. Generally instruction will

be a client‟s order for the particular element of work;

The client’s order identified by a unique reference attributed to the work and

this should be used. The checklist of what should be included in an order is

provided in the Supply Chain Management section of this Toolkit;

The client’s cost ledger is the information provided from the client‟s

accountancy system of the current record of cost for the particular client‟s

orders or project;

The project’s cost report is the cost information collated by the project

team at a specific point in time. The information will include information on

budgets, order values, value of work done and forecasted final costs;

Reconciliation the client‟s cost ledger and the project‟s cost report should

be compared to identify variance between the project elements. The

differences should be identified on the template opposite with commentary

explaining each difference. In the example VoWD and payments have been

compared.

209

Fig 7.43 Client’s Cost Ledger – Reconciliation Report

210

7.6.5 Accruals Calculation

Accruals - Definition

Accruals are the anticipated cost liability of the client for project work from a

current point in time up to a future point in time. Careful consideration is needed to

identify exactly what is meant by „accruals‟, as clients vary in their interpretation as

to what should be included. Confusion arises over inclusions for accruals, as to

what will be paid or work done by a particular date and those costs not yet paid,

but due for payment within a specific time period. The relevant point in time will be

a requirement for the client‟s business needs. The accrual‟s date will be either for

the client‟s financial year, quarter or month or for a calendar date.

Accruals - Calculation

The initial information that will need to be agreed with the client‟s financial advisers

will be to:

Confirm the accruals „cut off‟ or relevant date;

Confirm what can to be included as an accrual;

Confirm the current status of cost information recorded by the client‟s

accountancy system.

The accruals calculation statement should be prepared and summarised as

follows:

Project Components should include prime cost, design and management,

project specific and allowances. The prime cost component should be

presented either by activity or contract strategy. Each component should

be considered for its cost profile for regular intervals over the project

duration;

Value of Work Done compiled for current cost assessment as described

earlier in this section;

Anticipated Final Cost compiled as the current forecast of the total final

cost of completing the particular element and project. The AFC figures

used should equate to the current reported cost information;

Future Period Cost is the implementation of confirming accruals „cut off‟

date and inclusions. The template has been prepared for calculation of

211

accruals distributed, in this example, at monthly intervals and is the

forecast of the cost to be expended up to the accruals „cut off‟ date;

AFC Check The A F C should equal to the sum of VoWD plus cost

allocations over the accrual period and future period cost. It is useful to

make a comparison of the reported A F C and the sum of the elements as

described to ensure that there is no difference and error in the calculation

of accruals figures reported to the client‟s financial team.

Accruals – Presentation

Accruals information should be presented either as

The accruals calculation template as shown opposite

or

Graphically using an adaptation of the forecast cash flow curve prepared in

Estimate Development.

212

Fig 7.44 Accruals Calculation - Report

213

7.6.6 Cash Flow Forecasting – Tracking Costs

Tracking cost movement is a Cost Management technique used to compare

graphically, actual cost against planned cost. Tracking cost movement can be

applied to a number of project cost elements:

Cumulative Expenditure - monitors the V o W D cost information for

individual contract, particular activity, or project as the work progresses;

Anticipated Final Cost - monitors throughout the project duration on a

regular basis the project team‟s forecasts of final cost of the contract, activity

or project;

Contingency - monitors the contingency percentage allowance included in

cost forecasts for contract, activity or project as the work progresses;

Change Expenditure - monitors the allocation of cost to changes formally

approved by the project change control procedures as the project develops;

Risk - the user records the level of risk to the project, in cost terms,

considered by the project team as the project develops. The information is

produced from the risk evaluation log and should be used as an alternative to

consideration of contingency.

The graph shown opposite has been compiled for a whole project, but the template

could be customised for an individual activity or contract as required. The graph

was initially prepared in Estimate Development as forecasting cash flows. The

compilation of the cost information should be made from Progress Measurement,

Cost Management and Reporting techniques.

Tracking Costs - Cumulative Expenditure

Tracking cumulative expenditure is the comparison of actual against planned

expenditure over the duration of the contract, activity or project expressed at

regular assessment intervals. The actual expenditure is the cumulative summation

of expenditure up to the current assessment point.

Forecasting cumulative expenditure is anticipating the costs to go from the current

assessment point required to complete the activity, contract or project. The

calculation of cost to go could be based upon information provided by the

consultant, contractor or supplier as the current forecast of expenditure to go and

should be reviewed by project team resources to identify known or unknown

changes to scope.

214

Comparing the trend of cumulative expenditure will clearly identify any variance

from the expenditure curve planned. Interpretation of the variance trend, however,

could be because of a number issues as listed below:

Work being completed late or early;

Under or over estimation of the planned expenditure spend;

Time scale error.

Tracking Costs - Anticipated Final Cost

Tracking anticipated final cost is the comparison of the planned AFC which should

be a straight line representing the project budget and the forecasted AFC, stated in

the regular progress statements as the project team‟s current assessment of the

final cost of an activity, contract or project. By monitoring the variance and trend in

these forecasts, the project team can assess if any remedial actions or additional

spends are likely to exceed any funding constraint imposed by the client.

Both cumulative expenditure and anticipated final cost tracking are presented on

the template opposite.

215

Fig 7.45 Cash Flow Forecasting – Tracking Movements

216

7.6.7 Tracking Costs - Contingency

Contingency is included in the project budget as an allowance to be used to pay

for anything unexpected that may happen during the development of the project.

Contingency allowance should, however, not be considered as a budget to be

expended, but as fund available to the project to be used to offset cost of the

unexpected.

Comparing the current planned against the actual contingency allowance

requested by the project team, will identify a trend or variance that should be

considered for the relevance of the remaining allowance or budget, considered

necessary to complete the project. The use of the contingency allowance is a

reflection on the ability of the project team to; manage change, to fully understand

the requirements of the project and to anticipate the unexpected.

Two templates are provided for the presentation of contingency allowances

throughout the project duration:

Expressed as a percentage addition to the current anticipated final cost of

the project;

Expressed as separate cost expenditure for additional works.

The contingency allowance originally anticipated for a project should be monitored

for trends or variance and used to calculate the current level of contingency still

needed or requested. The comparison should be seen as an indication of the

current overall success of the project. The contingency factor is a reflection on the

ability of the project team to, manage change, to fully understand the requirements

of the project and anticipate the unexpected.

Tracking Costs - Contingency Rundown - The graph uses the recorded

percentage allowances that have been assessed and included in the A F C for the

project at each progress interval. The actual contingency allowances requirements

are plotted as a graph for comparison against the planned contingency. In

addition, the project team‟s assessment of risk and the product of current risk

evaluation workshops could be presented as a separate graph if the allowances

are different. The presentation should be completed by forecasting the

contingency allowance required to complete the project.

217

Tracking Costs - Contingency Expenditure - The graph reports the expenditure

of the contingency budget to offset payment for authorised change. The graph

should be presented either as total expenditure or expressed as a percentage of

the overall project budget. The allowance should be shown either as a straight line

increment, anticipating that the contingency budget would be expended equally at

regular intervals, or as an „S‟ curve forecasting a decrease in expenditure change

as the project develops.

The actual expenditure recorded in the regular project reports are plotted onto the

graph. The actual cost information is the cumulative expenditure of change

recorded from the project‟s change control report, using only the approved

changes.

218

Fig 7.46 Tracking Costs – Contingency Movement

219

7.7 Change Control Process

Change control flow sheet

The change control flow sheet shown opposite presents an approach to the

information requirements, the decisions that are needed and the activities involved

in managing changes to the initial agreed scope of work, that was used to create

the budget and schedule against which the project is being monitored.

A more detailed flow sheet is included later in this section to provide a presentation

of the sequence of change activity in the two stage approval procedure proposed

here. The change control procedure should be contained in the Project Execution

Procedures. The process of checking if the change order is compliant with

requirements is outlined in the change order flowchart.

Change Control Process

The change control process is the project‟s chosen method of managing change to

the initial cost and schedule content, used to obtain funding to undertake the

project scope of work and to achieve the project‟s objectives. The process of

managing change is to control the project team resources as to how they should

act to a variation to the original intention. There are a number of methods as to

how change is managed, but it is important that the requirements of the project are

identified and advised to the project team resources as soon as project approval is

given.

Change – What is a Change?

A change is a variation to the original planned scope of work formally recorded in

support information approved by the client and sanctioned for delivery to a

specified cost, by a certain date and to achieve a specified quality safely. The

change may be a variation to the project‟s objectives, scope of work or method of

execution. The change may be as result of a variation of time or funding allowance

that alters the sequence or budget for an element of the whole project. The change

may be as a result of an error or omission by a project team resource in the

execution of the work. The variation may be contained within the work activity or

may have an impact on subsequent activities.

220

Estimate Development introduced the concept of design development allowance

made by the estimator or scheduler on behalf of the responsible project team

resource before formal approval. The design development allowance is included

for the design quantity, performance or quality improvement as an accuracy factor.

A change may be claimed to be as a result of a fundamental variation but should in

fact be funded by the design development allowance included in the responsible

project team resource‟s budget. A variation that is design development in nature

would not constitute a change, as this variation should be accommodated by the

growth or design development allowance made in Estimate Development

contingency allowance. If the variation is as a field order instruction (i.e. to resolve

a clash between disciplines) it is not considered a change, as this variation should

also be accommodated by the growth allowance for design development made in

estimate development contingency allowance.

A change order (CO) is, therefore, an approved project team agreement that a

change is accepted as such and has been fully assessed for cost and schedule

impact and is compliant with the change order procedure as instructed by the

project management team.

221

Fig 7.47 Change Control Flow Sheet

222

7.71 Change Control Organisation

Who is Involved in the Change Control Process?

A typical project change control organisation „organogram‟ is provided as a

checklist of those parties involved with the process of preparing and authorising a

change order. Reference should also be made to the change control flow sheet, to

identify the point in the process at which each party needs to be formally involved.

Each change order starts by an initiator who recognises that there is a variation

from the current understanding of the scope of work. The change order initiator

could in fact be any member of the project team. The change order initiator should

complete the change order request (COR.) part of the change order form,

discussed in detail later in this section. The change order process involves two

stages in which the project team resources are involved and they are:

Stage 1 - on receipt of the change order request (COR) the project manager

should:

instruct the project team resources to consider the relevance of the COR.

The project team resources instructed by the project manager to review the

content of the COR should report back, or immediately consider if the change

order is relevant and should proceed. Approval to proceed would be an instruction

for all relevant project team resources to collaborate to prepare a change order

proposal (COP.)

instruct the project team resource to record the details and provide a

change order number;

instruct the necessary project team resources to consider the detail of the

COP. The project team resources may involve the relevant contractor

and / or supplier to provide information on cost and schedule to enable

quantification of the impact of the COP.

Stage 2 – on receipt of the change order proposal (C O P) the project manager

should:

review if C O P is acceptable for cost and schedule impact and if

necessary, request project team resources to recalculate until acceptable;

223

request authorisation and approval of the COP from the project sponsor or

equivalent client‟s representative.

Approval of the change order proposal will signal the incorporation of change order

authorisation (COA) into the project progress reporting system for cost and

schedule impact.

Fig 7.48 Change Control Organogram

224

7.7.2 Change Order – Process Flow Sheet

Significant work may be involved preparing the change order proposal (COP) and

no work should be undertaken by the project team resources without prior

approval of the change order request (COR) to proceed from the relevant

authority. The instruction to proceed is an implicit instruction that project team

resources to undertake work and incur additional cost as a result of this change.

All project costs associated with preparation of the COR and COP should be

included in the total cost of the change order.

The change order flow sheet is prepared with the activities involved in completion

of a change order. The maximum timescale for submission and consideration at

each stage should be advised either in the project procedure or by the project

manager when authorising the COR.

Effective change control requires a systematic approach to the activities of

responsible project team resources relevant to a change. The impact of change to

project activities can be assessed in a number of alternative ways to consider the

most suitable to meet the objectives of the project.

On receipt of the authorised change order request (COR) the project team‟s

scheduling resource should identify the activities and resources affected by the

change. The technique used to consider and present the schedule information

should be created separately from the „baselined‟ project schedule. The

scheduling technique selected should be created using the base lined project

information, plus assumptions for activities and resources impacted by the change.

The schedule presented will either alter or maintain the planned project end date.

An altered planned project end date will be either acceptable to the project team or

rejected and then further consideration will be necessary.

In order to reconsider the impact of the change the project team‟s scheduling

resource will need to address the specific criteria, upon which assumptions were

made to recalculate the initial schedule. The specific areas to reconsider are as

follows;

Reassess the logic between activities and their timing and sequence for

potential reduction in the critical path duration.;

Vary the project‟s daily or weekly calendar to increase the available

working period within the Project duration. The project‟s calendar increase

225

can be achieved by resources working additional days (weekends, bank

holidays) or additional hours (overtime, shift working);

Increase the resource numbers to achieve more progress although

productivity may be reduced. Resource increases that could be considered

are labour and plant/equipment;

Use alternative materials with equivalent performance requirements that

are however installed more productively.

The considerations listed for schedule impact may, however, have additional cost

implications. The project team will need to balance the schedule and cost impact

to meet the objectives of the project as a whole.

From the options available, the project team will have to select their course of

action to offset the impact on the project schedule. The project schedule may

have altered or maintained the planned end date and should be included in the

change order proposal (COP) that is submitted to the client‟s authorised resource

for approval. The change order authorised (COA) is the instruction to incorporate

the impact into the base lined schedule. On completing the revised schedule, it

should be issued to the project team.

226

Fig 7.49 Change Order – Process Flowsheet

227

7.7.3 Change Order - Form

The change order form shown on the opposite page is provided as a single

document recording the status of the change order and summarising the cost and

schedule impact. The form could, however, be customised to suit the client‟s own

change order procedure if appropriate. There are three distinct phases to the

progress of the change order and are listed as follows.

Phase 1 - Change Order Request (COR) - Should be initiated by a member of

the project team. The appropriate supportive detailed documentation outlining the

background to change should be included. The project manager will decide the

course of action from this information and may:

Dismiss the C O R as not relevant as a change;

Request that further information is provided to enable a decision to be made;

Instruct the project team to prepare a change order proposal.

Phase 2 - Change Order Proposal (COP) – Following approval of the C O R, the

project team resources should prepare a detailed cost and schedule submission

for consideration by the responsible project team resource. The project team

resources that could be involved are the responsible project team resource

supported by cost and schedule resources, construction manager and design

manager. The completed information and documentation should be submitted by

the responsible project team resource to the project manager as the change order

proposal. The project manager will consider the following options:

Dismiss the COP as not relevant as a change. (although costs will have been

incurred in preparation of the COP. and therefore, will have a project cost

implication);

Request that further information is provided and / or consider options to both

schedule and designs impact before resubmitting the COP;

Accept the COP and request authorisation from project management team or

project sponsor. Informal discussion should have been made prior to issue

of the COP to prepare the background, before formal presentation to the project

management team or project sponsor.

Phase 3 - Change Order Authorisation (COA) – Approval of the COP by the

project management team or project sponsor is formally made by signing the

change order authorisation (COA) form. The signed COA is issued to the project

228

manager for record as an approved change to the project. The formal

authorisation is an instruction to proceed with the incorporation of the change into

the project and will require the following:

Design manager to revise the design information and documentation;

Cost budgets to be adjusted;

Schedule to be adjusted;

Design, budgets and schedule adjustments to be communicated to the

project team resources.

Rejection of the C O P by the project management team or project sponsor will

require the following:

Further consideration of design and schedule options before resubmission of

an acceptable COP;

Acceptance by the project team that the change will not be authorised and

that the costs involved with production of COA and COP together with the

impact of the change are absorbed into the project A F C;

Pursue the implications of a dispute between project team resources and the

client‟s project management team or project sponsor resolved through one

of the solutions listed in Supply Chain Management;

229

Fig 7.50 Change Order – Form (Template)

Apr-04Apr-04

230

7.7.4 Change Order - Register

All potential changes arising on a project in accordance with the Project Execution

Procedures should be recorded for progress and their current status. The register

should therefore be kept up to date by the relevant project team resource. The

phases of the evolution of a change order are provided with a separate column to

be completed as each approval is achieved. The issue of a change order number

should only be made after instruction to proceed in preparation of a COP.

The following information should be recorded in the change order register:

Change Order Number Unique number assigned by the project team resource

on receipt of a signed COR instructing resources to

proceed in preparation of a COP.

Change Order Description The brief description of the change.

Change Order Approval The relevant dates as approval for COR, COP, and COA

is achieved.

Activity Reference The relevant references for those project activities

included in the current schedule that the change will

impact upon. The activities in the schedule should only

be included in the schedule when the change order is

authorised (COA).

Change Allowance The current forecast cost impact of the change order if it

is authorised should be included. The change allowance

should be estimated from the current information

available. The change allowance is used in progress

cost reports. On approval of the change order the cost

impact should be included in budget allowances. Before

approval, current cost forecasts for changes should be

included in anticipated final costs calculations.

Budget Allowance The forecast cost impact of the change order authorised

(COA) and included in progress cost reports as budget

allowance, should be regularly compared with the actual

costs.

The information provided in the change order register is the basis of costs used

compiling the change control report and cost reports.

231

Fig 7.51 Change Orders – Register Progress

232

7.8 Progress Measurement

Progress Measurement – Status Evaluation Techniques

Throughout the duration of the project, the project team need to gather progress

information to assess if an activity is ahead, or behind the proposed plan to deliver

the objectives of the project, in order to consider options as changes or variance

against planned progress occurs.

The activities that should be considered for progress assessment are all tasks

needed to complete a project from design, through construction, to process or

facility start up and handover. The techniques of evaluating and measuring the

current progress of an activity against planned are listed as follows:

Progress Measurement Technique - Units Completed

The units completed progress measurement technique is used to assess those

activities that involve repeat production of measurable items of work, for example:-

Installation of a new street lights along a road

1 Erect street lights 50 off -30 erected = 60% completed.

2 Connect street

lights

50 off -20 erected = 40% completed.

These types of units of activity can be undertaken by a number of different

construction approaches to achieve the same completion milestone. In the

example - installation of lighting, the multiple activities could be undertaken by:

each activity (erect all street lights then connect street light)

or each unit (erect and connect each street light)

Careful preparation is, therefore, needed to ensure that the plan to undertake

activities for the working sequence is represented in the schedule. The Schedule

Development should meet the demands of Progress Measurement and, therefore,

close liaison with project construction resources is needed to prepare activity

details in the way they will be undertaken and reported for progress.

233

7.8.1 Progress Measurement Technique - Incremental Milestone

The incremental milestone progress measurement technique is applicable to any

project activity that includes sub tasks, which must be handled in sequence.

Activities are analysed for sequence and the key milestones will each need to be

complete. Each key milestone should be an easily definable, measurable, set at

regular intervals and be a relevant achievement in order to monitor progress of the

activity. Each key milestone is allocated an agreed percent complete factor before

starting the activity. As work is completed and each key milestone is achieved, the

table should be used to record the current status of completion. If required the key

milestones can be split into disciplines and the relevance of each element given a

weighting. Progress measurement can be used either to record complete

milestones only or the current percentage complete of the activity can be

calculated by interpolation between last achieved and next to be complete

milestone figures.

The example table shown opposite can be used as a template:

Development of Design Phase of a Construction Project.

The current progress assessment of the activity is calculated as the sum of the

disciplines total. The current percentage completion for each discipline is multiplied

by the weighting of each discipline and the sum for all disciplines combined.

234

Fig 7.52 Progress Measurement – Incremental Milestone

235

Progress Measurement Technique – Start / Finish

The start / finish technique is used where a project activity does not have any

readily definable intermediate key milestones and the assessment of effort / time

involvement is difficult to estimate or measure. To make any meaningful progress

measurement the activity does, however, need to be broken down into its

component tasks. Each task will only be awarded 100% status on completion. Until

the completion status is achieved, the status will be zero percent. By weighting the

tasks for the whole activity and combining the current status for each task, the

activity progress can be identified.

The example shown below is for pre commissioning or dead testing the electrical

content of a contract.

Planned Actual

Prepare test forms 6 6

Prove power circuits 15 15

Prove lighting circuits 18

Prove power equipment 15 15

Prove lighting equipment 22

Prepare test certificates 20

Sign off test certificates 4

Total activity weighting 100 Percentage complete 36

Progress Measurement Technique - Supervisor Opinion

The supervisor‟s opinion technique is basically a subjective approach without

factual information, to support any assessment and should be used only for

relatively minor tasks where development of an alternative relevant technique

cannot be used. The supervisor‟s participation in Progress Measurement is,

however, necessary to make comment on the quality of workmanship of completed

work and therefore, this resource should be used to confirm the facts upon which

any assessment has been made. This technique is best used for trade‟s man

work, whereby the discipline supervisor periodically reports progress against

scheduled durations.

Progress Measurement Technique - Cost (or Effort) Ratio

The cost (or effort) ratio technique is used to assess project activities such as

project management, quality assurance, and contract administration. These

236

activities involve a long duration or are continuous over the life of a project. These

activities are estimated and budgeted for bulk allocation of cost and planned man

hours, rather than on the basis of production.

The percentage completion is calculated as follows:-

Percent complete = Actual cost or Actual man hours

Forecast cost at completion

Forecast man hours at

completion

Comparison of the activity using cost as the method of assessment will generally

give a differing percentage than when man hours are used. The method of using

man hours does not acknowledge that the average rate for the activity can

fluctuate depending upon the complexity of resource cost employed on the activity

and is not a uniform cost throughout the project.

237

7.8.2 Progress Measurement Technique – Weighted or Equivalent

The weighted or equivalent units technique is used where the project activity being

monitored is significant in its number of tasks either involving a long duration and /

or is composed of two or more overlapping activities. The activity is further made

complex in that some tasks have different measurement assessment units.

The example below is the erection of a structural steel frame.

The table identifies all the tasks involved in the erection of the structural steel

frame for a building. The selected unit of measure for this example was chosen as

tonnage, being the common denominator of the majority of the activity. The tasks

that comprise the whole activity have been broken down into relevant sub tasks

that are assessed for, in this example, a weight or given an equivalent weight. The

total „weight' will be used as the unit against which progress will be assessed.

Progress will be calculated by measuring the tasks and subtasks for the completed

actual and equivalent weight and assessed against the total weight. The current

progress is stated as a percentage.

Fig 7.53

238

Progress Measurement Technique – Earned Value

Progress Measurement information gathered at a particular point in the project‟s

development using one or more of the techniques previously described in this

section is presented as actual man hours against the planned man hours to be

expended at that point in time.

Earned value is the assessment of „progress‟ achieved for a task, activity or series

of activities expressed as man hours. Earned value is calculated as the

percentage of work completed, multiplied by the planned man hour for the task,

activity or series of activities under consideration.

(E.V) Earned value = planned man hours x progress measure (%);

(A.V.) Actual man hours used to achieve the task, activity or series of

activities under consideration should also be provided.

The project forecast „S‟ curves prepared in Schedule Development are used to

present the earned value and the actual man hours to identify variance or trend

variation between actual performance against planned. The project forecast „S‟

curves were the planned allocation of resources, presented as a cumulative curve

of man hours. The planned progress is presented as „S‟ curves representing both

the early start and late start dates for undertaking the task, activity or series of

activities under consideration. The (E.S.) early start and (L.S.) late start curves will

describe an „envelope‟ within which the work should actually be achieved.

The example opposite presents the overall curves for ES and LS and shows the

current A V and E V for the work under consideration.

The A V is within, but the E V is below, the planned envelope and, therefore, the

activity should be reviewed for the reason behind the trend and variance either

because:

(a) Activities have been omitted from the scope of activity work and the

anticipated final value is expected to fall below the original. The „envelope‟

has not been re-baselined to reflect the change in scope. Is re base lining

required? or;

(b) Performance is falling behind planned. What actions are needed to remedy

this situation?

239

The project forecast „S‟ curves are used to monitor performance of physical effort

(man hours) required to achieve the project completion date. The information to

generate these curves is obtained from allocation of anticipated and actual

productive man hours. In addition to providing an overall progress measurement

basis, earned value can be used to assess performance (or measure productivity).

Progress Measurement Technique - Performance

Progress Measurement performance throughout the project can be calculated

using the ratio of earned value E V man hours against actual A V man hours

expended for a task, activity or series of activities. If the current ratio is less than

1.0 either:

(a) progress is not being maintained as planned. What actions are needed to

remedy progress or corrective action initiated.

(b) the originally scheduled hours were under estimated. What adjustments are

needed to budget and schedule?

Performance data can be used to assess efficiency of the project team or specific

disciplines. When corrective action is taken, a positive trend should result.

240

Fig 7.54 Progress Measurement – Project Forecast ‘S’ Curve

241

7.8.3 Progress Measurement - Requirements

Progress Measurement – Requirements

To achieve maximum efficiency in Progress Measurement it is important that

information to be used in the assessment of progress is made available and

provided at required regular intervals by the project team. Consideration and

preparation of the project‟s requirements should be made during Schedule and

Estimate Development and reference should be made to the measurement

techniques and options in both this section and Cost Management. A requirements

checklist is provided in Supply Chain Management to assess inclusions in tender

documentation.

During Schedule Development the project team need to recognise and reflect the

sequence and activities that are likely to be undertaken during the project stages

under progress scrutiny. The revision and maintenance of the various schedules

during these stages, therefore, need to reflect any revision to the planned activities

or their sequence as progress measurement and should reflect the actual

sequence and activities that are being undertaken.

Progress information to be provided by the project team during the project needs

to be communicated and listed as a deliverables as early as possible in the Project

Execution Procedures and could be detailed by use of the activity definition form

available in Schedule Development. The deliverable of regular progress

information should be included as a requirement in any contractual agreement,

between the client and the contractors or suppliers.

Progress Measurement – Flow Sheet

The Progress Measurement – flow sheet opposite shows the input information that

is necessary to undertake Progress Measurement. The information needed and

therefore, the resources required to provide information will be determined by

selection of the techniques from those described previously in this section, to be

used on the project.

After collation of the Progress Measurement information, the project team will be

presented with the information using a selected method to enable comparison and

trending to be clearly identified. The various scheduling methods are described

242

later in this section. Cost progress presentation will be described in the Cost

Management section of this Toolkit.

The objective of both Progress Measurement and Cost Management is to identify

variances in actual use of resources, against planned and those trends that may

lead to potential variances. The techniques that are described in these sections

are the tools that the project team resources have available to both identify trends

and to be used as options to rectify variances to enable the team to achieve the

project‟s objectives. It is therefore, important that careful selection of the right

techniques to be used on the project are identified and explained to all project

resources. It is not anticipated that all techniques will be required, but the project

team need to consider those that are going to be used on the project as soon as

possible.

243

Fig 7.55 Progress Measurement – Flow Sheet

244

7.8.4 Progress Record – Milestone Schedule

The progress record milestone schedule uses the schedule created in Schedule

Development as the document to record the completion of key activities that are

considered as critical to the success of the project. Progress is recorded against

the milestone schedule planned completion dates, created previously with the

actual key dates for completion of each activity.

The milestone schedule progress, in the example shown opposite is a

development of the initial document, but with the addition of a column for the

actual date. A further addition to the schedule is the „time now‟ bar or row, that is

inserted into the milestone schedule at the relevant chronological point between

activities, to represent the current date.

The planned and actual dates could be recorded as either project days, as the

example, or calendar days. The milestone schedule will immediately identify, by

comparison, any variance between planned and actual dates.

The comments column is used to record an explanation of a variance between

actual against planned dates and a brief statement of any action taken to remedy a

delay or exploit an early completion.

Progress recorded using the milestone schedule only presents information for key

activities and if completion has been achieved or not. If progress assessment is

required on whether or not the completion date for a subsequent activity will be

achieved, the project team will need to use an alternative schedule technique.

245

Fig 7.56 Milestone Schedule - Progress

246

7.8.5 Progress Record – Classic Schedule Bar Chart

The progress record classic schedule bar chart should be baselined on

sanctioning of the project. The techniques to be used, frequency and distribution

of updating the classic schedule bar chart, should be discussed and agreed with

the project team resources. It is important that the project team resources fully

understand their contribution and provide information of what is required. If

necessary guidance or training on interpretation of the updated classic schedule

bar chart should be provided. The requirements should be detailed in the Project

Execution Procedures.

Progress should be recorded with assessment of current percentage completion

using a progress measurement technique described previously in this section. In

addition an assessment of the remaining duration of the work for completion

should be agreed by the relevant project team resources and recorded. The

assessment of the remaining duration for each activity will be important especially

towards the end of an activity, when the assessed % complete may not reflect the

final completion date. In the event of dispute it is necessary to have recorded

against each activity the „actual start‟ and „actual finish‟ dates. The critical path

should also be recorded and monitored for its potential compromise that would

impact on the completion date. Movement, however, in an activity start or finish by

delay or improvement may result in the activities that make up the critical path

changing. The activities along the revised critical path will then be the activities to

closely monitor.

On completion of entering all progress into the schedule, an „update‟ of the classic

schedule bar chart should be performed highlighting any movements in start and

completion dates of activities. The baselined classic schedule bar chart should be

presented in order that an assessment of movement against the update may be

highlighted.

Following „update‟ of the classic schedule bar chart, if any of the activities on the

critical path have been delayed in their completion dates, the overall project

completion date will be delayed. The classic schedule bar chart can be used in

developing a series of „what if‟ scenarios to review the available alternative options

to the project team, to remedy potentially failing activities in order to achieve the

planned completion date.

247

The classic schedule bar chart is used to provide a forward view of actions against

particular activities needed to meet project objectives and to highlight any potential

difficulties.

Fig 7.57 Classic Schedule Bar Chart - Progress

248

7.8.6 Progress Record – Period „Look Ahead‟ Chart

The period „look ahead‟ chart presents a „window‟ of those activities, either as a

project as a whole or in part, that are to be undertaken in a specific time scale.

This form of chart is used to closely monitor progress of those activities planned to

be undertaken, over the specific period of time. Generally the timescale will be the

immediate future and the chart will present the selected activities planned to be

undertaken in this period.

The period „look ahead‟ chart uses the classic schedule bar chart software to

present the selected „window‟ of project activities. The detail data used will be that

already populated in the classic schedule bar chart, with baselined and progress

information.

By concentrating on monitoring the progress of these key activities in detail, trends

can be immediately identified for slippage. This is particularly useful when plans

are made to use a remedial course of action to halt a trend or improve productivity

of activities identified as drifting towards slippage. Progress can be monitored on a

frequent basis, (daily if necessary), for selected activities without having to

populate the whole project plan.

The example shown on the opposite page shows those high level activities to be

completed in the next month (four weeks) of the project development and is,

therefore, useful to provide detail information for use in preparing the executive

summary as part of reporting.

This type of progress record period „look ahead‟ chart is a versatile use of the

classic schedule bar chart, where specific time periods or series of activities can

be used to graphically demonstrate to the project team resources, how progress is

being achieved.

249

Fig 7.58 Period ‘Look Ahead Chart’ - Progress

250

7.8.7 Progress Record – Scheduled Activity Table

The progress record scheduled activity table, records all or selected key activities

for the whole or part of the project that is required by the project team resources.

The scheduled activity table comprises the following information:

Activity Reference Number See Schedule Development for activity numbering.

Activity Description As described in the selected schedules for the

activities selected from overall project scope.

Scheduled Duration Activity duration as calculated and recorded in the

base lined schemes.

Remaining Duration Forecast duration to complete the activity.

Percentage Complete Record of the current assessment of work complete

as calculated by a progress measurement technique

as previously described.

Baseline Start and Finish

Dates

Statement of the baselined start and finish dates for

each activity.

Actual Start and Finish Dates Record of when each activity was started and

finished.

The project record scheduled activity table is used by the project team resources

to review and compare planned and actual start and finish dates of specific

activities. The information in the scheduled activity table is an alternative method

of considering information on the classic schedule bar chart and indeed all of this

information is already used to populate the Gantt chart, but generally is hidden.

251

Fig 7.59 Schedule Activity Table - Progress

252

7.8.8 Progress Record – Resource Histogram

Progress record resource histogram uses the diagrammatic representation of

resource forecasting created in Schedule Development. The resource histogram

document is base lined to record the planned levels of resources required to

complete the activity. Progress is recorded on the resource histogram as additional

columns „from additional rows in the table‟ representing the actual resource man

hour content. Information is provided from project team resources for each interval

over the activity duration.

Planned and actual man hours can be presented either as individual disciplines,

individual columns as shown in the example, or a sum of disciplines, stacked

columns. The individual columns can readily show any variance, whereas the

stacked columns require further interpretation to understand the progress of each

discipline.

The actual man hour resource information can be quickly collated and recorded in

the table used to generate the chart. Inspection of actual against planned man

hours for resources can demonstrate any variance in specific discipline activity.

The resource histogram can be used to assess if an increase in resource use over

a period of time is practical and, therefore, potentially a solution to the variance

problem.

253

Fig 7.60 Resource Histogram - Progress

254

7.8.9 Progress Record – Procurement Schedule

Progress record procurement schedule uses the procurement schedule and

information prepared during Schedule Development. This schedule is used to

record progress of actual achievement for the selected items of equipment.

Information to keep the schedule up to date is needed on the project contractors or

suppliers, with actual contract placement and delivery dates, together with a

simple statement on current progress. The information should be provided as

required by the relevant project team resources.

The purpose of the procurement schedule progress is to provide a presentation of

the critical information to enable identification of any variances between a

supplier‟s delivery forecast and schedule requirement dates that might have an

impact on subsequent key activities of the project. The procurement schedule

progress is used to identify as early as practical any slippage in delivery dates or

other key activity dates and by application of this information to the classic

schedule bar chart, progress the impact on the whole project can be assessed.

The procurement schedule progress should be maintained until all equipment has

been delivered to site. The progress record procurement schedule is therefore,

used to support other progress record presentations.

Intermediate milestone progress dates should be considered for inclusion in the

procurement schedule, when a supplier providing a material or item of equipment

needs a long duration for manufacture or fabrication. The intermediate milestones

should be selected for simple assessment, but key stages of progress against

which inspection and checking of progress can be undertaken and recorded.

Examples of such key milestones are dates achieving:

Drawing issue;

Component order;

Quality inspection;

Unit test;

Completion in fabrication shop;

Delivery and offloading on site.

255

Fig 7.61 Procurement Schedule - Progress

256

7.9 Reporting Process

Reporting information is required for:

Internal use by the project team on a regular basis. The project team

resources use the progress information to undertake their „day to day‟

management of the project. Each project team resource should be advised

of their responsibilities and of the techniques and reports that should be

made available in the Project Execution Procedures. The preparation of the

reporting information is started in the Progress Measurement and Cost

Management sections of the toolkit. The formal documents that need to be

prepared as a regular permanent record of progress reports should be

selected from the list provided in the schedule of reports. The reports are

used as historical information during the duration of the project and as

reference on future projects;

External use by the project team to inform the client or the client‟s steering

committee of the current progress of the project for actual work completed,

highlighting achievements and failures, forecasting future trends and

proposing remedial actions to rectify any trend or variance.

Reporting Process

The information provisions, decisions, activities and reports are shown in the flow

sheet on the opposite page. The process of reporting is to understand what is

needed to be provided, when and by whom.

What is needed? The various schedules, progress templates and forms are

listed in Progress Measurement, Cost Management and

Reporting sections of the Toolkit. The project team should

consider the various techniques and presentations and agree

those that are relevant to the project. The selection of the

project‟s reporting techniques need to be agreed early in

project execution, as these requirements should be included in

contractual arrangements. The selection of reporting

templates should also reflect the reporting requirements and

preparation of support information at Estimate and Schedule

Development to avoid additional project team‟s work changing

presentations at a later date in the project duration;

257

When is it needed? The regularity or preparing, reviewing and issuing of reports

should be considered and agreed by the project team. The

issuing of reports should consider the requirements of both

internal and external demands for information and tailored to

meet both requirements;

Who is to provide? The project team resources should understand their

responsibilities and deliverables for providing information.

Fig 7.62 Reporting Flow Sheet

258

7.9.1 Reporting – Team Effort

Report information is prepared for both cost and scheduling and each should

collaborate in the production of progress and forecast statements. Report

preparation requires contribution from all relevant project team resources, as

shown diagrammatically on the opposite page. The contribution required from

each project team resource is described as follows:

Project Manager The focal point for the management of all project issues

and is ultimately responsible for the completion and issues

of the executive summary and the progress information.

Design Manager Responsible for advising of the future development of the

design scope, updating and issue of the design content as

changes are approved.

Supply Chain Manager Responsible for monitoring progress and reviewing

delivery states as well as advising on the forecast final

cost for suppliers and contractors.

Construction Manager Responsible for advising on „field instructions‟ given to site

contractors and providing information to the supply chain

manager on site progress and completion dates.

Scheduling Resource Responsible for monitoring progress against the current

schedule of activities. Assessing implication of variance in

progress, changes to the design and forecasting

completion and providing information for use by the supply

chain manager and construction manager.

Cost Resource Responsible for monitoring actual cost against the

anticipated expenditure of cost. Assessing implication of

variance in cost progress, changes to the design and

forecasting completion and providing information for use

by the supply chain manager and construction manager.

The reporting section of these guidelines considers the following issues:

Regularity of Reporting – including calendar calculator to prepare information;

Schedule of Reports – list of reports and distribution;

Key information – summary – description and use of each summary report;

Key information – detail – description and use of each detail report.

259

Fig 7.63 Reporting – Team Effort Model

Reporting Needs

Teamwork

4.

Ac

co

un

ts

In-h

ou

se

Co

sts

4.

Ac

co

un

ts

In-h

ou

se

Co

sts

2.

De

sig

n

De

sig

n

De

ve

lop

me

nt

(to

co

mp

lete

)

2.

De

sig

n

De

sig

n

De

ve

lop

me

nt

(to

co

mp

lete

)R

ep

ort

sR

ep

ort

s

7.

Co

mm

erc

ial

Ma

na

ge

me

nt

Co

st

to D

ate

Ch

an

ge

Ord

ers

Co

st

to C

om

ple

te

7.

Co

mm

erc

ial

Ma

na

ge

me

nt

Co

st

to D

ate

Ch

an

ge

Ord

ers

Co

st

to C

om

ple

te

6.

Sc

he

du

lin

g

Pro

gre

ss

to

Da

te

Tre

nd

s t

o

Co

mp

lete

6.

Sc

he

du

lin

g

Pro

gre

ss

to

Da

te

Tre

nd

s t

o

Co

mp

lete

5.

Co

ns

tru

cti

on

Ma

na

ge

me

nt

Fie

ld I

ns

tru

cti

on

s

5.

Co

ns

tru

cti

on

Ma

na

ge

me

nt

Fie

ld I

ns

tru

cti

on

s

1.

Pro

jec

t M

an

ag

er

All

Pro

jec

t Is

su

es

1.

Pro

jec

t M

an

ag

er

All

Pro

jec

t Is

su

es

3.

Pro

cu

rem

en

t

Ma

na

ge

me

nt

Pu

rch

as

e O

rde

r

(Ex

pe

dit

ion

)

3.

Pro

cu

rem

en

t

Ma

na

ge

me

nt

Pu

rch

as

e O

rde

r

(Ex

pe

dit

ion

)

Reporting Needs

Teamwork

4.

Ac

co

un

ts

In-h

ou

se

Co

sts

4.

Ac

co

un

ts

In-h

ou

se

Co

sts

2.

De

sig

n

De

sig

n

De

ve

lop

me

nt

(to

co

mp

lete

)

2.

De

sig

n

De

sig

n

De

ve

lop

me

nt

(to

co

mp

lete

)R

ep

ort

sR

ep

ort

s

7.

Co

mm

erc

ial

Ma

na

ge

me

nt

Co

st

to D

ate

Ch

an

ge

Ord

ers

Co

st

to C

om

ple

te

7.

Co

mm

erc

ial

Ma

na

ge

me

nt

Co

st

to D

ate

Ch

an

ge

Ord

ers

Co

st

to C

om

ple

te

6.

Sc

he

du

lin

g

Pro

gre

ss

to

Da

te

Tre

nd

s t

o

Co

mp

lete

6.

Sc

he

du

lin

g

Pro

gre

ss

to

Da

te

Tre

nd

s t

o

Co

mp

lete

5.

Co

ns

tru

cti

on

Ma

na

ge

me

nt

Fie

ld I

ns

tru

cti

on

s

5.

Co

ns

tru

cti

on

Ma

na

ge

me

nt

Fie

ld I

ns

tru

cti

on

s

1.

Pro

jec

t M

an

ag

er

All

Pro

jec

t Is

su

es

1.

Pro

jec

t M

an

ag

er

All

Pro

jec

t Is

su

es

3.

Pro

cu

rem

en

t

Ma

na

ge

me

nt

Pu

rch

as

e O

rde

r

(Ex

pe

dit

ion

)

3.

Pro

cu

rem

en

t

Ma

na

ge

me

nt

Pu

rch

as

e O

rde

r

(Ex

pe

dit

ion

)

4.

Ac

co

un

ts

In-h

ou

se

Co

sts

4.

Ac

co

un

ts

In-h

ou

se

Co

sts

2.

De

sig

n

De

sig

n

De

ve

lop

me

nt

(to

co

mp

lete

)

2.

De

sig

n

De

sig

n

De

ve

lop

me

nt

(to

co

mp

lete

)R

ep

ort

sR

ep

ort

s

7.

Co

mm

erc

ial

Ma

na

ge

me

nt

Co

st

to D

ate

Ch

an

ge

Ord

ers

Co

st

to C

om

ple

te

7.

Co

mm

erc

ial

Ma

na

ge

me

nt

Co

st

to D

ate

Ch

an

ge

Ord

ers

Co

st

to C

om

ple

te

6.

Sc

he

du

lin

g

Pro

gre

ss

to

Da

te

Tre

nd

s t

o

Co

mp

lete

6.

Sc

he

du

lin

g

Pro

gre

ss

to

Da

te

Tre

nd

s t

o

Co

mp

lete

5.

Co

ns

tru

cti

on

Ma

na

ge

me

nt

Fie

ld I

ns

tru

cti

on

s

5.

Co

ns

tru

cti

on

Ma

na

ge

me

nt

Fie

ld I

ns

tru

cti

on

s

1.

Pro

jec

t M

an

ag

er

All

Pro

jec

t Is

su

es

1.

Pro

jec

t M

an

ag

er

All

Pro

jec

t Is

su

es

3.

Pro

cu

rem

en

t

Ma

na

ge

me

nt

Pu

rch

as

e O

rde

r

(Ex

pe

dit

ion

)

3.

Pro

cu

rem

en

t

Ma

na

ge

me

nt

Pu

rch

as

e O

rde

r

(Ex

pe

dit

ion

)

260

7.9.2 Report Types

The schedule of report types should be used to consider the reports that are

required by the project team, for the particular project. The regularity of production

and issue of each report should be agreed for the required timescale. As the

information in each report is ultimately used to prepare the project manager‟s

executive summary, the timescale should be determined by the dates in the report

issue dates template.

Each report template should be considered for content and customised if

necessary. The customised template together with a list of the preparation, review

and issue dates should be issued to each of the relevant team members. The

schedule should be completed after considering and agreeing the following

information for each report:

Project Team Resource responsible for preparation;

Distribution for review and comment;

Frequency of issue if dates are not agreed / available for preparation, issue

etc.

The following key reports should be considered for use on the project. A

description and information requirements that should be contained in each report

are summarised below:

Executive Summary Costs, progress, milestones, significant achievements, critical

issues and safety records, plus the key objectives for the next

period.

Key Items Summary Schedule information on overall project key dates, duration,

work content and activities monitoring actual and planned.

Schedule Report Schedule information for the overall project with record of the

planned and actual progress of significant critical activities of

work.

Cost Report Cost information for overall project on budget, actual and

forecast for the significant elements of work.

Milestone Progress Schedule information for the key milestone activity dates with

record of planned and actual dates and proposed course of

action to remedy any difference.

261

Change Control Record of status of all information associated with change.

Risk Record of status of all information associated with risk

management.

Fig 7.64 Report Types - Schedule

262

7.9.3 Report Regularity

The information reported on a regular basis will be compiled over a period of time

from a significant amount of data. The time needed to prepare information by the

project team resources, is used to allow assessment, draft, review and if

necessary, change before final compilation and issue of the project report. The

attached template to record target dates has been prepared as an example with

proposed time scales. The following target dates are the critical milestone

involved in the compilation of the project manager‟s report:

‘Cut off’ Date – at which the progress data starts to be compiled. The „cut off‟

date is a significant milestone and is recorded as such in the report. It should be

noted that the date of the report is not the relevant date of the information. The

time difference between cut off and report dates should be kept to a minimum.

Complete Information Collection Date – at which all data should have been

compiled by the relevant resources. This is the key milestone at which the „draft‟

report is started. The difference between complete information collection and „cut

off‟ dates is the period of time allowed for the resources to prepare, review and

assess the impact of progress needed in the report.

Issue to Project Team Date – at which the „draft‟ report information is issues to

the members of the project steering committee following review, comment and

approval of the content by the project team. The „draft‟ report is issued to the

steering committee for their review and comment. The difference between issue to

steering committee for their review and comment. The difference between issue to

steering committee and issue to project team dates is the period allowed for the

project team to comment upon the report and for any changes to be made.

Issue Project Manager’s Report Date – at which the report is issued to the

relevant client‟s resources. The information contained in the report, if the previous

milestones have been used, will have been prepared with the full support of the

project team. The difference between issue project manager‟s report and issue to

steering committee dates is the period of time allowed for the steering committee

to comment upon the report and for any changes to be made.

263

The table below will automatically provide a matrix of the key dates by inserting the

following information:

1. Key date Issue of project manager‟s report to the client;

2. Timescales Period of time between each of the key milestone dates, from

„cut off‟ allowing for preparation, review, comments and

making changes at each stage of report preparation.

Fig 7.65 Report Issue Dates

264

7.9.4 Project Report – Executive Summary

The client‟s requirements for detail progress information to be included in the

executive summary should be agreed with the client and stated as part of the

Project Execution Procedures. The report details should be limited to the

essentials that the client requires to show progress as planned, against actual cost

and schedule. In addition any proposed strategies that need agreement from the

client, to rectify variances between planned and actual. Additional information may

be required by the client on achievements and critical activities planned in the

short term.

The attached template is representative of the information summarised as a single

document project report. The report is compiled from information prepared in

other detail reports. The key components should be as follows:

Project Information Project title, reference number, location and report date.

Source of this information is in Project Execution Procedures

and the report regularity table.

Project Summary Statement of the project‟s objectives inclusive of time and cost

limits, and significant deliverables. Source of this information

is the Project Execution Procedures.

Key Players Identification of key project team members committed to

delivering the project. The circulation should include project

sponsor and manager. Source of this information is the

Project Execution Procedures.

Project Schedule Records planned against actual progress of key schedule

milestones, summarising overall status of project completion.

Source of information is the project reports, milestone

schedule or schedule update.

Project Cost Records details of budget, actual and forecast cost of the

project. Source of information project report cost update.

Update Activities Records key activities achieved since the previous report,

highlighting any differences in actual against planned for cost,

schedule or resource. Identify any critical activity, key to the

successful progress of the project, planned to happen in the

short term time periods. Sources of information are the

project reports cost and schedule updates and discussions

with the project team.

265

Fig 7.66 Project Report – Executive Summary Update

266

7.9.5 Project Report – Key Items

The planned and actual key items report information, should be compiled from

data prepared for other project reports and progress statements. The purpose of

using this report type is to present information in a simpler way than the project

report schedule update, for the benefits of project team resources that are not

familiar with using the schedule technique.

The planned and actual information presented in this report type is as follows, for

each item listed below:

Progress Percentages The percentage progress is recorded and an assessment

made of any variance between actual and planned project

activity, identifying those key areas that may be ahead or

behind the planned schedule. The source of this information

is project report schedule update.

Programme Dates The start and finish dates are recorded and any variances

between planned and actual start and finish of an activity

are highlighted and expressed as difference in days. This

approach could be applied to an individual activity, a series

of activities of the whole project. The objective of this

presentation should be to consider the key areas or

disciplines that are currently critical to the success of the

project and present the impact of any difference. The

source of this information is project report schedule and

milestone schedule updates.

Planned Man Hours The planned man hour content is recorded. The data

separates the man hour content originally planned for each

activity to be considered for the impact of any change, as a

result of activity reassessment or variation in scope.

Progress assessment should forecast the number of

productive hours that an activity will need to complete the

work. The source of this information is project report

schedule update and progress statements resource

histogram.

Progress Man Hours The actual man hour content is recorded. Any variance

between planned and actual productive progress

assessment should be used to identify critical activities and

their resource levels. The source of this information is

267

project report – schedule update and progress statements

resource histogram.

Weightings The project should be considered for percentage impact of

areas or phases over the whole. The weightings should be

recorded. By assessing actual progress by area or phase,

the information can be used in conjunction with other

progress information to evaluate future impacts on the

programme. The source of this is project report schedule

update and project report change order update.

268

Fig 7.67 Project Report – Key Items Update

269

7.9.6 Project Report – Milestone Schedule

The milestone schedule update information is obtained from the progress

statements – milestone schedule, prepared under the Progress Measurement

section. The milestone schedule was initiated in Schedule Development and the

key activities and constraints should be identified as soon as possible in project

evolution. The key milestones are a selected series of critical activities and their

dates, by which each are to be completed in order that the planned project

programme is achieved.

The project report – milestone schedule update contains the following information

for each critical activity:

Activity code Identifies each activity using the project activity coding

system.

Activity description Provides a brief description of each key activity. The

description should give a reference to a milestone in

the project duration that a critical achievement is

realised.

Planned date of completion The date that each critical activity is planned to be

realised. The date may in fact be the completion of a

particular activity and the start of the subsequent

activity.

Actual date of completion The date that each activity was actually realised.

Variance Is the time period difference between the planned and

actual date that each activity was realised.

Responsible authority The project team resource responsible for ensuring

that each activity is completed. The responsible

person should be clearly identified in Project Execution

Procedures.

Action to be taken Considering progress of the activity or subsequent

activities. It may be seen appropriate by the project

team to adopt an alternative approach to the planned

action and any revision should be reported here.

Comments Recording the progress of the activity and the

commentary on the current course of a remedial action

plan. Referring to any appropriate documentation that

has been generated to verify completion or needed to

progress the activity.

270

The milestone schedule report is seen as containing important crucial information

for use in preparing the overall executive report.

Fig 7.68 Project Report – Milestone Schedule Update

271

7.9.7 Project Report Schedule

The scheduling technique options were considered in Schedule Development and

Progress Measurement. The most appropriate project report selected to present

schedule information should be prepared regularly as required by the Project

Execution Procedures. The project report – schedule should provide detail

progress information for the project team use. It is important that the schedule

selected and used should be fully understood by the users.

The project report schedule is recognised as the most useful technique to record

progress and is used at regular report reviews, being understood by most

members of the project team and graphically shows any variance between

planned and actual. The project report milestone schedule contains important high

level information and should be used as a first source to compile the executive

summary.

Progress information from the following schedules should be used to identify

variances or trends and to prepare rectification plans:

Milestone Schedule Review key milestone activities and their dates. Relies on

other schedule techniques to prepare remedial option plans.

Classic Bar Chart Review key activities and their impact on the critical path.

Relies on resource allocation schedules to confirm

practicalities or options. Used to prepare remedial option

plans.

Resource Histogram Review resource used and availability. Used to interpret

impact of resources on the critical path options.

Progress ‘S’ Curves Review progress to identify trends. Can be used to interpret

impact on the critical path options.

272

Fig 7.69 Project Report – Schedule Update

273

7.9.8 Project Report - Cost

The project report – cost update is a development of the cost estimate summary

prepared in Estimate Development. The prime cost content in the example is by

contract. Design and management, project specific and allowances should also be

included and should be detailed as in Estimate Development. The cost update

uses the wording budget rather than estimate and assesses actual costs incurred

and the summary is completed by regular review of forecast costs.

BUDGET – is the cost allowance for each element of the project.

Column A Original Budget – uses the sanctioned project estimate for each

element of work. If the sanctioned funds provided by the client differ from the

estimate the original budget should be the sum or budget to complete the work

agreed by the project team.

Column B Authorised Change Orders – as authorised change orders are

realised the allowed budget for change should be recorded. The authorised

change order should be allocated to the relevant element budgets. Funds could

be transferred between projects or elements of the project but should be formally

recorded as an authorised change order and registered as impacting on the

budget.

Column C Approved Budget – is the current authorised allowance for the

element or work and is the addition of the original budget to the authorised change

orders.

ACTUAL – is the current statement of cost for work authorised by the project for

completed activities and contractual obligations for work to be completed.

Column D Original Scope Award – is the cost associated with the contractual

arrangements entered into by the project and could be award sums for purchase

orders of the commitment by the project team to resources to complete the scope

of works.

Column E Variation Orders Agreed – is the cost associated with variations to the

originally awarded scope for work authorised by the project. The cost should be

an assessment of the likely cost.

274

Column F Current Scope Award – is the current order value stated as the

original scope award plus the agreed variation orders.

Column G Value of Work Done – see Cost Management for explanation.

FORECAST – is the current assessment of the final cost for each element of the

project.

Column H Anticipated Variation Orders – is the current assessment of

variations to the original scope of work identified, but not yet authorised as a

change.

Column I Anticipated Final Cost – is the current assessment of the final cost

calculated by adding the current scope award to the anticipated variation orders.

Column J Variance – is the reconciliation of the AFC against the approved

budget. The variance figure between these two should be minimal.

Column K Growth in Scope – is the reconciliation of the current assessment of

the AFC against the original scope award. This increase can be used as a trend

tool in assessing design completeness.

275

Fig 7.70 Project Report – Cost Update

276

7.9.9 Project Report - Change

The project report – change is compiled using the information from the change

order register, described in the change control section.

The project report change order update, records the current status of changes

authorised by the project team in accordance with the Project Execution

Procedures. The project report – change order update can be customised to

present movement in changes since the previous issue of the report. Information

from the project report – change order update is used to compile the project report

executive summary to state the total authorised changes since the previous issue.

The authorised change total should be expressed in cost and „progress‟ can be

compared by consideration of planned and actual contingency budget levels.

The information contained in the project report – change order update is as

follows:

Change Order Number Reference number – see change order form.

Change Order Description Brief description – see change order form.

Change Order Request Date Recorded date – see change order form.

Change Order Proposal Date Recorded date – see change order form.

Change order Authorisation Date Recorded date – see change order form.

Change order Inclusion in Schedule Information from project team resource.

Change order Request Allowance Information from project team resource.

Change order Budget Allowance Information from project team resource.

Note: Information included in reports should be based on authorised changes only.

277

Fig 7.71 Project Report – Change Order Update

278

7.9.10 Project Report - Risk

Project report risk is compiled using the information discussed in risk workshops

and recorded in the risk register, described in the Cost Management section.

The project report – risk update should contain the following information:

Fig 7.72

Executive Summary Statement of the key information agreed at the regular

workshop meeting and the results of the reworked

model.

Project Details Introduction to the project listing the objectives, key

milestone dates, assumptions, exclusions, constraints

and interfaces.

Process and Methodology Statement of the agreed proposed approach and

method of coping with and avoiding risks, and the

method of quantifying risks, ranking all risks and

issues.

Proposals Statement of the proposed ongoing management

process including the participation and ownership

responsibilities of attendees and risk owners.

Actions Plan Tasks to be carried out in the short term and

recommendations for future reviews.

Appendices

Workshop Attendees List of those members of the project team who

attended each risk workshop and their relevant

responsibility.

Issues Identified List of key issues raised at each risk workshop.

Risk Response Strategy Agreed chosen strategy to be used for the process of

risk management.

Risk Register Risk register, an example of which is shown in the

Cost Management section.

‘S’curve – Model Output Result of the simulation using @ Risk and/or

„Pertmaster‟ software using information form the latest

risk workshop.

The evaluation or risk in project report risk update should be considered as a cost

total against the contingency allowance. The review of the final cost total or risk

and project AFC should be considered as to the impact of the need for additional

279

project funding. If the funding is not sufficient the situation needs to be highlighted

and included in the project report – executive summary.

7.9.11 Project Report – Risk Update

This is the project record of discussion and outputs from each risk workshop /

meeting and will include the updated risk register, actions and recommendations

for ongoing management throughout the project.

A typical project report – risk update would comprise the following:

CONTENTS

i.

1. Executive Summary............................................................................... 2

1.1. Results from the Quantitative Risk Analysis (QRA) ................................................ 2

1.2. Issues Identification................................................................................................... 2

1.3. Risk identification ...................................................................................................... 3

1.4. Project Risk Register ................................................................................................. 5

1.5. Mitigation Actions Arising......................................................................................... 5

2. Project Details....................................................................................... 6

2.1. Introduction................................................................................................................ 6

2.2. Key Project Dates ...................................................................................................... 6

2.3. Assumptions .............................................................................................................. 7

2.4. Exclusions.................................................................................................................. 7

2.5. Constraints................................................................................................................. 8

2.6. Interfaces.................................................................................................................... 9

3. Process and Methodology.................................................................... 11

3.1. Risk Workshops....................................................................................................... 11

3.2. Ranking of risks ....................................................................................................... 12

4. Proposals for Ongoing Risk Management ............................................ 13

5. Actions and Recommendations ........................................................... 13

Appendix A: List of Workshop Attendees ..................................................... 14

Appendix B: Issues Identified....................................................................... 16

Appendix C: “S” Curve and modelling Output ............................................... 20

Appendix D: Risk Response Strategy ........................................................... 20

Appendix D: Risk Register............................................................................ 22

ii.

280

8 Conclusions

The use of inadequate project controls is affecting the delivery of projects on time

and within budget.

The thesis has achieved its aims in establishing how Project Controls is working in

the UK and determining what works and what does not work.

The research established from tacit knowledge, a questionnaire survey, a literature

review and three company audits of construction companies how projects were

currently controlled.

The research methodologies were then contextualised to establish if there were

common threads of strengths and weaknesses in current processes and systems.

In the event it was established there were common threads of weakness within

existing processes and systems.

Once we had established what the problems were related to Project Controls we

were then is a position to develop road maps and procedures of how we could

improve the controls. Road maps were developed and subsequently tested in

several industries as being the methodology for best practice for developing

project planning, cost management, progress measurement and reporting. Several

companies have incorporated the methodology within the road maps, and tool

kit/procedures as their method of controlling projects. Also the author has

examples of where the delivery of projects has risen from 25% achievement of

major milestones to a regular 85% achievement. These improvements are as a

direct result of improved systems and processes related to the research period.

With regards to the contribution to knowledge the thesis has demonstrated that UK

Industries in particular, Pharmaceutical, Building construction and possibly the

nuclear industries have major issues with respect to controlling projects. This

thesis has identified some of the key problem areas were controls are not working

and it has subsequently developed improved processes that can improve controls.

This knowledge could be used to carryout further research into how we can

transfer this knowledge to these industries. An example of this is demonstrated on

page 63 for example when it is apparent that the pharmaceutical company in

question needed to improve its Project Control procedures.

The conclusions will now look at the individual aspects of the research thesis:

281

8.1 Project Control Survey Questionnaire

The questionnaire was discussed with some 24 different companies and the

statistical analysis derived from the results gives a general view from the sample

taken, However, we are mindful that there could be an element of bias in the

results from the sample taken. The sample of 24 could be described as a low

figure on which to base discrete results; therefore we need to treat the statistical

analysis results with a level of caution when considering the size of the sample.

The questionnaire was also used to gain tacit knowledge from the project control

personnel interviewed and this feedback provides comments regarding the

effectiveness or otherwise of the project control processes being surveyed.

The survey indicated that cost control and estimating was only used by 46% of the

sample companies businesses and that 9% felt that control of projects was

impaired as a result of not applying best practice. The main issues for

improvement were the need to monitor changes in scope and that cost and

planning teams must work together more closely.

The survey results also showed that only 51% of companies used planning and

schedule control best practice on a regular basis. It was also established that 14%

of companies believed that project control was impaired as a result of poor

planning and schedule control. The main conclusions from the survey were to

ensure that schedules were baselined, improved training and buy-in from Project

Managers, effective software was to be utilised and some of the planning

engineers would benefit from additional training.

Change control results from the survey indicated that 51% of the companies used

change control systems to track changes in cost and time. However, 14% advised

that they felt that control of the project was impaired as a result of inadequate

change control processes. The management and control of changes is

fundamental to the success of projects. If changes are not captured and monitored

effectively then the control of the project costs and schedule will be detrimentally

affected. One of the main reasons why project fail is the lack of change control

processes.

Progress measurement and reporting was only carried out on a regular basis by

49% of the businesses surveyed and 8% felt that control of the project was

impaired as a result of ineffective reporting. Key areas for improvement were the

lack of baseline reporting, the reporting process not standardised and

282

improvements were also necessary to the reporting procedures. However, with

regards to key performance indicators most of the companies used earned value

analysis.

8.2 Company A Report

The main conclusions from this report were that project planning was not

approached in a consistent manner across the whole site. For example WBS and

coding structures were not standard, only 50% of the planning team applied

resources to schedules. There was minimum use of S Curves and earned value

calculations. Baseline planning was only used by less than 50% of the staff and

change control processes were again only used by 50% of the team. There was

generally very little integration between the cost and planning engineers and there

was no planning procedures or guidelines to ensure a consistent approach.

The cost engineering aspect of the site also indicated a lack of

guidelines/procedures. There was minimal alignment between the cost breakdown

structure and the work breakdown structure. Cost reports indicating actual costs to

date were completed differently across the site with no consistent approach.

Earned value reporting was being used, however there were differing views on

how this should be calculated. Risk management was not applied effectively and

regular reviews of changes were not carried out.

There was no standard procedure for change control and awareness of the need

to manage changes was limited across the cost engineers.

Finally cost and planning engineers were not integrated across the site this caused

major issues regarding reporting and gave rise to confusion and mis-

understandings.

8.3 Company B Report

Company B had a planning system in place, however, the client determined it was

not operating correctly and required improvement.

The current process developed schedules for most of the 50-60 active projects,

however, they were not resourced and not updated on a regular basis, and also

they were not base lined. It was necessary therefore to design a planning process

that improved the present system and improve the delivery of the 50-60- live

projects.

283

It was necessary to underline to the Project Managers that they were the owners

of the project plans. It was also a requirement that additional detail including

milestones be added to the existing schedules. Also as the portfolio of 50-60

projects were using the same resources it was necessary to resource load all

schedules in order that “peak” resource levels could be determined and managed.

In order that progress could be reported and corrective action initiated if necessary

it was required that a 2 weekly progress measurement system was implemented. It

was recommended that a regular progress review meeting be scheduled to ensure

the schedule was driving the projects and the project managers were accountable

for progress and corrective action.


There was minimum control being used by Company C, the method used to

control projects was an Excel spread sheet which monitored deliverables with no

defined durations or responsibilities. There was evidence that some project did

have project plans. However, once the programme of work was in the control of

the consultants or employers agent there was little in house monitoring other than

via the Excel spread sheet tracking device, which is a coarse method of tracking

progress.

The consultants used Microsoft Project to plan the work although there was no

regular methodology to measure and record progress. The role of the consultant

was to monitor the contactors progress, although as the contractor and the

consultant used different planning packages it was impossible to transfer progress

from one system to another. This obviously gave major issues with regards to

monitoring progress and initiating corrective action if a problem arose.

The contractors generally monitor and drive the projects by use of the plan,

although there is no work breakdown structure or formal reporting methodology,

the whole system therefore from contractor to consultant to company A

management was flawed with lack of relevant systems, procedures and

processes.

In order to rationalise the approach to effective planning and control it was

recommended that Company A migrate to Primavera P3e software to plan and

control costs. A pilot study was carried out and results presented to Company A

284

management, this revised system was subsequently adopted as the methodology

and process with which to plan and control their projects.

8.5 Commentary and Contextualisation of the Thesis

The results of the survey of 21 companies who completed the survey

questionnaire have a close co-correlation with reports from Companies A, B and

C, with the key conclusions being:-

With regards to planning issues Project Managers seem on many occasions show

a lack of understanding of planning and controls and they would benefit from some

training to improve their understanding, this conclusion manifests itself within the

questionnaire results and within Companies A, B and C.

The use of correct planning software is important to effective controls this

conclusion was observed in the questionnaire and with Companies B and C.

There is tendency for client organisations to have a hands off approach with

regards to planning and control when they appoint contractors to do work, this

conclusion was apparent from the questionnaire and Company C. This approach

can have detrimental outcomes for the project as the drivers for contractors to

maximise their commercial returns can be at odds with project requirements and

priorities.

The lack of work breakdown and coding structures was apparent in the

questionnaire results and in Companies A, B and C. The WBS is the cornerstone

of all control system and should be part of a good process to manage project.

The failure to recognise the importance of base lining the schedule was observed

in the questionnaire and with Companies A, B and C. It‟s essential that progress

measurement against an agreed base line is in place for schedule and cost control

to be effective and measurement against target undertaken.

The failure to develop a procedure for planning and schedule control was

observed within the questionnaire and with Companies A, B and C, again it

essential that planning teams have a structured approach to the process of

planning and schedule control.

285

Cost control and estimating conclusions are that both the questionnaire and

Companies A, B and C Indicated that was a need for better collaboration between

cost and planning personnel to develop an integrated approach to controls. It was

observed that the processes for cost and planning were not aligned and in some

instances there were no relationship between WBS, CBS for cost, planning and

estimating. The survey and Company reports also indicated that as a result of

inadequate change control planning and cost forecasts were inaccurate.

The issues of Progress Reporting indicated that the underlying conclusion was a

lack of procedures to correctly set out the methodology for progress measurement

and reporting and that the progress reporting was not analysed to implement

corrective action or mitigation processes.

8.6 Cultural Aspects

There is a definitive link between the culture of business and its approach to

project controls. The culture of, for example, pharmaceutical companies and other

process industries (with the exception of oil and gas and petrochemical

companies) has indicated a lower level of project controls. It would appear that

senior management in those industries has concentrated on the production of

goods for the market and the delivery of projects was a secondary issue. Also,

there appeared to be a lack of recognition on best practice and how project

controls was operating in the wider world. The author was able, by having

exposure to other industries, to recommend improvements to the pharmaceutical

industry, for example, by applying best practice as developed in the North Sea oil

industry in the 1980‟s.

There were other examples of below expectations with regard to project controls

and these were seen in the nuclear industry and road buildings.

8.7 The Oil Industry Model

The model of project control as developed by the oil industry in the 1980‟s, is

recognised as the model with which to provide control to projects. The model has

been recommended by the British government as the model to be adopted by the

nuclear industry. It is a tried and tested model that is applicable to any company

who manages projects. The road maps shown in section 7 indicate how the

process is developed.

286

8.8 Training

There is clearly a need for training of project managers to understand the need

and importance of project controls with regards to managing projects. Very often

the level of project controls is influenced by the project manager, as being

necessary to provide effective controls to the projects.

Due to the lack of understanding and training by project managers, however, the

level of controls seen as necessary is woefully inadequate. This lack of

understanding manifests itself in basic planning and controls being established

and the project control engineers not being allowed to develop some of the finer

points of control, e.g. „S‟ curves, earned value, resource planning, and earned

value analysis.

I would recommend that areas for future research would include –the role of the

Project Manager in Project Controls, to try to establish why so many Project

Managers do not use the Project Controls process to help with the management of

projects. This research could involve issues such as to current Project Controls

knowledge of the project managers, understanding of its benefits in managing

projects, and training needs to improve the level of understanding of controls. This

research could also be widened to include the training and experience of planning

and cost engineers, what makes successful control engineers. This research could

investigate what background, experience and training and education makes the

best engineers. Also it would be relevant to investigate, what additional training is

required to integrate the cost and planning disciplines as one of the keys to project

control success is the integration of the cost and planning disciplines. This thesis

has demonstrated on a number of occasions that the cost and planning disciplines

have not been co-ordinated and indeed in some instances have been going in

different directions, additional research is required to establish how this integration

could be improved with the resultant improvement in controls.

Further development of this Thesis/research could be around the implementation

of road maps in those sectors of construction that are seen as weak in terms of

project controls. An example of a sector that does not use effective project controls

is Building Construction. It would therefore be of benefit to use the road maps to

develop revised processes and systems to improve Project Controls in a sector

that currently lags behind many other sectors such as Oil & Gas and

Petrochemicals.

287

In the case of many companies the cost of implementing effective Project Controls

is not balanced with the savings that can be made by utilising effective controls. A

useful follow on research study would involve determining the cost of effective

controls. The road maps could be used as the template to determine best practice

and costs applied to the implementation of systems and processes.

Benefits of the road maps would need to be determined from improved completion

dates, lack of cost overruns, less commercial and delay claims and increased

productivity. It would be necessary of course to carryout this analysis over a

number of projects to determine the benefits of improved controls.

288

9. References;

Association of Project Management (APM 2004)

Avison, D, Baskerville, R, & Myers, M (2001) Controlling Research Projects. Information

Technology and People 14 (I), 28 – 45.

Czaja, R and Blair, J (2005) Designing surveys: A guide to Decisions and Procedures, 2nd

ed, Pine Forge Press Thousand Oakes, CA.

Dawood, N & Mallasi, Z Construction Workspace Planning : Assignment and Analysis

utilising 4D Visualisation Technologies, 2006 Computer-Aided Civil and Infrastructure

Engineering 21 2000 498 – 513.

De Falco, M, & Macchiaroli, R, (1998) Timing of Control Activities in Project Planning,

International Journal of Project Management 16 (1), 51 – 58.

Deng, MZM, & Hung Y.F (1998) Integrated Cost & Schedule Control: Hong Kong

perspective, Project Management Journal ea (4), 43 – 49.

EGAN, J 1998 – Rethinking Construction Report of the Construction Task Force & the

Deputy Prime Minister, John Prescott, on the Scope for Improving Qualities and Efficiency

of the UK Construction, DETR, London.

Elkington, P & Smallman, C (2002) Managing Project Risks: A Case Study from the

Utilities Sector, International Journal of Project Management 20 (1), 49-57

Evaristo, R & Van Fenema, P.C. (1999) a Technology of Project Management:

Emergence and Evolution of New Forms. International Journal of Project Management

17(s), 275 – 282.

Flemming, QW & Koppelman, Jim, (1999) Earned Value Management an introduction.

The Journal of Defence Software Engineering 11 – 14.

Flemming, QW. & Koppelman J. M (2000) – Earned Value Management Project

Management, Newton Square, P.A. Project Management Institute.

289

Fricke, S., & Shenhar, A.J. (2000) Managing Multiple Engineering Projects in a

Manufacturing Support Environment. ICCE Transaction on Engineering Management 47

(2) 258 – 268.

Globerson, S, & Zwikael, O (2002) The Impact of the Project Manager on Project

Management Planning Processes. Project Management Journal 33 (3), 58 – 65.

HM Government White Paper -2003 addressed to the UK Nuclear Industry.

Independent Project Analysis (IPA 2004)

Industry Benchmarking Consortium (I B C 2004)

Industry Benchmarking Consortium Cost Engineering Committee (CEC 1999)

Latham M 1994 – Constructing the Team, The Stationary Offices, London.

Marathon Oil UK -1984 Brae Field Developments.

Mawdesley, M, Askew, W & O‟Reilly, M 1997 Planning and Controlling Construction

Projects: The Best Laid Plans, Addison Wesley Longman, England.

Miller, R, & Leonard, D (2001) Understanding and Managing Risk in Large Engineering

Projects. International Journal of Project Management 19 (8), 437 – 443.

PMBOK Guide 2004-A guide to the Project Management Body of Knowledge (PMI 2004)

Regina Gyampoh-Vidogah, Robert Morelon, David Proverbs 2003, Construction

Innovation : Information, Process and Management Vol. 3 Issue 3 Page 257-173.

Rozenes S, Spraggett S & Vitner G (2006) Project Management Institute 37 (4)

5 – 14.

Rozenes, S, Vitner C & Spraggett, S (2004) MMDCS, International Journal of Project

Management 22 (2), 109 – 118.

Sadet, A; Duir, D., & Shenhar, AJ (2000) The Role of Contract Type in the Success of

R&D Defence Projects Under Increasing Uncertainty Project Management Journal 31 (3)

14 – 22.

290

Sheakar, A.J (2001) One Size Does Not Fit All Projects: Exploring Classical Contingency

Domains. Management Science 47 (3) 394 – 414.

Shtub, A, Bard, J, & Globerson, S. (2005) Project Management, Processes,

Methodologies and Economics 2nd Ed. New York Prentice Hall.

Sipper, D & Bufin, R (1997) Production Planning Control & Integration, New York,

McGraw Hill.

Songer, A.D., Hays, B & North, C Multi-dimensional Visualisation of Project Control Data,

Journal – Construction, Innovation: Information, Process Management 2004 Vol 4 Issue 3

173 – 190.

Tatikonda, M.V & Rosenthal, SR (2000) Successful Execution of a Product Development

Projects: Balancing and Flexibility in the Innovation Process Journal of Operations

Management 401 – 425.

University of Leeds (2006) Guide to Design of Questionnaires

White, D & Fortune, J, (2002) Current Practices in Project Management – An Empirical

Study, International Journal of Project Management 20 (2), 1 – 11.

291

10 Appendix

Project Controls Questionnaire

Project highlights

Education

research thesis

review of project controls

construction processes

improved project controls

status of project controls

phd thesis

thesis reviews

uk methodologies