Project Management Module 4 Script

Project Management Principles: Execute &
Finish Phases - Module 4

Topics:
1. An overview of the Execution stage of the life cycle
2. H/R and Communications management
3. Monitoring and controlling execution
4. Quality auditing and continuous improvement
5. Integration processes for the PM
6. Integrated change control
7. Finishing phase & getting handover right
8. Project Closure and reflection
9. Final recap of Project Management
10. Where to from here…
Topic 1: The Execute – or doing – phase overview

Welcome to Module 4 of the Project Management subject. In this subject we are going to
discuss:
• The Executing life-cycle phase in more detail, including:
o Executing processes for H/R and effective Communication
o Processes for monitoring and controlling progress on your project
o Assuring and controlling quality as well as seeking to continuously improve
processes and procedures
o Integration processes the PM is responsible for, directing execution and
monitoring and controlling the work.
o How to integrate changes into the project during execution with the minimum
of fuss
o We’ll also discuss the Finishing phase of the project, including:
o The two closeout processes of closing procurements and closing the project
or phase.
o How to manage handover of the project goal
o Why the team should always reflect on the running of the project at the end
o The importance of archiving project documentation for future projects
• Then I’ll provide a final recap of Project Management, summarising what we have
covered in these four modules
• And we’ll finish with a section on where you can progress to from this MOOC.
Project Management Principles: Execute & Finish Phases - Module 4 Page 1 of 35

• In Module 1 we introduced the acronym C-D-E-F to represent a four phase project
life-cycle, being the Concept, Development, Execution and Finishing phases. In the
last Module we looked at the Develop phase of the project life cycle, where all the
work for planning all foreseeable details of your project is performed. In this module
we’ll cover Execute and Finish!
• Do remember that just because you move into the Execute phase of the project’s life
cycle it doesn’t mean you may not be revisiting some of these planning processes
though! Invariably as the project moves into execution mode areas not previously
foreseen will raise their heads and necessitate revisiting some of those planning
processes!
• In this topic we will start with an overview of the management processes that occur
in the ‘Execution’ (or doing) phase of a project.
• The execute phase of the project is where you finally get to do some work!... not
really… you already have done a lot of project management work! It is just when the
work on the end goal of your project begins.
• Basically the Execute phase of the project’s life cycle is where the Project
Management Plan is put into action and the work activities as defined in the plan are
carried out according to the resources and time frames also contained there. In a
perfect world everything requiring execution will be contained in the Plan at the start
of the project’s execution but reality dictates that changes are likely to be required
which we will discuss in Topic 6 under Change Control.
• There are 42 processes PMBoK recommends for managing projects and 18 of them
fall into the two process groups of executing and monitor and controlling. Both these
process groups are typically utilised during the Execute phase of the project’s life.
• Where executing processes all revolve around completing the work that has been
defined as accurately as possible during the Develop phase of the project (all
encompassed in the Plan), the monitoring and controlling processes happen in
parallel as they require the tracking, reporting, managing and analysing of the
project’s progress. In fact to some extent these processes are used throughout the
entire project life cycle as at Concept, Develop, Execute and Closing phases
performance should be measured and reported on. Key personnel such as the
Project Sponsor are going to want to know how planning processes progress just as
much as the executing processes – after all without knowing where planning is at
they will not be able to assess how long it is until the work of creating the project
deliverable will start – or for that matter, assess whether it should.
• When reaching the Execute phase of the project’s life what is vital is that monitoring
and controlling processes are used to assess and inform key stakeholders about
how accurately the baselines created in the project management plan are being
matching by project performance.
• One of the key tools for scope, time, cost, communication and risk management is
Variance Analysis. In essence variance analysis is the observation of variance (or
difference) between planned and actual, and the considered response to resolve
that variance. Recording a variance is not sufficient – methods also need to be
determined as to how to either reduce the variance to an acceptable amount, or if
required get agreement to a change in the baselines to reflect the change that has
occurred between planned and actual.
• As long as the project plan is executed according to plan, and monitoring and
controlling processes are used to report on and validate that progress, the Execute
phase of the project’s life should continue for the period that the plan is being

activated. It is the phase of the project where you expect to see the majority of the
work carried out as well as the greatest amount of expenditure.
• The biggest risk to the project at this stage can be unmanaged project changes.
Unfortunately it may not be until project execution, when the first of the actual
project deliverables are being created and verified with the Client, that they realise
there are changes they would like. Having their – and end users – involved
throughout concept and planning is the best way to minimise this, but many project
leaders will be able to tell you how a client still ‘didn’t get it’ until they started seeing
the end deliverable being created.
• We’ll discuss the H/R and Communication execution processes in the next topic, but
at this stage we’ll have a quick look at the execution process for Procurement.
• In Module 3 we discussed how to plan for Procurements and the importance of
weighing up what parts of the project may be best procured, and how you may be
able to reduce risk in some cases by doing so. Here we will overview Conducting
Procurements.
• See the accompanying illustration for the inputs, tools & techniques and outputs.
o Conducting procurements inputs consist of: Project Management Plan,
Procurement documents, Source selection criteria, Qualified seller list, Seller
proposals, Project documents, Make or buy decisions, Teaming agreements,
Organisational process assets.
o Tools & Techniques recommended are: Bidder conferences, Proposal
evaluation techniques, Independent estimates, Expert judgement, Advertising,
Internet search, Procurement negotiations
o Outputs are: Selected sellers, Procurement contract award, Resource
calendars, Change requests, Project management plan updates, Project
document updates
• Just as we earlier warned against seeing “winning a tender” as a project goal,
without proper evaluation of the SOW, being the organisation seeking procured
services also has traps. Make sure you thoroughly evaluate seller proposals using
the T&T described for this process. Too many have been caught out by over-
enthusiastic bidders and been complacent because they believe penalties for non-
provision or missed deadlines will ensure the selected seller will provide the
procured service, product or result. However history shows us that without proper
analysis you may end up with a sub-standard result or nothing at all and you need to
weight up the risk of that occurring, as if it endangers the success of your project,
regardless of it being the provider’s fault, as Project Manager you are likely to end
up wearing the blame.
• We will next examine execution processes for H/R and communications in greater
detail as these two knowledge areas are both closely related as well as requiring the
best of a PMs “soft skills” in communicating and displaying emotional intelligence!
o Before progressing to the next topic encourage to look at the Readings Tab.
“All That You Need to Know Regarding Execution of Projects” on the Bright
Hub PM website.

Useful Links
VIDEO:
• http://www.youtube.com/watch?v=vDkuYoMvgG0 Overview of conducting
procurements using PMBoK Ed.5 process by Tamilselvan Mahalingam
• http://www.youtube.com/watch?v=vl_nmOZB2Og Good overview of project
procurement basics, looking mostly at what procurements are and how to plan them.
WEB:
• http://en.wikipedia.org/wiki/Emotional_intelligence Overview of what emotional
intelligence is.
• http://www.maxwideman.com/papers/procurement/procurement.pdf Review of book
on Procurement Management that includes useful information.
• http://www.building.co.uk/news/qs/apc-trainer-on-procurement-and-tendering-
%28t062%29/3112815.article Explanation of procurement and tendering processes
• http://www.projectsmart.co.uk/ten-tips-for-running-successful-projects.html 10 tips
for running successful projects by Leslie Allan.
• http://www.brighthubpm.com/project-planning/3387-how-to-effectively-plan-and-
execute-a-project/ “How to Effectively Plan and Execute a Project” by Joe Taylor
• http://www.brighthubpm.com/project-planning/124879-all-that-you-need-to-know-
regarding-execution-of-projects/?cid=parsely_rec All That You Need to Know
Regarding Execution of Projects, with hyperlinks to supporting information.

Topic 2: H/R and Communications management
o In this topic we will look at the 5 executing processes for the h/r and communications
knowledge area.
o The first set of processes we will look at belong to the Human Resources knowledge
area. They are:
1. acquiring the project team,
2. developing it and
3. managing it.
o Should be obvious having the right people for the job is a really good start for running a
project successfully. While having team members that have been involved with projects
before, and who have had some form of training in project management processes will
help, for most of the team what will be critical is that they have the technical skills
required to carry out the work activities they have been assigned to and the personality
traits to work well in a team. The most skilled individual in the world can throw a project
into chaos if they refuse to work in with the team!
o See the accompanying illustration for the inputs, tools & techniques and outputs of
acquiring the project team.
o Acquiring the project team consist of:
o Inputs: project management plan, enterprise environmental factors and organisational
process assets.
o Tools & Techniques recommended are: Pre-assignment, Negotiation, Acquisition and
Virtual teams
o Outputs are: Project staff assignments, resource calendars, project management plan
updates
o Because acquiring the project team should be partly based on what skills are required for
the project work – as worked out in the Time management processes where the team
has broken down the work of the project into an extensive list of activities and estimates
of sequence, duration and resources required for each, acquiring the project team is
listed in PMBoK as happening in the Execution phase –, so there will be informed
decisions made about who needs to be brought onto the team.
o However while it makes sense to acquire members with specialist skills after working out
whihc skills are needed, this doesn’t fit with the recommendations we made back in
Module 2 about making sure that the PM involved their team members in doing the
estimates as – after all – the best guidance on how long a task will take and what
resources it is likely to require are likely to come from the SMEs in that area! It also
doesn’t fit with the suggested input of “Resource Calendars” for estimating activity
resources!
o This is all symptomatic of the slightly egg-or-chicken first nature of project management...
just as it is often pointed out that it is easy to be clever in hindsight, many project
planning processes are easier done after other planning processes have been
performed, but because – as in the case of acquiring a team and planning what the team
member skills need to be – they can’t both be done simultaneously – project teams
instead rely on iteration... being repeated as more knowledge is discovered.
o In truth it is likely that the key project team members – which will include people with SM
Expertise – will be put together at the end of the Concept phase, and with the key team
providing expert advice throughout planning, the whole team can be acquired at the start

and during the execution phase as required. After all there are many projects that require
specialist skills at only some stages and so there is no point in hiring staff that are not
going to be required until sometime in the future.
o In the interim plans can be made with “job titles” instead of people’s names assigned,
denoting the need for a “human resource” but not specifically who that will be.
o The Resource Calendar “output” of this process simply documents the availability, work
time wise, of each of the project team. It should include any pre-booked leave or
commitments. This information can obviously have an impact on a number of other
processes – such as task durations and activity sequencing. If a person with a key skill
the Project Team really wants to utilise for some activities is not going to be available for
a certain block of team then activity sequencing may need to be adjusted and accordingly
some lead or lag times added to other activities or team reassignments to ensure the
time when waiting for that particular person to be available is fully utilised.
o Next let’s look at “Developing the Project Team”. See the diagram for process inputs,
T&T and outputs.
o Developing the Project Team consists of: Inputs: project staff assignments, project
management plan, resource calendars.
o Tools & Techniques recommended are: Interpersonal skills, Training, Team-building
activities, Ground rules, Co-location and Recognition and rewards.
o Outputs are: Team performance assessments and updates to enterprise
environmental factors
o Building a team is something that can occur in many different ways. For instance, though
it is not listed within PMBoK, once the final project team is assembled and the project
management plan is ready to execute a kick-off event should be held for the execution
stage of the project.
o We already mentioned a kick-off event at the end of the Concept phase- which would be
for the key Project Team members – but a further kick-off event should not be
undervalued. While you and your immediate team that have planned out all the work that
needs doing will be feeling very familiar with the scope and objectives, staff that have
been especially recruited or ‘seconded’ for the technical work of the project will really
benefit by knowing what the organisational “vision” behind running the project is.
o The benefits of running a kick-off event for the entire project team are the same as
holding one for your planning team:
• Everyone gets to be on the same page when it comes to understanding the project
objectives and goal
• Roles and responsibilities, including who to go to in management for direction or
assistance, will be clearer
• Allows opportunity for people to ask questions and hear answers from “the horse’s
mouth”.
• Outlines important processes and procedures you wish to see team members follow.
• Helps everyone know how communication will work and where important documents
such as the Project Management Plan can be found.
• Confirms the “project proper” has begun – in other words that the PM Plan has been
formally authorised to move to execution.
• Additional benefits are that the Project Manager can demonstrate their leadership
qualities by enthusing team members about the project, organising the meeting

effectively so everyone feels their time has been well spent and empowering people
by letting them know where to go for what and what their responsibilities are.
• A well run kick-off event will help in the work of building a strong team ethos, as all
present should feel they are an important part of the project.
o Another simple and productive way to help build a team is to involve them in planning
processes. As a PM you would benefit from their knowledge, and they will benefit from
knowing their opinions are being sort and listened to.
o The next execution process for Human Resources is to manage the project team. See
the accompanying image for inputs, t & t and outputs.
o Inputs: project staff assignments, project management plan, Team performance
assessments, Performance reports and organisational process assets.
o Tools & Techniques recommended are: Interpersonal skills, observation &
conversation, project performance appraisals, conflict management and an issue log.
o Outputs are: Change requests, organisational process assets updates, project
management plan updates and enterprise environmental factor updates.
o The “tool” of an Issue log has not been previously discussed. While most people are
familiar with Risk Registers, that help document, track and monitor unexpected (in the
future) events that may impact the project either positively or negatively, an issue log is a
place where issues (things that have eventuated) can be logged. Team members &/or
stakeholders may raise issues that require some action to be taken to prevent them being
hindered in their work. The logged issue should be assigned a measure of urgency and
allocated to an individual for resolution by a proposed date. As part of communications
management Issue logs need regular assessing and attending to as unresolved issues
may end up causing delays and major conflict, none of which is good for the harmony of
the team and may block the team from achieving the project objectives.
o The next set of processes we will look at belong to Communications Management
knowledge area. There is a fair overlap between the outputs of human resource and
communication management as you may expect. People management and effective
communication usually go hand in hand.
o The communication management processes are:
1. distributing information and
2. managing stakeholder expectations (which includes the project team members as
well as other external and internal stakeholders).
o The first execution process for Communications we will examine is to distributing
information. This sounds simple but what you distribute to who actually requires some
careful consideration. Overloading people with information they don’t need to know can
lead to saturation and a tendency to just ignore all communications – which can be
extremely dangerous. In the same way not keeping the right people informed about
relevant information for them can lead to gaps in understanding which in turn can lead to
frustration and conflict within the project.
o See the accompanying image for a list of the inputs, T&T and outputs for distributing
information.
o Inputs: Project management plan, Performance reports and Organisational
process assets.
o Tools & Techniques recommended are: Communication methods, Information
distribution tools

o Outputs are: Organisational process assets updates.
o Sounds simple but must be done well. For instance avoid overloading people with
information as there is a risk they will simply “tune out” which can be dangerous as they
may then miss information critical to their work tasks.
o The tools & techniques for information distribution have been dramatically impacted by
advances in electronic communication. As the internet backbone increases in bandwidth
and speed more and more effective real time communication is occurring between
geographically remote team members. Resultantly project team members and
stakeholders are increasingly being able to travel and maintain effective communication
more easily. Similarly expert judgement is able to be sought from further afield to make
sure that the best possible information and communication inputs and outputs are
achieved.
o The next Communications execution process we will look at is managing stakeholder
expectations. As we discussed back in Module 2 understanding who your stakeholders
are, what their interest in the project is and their potential influence is one of the key
processes in initiating a project at its Concept phase. The importance of stakeholders is
demonstrated by the need to formally manage their expectations. The illustration shows
the inputs, T&T and outputs PMBoK outlines.
1. Inputs: Stakeholder register, stakeholder management strategy, Project
management plan, Issue log, Change Log and Organisational process assets.
2. Tools & Techniques recommended are: Communication methods, Interpersonal
skills and Management skills
3. Outputs are: Change requests, organisational process assets updates, project
management plan updates and project document updates.
o Effective stakeholder management will mean you keep the right people supporting and
championing your project throughout – which should very importantly include your team –
it should also help you to manage the negative influence of those that seek to demote or
discredit the project so as to not have a seriously negative impact.
o The Monitoring and Controlling processes we will examine next obviously need to be
occurring at the same time project execution is taking place so that the progress of the
project is measured as it is executed. There is very little point in waiting until the end of
project execution to report that the project has run over time, budget and not met scope
or quality standards!
 Before progressing to the next topic encourage to look at the Readings Tab and have
a look at Simon Wallace’s free electronic Project Management book’s chapter on
Team Management for useful information on this area.
 It would be great if you could take the opportunity to discuss in the Forum innovative
methods you are aware of for communicating between project stakeholders. There
are some great ideas and methods available and project leaders will benefit from
knowing the widest tool-set possible for allowing stakeholders to effectively
communicate, regardless of their geographic location.

Useful Links
VIDEO:
• http://www.youtube.com/watch?v=qxjuo4Vnp6U How to kick-off a project
• http://www.youtube.com/watch?v=cJ91fLrTL9Q A 48 minute webinar on project
communications and reporting
• http://www.youtube.com/watch?v=90RiAJTNUss Video on managing stakeholder
expectation process and the goal this aims to achieve.
WEB:
• http://www.epmbook.com/team.htm In depth look at building teams for projects
• http://www.techrepublic.com/blog/project-management/get-everyone-on-the-same-
page-with-a-project-kickoff-meeting/138 benefits of having kick-off meetings
• http://www.tutorialspoint.com/management_concepts/project_kick_off_meeting.htm
• http://goodkickoffmeetings.com/tips/ designed for Web Project kick-offs.
• http://www.projectmanagementdocs.com/project-execution-templates/employee-
annual-review.html template for reviewing employee performance
• http://www.projectmanagementdocs.com/project-documents/issue-log.html Sample
and template for Issue Log.

Topic 3: Monitoring and controlling execution
In the last two topics we looked at most of the executing processes used for managing
human resources, procurement and communication. As earlier discussed monitor and
controlling is all about tracking the performance of the project, reporting on it and using tools
and techniques to help keep it on track – or in the case of a variance – bring it back on track!
In this topic we will look at the processes used for monitoring and controlling the project
scope, costs and communications as well as risks and procurements.
Scope management requires monitoring and controlling to:
1. Verify scope
2. Control scope
The Verification of scope process requires (as illustrated)
• Inputs: Project Management Plan, Requirements documentation, Requirements
traceability matrix, Validated deliverables
• Tools & techniques: Inspection
• Outputs: Accepted deliverables, Change requests, Project management documents
Note that the work done back in “Collecting requirements” – before you had even defined the
scope, also helps to monitor scope verification, by providing information about the
stakeholders documented requirements to verify if they have been met. This is typical of
where the early work performed in a project’s planning can pay off when it comes to getting
acceptance of the project goal.
Inspection is the only tool for verifying scope – basically this is where the work and
deliverables are checked to make sure they meet the requirements documented at project
start that were defined by setting measurable outcomes and success criteria, the WBS work
packages and any deliverables that have already been checked by Quality Control for
correctness. These inspections may be called product reviews, walkthroughs or audits – it
doesn’t really matter. What they are about is confirming that what was agreed to have been
done is being done. If it has the deliverables inspected will be accepted.... if not it is likely a
Change Request will result, requiring assessment and integration via integrated change
control, which if accepted will likely result in updates being made to various project
documents and rework.
The sooner you can actually verify scope is being met during execution the more confident
you can be that you will be meeting the customers’ requirements at handover.
The scope control process requires (as illustrated)
• Inputs: Project Management Plan, Work performance info, Requirements
documentation, Requirements traceability matrix, Organisational process assets
• Tools & techniques: Variance Analysis
• Outputs: Work performance measurements, Organisational process asset updates ,
Change requests, Project management plan updates, Project document updates
Variance Analysis was briefly discussed in the introduction to this module. In this case it is
used to measure the variance between the originally defined scope and the scope during
execution. If too great a difference occurs between planned and actual work then either
corrective or preventative action may be required. Corrective action is documented directions
designed to bring the project execution back in line with the scoped work from the projects’

scope baseline where preventative action is documented directions to alter future actions so
that the scope may be brought back on line before execution is finished.
Monitoring and controlling of Time management requires a process of:
1. Control schedule
• The control schedule process requires (as illustrated)
o Inputs: Project Management Plan, Project Schedule, Work performance info,
Organisational process assets
o Tools & techniques: Performance reviews, Variance Analysis, Project
management sware, resource levelling, what-if scenario analysis, adjusting
leads and lags, schedule compression and scheduling tool.
o Outputs: Work performance measurements, Organisational process asset
updates , Change requests, Project management plan updates, Project
document updates
• The tool of Variance Analysis in controlling the schedule basically works in the same
was as for scope control – it looks for difference between the baseline and the
actual execution and uses variance over a certain amount as a trigger for corrective
/ preventative action.
• Schedule compression occurs by either fast tracking or crashing. Fast tracking is
where activities originally defined as being performed sequentially (e.g. FS or SF)
are altered to happen in //. Generally increases risk of rework though! Crashing is
doing things to shorten the timeline like paying for overtime or bringing in additional
staff and / or resources – so generally incurs a financial penalty.
• Cost management monitoring and controlling requires the one process:
1. Control of costs
• The control costs process requires (as illustrated) :
o Inputs: Project Management Plan, Project funding requirements, Work
performance info, Organisational process assets
o Tools & techniques: Earned value management, forecasting, to-complete
performance index, Performance reviews, Variance Analysis, Project
management sware.
o Outputs: Work performance measurements, Budget forecasts, Organisational
process asset updates , Change requests, Project management plan updates,
Project document updates
• Earned Value Management (EVM) was developed for financial analysis back in the
60’s but has become a popular tool in project management since the 1980s. What is
special about it is that it allows PMs to combine measurements of scope / schedule /
cost in a single system to track and forecast project performance. It helps with both
monitoring and measuring variances from baseline. There have been studies that
have shown a positive connection between EVM and project success rates.
• Communications management requires:
o Report performance
• The report performance process requires (as illustrated)
o Inputs: Project Management Plan, Work performance info, Work performance
measurements, Budget forecasts, Organisational process assets

o Tools & techniques: Variance Analysis, forecasting methods, communicating
methods, Reporting systems
o Outputs: Performance reports, Organisational process asset updates ,
Change requests
• Performance reports – often referred to as Status Reports – are probably the most
commonly understood method of monitoring and reporting on project progress. They
range between different companies in complexity and frequency, but what they
should all show is:
1. Work completed for the last period
2. Work scheduled for completion for the period ahead
3. Notification / explanation of variance
4. Summary of any changes requested
5. Current status of any risks and issues
6. Currently forecast project end date (and possibly cost).
• Risk management requires the process of:
2. Monitor and control risks
• The monitor & control risks process requires (as illustrated)
o Inputs: risk register, Project Management Plan, Work performance info,
performance reports
o Tools & techniques: risk assessment, risk audits, Variance & trend Analysis,
technical performance measurements, status meetings.
o Outputs: Risk register updates, Organisational process asset updates ,
Change requests, Project management plan updates, Project document
updates
• The success of monitoring and controlling risks will be largely dependent on how
good a job the team has done of identifying risks, analysing them and planning
responses. What is vital is that throughout the life of the project the risk register is
used to frequently reassess the “risk landscape” as continuing to identify as well as
deal with and respond to risks in pre-planned ways is the best way to keep them
from seriously impacting on the project. There is always the possibility of extreme
unexpected events such as earthquakes, or death or insolvency but these will be
rare. Of course if your project involves such life critical products as to require even
these risks to be planned for, even more emphasis should be placed on planning
responses.
In the next topic we will look at both execution and monitor & controlling processes for
assuring and controlling quality on your project.
• Before progressing to the next topic encourage to look at the Readings Tab. Too
many processes have been covered here to be fully explained, so do please check
out all the readings and videos which will help better inform you about monitor &
controlling processes for Project Management.

Useful Links
VIDEO:
• https://www.youtube.com/watch?feature=player_embedded&v=IQK4QN-NqgM (40
years of great projects)
WEB:
• http://www.brighthubpm.com/monitoring-projects/124945-collection-of-guides-and-
tips-to-improve-the-project-monitoring-process/ Great overview of series of articles
aimed at helping better monitor and controlling of projects
• http://project-management-knowledge.com/definitions/v/variance-analysis/
Definition of Variance Analysis
• http://www.projectmanagement.com/articles/177431/The-Power-of-Variance-
Analysis Useful article on the power of variance analysis by George Spafford.
• http://en.wikipedia.org/wiki/Earned_value_management Overview of EVM
• http://www.brighthubpm.com/monitoring-projects/127582-earned-value-analysis-
forecasting-to-complete-performance-index/ Earned Value Analysis
• http://www.projectsmart.co.uk/earned-value-management-explained.html Earned
Value Management explained by Umesh Dwivedi.

Topic 4: Quality auditing, control and continuous
improvement
In the last three topics we have covered most of the executing and monitoring and controlling
processes, excluding quality assurance and control. This is because quality in a project is
such an important area that it requires a topic of its own.
There are only three processes for Quality Management in total and we covered the 1st –
Plan Quality – back in the Develop phase of the project’s life cycle, when Quality plans are
built.
The other 2 processes are from EXECUTE phase and are:
1. Perform Quality Assurance
2. Perform Quality Control
While there are only three processes for Quality Management in total, the importance of
getting quality standards right on a project is such that Quality Management has in its own
right spawned a number of standards and methodologies such as:
• Total Quality Management (TQM)
• ISO 9000 and 9001 (Quality Management)
• Six Sigma - follows a five stage improvement process (often called DMAIC) of
define, measure, analyse, improve and control. This process examines existing
processes. If you are looking to build a new process you may use DMADV (define,
measure, analyse, design and verify).
Execution process is: Perform Quality Assurance.
Involves tools such as auditing results to make sure appropriate standards and definitions
are are being used in the project execution. All about using the right processes and
executing for quality! See the process diagram for:
• Inputs = Project management plan, quality metrics, work performance information,
quality control measurements
• Tools & Techniques = Plan quality & perform quality control tools and techniques,
quality audits, process analysis
• Outputs = Organisational process asset updates, change requests, PMP updates,
project document updates
Monitor & control process is: Perform Quality Control. Recording results of quality
activities, checking quality of deliverables against plans. All about results and monitor and
controlling them! Process diagram displays:
• Inputs = Project management plan, quality metrics, quality checklists, work
performance measurements, approved change requests, deliverables,
organisational process assets
• Tools & Techniques = Cause & effect, control charts, flowcharts, histogram, Pareto
charts, run chart, scatter diagram, statistical sampling, inspection, approved change
requests.
• Outputs = quality control measurements, validated changes, validated deliverables,
Organisational process asset updates, change requests, PMP updates, project
document updates

The input of Quality Metrics used for both this process and performing Quality Assurance is
actually an output from having Planned Quality back in the Develop phase of the project.
Establishing Quality Metrics then helps you to assure and control quality during execution.
Seven tools of quality control are commonly listed for assisting in Quality Control and these
are:
• Cause-Effect Diagram, Pareto Chart , Check Sheet, Scatter Chart, Bar Chart and
other graphs, Histogram and the Control Chart.
We’ll look at an example of cause and effect diagrams – which were originally known as
“Ishikawa” or “Fish bone” diagrams, after the Japanese quality management expert who
invented them. Used to analyse the cause and effect behind a problem to identify what
caused it so you can address the problem effectively.
NOTE: that the quality control measurements output from performing quality control are used
as inputs for assisting in assuring quality control, so the measurements taken in controlling
can help inform improving processes to remove the fault, such as in the case of our cause
and effect diagram. Shows the circular nature of Project Management.
• Good example of continuous improvement is a story that illustrates the difference
between American and Japanese car manufacturers in the 1970s. The story goes
that when a car came off the production line in the US with only 3 wheels everyone
raced around looking for a 4th wheel, added it on and shipped the car out the door.
However if the same thing happened in a Japanese factory the entire production line
was immediately shut down until the cause of the fault was located, so that never
again should a car be produced with only 3 wheels. It may only be a story but it
perfectly explains the difference between simply fixing defects after production and
applying quality management so that the likelihood of the fault is either reduced or
removed.
• Before progressing to the next topic encourage to look at the Readings Tab. The
extensive guide to quality management with sample quality plan and inspection
report on the Project Perfect site is well worth reviewing.
• Try doing a forum posting on your own experiences of quality failings or quality
improvement processes.

Useful Links
VIDEO:
• http://www.isixsigma.com/new-to-six-sigma/getting-started/what-six-sigma/
(contains a video to explain Lean Six Sigma)
• http://www.youtube.com/watch?v=TDj0RBjYAdk Meeting quality targets to improve
project results
WEB:
• http://www.pmhut.com/quality-control-in-project-management Discussion on quality
control in Project Management
• http://www.isixsigma.com/new-to-six-sigma/getting-started/what-six-sigma/
explanation of what Six Sigma is
• https://fliphtml5.com/tags/juran%20trilogy Juran Trilogy by Brad
Lewis
• http://www.juran.com/ Home site for Juran Institute
• http://en.wikipedia.org/wiki/Total_quality_management Wikipedia explanation of
Total Quality Management and its relationship to Six Sigma.
• http://www.projectperfect.com.au/downloads/user-
guides/Quality%20Management%20User%20Guide.pdf Extensive guide to quality
management including sample quality plan and inspection report.
• http://evolt.org/The_Tao_of_Testing/ Discussion on importance of testing (IT
related)
• http://en.wikipedia.org/wiki/Ishikawa_diagram Overview of cause-and-effect
diagrams.
• http://thequalityweb.com/cause.html Guidance on creating cause and effect
diagrams
• http://www.projectmanagementdocs.com/project-controlling-templates/root-cause-
analysis.html Root cause analysis sample and template

Topic 5: Integration processes for the PM
The last four topics have covered all executing and monitoring and controlling processes
except for the three that are the primary responsibility of the Project Manager and therefore
belong to the Integration knowledge area.
These are:
1. Directing and Managing the Project Execution
2. Monitoring and Controlling Project work
3. Performing integrated change control
We will look at performing Integrated Change Control in Topic 6 so this topic will concentrate
on the first two.
Not surprisingly the Executing process is called Direct and manage project execution. It is
the Process for executing all the work contained in the Project Management Plan to achieve
the project’s outcomes. See the process diagram for:
• Inputs = Project management plan, approved change requests, enterprise
environmental factors, organisational process assets
• Tools & Techniques = Expert judgement, project management information system
• Outputs = Deliverables, Work performance information, change requests, Project
Management Plan updates, project document updates
Note the outputs – they truly reflect what the PM (and their team) work is in this process. First
– it is creating deliverables of the project... these aren’t necessarily only the product/service/or
result sub-deliverables. Documentation for projects such as the Charter, Project Management
Plan, Project Closure Report are all physical items that are produced as sub-deliverables of
running the project, so should also be considered as such. Next we have work performance
information, which are the various reports (and status updates) that the
PM will produce while tracking the execution of the project. There are also change requests
as during execution it is very likely the team and PM will uncover aspects that weren’t
correctly covered in planning and therefore require a request for change to be issued.
Obviously while the project is executing the PMP should also be updated to note how project
baselines are playing out, plus any changes to subsidiary plans and information. Other
project documentation requiring constant updating are items such as the risk register and
issue log. The PM may not be personally making all these changes, but they are responsible
for making sure they are performed.
With the T&T note PMIS. For an example of this, if an mpp file has been created in MS
Project to assist in managing the project, as mentioned earlier it can have all work activities
with their sequence, duration and resources entered and it will create a Gantt Chart to act as
a diagrammatic schedule baseline. When executing is started that schedule should be saved
as “a baseline”. From this point on the PM can then add what the actual progress of the
work is and add in any differences in durations that occur. MS Project can display a
“Tracking Gantt” which will show the original schedule with the actual durations alongside –
providing a useful illustration of where tasks are slipping and when projected durations have
gone longer or shorter than planned.
The Monitoring and controlling process for Integration Management is called: Monitoring
and controlling project work. This is all about tracking, measuring reviewing and regulating
the actual progress of the project against the project management plan baselines, using the
methods and processes that that have been planned. See the diagram for:

• Inputs = Project management plan, performance reports, enterprise environmental
factors, organisational process assets
• Tools & Techniques = Expert judgement
• Outputs = change requests, Project Management Plan updates, project document
updates
Again the outputs explain what the work required for this process is. As a result of comparing
what is actually happening with project execution against what was contained in the plan, the
PM may need to request changes. These may be changes to cope with variance analysis
results, assisting to bring project work back in alignment with the plan by taking corrective
actions, it may be a request for a preventative action because a risk is escalating in the
project and making a change will lessen or remove its potential negative impact. It may also
be a request for a defect repair, as in the performance reports and quality control activities a
fault or defect may have been uncovered in a deliverable that requires it to be replaced,
repaired or removed.
The PM Plan updates are going to be a possible requirement whenever you are requesting
changes, and as a result of attempts to control project activities. Lastly, document updates in
this process include the Status Reports (or Performance reports – as PMBoK calls them) to
be updated, the Issue log and forecasts may be requested to evaluate how current
deviations from the plan may alter the planned baselines. Earned Value Management we
discussed briefly under Cost control is a tool that may be used for these.
These two processes simplistically cover the day-to-day work of the PM when managing a
project, but don’t forget they also represent activities such as training and mentoring team
staff, dealing with issues and conflicts that may arise at any time, constantly trying to balance
the often conflicting constraints of scope, time, cost, quality, resources and risks, as well as
probable involvement in all 42 of the management processes we’ve discussed.
Next topic examines the last of the monitoring and controlling processes of the Execute
phase of the project – a process that actually runs throughout the entire project life,
Integrated Change Control.
• On the Readings Tab at least try and look at the Slideshare show on executing and
monitoring a project.

Useful Links
VIDEO:
• http://www.youtube.com/user/projectlessons Channel that contains lessons from
history of great projects.
• http://www.youtube.com/watch?v=aLJH3L_XulQ Overview of directing and manage
project execution
WEB:
• http://project-management-knowledge.com/definitions/d/direct-and-manage-project-
execution/ Definition of, and associated hyperlinked information.
• http://project-management-knowledge.com/definitions/m/monitor-and-control-
project-work/ Definition of, and associated hyperlinked information.
• http://www.slideshare.net/pajames36/managing-project-execution-presentation
Good Slide Share overview of executing and monitoring a project.
• http://www.projectsmart.co.uk/21-project-management-success-tips.html success
tips

Topic 6: Integrated change control
Change control has only one management process suggested for it, but you are likely if you
are the project manager to spend quite a lot of time using it. As the person responsible for
the successful execution of the project “Performing Integrated Change Control” you should
recognise it belongs to the Integration knowledge area, as any requested change is likely to
result in changes that may affect all other knowledge areas: scope, time, cost, quality, HR,
communications, risk and procurement.
It is a Monitoring and controlling process and may be required at any stage of the project’s
life, from concept to finish. All about reviewing, assessing, approving the inevitable changes
that a project requires and integrating them back into the project management plan and other
documents. Importantly, it is also about rejecting change requests that are not going to add
value, save time or money or in any measurable way greatly improve the project. Very
dangerous to see approving change requests as your only option.... just as important to block
ones that are not beneficial and will only delay or complicate the project.
• See diagram for Inputs = Project management plan, work performance information,
change requests, enterprise environmental factors, organisational process assets
• Tools & Techniques = Expert judgement, change control meetings
• Outputs = change requests status updates, PMP updates, project document
updates
As with many tasks the PM is responsible for it is a good thing to not be the only person
assessing and authorising change requests. We early mentioned that a way of planning for
change is to appoint a Change Control Board. As you would need authorisation from the
Project Sponsor to any major changes anyway, having an appointed ‘executive’ or board with
yourself, the sponsor and any other key decision makers should assist in making the right
decisions.
Don’t forget that when change requests are made they need to be properly assessed. For
instance changes should be evaluated for cost, time, risk, work considerations, product and
technical specifications. To make an informed decision on a large change the CCB will need
ot understand the impact of making the change as well as the impact of not making it. If one
out ways the other by a significant margin it will simplify the decision. The Change request
needs to act like a “business case” for the change, particularly if it is a significant one.
However, you don’t want your change management system to introduce barriers to
implementing necessary changes. Let’s say that while executing a series of tasks your team
member realises thy need a piece of software that only costs $250 to purchase. There is no
other product the company already has that will do the required job. It’s unfortunate that it
wasn’t identified as a resource when estimating them, but it wasn’t – these things happen.
However, we have to document the need and cost of purchase in the project documentation
– we can’t just have $250 vanish out of the budget without justification! Are you really going
to take this request to the CCB...? I don’t think so. The executive are all busy people and
they aren’t going to want to have to make this obvious a decision.
This is where in your Change Control System it should be flagged at which levels different
people have responsibility for assessing and approving changes. Depending on the size and
budget for the project the change management plan may denote $4000 as the barrier
between where a PM can authorise a change request and where the CCB needs to be
involved. As long as the project budget also contains some contingency reserve for
unexpected expenditure, it will be a simple process for the Team Member to fill in the
Request and the PM to sign off on it and release the funds for purchase. Of course that will
then mean some updated to project documentation – for a start the resource will need adding

to the plan. Remember, while this change request may have been initiated by a conversation
with your team member, to perform integrated chg control properly you do need to get her to
fill out a request – just make sure for smaller changes the form isn’t too onerous to fill in!
A good chg management system shouldn’t put people off making reasonable requests... you
can’t expect everything will have been thought of in planning, but it should put people off
making frivolous requests because it should require a rationale to why the change is being
requested. Making it clear to all stakeholders what the considerations are that will be used to
assess change requests will also help prevent people submitting requests that are not going
to be passed.
Next topic provides an overview of the last of the project’s life cycle phases: Finishing.
• Readings Tab at the ProjectSmart “Driving Successful Change” index which looks at
change management both from an organisational perspective and change
management within a project. Also highly recommend The Department of Health
and Human Services extensive guide to change management, written in easy to
understand.
Useful Links
VIDEO:
• http://www.youtube.com/watch?v=yljkbUNTB5g Overview by Simplilearn of Monitor
& Control Project Work
• http://www.youtube.com/watch?v=5_EwXi_SgfU Overview of Performing Integrated
Change Control.
WEB:
• http://www.projectsmart.co.uk/change-management.html an index page to a whole
range of related topics on change management
• http://manage.techwell.com/articles/original/how-say-no Saying no to change
requests.
• http://www.chacocanyon.com/essays/sayingno.shtml In-depth look at saying no for
Project Managers.
• http://www.projectsmart.co.uk/rescuing-projects-in-crisis.html Tips on how to
salvage a project in crisis.
• http://office.microsoft.com/en-us/project-help/how-to-evaluate-project-change-
requests-HA010172671.aspx Good overview of change management titled “How to
evaluate project change requests”.
• http://www.hhs.gov/ocio/eplc/EPLC%20Archive%20Documents/07%20-
%20Change%20Management%20Plan/eplc_change_management_practices_guide
.pdf Comprehensive guide and sample change management practices from The
Department of Health and Human Services.

Topic 7: The Finishing phase & getting handover right
While topics one to six in this Module have covered the Execute phase of a project’s life
cycle, the next two look at the wrap up of the project in the finishing phase of its life cycle.
This phase often seen as the least important of the four, being Concept > Develop > Execute
> Finish but is vital for capturing lessons learned to improve project management into the
future for an organisation.
• The Closure phase does only have two processes specified for it (remember the
Concept phase only had two also)? These two are:
1. Close procurements and
2. Close project or phase
• From this you may conclude there isn’t much to do, but a better appreciation of why
the Finishing phase of a project is important can be drawn from how often we have
referred to “Organizational Process Assets” and “Expert Judgement” across these
modules.
• Organisational process assets are listed as “inputs” for 34 of the 42 management
processes PMBoK recommends to manage a project. You should know by now that
Organisational Process Assets include the archives of “projects past” which provide
historical information anyone involved with a project can draw from to inform current
projects. Without a proper finishing phase these vital company assets would not be
available!
• “Expert judgement” which is listed as a key “Tool & Technique” for many of the
processes can also often be attained by researching documentation such as
“lessons learned” from past projects, or expert advice obtained for similar past
projects that has been documented, so the value to the organisation and any
projects that run after yours, of carrying out closing processes thoroughly, should
not be underestimated.
• Let’s start by looking at the Integration Management process of closing the project
or phase. See the process diagram for:
o Inputs = Project management plan, Accepted deliverables, Organisational
Process Asset
o Tools & Techniques = Expert judgement
o Outputs = Final product, service or result transition, Organisational Process
Asset updates
• Firstly note that this process states “project or phase”. Remember back in Module 1
where we discussed the 5 process groups used to manage the project across its
CDEF life? We noted then that if a project were particularly complex, it could be
advantageous to separate it into “sub-projects” or phases for ease of management. I
think the example we gave was that on a very unique or large project the work of
running a Feasibility Study and writing a Report could be turned into a phase. This
process is reflecting the fact that rather than being an entire project that is being
closed, it may be the end of a phase of the project, in which case the new phase
would begin with those 2 initiating processes of writing a Charter and Id’d
stakeholders.
• Also note that carrying out this process does not necessarily mean that the project
handover of its final product, service or result was carried out. If the project has
been beset by problems and has drifted off course, or if the environment that the
project was being carried out has changed so significantly that it can no longer meet

its initial business reason, then the sensible thing to do is for the Sponsor – and any
other key stakeholders that need to be consulted – agree to close the project down.
• The figures various surveys quote on wasted $ through projects that ultimately failed
are quite horrifying and so learning when it is best to terminate a project is an area
that project management, as a discipline, probably needs to learn how to better
evaluate. Interestingly many mining companies have built into their projects the
market conditions within which they will choose to continue or close a project.
Because much of their profitability is directly aligned to the current price of the ore
they are mining right at the start of project initialisation cost estimates will be
performed to determine the price range within which reconsideration of a project’s
viability needs reassessing. In mining they have become quite adept at closing
projects, without entirely cancelling them, maintaining all the work and project
documentation so that when the right prices again prevail the project’s viability can
again be assessed and a decision made to restart.
• However, given the assumption that the project has been run right through to the
end of the project management plan, obviously the outputs from this process should
be the final handover of the project’s product, service or result. The project manager
is responsible for checking that all this work has been completed and all 42
management processes have ended (except for closing procurements which is
probably occuring in //).
• The organisational process asset updates is signifying that all documentation that
has been created during the life of the project should be carefully archived in a
manner that allows future project managers to easily search for and access the
information contained. After all there is no value in archiving documentation if it is
going to be extremely difficult to ever access or reference again.
• In the next topic we will look in more detail at the closing documentation that the PM
should ensure is created in this final stage of the project’s life.
• The Procurement closing process called “Close Procurements” is the last process
that PMBOK list in their listing of project management processes for a project.
However it is designed to help support closing the project as it will assist in verifying
that all work and deliverables were accepted. See diagram for Closing
procurements:
o Inputs = Project management plan, Procurement documentation
o Tools & Techniques = Procurement audits, Negotiated settlements, Records
management system
o Outputs = Closed procurements, Organisational Process Asset updates
• As you can see from the tools & techniques and outputs a lot of the work for this
process is administrative. Every contract that has been used in procuring needs to
be checked for terms and conditions, where specific instructions may be given for
closing the contract, and checked to make sure that everything the contract was
supposed to deliver has been and that all outstanding payments have been made.
As contracts are legally binding documents it is very important to be meticulous in
closing them down according to proper procedures and meeting the contract terms,
or litigation may result.
• Sometimes you may find that an outstanding dispute is still unsettled at the time of
project closure. In this case using negotiated settlement tools such as dispute
resolution or mediation is highly recommended though of course, ultimately legal
action by one or the other party may result in forcing an outcome to be reached.

• Put simply, as long as your project scope was well defined in the Concept stage,
stakeholder requirements correctly identified and meaningful, measurable success
criteria and quality standards agreed to, finishing the project should run smoothly as
the deliverables are verified and accepted as meeting the customer requirements
and the needs of the project objectives.
• It is possible, depending on what was originally agreed on in the scope, that even
after formal handover of the project deliverables has been accomplished there may
be some sort of handover period defined where the SMEs from the project help
support the staff where the project outcome has been implemented until they have
confidence in being able to maintain and utilise the project goal for the purposes it
was defined. This is particularly common in situations where the project deliverable
was IT infrastructure or software.
• In the next topic we will have a better look at the types of procedures that can be
used to help ensure efficient closure of the project, outside of the ending of the
closing processes.
o Before progressing to the next topic encourage to look at the articles on the
Sydney Opera house. It is a very interesting project in that although at the
time the project was beset by problems, and could have benefited a lot from
better project management. While construction was supposed to take 4 years
it dragged on for 14! The architect resigned from the project under duress and
it was all generally judged to be a waste of time and money. And yet, in the
intervening years from its opening in 1973 this “failure of a project” has
ultimately been determined to be such an outstanding success in both its
innovative design and its fulfilment of functionality as the premier performing
arts centre for NSW that it was placed on the World Heritage List in 2007!
Useful Links
VIDEO:
• http://www.youtube.com/watch?v=I3Wt_bHZl7U Project management close out,
construction based.
• http://www.youtube.com/watch?v=cM1JphMzqKs Learn 7 steps to Avoid Closing
Pitfalls & Be Left Holding the Project Bag by Jennifer Whitt.
WEB:
• http://www.gids.nl/sydney/opera.html Example of how a project originally described
as a failure can end up being deemed a huge success.

Topic 8: Project closure and reflection
Worth noting that in some cases the success of a project in meeting its goals will not be able
to be evaluated until sometime after the project has been handed over. This is particularly
the case with handover of a new service. The Sydney Opera house is an interesting example
of where sufficient time between project end and the use of the deliverable has converted a
“failure” into an iconic success. However, I wouldn’t aim to wait this long to measure a
project’s success. Instead within 6 months of completion it should be possible to hold a post
project review that will seek to answer the longer term success of the project now it is in use.
In the meantime we will discuss why it is important that any project a company sponsors
includes the writing of a Project Closure Report with lessons learned documented to pass the
knowledge gained by the project team over into the assets of the company, so those who
never have run a successful project can learn from your experience. Even if the project is
terminated this process should be followed as obviously, the lessons learned in a failed
project may be even more pertinent for those following behind.
A Project Closure report needs to use the advantage of hind-sight to outline where the
project could have been better managed. It needs to highlight failures and successes and
document the lessons that have been learnt – as well as provide recommendations for any
future projects that may be run. In this way a company can build up a library of insight and
knowledge about what is a very complex area – project management.
A project closure report is not just useful for those who follow in your path though – it is also
a way of making time for you and your team to self-reflect on where your weaknesses and
strengths in project management lie. Self-reflection is a valuable tool for self-improvement.
Too often we are not given the time or opportunity to take advantage of this important
learning tool – but to employ best practise for Project Management you should have the
opportunity to do so by writing your Closure Report.
The purposes of a Project Closure Report are:
• To review the successes and failures of the project
• Assess how successful the project has been in meeting its outcomes
• Outline any hand-over procedures that are needed for the transition of a project to
becoming an on-going operation
• Provide details for any outstanding issues that need dealing with after the formal
closure of the project.
• To document important lessons that have been learnt throughout the project
• To make recommendations on how the project may have been better managed
• Highlight best practise
• Formalise the closure of the project (and get sign-off that it is closed)
The Project Closure Report should contain:
• The project title
• The author(s) of the report
• A Table of Contents
• Background overview of the project
• Reasons and methodology for closing the project
• Highlights and best practise

• Assessment of performance, compared against original objectives
• Lessons learnt
• Hand-over tasks for those that will be using/managing the project deliverable
• Post-closure issues for anyone taking on the managing of the project deliverable
• Recommendations for future projects
The other feature of a proper project finish that is not referred to in PMBoK is the team, if it
has been a success, should have some sort of formal “wrap-up” event. Just as a kick-off
event marks the start of project execution, having a celebration to formally recognise the
project end – and give everyone involved the opportunity to celebrate their part in the
project’s success – is an important aspect of finishing a project well... particularly if you want
to be able to assemble the same valued team members for another project in the future!
• Before progressing to the next topic encourage to look at the Readings Tab for the
article on the Microsoft website about “applying the finishing touches to project
closure”.
Useful Links
VIDEO:
• http://www.youtube.com/watch?v=I3Wt_bHZl7U Overview of Project Management
Closeout, construction based.
WEB:
• http://web.archive.org/web/20120403022605/http://www.nsf.gov/od/oci/CPMLL.pdf
Interesting “Lessons Learned” report from the results of a community cyber-
environment project that was intended to build a cyber- community of earthquake
engineering researchers.
• http://www.projectsmart.co.uk/lessons-learned.html Index page to articles about how
Lessons Learned benefit project management.
• http://office.microsoft.com/en-us/help/project-closure-applying-the-finishing-touches-
HA001127766.aspx Extensive and useful article on the benefits of closing a project
well. – Please note this article is no longer available (2nd June 2016). You may refer
to the following link for similar content: http://www.verillon.com/cased.html

Topic 9: Final recap of Project Management
In these four modules we have taken a journey that overviews most of the processes used in
modern Project Management to help projects to be run effectively and efficiently, with the aim
of delivering a project on time and within the agreed parameters that has a positive impact on
the environment it is employed in.
We started by looking at what a project is defined as (remember: unique, specific S & e,
temporary, limited resources, involve uncertainty and implements change and creates a
product / service or result).
While we can identify “projects” from the beginning of history, modern Project Management
processes have really only been used since about the 1950’s. In the last half century a
number of methodologies or standards have been established and are gaining in popularity
and usage around the world rapidly. We discussed a few of these but this Subject has been
based mainly on the processes recommended by the Project Management Institute’s Edition
4 guide, called the Project Management Body of Knowledge. PMBoK was first published in
the early 1980s and has been used as a standard in America (American National Standards
Institute) as well as the Institute of Electrical and Electronics Engineers (IEEE). In just
September of last year there was a new ISO standard released for Project Management that
has a very close synergy with PMBoK so the processes we have discussed are in wide use
all around the world.
However, for effective project management what is really important is to have a methodology
established within your organisation and then follow it! One of the reasons modern project
management is growing in popularity is that the evidence shows the better educated staff are
and more mature project management processes are within an organisation, the greater the
number of successful projects will be produced. This is also why even if the only learning you
do about project management is completing this SUBJECT you will have benefited yourself
and your company if you work in projects.
We discussed how a project can be thought of as having a ‘life-cycle’ which we defined as
“Concept > Develop > Execute > Finish”. Thinking of a project in this way helps us to think
about what processes should be run at what stage of the project and how management
techniques will need to alter across the project’s life dependant on what stage it is at.
Using PMBoK as a guide we looked at how there are many differing areas of knowledge that
a Project Manager will need to become informed about to be able to effectively manage the
multitude of areas that need careful consideration when managing a project.
We explored the four so called ‘core’ areas of knowledge which are Scope, Time, Cost and
Quality management. As scope represents the actual specifics of the product, service or
result the project is to produce, both in terms of what the project deliverable’s specifications
are and what work will be needed to produce it, scope is a good starting point for planning in
a project. However anyone that has been involved in a project will quickly find that these
areas do not operate in isolation. While obviously the scope is the core of why the project is
being run the other core areas have to be taken into consideration at the same time. The
budget allowed for a project and the time and quality standards that need to be met all have
to be considered when working out the scope or the natural tendency would be to aim too
high for the money and time allowed.
While it is easy to appreciate why scope, time, cost and quality are all areas the project will
need carefully managed, the four facilitating knowledge areas are also critical to the project’s
success. As we discussed they were Human Resources, Communication, Risk and
Procurement. When you think about it, how could a project be run if proper care and
attention were not paid to the team that will run it, how effective communication between all

the parties with vested interest in the project should be managed and how any external
purchasing for the project should be handled.
Risk is a knowledge area that is particularly important because of the very nature of a
project. Projects are unique and involve uncertainty. If they weren’t they would be just part of
the day to day operations of a company. Because projects contain uncertainty they also face
more risks than ordinary operations, and because the project needs to run to a predefined
schedule and budget unexpected events can’t afford to be unplanned for. Planning for risk
helps the project team deal with risks when they occur and plan how to respond.
Of course there is one more knowledge area that we discussed which was the prime
knowledge area for the Project Manager. While team members may need in depth
knowledge of a number of the previous areas the Integration knowledge area is where the
project manager draws together the threads of scope, cost, time, quality, HR,
communication, risk and procurement to build the key documents for managing the project:
the project charter and the project management plan.
We then went on to look at the five process groups that PMBoK recommends be used to
manage the project. While the knowledge areas highlight what fields you need to be informed
about to manage projects, the five process groups contain all the processes used to manage
these knowledge areas. They are:
• Initiating
• Planning
• Executing
• Monitoring and controlling
• Closing
You may mistake these five groups for the project’s life cycle but where the CDEF life cycle
is the phases the project goes through from its start date to its end date, these five groups of
processes may be run across the life cycle or across the different phases or sub-projects the
main project goal has been broken up into. However, in general the initiating processes will
run during the concept phase of the project, the planning processes will be needed to
manage the development phase, both executing and monitoring and controlling processes
will be used while the project is in its execute phase and the closing processes will be used
to manage the finish of the project’s life.
The other difference between the project’s life cycle and the five process groups is while the
project is never going to go from its execution phase back to its concept phase, the five
management process groups can be iterative – and in fact often need to be – as because
projects involve uncertainty the team is bound to uncover new areas of work required or
changes to resources, time frames and costs as the project evolves through its execution.
This means that while executing the work of the project, the manager may need to return to
planning processes which will then involve more executing and monitoring and controlling
processes to be carried out. Sometimes the manger may even need to reemploy some of the
initiating processes such as identifying new stakeholders and making a retrospective –
though authorised change - to the project charter.
Another area important to effective management of projects that we have covered are
constraints. We discussed how traditionally four constraints have been identified that apply to
all projects and how PMBoK Ed4 now identifies six. The four main ones were:
• Scope
• Cost / Budget
• Time / Duration

• Quality
These four have traditionally been identified because it is easy to see how they impact on
each other. The more complex the scope, the more money and time will be needed and the
more important the quality standards will be. The less time there is available to a project then
the more likely you will need to restrict the scope to the bare essentials, but more money
may be required to outsource some work, or employ more staff to speed up its execution. If
there are very tight time frames to be met the quality requirements need to be made very
specific as frequently less time means lower quality. Depending on the project goal this may
be acceptable. However if the project involves safety to individuals, or a function that will be
critical to the businesses survival then attaining sufficient quality standards may involve more
time and cost allowances to ensure this. Because these factors are so dependent on each
other they can be used as a way of explaining to a project sponsor or client how a requested
change is likely to affect more than one aspect of the project. A constant danger to running
projects successfully is having a client wanting to constantly add to the project’s scope.
Using the common constraints to explain how a change to scope has an impact on the other
areas will help them to understand why the change should not be made – or of it is agreed to
– why it will require more time and money to authorised for it to be included.
The Edition 4 version of PMBoK lists:

• Scope
• Quality
• Schedule
• Budget
• Resources and Risk
…as project constraints that need balancing, and we discussed why these additional factors
are also worthy of careful consideration and managing.
In the section on the concept phase of a projects life cycle we looked at how important it was
to carefully assess the business case and feasibility of a project before it is started. There
have been countless billions wasted world-wide on projects that have either been closed
down or which have delivered results that were no longer deemed useful to the organisation
they were implemented in. while there are many definitions of success and failure in a project
these two are I think the main reasons a project should be deemed a failure. Running a
project that rambles endlessly on to the point a realisation is made that it never is going to
end so it has to be closed down is a definite failure. In my opinion just as definite a failure is
running a project that delivers the agreed scope on time and within budget but that the end
result of is a product, service or result that is not used or is in fact a detriment to the
organisation it was implemented for. While balancing scope, quality, schedule, budget,
resources and risk to deliver the agreed goal on time and within budget are all ways success
of a project can be measured ultimately the main gauge will be the satisfaction of the end
user of the delivered goal. It is surprising how many projects that have failed on these
specific measures have in the long term been considered great successes – the Sydney
Opera house is a perfect Australian example!
In the concept phase once the goal had been clearly identified and evaluated by upper
management and resources authorised for the project to be progressed we discussed how
the first of the PMBoK management processes should be employed, which was to develop a
Project Charter. We looked at regardless of whether appointed Project Manager or the
Project Sponsor wrote this document what was really important was:
• It outlined as clearly as possible the project objectives and deliverables

• It identified how the success of the project would be measured
• It enables a clear delegation of authority for the Project Manager to begin expending
money and resources to plan the project
• It signifies the support of the sponsor / client / project manager for the project to be
transitioned to the development phase of its life cycle.
The more accurately and specifically the Project Charter has been drafted and agreed to, the
more smoothly all further work on the project will progress and the more likely a successful
handover at the end of the project will be. It provides a key framework for all stakeholders to
refer back to throughout - and as long as at the project handover that framework is met –
there should be agreement all around.
In the development phase we talked about the planning processes required – there were 20
in all – to plan out the scope, time, cost, quality, human resources, communication, risk and
procurement of the project. We talked about how the planning needs involvement from the
team to be comprehensive and accurate enough. We looked at how each of these processes
used inputs, tools and techniques to provide outputs that were then integrated by the project
manager in to the “go-to” document for executing the project, which is the Project
Management Plan. This document is best thought of as an over-arching document that
provides an interface to all the relevant plans for managing the project through its execution.
It is also a dynamic document that should constantly be updated as the project progresses
with the latest information so that any stakeholder at any stage can gather a clear idea of the
project’s progress from reviewing it. It also provides the framework for how all the knowledge
areas should be executed and managed, including monitoring and controlling plus how to
make change requests and integrate them if agreed.
We looked at why it is important to plan for change in a project. References to “iterative
processes” and “rolling wave method” were made to help clarify that as a project goes
through its planning and execution life cycle phases naturally a better understanding of the
details of the project will be achieved which means that it is extremely likely the team will
uncover areas that were missed from the initial plans. The most important thing about
change in a project is not that it happens – it will – it is that there is a formal process set up to
manage change. By making sure that requests for change are formally made so that they
can be properly assessed as to whether there is value in integrating them and an accurate
appreciation of the flow on effects from integrating them, sensible decisions can be made on
what changes should be agreed to and which should not. Without careful management of
change – which is one of the key responsibilities of the Project Manager in the Integration
knowledge area – projects can be needlessly and continuously changed which ultimately will
almost ensure you go over budget and time and potentially deliver a very different deliverable
to the one originally defined in the Charter. Not only can this cost money time and waste
resources it is bound to frustrate and confuse everyone involved with the project, so good
change control management is yet another key area the project manager needs to be well
skilled in.
For the execution of the project to occur smoothly once the project management plan has
been set up and authorised, there are a total of 18 processes from the monitoring &
controlling and executing process groups that can be used. If the Plan has been well
developed and is used as a benchmark for measuring against throughout, the Execute phase
should simply follow the Plan, with only necessary changes integrated into it.
Finally smooth the transition to operation of the project in the Finish phase by properly
applying the closing project and procurements processes and supporting handover of
deliverables. Developing a Closure Report to allow for reflection and documentation of
lessons learned and archiving all project documentation will add to the knowledge bank of

the organisation (and its organisational process assets) and will benefit all future projects to
be run.
To manage projects well there needs to be a commitment by the performing organisation to
allow time and resources to be allocated to concept and develop phases of the project’s life,
as the better this is done the better execution will run and the higher the likelihood of
successful handover.
• While this has been a brief overview of project management investigating all the
videos and web links to readings in the resource tabs for each Topic will allow
further expansion of your understanding of Project Management.
Useful Links
VIDEO:
• https://www.youtube.com/watch?feature=player_embedded&v=r5qFLd1u0XQ (An
Idiots Guide to Project Management) The basics.
• http://www.youtube.com/watch?v=GcR-wpSzr4Y A simple 5 step process example
of how to manage a project: why, what, how, who, tracking.
• http://www.youtube.com/watch?v=9LSnINglkQA Simple, cartoon overview of Project
Management.
• http://www.youtube.com/user/projectlessons Channel that contains lessons from
history of great projects.
WEB:
• http://www.brighthubpm.com/project-planning/65203-the-project-life-
cycle/?cid=parsely_rec Overview of the entire project life cycle.
• Max's Project Management Wisdom - Max Wideman was the author of the first
PMBOK guide and has dedicated a lot of his time and effort to creating a wealth of
information about Project Management, accessible for free from this site.
• Australian Institute of Project Management (AIPM) - the Australian organisation
representing Project Management professionals in Australia, formed in 1976.
• Projects at Work - American resource for Project Managers, founded 2001 and "The
online destination for leading-edge approaches and perspectives in program,
portfolio, and project management. (their description)".
• Project Smart - British resource, free site launched 2000, with many Project
Management resources.
• http://en.wikipedia.org/wiki/List_of_project_management_topics
• http://www.maxwideman.com/pm_101/intro.htm is an easy to read overview by Max
Wideman about projects and project management.
• http://www.maxwideman.com/papers/framework/intro.htm is a more sophisticated
explanation of project management by Mr Wideman.
• http://www.businessballs.com/project.htm Short overview of a whole lot of project
techniques and tools.

Topic 10: Where to from here...
We’re hopeful by now you will feel that you have learnt a whole heap about how to manage
projects! However, as we said right back at the start, this is only an overview! It should have
given you a pretty good idea of how much work needs to go into managing projects in a
structured and formal way and highlighted some of the traps that projects fall into when these
processes are not properly employed. It should also have provided you with enough of a
‘taster’ to assess whether project management is a discipline you wish to be employed in.
Remember, most of the most interesting work in the world revolves around running projects!
However if you are serious about gaining a thorough understanding of project management
please don’t think this MOOC has provided it.
Educationally you have a number of options.
• Use as pathway to a Cert IV in PM. Under the Australian Qualifications Framework
the cert 4 covers 8 units: Scope, Time, Cost, Quality, Human Resources,
Communications, Risk and Procurement.
• Use as pathway to the Diploma of PM, which comprises 9 units: Scope, Time, Cost,
Quality, Human Resources, Communications, Risk, Procurement and Integration.
• They may seem pretty familiar after this MOOC – these qualifications basically cover
project management using the PMBoK knowledge areas.
• The Cert IV doesn’t include integration management because it is intended for those
students who work – or wish to work – in projects but are not aiming to be project
managers. The Diploma is intended for those wanting to pursue a career so PM and
so obviously needs to cover Integration management. Being at different qualification
levels obviously the standard of work required for the Diploma is at a higher level
than the Cert IV, so even those wishing to pursue PM as a career may prefer to start
at the Cert IV level as a slightly ‘softer’ lead in. Be aware that if you are applying for
either of these qualifications you should have access to a workplace – and
preferably one that runs projects. As a Diploma would normally allow you to claim
exemptions in related Bachelor degrees the standard of work required is at a higher
education level. In other words you would be expected to have good literacy and
communication skills and know how to research and reference appropriately. Mind
you these skills are also necessary for being a Project Manager!
• Depending on your current level of formal education you may choose to progress
from this MOOC straight to a university course such as a Bachelor of Business that
will also cover many aspects of managing projects at a greater depth, or a Bachelor
of Project Management. Degrees in Project Management are relatively new but
more are being made available through Universities. These obviously provide a
higher education qualification than a Certificate IV or Diploma.
• You can also pursue one of the many popular industry based courses. For instance
the PMI – authors of PMBOK – provide links to accredited courses in Project
Management and run a range of project management certification exams. One of
the most popular certifications is the Project Management Professional - or PMP.
Prince2 also has a qualification framework that enables successful students to claim
Prince2 Practitioner status, amongst others.
• If wishing to seek employment in Project Management most team members are first
and foremost specialists in a technical area in an organisation that runs projects, so
to be a project team member have good skills in your discipline of choice and look
out for employment opportunities within organisations that run projects. Let them
know you are interested in being involved in Project work. Tell them you have done

a MOOC which gave you a background of what modern project management is.
Obviously obtaining a qualification such as the Certificate IV would be a desirable
entry on your resume!
• If you want to be a Project Manager then you really need to enrol in more specific
training such as the Diploma or above. Having a qualification by itself won’t ensure
you are employed as a Project Manager. Really it should be a ‘value add’ to a
technical proficiency such as IT, Business, Engineering, Construction etc. As most
projects involve a fair amount of money and resources to be allocated you can
understand why most organisations would be reluctant to hire a “green” Project
Manager, even with a Bachelor Degree. Your best method for pursuing this career is
working in project environments as a team member, promoting yourself as a
potential project manager by communicating with the people that count and backing
it up by enrolling in and studying formal project management. Looking for a Project
Manager mentor within an organisation can be really useful – and then look for your
opportunities and argue to be given a chance. If you can demonstrate to a company
that you possess the necessary skills to be a Project Manager, have the
qualifications to back this up, and be persistent chances are you will get your
chance! There are more and more companies looking for more and more Project
Managers and for all the emphasis put on having experience first, we all know that
only happens by being given the first chance!
• Thanks for spending your time with me on this Subject and good luck with whatever
pathway you choose to follow!
• As always, do have a look at the Readings for some further information you can
explore on possible pathways to further education in Project Management.

Useful Links
VIDEO:
• http://www.youtube.com/watch?v=pXdKUY9d-4A YouTube video about what PMP
certification is about
• http://www.youtube.com/watch?v=YK8JJu9Ejvg More in depth YouTube video about
PMP certification and how to study for it
• http://www.youtube.com/watch?v=e5-TriVtzlI Video about obtaining Prince2
certification
• http://www.youtube.com/user/PMstudyLessons?feature=watch Series of videos
about benefits of Prince2 Practitioner certification
WEB:
• https://www.open.edu.au/courses/business/university-of-south-australia-
graduate-certificate-in-project-management--usa-pjm-gce-2016 Specific
information on the Graduate Diploma of Project Management
• http://www.pmi.org/Certification.aspx Page explaining PMI’s Certification options.
• http://www.prince-officialsite.com/Qualifications/QualificationScheme.aspx Page
explaining the official Prince2 Qualification scheme.

Project Management Module 4 Script

Uploaded by

Copyright:

Available Formats

Project Management Module 4 Script

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Project Management Module 4 Script

Uploaded by

Copyright:

Available Formats

Project Management Principles: Execute &

Finish Phases - Module 4

Topic 1: The Execute – or doing – phase overview

Project Management Principles: Execute & Finish Phases - Module 4 Page 1 of 35

Project Management Principles: Execute & Finish Phases - Module 4 Page 2 of 35

Project Management Principles: Execute & Finish Phases - Module 4 Page 3 of 35

Project Management Principles: Execute & Finish Phases - Module 4 Page 4 of 35

Project Management Principles: Execute & Finish Phases - Module 4 Page 5 of 35

Project Management Principles: Execute & Finish Phases - Module 4 Page 6 of 35

Project Management Principles: Execute & Finish Phases - Module 4 Page 7 of 35

Project Management Principles: Execute & Finish Phases - Module 4 Page 8 of 35

Project Management Principles: Execute & Finish Phases - Module 4 Page 9 of 35

Project Management Principles: Execute & Finish Phases - Module 4 Page 10 of 35

Project Management Principles: Execute & Finish Phases - Module 4 Page 11 of 35

Project Management Principles: Execute & Finish Phases - Module 4 Page 12 of 35

Project Management Principles: Execute & Finish Phases - Module 4 Page 13 of 35

Project Management Principles: Execute & Finish Phases - Module 4 Page 14 of 35

Project Management Principles: Execute & Finish Phases - Module 4 Page 15 of 35

Project Management Principles: Execute & Finish Phases - Module 4 Page 16 of 35

Project Management Principles: Execute & Finish Phases - Module 4 Page 17 of 35

Project Management Principles: Execute & Finish Phases - Module 4 Page 18 of 35

Project Management Principles: Execute & Finish Phases - Module 4 Page 19 of 35

Project Management Principles: Execute & Finish Phases - Module 4 Page 20 of 35

Project Management Principles: Execute & Finish Phases - Module 4 Page 21 of 35

Project Management Principles: Execute & Finish Phases - Module 4 Page 22 of 35

Project Management Principles: Execute & Finish Phases - Module 4 Page 23 of 35

Project Management Principles: Execute & Finish Phases - Module 4 Page 24 of 35

Project Management Principles: Execute & Finish Phases - Module 4 Page 25 of 35

Project Management Principles: Execute & Finish Phases - Module 4 Page 26 of 35

Project Management Principles: Execute & Finish Phases - Module 4 Page 27 of 35

Project Management Principles: Execute & Finish Phases - Module 4 Page 28 of 35

The Edition 4 version of PMBoK lists:

Project Management Principles: Execute & Finish Phases - Module 4 Page 29 of 35

Project Management Principles: Execute & Finish Phases - Module 4 Page 30 of 35

Project Management Principles: Execute & Finish Phases - Module 4 Page 31 of 35

Project Management Principles: Execute & Finish Phases - Module 4 Page 32 of 35

Project Management Principles: Execute & Finish Phases - Module 4 Page 33 of 35

Project Management Principles: Execute & Finish Phases - Module 4 Page 34 of 35

You might also like