12 Controlling the Project 14-15 (1)

8/10/2019 12 Controlling the Project 14-15 (1)

1/29

SESSION 12

CONTROLLING THE PROJECT

Aims

To discuss:

Monitoring and Controlling: Time Cost (see Earned value) Quality (see also Quality session) Deliverables Changes.

Objectives

To be able to:

Describe the role of monitoring process. Use schedule monitoring tools, including network charts, tracking Gantt chart

and milestone slip chart. Describe a configuration management and change control process.


2/29

Controlling the Project

12.2Issue 6-01 Aug 2014 MW, JB, UCL 2014

Introduction

Monitoring is the process in which the manager obtains information about conditionsin the project. They must then decide if the project is running according to plan, and

if it is not, take corrective action so that it does. This is Control.

Planning, monitoring and controlling occur continuously through the life of theproject. As we have seen there is a much greater emphasis on Planning at thebeginning whereas Monitoring and Controlling are activities that occur largely in themature phases of the project.

Figure 1. Planning, Implementation, Monitoring and Control occur in a continuousloop.

We will look at the tools of Monitoring and Control and also some of the issues ofjudgment a manager must make in order to keep this system balanced and

appropriate to their needs.

Monitor:

Collect, record, report information.

Control:

Reduce difference between reality and plan. Respond to changes. Initiate needed changes.

Initiate

Define & Plan

Monitor &

Control

Learn & Close


3/29



Monitoring

The aim of monitoring is to gather, record and report timely and accurateinformation about what is happening in the project.

This information will be compared to what's documented in the Project Plan, so it'simportant that the information gathered can be compared in this way.

Statements can be made in the three fundamental areas of project management,about any particular activity or work package. That is, for a given task, its Schedule,Cost or Quality may be reported in some way. These will be compared to theBaseline Plan.

The project environment and boundaries must also be monitored. The Environmentmay change in some way that affects the assumptions of the project, or the detail ofthe work. The Boundaries are in practice represented by the technical and

organisational interfaces.

Consider a change that has an effect on a project:

1. Is the change expected or unexpected?2. Is the consequence detectable or invisible?3. Is the correction cheap/easy or difficult/costly

Monitoring the project must detect all change that has an effect on the project.

An important part of planning is to design the information gathering system, or to

specify in advance of what types of information should be reported to the manager.

What to Monitor

It's not reasonable to expect a project manager to know everything. The managermust, however, be in possession of the relevant facts. The PM should try not to beburdened by reports about every conceivable aspect of the project.

Monitoring activities should focus on certain areas. These include the major risks (asidentified in the risk register), activities on the critical path, cost drivers (activitieswhich represent the largest items in the budget or budget category) and activitiesprone to complexity (e.g. interfaces).

Much of the monitoring is defined by a reading the components of a projects Plan,but there may be additional aspects that should also be identified in advance.

Attention should also be focused on those activities that directly affect the customerrequirements. If there are other important constraints, particularly those establishedby executive management, then activities that impact these should also be givenpriority.

Other parts of the project should be subject to a continual survey at a lower level of

intensity. This may be achieved through regular written reporting from team leaders.


4/29



Figure 2. Project monitoring points

Monitoring Should refer back to key project documents:

Business case are we still on track to deliver what our client wants?

Project strategy are we still going about this in the right way?

Work breakdown structures/work instructions are they producing the deliverables we want?

Schedule what progress are we making?

Resource plan is it still right? are the resources lined up?

Budget how much have we spent? how much is committed? whats the forecast

spend by the end of the project? Risk register

are the risks increasing? decreasing?

How To Find Out

Verbally Management by walking around, informal observation and talking Getting a feel for team progress

Written reports Capture many data types

Project team meetings Broad capture of information

Costly, because work stops for meetings


5/29



Management by exception Concentrate on variance from baseline only Potentially lower-cost management principle Requires Exception-based reports

Define methods in advance Plan meetings, reports, indicators

Presentation of Reports

Project reporting consists of the collection of progress data from the task owners,the collation and analysis of that information and its dissemination out tostakeholders including the task owners themselves.

A typical project reporting cycle might be:

Team workers to task owner: daily updates, e.g. on testing progress. Task owners to PM: weekly progress reports. PM to sponsor: weekly exception report. PM to sponsor: monthly progress report. Sponsor to board: monthly exception report. Contractor to PM: quarterly progress report (linked to staged payments). Sponsor to board: quarterly progress report.

Different stakeholders will have different information needs. For example, the PMand project team will work at a very detailed level of reporting, but senior

management and the sponsor are likely to require a less detailed level ofinformation. Project reports must be relevant to the recipient, and timely.

The PM must agree with task owners and stakeholders:

Performance measures to be reported. Format to be used. Frequency and timing.

There needs to be balance between giving progress reporting activities a sufficientlyhigh priority for timely information and project control, and time taken to collate thedata.

A typical task owner progress report format might be, for example:

Name, Date of report. Task configuration details. Narrative statement of progress in the last reporting period. Spend / commitment in the reporting period. Milestones completed in reporting period. Milestones anticipated in next reporting period. % completion of task. Changes to risk assessment in reporting period. Exceptional developments.


6/29



The WBS should be used as a guide when determining the structure and frequencyof report. Often there are very many individual tasks in a project; therefore workpackages should receive greater attention.

Although it is commonplace to have periodic reports (for example monthly) fromgroup or department heads, i.e. functional managers, this is not necessarily ideal. Itis better to have the work package owners report directly on the status of their workpackages with a frequency relevant to the intensity of the activities at the time.

The frequency should be higher and the report more elaborate if there is greateruncertainty of criticality with the work package, or if the work is being carried outremotely (at a co-operating institute or contractor).

Since it is easier to remember to submit to a regular report, it is better tocompromise by simply changing the frequency as the project moves through

different phases. An early definition stage might warrant frequent reports, whilst alater production effort might require only infrequent monitoring.

The PM should be aware of the dangers of becoming overloaded with information. Itis in everyone's interest for reports to be focused.

The transition between phases will be associated with formal project milestones,many details of the project administration will be expected to change at that time,and so a change in reporting frequency won't be unexpected.

Monitoring of the project also has a useful side-effect of promoting team morale andmomentum. A regularly updated Gantt chart displayed in the Project Office or insome other public space can be a major boost to the involvement of the team.

Monitoring the Schedule

Network diagrams can be adjusted to show progress. The symbol at each node mayinclude a cell in which the percentage progress is written. A common convention isfor completed tasks to be crossed through on the diagonal as shown here.

Figure 3. Indication of progress in a project network.


7/29



Gantt charts can also show progress effectively. The chart below is a common format(Microsoft Project: Tracking Gantt) where the progress of the task is represented bya shaded portion whose length represents the % complete. If progress on the task ison Schedule to date then the end of this portion should with todays date.

It is necessary for someone to enter accurate data in the % complete field for eachtask. Although project planning software allows task owners to automatically updatethe schedule, it is up to the project manager to ensure consistency of these values.This is an case where milestone reporting although notionally much cruder, is muchmore accurate than percentage progress.

Figure 4. Tracking Gantt View. Present time and task progress are indicated.

Milestone slip charts

One way of avoiding the syndrome that task completion is optimistically over-estimated (a common effect is rapid progress to 90% complete followed by slowprogress thereafter) is to focus on a set of well-defined milestone events.

Activity owners can then report whether the milestone has been achieved or what itscurrent expected date of achievement is.

It is extremely common when requesting reports about the rate of progress, to hear

numbers like 90% or 95%. To hear reports that rise quickly at the beginning of thescheduled time for the task and quite rapidly get to 90% or 95%. But then, whenthe task continues to be unfinished on week later, the report of progress goes to97% or 98%!

This syndrome, sometimes called theperpetual 90% done effect, is troublesome forthe project manager as it is difficult to tell what the real rate of progress really is.One way of avoiding this confusion is to focus on a set of well-defined milestoneevents, rather than attempting to measure all the tasks.


8/29


9/29



The chart is compiled as follows:

The horizontal scale is the project calendar.

The vertical scale shows the Monitoring period (reporting dates).

The diagonal line (called the completion line) is the present time at anymoment.

Milestone progress (achievement or slippage) is recorded on the chart on aregular basis by the project manager (e.g. weekly) by use of the differentsymbols (see key below chart).

No milestone can appear below the line it must either be already completed

(on the line) or planned to be completed in the future (to the right of theline).

How to interpret the example chart shown:

On the example chart, we are currently in Monitoring Period 6, Week 24 ofthe project.

This can be seen because the current status of the outstanding milestonesare all shown on the line for Monitoring Period 6.

The expected milestone achievement dates (the clear triangles) are plottedon the chart, and where they intersect the diagonal line is their predictedachievement date.

0

1

2

34

5

6

7

8

9

10

11

12

13

14

15

16

17

18

1920

0 4 8 12 16 20 2 4 28 32 3 6 40 44 48 52 56 6 0 64 68 7 2 7 6 80

W eek no

Monitoring

period

Connection Line Planned milestone Slippage (his torical)

Planned Dates Date achieved

.

Figure 5. . A simple milestone slip chart, demonstrated in Microsoft Excel.


10/29



In the example, the predicted achievement dates presume that the slippagefor all of the outstanding milestones will get no worse (e.g. the cause of thehistorical slippage has been resolved).

The second milestone, for example, has currently slipped to around week 38.This is the present predicted achievement date, and unless we are givenfurther information, we do not expect this to change over the next fewMonitoring Periods. This is the optimistic view.

Being pessimistic, we could also use the chart to extrapolate the slippages

A trend line can be drawn along the historical slippage points of eachmilestone (presuming that the slippage rate will continue).

This is then be extrapolated until it crosses the (diagonal) completion line,

giving another predicted completion date.

In the above example, milestone 2 would be achieved at around week 48 onthis basis.

Milestone dates, once set, require formal approval to be changed. Predicted slippageis not the same as a formally accepted change to the milestone delivery date.

If milestones are formally changed, this will require a re-issue of the milestone slipchart and, probably, the project plan.

If milestones are formally changed, this will require a re-issue of the milestone slipchart and, probably, the project plan.Advantages of the milestone progress chart:

Provides a clear view of the current status of milestone achievement andslippage.

Overcomes the ambiguity of % task complete a milestone is eitherachieved or not.

Provides a historical record of milestone progress. Can be used to forecast (through extrapolation) likely milestone

achievement dates. Extrapolation can be used to assess the impact of various milestone

achievement scenarios (e.g. if a slippage is on or will feed into the criticalpath).


11/29


12/29



Configuration Management and Change Control

A configuration is the functional and physical characteristics of the final deliverableas defined in its specification1.

The customer has specified a camera. What are we producing for the customer?

The as built product that the customer has specified:

What is Configuration Management?

Configuration management is the process to manage the integrity of the projectsdeliverables, and is very closely related to Change Control (covered later in thissession). Configuration management:

Controls the coherence of important information within the project.Uncontrolled changes to component parts of deliverables or projectdocumentation would lead to chaos, late delivery and overspend.

Is applied to:

The projects deliverables. Project documentation (documents which are deliverables, such as

operating manuals, and project management documentation such as thePMP etc.).

Supporting technical information (e.g. requirements specifications,designs, drawings, computer models, parts lists etc.)

Is applied throughout the life cycle and continues into operation (e.g.management of parts and spares).


13/29



At its simplest, configuration management must involve version control eitherversions of documentation such as project documentation and technicalspecifications, or versions of the end deliverables themselves.

The Need for Configuration Management

Reasons for requiring configuration management on a project include:

Deliverables are likely to be subject to change as they are developed. Needto keep records and an audit trail of the design evolution.

All project team members must be working to the same versions to avoidconfusion and production of incorrect products / products at the wrong time.

Avoid unnecessary costs caused by duplication / rework from uncontrolledchanges.

Stakeholders need to be informed if changes are planned to any of theproject deliverables.

Customers need to be in close touch with the evolution of deliverables toensure their requirements continue to be met, e.g. via configuration reviews.

The management of component parts of the deliverables throughout the lifeof the facility (e.g. spare parts for maintenance, repair etc.).

Stock control, ensure correct components are in stock and out of date ones

disposed of in some way.

Roles

Configuration Management Roles

In this process, the roles of the main parties are as follows:

Project manager: Responsible for the smooth running of the process,monitoring items under configuration control, evaluation of proposedchanges, and implementation of needed actions.

Change controller (change co-ordinator): Runs the configurationmanagement / change control process with delegated authority (also calledthe configuration manager or change clerk). This may be a part-timeappointment, undertaken by an existing staff member.

The project sponsor: Authorises changes where warranted, reviewing majorchanges and carrying out assessments of the business benefit of proposedchanges.

Project team: responsible for implementing their elements of the project inline with the configuration management plan. May be involved in identifying


14/29



configuration items and, for example, recommending when to freeze designobjects.

The client / customer: Consider the impact of changes, evaluation of effectsand give agreement to changes where necessary. May even be the instigator

of a change request (see later).

Users: Help to define requirements, particularly during the early stages ofthe design. May also help with usability testing (e.g. user interface /ergonomics) and may be consulted about proposed changes.

Other stakeholders may also be involved / consulted about configuration items /changes, e.g. design engineer, field maintenance engineer, quality manager, projectoffice.

The CM Process

Configuration management comprises five core activities:

CM Planning

Identification

Control

Staus Accounting Auditing

CM PlanningCM Planning is the process to establish the CM procedures and roles for the duration

of the project.

The CM plan is part of the PMP and should cover:

A description of the CM process to be used, referencing corporateprocesses and documentation as appropriate.

Approval and update authorities (e.g. who authorises changes, whoupdates documents etc.).

Identification of the items that are under configuration control.

The configuration item (CI) coding system to uniquely identify each item.

A plan of the libraries and files to hold configuration item documents (seealso Information Management session).

Identification of the Change Controller.

The set of configured items will be held within or referenced by a hierarchical set ofdocuments. To reduce the possibility of inconsistent information being referred to, itis best not to duplicate information in separate documents but to cross-reference.

In major, complex projects a Configuration Librarian (usually a member of theProject Support Office), responsible for the document library, may be appointed.

Identification


15/29



This is the process of determining whether an item in the hierarchy of deliverables,or an item of supporting information, is to be placed under formal configurationcontrol. These are known as configuration items (CIs):

Locate all the items required to deliver the project (including supporting

documentation and project management documentation). Establish the information to keep track of those items throughout the PLC

(e.g. coding, cross-referenced documents etc.).

Configuration items are identified through the PBS and WBS:

The items under configuration control will include: specifications, drawings,computer code, plans, budgets, schedules as well as physical product items.

One of the most important configuration items is the product that is deliveredto the customer. Its configuration should provide an unambiguous as-built

build standard. It should be known what this configuration is.

The initial configuration for the project is agreed with the client / sponsor at theDefinition stage. This forms the Baseline for the work which follows:

A Baseline is a set of approved values for items which form the basis forsubsequent work. Items are Baselined following a successful test or review.The status of the Baselined configuration items is frozen1, and these thenbecome subject to Change Control (covered later in this session).

In the early stages of a project, Baselined configuration items will be fairlytop-level (e.g. requirements, specifications and contractual obligations), asthe detail of, for example, the design components may not yet be fullyunderstood (and so cannot be frozen until work has progressed).

As the design progresses, the level of detail (and number of frozen items)increases.

It is important not to place items under Change Control (freeze them) tooearly, as this may cause unnecessary inflexibility resulting in delays, increasedcost etc.

Configuration Control

This is the process of controlling configuration items through each stage of the lifecycle, protecting finished items and controlling any changes to them.

As previously noted, during the design process there will invariably be changes to theprevious Baseline version as the design evolves:

Once an item is frozen (e.g. the specification, the final design once the project is inthe build stage), changes must be authorised by a formal Change Controlprocedure.

1Note: freeze in the sense here means Design Freezeand not Change Freeze which is different and

discussed later.


16/29



Therefore Configuration Control can be said to have two complementary aspects:Management of Baselines, and Application of Change Control procedures.

The figure below illustrates the evolution of a design. It shows items within that

design increasingly becoming frozen and the Baselining of the whole design overtime, until the complete design is frozen.

At each design review, the design at that point in time is Baselined as the agreedcurrent version of the design. Some items within the design will be subject toChange Control (frozen), whereas others are still in the process of being developedand will be frozen at a later stage.

Figure 6. Evolution of a Design

Design Objects (DOs) in the above diagram are those aspects of the design that

have not yet been frozen (work is still ongoing, and their status is not yet final).

Configuration Management and the PLC

In the Feasibility and Design phases, configuration management is most concernedwith refining the details of the specification and deliverables, and agreeing thesewith the client / sponsor. Most changes should be made in these phases.

The longer work progresses, the greater the knock-on effect of changes on otheritems leading to increased complexity of rework, delays and increased costs.

Once the build stage begins, changes should be minimised restricted toshowstoppers only (i.e. the system will not work without this change).

Design work Review

Design work Review

Design work Review

Baseline 1 Baseline 2 Baseline 3

time

The design space

Design objects

- Not frozen

FrozenConfigured

Items


17/29



Configuration Reviews

Regular design reviews are held with key stakeholders (e.g. client, sponsor, end

users etc.) to review and approve each refinement of the design (configuration).

This is then Baselined as the current version and handed over to the next stage ofwork. This process continues throughout the PLC.

Configuration Audit

This normally takes place at the end of a phase, stage or tranche and may be part ofthe configuration review process.

Generally it will take one of the following forms:

Physical: Review elements of a configuration to confirm that it meets itsspecification. It will check quality control results to ensure all necessarytesting has been completed.

Functional: Check that the configuration item performs the function for whichit was designed.

System: Audits the CM system itself to ensure that it is robust and able tosupport the necessary processes.

Configuration Auditing is the process of determining that the current configurationconforms to the agreed baseline and thereby back to the original requirements.

Effective auditing ensures:

1. That the design and implementation, as they evolve, is responsive toactual needs.

2. That unspecified capabilities are not included in the product.


18/29



Configuration Control

This is the process of controlling configuration items through each stage of the lifecycle, protecting finished items and controlling any changes to them.

As previously noted, during the design process there will invariably be changes to theprevious Baseline version as the design evolves:

If a Baselined version is changed, the previous Baseline version stays thesame.

A new version number is allocated to the new Baseline and the previousversion is never discarded.

Sometimes there may be a need to re-visit a previous Baseline to recreateelements of a previous version.

If an item is frozen (e.g. the specification, the final design once the project is in thebuild stage), changes must be authorised by a formal Change Control procedure(see later in these notes).

Auditing

Configuration Auditing is the process of determining that the current configurationconforms to the agreed Baseline and thereby back to the original requirements.

Aspects of the current design, or actual product, are traced back individually and

collectively to itemised requirement statements. Generally, a series of tables is usedto summarise the activity. These are called traceability tables.

The tables assist in the process of auditing, but do not constitute the auditingprocess itself. Careful thought is needed as to whether each element in theconfiguration being considered is adequate, given the agreed functionalrequirements.

The tables should permit forward and backward mapping between items in thebaseline and functional requirements.

Effective auditing ensures:

That the design and implementation, as they evolve, are responsive toactual needs.

That unspecified capabilities are not included in the product.


19/29



Status Accounting

This is an administrative function that involves recording and reporting of all currentand historical data associated with each configured item:

Configuration items, their version and specification. Baselines. Cross-references to applicable documentation. Change proposals. Problem reports. Modifications and repairs.

The aim is to allow an interested party to get a current statement on an item orcollection of items.

At each configuration review, the project team should note the current configuration

and any changes made since the last one. This provides a history of changes, incase the team needs to go back to a previous version (e.g. if a mistake is made in alater version).

Status accounting also aims to ensure that those working on the project are notusing outdated versions and are aware of any pending changes, e.g:

Authorised modifications which are awaiting completion of amendeddocumentation.

Complexities caused by superseding (major enhancement) configurations.

Ideally a database software system is used which allows rapid review of the status ofparticular items.

Document control is essential including the use of Issue numbers, distribution lists,date of issue, issuing authority, and a document list indicating the current version ofall documents.


20/29



Change Control

Change control is the process through which allrequests to change the baseline scope of a project

are captured, evaluated and then approved, rejectedor deferred.(APMBoK6)

Changes can be caused by:

Technical problems, e.g. testing revealsperformance shortfall or incompatibilitiesrequiring a change to a frozen item or thespecification. Changes in the early stages ofa project should be expected, but as a project progresses the knock-on

effect on other items, complexity and cost of making changes increases.

Incomplete planning, e.g. lack of detailed definition (common in the earlystages of a project), over-optimistic scheduling, unrealistic resourceconstraints (often imposed by senior management).

Unavailability of resources, e.g. individual expertise, equipment, facilities,funds etc. at the time when needed.

Organisational change, e.g. restructuring, may affect project teamstructure and membership.

Contractor difficulties. Even in the presence of contractual arrangements,the performance of suppliers and collaborators in meeting deadlines, budgetsand quality specifications may be poor.

Customer-originated requests, e.g. needs have changed, the originalrequirements were incomplete in some way, the customers own businessenvironment has changed or the customer may have emerging or evolvingrequirements. The contract will define how such changes are dealt with.Ideally, such variations in the contract will be funded by the customer. Thismay include the cost of evaluating the change request.

Suppliers / contractors. For example, a supplier (contractor) may identifythe opportunity to use a new production machine or process which, whilstbringing time or quality benefits, for example, may require a design ormaterials modification.

Variation Orders. These are required changes to the work that have beenidentified as being outside the agreed scope (and therefore subject to anadditional payment). They may start as customer-generated requests andbecome recognised as variation orders later as their relationship to theagreed scope of work is fully analysed.


21/29



Risk reduction. As risks become apparent, measures may have to be takento bring them to an acceptable level. Often this will involve a change to theproject.

Environmental change. For example, a new technology or component

becomes available, or an existing one (that was planned to be used) iswithdrawn from the market. Other PESTLE factors (e.g. new / updatedGovernment regulations) may also affect what is done on the project or how.

Not all changes in a project affect the project definition (the scope, deliverables andobjectives), and are therefore dealt with as part of the day-to-day management ofthe project.

Changes can occur throughout the project lifecycle, but the later in the lifecycle, themore expensive it is likely to be to make changes.

More work will already have been done (and might well have been wasted), andmore work is likely to be done to effect the change for example, changing theshape of new biscuits is likely to be much more expensive if requested after theequipment to manufacture them has been delivered than before.

A convenient way of identifying change which must be controlled is to say that it isany event that causes a significant change in any formally issued projectcontractdocument, drawing, or specification.

Uncontrolled changes in these areas lead to chaos, rework, wasted effort,delays and increased costs.

Change control is important to prevent uncontrolled scope or requirementscreep.

This links closely to configuration management where both deliverables andproject management documentation are subject to controlled change.

Amendments to project management documentation (e.g. the PMP, schedule etc.)may result as the project progresses, emanating from monitoring and controlactivities, progress reviews etc.

These amendments would be undertaken by the PM and would normally be

approved by the sponsor (e.g. as part of a review process).

Configuration management applies, with new version numbers and re-issueof the documents (as stated in the CM section of this session).

Where proposed changes affect the scope, deliverables, project objectives or frozenconfiguration items these would have to be requested and reviewed via a formalChange Control process.

In some circumstances it is appropriate to have a change freeze where no furtherchanges to scope will be considered (although those emanating from regulatory

requirements would probably have to be). Changes to scope might be when furtherchanges might jeopardise one of the projects objectives, e.g. no more changes


22/29



might be made to a new office layout in order for the work to be carried out in orderto meet the projects time objectives.

Change Control Process

The stages in the process are summarised:

1. Receive Request2. Register change request.3. Evaluation and Decision.4. Implement and Document.5. Close.

These are each discussed in more detail:

1. Change Request Generated

Change requests should always be made formally, in writing.

Changes may be generated externally (by the customer) or internally (e.g. within theproject organisation).

The contract with the customer should specify the appropriate document forrequesting a change, normally a contract variation order or purchase orderamendment.

Even requests from customers (which the customer should fund) should notbe implemented without review and evaluation, as they may affect the timeor performance of another deliverable.

Internal change requests should be submitted on a Change Request form,referred to in many industries as an engineering change request. The changerequest form should contain the following information:

The name of the requester. The date of the request. A unique identifier added by the Change Coordinator. The CI reference (drawing number, document number etc) of items that

would be affected by the change. The requested change brief description. A short justification. A rough estimate of the impact of the change in terms of cost and

schedule.

The form will also include space for the following, to be completed as theprocess is followed:

Authorisation or rejection decision and signature. Reason, if rejected. Any special conditions attached to the approval or rejection.


23/29



2. Enter Request in Change Control Register

The Change Controller enters the request in the projects Change Register.

The Change Register is a record which summarises all changes in the project. It is

used to track the status of all changes.

It should have, at least, the following fields for each change:

Serial number. Name of the originator. Contact details for the originator. CI reference. Brief, descriptive title of the change. Fields allowing the state of progress to be tracked, including a field for

final sign-off (when the change is either implemented or rejected) and

change (if any) to the project budget.

The Change Controller then arranges for the change request to be distributed tomembers of the Change Control Board.

3. Evaluation and Decision

The impact of the proposed change should be discussed with all those affected bythe change.

This includes the customer, sponsor, those involved with implementing the change

and other key stakeholders as appropriate (e.g. end users, if a change impacts howdeliverables will operate).

Change Control Board

The decision whether to approve the change is normally made by keyrepresentatives from the various departments in the project organisation, which formthe Change Control Board or Change Committee.

These often meet as a formally constituted body, although on smallerprojects the arrangements may be less formal (e.g. circulation of documents,

telephone, e-mail exchange of views).

Whatever arrangements exist, it is important that key departments are partyto the decision, and that approval is at an appropriate senior level.

The composition of this body will depend upon the particular configuration ofthe project, the relationship with the customer and the significance of thechange.

For an external change, the customer will be involved, and would in any caseneed to authorise changes to any contract.


24/29



The following are typical key roles within the Change Control Board:

The design authority. This person is competent to consider the effect thatany change might have on the performance of the delivered project. Forexample, an architect or chief engineer.

Inspection or quality authority. This role, which might be the sameperson as the design authority, will be focused on how the proposed changemight affect reliability, safety or other quality aspects.

Manufacturing department. Representatives of implementationdepartments will need to know the effect of any change on ongoing work,future work, and work already completed.

Planning and cost engineering. Detailed estimates on the effect ofchange on project cost and schedule may be necessary. In smaller projects

this is the task of the project manager but on larger projects this could be aseparate function.

Purchasing / procurement. Organisational units concerned with buyingshould be involved if a proposed change may affect outstanding purchaseorders.

Commercial / legal management. Advice may be necessary oncontractual or legal aspects of certain changes.

Decision Criteria

The Change Control Board would examine impact of the change on the following:

Safety. Performance / quality (e.g. reliability). Cost / budget. Time / schedule. The necessity of the change.

This also includes consideration of:

The impact of the change on other items yet to be delivered.

The impact of the change on items already delivered, and whether thechange should be retrospective or for future items only.

Whether the change is customer-generated (and they will pay for the changeto be implemented, in which case it is highly likely to be approved subjectto safety and reliability considerations).

An example of a simple evaluation process is shown in the following diagram.


25/29



Source: Lock2

Figure 7. Example Evaluation Process


26/29



There are three fundamentally different outcomes:

1. Outright rejection. Reasons should be given, and this results in theChange Register being updated and the change originator being informed.The change is now formally closed.

2. Provisional approval, subject to the originator supplying more informationor submitting the request afresh. The Change Register is updated to reflectthe new status and the originator informed. The change remains open.

3. Approved. The Change Register is updated and the originator informed.Work to implement the change is then carried out, and any necessarydocumentation changed accordingly.

In all cases, the decision must be recorded and signed-off on the Change Requestform.

In the case of approval, the extent to which the change is implemented must bedecided. The main options:

The change could authorise a complete and total implementation, whichmight involve recalling parts of the project that have been already delivered.

Less than total implementation could be made, so avoiding product recall butcausing scrapping or modification of parts already made.

Alternatively, the change could be authorised for new project work only.

Other limitations could be imposed on the change implementation.

4. Implement and Document

The accepted change is implemented, subject to a successful (re-)test if necessary,and becomes the new Baseline (see configuration management).

An essential part of implementation is the updating of all related projectdocumentation specifications, drawings, the budget, schedule etc. These wouldthen be re-issued with a new version number.

If the customer is paying for the change, then the budget would be increasedaccordingly. If not, the PM may have to draw down the appropriate sum from thereserve to increase the relevant budget.

5. Close

Once implemented, and when all relevant parties are informed of the change, theChange Request is closed by the Change Controller, and this status is noted on theChange Register.


27/29



Advantages of a Change Control Process

Change control process reduces the potential for scope creep. Scope creep iswhere additional requirements are added in (usually informally) with nosubsequent change to budget. They may all be quite small in themselves

(although not always) but can add up to a large increase in what has to bedone, not matched by an increase in time, cost or other resources. Reducingthe potential for this to occur saves time and moneyfor the organisation.

It provides a clear process, which should be understood by all (as part of theorganisations methods a procedures) to formally define, evaluate andapprove change. This ensures that everyone knows how changes toBaseline scope items will be made, leading to a culture which discouragesscope creep.

The formal process helps to regulate and reduce the number of changes tothe project, and will serve to police change freezes. This will facilitate

project progressas work is not being stopped / redone due to (especiallylate) changes.

A formal change control process ensures that change requests are thoroughlyevaluated and that only essential changes are permitted. This enablesresources to be focusedon project progression and priority activities.

The change register can provide as a knowledge base regarding causes ofchanges to the project. This can inform future projects, encouragingcontinual improvementand organisational learning and development.

The change control process should ensure that all stakeholder groupsaffected by the proposed change be consulted and give input into theevaluation process. This is beneficial in securing stakeholder buy-inandimproving communicationswithin and between organisations.

Disadvantages of a Change Control Process

These are largely to do with how the process might be managed.

Scheduling meetings to review change requests may be difficult due to thediversity of the change control board and their likely different schedules. Too

many will waste the time of the board members and too few will delay reviewof change requests.

Even without any problem in scheduling change board meetings, projectprogress can still be held upwhile awaiting the decision about a changerequest. This may be particularly true if the change request affectsforthcoming tasks on the project schedule.

Related to the above point, delays due to meetings scheduling and / orprocessing can result in development work becoming void. For example, ifwork currently being done ends up being invalidated by a change that is in thesystem.


28/29


29/29


REFERENCES1APM (2012) Body of Knowledge. (6thedition). Association for Project Management. PrincesRisborough.2Lock, D (2003). Project Management. (8thEdition). Gower. Aldershot.

RECOMMENDED READING

Field, M & L Keller (1998) Project Management. Open University. Oxford. Chapter 6.3Lester, A. (2007). Project Management: Planning and Control. (5thedition). ButterworthHeinemann. Oxford. pp142-143; Chapters 18, 19, and 27.Lock, D (2003). Project Management (8thedition). Gower. Aldershot. Chapter 23.

Young, Trevor. L (2003) The Handbook of Project Management. Kogan Page. London. Pp.197-20

Documents

12 Controlling the Project 14-15 (1)