PGDPM Project Integration Management

Project Integration Management
POSTGRADUATE DIPLOMA IN PROJECT

MANAGEMENT
PROJECT INTEGRATION MANAGEMENT
STUDY GUIDE
Copyright © 2018
REGENT BUSINESS SCHOOL
All rights reserved; no part of this book may be reproduced in any form or by any
means, including photocopying machines, without the written permission of the
publisher.
TABLE OF CONTENTS
CHAPTER TOPIC PAGE
Introduction to Project Integration Management 3
PROJECT MANAGEMENT AND ORGANISATIONAL 7

1
STRATEGY
2 WHAT IS PROJECT MANAGEMENT? 24
3 PROJECT PLAN DEVELOPMENT 62
4 PROJECT PLANNING METHODOLOGY 118
5 PROJECT PLAN EXECUTION 140
6 PROJECT INTEGRATED CHANGE CONTROL 148
7 PROJECT CLOSURE 160
Bibliography 170
POSTGRADUATE DIPLOMA IN PROJECT MANAGEMENT 2

Introduction to Project Integration Management

Project management integration deals with effectively integrating the various project management
knowledge areas across the project life cycle (Initiation, Planning, Execution and Closing), in order to
successfully accomplish project objectives. Integration ensures that the various elements of the
projects are properly coordinated. It involves making trade-offs among competing objectives and
alternatives to meet or exceed stakeholder needs and expectations.
Integration management will produce a series of deliverables. The key deliverables include the project
charter, project plan, change requests and status reports. Six processes are engaged during
integration. The first of these processes is the development of the project charter which initiates the
project and authorises the project to get underway. The second process is the development of the
project plan. The project plan includes the project charter, the definition of the project, project
objectives, the project budget, the project schedule, the resources required for the project, the
approach, management plans, and the initial risk assessment. The process that follows the project
plan is the directing and monitoring of project execution. This is the third process. Items produced
during this phase include the final deliverable product.
Fourth, project work must be monitored and controlled. One important aspect of this process is change
management. Requests for project change may be made during the project lifecycle. If these requests
are not monitored and controlled, then the quality budget, schedule and success of the project may be
negatively impacted. This process is closely related to the fifth: the control of integrated change.
Finally, the project must be closed when it has been completed – approval signatures obtained and
final invoices paid. Closing the project involves reviewing the processes, successes and deficits that
were encountered during the project lifecycle. During this phase, a “lessons learned” document is
produced by the project management team.
Project integration management is by far the most important role in any project as it helps project
managers to integrate all activities crucial to project success. The main project integration
management tasks include:
 the development of the project charter
 the development of a project management plan

 Directing and managing project execution

 Monitoring and controlling project work
 Performing integrated project change control
 Closing project or phase
Aims of the Module

The aims of this module are to ensure that the student is able to:
Understand the theories, methods and techniques in project integration management and how it applies
in the project management environment
 Demonstrate the ability to interrogate multiple sources of knowledge in project integration
management
 Understand the complexities and uncertainties of applying project integration knowledge, skills,
tools, techniques and processes
 Use a range of specialised skills from the Project Management Bodies of Knowledge (PMBoK)
to identify, analyse and address project integration management problems
 Critically evaluate the potential roles and responsibilities of the Project Manager and Project
Team to inform professional and ethical project management practice
 Critically review the accessing, processing and managing of information via the integrated
change control processes of monitoring and controlling project work
 Produce and communicate the project management plan and report on its implementation and
change control to the various project stakeholders based on their roles and relationships within
the project
 Take responsibility to manage their own and others learning needs by engaging in individual
and group discussions on related project integration management case studies and learning
exercises
Learning Outcomes
Upon completion of this module, the student should be able to:
 Conceptualise and contextualise project management
 Conceptualise project phases and project life cycles
 Analyse the managing by projects approach
 Differentiate between the various major processes in integration management
 Apply project integration management tools and techniques

How to use this module guide

The purpose of this guide is to introduce you to the concept and application of Project Integration
Management which outlines the processes required to ensure that the various elements of the project
are properly coordinated. These processes that you need to familiarise yourself with consists of the
development of the project charter and project plan, execution of the project plan, and overall change
control.
The module guide should be used in conjunction with the prescribed textbook. The module guide and
prescribed textbook comprehensively explains the project integration management knowledge, skills,
tools and techniques required for successful project management.
At the commencement of each section of this Study Guide, you will find a list of learning outcomes.
These learning outcomes outline the main points that you should understand when you have completed
the section with its supporting chapters in the prescribed textbooks. Avoid reading all the material at
once. Each study session should be no longer than two hours without a break.
As you work through the Study Guide you may come across:
A think point asks you to stop and think about an issue. Sometimes you are
Think Point
asked to apply a concept to your own experience or to think of an example
You may come across self-assessment questions which will test your
Self-assessment understanding of what you have learnt so far. You should refer to the Study
Exercise Guide and prescribed textbooks when attempting to answer the self-check
activities
These are designed to help you study and prepare for the assignment and examination.
To ensure that you derive maximum value from studying the Project Integration Management modules,
please do the following:
 read the module guide in conjunction with your prescribed textbook and recommended
readings;
 check that you understand each chapter of both the module guide and prescribed textbook
 Familiarise yourself with the abbreviated words used in the module guide and prescribed
textbook

 Test your knowledge by completing the activities after studying each chapter
PRESCRIBED AND RECOMMENDED READING
PRESCRIBED:
Larson, E.W. and Gray, C.F.2017.Project Management: The Managerial Process.7th ed. New York:
McGraw-Hill
RECOMMENDED:
1. PMI. 2013.A Guide to the Project Management Body of Knowledge.6th ed. Pennsylvania: Project
Management Institute
2. Gido, J and Clements, J.P.2015. Successful Project Management. 6th ed. USA: Cengage Learning
3. Van der Walt, G. and Williams, F.2015.A Guide to Project Management.2nd ed. SA: Juta and Company
Ltd
4. Kloppenborg, T.J.2015.Contemporary Project Management.3rd ed. USA: Cengage Learning

CHAPTER ONE
ORGANISATION AND PROJECT MANAGEMENT
Learning Outcomes:
On completion of this chapter, the student should be able to:
 Demonstrate a basic understanding of strategic management.
 Justify the use of projects in achieving organisational strategy.
 Evaluate and choose from a range of project selection criteria those required to ensure
alignment with a specific organisation’s strategy.
 Differentiate between financial and non-financial project selection methods.

1.1 Introduction
The race to create a business value and to sustain competitive advantage has organisations turning to
project management. Project management is seen to play a critical role as a key enabler of
organisational strategy.
Survival in today’s highly competitive modern business environment requires continuous investment in
new ideas and products by using modern technologies and practices. Additionally, the rapid technology
evolution affects organisations significantly. The strategy of an organisation, must invest continuously in
Research and Development (R&D) for new competitive products and services. Such a new product or
service must be available to the market in time and with the appropriate quality.
Even the best-designed business model cannot last forever and must be continually adapted to keep
pace with shifting customer needs, markets and competitive threats.
Project management is rapidly becoming a standard way of doing business in organisations and
projects are becoming the tools of implementing the business strategy of an organisation. The desired
benefits of organisational strategy are achieved faster and more efficiently when strategic objectives
are implemented using a project management approach. Adopting a corporate-wide approach to
project management ensures consistency of delivery and it raises the general standard of project
delivery, enabling an organisation’s business opportunities to be embraced more profitably with
reduced risk. The role of project management has now evolved to that of being a pillar of
organisational success.
Strategic Management
Strategy is fundamentally deciding how the organisation will compete (Larson and Gray, 2017). The
following basic concepts impact on the understanding of what is strategic management:
 Competitive advantage — operating with an attribute or set of attributes that allows an
organisation to outperform its rivals.
 Sustainable competitive advantage — one that is difficult for competitors to imitate.
 Strategy — a comprehensive transformation action plan that identifies long-term direction for
an organisation and guides resource utilisation to accomplish organisational goals with
sustainable competitive advantage.

 Strategic intent — focusing all organisational energies on a compelling goal.
Strategic management is therefore, the process of formulating and implementing strategies to

accomplish long-term goals and sustain a competitive advantage.
1.1.1 Why Project Managers need to understand the Strategic Management

Process
There are two main reasons why project managers need to understand their organisation’s mission and
strategy (Larson and Gray, 2017). The first reason is so they can make appropriate decisions and
adjustments.
Project managers who do not understand the role their project plays in accomplishing the strategy of
their organisation tend to make the following serious mistakes:
 Focusing on problems or solutions that have low priority strategically
 Focusing on the immediate customer rather than the whole market place and value chain
 Overemphasizing technology as an end in and of itself, resulting in projects that wander off
pursuing exotic technology that does not fit the strategy or customer need
 Trying to solve every customer issue with a product or service rather than focusing on the 20
percent with 80 percent of the value (Pareto’s Law)
 Engaging in a never-ending search for perfection that no one except the project team really
cares about
The second reason project managers need to understand their organisation’s strategy is so they can be
effective project advocates. Project managers have to be able to demonstrate to senior management
how their project contributes to their firm’s mission. Protection and continued support come from being
aligned with corporate objectives. Project managers also need to be able to explain to team members
and other stakeholders why certain project objectives and priorities are critical. This is essential for
getting buy-in on contentious trade-off decisions.
For these reasons project managers will find it valuable to have a keen understanding of strategic
management and project selection processes (Larson and Gray, 2017).

1.1.2 Requirements for Strategic Planning

Strategic planning is an organisational management activity that is used to: set priorities; focus energy
and resources; strengthen operations; ensure that employees and other stakeholders are working
toward common goals; establish agreement around intended outcomes/results; and assess and adjust
the organisation's direction in response to a changing environment. It is a disciplined effort that
produces fundamental decisions and actions that shape and guide what an organisation is, who it
serves, what it does, and why it does it, with a focus on the future. Effective strategic planning
articulates not only where an organisation is going and the actions needed to make progress, but also
how it will know if it is successful (Mar, 2012).
The requirements for strategic planning are therefore:

1. Mission Statement: A statement that makes it clear what business the company is in.
2. Objective statements: Series of statements that express an organisation’s qualitative and
quantitative goals. Also called Critical Success Factors or Corporate Values.
3. Competitive Strategy: It is a method by which an organisation attempts to achieve its mission
and objectives
1.1.3 The Strategic Management Process

Strategic management is the process of assessing “what we are” and deciding and implementing “what
we intend to be and “how we are going to get there.” Strategy describes how an organisation intends to
compete with the resources available in the existing and perceived future environment (Larson and
Gray, 2017).
Strategic management provides the theme and focus of the future direction for the firm by:
 Responding to changes in the external environment — environmental scanning
 Allocating scarce resources of the firm to improve its competitive position —internal responses
to new action programs.
The components of strategic management are closely linked, and all are directed toward the future
success of the organisation. Strategic management requires a strong link among the mission, goals,
objectives, strategy, and implementation. The mission gives the general purpose of the organisation.
Goals give global targets within the mission. Objectives give specific targets to goals. Objectives give

rise to formulation of strategies to reach objectives (Larson and Gray, 2017). Finally, strategies require
actions and tasks to be implemented. In most cases the actions to be taken represent projects. Figure
1.1 shows a schematic of the strategic management process and major activities required.
Review/ Revise
Mission
What are we
1
External Environment: Internal Environment:

(Opportunities & Threats) (Strengths & Weaknesses)
New Goals &

2 Objectives
What do we intend to be?

Portfolio
of Strategic Choices
3
Strategy
Implementation
How are we going to get there?

Project Selection
4
Projects
Figure 1.1 the Strategic Management Process

Source: Larson and Gray (2017).
The typical sequence of activities of the strategic management process, as

highlighted in Figure 1.1 above is:
1. Review and define the organisational mission:
 identify “what we want to become
 identify the scope of the organisation in terms of products and services
 traditional components found in mission statements are major products and
services; target customers and markets; and geographical domain

2. Set long-range goals and objectives:

 Objectives translate the organisation mission into specific and concrete, measurable terms
3. Analyse and formulate strategies to reach objectives:
 Answers the questions of what needs to be done to reach the objectives
 Assessment of internal and external environments; internal strength and weaknesses of the
enterprise
4. Implement strategies through projects:
 answer the question of how strategies will be realised, given available resources
 emmited resources are allocated based on organisational priorities.
 orrganisational structure to support projects.
 project management processes for planning, executing, and controlling are essential to ensure
strategies implemented effectively and efficiently.
 Project selection and priority system ensures strong linkages between projects and the
strategic plan.
1.2 Implementing Strategies through Projects

Research suggests that implementing organisation strategy through project management produces
significant benefits for the organisation (Van der Walt and Fox, 2016). The following are key benefits of
aligning projects with organisational strategy:
 Coordination of Resource Sharing:
By aligning projects and greater strategic goals, project managers help ensure that resources are well
spent. Where previously project managers might lead expensive projects that may not have been
compatible with greater business aims, alignment casts spending in a new light. Funds are spent to
directly impact a company’s overall performance, thereby increasing profitability and reducing
unnecessary expenses.
 Process Improvement:
Alignment can also help improve project success rates and, therefore, the ability for the organisation to
address customer needs and expectations. Research has shown a significant increase in
organisational financial performance and project success rates when projects were aligned with

business strategies. When each project directly contributes to the welfare of the company, the
organisation as a whole improves, improving customer experiences and retention rates.
 Reputation:
Reputation plays a major role in the image and marketability of the organisation. Survival becomes a
struggle for organisations with a bad reputation caused by poor: delivery systems, product development
and customer relationship management. Contracts must be completed on time, use the minimum
resources without harming the environment and satisfy the needs of stakeholders. A project-based
approach is crucial to rectify poor performance and an organisations poor image. Available resources
are used more efficiently and products are delivered on time and within scope.
 Workflow and Design:

Large organisations are generally bureaucratic in nature with many levels of reporting, management
and decision-making. Working under the triple constraints of time, cost and scope as well as quality,
places tremendous pressure on managers to implement a policy or programme in a short period of
time. Project management improves workflow by avoiding delays caused by hierarchical approval
processes (Van der Walt and Fox, 2016).
1.1.4 How to align Organisational Strategy to Project Management

The nature of the project management/business strategy alignment is depicted in n Figure 1.2.
Highlighted are the competitive attributes of organisational/business strategy and the focus and content
of project management elements (Milosevic and Srivannaboon, 2006).
An organisation makes its strategic choice by selecting competitive attributes that are advantageous
(e.g., time-to-market, quality, cost, and features). These attributes are used to drive the different ways
that projects are managed in terms of their foci and contents. For example, if the competitive attribute of
time-to-market is chosen, the focus or priority of project management elements (strategy, organisation,
process, tools, metrics, and culture) is to accomplish the time-to-market competitive attribute. This
study defines this focus as schedule-driven (see Figure 1.2).
The content or configuration of project management elements (strategy, organisation, process, tools,
metrics, and culture) is also tailored to support this schedule-driven focus. For example, in case study A
(Larson and Gray, 2017), the configuration of the project strategy (P1) was tailored to support its

schedule focus; the time-to-market competitive attribute adopts a strategic focus that allows project
managers to ignore cost and product features in making trade-off decisions in order to attain time-to-
market goals. The project process (P3) is similarly tailored to deliver a time-to-market competitive
advantage by overlapping or combining process phases, milestones, and activities. At the same time,
operating conditions detected from stage gates (P7) help to redirect projects, if there is any change that
might threaten the success of the projects.
There are infinite combinations of competitive attributes that companies can use as sources of
advantage to compete with their rivals. There are also unlimited alternatives for tailoring project
management elements to support these competitive attributes.
Figure 1.2: Aligning Projects with Organisational Strategy

Source: Milosevic & Srivannaboon (2006)
Propositions 1 to 6 demonstrate how the competitive attributes of business strategy configure the
individual project management elements. This should lead to one single and generic proposition that
describes the interaction of the organisational/ business strategy and project management elements:
the competitive attributes of the business strategy drive the focus and content of project management
elements.

Think Point Will all projects necessarily align with strategic intent?
1.1.5 Enterprise Project Management Office

The organisational structure tasked to achieve this alignment should be none other than project
management office (PMO) or the enterprise project management office (EPMO) (Villanovau, 2017). An
EPMO, as a centralized, organisation-level entity, is designed to specifically plan new projects with
greater organisational strategy in mind. EPMOs work within the project management framework of the
organisation as depicted in figure 1.3 below, to ensure that projects successfully deliver on
organisational strategies that seek to deliver organisational objectives.
EPMOs participate in both executive-level planning sessions and overall strategic planning sessions to
better understand how individual projects can meet the needs of the organisation and establish a
unified company vision. Here, it is crucial that both project managers and senior leaders recognize the
value of full EPMO integration and view the entity as having executive-level access to better align
projects with overall goals (Villanovau, 2017).
For each project, the EPMO is designed to serve as a liaison between team members, project
managers and senior executives. EPMO managers and executive leaders should work together
throughout a project’s implementation to establish a continuing dialogue and ensure alignment.

Figure 1.3: Project Management Framework

Source: Chase group (2017)
When projects are completed, EPMOs have the added responsibility of reporting success in the context
of overall business aims (Chase group, 2017) to senior executives and illustrate how the project fit with
strategic considerations. Unlike in traditional project management, EPMO projects are generally not
viewed as successes in and of themselves. Rather, a success is defined by the degree to which it helps
achieve business goals.
As businesses continue to compete with each other and define themselves in their industries, project
alignment can be used to ensure that everything a business does is for a specific purpose. Facing the
near-constant scrutiny enabled by digital technology, businesses wishing to be seen as having a clear
mission should analyse the extent to which their various departments are aligned with that strategy.
EPMOs are one way of pursuing alignment and, therefore, improving both financial performance and
company image.
1.2 Project Selection

In many organisations, there is going to be more potential projects or proposals than the capacity of the
organisational resources. A system is necessary to select projects and allocate resources to these
projects in order to maximise value added. Specific selection criteria are required to ensure alignment
with organisational strategy. The benefits of carefully selected criteria are as follows:
 More effective planning of organisational resources.
 More efficient utilisation of organisational resources.

 A portfolio of projects that balance opportunities, and threats given available resources.
 Keeping the organisation stakeholders focused on the most critical projects.
 Obtaining consensus as to which projects have the highest priority (Larson and Gray, 2017)
Practitioners can choose from a relatively large number of project selection models. Picking a selection
model is highly dependent on certain organisational attributes such as industry, risk aversion level,
technology, competition, management style, and markets. Selection models should encompass
multiple criteria such as profitability, researching new technology, public image, core competencies, and
strategic fit.
1.1.6 The Selection Process

Projects falling in the “must do” category (otherwise the organisation will fail or will suffer a severe loss),
will see all other selection criteria being ignored (Larson and Gray, 2017). A “must do” project is one
where the majority of the organisation stakeholders agree that the project is crucial and needs to be
implemented in order to ensure the continuity of the organisation. For all remaining projects, multiple
selection criteria, which link the project to the organisational strategy, should be used.
Figure 1.4 shows the project screening process starting with the idea for a project or a potential project.
The value to the organisation of the potential project is assessed through data and information
collected. The project chosen by the sponsor based on the collected data is forwarded to the project
office who rejects or accepts the project based on the criteria and current portfolio of projects.
The project office then sets implementation in motion if the project is accepted. In the case where the
project sponsor is an external stakeholder, then it is the project sponsor and not the project team who
decides which project needs to be completed.

Terminate Reject
Supporting Data &

Analysis Project Office
Project Idea Self Evaluation
Need, Strategic Fit, ROI, Pursue Assessment
Payback, Risk, IRR
Need more information
Accept Accept
Allocate Resources,
Hold for Resources
Monitor Progress
Figure 1.4: The Project Screening Process

Source: Larson and Gray (2017)
1.1.7 Selection Criteria

The strategic value of a proposed project must be determined before it can be considered for
implementation. Although there are many criteria for selecting projects, selection criteria are
typically identified as financial and nonfinancial.
1.1.7.1 Financial Selection Criteria
For most managers, financial criteria are the preferred method to evaluate projects. These models are
appropriate when there is a high level of confidence associated with estimates of future cash flows.
Two models and examples are demonstrated here—payback period and the net present value (NPV).
Other financial models include return on investment (ROI), breakeven analysis and internal rate of
return (IRR).
Payback Analysis
Payback analysis is used to determine the amount of time it will take to recoup (net cash inflows) the
total investment made on a project. Payback analysis shows the time that will pass before realized
benefits overtake accrued and continuing costs. Payback occurs in the year when the cumulative
benefits minus costs reach zero. The project owners are interested in those projects with the shortest
payback periods.

Net Present Value Analysis

Net Present Value analysis is a method of calculating the expected net value (gain or loss) by
discounting all expected future cash inflows and outflows to the present time. If financial consideration
is a key decider for a project selection, then companies should only consider a project under the
following:
 If the NPV is greater than or equal to zero rands, accept the project.
 If the NPV is less than zero rands, reject the project.
 Accept projects with higher NPV’s than lower NPV’s if all other factors are equal.
A positive value of NPV indicates that the firm will earn a return equal to or greater than its cost of
capital.
1.1.7.2 Non-Financial Selection Criteria

Financial return, while important, does not always reflect strategic importance. Organisations have to
be disciplined in saying no to potentially profitable projects that are outside the realm of their core
mission. This requires other criteria be considered beyond direct financial return. For example, a firm
may support projects that do not have high profit margins for other strategic reasons including:
 To capture larger market share
 To make it difficult for competitors to enter the market
 To develop an enabler product, which by its introduction will increase sales in more profitable
products
 To develop core technology that will be used in next-generation products
 To reduce dependency on unreliable suppliers
 To prevent government intervention and regulation
Less tangible criteria may also apply. Organisations may support projects to restore corporate image or
enhance brand recognition (Larson and Gray, 2017). Many organisations are committed to corporate
citizenship and support community development projects. Since no single criterion can reflect strategic
significance, portfolio management requires multi-criteria screening models. These models often use a
weighted individual criterion so that those projects that contribute to the most important strategic
objectives are given higher consideration.

Weighted Scoring Model

A weighted scoring model is a tool that facilitates the systematic process for selecting projects based
on a combination of different criteria (Larson and Gray, 2017). Project selection criteria needs to be
based on the organisational critical success factors and strategic goals. Failure to select the right
factors will render the priority and selection process useless. An example of an organisation’s project
selection criteria used may be: alignment with core competencies; alignment with strategic goals;
internal rate of return in excess of (eg. 15%); improve customer service; and urgency. Every company
develops their own selection criteria for projects.
Management weights each criterion by its relative contribution and importance to the organisation’s
goals, and strategic plan. The project office team evaluates each project proposal by its relative
contribution or benefit to the selection criteria. The project office team assigns a spectrum of values for
each criterion ranging from low (0), to high (10). This value represents the proposal’s fit to the specific
criterion.
SELECTION Alignment Alignment Internal Improve Urgency TOTAL

CRITERIA with Core with Rate of Customer SCORE
Competencies Strategic Return in Service
Goals excess of
15%
Weight 2.0 3.0 1.5 3.0 2.0
Proposal 1 2 7 3 5 3 50.5
Proposal 2 3 4 1 5 3 40.5
Proposal 3 9 6 3 3 3 55.5
Proposal 4 5 0 9 7 8 56.5
Proposal 5 3 8 4 9 4 69.5
Table 1: Example of a Project Scoring Matrix

Table 1 above shows a project selection matrix. For example, “Proposal 1” appears to fit well with the
strategic goals of the organisation since the project team gave it a score of seven. However, “Proposal

1” does little to support core competencies since the project team gave it a score of two. The last step
in this model is to apply management weights to each criterion by importance using a spectrum of
values ranging from low (1), to high (3). For example, improve customer service has a weight of three
while urgency has a weight 2. In rare cases such as two projects having the same score; the project
office team may pick the project that is more profitable and has less demand on organisational
resources.
A project management approach to business problems and opportunities is becoming the norm rather
than the exception (Larson and Gray, 2017). Projects are the tools for implementing the strategy of the
organisation. Effective project management starts with selecting and prioritising projects that support
the organisational vision, mission and strategy. The priority system focuses attention on the vision,
mission and major goals of the organisation. It fosters consensus to which projects are of highest
priority. It results in a portfolio of projects that balance threats and opportunities. It provides a better
utilisation of resources. All projects need to use the same selection criteria.
1.2 Summary
The importance of aligning projects with organisational strategy cannot be overstated. Multiple
competing projects, limited skilled resources, dispersed virtual teams, time to market pressures, and
limited capital serve as forces for the linking of organisational strategy with project management. This
link can only be achieved by integrating projects into the organisational strategy. Significant benefits for
the organisation are produced as a result of this integration. The focus of project management
elements can be seen to directly impact the achievement of the competitive attributes of the
organisation strategy. Effective project management starts with selecting and prioritising projects that
support the organisational vision, mission and strategy.
SELF-ASSESSMENT EXERCISE
1. “Project management is a key enabler of organisational strategy”. Do you agree/disagree with

this statement? Justify your response.
2. Deliberate on the mistakes that project managers who do not understand the role their project
plays in accomplishing the strategy of their organisation tend to make.
3. For a company of your choice, research what is their organisational goal and competitive
Strategy?

4. Where in the strategic management process do projects fall?

5. What are the key benefits of aligning projects to organisational strategy?
6. How would you go about aligning the focus of the project management elements to the
competitive attributes of the business strategy?
ANSWERS TO SELF-ASSESSMENT EXERCISE

1. Agree. Project management has the necessary knowledge, skills, tools and techniques to
effectively deal with deal with the constraints of limited time and funds to achieve organisational
objectives, satisfy customer needs and to sustain competitive advantage.
 Project managers who do not understand the role their project plays in accomplishing the
strategy of their organisation tend to make the following serious mistakes:
 Focusing on problems or solutions that have low priority strategically
 Focusing on the immediate customer rather than the whole market place and value chain
 Overemphasizing technology as an end in and of itself, resulting in projects that wander off
pursuing exotic technology that does not fit the strategy or customer need
 Trying to solve every customer issue with a product or service rather than focusing on the 20
percent with 80 percent of the value (Pareto’s Law)
 Engaging in a never-ending search for perfection that no one except the project team really
cares about
1. Responses may vary.

Company Business Goal Business Strategy
Ford Motor  Regain market share recently  Resize and downsize present
Company lost to General Motors models
 Regain quality reputation that  Emphasise use of
was damaged because of Pinto gas tank programmed combustion engines
explosions instead of diesel engines
Burger King  Increase productivity  Increase people efficiency
 Increase machine efficiency
CP Railroad  Continue company Growth  Modernise
 Continue company profits  Develop valuable real estate
holdings
 Complete an appropriate
railroad merger

2. The typical sequence of activities of the strategic management process is:

 Review and define the organisational mission
 Set long-range goals and objectives
 Analyse and formulate strategies to reach objectives
 Implement strategies through projects
3. Coordination of Resource Sharing
 Process Improvement:
 Reputation
 Workflow and Design
4. The competitive attributes of the business strategy drive the focus and content of project
management elements. Discuss Figure 1.2: Aligning Projects with Organisational Strategy.

CHAPTER TWO
DEFINING PROJECT MANAGEMENT
Learning Outcomes:
Demonstrate a basic understanding of project management framework
 Understand the impact of a change on one or more of the triple constraints to project success
 Differentiate between strategic leadership and management in a project management context

2.1 Introduction
Project management is both a science and an art.
It is science in that it relies on proven and repeatable processes and techniques to achieve project
success (Larson and Gray, 2017). It is an art because it also involves managing and relating to people
and requires the project manager to apply intuitive skills in situations that are totally unique for each
project. A good project management methodology provides the framework, processes, guidelines and
techniques to manage the people and the work. A good project management methodology increases
the odds of being successful and therefore adds value to the organisation, the project and the project
manager.
Project management has been proven to be the most effective method of delivering products within
cost, schedule, quality and resource constraints. Leading organisations across sectors and geographic
borders have been steadily embracing project management as a way to control spending and improve
project results. When the 2008 recession began, this practice became even more important.
Executives discovered that adhering to project management methods and strategies reduced risks, cut
costs and improved success rates—all vital to surviving the economic crisis (PMI, 2010).
The future of many organisations depends on their ability to harness the power of project management,
and good project managers continue to be in high demand (Larson and Gray, 2017). Educational
institutions have responded to this need by establishing courses in project management and making
them part of the information technology, management, engineering, and other curriculums.
Corporations are investing in continuing education to help develop effective project managers and
project teams.
Today’s companies, governments, and non-profit organisations are recognizing that to be successful,
they need to be conversant with and use modern project management techniques. Individuals are
realizing that to remain competitive in the workplace, they must develop skills to become good project
team members and project managers. They also realize that many of the concepts of project
management will help them in their everyday lives as they work with people and technology on a day-
to-day basis (Schwalbe, 2017).
This chapter introduces projects and project management, explains how projects fit into programs and
portfolio management, discusses the role of the project manager, and provides important background

information on this growing profession in terms of the project management framework that integrates
the knowledge areas with the project life cycle.
2.2 Importance of Project Management

2.2.1 Why is project management important?
Project management as a management discipline underpins much economic activity. In industries as
diverse as pharmaceuticals, software and aerospace, projects drive business. And in the public sector,
it is effective project management that translates politicians' promises of new roads, schools and
hospitals into gleaming new constructions that improve everyday life (Wheatley, 2017).
Without it, teams and clients are exposed to chaotic management, unclear objectives, a lack of
resources, unrealistic planning, high risk, poor quality deliverables, projects going over budget and late
delivery. Project management is important because it delivers success. Project management creates
and enables happy, motivated teams who know their work matters, and therefore do their best to
deliver beyond customer expectations which is the real return on investment – making happy clients.
Great project management means much more than keeping project management’s iron triangle in
check, delivering on time, budget, and scope; it unites clients and teams, creates a vision for success
and gets everyone on the same page of what’s needed to stay on track for success. When projects are
managed properly, there’s a positive impact that reverberates beyond delivery of ‘the stuff’ (Aston,
2017).
2.2.2 Project management is important for several reasons

The following intents demonstrate the significance of project management in today’s industry:
 Strategic Alignment  Managing Integration
 Leadership  Managing Change
 Clear Focus & Objectives  Clearing Issues
 Realistic Project Planning  Retaining and Using Knowledge
 Managing Risk  Learning from Success and Failure
 Managing Quality

2.2.2.1 Strategic Alignment

Project management is important because it ensures what is being delivered, is right, and will deliver
real value against the business opportunity (Larson and Gray, 2017). Every client has strategic goals
and the projects that we do for them advance those goals. Project management is important because it
ensures there’s rigor in architecting projects properly so that they fit well within the broader context of
our client’s strategic frameworks. Good project management ensures that the goals of projects closely
align with the strategic goals of the business.
In identifying a solid business case, and being methodical about calculating ROI, project management
becomes important because it can help to ensure that the right thing is delivered, which is going to
deliver real value.
Of course, as projects progress, it is possible that new risks may emerge, that turn into issues or even
the business strategy may change. But a project manager will ensure that the project is part of that
realignment. Project management really matters here because projects that veer off course, or which
fail to adapt to the business needs may end up being expensive and/or unnecessary.
2.2.2.2 Leadership
Project management is important because it brings leadership and direction to projects (Larson and
Gray, 2017). Without project management, a team can be like a ship without a rudder; moving but
without direction, control or purpose. Leadership allows and enables a team to do their best work.
Project management provides leadership and vision, motivation, removing roadblocks, coaching and
inspiring the team to do their best work.
Project managers serve the team but also ensure clear lines of accountability. With a project manager
in place there’s no confusion about who’s in charge and in control of whatever’s going on in a project.
Project managers enforce process and keep everyone on the team in line, because ultimately, they too
carry responsibility for whether the project fails or succeeds.
2.2.2.3 Clear Focus & Objectives

Projects are naturally chaotic (Larson and Gray, 2017). The primary business function of project
management is organizing & planning projects to tame this chaos. It's hard to think of any complex
business endeavour that was ever achieved without organisation & planning. Project management is

The organisation planning and control of projects.
Project management is important because it ensures there’s a proper plan for executing strategic goals.
Where project management is left to the team to work out by themselves, you’ll find teams work without
proper briefs, projects lack focus, can have vague or vague objectives, and leave the team not quite
sure of what they’re supposed to be doing, or why.
Project managers position themselves to prevent such a situation and drive the timely accomplishment
of tasks, by breaking up a project into tasks for their teams (Larson and Gray, 2017). Often, the
foresight to take such an approach is what differentiates good project management from bad. Breaking
up into smaller chunks of work enables teams to remain focused on clear objectives, gear their
efforts towards achieving the ultimate goal through the completion of smaller steps and to quickly
identify risks, since risk management is important in project management.
Often a project’s goals have to change in line with a materializing risk. Again, without dedicated oversite
and management, a project could swiftly falter but good project management (and a good project
manager) is what enables the team to focus, and when necessary refocus, on their objectives.
2.2.2.4 Realistic Project Planning

Project management is important because it ensures proper expectations are set around what can be
delivered, by when, and for how much (Larson and Gray, 2017). Without proper project management,
set budget estimates and project delivery timelines can be over-ambitious or lacking in analogous
estimating insight from similar projects. Ultimately this means without good project management,
projects are delivered late, and over budget.
Effective project managers should be able to negotiate reasonable and achievable deadlines and
milestones across stakeholders, teams, and management. Too often, the urgency placed on delivery
compromises the necessary steps, and ultimately, the quality of the project’s outcome.
We all know that most tasks will take longer than initially anticipated; a good project manager is able to
analyse and balance the available resources within the required timeline, and develop a realistic
schedule. Project management really matters when scheduling because it brings objectivity to the
planning. A good project manager creates a clear process, with achievable deadlines, that enables

everyone within the project team to work within reasonable bounds, and not unreasonable
expectations.
2.2.2.5 Managing Risk

Any good project has plenty of risk (Larson and Gray, 2017). After all, the nature of business is taking
risks. Risk is a fundamental part of business strategy. However, risk needs to be managed. Risk is that
chance of a negative event or loss.
Project management is important because it ensures risks are properly managed and mitigated against
to avoid becoming issues. Risk management is critical to project success. The temptation is just to
sweep them under the carpet, never talk about them to the client and hope for the best. But having a
robust process around the identification, management and mitigation of risk is what helps prevent risks
from becoming issues.
Good project management practice requires project managers to carefully analyse all potential risks to
the project, quantify them, develop a mitigation plan against them, and a contingency plan should any
of them materialize. Naturally, risks should be prioritized according to the likelihood of them occurring,
and appropriate responses are allocated per risk. Project management identifies, manages and
controls risk.
2.2.2.6 Managing Quality

Quality means fulfilling inherent requirements and it is the value of what you produce (Larson and Gray,
2017). There's not much sense producing something that has no value. Quality is seen from two
perspectives. Firstly, it must meet the industry standards. But most important it needs to meet the
customers’ standards. Leaving quality to chance is analogous to producing something of random
value. Project management is important because it ensures the quality of whatever is being delivered,
consistently hits the mark. Projects are also usually under enormous pressure to be completed.
Without a dedicated project manager, who has the support and buy-in of executive management, tasks
are underestimated, schedules tightened and processes rushed. The result is bad quality output.
Dedicated project management ensures that not only does a project have the time and resources to
deliver, but also that the output is quality tested at every stage. Project management identifies,
manages and controls quality.

Good project management demands gated phases where teams can assess the output for quality,
applicability, and ROI. Project management is of key importance to Quality Assurance because it allows
for a staggered and phased process, creating time for teams to examine and test their outputs at every
step along the way.
2.2.2.7 Managing Integration

Projects don't happen in a vacuum (Larson and Gray, 2017). They need to be integrated with business
processes, systems and organisations. You can't build a sales system that doesn't integrate with your
sales process and sales organisation. It wouldn't add much value. Integration is often key to project
value. Project management is important because it ensures a project’s progress is tracked and
reported properly.
Status reporting might sound boring and unnecessary – and if everything’s going to plan, it can just feel
like documentation for documentation’s sake. But continuous project monitoring, ensuring that a project
is tracking properly against the original plan, is critical to ensuring that a project stays on track.
When proper management and project reporting is in place it makes it easy to see when a project is
beginning to deviate from its intended course. The earlier you’re able to spot project deviation, the
easier it is to course correct.
Good project managers will regularly generate easily digestible progress or status reports that enable
stakeholders to track the project. Typically, these status reports will provide insights into the work that
was completed and planned, the hours utilized and how they track against those planned, how the
project is tracking against milestones, risks, assumptions, issues and dependencies and any outputs of
the project as it proceeds. This data is invaluable not only for tracking progress but helps clients gain
the trust of other stakeholders in their organisation, giving them an easy overview of a project’s
progress. Project management identifies and manages integration (Larson and Gray, 2017).
2.2.2.8 Managing Change

Projects always happen in an environment in which nothing is constant except change (Larson and
Gray, 2017). Projects are always a moving target. Managing change is a complex and daunting task.
It's not optional. Unless you can put your business universe on pause, change happens whether you
manage it or not. Project management manages change.

2.2.2.9 Clearing Issues

Business initiatives typically encounter regular issues that must be managed to achieve objectives
(Larson and Gray, 2017).
Project management plays a critical role in identifying and clearing issues.
2.2.2.10 Retaining and Using Knowledge

Projects generate knowledge. Knowledge represents a significant asset for most businesses. Left
unmanaged, knowledge tends to quickly fade. Project management ensures that project knowledge is
captured and managed.
2.2.2.11 Learning from Success and Failure

Projects fail and when they do, it's important to learn from the process. Learning from failure is key
to business innovation and quality improvement. Project management is important because it learns
from the successes and failures of the past.
Project management can break bad habits and when you’re delivering projects, it’s important to not
make the same mistake twice. Project managers use retrospectives or post project reviews to consider
what went well, what didn’t go so well and what should be done differently for the next project.
This produces a valuable set of documentation that becomes a record of “do's and don’ts” going
forward, enabling the organisation to learn from failures and success. Without this learning, teams will
often keep making the same mistakes, time and time again. These retrospectives are great documents
to use at a project kick-off meeting to remind the team about failures such as underestimating projects,
and successes such as the benefits of a solid process or the importance of keeping time sheet
reporting up to date! Project management ensures that lessons are learned from project success and
failure (Mar, 2012).
2.2.3 Benefits of Project Management

Organisations should consider using project management techniques in their business for the following
reasons (Mar, 2012):
 providing a greater likelihood of achieving the desired result;
 ensuring efficient and best value use of resources;
 Satisfying the differing needs of the project’s stakeholders.

 Better control of financial, physical, and human resources

 Improved customer relations
 Shorter development times
 Lower costs and improved productivity
 Higher quality and increased reliability
 Higher profit margins
 Better internal coordination
 Positive impact on meeting strategic goals\
 Higher worker morale
2.3 Project Management

2.3.1 What is a project?
According to PMI (2013, 3), “A project is a temporary endeavour undertaken to create a unique product,
service or result”.
This definition has several different components that need to be examined more closely in order to get
an accurate view of what constitutes a project.
 A project is temporary in that it has a defined beginning and end in time, and therefore defined
scope and resources.
 A project is unique in that it is not a routine operation, but a specific set of operations designed
to accomplish a singular goal. Therefore, a project team often includes people who don’t
usually work together – and are sometimes from different organisations and across multiple
geographies.

The development of software for an improved business process, the construction of a building or
bridge, the relief effort after a natural disaster, the expansion of sales into a new geographic market all
are projects. And all must be expertly managed to deliver safely, on-time, on-budget results, and within
the quality specifications and the integration that organisations need.
2.3.2 Project Attributes

All projects have some elements in common and, according to Pycraft et al. (2010:464), these include:
 An objective. A definable end result, output or product, which is defined in terms of cost, quality
and timing.
 Complexity. Several tasks are required to be undertaken to achieve the objectives. The
relationship between all these tasks can be extremely complex.
 Uniqueness. A project is usually a one-off undertaking.
 Uncertainty. As all projects are planned before they are executed, they carry a certain amount
of risk.
 Life cycle. Projects normally go through four phases – initiation, planning, execution and phase-
out.
 Temporary nature. Resources may be moved from one project to the next once the tasks have
been completed
.
2.3.3 Examples of Projects
Examples of projects include, but are not limited to (PMI, 2013).:
 Developing a new product, service or result;
 Effecting a change in the structure, processes, staffing or style of an organisation;
 Developing or acquiring a new or modified information system (hardware or software);
 Conducting a research effort whose outcome will be appropriately recorded;
 Constructing a building, industrial plant, or infrastructure; or
 Implementing, improving or enhancing existing business processes and procedures
2.3.4 Differentiating Between Projects, Programmes and Portfolios

Two important concepts that help projects meet enterprise goals are the use of programs and
portfolios. Figure 2.1 below shows the alignment between portfolio, programme and project
management.

Figure 2.1: Portfolio, Programme and Project Management Alignment
Strategic • Doing the RIGHT THING

• Strategic Alignment
Level • Governance
• Risk
(Business Value)
• Resource
Benefit Level • Realising the BENEFITS

• Verification & Validation
(Stakeholder Value) • Prioritisation
• Resource
Deleivery • Doing THINGS RIGHT

• Scope
Level • Cost
(Quality • Time
Deleiverables) • Quality
Projects, programmes and portfolios are tactics used by organisations to implement their corporate and
business strategies. The objective of programmes and portfolios is to breakdown business strategies
into manageable chunks so that specific resources can be allocated to them. Following that,
Programme Managers and Portfolio Managers are assigned to take charge of these initiatives.

A programme is a group of related projects clustered together with the programme manager taking
overall group management responsibility. Programmes use a co-ordinated approach to manage
projects and they exploit resource synergies across the projects, thereby reducing the overall costs. An
example of a programme is the South African government’s infrastructural group of projects. The group
consists of various tar road upgrades across the country. These projects have separate project teams
including separate contractors, however they are managed as a programme because they are inter-
related (Schwalbe, 2009:14).
A portfolio is a collection of projects or programs and other work that are grouped together to facilitate
effective management of that work to meet strategic business objectives (PMBOK Guide, 2004:16).
The projects or programmes in a portfolio may not necessarily be related or inter-dependent. Portfolio
managers must always ensure that projects and programmes included in a portfolio support the
business strategy and improves profitability of an organisation. Portfolio managers are likely to be
senior managers or senior management teams and they focus on the big picture of the organisation.
Project, program, and portfolio management aren’t the same (PMBOK Guide, 2004:16). Table 2.1
illustrates their differences against various criteria. It is key however, that they work together. To be
effective, a portfolio manager should understand what project management is. This allows the portfolio
manager to ask the right questions of the program and project managers and interpret the information
in the most effective way, so that the portfolio strategy is well thought out.
With portfolio management, the organisation is making sure that projects align to business strategies so
it’s clear why particular work being done. To remain objective, it’s key that standards are developed for
how projects are moved into and out of the portfolio. From the project and program management
perspective, it’s key that the plans are correct and communicated clearly to enable effective decision-
making within the portfolio.

DIFFERENTIATING PROJECTS PROGRAMMESS PORTFOLIO

CRITERIA
Definition A temporary endeavour A group of related projects managed in A collection of projects or

undertaken to create a unique a coordinated way to obtain benefits programs and other work that are
product, service or result and control not available from grouped together to facilitate
managing them individually effective management of that work
to meet strategic business
objectives
Example Integration of HR system with IT Transformation program NASA’s space program

Oracle apps
Scope Have defined objectives & Wider scope compared to projects & Scope driven by strategic business
scope is progressively more focused on the benefits objective that portfolio is created to
elaborated during project life address
cycle
Success criteria Measured by product & project Measured by degree to which program Measured in terms of aggregate
quality, timeliness, budget satisfies the needs & benefits for which performance of portfolio
compliance, & degree of it was undertaken components & long term value
customer satisfaction creation to investors &
stakeholders
Schedule Time taken to create Aggregation of the schedule of the No schedule. Individual program/
deliverables expected of the program components projects that facilitate achieving the
project business objectives will have their
respective schedules
Risk Management Risks typically considered as Risks considered as opportunities but Risks considered as deviation from
threats sometimes as threats too stakeholder expectations &
managed through portfolio balance
Monitoring and Project manager directly Program manager uses program Portfolio manager monitors
Control monitors & controls activities & governance mechanism for monitoring aggregated performance & value
deliverables & control indicators
Leadership style Mainly execution oriented, Program manager is the leader with Portfolio managers add value to
Project manager is part of the the vision & aids in relationship & the portfolio decisions
team conflict management
Table 2.1: Comparative Overview of Project, Programme and Portfolio Management

2.3.5 What is Project Management?

PMI (2013: 5) defines Project Management as “the application of knowledge, skills, tools and
techniques to project activities to meet the project requirements”. Project managers must not only
strive to meet specific scope, time, cost, and quality requirements of projects, they must also facilitate
the entire process to meet the needs and expectations of the people involved in or affected by project
activities. Due to time-based competition and a quality mandate in current business, the value of
project management as a strategic asset is realised.
Project management is accomplished through the project management framework which advocates
“the appropriate application and integration of” the TEN project management knowledge areas across
the FIVE project management process groups of the project life cycle (PMI, 2013).
Table 2.2 illustrates the mapping of the knowledge areas with the process groups. This mapping
constitutes the project management framework. The integrated Project Management Framework is
intended to add value to the organisation by outlining a body of knowledge, processes, skills, tools, and
techniques that, when used, will improve the organisation’s performance in conducting its work. The ten
project management knowledge areas and the project management process groups will be discussed
in further detail.
PROJECT MANAGEMENT PROCESS GROUPS
KNOWLEDGE
Monitoring &
AREAS Initiating Planning Executing Closing
Controlling
Project Develop Develop Project Direct & Manage Project  Monitor & Close Project
Project Management Plan Work Control or Phase
Integration
Charter Project Work
Management
 Perform
Integrated
Change
Control
Project Scope  Plan Scope  Validate
Management Scope
Management
 Collect  Control
Requirements Scope
 Define Scope
 Create WBS
Project Time  Plan Schedule Control Schedule
Management
Management
 Define

Activities
 Sequence
Activities
 Estimate
Activity
Resources
 Estimate
Activity
Durations
 Develop
Schedule
Project Cost  Plan Cost Control Costs
Management
Management
 Estimate Costs
 Determine
Budget
Project Quality Plan Quality Management Perform Quality Control Quality
Assurance
Management
Project Human  Plan Human  Acquire
Resource Resource Project Team

Management  Develop
Management
Project Team
 Manage
Project Team
Project Plan Communications Manage Control
Management Communications Communications
Communicatio
n Management
Project Risk  Plan Risk
Management
Management
 Identify Risks
 Perform
Qualitative
Risk Analysis
 Perform
Quantitative
Risk Analysis
Plan Risk
Responses
Project Plan Procurement Conduct Procurements Control Procurements Close
Management Procurement
Procurement
s
management

Project Identify Plan Stakeholder Manage Control Stakeholder

Stakeholder Management Stakeholder Engagement
Stakeholder
s Engagement
Management
Table 2.2: Mapping of the Project Management Process Groups and Knowledge Areas
Source: Adapted from PMI (2013)
2.4 Project Management Knowledge Areas

In order to manage a project, PMBOK (PMI, 2013) defines the basic knowledge areas a project
manager should understand. These knowledge areas are the method the PMBOK uses to categorize
areas of expertise required to successfully manage and complete projects.
Figure 2.2: Ten Project Management Knowledge Areas

Source: Srinivasan (2010)

Figure 2.2 highlights all ten knowledge areas together with their associated processes. A description of
each knowledge area is as follows:
 Managing integration: Project elements, such as Scope, Schedule, Cost, Risk, and Quality,
are inter-dependent. Making a small change in one of these could have a big impact in other
parts of your project. Project Integration is what you do to coordinate these elements and
make trade-offs in order to achieve your project objectives. Project Integration Management
includes those processes required to ensure that the various elements of the project are
properly coordinated.
 Managing scope: Projects need to have a defined parameter or scope, and this must be
broken down and managed through a work breakdown structure or WBS. Managing scope is
about planning, definition, WBS creation, verification, and control.
 Managing time/schedule: Projects have a definite beginning and a definite ending date.
Therefore, there is a need to manage the budgeted time according to a project
schedule. Managing time/schedule is about definition, sequencing, resource and duration
estimating, schedule development, and schedule control.
 Managing costs: Projects consume resources, and therefore, there is a need to manage the
investment with the realization of creating value (i.e., the benefits derived exceed the amount
spent). Managing costs is about resource planning, cost estimating, budgeting, and control.
 Managing quality: Projects involve specific deliverables or work products. These deliverables
need to meet project objectives and performance standards. Managing quality is about quality
planning, quality assurance, and quality control.
 Managing human resources: Projects consist of teams and you need to manage project
team(s) during the life cycle of the project. Finding the right people, managing their outputs,
and keeping them on schedule is a big part of managing a project. Managing human resources
is about human resources planning, hiring, and developing and managing a project team.
 Managing communication: Projects invariably touch lots of people, not just the end users
(customers) who benefit directly from the project outcomes. This can include project
participants, managers who oversee the project, and external stakeholders who have an
interest in the success of the project. Managing communication is about communications
planning, information distribution, performance reporting, and stakeholder management.
 Managing risk: Projects are a discovery-driven process, often uncovering new customer
needs and identifying critical issues not previously disclosed. Projects also encounter

unexpected events, such as project team members resigning, budgeted resources suddenly
changing, the organisation becoming unstable, and newer technologies being introduced.
There is a real need to properly identify various risks and manage these risks. Managing risk is
about risk planning and identification, risk analysis (qualitative and quantitative), risk response
(action) planning, and risk monitoring and control.
 Managing procurement: Projects procure the services of outside vendors and contractors,
including the purchase of equipment. There is a need to manage how vendors are selected and
managed within the project life cycle. Managing procurement is about acquisition and
contracting plans, sellers’ responses and selections, contract administration, and contract
closure.
 Managing stakeholders: Every project impacts people and organisations and is impacted by
people and organisations. Identifying these stakeholders early, and as they arise and change
throughout the project, is a key success factor. Managing stakeholders is about identifying
stakeholders, their interest level, and their potential to influence the project; and managing and
controlling the relationships and communications between stakeholders and the project.
Effectiveness in managing projects is dependent upon a project manager’s effectiveness in managing

each of the 10 knowledge areas.
2.5 Project Management Process Groups: Project Cycle

While no two projects are exactly alike, all projects should progress through the same five project
management phases (or process groups), initiating, planning, executing, monitoring and controlling,
and closing (Larson and Gray, 2017). There is a slight distinction between the project life cycle (See
Figure 2.3) and the process groups where the project life cycle constitutes all of the process groups
except for monitoring and controlling.

Figure 2.3 The Project Life Cycle

2.5.1 Initiation
The Initiation Phase consists of the processes that facilitate the formal authorisation to start a new
project or a project phase (Larson and Gray, 2017). Initiation processes are often performed by the
performing organisation outside of the strict project boundaries. For example, before project initiation,
the organisation’s business needs are identified and documented. As a next step the feasibility of a new
project may be established through a process of evaluating alternatives documented in a formal
feasibility study. The documentation for this decision might also contain a brief presentation of the
project scope, its deliverables, duration, resource requirements and investment estimation.
During the Initiation Phase, the initial scope of the project and the resource requirements are further
refined. Initial assumptions and constraints are also documented and the other project related elements
(such as deliverables, schedule, etc.) are refined and undergo minor modifications to best fit the
business and project needs.
Additionally, during the Initiation Phase, a large and complex project may be decided to be split into
phases, so as to be more manageable and produce intermediate outputs or results.

2.5.2 Planning
During the Planning Phase, information is gathered from many sources with each having varying levels
of completeness and confidence. The planning processes identify, define and mature the project scope,
project cost, and schedule the project activities. As new project information is discovered, additional
dependencies, requirements, risks, opportunities, assumptions and constraints will be identified or
resolved. As more project information or characteristics are gathered and understood, follow-on actions
may be required. Significant changes occurring throughout the project life cycle trigger a need to revisit
one or more of the planning processes and, possibly, some of the initiation processes.
The planning phase is iterative. Initially it gives emphasis on exploring all aspects of the scope,
technology, risks, schedule and costs. Updates arising from approved changes during project execution
may significantly impact parts of planning. As a result, greater precision will be put into planning for all
aspects of a project (i.e. schedule, costs, resources, etc.) to meet the defined project scope as a whole.
This progressive detailing is often called “rolling wave planning” showing that planning is an iterative
and ongoing process.
During planning all appropriate stakeholders should be involved, depending on their influence on the
project and its outcomes.
2.5.3 Execution
The Execution Phase aims at completing the work defined during the Planning Phase to accomplish the
project’s requirements. This phase involves coordinating people and resources, as well as integrating
and performing the activities of the project in accordance with the plan. This phase also addresses the
project scope that has already been defined and implements approved changes.
Normal execution variances cause some re-planning of the work. These variances may include activity
durations, resource productivity and availability, and unanticipated risks. Such variances may or may
not affect the planning of the project but require some analysis. The result of this analysis can trigger a
change request that, if approved, might modify project planning.

2.5.4 Monitoring and Control

This project function within the project life cycle, is related to observing project execution so that
potential problems can be identified in a timely manner and corrective action can be taken, when
necessary, to control the execution of a project.
The key benefit of this phase is that project performance is observed and measured regularly to identify
variances from planning. This phase also includes controlling changes and recommending preventing
actions in anticipation of possible problems. This phase includes, for example:
 Monitoring the ongoing project activities against planning and project performance indicators;
 Influencing the factors that could circumvent integrated change control so that only approved
changes are implemented.
This continuous monitoring provides the project team insight into the health of the project and highlights
any areas that require additional attention. When variances jeopardize the project’s objectives,
appropriate processes within the Planning Phase are revisited. This review can result in recommended
updates to the planning of the project.
2.5.5 Closure
Closing includes three activities: delivering the project product to the customer, redeploying project
resources, and post-project review. Delivery of the project might include customer training and
transferring documents. Redeployment usually involves releasing project equipment/materials to other
projects and finding new assignments for team members. Post-project reviews include not only
assessing performance but also capturing lessons learned.
2.5.6 Example of a Project Life Cycle

 Starting the Project:
Example Activities: Developing the project charter, authorizing memo or email, obtaining output from
another project, formulating service agreements, etc.
Example Outputs: Project charter developed, including designation of project manager, identification of
project category (Basic, Standard, Complex, or Complex), and preliminary project cost estimate.
Example Milestones: Review of project charter, decisions, and preliminary costs. Go/no-go decision made
to proceed to next phase of project.

 Organizing and Preparing:

Example Activities: Preparing the PMP, appraisal study, feasibility study, planning study, value planning
study, etc.
Example Outputs: Signed PMP, environmental and other required processes and permits, appraisal
design, feasibility design, final design, and significant acquisitions/procurement events.
Example Milestones: Milestone review of outputs, authorization of recommendations, and approval to move
to next phase.
 Carrying Out the Work:
Example Activities: Executing work orders, design, acquisition, delivery, construction, etc.
Example Outputs: Product or system, results, and documentation that work is complete.
Example Milestones: Review of deliverables and artefacts, and construction or delivery results. Authority to
proceed to deployment, operations, or operation and maintenance.
 Closing the Project:

Example Activities: Review and approval of deliverables, developing delivery memo and other final
reports, commissioning, transfer of facilities, as-built drawings, Standing Operating Procedures, manuals,
contract closeout, and closeout report.
Example Outputs: Closeout report completed, lessons learned, and team closure.
Example Milestones: Post Implementation Review, Termination/Change Review, Decommissioning, or
Succession Review.
2.6 The Triple Constraints

Specific time, cost, and performance requirements bind projects. Projects are evaluated according to
accomplishment, cost, and time spent. These triple constraints impose a higher degree of
accountability than you typically find in most jobs. These three also highlight one of the primary
functions of project management, which is balancing the trade-offs between time, cost, and
performance while ultimately satisfying the customer.
Every project is constrained in different ways by its scope, time, and cost goals. These limitations are
sometimes referred to in project management as the triple constraint. To create a successful project, a
project manager must consider scope, time, and cost and balance these three often-competing goals.
He or she must consider the following:

 Scope: What work will be done as part of the project? What unique product, service, or result
does the customer or sponsor expect from the project? How will the scope be verified?
 Time: How long should it take to complete the project? What is the project’s schedule?
How will the team track actual schedule performance? Who can approve changes to the schedule?
 Cost: What should it cost to complete the project? What is the project s budget? How will costs
be tracked? Who can authorise changes to the budget?
Figure 2.4 illustrates the three dimensions of the triple constraint. Each area scope, time, and cost have
a target at the beginning of the project. Because projects involve uncertainty and limited resources,
projects rarely finish according to discrete scope, time, and cost goals originally planned. Instead of
discrete target goals, it is often more realistic to set a range of goals.
Managing the triple constraint involves making trade-offs between scope, time, and cost goals for a
project (Gido and Clements, 2015). For example, you might need to increase the budget for a project to
meet scope and time goals. Alternatively, you might have to reduce the scope of a project to meet time
and cost goals. Experienced project managers know that you must decide which aspect of the triple
constraint is most important. If time is most important, you must often change the initial scope and/or
cost goals to meet the schedule. If scope goals are most important, you may need to adjust time and/or
cost goals.
Figure 2.4: The Project Management Triple Constraint
Although the triple constraint describes how the basic elements of a project scope, time, and cost
interrelate, other elements can also play significant roles (Gido and Clements, 2015). Quality is often a
key factor in projects, as is customer or sponsor satisfaction. It is often referred to as the fourth

constraint of project management. Others believe that quality considerations, including customer
satisfaction, must be inherent in setting the scope, time, and cost goals of a project. A project team may
meet scope, time, and cost goals but fail to meet quality standards or satisfy their sponsor, if they have
not adequately addressed these concerns. For example, Dean Winchester may receive a 50-page
report describing 30 potential information technology projects and hear a presentation on the findings of
the report. The project team may have completed the work on time and within the cost constraint, but
the quality may have been unacceptable. Dean’s view of an executive presentation may be very
different from the project teams’ view. The project manager should be communicating with the sponsor
throughout the project to make sure the project meets his or her expectations.
Here are some examples:

 During a project to create a new mobile phone handset, your customer asks that the launch
date is brought forward two weeks to coincide with a major industry show.
Impact: Costs increase as more people are added to meet the new deadline. Some features of the
product are removed and put into a phase two release to reduce delivery time and meet the new launch
date. The most significant constraint, in this case, is time (project schedule).
 During an automotive engineering project, an unexpected budget cut is imposed on your
project after the company posts poorer than expected 4th quarter financial results.
Impact: Scope is cut, quality is reduced, and the schedule is pushed back so that cheaper resources
can be found. The most significant constraint, in this case, is the cost (the money the company is willing
to spend).
 During a software development project, your customer increases the scope. The client asks
that new features be added to the software after learning that a competitor's product will be in
direct competition with their own. It is important the product includes these new features if it is
to compete successfully.
Impact: The budget and schedule increase as a result of pushing up the final delivery date. More
people are added to minimise disruption to the project schedule, thereby increasing the project's overall
cost. The most significant constraint, in this case, is scope (features of the product).
In each of these examples, it is the project manager who needs to rebalance the project to meet new
constraints and deliver success for the customer. More often, a project manager needs to weigh one

constraint against another to reach the best result. As a project manager, you need to educate your
customers about project management's triple constraint, create the best balance, and be aware of all
changes that will impact cost, time, and scope. The triple constraint represents key elements of a
project that, when balanced well, lead to success.
Think Point Is the triple constraint still relevant?
2.7 The Project Manager

Project managers perform the same functions as other managers. They plan, schedule, motivate, and
control resources. However, what makes them unique is that they manage temporary, non-repetitive
activities, to complete a fixed life project. Unlike functional managers, who take over existing
operations, project managers create a project team and organisation where none existed before. They
must decide what and how things should be done instead of simply managing set processes. They
must meet the challenges of each phase of the project life cycle, and even oversee the dissolution of
their operation when the project is completed.
Project managers provide direction, coordination, and integration to the project team, which is often
made up of part-time participants loyal to their functional departments. They often must work with a
team of outsiders—vendors, suppliers, subcontractors—who do not necessarily share their project
commitment.
Project managers are ultimately responsible for performance (frequently with too little authority). They
must ensure that appropriate trade-offs are made between the time, cost, and performance
requirements of the project in a safe working environment. At the same time, unlike their functional
counterparts, project managers generally possess only rudimentary technical knowledge to make such
decisions. Instead, they must orchestrate the completion of the project by inducing the right people, at
the right time, to address the right issues and make the right decisions.
While project management is not for the faint-hearted, working on projects can be an extremely
rewarding experience. Life on projects is rarely boring; each day is different from the last. Since most
projects are directed at solving some tangible problem or pursuing some useful opportunity, project

managers find their work personally meaningful and satisfying. Good project managers are always in
demand. Every industry is looking for effective people who can get the right things done on time.
2.7.1 Portfolio of Skills of a Project Manager

It is the project manager’s leadership responsibility to:
 Lead the generation of entrepreneurial and innovative ideas, spot opportunities and respond to
competition.
 Lead the technical design and development of the product and incorporate new technology.
 Oversee the project management planning and control process
 Negotiate for project resources and inspire the project team (Burke and Barron, 2007).
Figure 2.5 clearly outlines the various skills project managers require in order to successfully lead
projects. The project manager needs technical skills together with product knowledge to design and
make the project or product. Project management skills are needed to set up the project management
system to plan and control the project through the project life cycle. Leadership skills are needed to
coordinate and lead the project participants together with the vision, strategy and determination to drive
the project – to motivate and inspire the team to deliver on project deliverables. Finally, the project
manager needs entrepreneurial skills to spot and exploit marketable opportunities, to find innovative
solutions to company problems, together with networking skills to communicate with a wide range of
useful contacts and stakeholders.
PROJECT
MANAGER
Technical Project Project Project

Management Management Leadership Entrepreneurship
Spot
Technical Skills Plan & Control Vision
Opportunities
Product Scope
Strategy Solve problems
Knowledge Management
Communication Team building Networking
Figure 2.5: Portfolio of Skills of a Project Manager

Source: Adapted from Burke and Barron (2007)

2.7.2 Leadership Techniques for Project Managers

"Leadership appears to be the art of getting others to want to do something you are convinced
should be done." This is an interesting definition of leadership by Vance Packard, an American
journalist, social critic and author (Forbes, 2017).
As a project manager, have you ever felt that even though you are doing everything "right" people are
still not paying attention to your project? Or, that even though you manage an effort, others appear to
have a stronger influence over what happens? Or, wondering what combination of skills makes a
project manager a more effective leader?
As project managers, we are trained to control the three key project influences of scope, schedule and
budget, and to understand the nuances of team dynamics. Some would say that we are fanatic about
driving productivity and meeting schedule commitments. Other project managers embody all that, but
they have something more going for them. They have an uncanny ability to spot red flags, they are
zealous communicators, and well respected by peers and business leads. They demonstrate an ability
to balance what needs to be done, as driven from the plan, with what should be done to meet the
business need, even if it is counter intuitive to the project roadmap. These are the project managers
that instil confidence, who are invited to participate in business discussions, and asked to weigh in at
the project inception stage. What separates these project managers is that they not only manage, but
that they also lead (Cooper, 2017).
What then are some of the essential behaviours that are associated with leaders? Here are four
leadership traits that, when combined with a project management skill set, can really elevate your
game:
 Demonstrates a passion for learning: Learning means staying relevant. Learning means
having new ideas that may challenge the status quo. Being curious means you are asking
questions, connecting the dots, gaining insight, getting beyond the superficial, and getting a
knowledge base that positions you as a go-to person. Each project brings learning, and those
mindful know how to leverage their successes and failures in the next project. The benefits of
your experience become tangible assets in every project.

 Demonstrates a personal commitment to success: Commitment fuels accountability which

translates into proactive behaviours. For a project manager, this means a willingness to
advocate at all levels, whether it is helping the team get unstuck, finding out what motivates an
individual and providing it, or empowering stakeholders whose contributions are vital but who
would otherwise not have a voice in decisions. It is an expectation of accountability in others,
and the willingness to address a lack of commitment, but with compassion first. In other words,
you operate in a manner that suggests there is always a way to solve an issue, that you are
willing to work with anyone to help resolve it, but you are always calibrating with the end goal in
mind.
 Takes calculated risks: Risks are uncertain events that could have a positive or negative
effect on your career and in your projects. As project managers, we often focus on mitigating
risk, but tend to forget that there is the opportunity aspect of risk. Taking a calculated risk
means you've weighed the costs of failure against the benefits of success and have chosen to
move forward. Have you ever volunteered to work in another area of the business, or on a
project outside your comfort zone, because you wanted to stretch yourself? You face a hit to
your reputation, or maybe a longer work day, but the reward is that (combined with your
passion to learn and commitment to success) you gain more experience and become even
more valuable to the business. A calculated risk in a project context is to try a new technology
or to mentor a less talented team member, knowing that it could slow things down or require
additional costs, but the end result, if successful, will benefit both the current project and future
projects; that you've created more assets for the business. Bottom line, you are willing to go
outside your comfort zone for a better result.
 Delegates effectively: Delegating effectively creates an atmosphere of enablement. You are
able to focus on higher level project management activities and your team is empowered to
make significant contributions. To delegate effectively you must be able to assign work and
create an obligation to perform. How is that done? You are clear about overall purpose of the
task, the outcome, and ask (versus dictate) an estimate to complete. Based on a mutual
agreement on deadlines, you identify when you want progress updates. Most importantly,
based on the experience and comfort-level of the team member, you agree on what level of
autonomy is required. In developing high performing teams, the goal for the project manager is
to become less directive and more facilitative — giving the team more and more capability to
self-manage.

Think Point What exactly distinguishes leaders from managers?
2.7.3 Managing Versus Leading

Project management and leadership are two sides of the same coin (Burke and Barron, 2007). They
are inter-linked and need to be if a project is to be delivered on time, to budget and to the desired
quality. However, too many project managers place too much attention on managing and too little time
on leading. As with everything in life, finding the right balance is the key.
Management and leadership are functional roles with specific activities, while managing and leading
are processes with specific sets of skills and clusters of competencies. Project management leadership
focuses on the human side of project management, and the leadership skills that the project manager
needs to manage the project team and other stakeholders. Besides project management skills, the
project manager also needs leadership skills to negotiate, motivate and inspire the team members, both
individually and collectively. However, the project manager’s challenges do not end there, the project
manager also has to manage and lead all the other project stakeholders.
Figure 2.6: The Differences between a Leader and a Manager

There have been two major changes in the project environment in recent years which have motivated
significant changes in the project manager’s leadership style (Gido and Clements, 2015). The
introduction of project teams working within a matrix organisation breakdown structure, and a general
increase in the workforce’s level of education and ability. The organisational changes mean project
managers may not have the full line authority over the resources they need to carry out the work.
Project managers must, therefore develop negotiation and networking skills to enable them to obtain
labour and equipment from the resource providers.
The other factor motivating a change in leadership style is the ability of the workforce who are now
better educated, more experienced, more competent and more articulate. This greater competency has
led to greater expectations and demands to have a greater say in their working environment, and they
also are quite prepared to question their leader’s instructions.
These two factors have alone encouraged a dramatic change from the command and control
leadership style of yesteryear to a more participative and collaborative approach. Leadership is
required to effectively motivate employees.
2.7.4 Incorporating Leadership Behaviours into Project Management Methodology

Project managers worry about loss of control, mistakes, and missed deadlines. Their days are spent in
details whether planning, organizing, or problem solving. So how do you incorporate leadership
behaviours which emphasize direction setting, alignment, and motivating? Here are some ideas for
how to infuse active leadership into your project management methodology:
 Leadership goal: Keeping your project in sync and visible within overall organisational
priorities.
Initiate: Understand and communicate your project's alignment to the business strategy.
Plan: Be mindful of your stakeholders. Truly understand how to satisfy their expectations for
success.
Execute/Control: Focus on delegation techniques and relationships with functional managers.

Close: Audit the project and maintain metrics for how it met the business goal.
 Leadership goal: Create a public relations campaign for the project.
Initiate: Develop top management support and keep them informed.

 Plan: Plan for rewards and visibility to motivate all participants.

Execute/Control: Be mindful of team morale and actively manage perceptions.
Close: Celebrate project completion and share the success story.
 Leadership goal: Create a high performing project team.

Initiate: Establish excitement for the project and be sure to focus on stakeholder
inclusion activity.
Plan: Focus on a mix of skill sets, a work environment that emphasizes collaboration, and a
communications plan that highlights team contributions.
Execute/Control: Establish team operating methods early on, reinforce positive team
behaviours, proactively manage conflict.
Close: Reward and recognize positive contributions to the team.
Above and beyond getting the project done, project leaders are mindful of sharing a vision, empowering
others, modelling the way, being integrative, and balancing what's required by a schedule with what's
practical in view of the larger goal. Successful project managers have the ability to demonstrate the
unbiased fairness of a judge, the skills of a diplomat, the authority of a general and the understanding
of a parent (McNamara, 2003).
2.8 An Integrative Approach

Organisations manage more and more projects as a result of global competition influenced by rapid
change, innovation, and time to market means. This has led to a specific need for a means to
coordinate and manage projects in changing environments. Established companies like Dell, IBM,
Hewlett-Packard, and Intel all have over 1,000 projects being implemented concurrently every day of
the year across borders and differing cultures. The questions raised include: “How do these
organisations oversee the management of all these projects? How were these projects selected? How
do they ensure performance measurement and accountability? How can project management
continually improve? Centralization entails integration of all project processes and practices to improve
project management (Larson and Gray, 2017).
The rationale for integration of project management was to provide senior management with:

 An overview of all project management activities;

 A big picture of how organisational resources are being used;
 An assessment of the risk their portfolio of projects represents;
 A rough metric for measuring the improvement of managing projects relative to others in the
industry;
 Linkages of senior management with actual project execution management (Larson and Gray,
2017).
Integration enables management to have greater flexibility and better control of all project management
activities. Full insight of all components of the organisation is crucial for aligning internal business
resources with the requirements of the changing environment.
What does project management integration mean operationally? The major dimensions of project
management are combined under one umbrella. Integration means applying a set of knowledge, skills,
tools, and techniques to a collection of projects in order to move the organisation toward its strategic
goals.
2.8.1 Integration of Projects with Organisational Strategy

Since projects have become the modus operandi of strategic management, strategic alignment of
projects is of major importance to conserving and effective use of organisation resources (Larson and
Gray, 2017). Selection criteria need to ensure each project is prioritized and contributes to strategic
goals. Anything less is a waste of scarce organisational resources—people, capital, and equipment. All
selected projects become part of a project portfolio that balances the total risk for the organisation.
Management of the project portfolio ensures that only the most valuable projects are approved and
managed across the entire organisation.
2.8.2 Integration of Projects through Portfolio Management

Full insight of all components of the organisation is crucial for aligning internal business resources with
the requirements of the changing environment. Project portfolios are frequently managed by a project
office that serves as a bridge between senior management and project managers and teams. The
major functions of portfolio management are to:
 Oversee project selection.

 Monitor aggregate resource levels and skills.

 Encourage use of best practices.
 Balance projects in the portfolio in order to represent a risk level appropriate to the
organisation.
 Improve communication among all stakeholders.

 Create a total organisation perspective that goes beyond silo thinking.
 Improve the overall management of projects over time.
 Portfolio management manages the integration of elements of organisational strategy with
projects, along with their interdependencies. At the project level, the management of the
portfolio is directed toward creation and use of best practices.
2.8.3 Integration of the Processes of Implementing Actual Projects

Implementing the project is the challenge. There are two dimensions within the actual execution of
projects: Technical and Sociocultural dimensions (Larson and Gray, 2017). The technical side of the
management process, consists of the formal, disciplined, logical parts of the process. This technical
dimension includes planning, scheduling, and controlling projects. Clear project scope statements are
written to link the project and customer and to facilitate planning and control. Creation of the
deliverables and work breakdown structures facilitates planning and monitoring the progress of the
project. The work breakdown structure serves as a database that links all levels in the organisation,
major deliverables, and all work—right down to the tasks in a work package. Effects of project changes
are documented and traceable. This integrated information approach can provide all project managers
and the customer with decision information appropriate to their level and needs. A successful project
manager will be well trained in the technical side of managing projects.
The second and opposing dimension is the sociocultural side of project management. In contrast to the
orderly world of project planning, this dimension involves the much messier, often contradictory and
paradoxical world of implementation. It centres on creating a temporary social system within a larger
organisational environment that combines the talents of a divergent set of professionals working to
complete the project. Project managers must shape a project culture that stimulates teamwork and high
levels of personal motivation as well as a capacity to quickly identify and resolve problems that threaten
project work. This dimension also involves managing the interface between the project and external

environment. Project managers have to assuage and shape expectations of customers, sustain the
political support of top management, negotiate with their functional counterparts, monitor
subcontractors, and so on. Overall, the manager must build a cooperative social network among a
divergent set of allies with different standards, commitments, and perspectives.
The technical dimension represents the “science” of project management while the sociocultural
dimension represents the “art” of managing a project. To be successful, a manager must be a master of
both. Good project managers balance their attention to both the technical and sociocultural aspects of
project management.
2.8.4 Project Integration Management Tasks

Project integration management is by far the most important role in any project as it helps project
managers to integrate all activities crucial to project success. The main project integration
management tasks include:
 the development of the project charter
 the development of a project management plan
 Directing and managing project execution
 Monitoring and controlling project work
 Performing integrated project control
 Closing project or phase
2.9 Summary
Project management is both a science and an art. It is science in that it relies on proven and
repeatable processes and techniques to achieve project success. It is an art because it also involves
managing and relating to people and requires the project manager to apply intuitive skills in situations
that are totally unique for each project. A good project management methodology provides the
framework, processes, guidelines and techniques to manage the people and the work. A good
methodology increases the odds of being successful and therefore provides value to the organisation,
the project and the project manager.
As the practice of project management matures—from the portfolio level on down to individual
projects—the connections between organisational project management and business value become

clearer (PMI, 2010). A project is defined as a non-routine, one-time effort limited by time, resources,
and performance specifications designed to meet customer needs. One of the distinguishing
characteristics of project management is that it has both a beginning and an end and typically consists
of four phases: defining, planning, executing, and closing. Successful implementation requires both
technical and social skills. Project managers have to plan and budget projects as well as orchestrate
the contributions of others.
This chapter introduced projects and project management, explained how projects fit into programs and
portfolio management, discussed the role of the project manager, and provided important background
information on this growing profession in terms of the project management framework that integrates
the knowledge areas with the project life cycle as well as the triple constraints that always have to be
kept in balance.
CASE STUDY
A Day in the Life
Rachel, the project manager of a large information systems project, arrives at her office early to get
caught up with work before her co-workers and project team arrive. However, as she enters the office
she meets Neil, one of her fellow project managers, who also wants to get an early start on the day.
Neil has just completed a project overseas. They spend 10 minutes socializing and catching up on
personal news.
It takes Rachel 10 minutes to get to her office and settle in. She then checks her voice mail and turns
on her computer. She was at her client’s site the day before until 7:30 P.M. and has not checked her e-
mail or voice mail since 3:30 P.M. the previous day. There are 7 phone messages, 16 e-mails, and 4
notes left on her desk. She spends 15 minutes reviewing her schedule and “to do” lists for the day
before responding to messages that require immediate attention. Rachel spends the next 25 minutes
going over project reports and preparing for the weekly status meeting. Her boss, who just arrived at
the office, interrupts her. They spend 20 minutes discussing the project. He shares a rumour that a
team member is using stimulants on the job. She tells him that she has not seen anything suspicious
but will keep an eye on the team member.
The 9:00 A.M. project status meeting starts 15 minutes late because two of the team members have to
finish a job for a client. Several people go to the cafeteria to get coffee and doughnuts while others

discuss last night’s baseball game. The team members arrive, and the remaining 45 minutes of the
progress review meeting surface project issues that have to be addressed and assigned for action.
After the meeting Rachel goes down the hallway to meet with Victoria, another IS project manager.
They spend 30 minutes reviewing project assignments since the two of them share personnel. Victoria’s
project is behind schedule and in need of help. They broker a deal that should get Victoria’s project
back on track.
She returns to her office and makes several phone calls and returns several e-mails before walking
downstairs to visit with members of her project team. Her intent is to follow up on an issue that had
surfaced in the status report meeting. However, her simple, “Hi guys, how things are going?” elicits a
stream of disgruntled responses from the “troops.” After listening patiently for over 20 minutes, she
realizes that among other things several of the client’s managers are beginning to request features that
were not in the original project scope statement. She tells her people that she will get on this right
away.
Returning to her office she tries to call her counterpart John at the client firm but is told that he is not
expected back from lunch for another hour. At this time, Eddie drops by and says, “How about lunch?”
Eddie works in the finance office and they spend the next half hour in the company cafeteria gossiping
about internal politics. She is surprised to hear that Jonah Johnson, the director of systems projects,
may join another firm. Jonah has always been a powerful ally. She returns to her office, answers a few
more e-mails, and finally gets through to John. They spend 30 minutes going over the problem. The
conversation ends with John promising to do some investigating and to get back to her as soon as
possible.
Rachel puts a “Do not disturb” sign on her door, and lies down in her office. She listens to the third and
fourth movement of Ravel’s string quartet in F on headphones. Rachel then takes the elevator down to
the third floor and talks to the purchasing agent assigned to her project. They spend the next 30
minutes exploring ways of getting necessary equipment to the project site earlier than planned. She
finally authorises express delivery.
When she returns to her office, her calendar reminds her that she is scheduled to participate in a
conference call at 2:30. It takes 15 minutes for everyone to get online. During this time, Rachel catches
up on some e-mail. The next hour is spent exchanging information about the technical requirements
associated with a new version of a software package they are using on systems projects like hers.

Rachel decides to stretch her legs and goes on a walk down the hallway where she engages in brief
conversations with various co-workers. She goes out of her way to thank Chandra for his thoughtful
analysis at the status report meeting.
She returns to find that John has left a message for her to call him back ASAP. She contacts John,
who informs her that, according to his people, her firm’s marketing rep had made certain promises
about specific features her system would provide. He doesn’t know how this communication breakdown
occurred, but his people are pretty upset over the situation. Rachel thanks John for the information and
immediately takes the stairs to where the marketing group resides. She asks to see Mary, a senior
marketing manager. She waits 10 minutes before being invited into her office. After a heated
discussion, she leaves 40 minutes later with Mary agreeing to talk to her people about what was
promised and what was not promised.
She goes downstairs to her people to give them an update on what is happening. They spend 30
minutes reviewing the impact the client’s requests could have on the project schedule. She also shares
with them the schedule changes she and Victoria had agreed to. After she says good night to her team,
she heads upstairs to her boss’s office and spends 20 minutes updating him on key events of the day.
She returns to her office and spends 30 minutes reviewing e-mails and project documents. She logs on
to the MS project schedule of her project and spends the next 30 minutes working with “what-if”
scenarios.
She reviews tomorrow’s schedule and writes some personal reminders before starting off on her 30-
minute commute home.
1. How effectively do you think Rachel spent her day?

2. What does the case tell you about what it is like to be a project manager?
 What comprises the project management framework?

 How can you avoid the problems that occur when you meet scope, time, and cost goals, but
lose sight of quality or customer satisfaction?
 Differentiate between projects, programmes and portfolios.

 Are leadership and management two concepts that may be used interchangeably? Justify your
response.
 What are the key integrative aspects of a project manager’s portfolio of skills?

1) 10 project knowledge areas mapped across the project life cycle.
2) Good project management, which includes more than meeting the triple constraint.
3) See Table 2.1: Comparative Overview of Project, Programme and Portfolio Management
4) Management and leadership are functional roles with specific activities, while managing and
leading are processes with specific sets of skills and clusters of competencies. Project
management leadership focuses on the human side of project management, and the
leadership skills that the project manager needs to manage the project team and other
stakeholders. Besides project management skills, the project manager also needs leadership
skills to negotiate, motivate and inspire the team members, both individually and collectively.
However, the project manager’s challenges do not end there, the project manager also has to
manage and lead all the other project stakeholders.
There have been two major changes in the project environment in recent years which have motivated
significant changes in the project manager’s leadership style – viz. the introduction of project teams
working within a matrix organisation breakdown structure, and a general increase in the workforce’s
level of education and ability. The organisational changes mean project managers may not have the
full line authority over the resources they need to carry out the work. Project managers must, therefore
develop negotiation and networking skills to enable them to obtain labour and equipment from the
resource providers.
The other factor motivating a change in leadership style is the ability of the workforce who are now
better educated, more experienced, more competent and more articulate. This greater competency has
led to greater expectations and demands to have a greater say in their working environment, and they
also are quite prepared to question their leader’s instructions.
1. Project Manager has to have general management skills, project management skills,
leadership skills and entrepreneurial skills.

CHAPTER THREE
PROJECT PLAN DEVELOPMENT
Learning Outcomes:
 Produce a business case to motivate project selection
 Create a project charter outlining authorisation, resource commitment and responsibilities
 Develop a project schedule with costs and resources to manage project deliverables
 Document and plan for identified project risks to increase project success probabilities
 Design and Implement a communication plan to manage project and stakeholder expectations
and requirements

3.1 Introduction
One of the critical factors for project success is having a well-developed project plan. A project plan not
only provides a roadmap for project managers to follow, but is also the project manager's premier
communications and control tool throughout the project.
The output of the project planning process is the development of a project management plan, which
incorporates different area plans such as the controls, scope management plan, budgets, schedules,
risks, communications plan, procurement strategy, human resources plan, and quality plans. The
different plans are integrated into one under the project management plan. The project management
plan has different terminology in various industries, it can also be known as Project execution plan, or
project implementation manual.
Just as information technology, construction and engineering projects need to follow the project
management process groups, so do other projects, such as the production of a movie. Processes
involved in making movies might include screenwriting (initiating), producing (planning), acting and
directing (executing), editing (monitoring and controlling), and releasing the movie to theatres (closing)
(Schwalbe, 2017).
Many people enjoy watching the extra features on a DVD that describe how these processes lead to
the creation of a movie. For example, the DVD for Lord of the Rings: The Two Towers Extended Edition
includes detailed descriptions of how the script was created, how huge structures were built, how
special effects were made, and how talented professionals overcame numerous obstacles to complete
the project. This acted not as promotional filler but as a serious and meticulously detailed examination
of the entire filmmaking process. New Line Cinema made history by shooting all three Lord of the Rings
films consecutively during one massive production. It took three years of preparation to build the sets,
find the locations, write the scripts, and cast the actors. Director Peter Jackson said that the amount of
early planning they did made it easier than he imagined to produce the films. Project managers in any
field know how important it is to have good plans and to follow a good process.
A project plan takes into account the approach the team will take and helps the team and stakeholders
document decisions made regarding the objective, scope, schedule, resources, and deliverables. It is
important to include usability activities in the project plan, so that the time and resources to carry out
those activities can be built in.

3.2 Business Case

Organisations have at their disposal a variety of tools and techniques to select projects (Section 1.4 in
Chapter One) that best align with the organisational strategy. Project Managers are often tasked with
the responsibility to select potential projects and to motivate their selection to senior management in
order to procure commitment of funds and resources. The Business Case, a justification for a
proposed project or undertaking on the basis of its expected commercial benefit, is utilised by the
project manager to represent the project effectively to senior management.
The following information may be included in a business case Figure 3.1:

 Introduction/background
 Business objective
 Current situation and problem/opportunity statement
 Critical assumptions and constraints
 Analysis of options and recommendation
 Preliminary project requirements
 Budget estimate and financial analysis
 Schedule estimate
 Potential risks
 Exhibits
BUSINESS CASE: Project Management Intranet Site

1.0 Introduction/Background
JWD Consulting s core business goal is to provide world-class project management consulting services to various organisations. The
CEO, Joe Fleming, believes the firm can streamline operations and increase business by providing information related to project
management on its intranet site, making some information and services accessible to current and potential clients.
2.0 Business Objective

JWD Consulting s strategic goals include continuing growth and profitability. The Project Management Intranet Site Project will support
these goals by increasing visibility of the firm’s expertise to current and potential clients by allowing client and public access to some
sections of the intranet. It will also improve profitability by reducing internal costs by providing standard tools, techniques, templates,
and project management knowledge to all internal consultants. Since JWD Consulting focuses on identifying profitable projects and
measuring their value after completion, this project must meet those criteria.

3.0 Current Situation and Problem/Opportunity Statement

JWD Consulting has a corporate Web site as well as an intranet. The firm currently uses the Web site for marketing information. The
primary use of the intranet is for human resource information, such as where consultants enter their hours on various projects, change
and view their benefits information, access an online directory and Web-based e-mail system, and so on. The firm also uses an
enterprise-wide project management system to track all project information, focusing on the status of deliverables and meeting scope,
time, and cost goals. There is an opportunity to provide a new section on the intranet dedicated to sharing consultants’ project
management knowledge across the organisation. JWD Consulting only hires experienced consultants and gives them freedom to
manage projects as they see fit. However, as the business grows and projects become more complex, even experienced project
managers are looking for suggestions on how to work more effectively.
4.0 Critical Assumption and Constraints

The proposed intranet site must be a valuable asset for JWD Consulting. Current consultants and clients must actively support the
project, and it must pay for itself within one year by reducing internal operating costs and generating new business. The Project
Management Office manager must lead the effort, and the project team must include participants from several parts of the company,
as well as current client organisations. The new system must run on existing hardware and software, and it should require minimal
technical support. It must be easily accessible by consultants and clients and be secure from unauthorised users.
5.0 Analysis of Options and Recommendation

There are three options for addressing this opportunity:
1. Do nothing. The business is doing well, and we can continue to operate without this new project.
2. Purchase access to specialized software to support this new capability with little in-house development.
3. Design and implement the new intranet capabilities in-house using mostly existing hardware and software.
Based on discussions with stakeholders, we believe that option 3 is the best option.
6.0 Preliminary Project Requirements

The main features of the project management intranet site include the following:
1. Access to several project management templates and tools. Users must be able to search for templates and tools, read instructions
on using these templates and tools, and see examples of how to apply them to real projects. Users must also be able to submit new
templates and tools, which should be first screened or edited by the Project Management Office.
2. Access to relevant project management articles. Many consultants and clients feel as though there is an information overload when
they research project management information. They often waste time they should be spending with their clients. The new intranet
should include access to several important articles on various project management topics, which are searchable by topic, and allow
users to request the Project Management Office staff to find additional articles to meet their needs.
3. Links to other, up-to-date Web sites, with brief descriptions of the main features of the external site. 4. An Ask the Expert feature to
help build relationships with current and future clients and share knowledge with internal consultants.
5. Appropriate security to make the entire intranet site accessible to internal consultants and certain sections accessible to others.
6. The ability to charge money for access to some information. Some of the information and features of the intranet site should prompt
external users to pay for the information or service. Payment options should include a credit card option or similar online payment
transactions. After the system verifies payment, the user should be able to access or download the desired information.
7. Other features suggested by users, if they add value to the business.

7.0 Budget Estimate and Financial Analysis

A preliminary estimate of costs for the entire project is $140,000. This estimate is based on the project manager working about 20
hours per week for six months and other internal staff working a total of about 60 hours per week for six months. The customer
representatives would not be paid for their assistance. A staff project manager would earn $50 per hour. The hourly rate for the other
project team members would be $70 per hour, since some hours normally billed to clients may be needed for this project. The initial
cost estimate also includes $10,000 for purchasing software and services from suppliers. After the project is completed, maintenance
costs of $40,000 are included for each year, primarily to update the information and coordinate the Ask the Expert feature and online
articles.
Projected benefits are based on a reduction in hours’ consultants spend researching project management information, appropriate
tools and templates, and so on. Projected benefits are also based on a small increase in profits due to new business generated by this
project. If each of more than 400 consultants saved just 40 hours each year (less than one hour per week) and could bill that time to
other projects that generate a conservative estimate of $10 per hour in profits, then the projected benefit would be $160,000 per year.
If the new intranet increased business by just 1 percent, using past profit information, increased profits due to new business would be
at least $40,000 each year. Total projected benefits, therefore, are about $200,000 per year. Exhibit A summarizes the projected
costs and benefits and shows the estimated net present value (NPV), return on investment (ROI), and year in which payback occurs. It
also lists assumptions made in performing this preliminary financial analysis. All of the financial estimates are very encouraging. The
estimated payback is within one year, as requested by the sponsor. The NPV is $272,800, and the discounted ROI based on a three-
year system life is excellent at 112 percent.
8.0 Schedule Estimate

The sponsor would like to see the project completed within six months, but there is some flexibility in the schedule. We also assume
that the new system will have a useful life of at least three years.
9.0 Potential Risks

There are several risks involved with this project. The foremost risk is a lack of interest in the new system by our internal consultants
and external clients. User inputs are crucial for populating information into this system and realizing the potential benefits from using
the system. There are some technical risks in choosing the type of software used to search the system, check security, process
payments, and so on, but the features of this system all use proven technologies. The main business risk is investing the time and
money into this project and not realizing the projected benefits.
10.0 Exhibits
Exhibit A: Financial Analysis for Project Management Intranet Site Project

Discount rate 8%
Year
Assume the project is done in about 6 months
0 1 2 3 Total
Costs 140 000 40 000 40 000 4.0 000
Discount Factor 1 0.93 0.86 0.79
Discounted Costs 140 000 37 037 34 294 31 753 243 084
Benefits 0 200 000 200 000 200 000

Discount Factor 1 0.93 0.86 0.79

Discounted Benefits 0 186 185 171 468 158 766 515 419
Discounted Benefits – Costs (140 000) 148 148 137 174 127 013
Cumulative Benefits – Costs (140 000) 8 148 145 322 272 336  NPV
Payback in Year 1
Discounted Life Cycle ROI 112%
Assumptions
Costs # hours
PM (500 hrs, R50/hr) 25 000
Staff (1 500 hrs, R70/hr) 105 000
Outsourced Software & Services 10 000
Total Project Costs (all applied in Year 0) 140 000
Benefits
# Consultants 400
Hours saved 40
R/hr Profit 10
Benefits from saving time 160 000
Benefits from 1% increase in profits 40 000
Total annual projected benefits 200 000
Figure 3.1: Business Case Example

Source: Schwalbe (2011)
3.3 Project Chapter

Once senior management decides on which projects to pursue, the rest of the organisation is then
made aware of these projects by creating and distributing documentation to authorise project initiation
(Schwalbe, 2011). This documentation can take many different forms, but one common form is a
project charter. A project charter is a document that formally recognises the existence of a project and
provides direction on the project s objectives and management. It authorises the project manager to
use organisational resources to complete the project.
Key project stakeholders should sign a project charter to acknowledge agreement on the need for and
intent of the project. A project charter is a key output of the initiation process. Inputs to the
development of the project charter include:
 A project statement of work: a document that describes the products or services to be created
by the project team.

 A business case: to justify investment in a project.

 A contract: If you are working on a project under contract for an external customer, the contract
should include much of the information needed for creating a good project charter.
 Enterprise environmental factors: These factors include relevant government or industry
standards, the organisation s infrastructure, and marketplace conditions.
 Organisational process assets: include formal and informal plans, policies, procedures,
guidelines, information systems, financial systems, management systems, lessons learned,
and historical information that can be used to influence a project’s success.
The main tool and technique for developing a project charter is expert judgment. Experts from within as
well as outside the organisation should be consulted when creating a project charter to make sure it is
useful and realistic. The only output of the process to develop a project charter is a project charter.
Although the format of project charters can vary tremendously, they should include at least the following
basic information:
 The project s title and date of authorization
 The project manager s name and contact information
 A summary schedule, including the planned start and finish dates; if a summary milestone
schedule is available, it should also be included or referenced
 A summary of the project s budget or reference to budgetary documents
 A brief description of the project objectives, including the business need or other justification for
authorizing the project
 Project success criteria, including project approval requirements and who signs off on the
project
 A summary of the planned approach for managing the project, which should describe
stakeholder needs and expectations, important assumptions, and constraints, and refer to
related documents, such as a communications management plan, as available
 A roles and responsibilities matrix
 A sign-off section for signatures of key project stakeholders
 A comments section in which stakeholders can provide important comments related to the
project
Unfortunately, many internal projects do not have project charters (Schwalbe, 2017). They often have a
budget and some general guidelines, but no formal, signed documentation. Many projects fail because

of unclear requirements and expectations. Therefore, beginning with a project charter is the logical way
to go. If, for example, the project manager is having difficulty obtaining support from project
stakeholders, they can refer to what everyone agreed to in the project charter.
Project Title: Project Management Intranet Site Project

Project Start Date: May 2 Projected Finish Date: November 4
Budget Information: The firm has allocated $140,000 for this project. The majority of costs for this project will be
internal labour. An initial estimate provides a total of 80 hours per week.
Project Manager: Erica Bell, (310) 555-5896, erica_bell@jwdconsulting.com
Project Objectives: Develop a new capability accessible on JWD Consulting s intranet site to help internal
consultants and external customers manage projects more effectively.
The intranet site will include several templates and tools that users can download, examples of
completed templates and related project management documents used on real projects,
important articles related to recent project management topics, an article retrieval service, links
to other sites with useful information, and an Ask the Expert feature, where users can post
questions they have about their projects and receive advice from experts in the field. Some
parts of the intranet site will be accessible free to the public, other parts will only be accessible
to current customers and/or internal consultants, and other parts of the intranet site will be
accessible for a fee.
Main Project The project should pay for itself within one year of completion.
Success Criteria:
Approach:  Develop a survey to determine critical features of the new intranet site and solicit
input from consultants and customers.
 Review internal and external templates and examples of project management
documents.
 Research software to provide security, manage user inputs, and facilitate the article
retrieval and Ask the Expert features.
 Develop the intranet site using an iterative approach, soliciting a great deal of user
feedback.
 Determine a way to measure the value of the intranet site in terms of reduced costs
and new revenues, both during the project and one year after project completion.
ROLES AND RESPONSIBILITIES:

Name Role Position Contact Information
Joe Fleming, Sponsor JWD Consulting, CEO joe_fleming@jwdconsulting.com
Erica Bell Project Manager JWD Consulting, Manager erica_bell@jwdconsulting.com
Michael Chen Team Member JWD Consulting, Senior Consultant michael_chen@jwdconsulting.com
Jessie Faue Team Member JWD Consulting, Consultant jessie_faue@jwdconsulting.com

Kevin Dodge Team Member JWD Consulting, IT Department kevin_dodge@jwdconsulting.com

Cindy Dawson Team Member JWD Consulting, IT Department cindy_dawson@jwdconsulting.com
Kim Phuong Advisor Client representative kim_phuong@client1.com
Page Miller Advisor Client representative page_miller@client2.com
Sign-Off:
(Signatures of all the
above stakeholders)
Comments: “I will support this project as time allows, but I believe my client projects take priority. I will have one of my
assistants support the project as needed.”—Michael Chen
(Handwritten or
We need to be extremely careful testing this new system, especially the
typed comments
security in giving access to parts of the intranet site to the public
from above and clients. Kevin Dodge and Cindy Dawson
stakeholders, if
applicable)
Figure 3.2: Project Charter

Source: Schwalbe (2011)
3.3.1 Why is a Project Charter important?

A project charter announces that a new project has started and ensures your project gets off to the right
start, with management support and aligned with organisational objectives (Larson and Gray, 2017).
The multiple purposes of a project charter include:
 announcing a project has begun
 authorizing the project
 demonstrating management support for the project and project manager
 setting out management expectations for the results
 spelling out the nature and scope of the work
 broadly defining the project deliverables, schedule and budget
 aligning the project with organisational objectives
3.3.2 Issue in Projects without a Formal Project Charter

What could go wrong in a project without a formal project charter? How does having a comprehensive
project charter overcome these problems?
The overriding issue is that projects without a formal charter drift and become aimless because:

 The project and the project manager lack authority. Projects are always competing for
limited resources and the absence of formal authorization makes it difficult for project
managers to obtain the required resources. The primary purpose of the charter is to formally
authorise the project and most importantly, gives management’s stamp of approval for the
project and the project manager.
 There is no written demonstration of management support for the project. The act of
creating a charter shows management support for the project and the project manager. The
Project Sponsor is named and gives their backing to the project.
 There are no clear expectations for project outcomes. Without clear goals, project
outcomes are unlikely to be achieved. The act of creating a charter forces senior management
to spell out clearly what the project should do and sets out management’s expectations for
results.
 The scope and nature of the project may not be clearly defined. The project charter helps
by setting out the nature and scope of the work. A formal charter reduces the potential for
projects to grow in scope without control, a process called scope-creep.
 The project could set off in a direction that is not aligned with organisational
objectives. A key ingredient of a project charter is the inclusion of the Business Case – the
benefits of the project to the organisation and how the project will contribute towards the
organisation meeting its objectives.
After creating a project charter, the next step in project integration management is to prepare a project
management plan by first defining the project scope.
3.4 Define Project Scope

PMBOK states that Project Scope Management includes the processes required to ensure that the
project includes all the work required, AND ONLY THE WORK REQUIRED, to ensure that the project is
completed successfully. The project scope basically defines what needs to be done and it establishes
a common understanding with stakeholders regarding the scope of the project. The scope document
establishes the project baseline and puts in place change control system to avoid scope creep.
The primary purpose is to define as clearly as possible the deliverable(s) for the end user and to focus
project plans. As fundamental and essential as scope definition appears, it is frequently overlooked by

project leaders of well-managed, large corporations. Research clearly shows that a poorly defined
scope or mission is the most frequently mentioned barrier to project success.
The major project scope management processes are: Scope Planning and Definition; and Scope
Change Control. To develop the project scope, you need:
 Product/Service/Result description
 Project chart
 Project assumptions and constraint
 Stakeholder Input
 Agreement between all stakeholders.
3.4.1 Project Scope Document

The project scope document usually contains:
 Customer requirements: define the functional or performance specifications for the project’s
end product and other project deliverables. It should also include or reference applicable
technical specifications, standards, and codes that must be used and met regarding quality and
performance of the project work and deliverables.
 Statement of Work: (SOW) defines the major tasks that will need to be performed to
accomplish the work that needs to be done and produce all the project deliverables.
 Deliverables: are the products or outputs that the project team or contractor will produce and
provide to the customer during and at the completion of the performance of the project.
 Acceptance Criteria: for all project deliverables must be described in greater detail than what is
stated in the project charter or request for proposal.
 Work Breakdown Structure: (WBS) is a hierarchical decomposition of the project work scope
into work packages that produce the project deliverables (Gido and Clements, 2015).
3.4.2 Project Scope Statement / Statement of Work (SOW)

Figure 3.3 outlines the content of a project scope statement or statement of work (SOW) as follows
(Larson and Gray, 2017):
 Project objective. The first step of project scope definition is to define the overall objective to
meet your customer’s need(s). For example, as a result of extensive market research a
computer software company decides to develop a program that automatically translates verbal

sentences in English to Russian. The project should be completed within three years at a cost
not to exceed $1.5 million. Another example is to design and produce a completely portable,
hazardous waste, thermal treatment system in 13 months at a cost not to exceed $13 million.
The project objective answers the questions of what, when, and how much.
 Deliverables. The next step is to define major deliverables—the expected outputs over the life
of the project. For example, deliverables in the early design phase of a project might be a list of
specifications. In the second phase deliverables could be software coding and a technical
manual. The next phase could be to test prototypes. The final phase could be final tests and
approved software.
 Milestones. A milestone is a significant event in a project that occurs at a point in time. The
milestone schedule shows only major segments of work; it represents first, rough-cut estimates
of time, cost, and resources for the project. The milestone schedule is built using the
deliverables as a platform to identify major segments of work and an end date—for example,
testing complete and finished by July 1 of the same year. Milestones should be natural,
important control points in the project. Milestones should be easy for all project participants to
recognize.

PROJECT OBJECTIVE
To construct a high-quality, custom home within five months at cost not to exceed $350,000.
DELIVERABLES
• A 2,200-square-foot, 2½-bath, 3-bedroom, finished home.
• A finished garage, insulated and sheet-rocked.
• Kitchen appliances to include range, oven, microwave, and dishwasher.
• High-efficiency gas furnace with programmable thermostat.
MILESTONES
1. Permits approved—March 5
2. Foundation poured—March 14
3. Drywall in. Framing, sheathing, plumbing, electrical, and mechanical inspections passed—May 25
4. Final inspection—June 7
TECHNICAL REQUIREMENTS
1. Home must meet local building codes.
2. All windows and doors must pass NFRC class 40 energy ratings.
3. Exterior wall insulation must meet an “R” factor of 21.
4. Ceiling insulation must meet an “R” factor of 38.
5. Floor insulation must meet an “R” factor of 25.
6. Garage will accommodate two large-size cars and one 20-foot Winnebago.
7. Structure must pass seismic stability codes.
LIMITS AND EXCLUSIONS
1. The home will be built to the specifications and design of the original blueprints provided by the customer.
2. Owner responsible for landscaping.
3. Refrigerator is not included among kitchen appliances.
4. Air conditioning is not included but prewiring is included.
5. Contractor reserves the right to contract out services.
6. Contractor responsible for subcontracted work.
7. Site work limited to Monday through Friday, 8:00 A.M. to 6:00 P.M.
CUSTOMER REVIEW
John and Joan Smith
Figure 3.3: Project Scope Statement

 Technical requirements. More frequently than not, a product or service will have technical
requirements to ensure proper performance. For example, a technical requirement for a
personal
 Computer might be the ability to accept 120-volt alternating current or 240-volt direct current
without any adapters or user switches. Another well-known example is the ability of 911
emergency systems to identify the caller’s phone number and location of the phone. Examples
from information systems projects include speed and capacity of database systems and
connectivity with alternative systems. Limits and exclusions. The limits of scope should be
defined. Failure to do so can lead to false expectations and to expending resources and time
on the wrong problem. Examples of limits are: local air transportation to and from base camps
will be outsourced; system maintenance and repair will be done only up to one month after final
inspection; client will be billed for additional training beyond that prescribed in the contract.

Exclusions further define the boundary of the project by stating what is not included. Examples
include: data will be collected by the client, not the contractor; a house will be built, but no
landscaping or security devices added; software will be installed, but no training given.
 Reviews with customer. Completion of the scope checklist ends with a review with your
customer—internal or external. The main concern here is the understanding and agreement of
expectations. Is the customer getting what he or she desires in deliverables? Does the project
definition identify key accomplishments, budgets, timing, and performance requirements? Are
questions of limits and exclusions covered? Clear communication in all these issues is
imperative to avoid claims or misunderstanding.
The agreed-upon project scope document establishes the baseline for any changes that may be made
to the scope during the performance of the project. A change control system needs to be established to
define how changes will be documented, approved, and communicated. The project team or contractor
must avoid scope creep, which is informally making changes to the project scope without appropriate
approval.
3.4.3 Why should scope creep be avoided?

 Informal changes to the project can lead the entire project astray
 No approvals for changes can result in additional work that is not documented
 May cause errors
 May cause some of the sections of the project to be reworked
 Could make the project go overtime and over budget
3.5 Create a Work Breakdown Structure

After defining the scope of the project, the next step is to create a work breakdown structure (WBS)
(Larson and Gray, 2017). The WBS is a deliverable-oriented grouping of the work involved in a project
that defines the total scope of the project. Because most projects involve many people and many
different deliverables, it is important to organize and divide the work into logical parts based on how the
work will be performed. The WBS is a foundation document in project management because it provides
the basis for planning and managing project schedules, costs, resources, and changes. Since the WBS
defines the total scope of the project, some project management experts believe that work should not
be done on a project if it is not included in the WBS. Therefore, it is crucial to develop a good WBS.

The WBS is a map of the project. Use of WBS helps to assure project managers that all products and
work elements are identified, to integrate the project with the current organisation, and to establish a
basis for control. Basically, the WBS is an outline of the project with different levels of detail.
There are varying forms that a WBS may take. Figure 3.4 outlines three basic forms of the WBS.
Structure A is the more common type resembling an organisational chart.
A B C
Figure 3.4: Different Types of WBS Structures
3.5.1 Hierarchical Breakdown of the WBS

Figure 3.5 shows the major groupings commonly used in the field to develop a hierarchical WBS. The
WBS begins with the project as the final deliverable. Major project work deliverables/systems are
identified first; then the sub-deliverables necessary to accomplish the larger deliverables are defined.
The process is repeated until the sub-deliverable detail is small enough to be manageable and where
one person can be responsible. This sub-deliverable is further divided into work packages.

Figure 3.5: Hierarchical Breakdown of the WBS

Because the lowest sub-deliverable usually includes several work packages, the work packages are
grouped by type of work—for example, hardware, programming, testing. These groupings within a sub-
deliverable are called cost accounts. This grouping facilitates a system for monitoring project progress
by work, cost, and responsibility.
3.5.2 Benefits of the WBS to the Project Team

 The hierarchical structure facilitates evaluation of cost, time, and technical performance at all
levels in the organisation over the life of the project.
 Provides management with information appropriate to each level. For example, top
management deals primarily with major deliverables, while first-line supervisors deal with
smaller sub-deliverables and work packages.
 Each item in the WBS needs a time and cost estimate. With this information it is possible to
plan, schedule, and budget for a project.
 Serves as a framework for tracking cost and work performance.
 Integrates the work and the organisation by assigning responsibility to organisational units and
individuals for executing work packages.
 Can be used to “roll up” (sum) the budget and actual costs of the smaller work packages into
larger work elements so that performance can be measured by organisational units and work
accomplishment.
 Used to define communication channels and assist in understanding and coordinating many
parts of the project. The structure shows the work and organisational units responsible and
suggests where written communication should be directed.
 Problems can be quickly addressed and coordinated because the structure integrates work and
responsibility (Larson and Gray, 2017).
3.5.3 Approaches to Developing Work Breakdown Structures

There are several approaches you can use to develop a work breakdown structure. These approaches
include:

 Using guidelines: If guidelines for developing a WBS exist, it is very important to follow them.
Some organisations prescribe the form and content for WBSs for particular projects.
 The analogy approach: In the analogy approach, you use a similar project’s WBS as a starting
point.
 The top-down approach: To use the top-down approach, start with the largest items of the
project and break them into their subordinate items. This process involves refining the work into
greater and greater levels of detail.
 The bottom-up approach: Team members first identify as many specific tasks related to the
project as possible. They then aggregate the specific tasks and organize them into summary
activities, or higher levels in the WBS.
 The mind-mapping approach: mind mapping is a technique that uses branches radiating out
from a core idea to structure thoughts and ideas. Instead of writing tasks down in a list or
immediately trying to create a structure for tasks, mind mapping allows people to write and
even draw pictures of ideas in a nonlinear format (Larson and Gray, 2017).
3.5.4 Responsibility Assignment Matrix

Projects can involve large numbers of people often from different departments, functions and divisions
of the business (Larson and Gray, 2017). The project manager is accountable for the project but not
solely responsible for all the work involved. A Responsibility Matrix, Figure 3.6, is used to define who in
the organisation is responsible for individual work elements and deliverables. By forming a matrix with
the work breakdown structure, responsibilities can be assigned to lower level tasks. Each task is
assigned a WBS, the department responsible, the person responsible, and the scope of work required.
PROJECT BUSINESS PROJECT SOFTWARE
ACTIVITY KEY
SPONSOR ANALYST MANGER DEVELOPER
Initiate Project C AR R – Responsible
Establish Project Plan I C AR C A – Accountable

C – Consult
Gather user I R A I
I – Inform
Requirements
Develop Technical I R A I
Requirements
Develop Software Tools I C A R
Test Software I R A C
Deploy Software C R A C
Figure 3.6: RESPONSIBILITY ASSIGNMENT MATRIX (RAM) / RACI CHART

3.6 Generate the Project Schedule

Scheduling aims to predict the future, and it has to consider many uncertainties and assumptions. As a
result, many people believe it's more of an art than a science.
A project schedule designates work to be done and specifies deadlines for completing tasks and
deliverables. A major component of a project schedule is a work breakdown structure (WBS). The
project schedule is constructed to reflect the work breakdown structure. The project schedule depicts:
 Time (duration) estimates for all project tasks
 Start and finish dates for the tasks
 Names of staff resources assigned to complete the tasks
 Sequence of tasks
The project manager uses the schedule to help plan, execute and control project tasks and to track and
monitor the progress of the project. Team planning is more effective than planning on your own. It
ensures everyone has a stake in the schedule and ownership of the outcome. The project team must
account for all the phases, milestones and tasks, so the project can reach a successful conclusion.
But whether you're planning a team retreat, or leading a multimillion-dollar IT project, the schedule is a
critical part of your efforts. The project schedule defines timelines for key deliverables and sets
expectations for project progress and completion. It identifies and organizes project tasks into a
sequence of events that create the project management plan. A variety of inputs and tools are used in
the scheduling process, all of which are designed to help you understand your resources, your
constraints, and your risks. The end result is a plan that links events in the best way to complete the
project efficiently.
3.6.1 Benefits of a Project Schedule

A project schedule assists the project team to do the following:
 They provide a basis for you to monitor and control project activities.
 They help you determine how best to allocate resources so you can achieve the project goal.
 They help you assess how time delays will impact the project.
 You can figure out where excess resources are available to allocate to other projects.
 They provide a basis to help you track project progress (Larson and Gray, 2017).

3.6.2 Scheduling Tools
A variety of tools and techniques may be utilised in the development of a project schedule. The key
tools are listed below:
 Schedule Network Analysis – This is a graphic representation of the project's activities, the
time it takes to complete them, and the sequence in which they must be done. Project
management software is typically used to create these analyses
 Gantt Charts is a common format. It is a type of bar chart that shows the start and finish
dates of several elements of a project that include resources, milestones, tasks and
dependencies.
 Critical Path Analysis – This is the process of looking at all of the activities that must be
completed, and calculating the 'best line' – or critical path – to take so that you'll complete the
project in the minimum amount of time. The method calculates the earliest and latest possible
start and finish times for project activities, and it estimates the dependencies among them to
create a schedule of critical activities and dates
 Schedule Compression – This tool helps shorten the total duration of a project by decreasing
the time allotted for certain activities. It's done so that you can meet time constraints, and still
keep the original scope of the project. Two popular methods for schedule compression are:
 Crashing –More resources are assigned to an activity, thus decreasing the time it takes to
complete it. This is based on the assumption that the time you save will offset the added
resource costs.
 Fast-Tracking – activities are rearranged to allow more parallel work. Activities normally
done in sequence are now done at the same time.

3.6.2 Scheduling Process

There are five key processes to developing a project schedule as depicted in figure 3.7 (Larson and
Gray, 2017).
STEP 5
STEP 4 •Develop
Schedule
STEP 3 •Estimate
Activity
STEP 2 •Estimate Durations
Activity
STEP 1 •Sequence Resources
Activities
•Define
Acivities
Figure 3.7: Key Processes to Developing a Project Schedule
3.6.2.1 Step One: Define Activities

The goal of the activity definition step is to identify all the tasks required to accomplish the product. This
frequently results in identifying all the work products and deliverables that comprise the project. These
deliverables are found as the components of a Work Breakdown Structure (WBS). The project schedule
further decomposes these deliverables into the actual activities required to complete the work. Once all
activities are defined, the next step is to sequence the activities.
3.6.2.2 Step Two: Sequence Activities

The next step is to sequence the activities with dependencies. During this step, any dependencies of
related tasks are identified and documented in the project schedule. Determine the relationships among
the tasks. Identify tasks that must be completed before other tasks can begin. Identify tasks that can be
done while other tasks are being performed. A network diagram (a precedence diagramming method)
can be used to diagram the dependencies.
3.6.2.3 Step Three: Estimate Activity Resources

Once activities have been sequenced, the resources are identified along with their availability to the
project. Bear in mind that not all team members will be 100% available to the project as some team
members may be working on multiple projects. In this step, resources are then assigned to each of the

tasks. Assigning the right person to the right task is one of the most important factors in a project’s
ultimate success.
3.6.2.4 Step Four: Estimate Activity Durations

With resources assigned, the next step is to estimate each task's duration. The activity's duration is the
number of working periods required to complete the task. In Microsoft Project, this can be defined in
days, weeks or months. Work with individual team members or others who have experience with this
type of project. Base the duration estimate on an assumed level of skill.
3.6.2.5 Step Five: Analyse Schedule

The next step is to analyse the project schedule and examine the sequences, durations, resources and
inevitable scheduling constraints. The realities of vacations, meetings, discussions and staff
interactions and any ongoing responsibilities team members may have should be considered. The goal
of this step is to validate the project schedule correctly models the planned work. In this step you'll not
only validate the duration estimates are accurate, but validate the resource allocations are correct.
Check to see if staff is over-allocated. Resource levelling is a key step in ensuring the project dates are
realistic and the resources are appropriately assigned. Once the schedule is developed, it needs to be
reviewed with senior management. Feedback from senior management then needs to be affected in
order to commit to a baseline project schedule.
3.6.3 Project Schedule Review

Once you have outlined the basic schedule, you need to review it to make sure that the timing for each
activity is aligned with the necessary resources. If staff is over allocated, figure out a way to level the
staff so they are allocated the right amount of work. Possible actions:
 Modify the schedule to accommodate the constraint
 Provide additional resources for the task
 Reduce task or project scope
 Make any adjustments to the staffing plan
Caution should be maintained with overhead costs for bringing new staff up to speed. Not all staff is
truly interchangeable. The skill level of the new person may affect the time to complete and the quality
of the work. Contract staff may need more supervision.

The following are tools commonly used to review the schedule:

'What if' scenario analysis – This method compares and measures the effects of different scenarios
on a project. You use simulations to determine the effects of various adverse, or harmful, assumptions
such as resources not being available on time, or delays in other areas of the project. You can then
measure and plan for the risks posed in these scenarios.
Resource levelling – Here, you rearrange the sequence of activities to address the possibility of
unavailable resources, and to make sure that excessive demand is not put on resources at any point in
time. If resources are available only in limited quantities, then you change the timing of activities so that
the most critical activities have enough resources.
 Critical chain method – This also addresses resource availability. You plan activities using
their latest possible start and finish dates. This adds extra time between activities, which you
can then use to manage work disruptions.
 Risk multipliers – Risk is inevitable, so you need to prepare for its impact. Adding extra time
to high-risk activities is one strategy. Another is to add a time multiplier to certain tasks or
certain resources to offset overly optimistic time estimation.
Example: Project Name: Build a House

1) Work Breakdown Structure
BUILD A
HOUSE
EXTERNAL INTERNAL FINISHES
Prepare Plot Install Doors & Paint Walls

Windows
Istall Plumbing
Lay Foundation Tile Floors
& Electricals
Raise Walls Plaster Walls
Erect Roof

2) Project Schedule
ACTIVITY DURATION PREDECESSOR RESOURCE
A Prepare plot 1 - 2
B Lay foundation 3 A 3
C Raise walls 9 B 4
D Erect roof 3 C 4
E Install doors and windows 4 C 2
F Install plumbing and electricals 4 D,E 2
G Plaster walls 5 F 2
H Paint walls 3 G 3
I Tile floors 3 H 2
3) Network Diagram
D
3
A B C F G H I
START END
1 3 9 4 5 3 3
E
4

4) Critical Path
ABCEFGHI = 32
1) Gantts Chart
GANTTS CHART
DAYS/WEEKS/MONTHS
ACTIVITY
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32
A Prepare plot
B Lay foundation
C Raise walls
D Erect roof
E Instal doors and windows
F Instal plumbing and electricals
G Plaster walls
H Paint walls
I Tile floors
1. Resource Gantts Chart
GANTTS CHART
DAYS/WEEKS/MONTHS
ACTIVITY
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32
A Prepare plot 2
B Lay foundation 3 3 3
C Raise walls 4 4 4 4 4 4 4 4 4
D Erect roof 4 4 4
E Install doors and windows 2 2 2 2
F Install plumbing and electricals 2 2 2 2
G Plaster walls 2 2 2 2 2
H Paint walls 3 3 3
I Tile floors 2 2 2
Resource Loading 2 3 3 3 4 4 4 4 4 4 4 4 4 6 6 6 2 2 2 2 2 2 2 2 2 2 3 3 3 2 2 2

The availability of resources can alter the critical path. The lack of available resources can make the
project schedule very sensitive for any changes.
3.6 Estimate Project Costs

The triple constraint of project management involves balancing scope, time, and cost goals (Larson and
Gray, 2017). Project cost management includes the processes required to ensure that a project team
completes a project within an approved budget. Project managers need to ensure that their projects are
well defined, have accurate time and cost estimates, and have a realistic budget that they were
involved in approving. It is the project manager’s job to satisfy project stakeholders while continuously
striving to reduce and control costs.
There are three project cost management processes:

 Estimating costs involves developing an approximation or estimate of the costs of the
resources needed to complete a project. The main outputs of the cost estimating process are
activity cost estimates, basis of estimates, and project document updates. A cost management
plan is created as part of integration management when creating the project management plan.
It should include information related to the level of accuracy for estimates, variance thresholds
for monitoring cost performance, reporting formats, and other related information.
 Determining the budget involves allocating the overall cost estimate to individual work items
to establish a baseline for measuring performance. The main outputs of the cost budgeting
process are a cost performance baseline, project funding requirements, and project document
updates.
 Controlling costs involves controlling changes to the project budget. The main outputs of the
cost control process are work performance measurements, budget forecasts, organisational
process asset updates, change requests, project management plan updates, and project
document updates.
3.7.1 Basic Principles of Cost Management

Many projects are never initiated because project management professionals do not understand the
importance of basic accounting and finance principles. Likewise, many projects that are started never
finish because of cost management problems. Most members of an executive board have a better
understanding of and are more interested in financial terms than project management terms. Therefore,

project managers across professions need to be able to present and discuss project information in
financial terms as well as in technical terms. In addition to net present value analysis, return on
investment, and payback analysis, project managers must understand several other cost management
principles, concepts, and terms. These include concepts such as profits, life cycle costing, cash flow
analysis, tangible and intangible costs and benefits, direct costs, sunk costs, learning curve theory,
reserves, and one of the key tools and techniques for controlling project costs, earned value
management.
 Profits are revenues minus expenditures. To increase profits, a company can increase
revenues, decrease expenses, or try to do both. Most executives are more concerned with
profits than with other issues. When justifying investments in new projects, it is important to
focus on the impact on profits, not just revenues or expenses. Consider a project that you
estimate will increase revenues for a R1 million company by 10 percent. You cannot measure
the potential benefits of the project without knowing the profit margin.
 Profit margin is the ratio of revenues to profits. If revenues of R100 generate R2 in profits,
there is a 2 percent profit margin. If the company loses R2 for every R100 in revenue, there is a
-2 percent profit margin.
 Life cycle costing allows you to see a big-picture view of the cost of a project throughout its
life cycle. This helps you develop an accurate projection of a project’s financial costs and
benefits. Life cycle costing considers the total cost of ownership, or development plus support
costs, for a project. For example, a company might complete a project to develop and
implement a new customer service system in one or two years, but the new system could be in
place for ten years. Project managers, with assistance from financial experts in their
organisations, should create estimates of the costs and benefits of the project for its entire life
cycle, or ten years in the preceding example. Top management and project managers need to
consider the life cycle costs of projects when they make financial decisions.
 Cash flow analysis is a method for determining the estimated annual costs and benefits for a
project and the resulting annual cash flow. Project managers must conduct cash flow analysis
to determine net present value. Most consumers understand the basic concept of cash flow. If
they do not have enough money in their wallets or checking/credit accounts, they cannot
purchase something. Top management must consider cash flow concerns when selecting
projects in which to invest. If top management selects too many projects that have high cash
flow needs in the same year, the company will not be able to support all of its projects and
maintain its profitability.

 Tangible and intangible costs and benefits are categories for determining how definable the
estimated costs and benefits are for a project. Tangible costs or benefits are those costs or
benefits that an organisation can easily measure in rands. Conversely, intangible costs or
benefits are costs or benefits that are difficult to measure in monetary terms. Suppose a few
project team members, out of personal interest, spent some time using government-owned
computers, books, and other resources to research areas related to the project. Although their
hours and the government-owned materials were not billed to the project, they could be
considered as intangible costs. Intangible benefits for projects often include items like goodwill,
prestige, and general statements of improved productivity that an organisation cannot easily
translate into rands. Because intangible costs and benefits are difficult to quantify, they are
often harder to justify.
 Direct costs are costs that can be directly related to producing the products and services of
the project. You can attribute direct costs directly to a certain project. For example, the salaries
of people working full time on the project and the cost of hardware and software purchased
specifically for the project are direct costs. Project managers should focus on direct costs, since
they can control them.
 Indirect costs are costs that are not directly related to the products or services of the project,
but are indirectly related to performing the project. For example, the cost of electricity, paper
towels, and so on consumed in a large building, housing a thousand employees, who work on
many projects would be considered as indirect costs. Indirect costs are allocated to projects,
and project managers have very little control over them.
 Sunk cost is money that has been spent in the past. When deciding what projects to invest in
or continue, you should not include sunk costs. For example, suppose a project had spent R1
million on a project over the past three years to create a geographic information system, but
they never produced anything valuable. If the government was evaluating what projects to fund
next year and someone suggested that they keep funding the geographic information system
project because they had already spent R1 million on it, he or she would be incorrectly making
sunk cost a key factor in the project selection decision. Many people fall into the trap of
considering how much money has been spent on a failing project and, therefore, hate to stop
spending money on it. This trap is similar to gamblers not wanting to stop gambling because
they have already lost money. Sunk costs should be forgotten.
 Learning curve theory states that when many items are produced repetitively, the unit cost of
those items decreases in a regular pattern as more units are produced. For example, suppose

the Surveyor Pro project would potentially produce 1,000 handheld devices that could run the
new software and access information via satellite. The cost of the first handheld device or unit
would be much higher than the cost of the thousandth unit. Learning curve theory should help
estimate costs on projects involving the production of large quantities of items. Learning curve
theory also applies to the amount of time it takes to complete some tasks. For example, the first
time a new employee performs a specific task, it will probably take longer than the tenth time
that employee performs a very similar task.
 Reserves are rands included in a cost estimate to mitigate cost risk by allowing for future
situations that are difficult to predict. Contingency reserves allow for future situations that may
be partially planned for (sometimes called known unknowns) and are included in the project
cost baseline. For example, if an organisation knows it has a 20 percent rate of turnover for
project management personnel, it should include contingency reserves to pay for recruiting and
training costs for project management personnel. Management reserves allow for future
situations that are unpredictable (sometimes called unknown unknowns). For example, if a
project manager gets sick for two weeks or an important supplier goes out of business,
management reserve could be set aside to cover the resulting costs.
 Earned value management (EVM) is a project performance measurement technique that
integrates scope, time, and cost data. Given a cost performance baseline, project managers
and their teams can determine how well the project is meeting scope, time, and cost goals by
entering actual information and then comparing it to the baseline. This concept will be
expanded upon in the section on Cost Control.
3.7.2 Cost Estimation

Once a resource requirements list is produced, then the project manager and their team need to
develop several estimates of the costs for these resources (Larson and Gray, 2017). A cost
management plan is a document that describes how the organisation will manage cost variances on the
project. For example, if a cost estimate provides the basis for evaluating supplier cost proposals for all
or part of a project, the cost management plan describes how to respond to proposals that are higher or
lower than the estimates. Some organisations assume that a cost proposal within 10 percent of the
estimate is acceptable and only negotiate items that are more than 10 percent higher or 20 percent
lower than the estimated costs. The cost management plan is part of the overall project management
plan.

Another important consideration in preparing cost estimates is labour costs, because a large
percentage of total project costs are often labour costs. Many organisations estimate the number of
people or hours they need by department or skill over the life cycle of a project. Labour costs are often
much higher for contractors, so it is important to distinguish between internal and external resources.
3.7.2.1 Cost Estimation Tools and Techniques

Several tools and techniques are available to assist in creating cost estimates. Commonly used tools
and techniques include analogous cost estimating, bottom-up estimating, parametric modelling, the
cost of quality, project management estimating software, vendor bid analysis, and reserve analysis.
 Analogous estimates, also called top-down estimates, use the actual cost of a previous,
similar project as the basis for estimating the cost of the current project. This technique
requires a good deal of expert judgment and is generally less costly than others are, but it is
also less accurate. Analogous estimates are most reliable when the previous projects are
similar. Teams preparing cost estimates must have the needed expertise to determine whether
certain parts of the project will be more or less expensive than analogous projects. For
example, estimators often try to find a similar project and then customize/modify it for known
differences. However, if the project to be estimated involves a new programming language or
working with a new type of hardware or network, the analogous estimate technique could easily
result in too low an estimate.
 Bottom-up estimates involve estimating individual work items or activities and summing them
to get a project total. It is sometimes referred to as activity-based costing. The size of the
individual work items and the experience of the estimators drive the accuracy of the estimates.
If a detailed WBS is available for a project, the project manager could have each person
responsible for a work package develop his or her own cost estimate for that work package, or
at least an estimate of the amount of resources required. Using smaller work items increases
the accuracy of the cost estimate because the people assigned to do the work develop the cost
estimate instead of someone unfamiliar with the work. The drawback with bottom-up estimates
is that they are usually time-intensive and therefore expensive to develop.
 Parametric modelling uses project characteristics (parameters) in a mathematical model to
estimate project costs. A parametric model might provide an estimate of R150 per hour for a
professional builder based on the level of expertise of the builder, the size and complexity of
the building involved, and so on. Parametric models are most reliable when the historical
information that was used to create the model is accurate, the parameters are readily

quantifiable, and the model is flexible in terms of the size of the project. For example, a large
office automation project might use a ballpark figure of R10, 000 per workstation based on a
history of similar office automation projects developed during the same time period. Parametric
models that are more complicated are usually computerized.
In practice, many people find that using a combination or hybrid approach involving analogous, bottom
up, and/or parametric modelling provides the best cost estimates. Other considerations to make when
preparing cost estimates are how much to include in reserves, as described earlier, the cost of quality,
and other cost estimating methods such as vendor bid analysis.
4.7.2.2 Typical Problems with Information Technology Cost Estimates

Even though there are many tools and techniques to assist in creating project cost estimates, many
project cost estimates are still very inaccurate, especially those involving new developments. Four
reasons for these inaccuracies and some ways to overcome them are as follows:
 Estimates are done too quickly.
Developing an estimate for a large project is a complex task requiring a significant amount of
effort. Many estimates must be done quickly and before clear requirements have been
produced.
 Lack of estimating experience.
The technical project team members who develop cost estimates often do not have much
experience with cost estimation, especially for large projects. There is also not enough
accurate, reliable project data available on which to base estimates. If an organisation uses
good project management techniques and develops a history of keeping reliable project
information, including estimates, it should help improve the project’s estimates. Enabling
technical project team members to receive training and mentoring on cost estimating will also
improve cost estimates.
 Human beings are biased toward underestimation.
For example, a project manager might make estimates based on their own abilities and forget
that many junior people will be working on a project. Estimators might also forget to allow for
extra costs needed for integration and testing on large projects. It is important for project
managers and top management to review estimates and ask important questions to make sure
the estimates are not biased.

 Management desires accuracy.

Management might ask for an estimate, but really wants a more accurate number to help them
create a bid to win a major contract or get internal funding. It is important for project managers
to help develop good cost and schedule estimates and to use their leadership and negotiation
skills to stand by those estimates.
It is also important to be cautious with initial estimates. Top management never forgets the first
estimate and rarely, if ever, remembers how approved changes affect the estimate. It is a crucial
process to keep top management informed about revised cost estimates (Larson and Gray, 2017).
3.7.3 Determining the Budget

Determining the project budget involves allocating the project cost estimate to individual work items
over time (Larson and Gray, 2017). These work items are based on the activities in the work breakdown
structure for the project. The activity cost estimates, basis of estimates, scope baseline, project
schedule, resource calendars, contracts, and organisational process assets are all inputs for
determining the budget. The main goal of the cost budgeting process is to produce a cost baseline for
measuring project performance and project funding requirements. It may also result in project document
updates, such as items being added, removed, or modified to the scope statement or project schedule.
In addition to providing input for budgetary estimates, cost budgeting provides a cost baseline. A cost
baseline is a time-phased budget that project managers use to measure and monitor cost performance.
Estimating costs for each major project activity over time provides project managers and top
management with a foundation for project cost control, as described in the next section.
Cost budgeting, as well as requested changes or clarifications, may result in updates to the cost
management plan, a subsidiary part of the project management plan. Cost budgeting also provides
information for project funding requirements. For example, some projects have all funds available when
the project begins, but others must rely on periodic funding to avoid cash flow problems. If the cost
baseline shows that more funds are required in certain months than are expected to be available, the
organisation must make adjustments to avoid financial problems.
3.7.4 Controlling Costs

The controlling of cost crucial to successful completion of the project. Controlling project costs
includes monitoring cost performance, ensuring that only appropriate project changes are included in a

revised cost baseline, and informing project stakeholders of authorised changes to the project that will
affect costs. Several tools and techniques assist in project cost control. In addition to using software,
however, there must be some change control system to define procedures for changing the cost
baseline. This cost control change system is part of the integrated change control system that will be
discussed in Chapter 6 on Integrated Change Control.
Since many projects do not progress exactly as planned, new or revised cost estimates are often
required, as are estimates to evaluate alternate courses of action. Performance review meetings can be
a powerful tool for helping to control project costs. People often perform better when they know they
must report on their progress. Another very important tool for cost control is earned value management
(EVM), a cost control technique unique to the field of project management.
3.7.4.1 Earned Value Management (EVM)

Earned value management (EVM) is a project performance measurement technique that integrates
scope, time, and cost data (Larson and Gray, 2017). Given a cost performance baseline, project
managers and their teams can determine how well the project is meeting scope, time, and cost goals
by entering actual information and then comparing it to the baseline. A baseline is the original project
plan plus approved changes. Actual information includes whether or not a WBS item was completed or
approximately how much of the work was completed, when the work actually started and ended, and
how much it actually cost to do the completed work. Earned value management involves calculating
three values for each activity or summary activity from a project’s WBS.
 The Planned Value (PV), also called the budget, is that portion of the approved total cost
estimate planned to be spent on an activity during a given period. Table 3.1 shows an example
of earned value calculations. Suppose a project included a summary activity of purchasing and
installing a new Web server. Suppose further that, according to the plan, it would take one
week and cost a total of R10, 000 for the labour hours, hardware, and software involved. The
planned value (PV) for that activity that week is, therefore, R10, 000.
 The Actual Cost (AC) is the total direct and indirect costs incurred in accomplishing work on
an activity during a given period. For example, suppose it actually took two weeks and cost
R20, 000 to purchase and install the new Web server. Assume that R15, 000 of these actual

costs were incurred during Week 1 and R5,000 was incurred during Week 2. These amounts
are the actual cost (AC) for the activity each week.
 The Earned Value (EV) is an estimate of the value of the physical work actually completed. It
is based on the original planned costs for the project or activity and the rate at which the team
is completing work on the project or activity to date. The rate of performance (RP) is the ratio of
actual work completed to the percentage of work planned to have been completed at any given
time during the life of the project or activity. For example, suppose the server installation was
halfway completed by the end of Week 1. The rate of performance would be 50 percent
(50/100) because by the end of Week 1, the planned schedule reflects that the task should be
100 percent complete and only 50 percent of that work has been completed. In Table 3.1, the
earned value estimate after one week is therefore R5, 000.
Table 3.1: Earned value calculations for one activity after Week 1
Activity Week 1
Earned Value (EV) 5,000
Planned Value (PV) 10,000
Actual cost (AC) 15,000
Cost variance (CV) -10,000
Schedule variance (SV) -5,000
Cost performance index (CPI) 33%
Schedule performance index (SPI) 50%
The earned value calculations in Table 3.1 are carried out as follows:
EV = 10 000 * 50% = 5 000
CV = 5 000 - 15 000 = -10 000
SV = 5 000 - 10 000 = -5 000
CPI = 5 000 / 15 000 = 33%
SPI = 5 000 / 10 000 = 50%
3.7.4.1.1 Earned Value Management Formulas

Table 3.2 summarizes the formulas used in earned value management. Note that the formulas for
variances and indexes start with EV, the earned value. Variances are calculated by subtracting the

actual cost or planned value from EV, and indexes are calculated by dividing EV by the actual cost or
planned value.
TERM FORMULA
Earned value (EV) EV = PV to date* RP
Cost variance (CV) CV = EV- AC
Schedule variance (SV) SV = EV- PV
Cost performance index (CPI) CPI = EV/ AC
Schedule performance index (SPI) SPI = EV/ PV
Estimate at completion (EAC) EAC = BAC/ CPI
Estimated time to complete Original time estimate/ SPI
Table 3.2 Earned Value Formulas
(Larson and Gray, 2017)
After totalling the EV, AC, and PV data for all activities on a project, the CPI and SPI can be used to
project how much it will cost and how long it will take to finish the project based on performance to date.
Given the budget at completion (BAC) and original time estimate, you can divide by the appropriate
index to calculate the estimate at completion (EAC) and estimated time to complete, assuming
performance remains the same.
 Cost variance (CV) is the earned value minus the actual cost. If cost variance is a negative
number, it means that performing the work cost more than planned. If cost variance is a
positive number, it means that performing the work cost less than planned
 Schedule variance (SV) is the earned value minus the planned value. A negative schedule
variance means that it took longer than planned to perform the work, and a positive schedule
variance means that it took less time than planned to perform the work.
 The cost performance index (CPI) is the ratio of earned value to actual cost and can be used
to estimate the projected cost of completing the project. If the cost performance index is equal
to one, or 100 percent, then the planned and actual costs are equal - the costs are exactly as
budgeted. If the cost performance index is less than one or less than 100 percent, the project is
over budget. If the cost performance index is greater than one or more than 100 percent, the
project is under budget.
 The schedule performance index (SPI) is the ratio of earned value to planned value and can
be used to estimate the projected time to complete the project. Similar to the cost performance
index, a schedule performance index of one, or 100 percent, means the project is on schedule.

If the schedule performance index is greater than one or 100 percent, then the project is ahead
of schedule. If the schedule performance index is less than one or 100 percent, the project is
behind schedule. Note that in general, negative numbers for cost and schedule variance
indicate problems in those areas. Negative numbers mean the project is costing more than
planned or taking longer than planned. Likewise, CPI and SPI less than one or less than 100
percent also indicate problems.
 The cost performance index can be used to calculate the Estimate at Completion (EAC) an
estimate of what it will cost to complete the project based on performance to date. Similarly, the
schedule performance index can be used to calculate an estimated time to complete the
project.
The entire EVM process begins with an estimate and when the estimate is off, all subsequent
calculations will be off. Earned value management is the primary method available for integrating
performance, cost, and schedule data. It can be a powerful tool for project managers and top
management to use in evaluating project performance.
3.8 Plan for Project Risk

Risk is an uncertain event or condition that, if it occurs, has a positive or negative effect on project
objectives (Larson and Gray, 2017). A risk has a cause and, if it occurs, a consequence.
The essence of project management is risk management. Every project management technique is
really a risk management technique. Each in its own way tries to prevent something bad from
happening. Project selection systems try to reduce the likelihood that projects will not contribute to the
mission of the firm. Project scope statements, among other things, are designed to avoid costly
misunderstandings and to reduce scope creep. Work breakdown structures reduce the likelihood that
some vital part of the project will be omitted or that the budget estimates are unrealistic.
All of the techniques try to increase stakeholder satisfaction and increase the chances of project
success. From this perspective, managers engage in risk management activities to compensate for
the uncertainty inherent in project management and that things never go according to plan. Risk
management is proactive not reactive. It reduces the number of surprises and leads to a better
understanding of the most likely outcomesof negative events.

Although many managers believe that in the final analysis, risk assessment and contingency depend on
subjective judgment, some standard method for identifying, assessing, and responding to risks should
be included in all projects. The very process of identifying project risks forces some discipline at all
levels of project management and improves project performance. Contingency plans increase the
chance that the project can be completed on time and within budget. Contingency plans can be simple
“work-arounds” or elaborate detailed plans. Responsibility for risks should be clearly identified and
documented. It is desirable and prudent to keep a reserve as a hedge against project risks. Budget
reserves are linked to the WBS and should be communicated to the project team. Control of
management reserves should remain with the owner, project manager, and line person responsible.
Use of contingency reserves should be closely monitored, controlled, and reviewed throughout the
project life cycle.
Experience clearly indicates that using a formal, structured process to handle possible foreseen and
unforeseen project risk events minimises surprises, costs, delays, stress, and misunderstandings
(Larson and Gray, 2017). Risk management is an iterative process that occurs throughout the lifespan
of the project. When risk events occur or changes are necessary, using an effective change control
process to quickly approve and record changes will facilitate measuring performance against schedule
and cost. Ultimately successful risk management requires a culture in which threats are embraced not
denied and problems are identified not hidden.
3.8.1 Risk Concepts
CONCEPT DESCRIPTION
Risk According to Gido and Clements (2015), risk is an uncertain event that can
jeopardise the project objective. Risk includes the expected losses (economic, time,
infrastructure or resources) that a particular phenomenon might cause. It is a
function of the probability of particular occurrences and the losses that each would
cause (severity).
Risk management Risk management includes the processes concerned with identifying, analysing and
responding to project risks. It includes both minimising the impact of adverse events
and maximising the likelihood of positive outcomes. Project risk management
includes the processes of risk assessment, risk mitigation and risk response.
Hazard A hazard in the project management domain can be defined as a rare or extreme
event, or the probability of an occurrence in the natural or human-made

environment, that adversely effects the successful completion of the project, to the
extent that it may cause economic, time, infrastructure or resource loss.
Vulnerability Vulnerability is the degree of loss to a given element (economic, time, infrastructure
or resources) that is at possible risk from the impact of a hazard of a given severity.
It is specific to a particular project and can be expressed on a scale of 0 to 10 (0
indicating no loss, 10 indicating total damage).
Probability Risk probability in a project can be defined as which the risk event that is likely to
occur. The probability of certain risks influencing a project is determined by the
nature of the project.
Frequency Frequency refers to the number of times a particular risk can impact on a project, for
example rain interruption of a building project or systems downtime in an
information technology project.
Severity The impact of a risk on a project can be defined by its severity. The severity of a risk
is mostly quantified into monetary terms, although other measuring tools are also
often used.
Table 3.3: Risk Management Concepts
3.8.2 Risk Categories

Broad categories of risks include:
Market risk:
If the project is to produce a new product or service, will it be useful to the organisation or marketable to
others? Will users accept and use the product or service? Will someone else create a better product or
service faster, making the project a waste of time and money?
Financial risk:
Can the organisation afford to undertake the project? How confident are stakeholders in the financial
projections? Will the project meet NPV, ROI, and payback estimates? If not, can the organisation afford
to continue the project? Is this project the best way to use the organisation’s financial resources?
Technology risk:
Is the project technically feasible? Will it use mature, leading edge, or bleeding edge technologies?
When will decisions be made on which technology to use? Will hardware, software, and networks
function properly? Will the technology be available in time to meet project objectives? Could the

technology be obsolete before a useful product can be produced? You can also break down the
technology risk category into hardware, software, and network technology, if desired.
People risk:
Does the organisation have or can they find people with appropriate skills to complete the project
successfully? Do people have the proper managerial and technical skills? Do they have enough
experience? Does senior management support the project? Is there a project champion? Is the
organisation familiar with the sponsor/customer for the project? How good is the relationship with the
sponsor/customer?
Structure/process risk:
What is the degree of change the new project will introduce into customer areas and business
procedures? How many distinct customer groups does the project need to satisfy? With how many
other systems does the new project/system need to interact? Does the organisation have processes in
place to complete the project successfully? (Larson and Gray, 2017).
3.8.3 Benefits of Risk Management

 Proactive rather than reactive approach
 Reduces surprises & negative consequences
 Prepares project manager to take advantage of appropriate risks (opportunities)
 Provides better control over future events.
 Improves chances of reaching project objectives within budget, on time & to quality standards
3.8.4 Risk Management Process

The Risk Management Process is based upon an internationally accepted standard: ISO 31000: 2009,
as shown and discussed below (Larson and Gray, 2017).

Figure 3.8: Risk Management Process
3.8.4.1 Communication
Ongoing communication and consultation with all stakeholders to ensure understanding of the process
and its intended outcomes is performed by the Risk Administrator. This involves collating reports for
presentation to the Finance, Resources and Risk Committee; facilitating ongoing operational reviews of
risk registers, coordinating risk assessments for specific projects and ongoing advice and support to
ensure compliance with the Risk Management Framework.
3.8.4.2 Define Objectives (Establish context)

Risk management takes place within the goals and objectives of the project. Therefore, risk
management must be placed into both a strategic and operational context. Strategic risk identification

involves the relationship between the project and the broad external business environment. A range of
issues should be considered in examining the strategic content, including:
 Opportunities and threats associated with the local, national and global economic, social,
political, cultural, environmental, regulatory and competitive environments;
 Key thrusts of stakeholder strategies; and
 Strengths and weaknesses of the project in attaining corporate objectives and exercising a
state of influence amongst stakeholders.
Operational risk identification involves gaining an understanding of the organisation’s capabilities,

goals, objectives, strengths and weaknesses by considering:
 Organisational structure and culture;
 Geographic’s/ demographics;
 The identity and nature of interaction with key stakeholders;
 The existence of any operational constraints;
 Objectives and key performance indicators;
 Business resilience vulnerabilities;
 Relevant issues relating to recent change management risk, performance or audit reviews;
 Relevant stakeholder community concerns or requirements;
 Regulatory and contractual requirements and constraints; and
 Business management systems.
3.8.4.3 Risk identification

 Risk identification is a critical activity at both a strategic and operational level. It needs to
include all significant sources of risk, including those beyond the project’s control. If a
risk/threat is not identified, there can be no strategy to defend against it. The objective of this
step is not to create an onerous and lengthy list of all possible risks, but to identify all significant
risks that could impact the achievement of project objectives. Risk can be identified through the
use of:
 Focus groups (using brainstorming approaches, SWOT analysis techniques, project categories,
or broad business categories)
 Workshops
 Interviews with respective management by the Risk Administrator
 The intranet is also a means of reporting incidents or risks

 Analysing historical records and closeout reports

 Safety reports (health and safety requirements)
 Structured questionnaires
 Structured checklists
 Flow charts
 Judgement based on knowledge
 Scenario analysis
3.8.4.4 Risk Analysis and Evaluation (Risk Quantification)

Having identified a range of possible risks, the next step is to quantify the probability (likelihood) of the
risk occurring and the impact or consequence to the project, or to the amount at stake. These risks
should be assessed in consultation with appropriate stakeholders. The objectives at this step are to
separate the minor risks from major ones. The level of risk is determined by measuring the likelihood of
each event arising and the associated consequences.
For any given risk, whether it is a natural disaster, a liability, or a worker’s compensation loss exposure,
the following steps should be followed to analyse the frequency and severity of the risk:
I. Assign a category for the frequency of occurrence of a loss event (Table 3.4).
II. Assign a category for the severity of the loss event (Table 3.5
III. Multiply the likelihood value by the consequence value
IV. Prioritise/Rank the ratings for all loss exposures (Table 3.6)
The number of times within a specified period in which a risk may occur either as a consequence of
business operations or through failure of operating systems, policies or procedures.
Rating Description Probability Score
Almost Certain Expected to occur in most circumstances > 80% 5
Likely Will probably occur in most circumstances 61 – 80% 4
Possible Might occur within a 5 year time period 41 – 60% 3
Unlikely Could occur during a specified time period 21 – 40% 2
Rare May only occur in exceptional circumstances < 20% 1
Table 3.4: Likelihood/Probability Rating

Rating Description Score

Catastrophic Major impact on the project, e.g. >25% deviation in scope, scheduled end-date or project budget. 5
Major Significant impact on the project, e.g. 10-25% deviation in scope, scheduled end-date or project budget. 4
Moderate Measurable impact on the project, e.g. 5-10% deviation in scope, scheduled end-date or project budget. 3
Minor Minor impact on the project, e.g. <5% deviation in scope, scheduled end-date or project budget. 2
Insignificant Insignificant impact on the project, It is not possible to measure the impact on the project as it is minimal 1
Table 3.5: Consequence/Impact Rating
Prioritising risks
The purpose of prioritising the risk is to determine the level of action needed for the identified and
assessed risks (Table 3.6 and Table 3.7)
Consequences
Likelihood
Insignificant Minor Moderate Major Catastrophic
Almost Certain Low Medium High High Extreme
Likely Low Medium Medium High High
Possible Low Low Medium Medium High
Unlikely Low Low Low Medium Medium
Rare Low Low Low Low Medium
Table 3.6: Risk Prioritisation/Ranking
Priority Score Action required

Extreme 20-25 Immediate Action Required
High 10-19 Action plan required, project manager attention needed
Medium 6-9 Management by specific reviewing and monitoring of activities
Low 1-5 Manage by routine procedures, unlikely to need specific application of resources
Table 3.7: Risk Prioritisation/Ranking
3.8.4.5 Risk Response

The objective of this step is to identify how the analysed risks will be treated. Risk response involves
identifying the options for managing each risk, evaluating those options, assigning accountability (for
Extreme, High and Moderate residual risks) and taking relevant action. The following options in table
3.8 are available for responding to risks and may be applied individually or in combination, with due
consideration of risk appetite.

Response Description
Avoid the risk Not to proceed with the activity or choosing an alternative approach to achieve the same
outcome.
Aim is risk management, not aversion.
Mitigate Reduce the likelihood - Improving management controls and procedures.
Reduce the consequence - Putting in place strategies to minimise adverse consequences,
e.g. contingency planning, Business Continuity Plan, liability cover in contracts.
Transfer the risk Shifting responsibility for a risk to another party by contract or insurance. Can be transferred
as a whole or shared.
Accept the risk Controls are deemed appropriate.
These must be monitored and contingency plans developed where appropriate.
Exploit Exploitation means to ensure that the risk event definitely occurs so that its benefits can be
realized.
Enhance If actions cannot be taken to guarantee that the opportunity will occur then responses might
be taken to enhance its probability or its beneficial impact if it does transpire.
Share Sharing is similar to transference but its aim is to share the opportunity with the third party
who is best able to capitalize on it.
Table 3.8: Risk Responses Strategies
Having identified, quantified and prioritised the risks, you need to develop a risk response plan (Table
3.9) which defines ways to address adverse risk and enhance entrepreneurial opportunities before they
occur.
Risk
Risk
Ratin Risk Responsi
Risk Element Effect on Risk Contingency
g/ Respons ble
No. (Descrip Project Trigger Plan
Severi e Person
tion)
ty
Reserve indoor space.
Low attendance Weather
Rain on day Recruit extra volunteers
1 will incur financial 25 Accept report 2 days Vorne
of event to set up in indoor
loss before event
space.
Road Identify alternative
Transport routes. Develop signs
Low attendance
Road department and post them along
2 will incur financial 20 Accept Kyle
construction publishes route to event.
loss
construction Announce in news
schedule media.
Table 3.9: Risk Response Plan for Outdoor Festival Project

3.8.4.6 Controlling Risks

The ultimate goal of risk management is risk mitigation. Risk mitigation involves defining the necessary
steps to counter threats and to enhance opportunities. It is the active steps taken to lessen the effects
that a particular identified risk might have on a project outcome. It is also the continuous measures
taken during the life cycle of a project in order to ensure proactive actions to unforeseen circumstances.
Controlling risk is an ongoing process of (Figure 3.9):
 identifying, analysing & planning for new risks,
 keeping track of identified risks,
 reanalysing existing risks,
 monitoring trigger conditions for contingency plans,
 reviewing the execution of risk responses - measure actual progress & compare to planned
progress on a timely & regular basis, and
 taking corrective action immediately if necessary (PMI, 2013)
Figure 3.9: Flow Process Diagram for Controlling Risks
3.9 Plan Project Communication

Communication planning involves determining the information and communication needs of the
stakeholders: Who needs what information? When will they need it? And how will it be given to them.
While all projects share the need to communicate project information, the informational needs and
methods of distribution vary widely. Identifying the informational needs of the stakeholders, and
determining a suitable means of meeting those needs, are important factors for project success. A

project communication plan defines the generation and distribution of project documentation among
stakeholders throughout the project (Clements and Gido, 2012:419).
Project communication takes various forms:
 Face-to-face or via some medium
 Verbal or written
 Internal or external correspondence
Body language and tone are important elements in verbal communication (Clements and Gido,
2012:419). Failure to listen can cause a breakdown in communication. The three most common types
of project meetings are status review, problem-solving, and design review meetings. Before any
meeting, the purpose of the meeting and the people who need to participate should be determined, an
agenda drawn up and distributed, materials prepared, and room arrangements made. In preparing for
the presentation, it is important to determine the purpose of the presentation, find out about the target
audience, make an outline, develop notes and visual aids, make copies of handout materials, and
practice.
Written progress reports and final reports are often required during a project. At the start of the project,
a document tracking system needs to be established regarding how changes to documents will be
documented, approved, and communicated. A project communication plan defines the generation and
distribution of project documents among stakeholders throughout the project. Communicating with
stakeholders requires the project team to employ effective verbal and written communication, and in
particular effective listening to achieve understanding. Collaborative communication tools allow all or
some of the members of the project team, including subcontractors and the customer to communicate
with each other.
3.9.1 Importance of Project Communication Management

Most people would agree that communication between two individuals should be simple (Clements and
Gido, 2012:419). When you communicate, you are successful in getting your point across to the person
you're talking to. Within a project, communication is key for the following reasons:
 To meet the information needs of customers & stakeholders (Planning & Info Distribution),
 Track & report on project performance (Performance Reporting), and to
 Document project results (Administrative Closure).

3.9.2 Barriers to Communication

Many projects experience difficulties due to communication issues (Clements and Gido, 2012:419).
There are five key barriers that can occur within a project: language, cultural diversity, gender
differences, status differences and physical separation. These barriers to communication are specific
items that can distort or prevent communication within an organisation. Other barriers include:
 Filtering
 Selective perception
 Information overload
 Emotions
 Silence
 Communication apprehension/ social anxiety
 Complex project structures.
3.9.3 Critical Success Factors for Effective Communication

The following factors are essential for successful project communication (Larson and Gray, 2017):
 Effective and frequent personal communication is crucial to successful project management.
 A high degree of face-to-face communication is important early in the project to foster team
building, develop good working relationships, and establish mutual expectations.
 Body language and customs reflective of cultural diversity must be considered in
communications.
 The heart of communication is understanding—not only to be understood, but to understand.
Half of making communication effective is listening. Failure to listen can cause a breakdown in
communication.
 Communication should be clear, concise, honest, unambiguous, free of jargon, and not
offensive.
 Achieving customer satisfaction requires ongoing communication with the customer to keep
him or her informed and to determine whether expectations have changed. Regularly ask
customers about their level of satisfaction with the progress of the project.
 Keep the customer and project team informed of the project status and potential problems in a
timely manner.

 Project status meetings should be held on a regular basis. Have the team develop meeting
guidelines at the project kickoff meeting at the beginning of the project so that everyone
understands and is committed to what behavior is expected during project meetings.
 Do not confuse busyness and activity with accomplishment when communicating project
progress.
 Reports must be written to address what is of interest to the readers, not what is of interest to
the person writing the report.
 Make reports concise, readable, and understandable. Pay as much attention to format,
organisation, appearance, and readability as you do to the content.
 At the start of the project, a document control system needs to be established that defines how
changes to documents will be documented, approved, and communicated.
 At the beginning of the project, prepare a project communication plan to ensure that all
stakeholders will receive the information and documents they need.
 Regular and open communication, trust, respect, open-mindedness, and a positive win-win
attitude are keys to successful stakeholder engagement.
3.9.4 Project Communication Plan

Communication is a key component in coordinating and tracking project schedules, issues, and action
items (Larson and Gray, 2017). The plan maps out the flow of information to different stakeholders and
becomes an integral part of the overall project plan. The purpose of a project communication plan is to
express what, who, how, and when information will be transmitted to project stakeholders so schedules,
issues, and action items can be tracked. Project communication plans address the following core
questions:
 What information needs to be collected and when?
 Who will receive the information?
 What methods will be used to gather and store information?
 What are the limits, if any, on who has access to certain kinds of information?
 When will the information be communicated?
 How will it be communicated?
Developing a communication plan that answers these questions usually entails the following basic
steps:

1. Stakeholder analysis.
Identify the target groups. Typical groups could be the customer, sponsor, project team, project office,
or anyone who needs project information to make decisions and/or contribute to project progress.
2. Information needs.
What information is pertinent to stakeholders who contribute to the project’s progress? For example,
top management needs to know how the project is progressing, whether it is encountering critical
problems, and the extent to which project goals are being realized. This information is required so that
they can make strategic decisions and manage the portfolio of projects. Project team members need to
see schedules, task lists, specifications, and the like, so they know what needs to be done next.
External groups need to know any changes in the schedule and performance requirements of the
components they are providing. Frequent information needs found in communication plans are:
 Project status reports  Deliverable issues
 Changes in scope  Team status meetings
 Gating decisions  Accepted request

changes
 Action items  Milestone reports
3. Sources of information.
When the information needs are identified, the next step is to determine the sources of information
(Larson and Gray, 2017). That is, where does the information reside? How will it be collected? For
example, information relating to the milestone report, team meetings, and project status meetings
would be found in the minutes and reports of various groups.
4. Dissemination modes.
In today’s world, traditional status report meetings are being supplemented by e-mail, teleconferencing,
Lotus Notes, SharePoint, and a variety of database sharing programs to circulate information. In
particular, many companies are using the Web to create a “virtual project office” to store project
information. Project management software feeds information directly to the Web site so that different
people have immediate access to relevant project information. In some cases, appropriate information

is routed automatically to key stakeholders. Backup paper hardcopy to specific stakeholders is still
critical for many project changes and action items.
5. Responsibility and timing.

Determine who will send out the information. For example, a common practice is to have secretaries of
meetings forward the minutes or specific information to the appropriate stakeholders. In some cases,
the responsibility lies with the project manager or project office. Timing and frequency of distribution
appropriate to the information need to be established.
The advantage of establishing a communication plan is that instead of responding to information

requests, you are controlling the flow of information. This reduces confusion and unnecessary
interruptions, and it can provide project managers greater autonomy. Why? By reporting on a regular
basis how things are going and what is happening, you allow senior management to feel more
comfortable about letting the team complete the project without interference. See Table 3.10 for a
sample Project Communication Plan.
OBJECTIVE OF
COMMUNICATI FREQUEN TARGE RESPONSIBI DELIVERAB
COMMUNICATI MEDIUM
ON TYPE CY T LITY LE
ON
Kickoff Meeting Introduce the Face to Once Project Project Manager Agenda
project team and Face Sponsor Meeting
the project. Review Project Minutes
project objectives Team
and management Stake-
approach. holders
Project Team Review status of Face to Weekly Project Project Manager Agenda and
Meetings the project with the Face Team Meeting
team. Conference Minutes
Call
Technical Design Discuss and Face to As Needed Project Technical Lead Agenda and
Meetings develop technical Face Technical Meeting
design solutions for Staff Minutes
the project.

Monthly Project Report on the Face to Monthly Project Project Manager Agenda and
Status Meetings status of the project Face Sponsor Meeting
to management. Conference Project minutes
Call team
Project Status Report the status of Email Monthly Project Team Lead Project Status
Reports the project including Sponsor Report
activities, progress, Project
costs and issues. Team
Stake-
holders
Table 3.10: An Example of a Project Communication Plan
The importance of establishing up-front a plan for communicating important project information cannot
be overstated. Many of the problems that plague a project can be traced back to insufficient time
devoted to establishing a well-grounded internal communication plan.
3.10 Summary
The project scope definition, priorities, and breakdown structure are the keys to nearly every aspect of
managing the project. The scope definition provides focus and emphasis on the end item(s) of the
project. Establishing project priorities allows managers to make appropriate trade-off decisions. The
structure helps ensure all tasks of the project are identified and provides two views of the project—one
on deliverables and one on organisation responsibility. The WBS avoids having the project driven by
organisation function or by a finance system. The structure forces attention to realistic requirements of
personnel, hardware, and budgets. Use of the structure provides a powerful framework for project
control that identifies deviations from plan, identifies responsibility, and spots areas for improved
performance.
No well-developed project plan or control system is possible without a disciplined, structured approach.
The WBS, OBS, and cost account codes provide this discipline. The WBS will serve as the database for
developing the project network which establishes the timing of work, people, equipment, and costs. In
small projects responsibility matrices may be used to clarify individual responsibility.
Clearly defining your project is the first and most important step in planning. The absence of a clearly
defined project plan consistently shows up as the major reason for project failures. Whether you use a

WBS or responsibility matrix will depend primarily on the size and nature of your project. Whatever
method you use, definition of your project should be adequate to allow for good control as the project is
being implemented. Follow-up with a clear communication plan for coordinating and tracking project
progress and risks identified will help keep important stakeholders informed and avoid some potential
problems.
CASE STUDY
Article: Corporate Maturity towards Risk
Source: Klakegg (2015)
Maturity towards risk is achieved through awareness, the consideration that risk management is on the
same level as cost, time and scope management tasks, commitment to high quality of data, systematic
implementation of instruments to deal with risk, development of responses and assessment of the
obtained results (Hulett, 2001). A scarce awareness towards risk drives occasional applications of
informal risk management techniques to specific projects and problems are dealt with only when they
occur. Understanding the relevance of risk, instead, allows to proactively manage uncertainty
(Hopkinson, 2011). The degree of maturity towards risk of an organisation depends on its risk culture,
which is stimulated by the available informational context and the type and size of the organisation
itself.
Several models to assess risk maturity exist in literature (Hillson, 1997; Macgillivray et al., 2007).
Among them, Hillson (1997) proposes four stages: naïve, novice, normalised and natural. Naïve means
that an organisation does not feel the need for managing risk and does not use structured approaches
for this purpose. Novice defines an organisation that recognises the benefits of managing risk and is
implementing some form of risk governance but it lacks a formalised process to perform this task.
Normalised is the degree of maturity characterised by a formalised risk process included in routine
business activities whose benefits, however, are not consistently achieved in every project. Finally, the
natural maturity level refers to an organisation that is completely aware of risk and proactively manages
opportunities and threats through consistent risk information.
Moving from one level to the upper one in a maturity scale implies that an organisation is willing to
perform a more thorough and systemic analysis of the escalation processes of project risks with more
sophisticated and detailed techniques (Hopkinson, 2011; Hulett, 2001). In particular, a high level of risk
awareness together with an appropriate availability of knowledge makes it possible to obtain that

objective information allowing the quantification of risk. Based on this, it can be stated that the more
mature an organisation towards risk, the more the phases of the risk management process it will
implement. Companies with a low maturity degree only perform risk identification or qualitative risk
analysis, while organisations with a high level of maturity deal with all the stages of the risk
management process.
a. Where on the risk maturity model does your organisation fall? Explain in detail and using
examples, how you made that assessment.
Response may vary. Should identify the organisation on one of the following four phases, naïve,
novice, normalised and natural and then justify their choice.
b. To ensure that your organisation is at the “natural maturity level”, clearly outline and discuss
each step in the risk management process that your organisation would have to follow.
 Risk Identification
 Definition: determining what risks may affect the project and assessing the impact of the risk should it
occur.
 Identified risks documented in the risk register - list of all of identified risks, their root causes,
categories and responses, Risk register updated continuously throughout life of project because risk
assessment is an ongoing activity.
 Project team members encouraged to identify risks iteratively as new risks may become known as the
project progresses. Creates sense of ownership and responsibility for both the risks and associated
risk response actions.
 May be internal/external risks that impact on project success
 Inputs to risk identification include project management plan, communication plan, and project
schedule amongst others.
 Risk Analysis
 Using the risk register each risk is now analysed in terms of its probability and impact on the project if
it were to occur.
 It should be performed as soon as possible after risks have been identified so that appropriate time
and resources can be allocated to the more serious risks.
 It uses the probability and impact matrix (PIM) to rank and prioritize risks, and this information is
placed back on the risk register.
 Like all of the activities within risk management, this one should be performed regularly because new
risks will be identified and the characteristics of existing risks may change as the project progresses.

 The availability of time and budget, and the need for qualitative or quantitative statements about risk
and impacts, will determine which method(s) to use
 Risk Response Planning
 Having identified and assessed each risk you need to develop the options and actions to enhance
opportunities and to reduce threats to the project.
 When discussing risk response planning, there are three different risk actions involved. These include
risk response, contingency plan and fall-back plan.
 It is important that planned responses are appropriate to the significance of the risk, cost effective in
meeting the challenge, realistic within the project context, agreed upon by all parties involved, and
owned by a responsible person.
 Range of risk response actions include: For Threats – Avoid, Mitigate, Transfer; For Opportunities –
Exploit, Enhance Share; and for both Threats and Opportunities – Accept.
 Risk Monitoring and Control
 Planned risk responses that are included in the project management plan are executed during the life
cycle of the project, but the project work should be continuously monitored for new, changing, and
outdated risks.
 Periodically assess progress against implementation milestones and project goals
 Project risks do not remain static once the risk planning processes are completed. New risks crop up,
responses may not work as planned and the characteristics of the risk might change.
 Imperative to continually monitor and control the project risks.
I. What comprises the project management framework

II. What could be unforeseen circumstances that jeopardize the project with respect to: Scope,
Cost and Schedule?
III. Why is it critical to develop a baseline plan?
IV. What aspects of a project might involve some degree of uncertainty? Why?

V. Examine the project charter and comment on: Completeness of the information; and Possible
evaluation criteria
1. What is meant by planning a project? What does this encompass? Who should be involved in
planning the work?
2. Why is it important to clearly define the project scope?
3. How are the WBS and the RAM related?
4. Draw a network diagram representing the following logic: As the project starts, activities A and
B can be performed concurrently. When activity A is finished, activities C and D can start. When activity
B is finished, activities E and F can start. When activities D and E are finished, activity G can start.
The project is complete when activities C, F, and G are finished.
5. Why is it a good practice to have the person who will be responsible for performing a specific activity
estimate the duration for that activity?

1. Ten Project Management Knowledge areas mapped across the project life cycle.
2. Possible responses:
 Costs are more than estimated
 Inclement weather
 Additional redesign
 Modifications
 Delivery of critical components is delayed

 Key project team member leaves the project
3. Possible responses:
 Many projects overrun their budgets or miss completion dates
 A baseline plan helps to compare progress
 The graphical or tabular display shows the start and finish dates for each activity
 The amounts of resources are know
 The budget is displayed for each time period and the project
4. Many aspects can have some degree of uncertainty, such as the schedule or the budget.
 An unexpected snowstorm may delay a highway construction project.
 Increased lumber rates may increase the cost of building a new home.
 Not everything in a project can be planned, scheduled, or budgeted.
5.Completeness of information: Describes the project that needs to be addressed; Lists requirements,
constraints, assumptions, and risks; An RFP could be developed from the charter’s information;
Possible evaluation criteria: Meets the purpose; Cost; Reduces delivery costs by 26% the first year;
Experience; Risks; and Appropriate instructional strategies
6. Planning is the systematic arrangement of tasks to accomplish an objective. The plan lays out what
needs to be accomplished and how it is to be accomplished. The people who will be involved in
performing the work should be involved in planning the work.
7. It is important to clearly define the project scope to establish a common understanding among project
stakeholders regarding what needs to be done to produce all the deliverables for the project.
9. The WBS and the responsibility assignment matrix are related. All the work items and work packages
listed in the WBS are also listed in the responsibility assignment matrix.

1.
2. Builds buy-in from the person and generates commitments

 Avoids bias that may be introduced by having one person estimate the durations for all of the
activities
 The designated individual uses experience to estimate the durations
 Historical data can be used as a guide

CHAPTER FOUR
PLANNING METHODOLOGY
Learning Outcomes:
 distinguish the various project planning methodologies
 evaluate the various project planning methodologies
 recognise the benefits of institutionalising organisational project management
 utilise criteria to choose a project planning methodology for a specific project
 understand and apply the assessment process for project planning methodologies

4.1 Introduction
Project management approaches enable organisations to accomplish projects efficiently, addressing
both internal constraints and dynamic external situations in the interim. Project management enables
organisations to prevent or remove internal project constraints and also adapt to unforeseen changes in
project scope or goals. An organisation can, depending on its requirements, either adopt a standard
project management approach or combine multiple approaches. Additionally, an organisation has the
advantage of project management software applications which facilitates intelligent planning, constraint
removal and monitoring of projects.
As the field of project management has grown and developed, a number of different approaches have
arisen. Each has its own unique strengths and drawbacks, and some are more suited for certain needs
than others.
The ever-evolving project management methodology list includes agile, scrum, kanban,
lean, xp,waterfall, PRINCE2 and PMBOK, amongst others. A question often asked is “Why are There
So Many Project Management Frameworks?” Each framework has its own strengths and weaknesses,
but more importantly, projects have their own needs and resources. Some elements that may
determine which framework to employ are the type of business (big vs. small, manufacturing vs.
software), the unique nature of the projects (developing a product versus maintenance), or the different
departments using the method.
For example, the PRINCE2 framework might be used to control costs in an environment where cost
overruns have been common and management is seeking to reduce them. Critical Chain Project
Management (CCPM) might be introduced in an environment where there are many obstacles to
completing a project on time, such as a customer who wants new features or even developing entire
products that are outside the initial scope of the project. In that particular scenario, an agile framework
might be introduced in order to accommodate change rather than a method to overcome change.
To make projects flow faster and with less wasted effort, it would be wise to thoroughly review each
methodology to see if it fits well with your project. Methodologies can always be adapted to a project
team’s workflow process if a single methodology doesn’t perfectly match up. In that way, the project
management methodology’s effectiveness can be maximized.

4.2 Project Planning Methodologies

Selecting the most suitable project management methodology can be tricky (Larson and Gray, 2017). It
depends on so many variables, many of which are outside of our control. It should be kept in mind
though that the project management methodologies are just tools to help us deliver projects. The
argument should not be over the final details of a methodology – instead it should focus on the bigger
picture. Whether it is Kanban, Waterfall, or some other method, it doesn’t really matter. What matters is
a commitment to doing quality work that meets user needs, and delivers great value to the customer.
The best methodology is one that’s continually and organically improving, adapting and through strong
collaboration increases the value of the output so the sum is much greater than the parts. It should be
a methodology that surprises and delights the client by delivering value frequently, and getting it right.
4.2.1 Agile Methodology

Derived from software development, Agile is a popular project management method that views a project
as a series of smaller tasks to be accomplished, and which are designed to fit around the flow of the
situation instead of being constrained to a rigid pre-planned process (Larson and Gray, 2017). Agile
project management is a popular method especially favoured by the software development and creative
industries.
There are two main advantages of this method. Firstly, it is logical, since it constantly examines the
project being developed. Secondly, it is the only project management technique which incorporates
client involvement -- as long as the client is able to invest their time into project involvement.
Agile embodies many different project management methods, including the following:
 Scrum - A complete approach which concentrates on iterative goals as decided by the project
owner. These goals are then refined by the delivery team and carried out by the scrum master
 Crystal clear - which focuses on making sure that relevant information is easy to understand
 Kanban - The method of performing work through a defined set of instructions
 Scrum ban - This technique also uses both the Scrum and Kanban approaches, enabling
projects to be managed in a new and consistent way.

4.2.1.1 Core Values

Agile isn’t actually a methodology at all, but a set of principles for developing software. The agile
manifesto outlines four core values:
 Individuals and interactions over processes and tools;
 Working software over comprehensive documentation;
 Customer collaboration over contract negotiation; and
 Responding to change over following a plan.
Therefore, being agile is more of a philosophy and set of values and principles to follow, rather than a
process to apply to a project.
4.2.1.2 Methodology
Figure 4.1: Agile Project Management Methodology

Source: Harper (2017)
Figure 4.1 illustrates the flexible, iterative design and build process of Agile. Agile projects are
characterized by a series of tasks that are conceived, 1executed and adapted as the situation
demands, rather than a pre-planned process. Being agile helps teams respond to unpredictability

through incremental, iterative work processes. In much the same way that a good cook tastes the food
as they cook it, adding missing ingredients as they go along, an agile project management
process requires project teams to cycle through a process of planning, executing, and evaluating as
they go along.
4.2.1.3 Application
Agile is different from other project management methods which usually assume that things affecting
the project are predictable, and so it emphasizes adaptability to changing situations, adequate and
ongoing communication among the project team and between them and the client (Larson and Gray,
2017). Agile methodologies are great to use in dynamic environments where there’s potential for
changing or evolving requirements such as software and game development.
Agile project management focuses on adaptability to changing situations and constant, regular
feedback – whether it’s from the client or from other members of the team. This is ideal when clients or
management need to be in on the production process, resulting in changing requirements and drastic
shifts in team assignments. Agile project management is usually ideal for smaller software projects
and/or those with accelerated development schedules.
4.2.2 Waterfall Methodology

What is the most common way to plan out a project? Sequence the tasks that lead to a final deliverable
and work on them in order (Larson and Gray, 2017). This is the Waterfall methodology — the traditional
method for managing projects and the one that is simplest to understand. One task must be completed
before the next one begins, in a connected sequence of items that add up to the overall deliverable. It’s
an ideal method for projects that result in physical objects (buildings, computers), and project plans can
be easily replicated for future use.
The power of this methodology is that every step is pre-planned and laid out in the proper sequence.
While this may be the simplest method to implement initially, any changes in customers’ needs or
priorities will disrupt the sequence of tasks, making it very difficult to manage.

4.2.2.1 Core Values

Waterfall, often referred to as SDLC (Software Development Life Cycle) is a project management
methodology theme with a very simple approach that values solid planning, doing it once and doing it
right, rather than the agile approach of incremental and iterative delivery (Larson and Gray, 2017). It’s
simple to understand because you simply make a good plan, and execute on it.
The strong points in waterfall project management methodology is that:
 It stresses rigorous documentation – for example requirements or design document, along with
source code. This way, project knowledge can be easily passed on to new team members – in
case anyone leaves the project before completion.
 It moves forward in a linear way – this makes projects easy to understand and its phases are
self-explanatory. It’s also easy to identify project milestones as moving forward always implies
completing a step.
4.2.2.2 Methodology
Waterfall methodology is the one that is the most used across all industries, and it is very common in
software development and construction. There are many versions of the waterfall method, but the
original one included these high-level phases (Figure 4.2):
Figure 4.2: Waterfall Project Management Methodology
 Requirements specification
 Design
 Construction (AKA or coding)
 Integration

 Testing and debugging (AKA Validation)

 Installation
 Maintenance
The project manager tends to be large and in charge, and work is planned extensively up front and then
executed, in strict sequence, adhering to requirements, to deliver the project in a single, and usually
very long cycle.
Requirements are defined in full at the beginning, at the top of the waterfall, before any work starts.
Work then cascades, like water down a waterfall through phases of the project. In a waterfall model,
each phase must be completed before the next phase can begin and there is no overlapping in the
phases. Typically, in a Waterfall approach, the outcome of one phase acts as the input for the next
phase sequentially.
After the plan is approved, there’s little scope to adapt the plan unless absolutely necessary, and
changes that are needed usually require change requests. The project then flows through the process
from requirements, through design, implementation, testing and into maintenance.
Because of the single cycle approach, in a Waterfall project, there’s little scope to reflect, revise and
adapt once you’ve completed something. Once you’re in the testing stage, it is very difficult to go back
and change something that was not well designed in the concept stage. There’s also nothing to show
and tell the client as you go along. You complete the project with big fanfare and pray the client likes it.
That’s potentially very risky.
Waterfall is generally regarded with some disdain within agencies as an inefficient and passé traditional
project management approach. But Waterfall can be a useful and predictable approach if requirements
are fixed, well documented and clear and the technology is understood and mature.
4.2.2.3 Application
Traditional, or “waterfall” project management handles things sequentially, from the concept and
planning phase through to development and quality assurance and finally project completion and
maintenance. Project requirements are usually defined at the beginning, with little to no alterations to

the plan unless absolutely necessary. The waterfall methodology is used most often for large-scale
software development projects where thorough planning and a predictable process are paramount.
Waterfall project management is recommended for projects with fixed scope and requirements or for
fixed and stable projects with little change. Also, once the requirements are established, projects that
run on waterfall don’t need extensive client presence.
4.2.3 Scrum Methodology

Scrum is a type of agile methodology that focuses around 30-day "sprints" and monthly "scrum
sessions" where project deliverables are broken down into 30-day intervals (Schwalbe, 2017). When
teams switch to scrum, those previously paralyzed by heavy "process" or difficulty in prioritizing work,
can see great gains in productivity. In Scrum, there is no title of project manager. Instead there is a
"Scrum Master" whose role is to facilitate the daily project communications and tackle any distractions
that are trying to interfere with team members’ ability to do work on the project.
Scrum isn’t really a project management methodology but a framework for the ongoing development
and maintenance of complex products. Scrum is a light approach and defines a simple set of roles,
meetings, and tools to efficiently, iteratively and incrementally deliver valuable, shippable functionality.
It is a project management methodology which proposes principles and processes to improve delivery.
Within software development, it is one of the most popular and simple frameworks to put the principles
of Agile into practice.
The goal of Scrum is to improve communication, teamwork and speed of development. Sprints, scrums,
backlogs and burn-downs are all derivatives of Scrum. Fundamentally, Scrum is about empowering a
self-managing team to deliver and define roles and responsibilities to create a healthy tension between
delivering the right thing, the right way, as fast as possible.
4.2.3.1 Core Values

There are five (5) core values (Schwalbe, 2017);
 Courage,
 Commitment,
 Focus,
 Openness, and Respect.

Committing yourself to the team and Sprint Goal (commitment). Focusing on keeping the customer
happy and being focused on the sprint and its goal (focus). Telling everyone everything about all your
work (openness). Highlighting when you have challenges and problems that are stopping you from
success. Helping people to learn the things that you are good at and not judging the things that others
aren’t good at (respect). Even after the decision has been made continuing to push back (courage).
Being transparent, but willing to change even if that means accepting that you are wrong, or that your
opinion is not the direction that the team is going.
4.2.3.2 Methodology
Figure 4.3: Scrum Project Management Methodology

Scrum advocates using a small, cross-functional team of up to 9 people who work on items in a backlog
a collection of user stories (requirements) – that have been defined and prioritized by a Product Owner.
Work is divided into ‘sprints’, a development cycle of usually 2-4 weeks, during which, daily ‘scrums’
take place where the team report on progress and impediments. At the end of each sprint, work is then
reviewed in a sprint review meeting to determine together with the Product Owner if it passes the
Definition of Done (DoD).

Scrum is facilitated and served by a Scrum Master who enables and leads the scrums, sprint demo’s
and reviews, leading the development team to do their best work as well as a leading a ‘sprint
retrospective’ after each sprint, to ensure the team is continually optimizing and improving.

4.2.3.3 Application
Scrum is applicable only in certain types of environments - mainly those with co-located, 100%
dedicated team members (not working of multiple projects), with unlimited support for the project team
(not a heavily constrained time and materials budget).
Scrum was originally designed for software development so while there are agile artefacts from scrum
that can be leveraged – scrum doesn’t fit neatly into the typically more strategic and creative agency
world. Even on agency web projects, fixed budgets, timelines and scope provide a lack of flexibility for a
scrum self-managing team, on a project with a defined beginning and end.
That’s not to say it can’t work on development projects – agency project managers can act as scrum
masters, and clients as product owners in one big happy hybrid team. But it’s normally more
complicated than that, with fixed budgets and scope providing heavy constraints. That’s why many
agencies take some of the concepts of scrum – small, self-organizing, cross functional teams, daily
stand-ups, progress demos and retrospectives and use them in some kind of hybrid approach.
4.2.4 PRINCE2 Methodology

“PRINCE” stands for PRojects INControlled Environments. It is a very process-oriented methodology,
dividing projects into multiple stages, each with their own plans and processes to follow. The
methodology defines inputs and outputs for every stage of a project so that nothing is left to chance.
PRINCE2 is a ‘full stack’ waterfall project management methodology that includes principles, themes
and processes. It was created by the UK government in 1996 originally for IT projects.
The core elements of PRINCE2 concentrate on business justification, defined organisational structure,
product-based planning, executing the project by dividing it into bite-size components, and remaining
flexible at all levels of the project. For organisations, PRINCE2's recognition of responsibilities within a
project, along with its focus on project deliverables (the WHY, WHEN and FOR WHOM) provides an
organisation with tangible benefits of control, consistency and structure of both tasks and review cycles.

4.2.4.1 Core Values

PRINCE2 derives its methods from 7 core principles. Collectively, these principles provide a framework
for good practice (Schwalbe, 2017):
 Continued Business Justification;
 Learn from Experience;
 Define Roles and Responsibilities;
 Manage by Stages;
 Manage by Exception;
 Focus on Products; and
 Tailor to the Environment.
Continued Business Justification: A project must make good business sense. There needs to be a clear
return on investment and the use of time and resources should be justified. Learn from Experience:
Project teams should take lessons from previous projects into account. A lessons log is kept updated
for this purpose. Define Roles and Responsibilities: Everyone involved in a project should know what
they and others are doing. This includes knowing who the decision makers are. Manage by Stages:
Difficult tasks are better off broken into manageable chunks, or management stages. Manage by
Exception: A project running well doesn’t need a lot of intervention from managers. The project board is
only informed if there is or might be a problem. Focus on Products: Everyone should know ahead of
time what’s expected of the product. Product requirements determine work activity, not the other way
around. Tailor to the Environment: PRINCE2 can be scaled and tailored. Projects that adapt PRINCE2
to their needs are more likely to succeed than projects that use PRINCE2 dogmatically.

4.2.4.2 Methodology
Figure 4.4: PRINCE2 Methodology

The system emphasizes justification of the course taken by a business, and so the first step is
identifying a clear need for the project, who the target customer is, whether there are realistic benefits,
and a thorough cost assessment. A project board owns the project and is responsible for its success.
This board defines the structures for the team, while a project manager oversees the lower level day-to-
day activities. This methodology is based on eight high-level processes and gives team’s greater
control of resources and the ability to mitigate risk effectively.
As a methodology, it’s incredibly thorough – it’s a great framework for how to run large, predictable,
enterprise projects. It clarifies, what will be delivered, ensures a focus on the viability of the project,
clearly defines roles and responsibilities, endorses management by exception (arguably an agile
principle) and similarly to PMBOK, provides a common vocabulary which we can apply to other
methodologies. On the flipside, while the principles and themes are great, the process can make it
laborious and onerous for small projects.
4.2.4.3 Application
PRINCE2 is designed for large scale IT projects so would never work in an agency as a project
management methodology. However, the emphasis on developing a good business case with KPI’s

and value earned, clear roles and responsibilities, managing change and risk are helpful when we
consider managing projects for our clients.
4.2.5 PMBOK Methodology

PMBOK stands for Project Management Body of Knowledge. This approach centre’s on common
project management skills, such as budgeting and managing inputs and outputs, and it's commonly
used in the United States of America. Much of the PMBOK Guide is unique to project management
e.g. critical path method and work breakdown structure (WBS). The PMBOK Guide also overlaps
with general management which both including planning, organising, staffing, executing and controlling
the operations of an organisation. Other management disciplines which overlap with the PMBOK Guide
include financial forecasting, organisational behaviour, management science, budgeting and other
planning methods.
As an internationally recognised standard (ANSI/PMI 99-001-2008 and IEEE 1490-2011) it provides the
fundamentals of project management, irrespective of the type of project be it construction, software,
engineering, automotive.
4.2.5.1 Core Values

Project Management Institute has defined a Code of Ethics and Professional Conduct that all members
of PMI are expected to adhere to when managing projects. This Code is intended to address moral,
ethical and cultural competencies. In general, this code is intended to instil confidence in the
profession of project management by providing a common frame of behaviour for project managers. In
general, compliance with this code should facilitate each practitioner becoming more proficient as they
comply with the code. The Code addresses the areas of:
 responsibility,
 respect,
 fairness,
 honesty and
 Cultural competence.
Responsibility deals with taking the best actions for a specific situation; taking actions supported by
knowledge; fulfilling project and professional requirements; protecting sensitive information; upholding

the Code; compliance with all applicable laws and regulations (mandatory); and reporting unethical or
illegal behaviour (mandatory). Respect looks at keeping informed about cultural norms and customs;
listening to stakeholders; addressing conflict as required; behaving professionally at all times;
negotiating in good faith with customers and suppliers (mandatory); refraining from personal enrichment
(mandatory); not acting abusively (mandatory); and respect others property rights (mandatory).
Fairness considers making decisions in a transparent manner; act impartially; provide equal access to
information; provide equal opportunity when acquiring resources; avoid conflicts of interest (mandatory);
act fairly when hiring, do not base decisions on personal considerations (mandatory); do not
discriminate against individuals based on social prejudices (mandatory); and Apply rules impartially
(mandatory).
Honesty requires the project manager to seek the truth; speak the truth; make commitments in good
faith; and to not engage in or condone dishonesty (mandatory). Finally, Cultural Competence requires
the project manager to be aware of cultural differences; respect other cultures ways of behaviour and
moral interpretations; maintain professional sensitivity when dealing with other cultures; practice cultural
awareness in all project situations; and many professional responsibility questions can be answered
simply by using common sense. These questions will be incorporated into project scenarios. The best
choice is usually to choose to do the right thing.
4.2.5.2 Methodology
Figure 4.5: PMBOK Methodology

PMBOK recognises five basic process groups and ten knowledge areas typical of almost all projects.
The basic concepts are applicable to projects, programmes and operations. The five basic process
groups are:
1. Initiating
2. Planning
3. Executing
4. Monitoring and Controlling
5. Closing
Processes overlap and interact throughout a project or phase. Processes are described in terms of:
 Inputs (documents, plans, designs, etc.)
 Tools and Techniques (mechanisms applied to inputs)
 Outputs (documents, products, etc.)
The ten knowledge areas are:

1. Project Integration Management
2. Project Scope Management
3. Project Time Management
4. Project Cost Management
5. Project Quality Management
6. Project Human Resource Management
7. Project Communications Management
8. Project Risk Management
9. Project Procurement Management
10. Project Stakeholder Management (added in the 5th edition)
Each knowledge area contains some or all of the project management processes. For example, Project
Procurement Management includes:
 Plan Procurements
 Conduct Procurements
 Administer Procurements
 Close Procurements

4.2.5.3 Application
The PMBOK is the broadest and most widely used standard reference of industry best practices for PM
(PMI: 2013). It sets out good practices and guidelines that are applicable to a wide range of industries
and markets and cross multiple departments, from IT to production. Different industries can leverage
different aspects of the PMBOK to suit their specific needs.
4.2.6 Other Project Management Methodologies

 Kanban: improving speed and quality of delivery by increasing visibility of work in progress,
and limiting multi-tasking. It is focused on lean principles and a strict process to increase
efficiency. It’s similar in many ways to Scrum – it’s all about releasing early and often with a
collaborative and self-managing team. But compared to Scrum, Kanban is a more evolutionary
change, a softer landing into the world of agile as it’s less prescriptive. Kanban is well-suited to
work that requires steady output, like production or support and maintenance. Within the world
of agencies, it can also be a helpful tool as it’s more accommodating to changes, and clients
like to change their minds constantly. If Scrum seems too rigid an approach, but you want to
‘do agile’, Kanban is a simpler alternative.
 Lean Methodology: Lean is a project management methodology focused around the theme of
efficiency. Lean is all about doing more with less. It starts by identifying value and then
maximizes it through continuous improvement by optimizing the flow of value and eliminating
wastage. Focus is shifted from optimizing separate technologies, assets, and vertical
departments to optimizing the flow of projects through the entire value streams that flow
horizontally across technologies, assets, and departments to customers.
 Critical Chain Project Management (CCPM): Critical Chain Project Management, developed
by Dr Eli Goldratt, who proposed the theory of constraints, as an alternative to perceived
failures in the traditional approach. The system works by identifying the Critical Chain (defined
as the longest chain of dependent tasks), then cutting task estimates in half, and inserting
"safety buffers" between tasks. Priorities are set and execution is carried out with continual
focus on each task until completion. This is backed up with continual reviews that ensure
projects stay on target and deviations are addressed in the shortest possible time.
 Extreme Project Management (XPM): Extreme project management is often used by
industries that deal with constant change; examples are the mobile phone and software
industries. The common theme in these businesses is that it isn't easy to gain a proper and

stable understanding of requirements, and outcomes may be heavily affected by changes in

external factors, especially the market. XPM requires an acceptance of high unpredictability
and therefore a need for fluidity and rapid change. A main focus is on the human side of project
management (e.g. managing stakeholders), rather than on formal and often theoretical
processes for scheduling tasks and assessing progress.
 Six Sigma: Six Sigma is a disciplined, data-driven product and process-improvement
methodology that was originally developed by Motorola. The idea was to improve processes by
eliminating defects which are defined as "nonconformity of a product or service to its
specifications." The process steps go by the acronym DMAIC-S, which stands for Define,
Measure, Analyse, Improve, Control, and when it is done to Synergize through the
organisation.
 DMAIC: This is part of the Six Sigma methodology, but it also is often used as a stand-alone
method. DMAIC (an abbreviation for Define, Measure, Analyse, Improve and Control) refers to
a data-driven improvement cycle used for improving, optimizing and stabilizing business
processes and designs. It and can be used as the framework for improvement projects outside
of Six Sigma. The framework is described briefly here: Define – who are the customers and
what are their needs; the project purpose and scope. Measure – how is the process
performing and how is it measured; gather data on how well the current process performs in
meeting customer needs. Analyse –Identify root causes of performance gaps and confirm with
data. Improve- Plan, test, and implement solutions that eliminate root causes. Control –
Maintain the gains by standardizing work methods or processes; anticipate future
improvements and preserve the lessons from this effort.
 Critical Path Method (CPM): The critical path method developed in the 1950s is based on the
concept that there are some tasks you can’t start until a previous one has been finished. When
you string these dependent tasks together from start to finish, you plot out your critical path.
Identifying and focusing on this critical path allows project managers to prioritize and allocate
resources to get the most important work done, and reschedule any lower priority tasks that
may be clogging up your team’s bandwidth. This way, if changes need to be made to the
project schedule, you can optimize your team’s work process without delaying the end results.

4.3 Evaluation the Prooect Planning Methodologies

Choosing the right project management methodology is important because it defines how we work
(Larson and Gray, 2017). Project management methodologies provide the structures that can guide us
toward project success or failure. When deciding what project management methodology to use in a
project, we need to consider the simplicity or complexity of the project, the client, our available
resources and the project constraints (including the appetite for change and risk), timeline, tools, and
people.
When it comes to project management methodologies, there is no one-size-fits-all that works for all
business types, sizes or industries. Whether you’re working in a dynamic environment where there’s
appetite for evolution and change, and adopt an agile methodology, or if you’re working within very
fixed, rigid, requirements, timeline and budget and adopt a waterfall approach, each project
management methodology carries its own strengths and weaknesses. Ultimately, the methodology
chosen should be analysed on the basis of its ability to deliver the most value to the client, with the
least impact on those delivering it, how well it meets organisational goals and values, the constraints
the project team has to deal with, the needs of stakeholders, the risks involved, the project size, cost,
and of course, the complexity of the project.
The Project Management Institute (PMI) has developed a globally recognized standard called
the Organisational Project Management Maturity Model (OPM3). This assists organisations’ in
identifying, measuring and improving PM capabilities and standardizing processes. It helps solidify
successful project outcomes, ultimately determines best practices, and strengthens the connection
between strategic planning and execution.
4.4 Benefits Organisation Project Management (OPM3)

A primary goal of OPM3 is to achieve successful strategic alignment and successful project outcomes
depend heavily on such alignment. Organisations will need to include enterprise program management
offices (EPMOs) in high-level planning sessions to ensure the right methodologies are deployed for
specific projects to increase productivity and customer satisfaction, gain a competitive advantage,
improve cost control and communications and predict performance. Ultimately, this will improve and
expedite decision making as well as support alignment with company-wide goals.

Because of the various strengths and weaknesses of each PMM, organisations may want to consider
adopting multiple project management methodologies based on the unique nature of their project,
organisational makeup and project goals. Either way, organisations need to develop standardized best
practices that can be refined as various factors change. Here, the key is to figure out how a specific
project aligns with company-wide objectives. Once success or failure criteria can be isolated, it’s easier
to find the most suitable methodology or methodologies that will enable your organisation to effectively
and efficiently reach the desired business result.
4.5 Key Considerations in Choosing Project Planning Methodologies

When evaluating methodologies, just a few of the numerous factors that should be carefully considered
are listed below (Larson and Gray, 2017):
 Organisational strategic goals and core values
 Key business drivers
 Constraints
 Stakeholders
 Risks
 Complexity
 Project size and cost
Key steps usually followed by project managers are to:

 Find out from team members what has worked in the past – This will help narrow down the
choices you have to make.
 Clearly define the needs or expectations of your clients – Keep in mind the fact that
requirements could be fixed or dynamic.
 Outline organisational goals, keeping in mind project costs as well.
 Consider the structure of the team – Are they virtual or physical? Is some of the work being
outsourced?
 Lastly, you need not decide on a one size fits all kind of approach; keep in mind that it is
perfectly acceptable to pick the various positive elements from all the individual methodologies
to create a process that could work well for your team.

4.6 Project Planning Methodlogy Assessment Process

Once the assessment criteria have been factored into the decision, you need to develop a process to
identify the best PMM option(s) for your specific project. This process will need to be revisited and
modified from time to time to keep up with evolving business and stakeholder needs. Here are some
general steps:
1. Determine project drivers by identifying and weighing primary goals and priorities of the project.
2. After determining project drivers, requirements and goals, identify all the criteria that a
methodology will impact and vice versa.
3. Identify all available/possible methodologies that are most relevant for the project.
4. Spend time comparing and contrasting each PMM in relation to the project.
5. Consider which methodology will yield the best results and offer the least risk.
6. Gain feedback and buy-in.
7. Document the methodology and rationale.
8. Implement the methodology.
9. Monitor and modify as required.
The following criteria (internal and external) as outlined in figure 4.6, should be factored in when
selecting an appropriate project planning methodology:

Figure 4.6: PMBOK Methodology
4.7 Summary
Selecting the most suitable project management methodology can be tricky. It depends on so many
variables, many of which are outside of our control. What matters is to a commitment to doing quality
work that meets user needs, and delivers great value to our clients. The best methodology is one that’s
continually and organically improving, adapting and through strong collaboration increases the value of
the output so the sum is much greater than the parts. It’s a methodology that surprises and delights the
client by delivering value frequently, and getting it right. And to do this you need to be pragmatic, rather
than dogmatic about the methodology you use. Many organisations have begun to adopt a hybrid
project management approach, by combining the best features of standard project management
approaches. This approach has been beneficial and indeed goes to show how flexible the project
management approaches are. As you can see, there is no "one size fits all" method when it comes to

project management and some industries favour one technique over the other. What is common, of
course, is that they all aim to manage the project in an efficient way, and if they are properly
implemented by people who fully understand them, the upfront investment in planning and
management will repay itself many, many times over in greater efficiency and effectiveness.
1. Clearly differentiate between the agile and waterfall project management methodologies.
2. What are some of the key considerations in choosing a project planning method?

CHAPTER FIVE
PROJECT PLAN EXECUTION
Learning Outcomes:
 Explain project execution, its relationship to project planning, the factors related to successful
results, and the tools and techniques to assist in managing project execution
 Implement project plan execution activities
 monitoring and controlling activities for project plan execution
 implement best practice for successful project execution

5.1 Introduction
The direct and manage project execution process refers to the actual process of executing the
individual work components that are required to advance the process of the project’s development. The
ultimate goal of directing and managing the project’s execution is to guide the project to fulfil and meet
the predetermined and pre-set requirements that were set forth by the project sponsor or customer at
the onset of the project. The act of directing and managing project execution can be conducted by the
project manager, an individual team member delegated to manage individual components, or by the
project team as a whole. Regardless of who directs and manages project execution, a clean and
efficient execution of the project is essential.
Following the guidelines of the project management plan is crucial when creating the deliverables.
Project deliverables are subjected to the organisational processes as well as constraints. It also
involves the implementation of approved changes in order to achieve the objectives of the project.
Project execution requires inputs such as the project management plan, approved change
requests, enterprise environmental factors and organisational process assets. There are also certain
tools involved in this process. Project managers may use expert judgment and hold different meetings
to inform, consult, design and approve changes. The process leads to the creation of work
performance data and change requests; updates to the project management plan and other project
documents which form the outputs of execution.Fundamentally, project plan execution is the primary
process for carrying out the project plan—the vast majority of the project’s budget will be expended in
performing this process. In this process, the project manager and the project management team must
coordinate and direct the various technical and organisational interfaces that exist in the project. It is
the project process that is most directly affected by the project application area in that the
product/service/result of the project is actually created here.
5.2 Project Plan Execution Activities

The project manager together with the project team, directs and manages the technical and
organisational interfaces within the project. Unplanned activities should also be managed and the
appropriate course of action determined. Activities engaged in include:
 performing activities to accomplish project deliverables
 creating deliverables to meet planned project work
 training and managing team members
 optimum resource utilisation (tools, materials, equipment, facilities)

 implementing planned methods and standards

 establishing and managing communication channels (internal and external to project team)
 generating work performance data (cost, schedule, technical and quality progress, status) to
facilitate forecasting
 issuing change requests and implementing approved changes
 managing risks and implementing risk response activities
 managing sellers and suppliers
 managing stakeholder engagements
 Collecting and documenting lessons learned and implementing approved process improvement
activities (PMI, 2013).
The impact of project changes and the implementation of approved changes are also reviewed during
the project plan execution process in terms of the corrective or preventative action taken or the defect
repaired.
5.3 Inputs, Tools and Techniques and Outputs for Project Plan Execution
Project Plan Execution or Direct and Manage Project Work (PMI, 2013) is the process of leading and
performing the work defined in the project management plan and implementing approved changes to
achieve the project's objectives. The key benefit of this process is that it provides overall management
of the project work. The inputs, tools and techniques, and outputs of this process are depicted in Figure
5.1.
OUTPUTS:
INPUTS: 1.Deliverables
1.Project Management Plan TOOLS & TECHNIQUES:
2.Approved Change Requests 1.Expert Judgement 2.Work Performance Data
3.Eterprise Environmental Factors 2.Project Management Information 3.Change Requests
4.Organisational Process Assets System
4.Project Management Plan
3.Meetings Updates
5.Project Documents Updates
Figure 5.1: Project Plan Execution: Inputs, Tools & Techniques and Outputs

5.3.1 Inputs to Project Plan Execution

 Project Management Plan: guides in the management, execution, and monitoring and
controlling of the project. Since the primary concern of the process is with the
execution of the project plan, it is an essential input into this process.
 Approved Change Requests: scheduled for implementation by the project team. They
are documented and authorised changes to expand or reduce project scope.
 Enterprise Environmental Factors: The enterprise environmental factors which can
influence this process are:
 stakeholder risk tolerances
 organisational, company or customer culture and structure
 project management information systems
 infrastructure
 Organisational Process Assets: The organisational process assets that can influence
this process are:
 standardized guidelines and work instructions
 communication requirements
 issue and defect management procedures
 project files from previous projects
 issue and defect management database
5.3.2 Tools and Techniques for Project Plan Execution

 Expert Judgement: Expert judgement is applied to all technical and management
details during this process. Expert judgement is provided by the project management
team using specialized knowledge or training. Additional expert judgement is available
from many sources including consultants, stakeholders and professional and technical
associations.
 Project Management Information System (PMIS): The PMIS is used to provide access to
tools such as a scheduling software tools, configuration management system,
information collection system etc.

5.3.3 Outputs of Project Plan Execution

 Deliverables: An approved deliverable is one of the most important outputs of this
process. It is any unique and verifiable product, result or capability to perform a service
that must be produced to complete a phase, process or project.
 Work Performance Information: Work performance Information is the information on
the status of the deliverables. This information includes: Deliverable status, schedule
progress, Costs incurred.
 Change Requests: When issues are found while project work is performed, change
requests are issued which may modify project policies or procedures, project scope,
project cost or budget, project schedule or project quality.
 Project Management Plan Updates: In this process, the project management plan is
updated. Some of the elements that are updated include requirement management
plan, schedule management plan, cost management plan etc.
 Project Document Updates: Some of the project documents that are updated in this
process are requirement documents, project logs, risk register and stakeholder
register.
5.4 Monitoring and Controlling Activities for Project Plan Execution

Monitoring project work includes collecting, measuring, and disseminating performance
information (Larson and Gray, 2017). It also involves assessing measurements and analysing
trends to determine what process improvements can be made. The project team should
continuously monitor project performance to assess the overall health of the project and
identify areas that require special attention.
The project management plan, performance reports, enterprise environmental factors, and
organisational process assets are all important inputs for monitoring and controlling project
work.
The project management plan provides the baseline for identifying and controlling project
changes. A baseline is the approved project management plan plus approved changes. For
example, the project management plan includes a section describing the work to perform on a

project. This section of the plan describes the key deliverables for the project, the products of
the project, and quality requirements. The schedule section of the project management plan
lists the planned dates for completing key deliverables, and the budget section of the project
management plan provides the planned cost for these deliverables.
The project team must focus on delivering the work as planned. If the project team or someone
else causes changes during project execution, they must revise the proje ct management plan
and have it approved by the project sponsor (Larson and Gray, 2017). Many people refer to
different types of baselines, such as a cost baseline or schedule baseline, to describe different
project goals more clearly and performance toward meeting them.
Performance reports use this data to provide information on how project execution is going.
The main purpose of these reports is to alert the project manager and project team of issues
that are causing problems or might cause problems in the future. The project manager and
project team must continuously monitor and control project work to decide if corrective or
preventive actions are needed, what the best course of action is, and when to act.
An important output of monitoring and controlling project work is a change request, which
includes recommended corrective and preventive actions and defect repairs. Corrective actions
should result in improvements in project performance. Preventive actions reduce the
probability of negative consequences associated with project risks. Defect repairs involve
bringing defective deliverables into conformance with requirements. For example, if project
team members have not been reporting hours that they worked, a corrective action would be to
show them how to enter the information and let them know that they need to do it. A preventive
action might be modifying a time-tracking system screen to avoid common errors people made
in the past. A defect repair might be having someone redo an entry that was incorrect. Many
organisations use a formal change request process and forms to keep track of project changes
(Schwalbe, 2017).
5.5 Successful Project Execution
"If you don't have time to do it right, when will you have time
Think Point
to do it over?" - John Wooden

“The best laid plans of mice and men,” teaches you that that no matter how well you prepare,
your efforts can easily go off the rails without focused attention and proper follow-up along the
way. Execution is the gap between promises and results. There are some common elements
that ensure success. These include:
 Active Sponsorship: Making sure that somebody up top will not put a kibosh on a
project because it wasn't his or her idea. Make sure somebody high up believes in and
champions the project.
 Competent Project Personnel: Having not just subject matter experts, but people who
know the art and science of working with others to achieve resu lts is critical.
 Sufficient Resources and Funding: Assigning and funding resources is always a
challenge, so keep the expectations realistic.
 Clear Roles and Responsibilities: The road to hell is paved with good intentions.
Even well-meaning people can trip on each other if their roles are not clear. It should
be especially clear who is driving the bus and who is riding it.
 Proactive Risk Management: Identify the potential risks ahead of time and be
prepared to deal with them. As they say, it is better to fix the roof before it starts
raining.
 Change Management: Projects by definition change the status quo. Any time there is
a change to the status quo, it creates disruption. Make a plan to manage the change
consciously rather than burying your head in the sand.
 Realistic Project Plan: Miracles do happen, so hope for the best, but prepare for the
worst!
 Vigilant Tracking: Identify what can be measured during the progression of the project
and track it methodically. What gets measured gets done.
 Timely Issue Resolution: Issues will arise, so deal with them before they grow out of
control. Remember the old saying: a stitch in time saves nine.
5.6 Summary
Directing and managing project execution involves managing and performing the work
described in the project management plan, one of the main inputs for this process. Other
inputs include approved change requests, enterprise environmental factors, and organisational

process assets. The majority of time on a project is usually spent on execution, as is most of
the project s budget. The application area of the project directly affects project execution
because the products of the project are produced during project execution. Many unique
situations occur during project execution, so project managers must be flexible and creative in
dealing with them.
1. What is the project execution process all about?

2. Why is this process important?
3. When is the process performed?

1. In this process, the team is executing the work packages, and creating the project deliverables.
2. This is the process where things get done. In this process software applications are built,
buildings are constructed and work packages are executed. Businesses of all sizes and in all
industries, make huge financial and human investments in projects. Whether it's a small
business rolling out a new version of the product or a huge conglomerate trying to outsource
back-office accounting to India, they all feel the pain when a project doesn't live up to its hype.
The direct costs of these setbacks are just the tip of the iceberg. They create serious
implications for a company's stability, customer experience, and employee morale. Most
importantly, the leaders lose credibility. And once credibility is lost, it is very difficult to restore it.
3. This process is performed whenever the project management plan is followed to create project
deliverables.

CHAPTER SIX
PROCTECT INTERGRATED CHANGE CONTROL
Learning Outcomes:
 adequately define, review and gain approval for each change proposed during a project before
implementation
 Utilise the inputs, tools and techniques for controlling integrated change so as to ensure
specific outputs
 Engage in the integrated change control process
 Manage scope change control and its subsequent impact on project deliverables
 Implement integrated change control best practices

6.1 Introduction
The one thing that you can be sure will happen during a project is change. Despite the best laid plans,
changes will still occur. Changes may be initiated by the customer, the project team, caused by
unanticipated occurrences during the performance of the project, or required by the users of the project
results.
The change control process in project management ensures that each change proposed during a
project is adequately defined, reviewed and approved before implementation. The change control
process helps avoid unnecessary changes that might disrupt services and also ensures the efficient
use of resources. While change may help ensure the projects alignment with business needs, it is
important to consider and approve each change carefully.
An important aspect of the project manager’s job is to manage and control changes. Generally, the
later in the project that changes are identified, the greater their impact on accomplishing the project
objective. The aspects most likely to be affected are the project budget and the completion date. At the
start of the project, procedures need to be established regarding how changes will be documented and
authorised. These procedures must cover communication between the project manager and the
customer and between the project manager and the project team.
Whenever a customer requests changes, the project manager should have the appropriate project
team members estimate the effects on the project cost and schedule. The project manager needs to be
sure that team members will not casually agree to changes that may require additional work hours.
Open communication and a climate of trust are prerequisites for introducing change, reducing
resistance to change, and gaining commitment to the change. If possible, the project manager should
have users participate up front in the decision to make changes (Gido and Clements, 2015).
Not all changes follow the approved process. Often team members will be persuaded to make a
change without using the approved procedure where it seems necessary but minor. Although this can
seem practical to those concerned, it represents a risk to the project. The Project Manager and Project
Office team should be alert for uncontrolled changes. Where necessary, changes should be painlessly
re-directed into the correct procedure. The Change Control process will run continuously during the
project, and potentially beyond that into live running. The Project Office team and the Project Manager
will administer and control the process.

6.2 Inputs, Tools & Techniques and Outputs for Integrated Change Control
The inputs, tools and techniques, and outputs of the integrated change control process are depicted in
Figure 6.1 (PMI: 2013).
TOOLS & TECHNIQUES: OUTPUTS:

INPUTS: 1.Approved Change Requests
1.Expert Judgement 2.Change Log
1.Project Management Plan 2.Meetings
2.Work erformance Reports 3.Project Management Plan
3.Change Control Tools
3.Change Requests Updates
4.Project Documents Updates
Figure 6.1: Perform Integrated Change Control: Inputs, Tools & Techniques and Outputs
6.2.1 Inputs to Integrated Change Control
 Project Plan. The project plan provides the baseline against which changes will be controlled.
Elements of the plan that may be used include the scope management plan with procedures for
scope changes; the scope baseline providing product/service/result definition; and the change
management plan providing direction for managing and documenting change control.
 Work Performance Reports. Performance reports which include resource availability,

schedule, cost data, Earned Value Management (EVM) reports and burn-down charts, provide
information on project performance. Performance reports may also alert the project team to
issues which may cause problems in the future.
 Change Requests. Change requests may occur in many forms—oral or written, director
indirect, externally or internally initiated, and legally mandated or optional. They may include
corrective action, preventative action, or defect repairs.
6.2.2 Tools & Techniques for Integrated Change Control

 Expert Judgement: Besides the experts on the project team, other stakeholders may be asked
to provide their expertise and judgement. These stakeholders may include consultants,

customers, sponsors, professional and technical associations, industry groups, subject matter
experts (SME) and the project management office (MO) amongst others.
 Meetings: Referred to as change control meetings where change requests are reviewed by a
committee for either approving, rejecting or “other disposition of those changes”. Decisions are
documented and communicated to stakeholders for information and or action.
 Change Control Tools: In order to facilitate change management, manual or automated tools
may be utilised. One such tool is the Change control system - a collection of formal,
documented procedures that defines the steps by which official project documents may be
changed. It includes the paperwork, tracking systems, and approval levels necessary for
authorizing changes. Another tool may be the Performance management system - which looks
at for example earned value to help assess whether variances from the plan require corrective
action. A more widely used tool is the Project management information system.
6.2.3 Outputs from Integrated Change Control
 Approved Change Request. The disposition of all change requests whether approved or not
should be updated in the change log as part of the updates to the project documents.
 Change Log: Used to document changes that occur during the project. The changes and their
impact on the project in terms of time, cost, scope and risk are communicated to appropriate
stakeholders. Rejected requests should also be captured on the log .
 Project Management Plan Updates: Any subsidiary plans and baselines subjected to the
change process may be updated. Only changes from the current time forward should be
reflected in the changes to the baselines in order to protect its integrity as past performance
should not be changed.
 Project Document Updates: All documents subjected to the change control process should
be updated with relevant version controls.

6.3 Integrated Change Control Process

The overall goal of change control is to prevent changes from overwhelming a project or taking the
project unnecessarily off track (Larson and Gray, 2017). The goal of change control is NOT to prevent
all change. The change control process enables proactive identification and management of change, in
a manner that keeps the project moving in the right direction, towards successful completion/delivery as
is illustrated in Figure 6.2.
Figure 6.2: Change Control Process

Effective change control processes maintain the appropriate balance between control/discipline to
manage to the baseline plan, and flexibility to adapt the plans to meet customer expectations. Change
control contains five stages:
 Proposing a Change
 Summary of Impact
 Decision
 Implementing a Change Request
 Closing a Change Request
There are two documents used during the process:

 Change Log: used to provide a record of all changes requested and decisions made
 Change Request Form: used to document details of the change, including the business case

6.3.1 Proposing a Change

This process gives the ability for anyone in the project team (including the customer) to suggest a
change to the project (Larson and Gray, 2017). The proposal must include a description of the change
and expected benefits or other reason for the change. The change is presented using the Change
Request Form (Figure 6.3) and added to the Change Log for the project.
Figure 6.3: Example of a Change Request Form

The Change Request form addresses specific changes to be reviewed, authorised and made. In the
Change Request attention is given to the exact nature of the changes, whether they are scope
changes, where they lie in the project lifecycle, which specific document or deliverable requiring
change.

Specific attention is paid to the cost and implications, identifying where work will be required and what
its impact will be in terms of cost, risk and timescale. In particular, a benefit case will be prepared to
summarise why the change should be made.
The Project Manager, Change Control Board or Steering Committee will use this Benefit Case in
making a decision, in line with the pre-established guiding principles.
The status of the Change Request and its approval level should be tracked (Larson and Gray, 2017). In
addition to the database of Change Requests, there would be logs and various management reports to
allow the project leadership to track and control the changes. The Technical and administrative tracking
of the actual changes would normally be made using the Configuration Management process.
6.3.2 Summary of Impact

This process is carried out by the project manager, who will consider the overall effect on the project,
covering the following items:
 Quantifiable cost savings and benefits
 Legal, regulatory or other unquantifiable reason for change
 Estimated cost of the change
 Impact on timescales
 Extra resources needed
 Impact on other projects and business activities
 New risks and issues (Larson and Gray, 2017).
After this assessment, the project manager recommends whether to carry out the change.
6.3.3 Decision
This process involves a review of the change request by an approved authority who will consider all the
information provided by the project manager and person making the request. The decision will usually
be:
 Accept
 Accept with comments and special conditions
 Reject

 Defer (change is not approved, but is left for consideration later)
6.3.4 Implementing a Change Request

If the change is approved it is planned, scheduled and executed at a time agreed with the stakeholders.
As part of the planning, a regression test plan is needed in case the change needs to be backed out.
After implementation, it is usual to carry out a post-implementation review.
6.3.5 Closing a Change Request

Once implemented, the requester checks and agrees on the change, and it is closed in the Change Log
by the project manager.
6.4 Scope Change Control

The scope document is the basis for agreement by all parties. A clear project scope document is also
critical to managing change on a project. Since the project scope reflects what work will be
accomplished on the project, any change in expectations that is not captured and documented creates
the opportunity for confusion. One of the most common trends on projects is the incremental expansion
in the project scope. This trend is labelled “scope creep.” Scope creep threatens the success of a
project because the small increases in scope require additional resources that were not in the plan.
Increasing the scope of the project is a common occurrence, and adjustments are made to the project
budget and schedule to account for these changes. Scope creep occurs when these changes are not
recognized or not managed. The ability of a project manager to identify potential changes is often
related to the quality of the scope documents.
Events do occur that require the scope of the project to change (Larson and Gray, 2017). Changes in
the marketplace may require change in a product design or the timing of the product delivery. Changes
in the client’s management team or the financial health of the client may also result in changes in the
project scope. Changes in the project schedule, budget, or product quality will have an effect on the
project plan. Generally, the later in the project the change occurs, the greater the increase to the project
costs. Establishing a change management system for the project that captures changes to the project
scope and assures that these changes are authorised by the appropriate level of management in the
client’s organisation is the responsibility of the project manager. The project manager also analyses the

cost and schedule impact of these changes and adjusts the project plan to reflect the changes
authorised by the client. Changes to the scope can cause costs to increase or decrease.
Why is there a distinction between scope change and other changes? In general, Project Managers
should pay a great deal of attention to managing scope. Allowing the project's scope to change mid-
course usually means added costs, greater risks and longer duration. Many projects fail due to poor
scope management. Very often it is a large number of small scope changes that do the damage, rather
than the big, obvious ones. The successful Project Manager has learned that rigorous scope control is
essential to deliver projects on time and on budget.
The world-class Project Manager would not express this imperative in the same terms (Larson and
Gray, 2017). The prime focus for the Project Manager should not be to deliver the agreed scope on
time and on budget, but to optimise the benefit that is generated by the project. If that means allowing
the scope to change then that scope change is a good thing, not a bad thing. It is wrong to resist all
scope change. Where a scope change generates improved benefit, it should be proposed to the
project's decision-making body. Make clear the positive and negative impacts of allowing the change.
Make sure the impact is fully reflected in the project's definition and performance criteria.
Watch out for the use of "scope change" as a defensive behaviour. In many cases, people will discuss
scope changes in the context that a scope change is not the project's fault and must therefore be the
business's fault. This is particularly important if the work is being performed by a different organisation
under contract.
Watch out for the use of "scope change" as an aggressive behaviour. Sub-contractors may intentionally
try to expand the size of their contract by establishing scope changes that lead them to do additional
work outside the original agreement. Some contractors’ under-bid the cost of the work to gain the
contract, in the belief that they will be able to make their profit out of scope changes.
6.5 Integrated Change Best Practices

The following are recommended best practice approaches to integrated change management (Larson
and Gray, 2017):
 Document: Change requests should be centrally documented using some type of log.

 Unique Entries: Each change request should be recorded as a single-entry line. Do not
combine multiple requests under one change request identity.
 Iterative: Change management is an ongoing, iterative process conducted throughout the
project life cycle.
 Review: A regular review of change requests is good project management practice.
Depending on the complexity of the project, the review process may happen daily but should
happen at least weekly for even the simplest projects.
 Change Management System: A formally defined change management system should be
documented and communicated to the project team.
 Thresholds: Establish agreed upon thresholds outlined within the change management system
that defines who has the authority to approve what types of change.
 Analysis: Analyse the impact of approving a change request on the product, project and
programme as well as the impact of not approving the change request.
 Triple Constraints: Analyse change requests based on time, cost and scope impact to the
project. When managing competing requirements, evaluate how a change in one constraint
affects one or both of the remaining two. This evaluation will help the project understand the
costs and benefits of accepting a requested change.
 Acceptance Criteria: Define and document criteria for acceptance of deliverables outlined to
in the functional specifications of the approved change request.
 Back out Plan: Define and document criteria for backing out of the functionality of the
approved change request in case of unexpected consequences.
 Test Plan: The purpose of the test plan is to communicate the intent of the testing activities for
the approved change request. It is critical that this document be created as early as possible
after the change has been approved.
 Evaluate Risk: When identifying risks associated with making a requested change, consider
what can go wrong. Identify potential barriers to success so that risk can be reduced or
eliminated. Identify events which may occur that could decrease the likelihood of delivering the
change request.
 Organisational Change: When evaluating change requests, identify the organisational change
impact that authorising the change may have on the project, customer, or organisation.

 Production, Operations and Maintenance: When moving into the operation and maintenance
phase of the project life cycle, change management may be handled differently than during
development. Re-evaluate the change management plan well in advance and make the
necessary changes, make updates to accommodate any differences in approach, process,
management, etc. (Vitek, 2009).
6.6 Summary
The benefits derived from integrated change control are numerous and may include discouraging
inconsequential changes by the formal process; maintaining costs of changes in a log; maintain the
integrity of the WBS and performance measures; tracking the allocation and use of the budget and
management reserve funds; clarifying responsibility for implementation; making visible the effect of
changes to all parties involved; monitoring the implementation of change; and being able to quickly
reflect scope changes in baseline and performance measures.
Clearly, change control is important and requires that someone or some group be responsible for
approving changes, keeping the process updated, and communicating changes to the project team and
relevant stakeholders. Project control depends heavily on keeping the change control process current.
This historical record can be used for satisfying customer inquiries, identifying problems in post-project
audits, and estimating future project costs.
1. What are the benefits derived from a change control system?

2. Is scope creep good or bad?


1. The benefits derived from change control systems are the following:
 Inconsequential changes are discouraged by the formal process.
 Costs of changes are maintained in a log.
 Integrity of the WBS and performance measures is maintained.
 Allocation and use of budget and management reserve funds are tracked.
 Responsibility for implementation is clarified.
 Effect of changes is visible to all parties involved.
 Implementation of change is monitored.
 Scope changes will be quickly reflected in baseline and performance measures.
2. Scope creep is bad when the customer refuses to pay for the additional change requests and further
because it impacts on the scope delivery, time and cost. Scope creep may be good if necessary
specifications are added that enhance the product or ensure quality. It should be entertained in
situations where products become obsolete in a short space of time. Therefore, in order to remain
relevant, scope creep has to be allowed.

CHAPTER SEVEN
PROJECT CLOSURE
Learning Outcomes:
 finalise all activities and transfer completed or cancelled work to the appropriate people
 Utilise the inputs, tools and techniques for project closure so as to ensure specific outputs
 Compile a project closure report to be utilised to communicate a final summary of the project
for project stakeholders, as well as to create a reference document
 boost the morale of the team members through recognizing their work and celebrating project
successes
 facilitate and document the lessons learned process in a lessons-learned report
 determine when early termination of projects is necessary
 Implement project closure best practices

7.1 Introduction
Closing the project or phase involves finalizing all project activities. It is important to follow good
procedures to ensure that all project activities are completed and that the project sponsor accepts
delivery of the final products, services, or results of the project.
Project closure is the point in time for project managers to identify / highlight the things done well or
poorly during the project, and initiate the appropriate actions to ensure that these lessons learned are
reflected in future project efforts. At the end of a project, many project managers are busy preparing for
their next project or client, and miss this prime opportunity to leave a lasting impact on the client
organisation. Project closure starts with effectively shutting down project activities, validating all product
deliverables are complete and key product issues closed, and smoothly transitioning resources to new
roles. The second aspect of this best practice area is preparing the project closure report (also referred
to as the post-project assessment). Creating the project closure report includes gathering input from
key stakeholders, and identifying improvement actions to be implemented either as part of the closeout
process or for future projects. These improvement actions can have a significant impact on the
effectiveness of the processes and tools regularly practiced within the project office.
Effectively facilitating the lessons- learned process helps the team reflect on what was accomplished,
how it was accomplished, and what would the team do differently on the next project. This is the
opportunity for the team to have a real impact on how projects are completed within your organisation
in the form of implementing continuous improvement actions. The other important element of project
closure is celebrating success. Facilitate a project celebration that helps team members feel good
about was accomplished before they rush off to their next assignment.
7.2 Inputs, Tools and Techniques and Outputs for Project Closure
The last process in project integration management is closing the project or phase (PMI, 2013). In order
to close a project or phase, all activities must be finalised and the completed or cancelled work
transferred to the appropriate people. The main inputs to this process are the project management
plan, accepted deliverables, and organisational process assets. The main tool and technique is again
expert judgment.

The outputs of closing projects are:

 Final product, service, or result transition: Project sponsors are usually most interested in
making sure they receive delivery of the final products, services, or results they expected when
they authorised the project. For items produced under contract, formal acceptance or handover
includes a written statement that the terms of the contract were met. Internal projects can also
include some type of project completion form.
 Organisational process asset updates: The project team should provide a list of project
documentation, project closure documents, and historical information produced by the project
in a useful format. This information is considered a process asset. Project teams normally
produce a final project report, which often includes a transition plan describing work to be done
as part of operations after the project is completed. They also often write a lessons-learned
report at the end of a project, and this information can be a tremendous asset for future
projects. Several organisations also conduct a post-implementation review to analyse whether
or not the project achieved what it set out to do. Information from this type of review also
becomes an organisational process asset for future projects.
7.3 Project Closure Report

The project closure report summarises the product delivered, metrics associated with the effectiveness
of the project delivery process, and the feedback captured from project stakeholders (including
recommended next steps for future projects) (Larson and Gray, 2017). This document is utilised to
communicate a final summary of the project for project stakeholders, as well as to create a reference
document filed in the project archives. The communication to the project stakeholders is focused on
confirming that the project is “done”, and assessing the project delivery process. The information
maintained for purposes of the project archives focuses on creating a permanent record for reference
by future project teams.
7.3.1 Project Results

Details are presented of the key project performance metrics, including an assessment (rating) for each
type of performance metric (cost, schedule, change, and quality), and a brief explanation of the team’s
performance associated with the metric (Larson and Gray, 2017).

7.3.1.1 Budget Performance

Budget performance metrics describe how effectively the team was able to manage to the baseline
project budget. Budget performance metrics include:
 Final Cost - What was the final actual cost of the project?
 Breakdown by Component - Breakdown of the final cost by cost category - same costs
categories that have been tracked and reported throughout the project life cycle;
 Budget Variances - What is the difference between the baselines budgeted costs and the
actual cost? This should be detailed in dollars and as a percent of the project budget. Detailing
the variance by cost category clarifies the source of the cost variances;
 Budget Performance Rating - Based upon the % budget variance. The budget rating is best
defined at the beginning of the project in the cost management section of the project
management plan; and
 Explanations for Key Variances - Represents a descriptive narrative explaining the key budget
variances.
7.3.1.2 Schedule Performance

Schedule performance metrics describe how effectively the team was able to manage to the baseline
project schedule. Schedule performance metrics include (Larson and Gray, 2017):
 Total Duration - What was the actual duration of the project -from the start date to the end
date?
 Schedule Variances - What is the difference (in days) between the baseline end date and the
actual end date? This should be detailed in days and as a percent of the total project duration.
To provide clarification of the cause of the variance it is also helpful to provide the variances
(days and percent) for each of the project phases/milestones;
 Schedule Performance Rating – Based upon the % schedule variance, assign a
Green/Yellow/Red rating to schedule performance for the project. The schedule rating is best
defined at the beginning of the project in the schedule management section of the project
management plan (e.g., Green <10%, Yellow 11-20%, Red>20%).
 Explanations for Key Variances – Represents a descriptive narrative of the schedule variance
explanations. Again, I find it beneficial in the variance description to quantify how much each
variance source accounts for the total variance (in days or as a percent).

7.3.1.3 Change Management

Change management metrics highlight the team’s ability to manage change throughout the project life
cycle (Larson and Gray, 2017). Key change metrics include:
 Total number of changes – Breakdown of the total number of change requests submitted, and
the number that were approved and implemented. In addition, it is often helpful to provide a
breakdown of the approved/implemented requests in terms of the number that impacted scope,
schedule and cost.
 Impact of the change – Sum of the impact of the approved/implemented change request on the
project schedule (days) and budget (cost). This represents the cumulative impact of change on
the project.
 Highlight of key changes – A detailed description of the key changes that were implemented. In
this section it may also be appropriate to highlight changes that were not approved, particularly
if they are intended to be deferred to future product releases.
 Approved change vs. Total variance – A comparison of the total impact of change on the
project vs. the total project variances (schedule and budget) provides a good indication of how
much change accounts for the total project variances. In other words, were project variances
managed in a proactive manner (via the change management process) or reactive manner (via
after the fact variance explanations) throughout the project.
7.3.1.4 Feedback & Next Steps

The final section of the Project Closure summarizes the process and results of gathering stakeholder
feedback:
Process – Summary of the feedback survey and lessons learned processes. Who was solicited for
feedback? What was the response? How the lessons were learned discussion organized and
facilitated?
Rating Metrics – What was the average score for each question? What was the number of very high or
very low scores for specific questions?
Key Themes – What were some of the common themes from comments on the survey or during the
lessons learned session?
Opportunities – What are the high priority opportunities (those opportunities to improve, or leverage
what was done well for future projects / product releases)?

Next Steps – What are the action items to ensure that the opportunities are moved forward in the right
direction? Where possible, include owner assignments and target dates in this section of the document
(Larson and Gray, 2017).
7.4 Staff Recognition and Evaluation

Successful projects should end with some type of recognition and celebration (Larson and Gray, 2017).
 This helps boost the morale of the team members through recognizing their work.
 It also helps to celebrate a successful project.
The project manager should prepare a written performance evaluation of each member of the project
team.
 It should mention how each has expanded her or his knowledge as a result of the project
assignment
 It also identifies areas where he or she needs to develop further.
 These evaluations should be shared during individual meetings with the team members, or
given to their supervisor to share with them.
7.5 Lesson Learned Report

Implementation of a consistent continuous improvement practice (aka, the lessons learned process)
enables the ability to enhance the organisation’s project delivery capabilities with the initiation of each
project (Larson and Gray, 2017). The overall purpose of the lessons learned process is to identify
improvement opportunities (things done well, or areas for improvement), and to initiate actionable next
steps. In the context of this discussion, improvement opportunities can relate to both the product that
was delivered, as well as how the project was planned and executed. The lessons learned process
should have consistent structure and organisation from project to project. The following represents the
primary steps in the lessons learned process:
 Kick-off – The process is initiated with a brief discussion of the purpose of the lessons learned
process. Information captured in the project closure survey is helpful to determine the best flow
for the initial lessons learned discussion.
 Capture Ideas – Ideas are generated for each of the project areas (e.g., project phase,
functional group, or product category). Again, these ideas represent things done particularly
well on the project, or areas for improvement. The facilitated discussion includes a review of

ideas captured throughout the project (primarily by the project manager) and from the project
closure survey, as well as brainstorming new ideas during the lessons learned meeting.
 Group into Opportunities – Organize the ideas into groups based upon the type of
improvement opportunity.
 Prioritize – Identify the high priority opportunities, based upon impact of the opportunity (to the
product or future projects).
 Identify & Assign Actions – For the selected opportunities (high priority), identify actions that
represent the next step(s) associated with implementing the opportunity. In addition, assign
ownership for the opportunity to someone on the team who is responsible for seeing that the
next steps are initiated.
7.6 Archive Project Documents

During project closing, the project team or contractor should ensure that copies of appropriate project
documentation are properly organized, filed, and archived (Larson and Gray, 2017). Good organisation
helps make information readily retrievable for future use. It can be valuable to create a database of
common data elements from past projects:
 Helps to analyze and determine if there are trends or correlations between projects
 Can be helpful in bidding, planning, and/or performing future projects
 This should be done as part of, or in addition to, the documents in the archive.
7.7 Early Termination of Projects

Not all projects are finished. Certain circumstances require that a project to be terminated before it is
completed. Projects can be terminated by the sponsor or customer because of:
 Financial situations (the client runs out of money or the project becomes too expensive)
 Project return on investment change (perhaps from a change in the economy, such as a
recession)
 Dissatisfaction with the project progress (sometimes the client orders a project terminated
because it is progressing too slowly)
 Project needs have changed (the original project no longer suits the client’s requirements)
Project managers must monitor the level of customer satisfaction continually throughout the project and
take corrective action at the first hint of any dissatisfaction.

7.8 Best Practice for Project Closure

The following are recommended best practices for project closure (Larson and Gray, 2017):
 Involve Stakeholders: Involve all project participants and stakeholders in the close-out process
 Use a Checklist: Review the close-out checklist template to ensure that all key items have been
completed
 Solicit Feedback: Conduct a post-project survey to solicit feedback on the project from the
project team, customers and stakeholders who were well acquainted with the management of
the project
 Identify Lessons Learned: Convene a lessons-learned session to promote the success of future
projects
 Archive Data: Archive all project data in a central repository. Include best practices, lessons
learned and any other relevant project documentation
 Celebrate: Celebrate and reward project success
 Phased Closure: Should be phased over a period of time rather than being a single event. This
is to reduce final project implementation risks
 Manage Resources: Project Manager may face requests to release staff from the project team
before all project closure tasks are finished. These requests should be anticipated considering
both project goals and staff capabilities
 Confidentiality: Upon closing sub-contractor contracts, consider the confidentiality of the
contracts before potentially sharing with the client.
7.9 SUMMARY
At the end of a project, many project managers are hurriedly preparing for their next project or client,
and miss a prime opportunity to leave a lasting impact on the client organisation. Project closure starts
with effectively shutting down project activities, validating all product deliverables are complete & key
product issues closed, and smoothly transitioning resources to new roles (onto new projects, or within
operational functions). The PMBOK refers to this process as contract closure.
The second- best practice area is gathering customer input about the project, and facilitating lessons
learned. There are a lot of good resources available for gathering customer feedback for project work,
and the easiest way to evaluate the quality of this data is to ask two questions of yourself and the
project team:

 Is this information actionable?

 How likely will the organisation do something with this information?
 Although value is placed on customer input and recommended next steps, the true sign of a
well-run project is demonstrated in the final project performance report (also referred to as the
Post Project Assessment):
 How well can you reconcile actual delivery dates to original baseline dates?
 How well are budget variances explained through approved corrective actions?
 Are project quality metrics well-articulated?
The critical success factors of a solid project performance close-out are creating a strong and well
understood project baseline, and diligently managing to the baseline throughout the project life cycle.
1. Discuss what needs to be done as part of closing a project.

2. Why are these activities important?
3. What are some ways you can obtain feedback from a customer after a project has been
completed? How would you use this information?
4. Why are some projects terminated before they are completed? When would it be wise to do
so?
5. List several lessons learned for a project in which you were a project member or project
manager. How will these lessons learned inform your future projects?

1. The process of closing the project involves various actions, including:
 Collecting and making final payments
 Recognizing and evaluating staff
 Conducting a post-project evaluation
 Documenting lessons learned
 Organizing and archiving project documents

2. These activities are all important to:
 Ensure that the customer is satisfied

 Gather information about how to improve for future projects
 Determine if additional opportunities are available with the customer
 Obtain permission to use the customer as a reference
The post-project evaluation can be conducted as a meeting with open-ended questions, or as a

customer evaluation survey. The information is used to assess the level of satisfaction of the customer,
the opportunities for future work, and as a chance to ask permission to use the customer as a
reference.
3. Projects also can be terminated by the sponsor or customer for a variety of reasons including:
 Financial situations
 Project return on investment change
 Dissatisfaction with the project progress
 Project needs have changed
 It is wise to terminate a project if:
 The cost of doing the project outweighs the benefits
 The project is no longer needed
 If the project is not being carried out in a satisfactory manner
4. Responses will be dependent upon the project. Common lessons learned include:
 Increase project team communication
 Have more frequent project team meetings
 Analyze project progress to be more proactive when tasks are delayed
 Have more meetings with the customer
 Document changes more thoroughly
 Discuss risks at each project team meeting
Not all lessons learned are due to negative experiences. Positive experiences on how to implement a
technology solution are also valuable lessons. Lessons learned inform future projects because the
team can implement the suggestions from prior projects and thereby avoid the same problems.

BIBLIOGRAPHY
Aston, B. 2017. Why is Project Management Important?[online] Available from:
https://management.simplicable.com/management/new/why-project-management-is-important
[Accessed 20 October 2017].
Chasegroup. 2017. Project Management, [online] Available from:
http://www.chasegroup.com.au/files/7ALCT7QG4I/Project%20Management.jpg [Accessed 20 October
2017].
Clements, J.P. and Gido, J. 2012. Effective Project Management. 5th ed. Stamford: Cengage Learning.
Cooper, B. 2017 Leadership Techniques for Project Managers, [online] Available from:
http://www.corpedgroup.com/resources/pm/EffLeadTechniques.asp). [Accessed 20 October 2017].
Forbes. 2017. Forbes Quotes, [online] Available from: https://www.forbes.com/quotes/9421/ .
Gido, J. and Clements, J.P. 2015. Successful Project Management. 6th ed. Stamford: Cengage
Learning.
Harper, M. 2017. Agile Project Management, [online]. Available from: micheleharperdesign.com
Klakegg, O.J. 2015. Corporate Maturity Towards Risk. Journal of Risk Research. 18(2): 232–248.
Larson, E.W. and Gray, C.F. 2011 Project Management: The Managerial Process. 6th ed.New York:
McGraw Hill Irwin.
Larson, E.W. and Gray, C.F. 2017 Project Management: The Managerial Process. 7th ed.New York:
McGraw Hill.
Mar, A. 2012 Strategic Planning Basics, [online]. Available from:
http://www.balancedscorecard.org/BSC-Basics/Strategic-Planning-Basics [Accessed 20 October 2017].
McNamara, J.P. 2003 The “Neutral” Project Manager, PMI Global Congress North America 2003,
Baltimore, MD.
PMI. 2004. A Guide to the Project Management Body of Knowledge (PMBOK Guide). 4th ed.
Pennsylvania: Project Management Institute.
PMI. 2013. A Guide to the Project Management Body of Knowledge (PMBOK Guide). 5th ed.
Pennsylvania: Project Management Institute.
PMI. 2010. The Value of Project Management. United States of America: PMI
Pycraft, M., Singh, H., Phihlela, K., Slack, N., Chambers, S. and Johnston, R. 2010. Operations
Management. 2nd ed. Cape Town: Pearson Education South Africa (Pty) Ltd.

Schwalbe, K.2009 An Introduction to Project Management. 5th ed. United States of America: Cengage
Learning
Schwalbe, K.2011 Information Technology: Project Management. Revised 6th ed. United States of
America: Cengage Learning.
Schwalbe, K.2017 An Introduction to Project Management. 6th ed. United States of America: Cengage
Learning.
Srinivasan, B. 2010 Effective Project Management Using Mind Maps, [online]. Available from:
http://www.academia.edu/6667944/Effective_Project_Management_Using_Mind_Maps [Accessed 20
October 2017].
Van der Walt, G. and Fox, W. 2016 A Guide to Project Management.2nd ed. Cape Town: Juta.
Villanovau. 2017 Organisational Strategy, [online]. Available from:
https://www.villanovau.com/resources/project-management/project-management-organisational-
strategy/#.Wb-cuoyCzDc [Accessed 20 October 2017].
Vitek, D. 2009 CDC UP Change Management Practices Guide. USA: Centre for Disease Control and
Prevention, [online]. Available from: https://www.smartsheet.com/demystifying-various-project-
management-frameworks-and-methodologies [Accessed 20 October 2017].
Wheatley, M. 2017 New research into the role of project management in a modern developed economy
- like the UK, [online]. Available from: https://www.projectsmart.co.uk/the-importance-of-project-
management.php [Accessed 20 October 2017].

PGDPM Project Integration Management

Uploaded by

Copyright:

Available Formats

PGDPM Project Integration Management

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

PGDPM Project Integration Management

Uploaded by

Copyright:

Available Formats

What are the main project integration management tasks?

What are the main project integration management tasks?

What are the six processes engaged during integration management?

What are the six processes engaged during integration management?

Project Integration Management

POSTGRADUATE DIPLOMA IN PROJECT

PROJECT INTEGRATION MANAGEMENT

CHAPTER TOPIC PAGE

Introduction to Project Integration Management 3

PROJECT MANAGEMENT AND ORGANISATIONAL 7

2 WHAT IS PROJECT MANAGEMENT? 24

3 PROJECT PLAN DEVELOPMENT 62

4 PROJECT PLANNING METHODOLOGY 118

5 PROJECT PLAN EXECUTION 140

6 PROJECT INTEGRATED CHANGE CONTROL 148

7 PROJECT CLOSURE 160

POSTGRADUATE DIPLOMA IN PROJECT MANAGEMENT 2

Introduction to Project Integration Management

POSTGRADUATE DIPLOMA IN PROJECT MANAGEMENT 3

 Directing and managing project execution

Aims of the Module

POSTGRADUATE DIPLOMA IN PROJECT MANAGEMENT 4

How to use this module guide

POSTGRADUATE DIPLOMA IN PROJECT MANAGEMENT 5

PRESCRIBED AND RECOMMENDED READING

POSTGRADUATE DIPLOMA IN PROJECT MANAGEMENT 6

POSTGRADUATE DIPLOMA IN PROJECT MANAGEMENT 7

POSTGRADUATE DIPLOMA IN PROJECT MANAGEMENT 8

 Strategic intent — focusing all organisational energies on a compelling goal.

Strategic management is therefore, the process of formulating and implementing strategies to

1.1.1 Why Project Managers need to understand the Strategic Management

POSTGRADUATE DIPLOMA IN PROJECT MANAGEMENT 9

1.1.2 Requirements for Strategic Planning

The requirements for strategic planning are therefore:

1.1.3 The Strategic Management Process

POSTGRADUATE DIPLOMA IN PROJECT MANAGEMENT 10

External Environment: Internal Environment:

New Goals &

What do we intend to be?

How are we going to get there?

Figure 1.1 the Strategic Management Process

The typical sequence of activities of the strategic management process, as

POSTGRADUATE DIPLOMA IN PROJECT MANAGEMENT 11

2. Set long-range goals and objectives:

1.2 Implementing Strategies through Projects

POSTGRADUATE DIPLOMA IN PROJECT MANAGEMENT 12

 Workflow and Design:

1.1.4 How to align Organisational Strategy to Project Management

POSTGRADUATE DIPLOMA IN PROJECT MANAGEMENT 13

Figure 1.2: Aligning Projects with Organisational Strategy

POSTGRADUATE DIPLOMA IN PROJECT MANAGEMENT 14

1.1.5 Enterprise Project Management Office

POSTGRADUATE DIPLOMA IN PROJECT MANAGEMENT 15

Figure 1.3: Project Management Framework

1.2 Project Selection

POSTGRADUATE DIPLOMA IN PROJECT MANAGEMENT 16

1.1.6 The Selection Process

POSTGRADUATE DIPLOMA IN PROJECT MANAGEMENT 17

Supporting Data &

Need more information