dpm 2203: project operations and management (3 cu) · dpm 2203: project operations and management...
TRANSCRIPT
1
DPM 2203: Project Operations and Management (3 CU)
Course Instructor: Mr. Watuleke Joseph
Department of Adult and Community Education Room 1:
Email: [email protected] or [email protected]
Course description:
This course introduces learners to the operational/executional phase when the project activities
are carried out, and the project is yielding a flow of benefits. It equips learners with appropriate
tools and techniques of managing the process of project execution, termination, follow-up and
innovation.
Course objectives
This course aims at:
Introducing learners to the basic principles of project operations and management
Equipping learners with basic management tools for effective project operations
Enabling learners to apply the tools, skills and theories learnt for successful completion of
and sustainability of a project.
Course content
1. Overview of the Execution/operation stage of the project life cycle
2. Appoint the team and kick off the project
3. The project manager role
4. H/R and Communications management
5. Monitoring and controlling execution
6. Quality auditing and continuous improvement
7. Integration processes for the Project Manager
8. Integrated change control
9. Finishing phase & getting handover right
10. Project Closure and reflection
2
11. Follow-up action and innovation
Expected outcomes
By the end of this course, learners will be expected to:
Develop a clear understanding of the principles of project operations and management
To use the different managerial tools and technics in carrying out the activities of the projects
as planned.
Steer the project on course for successful completion, follow-up action, and innovation.
Methods of course delivery
Lecturettes
Brainstorming
Online platform discussions
Presentations (group/individual)
Films/video clips
Mode of assessment:
Take home assignments, tests, and hands on exercises 20%
Participation and group discussions 10%
Final examination 70%
Reading list
Cusworth, J. W. & Franks, T. R. (1993). Managing projects in Developing countries, London,
Longman
Lock, D. (2007a). Project management, 3rd edition, Aldershot, Gower publishing company
Lock, D. (2007b). The Essentials of Project Management, New York, John Wiley & Sons
Pearce, J. A. & Robinson, R. B. Jr. (2001). Strategic Management: Strategy Formulation and
Implementation, 3rd edition, Delhi, AITBS Publishers and Distributors.
3
Boddy, D. (2011). Management: An Introduction, Fifth edition, Prentice Hall.
Pearce, J. A. & Robinson, R. B. Jr. (2001). Strategic Management: Strategy formulation and
Implementation, 3rd edition, Delhi: AITBS publishers and Distributers.
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.
• 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.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.
• http://www.epmbook.com/team.htm In depth look at building teams for projects
4
• 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
5
Topic 1: The Execute - or doing - phase overview
In this course, we are going to discuss:
The meaning of project operations management
The Executing life-cycle phase of a project in more detail, including:
A pointing a team and getting started
The project manager's role
Executing processes for H/R and effective Communication
Processes for monitoring and controlling progress on your project
Assuring and controlling quality as well as seeking to continuously improve processes
and procedures
Integration processes the PM is responsible for, directing execution and monitoring and
controlling the work.
How to integrate changes into the project during execution with the minimum of fuss
We'll also discuss the Finishing phase of the project, including:
The two closeout processes of closing procurements and closing the project or phase.
How to manage handover of the project goal
Why the team should always reflect on the running of the project at the end
The importance of archiving project documentation for future projects
We will wind up by looking at the project evaluation, follow-up and innovation.
Meaning of operations management
Operations Management is the planning and execution of operations (routine work) in the service
and manufacturing worlds, including demand forecasting, production planning, inventory
control, quality management, and supply chain collaboration. Project Management is the
6
planning and execution of projects (non-routine work) in the service and business worlds,
including project initiating, project planning, project executing, project monitoring and
controlling, and project closing.
Efficient management of operations and projects is of utmost importance for both the success
and survival of a firm.
The Project life cycle
The project goes through four main stages that represent the project life cycle. They are
summarized in the acronym C-D-E-F, being the Concept, Development, Execution and Finishing
phases. During the Develop phase of the project life cycle, all the work for planning all
foreseeable details of your project is performed. In this course module, we’ll cover the
Execution/operations and Finish phases!
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! Always 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 course module, 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 another topic 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
7
typically utilized during the Execute phase of the project's life. PMBoK stands for Project
Management Body of Knowledge and is a recognized standard.
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 realize there are changes they would like. Having
their - and end users - involved throughout concept and planning is the best way to minimize
8
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. Just as we are 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 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!
Before progressing to the next topic, I encourage you 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.
9
• 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
In this topic we will look at the 5 executing processes for the H/R and communications
knowledge area.
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.
It should be obvious that, 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!
10
See the accompanying illustration for the inputs, tools & techniques and outputs of acquiring the
project team.
Acquiring the project team consists of:
Inputs: project management plan, enterprise environmental factors and organisational process
assets.
Tools & Techniques recommended are: Pre-assignment, Negotiation, Acquisition and Virtual
teams
Outputs are: Project staff assignments, resource calendars, project management plan updates
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.
However while it makes sense to acquire members with specialist skills after working out which
skills are needed, this doesn't fit with the recommendations that require 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!
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.
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
11
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.
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.
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.
Next let's look at "Developing the Project Team".
Developing the Project Team consists of:
Inputs: project staff assignments, project management plan, resource calendars.
Tools & Techniques recommended are: Interpersonal skills, Training, Team-building
activities, Ground rules, Co-location and Recognition and rewards.
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.
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.
12
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.
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.
The next execution process for Human Resources is to manage the project team. See the
accompanying image for inputs, t & t and outputs.
Inputs: project staff assignments, project management plan, Team performance assessments,
Performance reports and organisational process assets.
Tools & Techniques recommended are: Interpersonal skills, observation & conversation, project
performance appraisals, conflict management and an issue log.
13
Outputs are: Change requests, organisational process assets updates, project management plan
updates and enterprise environmental factor updates.
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.
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.
The communication management processes are:
1. Distributing information and
2. Managing stakeholder expectations (which include the project team members as well as other
external and internal stakeholders).
14
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.
See the accompanying image for a list of the inputs, T&T and outputs for distributing
information.
Inputs: Project management plan, Performance reports and Organisational process assets.
Tools & Techniques recommended are : Communication methods, Information distribution
tools
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.
15
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
16
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.
17
Scope management requires monitoring and controlling to:
1. Verify scope
2. Control scope
The Verification of scope process requires:
• 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.
18
The scope control process requires:
• 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)
Inputs: Project Management Plan, Project Schedule, Work performance info, Organisational
process assets
Tools & techniques: Performance reviews, Variance Analysis, Project management sware,
resource levelling, what-if scenario analysis, adjusting leads and lags, schedule compression and
scheduling tool.
Outputs: Work performance measurements, Organisational process asset updates, Change
requests, Project management plan updates, Project document updates
19
• 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 parallel. 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):
Inputs: Project Management Plan, Project funding requirements, Work performance info,
Organisational process assets
Tools & techniques: Earned value management, forecasting, to complete performance index,
Performance reviews, Variance Analysis, Project management Score.
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: Report performance
• The report performance process requires (as illustrated)
20
Inputs: Project Management Plan, Work performance info, Work performance measurements,
Budget forecasts, Organisational process assets
Tools & techniques: Variance Analysis, forecasting methods, communicating methods,
Reporting systems
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)
Inputs: risk register, Project Management Plan, Work performance info, performance reports
Tools & techniques: risk assessment, risk audits, Variance & trend Analysis, technical
performance measurements, status meetings.
Outputs: Risk register updates, Organisational process asset updates, Change requests, Project
management plan updates, Project document updates
21
• 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
22
• 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 the 1st process known as -
Plan Quality, is done during 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)
23
• 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).
1. Planning process is: Plan Quality
This process is conducted during the develop phase and it includes:
• Inputs: Scope baseline, Stakeholder register, Cost performance baseline, Schedule baseline,
Risk register, Enterprise environmental factors, Organisational process assets
• Tools and techniques: Cost-benefit analysis, Cost of quality, Control charts, Benchmarking,
Design of experiments, Statistical sampling, Flowcharting, Proprietary quality management
methodologies, Additional quality planning tools
• Outputs are: Quality management plan, Quality metrics, Quality checklists, Process
improvement plan, Project document updates
2. Execution process is: Perform Quality Assurance.
Involves tools such as auditing results to make sure appropriate standards and definitions are
being used in the project execution. It is all about using the right processes and executing for
quality! See the process 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
3. Monitor & control process is: Perform Quality Control.
24
Performing quality control involves recording results of quality activities, and checking quality
of deliverables against plans. It is all about results, monitoring and controlling them! Process the
process includes:
• 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.
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 a cause and effect
diagram. It 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.
25
• 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=mVsxxoGHHWM Video on Project Management Quality
Management
• 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
• http://ebookbrowse.com/juran-trilogy-paper-pdf-d18594600 Juran Trilogy by Brad Lewis
• http://www.juran.com/our-company/ Home site for Juran Institute
26
• 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://www.evolt.org/article/The_Tao_of_Testing/20/4142/index.html 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.
27
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. Process includes:
• 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
28
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 process requirements below:
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,
29
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.
The 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:
• https://www.youtube.com/watch?feature=player_embedded&v=IQK4QN-NqgM (40 years of
great projects)
• 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://projectmanagementsolutionsltd.com/main/?p=1141 Overview of directing and manage
project execution.
• http://www.slideshare.net/pajames36/managing-project-execution-presentation Good Slide
Share overview of executing and monitoring a project.
30
• 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 the process requirements below:
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 (CCB). 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.
31
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 to 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.
32
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".
33
• 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 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.
34
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 change 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 change 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
35
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".
36
• 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
is often seen as the least important of the four, being Concept > Develop > Execute > Finish but
it is vital for capturing lessons learned to improve project management into the future for an
organization.
The Closure phase does only have two processes specified for it. These two are: 1. Close
procurements and 2. Close project or phase
From this you may conclude that 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
organization 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 .
The process includes:
37
Inputs = Project management plan, Accepted deliverables, Organisational Process Asset
Tools & Techniques = Expert judgement
Outputs = Final product, service or result transition, Organisational Process Asset updates
Firstly note that this process states "project or phase". Earlier on, while discussing the 5 process
groups used to manage the project across its CDEF life, we noted that if a project was
particularly complex, it could be advantageous to separate it into "sub-projects" or phases for
ease of management. 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 identifying 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 initialization 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 skillful 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
38
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 occurring in parallel).
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 the process.
See for closing procurements:
Inputs = Project management plan, Procurement documentation
Tools & Techniques = Procurement audits, Negotiated settlements, Records management
system
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
39
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 utilize 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.
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.
40
• 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
41
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 practice 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 practice
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 practice
Assessment of performance, compared against original objectives
• Lessons learnt
• Hand-over tasks for those that will be using/managing the project deliverable
42
• 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:
• https://www.youtube.com/watch?feature=player_embedded&v=IQK4QN-NqgM (40 years of
great projects)
• http://www.youtube.com/watch?v=I3Wt_bHZl7U Overview of Project Management Closeout,
construction based.
WEB:
• 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.
43
Topic 9: Final recap of Project Management
In this module, we have taken a journey that overviews most of the processes used in modern
Project Execution 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.
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 2012, 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 dependent on what stage it is at.
44
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 a project could 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
45
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
46
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
47
• 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
48
• 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
49
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
50
VIDEO:
• https://www.youtube.com/watch?feature=player_embedded&v=IQK4QN-NqgM (40 years of
great projects)
• https://www.youtube.com/watch?v=4n0kVSxV8-8 (What is Project Management in simple
outline)
• 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
51
• 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: The Project Manager Role
In this topic, we are going to discuss Project Managers: what the job role entails.
What is the role of a Project Manager?
Project Managers are sort after people. Job demand for effective project managers has grown
enormously over the last few decades. Project Managers that are experienced and have
successfully led projects in the past are rewarded with some of the highest salary packages in
industry, below upper management. There is an article in your readings that outlines average
Project Manager Salary's across 2011.
First, what is the PM not- they are NOT the project owner… that is the person or organization
sponsoring (paying for) the project.
The PM is the person responsible for carrying out the day-to-day management of the project.
He/she is appointed by the owner of the project, be that the organization running the project or a
specific Project Sponsor.
They will need an overall appreciation of everything that is involved in the project because they
are the key contact between the project team and the project sponsor and/or upper management.
They are the "go-to" person for information about the project requirements, progress and
performance.
52
PMBoK says the project manager should have three characteristics:
KNOWLEDGE of PM via the Nine knowledge areas
PERFORMANCE (performance of applying knowledge) via the 42 management processes
PERSONAL characteristics that make them effective at leading the team and balancing the
constraints so the project objective is met.
Ultimately they have responsibility for managing the project team so that the agreed project
objective is reached on time, within budget, to the agreed quality requirements. However, they
may operate in an environment where between their and the project sponsor role is a portfolio
manager. If this is the case the Portfolio Manager - who usually governs a number of projects -
would be responsible for any decision on continuing or ceasing the project based on the strategic
priorities of the organization it is running in and in consultation with the Sponsor and possibly an
official project review panel.
Need to have multiple skills including: in depth knowledge of project management, good
communication and personnel skills and an ability to perform efficiently and effectively under
constraints such as time and budget. Also usually need a sound technical knowledge of the
technical discipline the project is being run in. Some argue what is most important is having
good project management skills, that technical knowledge isn't necessary. However, there is no
denying that having in-depth technical knowledge of the project greatly assists a PM in their
understanding of project requirements and constraints, in their ability to relate to project team
members and their ability to communicate technical issues to all stakeholders.
We can agree that successful Project Managers must actually not only have sound technical
knowledge and in depth knowledge of Project Management, they also need emotional as well as
intellectual intelligence (EQ and IQ). If you investigate what soft skills are, you will see why
having high emotional intelligence is important!
"Soft Skills are behavioral competencies. Also known as Interpersonal Skills, or people skills,
they include proficiencies such as communication skills, conflict resolution and negotiation,
53
personal effectiveness, creative problem solving, strategic thinking, team building, influencing
skills and selling skills, to name a few."
As a result there is a limited number of the population that is likely to make really good project
managers. Some organizations use personality trait tests such as the Myer-Briggs test (MBTI)
that categorizes personalities into 16 types that are combinations of: Introvert, Sensing,
Thinking, Judging, Extravert, iNtuitive, Feeling, Perceiving.
One of the readings is an article by Max Wideman where he attempts to break down the general
population on the basis of MBTI for suitability of project work. Interestingly his findings
indicate about 30% of the general public are probably not suited to working on Projects in any
team or leadership role. They believe 40-45% of the population are suitable for some type of
project management leadership role and 20-25% are followers, but that only a very few 1-2 % of
the population are the appropriate types for managing project conceptualization stage.
Should you take notice of this? Maybe not - there are always exceptions to the rule. However
you should recognize that some employment agencies and organizations where you may wish to
work will and for that reason it can be useful to be aware of your personality type and what type
of project role that is likely to make you considered suitable for.
Personally, while I think being aware of your MBTI can be useful. I'd recommend that you look
at the list of traits identified next for Project Managers and - if you wish to work in this role -
honestly appraise your own abilities against those listed. If you can truthfully say that you have
the majority of these traits Project Management as a discipline would welcome your entry into
this career. The more effective Project Managers we have trained in industry the higher the
number of successful projects there will be run! If however, you know that you would have
issues with many of these traits, I'd be inclined to place your energies elsewhere... possible still
in project work but aiming for a team role rather than a leadership role.
If you are in a situation where you know you will be expected to work in project teams
regardless of whether you believe you are suited to project work or not, then enrolling in and
undertaking some formal studies on Project Management will definitely make your life easier,
but if you recognize being a PM is not your ultimate goal then I would be likely to limit your
studies to vocational levels (Diploma).
54
See the SLIDE of points drawn from multiple sources of successful Project Manager traits:
Can inspire
Communicate well
Has integrity and enthusiasm
Team-builder
Competent
Has empathy and problem solves
Cool under pressure
Ability to delegate
Have foresight
Are organized
Know how to lead
Good communicators
Pragmatic
Empathetic
Collaborative management style
Adaptable
Resourceful
Great communicator
Flexible
Naturally command authority
Can sift data well
Set, observe, re-evaluate priorities
Ask good questions and listen
Don't use information as a weapon
If seeking to be a Project Manager, the hardest task will be getting an organization to appoint you
to the role before you have had experience running projects that have been successful. I am sure
many of you will already have experienced the frustration of having gained training in a field to
55
find that the great majority of employment opportunities are offered only for those with previous
experience! This is an issue for anyone looking to fulfil a leadership role - someone has to invest
the faith in you to start off with for you to gain the experience that everyone places so much
importance on. Often this trust will only be placed in people that have worked within an
organization on projects as a team member for some time, though there will always be the
occasional situation where a ‘newbie' is given a chance.
However, when seeking to get this type of position look for mentors both within and without the
organization. In the rest of the topics we have already covered, you have found "Expert
Judgement" referred to quite often as a technique for performing management processes.
Obviously if it is your first time running a project, you may be lacking in this area. However,
don't read "expert judgement" as just you own. If the organization uses Portfolio Managers this
job role entails providing mentorship to the Project Managers assigned to projects under their
authority. They are a great example of the sort of people that can provide you with their "expert
judgement" to help you carry out various processes. If there are no portfolio managers at this
level, seek out mentor relationships with other Project Managers that do have more experience.
The Internet can be an invaluable resource also, allowing you to access the experience and
advice of project and portfolio managers with a wealth of experience. Many of these people are
more than willing to put their experiences in writing, as you will find if you access the reading
resources provided with this course module.
If you are going to agree to managing a project, do try to form an understanding of it as quickly
as possible so that, at a personal level, you can form a decision about whether it is a good
potential project. Being offered a PM role for a project that seems deemed to fail can be a very
effective nail in the coffin for your aspirations of making a career as a project manager!
• Before progressing to the next topic, I encourage you to look at the Readings Tab. There are
some detailed descriptions of Project Manager Job Roles. Also have a go at the online quiz to
find out what Myer-Brigg ‘type' you are and read the Max Wideman article that evaluates which
Myer-Brigg personality types are most suited to project management job roles.
Useful Links
56
VIDEO:
• http://www.youtube.com/watch?v=Vkd7JGl0-90 (The Project Manager Role)
• http://www.youtube.com/watch?v=QLWl3NxgEW4 (Explanation of how Portfolio
Management helps with strategic analysis and selection of projects).
WEB:
• http://www.projectmanagement.net.au/position-project-manager-roles-and-responsibilities
Australian Project Manager - Job Description
• http://www.best-job-interview.com/project-manager-job-description.html USA Project
Manager Job Description
• http://targetjobs.co.uk/careers-advice/job-descriptions/278215-project-manager-job-description
UK description of Project Manager Job Role
• http://www.projectsmart.co.uk/top-five-project-management-traits-to-master.html
• http://www.cio.com/article/447182/Six_Attributes_of_Successful_Project_Managers
• http://www.projecttimes.com/articles/top-10-leadership-qualities-of-a-project-manager.html
• http://99u.com/tips/6946/Top-10-Characteristics-of-GREAT-Project-Managers
• http://www.pmi.org/en/Professional-Development/Career-Central/10-Countries-with-Highest-
Salaries-for-Project-Managers.aspx See for average figures and comments by people working in
the field.
• See http://www.maxwideman.com/papers/profiles/intro.htm To read an article that researches
which Myer-Briggs Personality Types are best suited to different roles in Project Management
• Then do the questionnaire http://www.humanmetrics.com/cgi-win/JTypes2.asp to find out
roughly what Myer-Briggs Type you are (not a replacement for having a full Myers-Brigg
evaluation).
• http://maxwideman.com/issacons2/iac1276b/index.htm Slide show on the Project Portfolio
Manager Job role.
• http://maxwideman.com/issacons3/iac1365b/sld001.htm slideshow about the power of politics
within an organisation.
57
• http://en.wikipedia.org/wiki/Soft_skills explanation of soft skills and their importance
Topic 11: Follow-up of Projects and innovation
Although it is extremely important, the follow-up phase is often neglected. During the follow-up
phase, everything is arranged that is necessary to ensure sustainability after the project
completion (Baars 2006). A project is said to be sustainable when:
it is functioning and being used
it is able to deliver an appropriate level of benefits (quality, quantity, convenience,
continuity) to all, including the poorest women and men
it continues to function over a prolonged period of time (which goes beyond the life span
of the original equipment)
its management is institutionalized
its operation, maintenance, administrative and replacement costs are covered at the local
level
it can be operated and maintained (O&M) at local level with limited but feasible external
support
it does not affect the environment negatively
Therefore, in order to ensure sustainability of a project, it is imperative to include an internal
follow-up process. This complements the participatory monitoring and evaluation component
done in cooperation with the end-beneficiaries, but gives the responsibility to the implementers
and initiators of the project to keep an eye on what has been done.
Definition of Follow-up
Follow-up is defined as “the monitoring and evaluation of the impacts of a project or plan for
management of, and communication about the performance of that project or plan” (Morrison-
Saunders and Arts 2004). However, to avoid overlapping with the participatory monitoring and
evaluation and operation and maintenance phases, this factsheet will focus on the following
principles:
58
Follow-up as spin-off projects: a project that exploits or builds on earlier work or that repeats
something that has already been done.
Follow-up as internal supervision of completed projects: the continuous monitoring of the
activities by the project implementers, and possible improvements to the existing project.
Purposes of Follow-up
Follow-up can serve many purposes ranging from technical and scientific to socio-political and
management aspects:
Control of projects and their impact: follow up provides both verifying and controlling
functions for implemented projects.
Maintain decision-making flexibility and promote an adaptive management approach:
feedback from follow-up programmes provides opportunities for project managers and
regulatory agencies to respond when changes in an activity, in the environment or in the
social-political context call for an adaptation of current practices.
Improved scientific and technical knowledge]: many activities involved in projects might
be based on scientific methods. Some follow-up activities evaluate the utility and
effectiveness of these tasks. Follow-up will allow the better understanding of new
technologies and approaches, which may result in improving the quality of measures or
techniques used in future projects.
Improve public awareness and acceptance: on-going follow-up programmes may improve
public awareness about the actual effects of development projects, leading to improved
public acceptance of proposals.
(Source: Morrison-Saunders and Arts 2004)
Follow-up as Spin-off Projects
Follow-up is a key mechanism for feedback: It allows to learn from the experiences of previous
projects and allows to share these outcomes with the development and scientific community. In
particular, without some form of follow-up, the benefits of the projects and the outcomes will
59
remain unknown. By incorporating feedback into the planning process, follow-up assesses the
impact and thereby enables learning from experience to occur. Through activities such as
monitoring and evaluation, follow-up provides concrete evidence of outcomes (Morrison-
Saunders and Arts 2004). This knowledge can be utilized by the implementers or other agencies
alike to improve future projects.
Spin-off projects are to some extent easier to carry out, as they build on previous experiences.
During the planning of spin-off projects, it is necessary to include the lessons from the previous
projects, based on the findings in the participatory monitoring and evaluation and follow-up
processes (Batjes, 2008). Typical questions you should ask yourself and your team when
brainstorming for spin-off projects are:
Which were the problems that we faced?
What could have been done to avoid these problems?
Did we learn something new about the technology implemented?
Is there any change in the technology that could be implemented?
Are the end-beneficiaries satisfied with the project?
Could we have approached the end-beneficiaries in a different way?
Is there any project-component we did not include?
The lessons learned should be described in the background chapter of the new proposal, but it
has to be clarified how this spin-off represents a breakthrough or advancement from what it was
done before.
Follow-up also gives credibility to an organisation, as implemented projects can serve as
references when applying for funds for new projects. Therefore, it is important to supervise what
has been implemented, and ensure that the objectives are reached in a long term. You should
make sure that you document every step of the follow-up process with up-dating reports, pictures
and videos. It is good to be able to demonstrate in an illustrative way (in powerpoint
presentations, web page, annual reports, etc.), the experience your organisation has gathered with
previous projects.
60
Follow-up as Internal Supervision of Completed Projects
Follow-up provides the missing link between planning and continued project implementation.
Follow-up links the pre- and post- decision stages of planning, thereby overcoming the gap that
arises when there is a difference between project plans and their implementation. Follow-up not
only provides information about the consequences of a project, but it also gives the agencies the
opportunities to implement measures to mitigate or prevent negative effects. Unless there is
minimum follow-up capability, the project operates as a linear rather than iterative process and
lacks continuity (adapted from Morrison-Saunders and Arts 2004).
Follow-up (Supervision) Programme Design
1. Determination of Need and Scope
The question of why to conduct an internal follow-up programme for your project can be
answered with a multitude of different solutions. The core purposes are control, information and
communication. A follow-up programme will definitely add value to your project and future
activities, and therefore it needs to be included during the planning step.
It is indispensable that you and your team realise the need of it. In this step you should define the
scope of the follow-up issues (what is to be supervised), specially the indicators that will help
you to keep an eye on the project. For instance, if you installed a new wastewater treatment
plant, you should monitor the quantity and quality of the treated water, as well as the level of
satisfaction of the end-users, and take the necessary steps if there is scope for improvement.
2. Defining Tools, Methodology and Time-Plan
Once the scope of the follow-up programme as well as the indicators are defined, the next step is
to define the tools and methodologies you will need. This means the type of activities, such as
visits to the project site, laboratory tests, interviews with the stakeholders and the frequency and
time span of these activities. Knowing what to do and how often, will give you an idea of how
much the follow-up programme will cost per year.
61
3. Financing the Follow-up Programme
Even though that most of the external financing programmes that support projects do not provide
funds after the project termination, it is imperative to plan ahead how the costs of the post-
implementation activities will be covered. One option is to cover the costs through beneficiaries’
contribution, in case there is a component of cost-recovery through end-user’s services. In this
case, it is important that the services fees include external follow-up activities. Another option is
to cover the costs of the mandays, field visits with the overheads or the annual budget of the
organisation. Finally, you could include supervision of on-going projects as part of your new
proposals, justifying the need for a follow-up component as part of the gathering knowledge
experience.
4. Determination of Roles and Responsibilities
The most important issue to take care of is to assign completed projects to your staff members. It
is essential to encourage the sense of ownership among your team members, especially of those
projects which are completed. Otherwise, the implemented projects will be forgotten when new
ones start. Deliberately look out for monitoring and evaluation skills in all your
project/programme and management positions, they will be of support in all these process.
5. Gathering Data and Evaluation
Once the project is completed, and the internal follow-up starts, make sure to plan and integrate
the visits, communication with stakeholders, laboratory analysis, etc. in your day-to-day
activities.
Unfortunately the evaluation of outcomes and results from the follow-up is often not conducted,
but this analysis should be carried out as it is a critical step in the process. An analysis of the data
collected should be conducted to ensure that the information provided is useful for the targeted
audience. Overall, the evaluation stage needs to identify the lessons learned from the follow-up
programme.
62
The evaluation stage of a follow-up programme may determine that further steps are needed in
order to manage the problems identified. To remedy problems identified during follow-up,
modifications of project design, activities, operation or maintenance activities might be required.
6. Reporting
To ensure that reporting of results is not neglected, it is recommended that a formal reporting and
evaluation process be developed. In order to avoid extra work and allow for comparison, make
sure to develop a simple template for all the members of the staff to report about their internal
follow-up activities and the evaluation. The follow-up reports should include as a minimum:
Short description of the project
Location of the project
Contact person in the project site (with contact information)
Description of the follow-up mechanisms (e.g. field visit, lab test, etc.)
Issues or problems identified
Results
Data analysis and evaluation
Corrective measurements undertaken
Further actions proposed to deal with the issue
Lessons learned
More Tips for the Follow-up Phase
1. Always budget for a follow-up programme including costs for staff, assessments,
baselines, monitoring systems and evaluation.
2. Include follow-up in the work plan and proposal, if possible.
3. Develop a follow-up plan and focus on just a few indicators.
4. Develop data collection and management processes-these should be made as simple as
possible to ensure utilisation and should also capture staff roles and responsibilities.
5. Regularly hold meetings to reflect on monitoring and evaluation data ― the emphasis
here should be learning and building feedback into the programme.
6. Share results with beneficiaries and other stakeholders ― avoid reporting only upwards.
63
7. Conduct a baseline at the beginning of the project/ programme and final evaluation at the
end so that results can be systematically captured.
Adapted from International Federation of Red Cross and Red Crescent Societies
2007
Applicability
Follow-up should be integrated to all types of projects, from establishment of infrastructure
initiatives to training and awareness raising activities.
Advantages
Managers and other stakeholders including donors need to know the extent to which their
projects are meeting their objectives and leading to their desired effects
Follow-up builds greater transparency and accountability in terms of use of project
resources
Internal follow-up alerts managers to actual and potential project weaknesses, problems
and shortcomings before it is too late
Future planning and programme development is improved when guided by lessons
learned from experience.
Successful implemented projects serve as reference for future applications for funds
In overall, it avoids that the implemented projects are forgotten with the time
Disadvantages
Internal follow-up of projects require human power and extra activities, which are mostly
not financed by the funding agency after the project completion
To follow-up completed projects might deviate the attention and efforts of the members
of the team working in new projects
64
References
BAARS, W. (2006): Project Management Handbook, Version 1.1 – July 2006. URL [Accessed:
17.04.2012]. PDF
International Federation of Red Cross and Red Crescent Societies (Editor) (2007): Monitoring
and Evaluation in a nutshell. International Federation of Red Cross and Red Crescent Societies.
MORRISON-SAUNDERS, A.; ARTS, J. (Editor) (2004): Assessing Impact, Handbook of EIA
and SEA Follow-up. London: Earthscan. URL [Accessed: 28.05.2010].
BATJES, K. (2008): Toolkit Cartoon: Monitoring. Wageningen: The Technical Centre for
Agricultural and Rural Cooperation (CTA). URL [Accessed: 03.04.2012].