MSIN0147

Lecture 10
Monitoring and control

Clive Vassell
Aims and Objectives

▪ To discuss:
— Project and programme monitoring and control tools and terminology
— Sources of project or programme change and effective change
management
▪ To be able to:
— Understand the importance of effective project and programme
monitoring and control
— Use project reporting and control tools and techniques
— Understand the importance of properly closing projects and
programmes
— Be able to recognise sources of change and describe an effective
change management process

Page 2
Project and Programme Monitoring
and Control

Establish Seek and Determine Evaluate Take action

monitoring receive progress progress to correct
strategy information against plan

Reduce uncertainty, anticipate problems,

build confidence
Page 3
Project and programme monitoring
strategy
▪ What is the information gathering process?
— Who reports what? to whom? when? how often?

▪ What sort of format are we going to use?

— Electronic? verbal? face-to-face? meetings?

▪ Consistent with the size, scope of the project?

▪ Consistent across the project?

— May differ for different project phases, work packages

▪ Communicate the strategy

— Make sure people are aware of what is required, set up meetings, give
people templates to complete, access to electronic systems

Page 4
Sources of information
▪ Formal
— Reports from team/work package owners,
project manager
— Reports from stakeholder groups, outputs from
meetings
— Quality control documentation
▪ Informal
— Discussions with sponsor, other senior
managers or stakeholders
— “Management by walking about” (MBWA)

Page 5
Issues with project and programme
information
▪ Who is telling me this?
▪ Why?
▪ Why now?
▪ Hidden agenda?
▪ How accurate?
▪ Project and programme managers need:
— a healthy degree of scepticism
— their own reliable sources of information

Page 6
Formal project and programme reporting
Portfolio
Management/
Executive Board

Programme
Sponsor or Board
Project
Board
Programme
Manager

Project
Manager

Team
members
Task
owners

Page 7
Report Content

▪ Project or programme name, date of report, reporting period

▪ Likely contents
— Project status: Red/Amber/Green
— Summary of progress
▪ corrective actions if necessary
— Spend / commitment
— Milestones complete / anticipated
▪ % complete of tasks
— Changes to risks
— Other issues
▪ May require escalation

Page 8
Frequency / depth

▪ Common to have regular reports

— Weekly / monthly
— Question this practice – is it right for your
project / this work package?
— Adjust frequency in each project phase?
— Milestones / reviews / gates
▪ Help inform all of changed reporting requirements
▪ Consider exception reporting

Page 9
Gate (or Gateway) reviews

▪ Undertaken at end of a project or programme phase or stage

▪ Determines whether we should proceed to the next stage
▪ Inputs:
— Evaluation of the project/programme so far
▪ to time/cost; quality of deliverables
▪ status of outstanding risks/issues
▪ detailed plan for next stage
— Assessment of performance (to date/forecast) against
business case
— May include an external audit
▪ Outputs:
— Proceed
— Proceed with changes
— Stop
Page 10
Any Questions?

Page 11
JLR Scenario

• Working in small groups, reflect on activity 1

• Be prepared to share your thoughts with the class

Page 12
Any Questions?

Page 13
Monitoring the schedule

Page 14
What to watch for (2)

▪ Monitoring progress
— the “nearly done” syndrome
▪ % done?
▪ estimated time to complete?
▪ Why are things happening?
— why milestone missed, activities not being
done?

Page 15
Showing progress on a Gantt chart

Page 16
Showing Progress on a Gantt Chart
October November December January February Marc
ID Task Name Duration 24 1 8 15 22 29 5 12 19 26 3 10 17 24 31 7 14 21 28 4 11 18 25 4
1 Start 0 days 10/16
2 Concept and System Design 30 days
3 Capture User Requirements 3 days
4 Develop System Concept 10 days
5 Review w ith Customer 2 days
6 Concept Agreed 0 days 11/3
7 System Design 15 days
8 Develop Sub-system #1 27 days
9 Design 10 days
10 Review 0 days 12/8
11 Manuf acture 15 days
12 Test 2 days
13 Develop Sub-system #2 13 days
14 Design 5 days
15 Review 0 days 12/1
16 Manuf acture 7 days
17 Test 1 day
18 Integration and Test 50 days
19 Develop Integration Plan 7 days
20 Develop Test Equipment 5 days
21 Integration 3 days
22 System Test 5 days
23 Acceptance 1 day
24 Delivery 0 days 1/15
25 Com m issioning 5 days
26 Hand over 0 days 1/22

Page 17
Milestones

▪ Significant event in the project

— something complete, delivered
▪ Unambiguous
▪ No duration, use no resource
▪ Key review gates
▪ May be related to payment
▪ Shown as a ♦ on Gantt charts
▪ Each milestone should have an owner

Page 18
Milestone slip chart

▪ Shows anticipated milestone date now

compared to baseline completion date
▪ % complete of tasks may be dubious
— milestones reached are definite
▪ Compare actual date with baseline date
(difference = variance)
▪ Record the dates as a function of report date

Page 19
Milestone slip chart

now

A
B

Page 20
Any Questions?

Page 21
JLR Scenario

• Working in small groups, reflect on activity 2

• Be prepared to share your thoughts with the class

Page 22
Any Questions?

Page 23
Project Control

Page 24
What tools do you have to control the
project?

(student ideas and discussion)

Page 25
Range of project/programme control

▪ Do nothing light

▪ Stop the project or programme

heavy

Page 26
Types of control
▪ Do nothing
— a considered response, not a failure to act
▪ Encouragement and advice
▪ Emphasis and clarification
▪ Increase or decrease supervision
▪ Reassigning tasks
▪ Adjustments to the scheduling of tasks
▪ Approval or otherwise of task commencement
▪ Modifications to the project plan
▪ Add, move or remove personnel
▪ Add or remove other resources
▪ Buy in more resource
▪ Stop the project or programme
Page 27
Project change management

▪ Change management is the process through

which changes to cost, schedule, scope or
benefits are identified, evaluated and
approved or rejected.

▪ Do not confuse project change management

with the management of change.

Page 28
Sources of change

▪ Business requirements
— competitive pressure, new personnel, senior management
▪ Stakeholder requirements
— revised idea of what the customer or the user wants
▪ External environmental changes
— Political, economic etc. – remember PESTLE
▪ Issues arising during the project or programme
— resources no longer available, technical failures
▪ Potential opportunities identified
— availability of new technology, other markets identified
▪ Errors or omissions in original plans
— not always clear what users/customer wants
Page 29
Benefits of change management

▪ Save time and cost

— no unnecessary change
— potential changes fully analysed
▪ against time, cost, quality and impact on benefits
— particularly important to enable change early on in the
project
▪ Originator fully aware of implications
— ideally before change decision made
▪ Project or programme compensated for extra costs or given
extra time
▪ Able to exploit opportunities
— change can be positive
▪ Keep the integrity of the project/programme, avoiding changes
in parts which may affect other documents
Page 30
or outputs
Change control process
Receive and
register

Evaluate

Recommend
and decide

No
Change
Close
accepted?

Yes

Implement

Page 31
Receive request
▪ Formal: in writing
▪ Internal (to the project) or external (by the customer)
▪ Must state:
— source and what is requested
— justification – impact on benefits
— costs – impact on budget, other resources
— impact on objectives and scope
— impact on risks
▪ Will typically have agreed formats
— part of governance/customer contract
▪ Don’t engage the formal process too early

Page 32
Register the Change

▪ Update Change control register

— Number in sequence
— Description
— Originator, date raised
— Impact assessor(s), date sent
— Status (being evaluated, agreed/not agreed)
▪ Distribute for evaluation
— Affected parties, Change Control Board (when appropriate)
▪ Change controller may be responsible for administration on behalf
of the project/programme

Page 33
Evaluation and Decision
▪ Review with all affected:

— Customer
— Sponsor
— Appropriate stakeholders

▪ Impact on project or programme

objectives/benefits

▪ Decision making authority part of project or

programme governance

— May have a specific Change Control Board

Page 34
Approval levels

Impact vs Level Programme Project in Stand-alone Sub-project or

Programme project work package

No impact on Programme Project manager Project manager PM or WP

schedule, cost, Manager manager
quality or scope

Some impact – Programme Programme Project sponsor Project manager

within agreed Sponsor Manager
contingencies,
no impact on
business case

Significant Programme Board Programme Board (Entity which Refer to project

impact – will not authorised the manager who will
deliver business project) escalate.
case objectives

Source: adapted from Young Page 35

Change Control Board

▪ Review and may make decisions on change requests

▪ Could include representatives from:
— Sales/Marketing (customer impact)
— Engineering
— Manufacturing
— Operations
— Procurement
— Commercial/finance/legal
▪ Senior representatives
— Other staff may carry out the impact analysis
▪ Comments around “informal” decision making apply here as well!

Page 36
Decision Criteria

Decision making body examines impact

• Safety
• Quality
• Cost
• Time
• Impact on benefits
… vs Necessity of change
Customer-generated? Customer Pays?  Implement (most of the times)!

Page 37
Outcomes

▪ Reject
— Closed
▪ Provisional approval
— Need more information
— Still open
▪ Approved
— Complete or partial implementation
▪ Impose limitations
— Open until tested
Page 38
Implement
▪ Changes adopted into project documentation
▪ Test if appropriate
▪ Update all relevant documentation
— when all have been done, the change is
closed
▪ Budget may be increased (customer-initiated
change) or funds drawn from management
reserve
▪ Inform – communication is vital
▪ "close" noted on the change register
Page 39
Very easy to be swamped by changes

▪ Beware of scope creep

▪ Avoid using change
control as a tactic to
increase contract value
▪ BUT enable innovation
and exploit opportunities

Page 40
Any Questions?

Page 41
JLR Scenario

• Working in small groups, reflect on activity 3

• Be prepared to share your thoughts with the class

Page 42
Any Questions?

Page 43
Break?

Page 44
Coursework Questions

Page 45
Configuration management

Page 47
What are we producing for the customer?

Page 48
What specification are we using?

▪ Spec v.01 21st August 2013.docx

▪ Spec v1 20th August.docx
▪ Spec NIGEL.docx
▪ Spec with marketing input.docx
▪ Spec v2.0.docx
▪ Spec Final 2013 08.docx
▪ Spec Final - LOUISE.docx
▪ Spec FINAL FINAL SEPT.docx
Page 49
What version of the plan are we on?

▪ Draft plan 1st August

▪ Plan v0.1 20th August.docx
▪ Plan agreed post project board 19th
August.docx
▪ Etc etc…..

Page 50
Configuration management

▪ Processes to manage "coherence" of project

information or outputs
— project deliverables and documentation
▪ Change control is an important process within
configuration management

Avoid uncontrolled change

Page 51
Configuration management

▪ Configuration: Functional and physical characteristics

of a product as defined in its specification.

▪ Configuration management: Encompasses the

administrative activities concerned with the creation,
maintenance, controlled change and quality control of
the scope of work.
APM Book of Knowledge 6th Edition (page 235)

Page 52
"Configuration Items" might include
▪ Physical items
— parts, tools, ingredients
▪ Requirements
— users, regulators, legal, safety
▪ Specifications
— designs, technical specifications
▪ Plans, drawings, code
▪ Project documents
— project plans, schedules, budgets, test plans
▪ Most important = the "as built" (to be delivered) product to the
customer
▪ Should include relationships with other items

Page 53
Links between configuration
management and change control
▪ Configuration management sets out which outputs /
deliverables are subject to change control:
— items which are critically important to get right
▪ Other parts of the project depend on them
▪ Customer requirements, technical designs and
specifications

▪ Once item is "frozen" any changes are subject to change

control

▪ Project must however be wary of "freezing" too early

— Enough time for development, innovation
Page 54
Conclusion
▪ Monitoring and control the major part of project
/ programme manager’s workload
▪ Reporting must be appropriate to the scale of
the project
— No “one size fits all”
▪ Project focus on outputs – time, cost, quality
▪ Programme focus on outcomes
— Including benefits realised from projects
already implemented
— And on remaining aligned with corporate
strategy
Page 55
Any Questions?

Page 56
Have your say!

Page 57
This week’s seminar

▪ Assignment structured abstracts

Page 58
Main Reading
APM v7 Handbook:
Sections 4.3
Supplemental Reading
Agile Project Framework:
Chapters 16
Thank you