PPMP 20010: Executing and Closing Projects

Lecture 5 –Project Control Systems I

Dr. Ronny Veljanovski, Bsc, PhD, GradCerTEd, PMPSenior Lecturer – Project ManagementSchool of Engineering & Technology | Higher Education DivisionCQUniversity Melbourne

Topics

• Overview– Progress– Future– Assignments

• Review PMBOK & PRINCE2• Recap of Weeks 2, 3, 4• Activities for Week 5

2

PPMP20010 Course Overview• This course is designed for project managers to develop their skills in the

executing and closing stages of the project life cycle. • The course considers several different definitions of what is required when

executing a project from the perspective of different standards, frameworks and academic works.

• Additionally, the course investigates projects according to industry, project domain, and other factors that influence approaches to project execution and closing.

• The content of inputs and outputs required and the tools and techniques applied are studied throughout the course.

• A highlight of the course is the practical application of project monitoring, earned value analysis, as well as control systems, and the management of control issues, such as, scope creep, risk, quality and baseline changes.

• The course also investigates project outsourcing, oversight, and contract closure.

• This course will be of interest to students that have a requirement to know more about project control, project auditing, management of external suppliers, and project termination.

Weekly Topics & Assignments

What We’ve Looked At:• Executing and closing projects• Project performance management.• Earned Value Management - I. • Earned Value Management - II.• Project Control Systems - I.

Still to Come:Project Control Systems - II.Project Audit.Project Termination.Project Governance - I.Project Governance - II.Integration Management – I.Integration Management – II.

4

Assignments:1. Earned Value Management Assignment (week 4) - 20% (done)2. Controls Assignment (week 6) - 20%.3. Audit & Termination Assignment (week 8) - 20%.4. Governance Assignment (week 10) - 20%.5. Presentation with Accompanying Script Assignment (week 12) - 20%.

PMBOK (2013) p51 Figure 3-2.Process Groups Interaction in a Phase or Project

5

Managing PRINCE2 (2009) p23Figure 4.2 The development path of the Business Case

6

Managing PRINCE2 (2009) p113Figure 11.1 The PRINCE2 process

7

Managing PRINCE2 (2009) p115Figure 11.2 PRINCE2 process model

8

ILX PRINCE2 process model

9

Managing PRINCE2 (2009) p167Figure 15.1 Overview of Controlling a Stage

10

Managing PRINCE2 (2009) p169Figure 15.2 Authorize a Work Package: activity summary

11

Managing PRINCE2 (2009) p170Table15.1 Authorize a Work Package: responsibilities

12

Week 1 & 2: Project performance management• Project performance management requires a structured and systematic approach to

measuring the performance of a project.• Directing Successful Projects with PRINCE2 (2009) page 85 section 9.3.1 identifies four

types of metrics that can be measured:– 9.3.1.1 Progress metrics– 9.3.1.2 Quality metrics– 9.3.1.3 Change metrics– 9.3.1.4 Risk metrics

• Kerzner (2013) page 1138 identifies five items required to manage complex projects:– New success criteria– Key performance indicators– Measurement– Dashboard design– Governance

• The PMBOK (2013) page 301 talks of performance reporting as the act of collecting and distributing performance information, including status reports, progress measurements, and forecasts.

• The PMBOK (2013) also discusses performance measurement in each of the knowledge areas as a means of control. Such as controlling scope, schedule, costs, quality, communications, risks, procurement and stakeholders.

Week 3 & 4: Earned Value Management• AS 4817-2006 : Project performance measurement

using Earned Value

• Dr Harold Kerzner Introduction to EVM (Movie 183MB)

• YouTube (link on Moodle):– Learn PMP Earned Value by Dave Litten (10 min 48 secs).– Learn drawing project S-curve for cumulative costs by

Engineer4Free ( 6 mins 35 secs)– Learn Earned Value Project S-Curve by Project Management

Tutorials (8 mins 05 secs)– MS Project 2010 Earned Value by VigenToT (12 mins 04 secs)– MS Project 2013 Earned Value by Roger Knowles (7 mins 02 secs)

Activities for Weeks 5

• PMBOK Chapter 3.8, 6.7, 8.2-8.3• Kerzner Chapter 5.0-5.5, 23 & A.E;• Directing PRINCE2 Appendix A• Managing PRINCE2 Chapters 9.3 & 10• AS/NZS ISO/IEC/IEEE 15288:2015 Systems and

software engineering - System life cycle processes

16

What is Control?

What is Control?

• PMBOK:– Comparing actual performance with planned performance,

analysing variances, assessing trends to effect process improvements, evaluating possible alternatives, and recommending appropriate corrective action as needed (p. 533).

• Kerzner:– Controlling is a three-step process of measuring progress

towards an objective, evaluating what remains to be done, and taking the necessary corrective actions to achieve or exceed the objectives (p. 225).

18

What is Control?

• Directing PRINCE2:– Control mechanisms; control points; change control; progress

controls; project controls (see index).

• Managing PRINCE2:– Chapter 15 Controlling a Stage– E4: Controlling a Stage

19

20Source: PMBOK 5th Ed.

PMBOK 3.8 – Project InformationSo

urce

: PM

BOK

5th

Ed.

PMBOK 6.7 – Control Schedule

• Monitoring status of project activities• Update project progress and manage changes to schedule baseline• Recognise deviation from the plan

Source: PMBOK 5th Ed.

PMBOK 6.7 – Control Schedule

• Week 3 – EVM & Trend Analysis Tools & Techniques• Performance Reviews

– Critical Path Method– Critical Chain Method– PM Software:

• Track planned dates vs actuals• Report variances to and progress made against schedule baseline• Forecast effects of changes to the schedule

– Resource Optimisation Techniques– Modelling Techniques

• What-If Scenario Analysis• Simulation

– Leads and Lags– Schedule Compression– Scheduling Tools

Critical Path Method

Source: PMBOK 5th Ed.

Critical Chain Method

Source: PMBOK 5th Ed.

Resource Levelling

Source: PMBOK 5th Ed.

Start and finish dates are adjusted based on resource constraints

Resource Smoothing

Activities of a schedule are adjusted but critical path is not changed / completion date not delayed

…within free and total float

Leads & Lags

Source: PMBOK 5th Ed.

Schedule Compression

• Crashing– Shorten schedule duration by adding resources– Cost associated– E.g. overtime, contract staff, expediting deliveries– On critical path– Increased risk! WHY?

• Fast Tracking– Compressing the critical path by having activities that are

normally done in sequence are performed in parallel for a portion of their duration

Schedule Compression

T1 T2 T4

T3

T1 T2 T4

T3

T1 T2

T4

T3

Original Schedule

Crashed Schedule-more resource on T4

Fast Tracked ScheduleT4 overlaps T2

PMBOK 8.2 – Perform Q.A

Source: PMBOK 5th Ed.

Quality Management & Control Tools

Source: PMBOK 5th Ed.

Quality Audits• Structured, independent process to determine if project

activities comply with organisation project policies, processes and procedures– Identify good and best practices being implemented– Identify all nonconformity / gaps– Share good practices in similar projects– Offer assistance to improve implementation to help raise

productivity

• This effort to correct deficiency should result in a reduced cost of quality and increase in customer acceptance of products developed

Process Analysis• Examine:

– Problems experienced– Constraints experienced– Non value-add activities

• Root Cause Analysis– Kerzner Chapter 20 –

cause and effect

PMBOK 8.3 – Control Quality

Source: PMBOK 5th Ed.

PMBOK 8.3 – Control Quality

Source: PMBOK 5th Ed.

PMBOK 8.3 – Control Quality

Source: PMBOK 5th Ed.

Managing PRINCE2 Chapter 15: Controlling a Stage15.1 Purpose:

– Assign work to be done, monitor such work, deal with issues, report progress to the Project Board, and take corrective actions to ensure that the stage remains within tolerance.

15.2 Objective:– Attention is focused on delivery of the stage’s products. Any movement

away from the direction and products agreed at the start of the stage is monitored to avoid uncontrolled change (’scope creep’) and loss of focus.

– Risks and issues are kept under control.– The Business Case is kept under review.– The agreed products for the stage are delivered to stated quality

standards, within cost, effort and time agreed, and ultimately in support of the achievement of the defined benefits.

– The project management team is focused on delivery within the tolerances laid down.

37

Managing PRINCE2 Chapter 15: Controlling a Stage15.3 Context:

– Describe the work of the Project Manager in handling the day-to-day management of the stage. This process will be used for each delivery stage of a project. Towards the end of each stage, except the final one, the activities within the Managing a Stage Boundary process (see Chapter 17) will occur.

15.4 Activities:– Are Project-Manager-oriented and comprise:

• Work Packages:– Authorize a Work Package – Review Work Package status – Receive completed Work Packages

• Monitoring and reporting:– Review the stage status – Report highlights

• Issues:– Capture and examine issues and risks– Escalate issues and risks– Take corrective action.

38

Managing PRINCE2 Chapter 15: Controlling a Stage

39

Source: Managing PRINCE2, AXELOS 2009

Managing PRINCE2 E.4: Controlling a Stage (p. 291-292)

40

No Question Yes/No

50 Have Work Packages been created and issued?

51 Have all the Team Managers agreed all their Work Packages?

52 Have completed products been produced in accordance with the Work Package and Product Description?

53 Have the relevant Configuration Item Records been created/updated?

54 Has the Quality Register been maintained?

55 Were any products handed over as part of a phased delivery? If so, were they handed over in accordance with the Configuration Management Strategy?

56 Has the Risk Register been maintained?

57 Has the Issue Register been maintained?

58 Has the Stage Plan been updated with actuals and revised forecasts?

59 Has the Daily Log been maintained?

60 Have Checkpoint Reports been received for each issued Work Package at the frequency and in the format agreed?

61 Was progress (actual and forecast) checked against agreed tolerances?

62 If tolerances were forecast to be exceeded, were they escalated to the Project Board?

63 If corrective actions were required, were they logged, implemented and tracked?

64 Was the Business Case periodically checked for ongoing viability?

65 Were Highlight Reports created and issued in accordance with the agreed reporting format and frequency?

66 Do Issue Reports exist for all issues being handled formally?

67 Do Exception Reports exist for all exceptions raised to the Project Board?

68 Has the Lessons Log been updated with any new lessons?

AS/NZS ISO/IEC/IEEE 15288:2015 Systems and software engineering - System life cycle processes• The complexity of man-made systems has increased to an unprecedented level. This has led to new opportunities,

but also to increased challenges for the organizations that create and utilize systems. These challenges exist throughout the life cycle of a system and at all levels of architectural detail.

• This International Standard provides a common process framework for describing the life cycle of systems created by humans, adopting a Systems Engineering approach. Systems Engineering is an interdisciplinary approach and means to enable the realization of successful systems.

• It focuses on defining stakeholder needs and required functionality early in the development cycle, documenting requirements, then proceeding with design synthesis and system validation while considering the complete problem.

• It integrates all the disciplines and specialty groups into a team effort forming a structured development process that proceeds from concept to production to operation.

• It considers both the business and the technical needs of all stakeholders with the goal of providing a quality product that meets the needs of users and other applicable stakeholders.

• This life cycle spans the conception of ideas through to the retirement of a system.

• It provides the processes for acquiring and supplying systems.

• It helps to improve communication and cooperation among the parties that create, utilize and manage modern systems in order that they can work in an integrated, coherent fashion.

41

AS/NZS ISO/IEC/IEEE 15288:2015 Systems and software engineering - System life cycle processes

42

AS/NZS ISO/IEC/IEEE 15288:2015 Systems and software engineering - System life cycle processes

5.2 System concepts – 5.2.1 Systems – 5.2.2 System structure – 5.2.3 Enabling systems

5.3 Organization and project concepts – 5.3.1 Organizations – 5.3.2 Organization and project-level adoption

5.4 Life cycle concepts– 5.4.1 System life cycle model – 5.4.2 System life cycle stages

5.5 Process concepts – 5.5.1 Criteria for processes – 5.5.2 Description of processes – 5.5.3 General characteristics of processes – 5.5.4 Tailoring

5.6 Processes in this standard– 5.6.1 Introduction – 5.6.2 Agreement processes – 5.6.3 Organizational project-enabling processes– 5.6.4 Technical management processes – 5.6.5 Technical processes

5.7 Process application 5.8 Process reference model

43

6 System life cycle processes – 6.1 Agreement processes – 6.1.1 Acquisition process – 6.1.2 Supply process

6.2 Organizational project-enabling processes – 6.2.1 Life cycle model management process – 6.2.2 Infrastructure management process – 6.2.3 Portfolio management process– 6.2.4 Human resource management process – 6.2.5 Quality management process– 6.2.6 Knowledge management process

6.3 Technical management processes– 6.3.1 Project planning process – 6.3.2 Project assessment and control process – 6.3.3 Decision management process – 6.3.4 Risk management process – 6.3.5 Configuration management process – 6.3.6 Information management process – 6.3.7 Measurement process – 6.3.8 Quality assurance process

6.4 Technical processes – 6.4.1 Business or mission analysis process – 6.4.2 Stakeholder needs and requirements definition process – 6.4.3 System requirements definition process – 6.4.4 Architecture definition process – 6.4.5 Design definition process – 6.4.6 System analysis process – 6.4.7 Implementation process – 6.4.8 Integration process– 6.4.9 Verification process – 6.4.10 Transition process – 6.4.11 Validation process – 6.4.12 Operation process – 6.4.13 Maintenance process – 6.4.14 Disposal process

AS/NZS ISO/IEC/IEEE 15288:2015 6.3.1 Project planning process

6.3.1.1 Purpose• The purpose of the Project Planning process is to produce and coordinate effective

and workable plans.• This process determines the scope of the project management and technical

activities, identifies process outputs, tasks and deliverables, establishes schedules for task conduct, including achievement criteria, and required resources to accomplish tasks. This is an on-going process that continues throughout a project, with regular revisions to plans.

• NOTE The strategies defined in each of the other processes provide inputs and are integrated in the Project Planning process. The Project Assessment and Control process is used to assess whether the plans are integrated, aligned, and feasible.

6.3.1.2 Outcomes• As a result of the successful implementation of the Project Planning process:

a) Objectives and plans are defined.b) Roles, responsibilities, accountabilities, authorities are defined.c) Resources and services necessary to achieve the objectives are formally requested and committed.d) Plans for the execution of the project are activated.

AS/NZS ISO/IEC/IEEE 15288:2015 6.3.2 Project assessment and control process

6.3.2.1 Purpose• The purpose of the Project Assessment and Control process is to assess if the plans are

aligned and feasible; determine the status of the project, technical and process performance; and direct execution to help ensure that the performance is according to plans and schedules, within projected budgets, to satisfy technical objectives.

• This process evaluates, periodically and at major events, the progress and achievements against requirements, plans and overall business objectives. Information is provided for management action when significant variances are detected. This process also includes redirecting the project activities and tasks, as appropriate, to correct identified deviations and variations from other technical management or technical processes. Redirection may include re-planning as appropriate.

6.3.2.2 Outcomes• As a result of the successful implementation of the Project Assessment and Control process:

a) Performance measures or assessment results are available.b) Adequacy of roles, responsibilities, accountabilities, and authorities is assessed.c) Adequacy of resources is assessed.d) Technical progress reviews are performed.e) Deviations in project performance from plans are investigated and analyzed.f) Affected stakeholders are informed of project status.g) Corrective action is defined and directed, when project achievement is not meeting targets.h) Project replanning is initiated, as necessary.i) Project action to progress (or not) from one scheduled milestone or event to the next is authorized.j) Project objectives are achieved.

PPMP20010 Project Controls Report for Controls Assignment1. Project Information

2. Controllable Categories

3. Configuration Procedural Outputs

4. Event Driven Controls

5. Time Driven Items

46

Project Management Domains

1. Engineering and construction domain2. Telecom/IT/Software domain3. Financial and business services domain4. Government & Welfare domain

47