Bcomscm Project Management

BACHELOR OF COMMERCE IN
SUPPLY CHAIN MANAGEMENT
PROJECT 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.
BACHELOR OF COMMERCE SUPPLY CHAIN MANAGEMENT PROJECT MANAGEMENT
TABLE OF CONTENTS
Chapter 1 Introduction to Project Management 5
Chapter 2 Project Selection and Prioritization 21
Chapter 3 Organisational Capability - Structure, Culture, and Roles 45
Chartering Projects
Chapter 4 63
Stakeholder Analysis and Communication Planning

Chapter 5 77
Scope Planning
Chapter 6 98
Scheduling Projects
Chapter 7 118
Bibliography
155
REGENT BUSINESS SCHOOL 1

INTRODUCTION TO PROJECT MANAGEMENT STUDY GUIDE
Welcome
Welcome to the PROJECT MANAGEMENT third year level module for the BCom
Supply Chain Management degree. May your commitment to learning expand your
knowledge on this module and take you on a successful journey.
This module requires that you dedicate time to read the study guide, prescribed text
book and recommended readings. Further to this, you are encouraged to do the
activities in your study guide, answer the questions and do the exercises at the end of
the chapter readings in your prescribed text book.
Plan your study times according to a timetable schedule and stick to it so that you
can easily pass all tests and examinations. Apply your time well and enjoy learning
more on P r o j e c t Management!

Essential (Prescribed and recommended) Reading
PRESCRIBED TEXT
The prescribed text book for Project Management for 3rdd year BCom students
is:
Kloppenborg, TJ. (2015). Contemporary Project Management. (3rd Edition). Cengage

Learning, USA.
Additional Recommended Reading:
1. Gido, J and Clements, JP. (2015). Successful Project Management. (6th Edition).
Cengage
Learning, USA.
2. van der Waldt, G and William, F. (2015). A Guide to Project Management. (2nd
Edition). Shumani Mills Communications, Juta and Company (Pty) Ltd, SA.
3 Bricknell., Fraser., Goldman., Kara., Labuschagne., Maritz., McGregor., Radford.,

(2014). Project Management in Perspective. (4th Edition). Oxford University Press,
South Africa.

INTEGRATED EXIT LEVEL OUTCOMES &

ASSESSMENT CRITERIA
The high level exit level outcomes for this Project Management module, and their associated
assessment criteria, are listed in the table below. Specific outcomes for each learning area are
detailed at the beginning of each learning area section that follows. The following are the
learning outcomes for the module. By the end of the module, the student should be able to:
 To understand the roles, skills and techniques a project manager uses.
 To be able to define the objectives and scope of a project.
 To communicate with all stakeholders in the project.
 To plan, control and allocate the project schedule and resources.
 To implement and assist with basic project monitoring and control

CHAPTER 1:
INTRODUCTION TO PROJECT MANAGEMENT
1. INTRODUCTION
This is an introduction unit on Project Management and discusses what a project

is, the history of project management, how project work is described, understanding
projects and project roles. This unit ends with a brief summary and activities for the
student to complete. The learning outcomes are given below.
Learning Outcomes
 Define a project in your own words, using characteristics that are common
to most projects, and describe reasons why organisations are using project
management.
 Describe major activities and deliverables at each project life cycle stage.
 List and define the ten knowledge areas and five process groups of knowledge
 Delineate measures of project success and failure with reasons for both.
 Contrast predictive or plan-driven and adaptive or change-driven project life
cycle approaches.
 Identify project roles and distinguish key responsibilities for each.
1.1. WHAT IS A PROJECT?

When a business attempts to undergo changes, like erecting a building for example,
these changes should be scheduled and managed as projects. A project is “a
temporary endeavour undertaken to create a unique product, service, or result”
(Kloppenborg, 2015:4).
“A project is an endeavour to accomplish a specific objective through a unique set of

interrelated activities and the effective utilisation of resources” (Gido and Clements,
2015:4).
Projects are subject to the limitations of time and resources (i.e. money and people).
A project requires a planned set of work efforts that are expanded as new information
surfaces. A project should follow a strategic and organized approach with a clear

beginning and ending. Plans and goals become more explicit as early work is
completed.
The project output is a collection of primary and supporting deliverables. A

deliverable is the end product on completion of the project objectives. Consider the
example of a school building project. The school can only be utilised once the
project is completed to a satisfactory standard (Gido & Clement, 2015:4).
Projects have unique combinations of stakeholders- “an individual, group, or

organisation who may affect, be affected by, or perceive itself to be affected by a
decision, activity, or outcome of a project” (Kloppenborg, 2015:4).
According to Gido and Clements, (2015), stakeholders can be the

customer/sponsor, project team, Project Manager, subcontractors, consultants, end
users or consumers and advocacy groups. Projects require a variety of people to
collaborate for a limited effort in addition to their other allocated work.
Project Management is “the application of knowledge, skills, tools and techniques to

the project’s activities to meet project requirements” (Kloppenborg, 2015:4). This
includes work processes that initiate, plan, execute, control, and close work.
During these processes, trade-offs must be made among the following

factors:
 Scope (size)
 Schedule
 Quality (acceptability of the results)
 Resources
 Cost
 Risks
When Project Managers successfully make these trade-offs, the project results do
the following:
 Meet the agreed upon requirements.

 Are useful to the customers.
 Promotes the organisation

Project Management includes:
 Administrative tasks: for planning, documenting, and controlling work.

 Leadership tasks: for visioning, motivating, and promoting work
associates. (Kloppenborg, 2015:4).
1.2. HISTORY OF PROJECT MANAGEMENT

Many projects have been undertaken throughout history. Historical projects included:
the pyramids, medieval cathedrals, and Indian cities, pueblos, waging wars and
building empires.
During the growth of the United States, projects involved creating railroads, farms and
cities. In the past, projects were completed at great human and financial cost. In the
50s and 60s, techniques for planning and controlling schedules and costs were
developed, mainly on aerospace and construction projects. By the 90s, several
software companies offered powerful and easier ways to plan and control project costs
and schedules.
In recent times, people have realised and recognized that communication and
leadership play major roles in project success. Rapid growth and changes in
information technology and telecommunications have fuelled massive growth in the
use of Project Management. People engaged in banking, insurance, retailing, hospital
administration, and many other service industries are now turning to Project
Management to help them plan and manage efforts to meet their unique demands. In
these days Project Management is commonly used on projects.
“The use of Project Management has grown quite rapidly and is likely to continue
growing. With increased international competition, customers demand to have their
products and services developed and delivered better, faster and cheaper. Because
Project Management techniques are designed to manage scope, quality, cost, and
schedule, they are ideally suited to this purpose” (Kloppenborg, 2015:5).
1.3. HOW CAN PROJECT WORK BE DESCRIBED?

It can be described as follows:

 Projects are temporary while other work (operations), are continuous.
 Project Managers need certain “soft skills” and “hard skills” to be effective.
 Project Managers frequently have more responsibility than authority.
 Projects go through predictable stages called a life cycle.
1.3.1. Projects versus Operations
Projects are temporary, and unique. Some projects may vastly differ from any other
work an organisation has performed, such as planning a merger with another
company. Other projects may have both routine and unique aspects such as building a
house. Operations, entail the constant work required for the organisation to function
effectively. Operations managers often use checklists to monitor their work. Project
Managers can use Project Management methods to help determine what to do, but
they rarely have checklists that identify all the activities that they need to complete.
THINK POINT
Think of the consequences if an operations manager did not use

checklists to guide their work.
1.3.2. S o f t Skills and Hard Skills
To successfully manage and lead in a project environment, a person needs to develop

both “soft” and “hard” skills. Soft skills: include communication and leadership
activities. Hard skills: can include risk analysis, quality control, scheduling, budgeting,
etc. Soft and hard skills are interdependent. Some people have a stronger natural
ability in one or the other. A successful Project Manager needs to develop both along
with their judgment about when each is needed. Training, experience, and mentoring
can be helpful in developing necessary skills.
1.3.3. Authority and Responsibility

A Project Manager is regularly liable for work that he/she cannot delegate. Projects are
most effectively managed with one person being assigned accountability. Such a

person often needs to negotiate with a Functional Manager. The Functional Manager is
someone that has management authority over an organisational unit.
1.3.4. Project Life Cycle

“The project life cycle outlines the stages that link the beginning of a project to the
end”.
(http://www.pmdocuments.com/pmbok-project-management-framework-reference/).
A project life cycle is “the series of phases that project goes through from its initiation to
its closure” Kloppenborg (2015:6). An organisation’s control needs to be assured that
the work of the project is proceeding in a satisfactory manner and that the results are
likely to serve its customer’s intended purpose.
The project customer is the person/organisation that will use the project’s product,
service, or result. Various project life cycle models are utilised for different types of
projects. The disparities these create will be explored in unit three. In this chapter the
following project stages are utilised:
 Selecting and initiating.
 Planning.
 Executing.
 Closing and realizing.
See Exhibit 1.1 for a predictive or plan-driven project life cycle. See Exhibit 1.2 for
an adaptive or change-driven project life cycle. The primary difference is that in the
first, the product is well-understood and all planning precedes all executing, while in
the second, early results lead into planning later work. The extreme of predictive is
sometimes called waterfall and the extreme adaptive is sometimes called agile. Agile
will be defined in unit three.
Many companies even have their own project life cycle model, such as the one
Midland Insurance Company has developed for quality improvement projects as shown
in Exhibit 1.3.

1.4. UNDERSTANDING PROJECTS

Some frameworks that provide a better understanding of Project Management are
described below.
1.4.1. Project Management Institute
“Project Management has professional organisations just as do many other

professions and industry groups. The biggest of these is the Project Management
Institute. It was founded in 1969, and has grown rapidly since the 1990’s. PMI
publishes and regularly updates the guide known as: A Guide to the Project
Management Body of Knowledge (PMBOK* Guide). All of the definitions in this
book come from PMBOK* Guide, fifth edition” (Kloppenborg, 2015:8).
1.4.2. Project Management Body of Knowledge (PMBOK)
The Project Management Body of Knowledge consists of a project life cycle

with five process groups, and ten knowledge areas. The five process groups are
as follows:
1. Initiating.
2. Planning.
3. Executing.
4. Monitoring and controlling.
5. Closing.
The ten knowledge areas are:

1. Integration management.
2. Scope management.
3. Time management.
4. Cost management.
5. Quality management.
6. Human resources management.
7. Communications management.
8. Risk management.
9. Procurement management.

10. Stakeholder management.
Read up more on this section on page 9 of the prescribed text book.
1.4.3. Selecting and Prioritizing Projects

Firstly potential projects must be identified. This is accomplished in a systematic
manner not just by chance. All parts of the organisation should be involved. For
example, salespeople can discover opportunities through discussions with existing and
potential customers. Everyone in the firm should be mindful of industry trends and use
this knowledge to identify potential productivity enhancing projects.
THINK POINT
Think about what would happen if all members of an organisation

were not aware of industry trends.
Once a project has been identified the organisation needs to prioritize among the
potential projects. The best way to do this is to determine which projects align best
with the goals of the firm. The executives in charge of selecting projects need to
ensure overall organisational priorities are understood, communicated, and accepted.
Once this common understanding is in place, it is easier to prioritize among the
potential projects.
The prioritization efforts should include asking the following questions:

What value does each potential project bring to the organisation?
Are the demands of performing each project understood?
Are the resources needed to perform the project available?
Is here enthusiastic support both from the external customers and from one or
more internal champions?
Which projects will best help the organisation achieve its goals?

1.4.4. Project Goals and Constraints

Projects are undertaken to accomplish specific goals. Those goals can be described
by scope which are the sum of the products, services, and result to be provided and
by quality which is the degree to which a set of inherent characteristics fulfils the
requirements. (Kloppenborg,2015:10). Collectively, they are called performance and
should produce outputs that customers can be content with. Projects usually have
time and cost constraints. “Constraints have to be managed well enough so that it does
not affect the success of the project” (Gido & Clement, 2015:4).
“A Project Manager needs to understand which of these four goals and constraints
(scope, quality, time and budget) should take precedence and which can be sacrificed.
The Project Manager needs to determine how much he/she wants to enhance
achievement of one of these four dimensions. The customer must also state which
dimension he/she is willing to sacrifice, by how much, and under what circumstances”
(Kloppenborg, 2015:11). From an internal standpoint a Project Manager must also
consider two more constraints: the amount of resources available and the decision
maker’s risks tolerance. From an agile viewpoint, resources (including cost) and
schedule are considered fixed however, what can change is value to the customer.
1.4.5. Defining Project Success and Failure

Project success is creating deliverables that satisfy the scope goals. The clients must
be able to utilise the outputs successfully (meet quality goals). The project should be
completed on schedule and on budget (meet time and cost constraints). A
successful project is one that is accomplished without heroics. This means that
people should not burn themselves out in order to complete the project.
People who work on the project should learn new skills and/or refine existing skills.
The performing organisation should reap business-level benefits. These benefits can
be: development of new products, increase in market share, and increase in
profitability, decreased cost, and so on. A contemporary and completed view of project
success is shown in Exhibit 1.5.

(Source: Kloppenborg, 2015:11)
When is a project a failure? A project is a failure when it does not meet the success
criteria. See Exhibit 1.5. Many projects are entirely successful in some ways but
unsuccessful in others. Severe project failure occurs when certain success criteria are
not met.
Failure can result from many causes. In each unit, more detailed potential failure
causes and prevention techniques will be discussed.
Below are some basic causes of failure:

 Lack of resources.
 Not enough time has been allocated to the project.
 Project expectations are unclear.
 Changes in the scope are not understood. There may be no agreement on

changes by the parties involved.
 There is disagreement. Stakeholders disagree regarding expectations for the

project.
 Poor project planning.

1.4.6. Using Microsoft Project to Help Plan and Measure Projects
A convenient tool to capture and display a range of important project data is Microsoft
(MS Project). MS Project is demonstrated in a step-by step manner using screen shots
throughout the prescribed text book.
Classifying by Industry - Classifying projects by industry is useful because different

industries often have unique requirements. “Several industry-specific project life
cycle models are in use, and various trade groups and special interest groups can
provide guidance. For example, PMI had 39 specific communities of practice at March
1st, 2013, as shown in Exhibit 1.6. These groups allow Project Managers worldwide to
share and learn together” (Kloppenborg, 2015:12).

Classifying by Size – Projects can be classified by their size. There is more

detailed planning and more control on projects that are large. “For example,
construction of a multi- story building in China would require a highly detailed
construction schedule, but even a much simpler construction project of building a
one-car garage would also need to follow a schedule” (Kloppenborg, 2015:13).
Classifying by Timing of Project Scope Clarity - This method deals with how early
in the project the Project Manager and team are likely to be able to determine with
certainty what the project scope will be. “For example, it may be rather simple to
calculate the cubic feet of concrete that are required to pour in a parking lot and,
therefore, how much work is involved. On the other hand, when developing a new
pharmaceutical, very little may be determined in the project until the results of some
early experiments are reported. Only at that time it is possible to begin estimating cost
and determining the schedule with confidence.
The planning becomes iterative, with more detail as it becomes available. In the first
case, predictive or plan-driven project techniques may work well. In the latter case,
adaptive or change-driven methods to iteratively determine the scope and plan for
risks may be more important” (Kloppenborg, 2015:13).
Classifying by Application – This guideline and the prescribed text book discusses
many types of projects, such as those dealing with:
Organisational change.
Quality and productivity improvement.
Research and development (R&D).
Information systems (IS).
Construction.
Many of these projects include extensive cross-functional work. This adds to

the challenge.
Part of the art of Project Management is:
Determining when to use certain techniques.

How much detail to use.

How to tailor the techniques to the needs of a specific project.
1.4.7. Scalability of Project Tools

Projects range in size and levels of intricacy. Consider two construction projects – one
on building a basic carport and the other to build a mall. Building a mall is a huge
project and would be intricate as opposed to building a carport which is a smaller
project that is relatively simple to carry out. However, in both cases, the following
should take place:
Determine the wants and needs of the customer(s).

Understand the amount of work involved.
Determine a budget and schedule.
Decide what workers are available and who will do which tasks.
Manage the construction until the owner accepts the project results.
While both projects require planning and control, the level of intricacy for the carport
is a time fraction of that for the mall. (Kloppenborg, 2015:14).
1.5. PROJECT ROLES
“To successfully initiate, plan, and execute projects, a variety of executive,

management, and associate roles must be accomplished, as shown in Exhibit 1.7.
In a large organisation, a person often fills only one of these roles’ sometimes, more
than one person fills a particular role.
In small organisations, the same person may fill more than one role. The names of
the roles also vary by organisation. The work of each role must be accomplished by
someone. Project Managers are successful when they build strong working
relationships with the individuals who execute each of these roles” (Kloppenborg,
2015:14).

1.5.1. P r o j e c t Executive - Level Roles

The four project executive-level roles are:
The steering team.
The sponsor.
The customer.
The chief project officer.
A steering/leadership team – this is usually the top leaders of an organisation. Such

a team plays an important role in selecting, prioritizing and resourcing projects. This
is done in accordance with the organisation’s strategic planning. This kind of team
ensures accurate progress is reported and necessary adjustments are made.
The sponsor – this is the second executive-level project role. Sponsor/s provide
resources and support for the project and are accountable for enabling success.
The senior customer representative- is the third executive-level project role. A

person serving in this role ensures that needs and wants of the various constituents in
the customer’s organisation are identified and prioritized. This person will also ensure
that project progress and decisions continually support the customer’s desires so that
the customer is satisfied.
In agile projects - The customer representative role is continuous and active.

The chief project officer’s role is sometimes called a Project Management Office
(PMO). This is “an organisational structure that standardizes the project related

governance processes and facilitates the sharing of resources, methodologies, tools

and techniques. The PMO can range from supporting Project Managers, to
controlling them by requiring compliance to directive in actually managing projects”
(Kloppenborg, 2015: 14).
1.5.2. Project Management – Level Roles

This is a management level played by the Project Manager. According to
Kloppenborg (2015), the Project Manager is “the person assigned by the performing
organisation to lead the team that is responsible for achieving the project
objectives” (Kloppenborg, 2015:14). The Project Manager is usually held accountable
for the project results, schedule, and budget.
The Project Manager is the key communicator. This person is responsible for the
planning and execution of the project. This person oversees and is responsible for all
the work required to be performed by specific people on a project from beginning of
the project to the end of the project. The Project Manager makes things happen and
uses the power of influence to do so since his/her formal power may be limited.
Another key management role is that of the Functional Manager who are
usually department heads and are the ongoing managers of the organisation.
Functional Managers determine how the work of the project is to be accomplished and
they may often supervise that work. They engage in negotiations frequently with the
Project Manager on which workers should be assigned to the project.
The Facilitator – This is a third managerial role. “If the project is complex and/or
controversial, it sometimes makes sense to have another person help the Project
Manager with the process of running meetings and making decisions” (Kloppenborg,
2015:15).
1.5.3. Scrum Master

In agile projects, a new title is introduced- that of the scrum master who in effect is a
Project Manager who serves and leads in a collaborative, facilitating manner.

1.5.4. Project Associate - Level Roles

Project associate level roles consist of members who are directly involved in
Project Management activities and may be known as core team members.
The core team together with the Project Manager do most of the planning and make
most of the project-level decisions. Temporary members that are brought on board are
known as subject matter experts and are people that are utilised on an as-needed
basis.
THINK POINT
Think about what would happen if executive, management and associate roles
were not accomplished.
1.6. SUMMARY
This unit discussed what a project is, the history of project management and how to
describe project work. Projects must be planned and managed. Projects are
temporary and unique while operations are more continuous work.
We have learnt more on soft skills and hard skills and the importance of both skill
sets that Project Managers and leaders should possess.
Project Managers are responsible, accountable people and are therefore put in charge
of projects to see these through from start to finish. In this section the project life cycle
stages were discussed namely; selecting and initiating, planning, executing, closing
and realising.
Projects should follow guidelines as prescribed by the Project Management Institute

(PMI) and Project Management Body of Knowledge (PMBOK). There are five process
groups and ten knowledge areas that guide project management. All projects should
and most do follow generally accepted methods. Selecting and prioritizing projects,
project goals and constraints, project success and failure, types of projects and
using MS Project were also discussed in detail in this unit.

You have now come to the end of unit one. Do the activities to test your
knowledge!
ACTIVITIES
ACTIVITY: 1.1
What is the difference between projects and operations?
ACTIVITY: 1.2
What are the features of soft skills and hard skills?
ACTIVITY: 1.3
What questions should the pioritization efforts include?
ACTIVITY: 1.4
Briefly discuss the four project executive-level roles.
ACTIVITY: 1.5
What is the purpose of a scrum master?

CHAPTER 2:
PROJECT SELECTION AND PRIORITIZATION
2. INTRODUCTION
This unit focuses on: strategic planning and portfolio management processes;
strengths and weaknesses of using financial and scoring models to select projects.
Selecting, prioritizing and resourcing projects as part of strategic planning are included
a part of the discussion in this unit.
How to select projects using a scoring model and how to secure projects from a
contractor’s viewpoint are also discussed herein. This unit end with a summary and
unit activities. The learning outcomes are listed below.
Learning Outcomes:
Understand and be able to explain in your own words the strategic
and planning portfolio management process.
Compare strengths and weaknesses of using financial and scoring
models to select projects.
Describe how to select, prioritize and resource projects as an outgrowth

of strategic planning.
Demonstrate how to select and prioritize projects using the scoring model.
From a contractor’s viewpoint, describe how to secure projects.

2.1. STRATEGIC PLANNING PROCESS
A company’s senior leadership is tasked with setting the firm’s strategic direction.
This usually happens when an organisation is young or when it is being revamped.
Strategic planning may be required to occur to repeatedly in some firms.
2.1.1. Strategic Analysis
The first part in setting a strategic direction is to conduct an analysis of the external
and internal environments. This is done to determine how to enhance or limit the
organisation’s ability to perform. This strategic analysis is referred to as a SWOT
analysis.
A SWOT analysis is:

Strengths.
Weaknesses.
Opportunities.
Threats.
The internal analysis (element within the project team’s control) deals with the
strengths and weaknesses of the organisation.
The external analysis (elements out of project team’s control) deals with the
opportunities and threats from: competitors, suppliers, customers, regulatory agencies,
technologies, and so on.A strategic analysis can be informative and provides
direction for an organisation. See Exhibit for an example of a SWOT analysis for for
the Built Green Home at Suncadia.

(Source: Kloppenborg, 2015: 28).
THINK POINT
Think about what would happen if the external and internal environments were
not analysed.
2.1.2. Guiding Principles

When the SWOT analysis is completed, the leadership team should work on creating
guiding principles such as the vision and mission. This step can be broken into many
parts but for simplicity’s sake, they are treated as part of the mission in this text.
Vision - The vision “must convey a larger sense of organisational purpose”
(Kloppenborg, 2015:29). It should be motivating and guiding. A clear and persuasive
vision ensures all members and stakeholders of an organisation understand and
aspire to achieve it.

Although, visions often require extra effort to achieve this effort is worthwhile.
Mission Statement - The mission statement is an approach to accomplish the vision.
It includes the “organisation’s core purpose, core values, benefits, culture, primary
business, and primary customers” (Kloppenborg, 2015:30).
The aspects which should be part of an organisation’s mission statement are as
follows:
The purpose -this communicates why the organisation exists.
The core values - communicates how decisions will be made and the way
people will be treated.
Beliefs - communicates the ideals for which its leaders and members are
expected to stand for.
ulture - instructs members to act in the desired manner.
The primary business areas – all in the organisation must understand on

what business the organisation wishes to engage in.
By identifying the primary customers - everyone will understand which groups of
people need to be satisfied and who is counting on the organisation.
The mission needs to be specific in describing the business areas and customers to
set direction however it does not have to be so specific that the organisation lacks
imagination.
2.1.3. S t r a t e g i c Objectives
Strategic objectives, are the means of achieving the mission and vision. For most
organisations, objective setting occurs yearly. Some organisations may revise
their objectives at three or six-month intervals.
Many of the strategic objectives identified will take more than a year to achieve. The
objectives describe both short-and long-term results that are desired along with
measures to determine achievement.

Organisations that embrace a triple bottom line in their values will have objectives
promoting each bottom line, and projects that are selected will contribute toward
each..These objectives should guide decisions regarding which projects to select
and how to prioritize them. An example of strategic objectives from The Internet
Society is shown in Exhibit 2.4.
2.1.4. F l o w -Down Objectives

After strategic objectives are set, they must be enforced. Projects tend to be the
main method for realizing many objectives.
In a small organisation, leaders may proceed directly to selecting projects at this point.
If the organisation is large, leaders may delegate project decisions and stipulate that
the decisions should be aligned with all of the organisation’s strategic planning that
has taken place to a certain point.
Regardless of the organisation’s size, several methods of project selection may be
utilised.
2.2. PORTFOLIO MANAGEMENT
Portfolio Management “aligns with organisational strategies by selecting the right

projects, prioritizing work, and providing needed resources” (Kloppenborg, 2015:31).
“The goal of portfolio management is to achieve the maximum benefit toward the
strategic goals of the company. To accomplish this, executives need to identify,

select prioritize, resource, and govern an appropriate portfolio of projects and

other work” (Kloppenborg, 2015:31).
THINK POINT
How is project success measured?
Project success is often measured by the following:

On how much the project contributes to the organisation’s objectives.
On the traditional measures of staying within budget and schedule.
On achieving the goals promised at the start of the project.
On obtaining the desired return on investment.
To understand how various work is related, organisations utilize an approach of

classifying portfolios, programs, projects and sub-projects.
Note: This method is not used by all companies. By understanding how the four
classifications are related helps one see where any particular portion of work fits in the
organisation.
2.2.1. P o r t f o l i o s
In large organisations it is not unusual to find that there are many projects in motion at
the same time. A portfolio can be defined as “projects, programmes, sub-portfolios,
and operations managed as a group to achieve strategic business objectives”
(Kloppenborg,2015:32). Project portfolios are similar to financial portfolios.
In a financial portfolio, diversification of investments is a method of reducing risk. The
returns on each investment are evaluated individually, and the entire portfolio is
evaluated as a whole. In a project portfolio, each project should have a direct
impact on the organisation.

Essentially, an organisation’s leaders should identify the organisation’s future

direction through strategic planning. This would result in identifying several possible
projects to further achieve the organisation’s goals.
Leaders determine what should be undertaken first. “Organisations typically try to
have a sense of balance in their portfolios by including:
Some large and some small projects.
Some high-risk, high-reward projects, and some low-risk projects.
Some projects that can be completed quickly and some that take substantial
time to finish” (Kloppenborg, 2015:32).
THINK POINT
Think about what would happen if an organisation did not have a balanced
portfolio.
2.2.2. P r o g r a m s
A program is “a group of related projects, sub-programs, and program activities
managed in a coordinated way to obtain benefits not available from managing them
individually” (Kloppenborg, 2015:32).
“Programs often last as long as the organisation lasts. For example, the U.S. Air Force
has an engine procurement program. As long as it intends to fly aircraft, it will need to
acquire engines. Within the engine program are many individual projects. Some of
these projects are for basic research, some are for development of engines, and
together are for purchasing engines” (Kloppenborg, 2015:32).
Each project has a Project Manager, and the entire program has a program manager.
Project Managers deal with the trade-offs of: cost, schedule, scope, and quality on their
individual projects. The program manager deals with making trade-offs between
projects for the maximum benefit of the entire program.
Programs deal with a specific group of related projects, while a portfolio deals with all
of an organisation’s projects/programs.

THINK POINT
Think about what would happen if a program manager was not allocated to a
large program.
2.2.3. Projects and Sub-projects

A subproject is “a smaller portion of the overall project when a project is sub-divided
into more manageable components or pieces” (Kloppenborg, 2015:33). In a large
project individuals may be assigned as sub-Project Managers and asked to manage
their sub-project as a project. Some sub-Project Managers may even work for another
company. “The Project Manager needs to coordinate the various sub-projects and
make decisions that are best for the overall project. Sometimes this may require that a
particular sub-project be sacrificed for the greater project good” (Kloppenborg,
2015:33).
THINK POINT
Why will changes to a project be a possible cause of failure for the project?
Below are some of the most typical reasons for project failures:
Not enough resources.

Not enough time.
Unclear expectations.
Changes to project.
Disagreement about expectations.

THINK POINT
Why do you think that it is important for managers to perform

portfolio management on a project?
How can these project failure reasons be overcome?

A manager must align potential projects with the parent organisation’s goals.
Managers also assess the organisation’s ability to perform projects.
They identify, select, prioritize, resource, and govern a portfolio of projects and other
work that will help the organisation achieve its strategic goals. In doing this managers
are performing portfolio management.
When companies consider their entire portfolio of work, they sometimes envision
projects as means of developing knowledge that can be capitalized upon in ongoing
work processes to provide profit. See Exhibit 2.6.

2.2.4. Assessing an Organisation’s Ability to Perform Projects

Assessing an organisation’s strengths and weaknesses is a vital part of aligning
projects with the organisation. If an organisation does not possess the sufficient
capacity, a project that may support organisational goals may be too challenging
to complete.
Below are some questions that must be asked to find out a firm’s ability to
support projects:
Do we have a teamwork attitude, free and open communication, creativity,

and empowered decision making?
Do we have a clearly defined project management process?
Do our associates have the right attitudes, skills, and competencies to use
the project management process?
Are our leaders at each level willing to take appropriate personal risk?
Does senior leadership establish a strong leadership foundation?
Do individuals and teams exhibit leadership at their respective levels?
Do we monitor and understand our external environment?

(Kloppenborg, 2015:34)
2.2.5. Identifying Potential Projects

Identifying potential projects can be in response to the following factors:
Market demand.
Strategic opportunity.
Social need.
Environmental consideration.
Customer request.
Legal requirement.
Technological advancement.

This is done in a systematic manner-not just by chance. Certain opportunities may

reveal themselves to the organisation. This means people at all levels and areas
must help identify potential projects. For example, sales people can uncover many
opportunities through discussions with existing/potential customers.
Everyone in the firm should be aware of industry trends. Many industries have
trade journals that can be read regularly for potential project ideas.
After prospective projects are recognized, the next step is to develop a brief
description of each. The leadership team that will select and prioritize projects
needs to understand the nature of the projects under consideration.
This calls for documentation. Usually the work is summarized in a brief
statement for work, which is a “narrative description of products, services, or results
to be provided by the project” (Kloppenborg, 2015:35).
The reason why the project is important is often summarised as a business case.
Is the project worth the required investment? The business case normally
includes both why the project is needed and an estimate of costs and benefits.
See Exhibit 2.7 for a series of processes that are utilised to select, prioritize, and
initiate. The rectangles represent work processes, and the documents represent inputs
into and deliverables out of the work processes.

2.2.6. Methods for Selecting Projects

Some considerations in prioritizing project selections are to first determine the
following:
What value does each potential project bring to the organisation?
Are the demands of performing each project understood?

Are the resources needed to perform the project available?
Is there enthusiastic support both from external customers and from one or more
internal champions?
Which projects will best help the organisation achieve its goals?
The methods of systematically selecting projects include both:

Financial
and Scoring models.
A financial analysis is necessary as from management’s perspective, projects are

investments. Therefore, proper selection should yield a portfolio of projects that
collectively contribute to organisation success.

There are three different approaches which are used to ensure both financial
and non- financial factors are considered when selecting projects.
These three approaches are:
Financial Analysis.
Financial Models.
Financial Justification.
Financial analysis is utilised as the primary means of determining which

projects are selected. Some organisations use financial models as screening
devices to qualify projects or even just to offer perspective. Qualified projects then go
through a selection process using a scoring model. Financial justification is one
factor utilised in multifactor scoring model.
2.2.7. Using a Cost-Benefit Analysis Model to Select Projects

Cost-benefit analysis is “a financial analysis tool utilised to determine the benefits
provided by a project against its costs” (Kloppenborg, 2015:36). These models
compare expected project costs to expected project benefits. Net Present Value (NPV)
- This is the most widely accepted model. When using NPV, the analyst firm
discounts the expected future value of both the project costs and benefits,
recognizing that a dollar in the future is worth less than a dollar today.
Then the analyst subtracts the stream of discounted project costs from the
stream of discounted project benefits. The result is the NPV of the potential project. If
the NPV is positive, then the project is expected to be profitable. Higher NPVs predict
higher profits. Benefit-Cost Ratio (BCR) -This is another model that is sometimes
utilised. The ratio is obtained by dividing the cash flows by the initial cash outlay. A
ratio above 1.0 suggests the project expects to make a profit, and a higher ratio than
1.0 is better.
Internal Rate of Return (IRR) - In this model, the analyst calculates the percentage
return expected on the project investment. A ratio above the current cost of capital is
desirable, and a higher expected return is better.

Payback Period (PP) – This ratio is used to calculate how many years it would take
for an initial project investment to pay back. Shorter payback periods are more
desirable than longer term payback periods. This makes sense doesn’t it? If you
invest in a project you would want to derive the returns as soon as possible!
Advantages and Disadvantages of Each Method - The payback period model does
not consider the amount of profit that may be generated after the costs are paid.
Thus, two projects with a similar payback period could look equal, but if one has
substantially higher revenue after the payback period, it would clearly be superior.
BCR would not be acceptable unless all costs and benefits were calculated in present
dollars (it is similar to NPV because they can favour smaller projects that create less
total value for the firm but have high percentage returns). For example, a huge project
with a medium rate of return would create a lot of value for a firm but may be passed
over for a smaller project with a higher return if only one project must be chosen.
Additionally, it is sometimes quite difficult to calculate an IRR if a project has non-
conventional cash flow.
The finance field recommends using NPV method. The other measures can be
calculated to provide perspective or to communicate with people who might not
understand NPV. However, none of the financial models ensure alignment with an
organisation’s strategic goals. Therefore, financial analysis, while very useful, is
normally not enough. There are several financial models that have weaknesses.
These models must first be understood before using them.
2.2.8. Using a Scoring Model to Select Projects

A scoring model helps to ensure that selected projects make financial sense, as well
as select and prioritize potential projects. A scoring model is useful whenever there are
multiple projects and numerous criteria to be considered.
Identifying Potential Criteria - “These criteria should include how well each potential
project fits with the organisation’s strategic planning. The criteria may also include
items such as risk, timing, resources needed, and so on. A normal practice is for the
company’s leadership team to jointly determine what criteria will be utilised to select
projects”

Determining Mandatory Criteria - “Once the leadership team agrees on a list of

criteria, the next step is to determine whether any of the criteria are mandatory. That
is, are there any situations that dictate a project must be chosen regardless of
any other considerations? Examples of this include government mandates and
safety/security situations. This list of “must do” projects should be kept as small as
possible since these projects automatically get selected and can crowd out other
worthwhile projects” (Kloppenborg, 2015:38).
Weighting Criteria - Next, the leadership team determines the relative importance or
weight of each decision criteria. Many firms utilise the basic methods defined here for
creating criteria weights. See Exhibit 2.10 for an example of project evaluations.
“First, executives determine which criterion is most important and give that a weight of
10. Then they ask how important in comparison each of the other criteria is. For
example, if the executives in a consumer products company thought development of
new products was most important, it would be assigned a weight of 10.
If the customer relations factor was deemed almost as important but supplier relations
and probability of project success were each deemed to be half as important as new
product development, each would be assigned 5.
The resulting criteria with weights are shown in Exhibit 2.10 in the top row of the
selection and prioritization matrix. Most organisations will decide to use about three to
five criteria. Lesser-rated criteria can be utilised as tie breakers if needed”
(Kloppenborg, 2015:38-39).

Evaluating Projects Based on Criteria – Here the leadership team evaluates each
project against each criterion. Concentration is on one criterion at a time. This is
and effective method done by going down each column in turn.
An easy technique for this is to rate each project on that particular criterion with
scores ranging from 1 (potential project has little/negative impact on this criterion).
The upper left portion of each cell in the matrix can show the rating. This signifies how
well that project fulfils that criterion.
After a project has been rated on a specific criterion, that rating should be multiplied
by the weight allocated to that criterion. This is then displayed as the weighted score
in the main body of each cell.
The total for each project should be added across the row. The highest-scoring
projects would usually be selected. If numerous projects have close scores, other
criteria can be utilised to break the tie.
See an example of this in Exhibit 2.11. There is a tie between Projects A and B.

Sensitivity Analyses – This entails examining what would happen to the decision if
factors affecting it were to change.
Selection criteria may be added or changed. Certain criteria that are viewed as
more important than others may be weighted accordingly. Missing criteria or new
alternatives can be added and the decision reviewed. “For example, if the team
evaluating the projects in Exhibit 2.11 had a bad experience with an unsuccessful
project and decided to re-evaluate their decision with success probability now
weighted at 9 for very important, the new project selection and priority matrix would be
calculated as shown in Exhibit 2.12. A company might want to select several projects.
If so, the scores from the selection matrix could serve as one method of prioritizing the
projects” (Kloppenborg, 2015:39).

2.2.9. Prioritizing Projects

How is this done? The decision-makers will need to determine which projects will
receive assigned resources and be scheduled to begin first.
If there are several projects that have been selected by a company not all of them can
begin at the same time.
The scoring models can be used to provide input on the starting order of projects.
“Most leadership teams will consider the weighted scores of each product as a starting
point in assigning resources to projects and determining their start dates”
There are other issues that are generally discussed by the leadership team. These
issues are:
The urgency of each project.
The cost of delaying the expected benefits from various projects.
Practical details concerning the timing.
One more discussion often arises in prioritizing process- if there is a conflict

between resource needs for two projects, which one gets the needed resources first?
This is left to the project sponsors to decide or, for important projects, the leadership
team. In that way, the possibility of the critical project being held up by a
misunderstanding is reduced.

See Exhibit 2.13 on how the Alternative Breaks (AB) planning committee at a
university ranked spring break projects. This exhibit shows four of the twenty-six
projects that were selected.
Each trip is a minor project while all twenty-six trips collectively form the complete
project.
2.2.10. Resourcing Projects

Resources must now be assigned to projects that have been prioritized. Resources
comprise of vital people such as sponsors, Project Managers, core team members,
and subject matter experts.
It can also involve money, space, and equipment that these may be in limited quantity.
The simplest method is to utilise a resource assignment matrix and start by allocating
resources to the highest priority projects. See Exhibit 2.14.

2.3. SECURING PROJECTS
This section deals with projects a company (client) wants performed, but for which it
may hire external resources (contractors) to execute significant parts or all of the work.
Client companies may initially put prospective external projects through a selection
and prioritization process and, if selected, then choose whether to execute the work
internally (make) or hire others (buy). If the decision is to buy, then the client company
must plan and carry out the procurement.
Contractor companies need to identify potential project opportunities. They should

then determine which project opportunity to pursue and to submit proposals.
They must be prepared to either bid or negotiate to secure the work.
2.3.1. Identify Potential Project Opportunities

Contractors looking for external projects should do this in the same manner as a
company considering internal projects. Since contractors are looking externally, they
should have agents at trade shows, professional conferences, and anywhere that
information on the intentions of potential customers and competitors may surface.

Contractor companies should also establish customer relationship management. They

can do this by creating and developing personal contacts at different levels and
functions.
Contractor companies can also establish customer relationship management by

joining information systems. This helps to recognise any useful information
regarding possible future projects and develop management of current projects.
2.3.2. D e t e r m i n e Which Opportunities to Pursue

Most contractor companies are best served by targeting the projects they wish to
follow. Some companies have a strategy that they will bid on all projects of potential.
They do this on the mind-set that if they do not bid they do not have a chance to get
the project. Many companies are of the view that if they target their
opportunities, their likelihood of acquiring the work on any proposal increases.
It takes time and resources to create a good proposal, so it is helpful to develop a
bid/no-bid decision strategy. All companies have strengths and weaknesses compared
to their competitors. A basic SWOT analysis could be developed to determine
whether to follow a potential project. Decision makers should also consider the cost
to pursue the work, and the likelihood of securing the project given the likely
competition. Furthermore, a company regularly considers the risks of pursuing and not
pursuing a potential project. Finally, does the company have the ability to complete the
work if it is granted?
2.3.3. P r e p a r e and Submit a Project Proposal

When a firm prepares to submit a proposal, it is essentially completing a minor
project with the primary deliverable being a conclusive and thorough proposal.
The contractor should understand the project’s source selection criteria, which is the
“set of attributes desired by the buyer which a seller is required to meet or exceed to
be selected for a contract” (Kloppenborg, 2015:43).
A client will usually want to be persuaded that the possible contractor is competent:
Technically.
Managerially.
Financially.

Operationally.
Successful Project Managers work hard to assure potential clients that they are
capable on all four dimensions. A small list of these aspects is shown in Exhibit 2.15.
2.3.4. N e g o t i a t e to Secure the Project

After all proposals have been conveyed and assessed, the client company may
choose to either grant the project or go into negotiations with one or more
prospective contractors. On more routine projects, the contract may be granted at this
point. Further explaining and negotiations may proceed for complicated projects.
A client company and a contractor company may negotiate on:
The amount of money to be paid on a project.
Contractual terms.
Schedule.
Quality standards.
Reporting mechanisms.
Specific personnel to be assigned to work on the contract.
Effective Project Managers know that they have to prepare well for negotiations. This
begins with a clear understanding of what is imperative to their management. It
includes fact-finding with the client company to understand its necessities and
capacities.

Equipped with the understanding of both perspectives, a Project Manager tries to find
a solution that enables the organisation to be granted the project work with a sufficient
profit prospect and with the commencement of a sound working relationship with the
client.
2.4. SUMMARY
In this unit project selection and prioritization was extensively discussed. Project
selection starts with the organisation’s strategic planning. An analysis is done on the
internal strengths and weaknesses of an organisation and externally on threats
and opportunities. Organisations then develop guiding principles such as the vision
and mission statements.
Once the strategic planning is accomplished the organisation will engage in portfolio
management. At this point an open and honest assessment is made on the
organisations ability to perform projects. Resource availability, organisation
capabilities of individuals to be assigned on the project/s are determined by
organisation’s leadership.
There will be an ongoing portfolio management of activity for everyone in the

firm to identify possible opportunities they feel may help the organisation to achieve its
goals.
Potential projects are identified and briefly described with statements of works and
business cases. These potential projects should be put through a process to
determine which should be selected and what their relative priorities are. Financial
and scoring models are often used to evaluate potential projects. Once a project list is
selected all the projects need to be prioritised so that some can begin immediately
and others at a later date. Contractor companies are constantly on the lookout for
potential project opportunities. (Kloppenborg, 2015:44).
You have now come to the end of unit two. You are encouraged to
complete the activities to test your knowledge on this section.

ACTIVITIES
ACTIVITY: 2.1
What is a SWOT analysis?
ACTIVITY: 2.2
Once a SWOT analysis is complete, what are some of the guiding principles that the
organisations leadership should establish?
ACTIVITY: 2.3
What is a sub-project?
ACTIVITY: 2.4
What are some of the typical reasons for project failure?
ACTIVITY: 2.5
What are some of the disadvantages of using Cost-Benefit Analysis models?

CHAPTER 3
ORGANISATIONAL CAPABILITY - STRUCTURE,

CULTURE, AND ROLES
3. INTRODUCTION
Unit three discusses types of organisational structures and the advantages and
disadvantages of each type of structure. Organisational culture and its impact on
projects, project life cycles, agile project management, project executive roles and
project team roles are also discussed in detail. This unit ends with a summary and
activities that the student is encouraged to complete. The learning outcomes of unit
three are given below.
Learning Outcomes:
Compare and contrast the advantages and disadvantages of the functional,

project, strong matrix, balanced matrix and weak matrix methods of organisations.
Describe organisational culture elements that are helpful in planning and
managing projects and demonstrate how to overcome organisational culture
elements that hinder project success.
Given a project situation, describe ethical behaviour consistent with PMI’s
Code of Ethics and Professional Conduct.
Describe different project life cycle models and distinguish when each is
appropriate.
Describe the duties, motivations, and challenges of each of the executive,
managerial, and team roles in projects and list important attributes for
selecting each.

3.1. TYPES OF ORGANISATIONAL STRUCTURES
The three types of organisational structures discussed in this unit are:

Functional Organisation
Projectised Organisation
Matrix Organisation
There are various methods that can be used for establishing organisational
structure and contemporary companies choose what would suit them. Organisational
structures include work assignments, reporting relationships, and decision making
responsibility. Each method of structuring organisations has its strengths and
weaknesses. In this section, the various organisational methods and the impact of
each on managing projects is investigated. The advantages and disadvantages of
each organisation form are discussed in the following sections.
3.1.1. F u n c t i o n a l Organisation
A functional organisation is based on the traditional approach. It is hierarchical and
each employee has one superior who is an expert in his area for example marketing or
finance. In a hierarchical organisation, staff are grouped by areas of specialization and
are managed by a person with expertise in that area. There are clear lines of authority
as on the type of work that is to be carried out.
Think about accountants as an example, who will report to the head of accounting, in
the same way all marketers will report to the head of marketing. See Exhibit 3.1 for a
typical layout of the functional organisation. Here you will note that everyone in the
organisation reports up through one and only one supervisor.

The Functional Manager does the following:

Controls the project budget.
Makes project decisions.
And is the key person that coordinates project communications outside of the
functional areas. He/she does this by contacting her/her peer Functional
Managers.
The advantages of a functional organisation are:
There is unity of command - all workers understand what they need to do
because instructions come through from only one boss.
Workers learn quickly from each other - having one boss or supervisor
enable employees to learn readily from each other thus keeping technical skills
sharp.
There is security - employees are secure that they will still have a job after a
project is complete as they will continue to report to the same Functional
Manager.
Functional organisations will work well on smaller projects that require most of the
work from a specific department because of the advantages mentioned above and
because the Functional Manager shares resources among various small projects and
centrally controls the work.

Some disadvantages of the functional form of organisation are:

Slower response time - Communications can become slower, especially
when multiple functions need to have input.
There are technical challenges - if input is required from multiple disciplines.
Lack of understanding - the Functional Manager may not understand
other departments as well as he/she does their own department.
Steeper communication channels - make for slower decision making and
slow response to change.
“Functional organisational structures are typically used in businesses that primarily sell
and produce standard products. For example, a company that manufactures and sells
electronic medical devices may have a functional organisational structure. In the
functional organisational structure, groups consist of individuals who perform the
same function, such as engineering, manufacturing, or have the same expertise or
skills such as graphics design or mechanical assembly” (Gido and Clements,
2015:437).
3.1.2. T h e Projectised Organisation

A projectised organisation is the exact opposite of the functional organisation. A
projectised organisation is defined as ‘any organisational structure in which the Project
Manager has full authority to assign priorities, apply resources, and direct work of
persons assigned to the project.” (Kloppenburg, 2015:55). In a projectised organisation
form, the larger organisation is broken down into self-contained units. These units
support large projects, geographies or customers. Usually, people assigned to a
project within this type of organisation report upward through the Project Managers.
The advantages of the projectised organisation are:

Traditional department barriers are reduced - because staff from different
functions report to the same Project Manager.
The Project Manager is responsible for communications - this makes
response times and decision making swift.
Workers have a clear understanding of what needs to be done- because
only one ‘boss’ which is the Project Manager gives them the instructions.

The technique of co-location is utilized - Co-location is an

organisational placement strategy where project team members are physically
located and are close to one another. This improves communication, working
relationships and productivity. Co-location results in enhanced project team
identity, strong customer focus and effective integration.
The disadvantages of the projectised organisation are:

Costly - Team members are often assigned to one project only - this is the
case even if a project requires part of their time and this is costly for the
organisation.
Separation of staff - The team may be physically located onsite and not with
the rest of the organisation.
Some projects may tend to develop their own work methods - this
disregards those of the parent organisation.
Teams can stray if not monitored closely - New methods may be
useful, however, project teams that are not monitored closely can fail to
practice important organisational norms.
Lessons may not be passed on to other project teams.
Co-location of members - that learn more about broader project issues, may
not keep up their discipline specific competence.
Insecurity - Team members may also worry about what they will do once
the project reaches completion.
THINK POINT
How does the Matrix Organisation structure function?

3.1.3. Matrix Organisation

“A matrix organisational structure is a hybrid of the functional and autonomous project
organisational structures, in which resources from appropriate functional components
are temporarily assigned to particular projects that have managers from the project
component of the organisation” (Gido and Clements, 2015:441).
We have seen that both the functional and projectised structures have advantages and
disadvantages and that in extreme strategies either the Functional Manager or the
Project Manager has a great deal of authority which has its advantages but can be
viewed as significant weaknesses as well.
In order to capture many of the advantages of both types of organisations and to try to
eliminate as many weaknesses of possible of each organisational form many
organisations use an intermediate organisation which is known as the matrix
organisation.
In the matrix organisation which is any organisational structure, both the Project
Manager and the Functional Manager have some authority and share other authority.
In this type of structure the Project Manager shares responsibility with the Functional
Manager in assigning priorities and directing the work of persons that are assigned to
the project. Refer to Exhibit 3.3 on a matrix organisation.

Note: Project team members will report to both functional and Project Managers and
this is a clear violation of the unity-of command principle; however, this is
necessary for the benefits of the matrix organisation to be enjoyable. The hoped-for
benefit of the matrix structure is a combination of the task focus of the projectised
organisational structure and the technical capability of the functional structure.
(Kloppenborg, 2015: 56)
The advantages of the Matrix Organisation structure are:

Good visibility - There is good visibility on who is working where.
Resources can be shared - between departments and projects.

Possible duplication is reduced - This is a major advantage in this age of
lean thinking in doing business.
Co-operation between departments can be very good - because both
managers are involved.
Higher quality decisions - decisions tend to be of higher quality and are
better accepted due to more input.
The development and retention of special skills - people are able to
develop and retain discipline specific knowledge as they still report to their
Functional Manager.
Effective integration – this is possible as the various discipline reports to
the same Project Manager who is responsible for recording lessons learned.
The function manager is responsible for how the work in a function is performed
and therefore any lessons learned are effectively shared between projects.
There is flexibility and sharing of decision making authority - the amount
of decision making authority that can be equally shared in whatever manner
desired.
A weak matrix is when the Project Managers have less authority than the
Functional Managers.
Many organisations begin to evolve when Project Managers are given a bit more
decision making authority. A progression of a balanced matrix is where the Project
Managers and the Functional Managers have about equal power.

A strong matrix is one where the Project Managers have more power than the
Functional Managers and this is similar to a projectised organisational form. Refer
to Exhibit 3.4 to view the progression of forms.
The disadvantages of Matrix organisational structure are:

Having two bosses - two bosses that is the Project Manager and the
Functional Manager is viewed by some as a disadvantage. Each manager may
try to do what they think is best for their project or department and may
therefore give conflicting advice.
Slower decision making - decisions may not be made fast as there are sources
of conflict, more meetings, more challenges to control and so on.
Many sources of conflict – each manager tries to do what is best for

his/her department and may give conflicting advise. There may be conflict
during staff performance reviews with having two managers.
Hard to monitor and control – conflict situations are difficult to monitor and
control
More meetings – takes time but is necessary to understand what needs to

be done.
Firms should consider the organisational structure that will best suit them to
capitalize on its advantages and to mitigate its disadvantages although; these
decisions do change over time. Refer to Exhibit 3.5 for a comparison of
organisational structures. Read up more on this section on pages 58 – 59 of your
prescribed text book.

3.2. ORGANISATIONAL CULTURE AND ITS IMPACT ON PROJECTS
Project Managers need to understand not only the structure of the parent
organisation they also should understand the culture of the parent organisation so
that they can communicate effectively.
Organisational culture comprises of values – these serve as a moral compass. It

guides and provides a frame of reference to set priorities and to determine what is right
or what is wrong. It is implemented via social rituals such as meetings, training, and
ceremonies along with symbols. Symbols – can be work layout and dress code that
are shared among the members of the organisation and taught to new members.
Values and symbols can informally do the following:

Motivate the ethical actions and communications of managers and
their subordinates
Determine how people are treated, controlled and rewarded
Establish how cooperation, competition, conflict and decision making are

handled

Encourage personal commitment to the organisation and justification for

its behaviour.
By understanding the culture of the parent organisation a Project Manager can

determine how to best develop the culture within his/her project. There are many
projects that are completed cooperatively between two or more parent
organisations. One organisation can be the contractor who will perform the project for
the other organisation that is the client.
When there is more than one parent organisation that is involved in a project the
Project Manager needs to understand the culture of each organisation well
enough to facilitate effective project communications and decision making.
(Kloppenborg, 2015:59-60).
3.2.1. C u l t u r e of the Parent Organisation
By studying the culture of the parent organisation the Project Manager needs to ask
the following questions:
What is the orientation of the corporate culture in general?
What are the ascribed values?
How is the organisation viewed by others in terms of living the values?
How does the organisation like to communicate internally and externally?
How well does the organisation support project management specifically?
Types of Power - A framework that is helpful in understanding a corporate culture

distinguishes the following four types of culture of on what is the most powerful
motivator:
Power Culture
Role Culture
Task Culture
Personal Culture

Power culture exists when the supervisor exerts a great deal of economic and political
power and everyone tries to please the boss. In this situation you will find that those in
formal authority control competition, conflict resolution and communication. –
motivates everyone to understand and closely follow their appointed roles.
Role cultures act as a motivator for everyone to understand and closely follow
their appointed roles. Formal designations of responsibility and utmost respect for
regulations and the laws are embraced by reliable workers.
Task culture is such that people tent to place more importance in getting a job done
and worrying about who does the work or gets the credit for it.
In personal cultures people have is genuine interest in the needs of the workers.
People consider the development of workers and regard this as critical to
organisational success. There is a display of attitude that is collaborative which is
satisfying and stimulating.
3.2.2. Project Cultural Norms

There are many things that can be done by effective sponsors and Project Managers
to promote good working cultural norms within the project. In so doing the sponsor
and Project Manager must have an understanding of organisational politics and
then work towards developing cooperation within the core project team and among the
various groups and relevant stakeholders to a project. In determining how to crate
project culture ethics should be an important consideration to determine how people
should act in the best interest of the project.
PMI Code of Ethics and Professional Conduct indicates guidelines for Project
Managers to instill as follows:
Responsibility – take ownership for decision

Respect – show high regard for ourselves, others, and resources
Fairness – make decisions and act impartially
Honesty – understand the truth and act in a truthful manner.

The Project Manager must do his/her best to personally show courage in making the
right decisions and creating an atmosphere in which others are encouraged to make
right decisions.
Why did PMI Code of Ethics and Professional Conduct indicate specific guidelines for
Project Managers to instill?
3.3. PROJECT LIFE CYCLE
“All projects go through a predictable pattern of activity, or project life cycle. Project
planning teams use project life cycle models because various types of projects have
differing demands. A research and development project may require a certain test
to be performed before management approves the expenditure of large amounts of
cash, while the manager of a quality improvement project may need to document how
the work is currently performed before it makes sense to experiment with a new
method. The major types of project life cycle model while differing in details have
some things in common” (Kloppenborg, 2015:62).
Below are some common factors in various project life cycle models:
All projects have definite starting and ending points
All projects involve a series of phases that must be completed and approved
prior to proceeding to the next phase
Each of the phases of a project will include at least one initiating, one planning,
one closing and one or more executing phases
The various life cycle models can be adapted by companies to suit or fit in
with the organisational culture and language.
There are several project models that represent the variety that is used in
improvement, research, construction, and agile projects.
Take note that the agile approach to project management is introduced in this
guideline and in the prescribed text book after its life cycle model. The rest of the units
and prescribed text book chapters will deal with the generic, plan-driven model that
includes selecting and initiating, planning, executing and closing and realizing
benefits.

See Exhibit 3.8 for an illustration of generic project life cycle model. In the prescribed
text book there are icons in the margins that highlight how the agile or adaptive
approach is different.
3.3.1. D e f i n e -Measure-Analyse-Improve-Control (DMAIC) Model

There are many firms and or organisations use projects to plan and manage quality
and productivity improvement efforts and there are various models that can be sued
for these improvement efforts.
Models may appear to be different in some ways but they all strive to use facts to
make logical decisions and to ensure the desired results.
The Six Sigma approach to improve quality uses DMAIC model and is discussed in
more detail in unit 11 of this guideline. See Exhibit 3.9 for a simple version of this
model.3.3.2. Research and Development (R&D) Project Life Cycle Model
Project management techniques are used by many organisations to organize,

plan, and manage research and development efforts.Research and development
efforts can vary in length – it can take as long as a decade or as little as a few weeks
to take something from an idea to a successful deliverable.
The length of time would depend on what is being researched and developed and on
what complexities exist.
There are some R&D that are complex with many phases. This is due to huge risks
and demanding oversight, See Exhibit 3.10 for a simple R&D model adapted
from defence development projects.

3.3.3. Construction Project Life Cycle Model
Construction projects differ to a great extent in size and complexity and there for a
variety of project life cycle models will be used. See Exhibit 3.11 for a generic
construction model.3.3.4. Agile Project Life Cycle Model
“One type of model increasingly used in information systems and some other projects
allow for incremental plans and benefits. These approaches have been variously
called iterative, incremental, adaptive, or change-driven. While agile is the umbrella
name, some of the specific approaches are called SCRUM, XP, Crystal, EVO,
phased delivery, rapid prototyping, and evolutionary” (Kloppenborg, 2015:63-64).
See Exhibit 3.12 for a generic agile project life cycle model.
Source: Kloppenborg, (2015:64)

3.4.AGILE PROJECT MANAGEMENT
Usually traditional plan-driven project management works well in many given situations
however, if the scope is difficult to define at an early stage of the project or if there is
much change that is expected then a change-driven or agile approach would be a
better option as it is known to often work better.
Project Managers find that the most useful method takes good practice from plan and
change- driven approaches.
In agile project the following occurs:
At the beginning there is a high level of overall planning.
Only work that will be done soon will be planned in detail.

The next part of the project emerges as people learn from the early work that is
undertaken.
The majority of the project work is done in iterations (a set length of time for e
example two or four weeks).
There is agreement from the project team that they will deliver something of
value as each iteration stage is completed.
Fixed time and the amount of committed resources allocated to each iteration
dictates what the size of the deliverable will be.
There is agreement between the project team and customer on how
the deliverable will be considered complete and useful.
Within each iteration there is initial planning, brief daily planning meetings, a
demonstration of the value at the end of the iteration and there is a
demonstration of the value at the end of the iteration.
Documentation are minimal at the early stage of the project and
becomes complete as the project progresses.
Change within an iteration is rarely permitted however, it is expected from
one iteration to the next.
All stakeholders need to be actively engaged. A sponsor or customer can be
one and the same or two different people.

In agile project management the customer or sponsor prioritizes work from a business
needs standpoint and makes trade-offs between value, quality, and constraints.
The scrum master (this is what the Project Manager is sometimes known as) is to
emphasize the needs to facilitate and remove obstacles. The project team needs to be
self-directed with high trust and all roles are more collaborative than confrontational.
3.5. PROJECT EXECUTIVE ROLES

Projects just do not happen or exist in a vacuum. Projects exist in organisations and
require resources and executive attention to be accomplished. Organisations use
projects as a primary method to reach organisational strategic goals.
A variety of players are involved from executive, managerial and associate levels.
See Exhibit 3.13 for an illustration of project executive, managerial and associate
roles. In smaller organisations one person may perform many roles.
There are four project executive roles namely, the steering team (ST), the
sponsor, the customer, and the chief projects officer (CPO).
3.6. PROJECT MANAGEMENT ROLES

The Functional Manager, Project Manager, scrum manger and facilitator occupy
manger- level roles in projects.
3.6.1. Functional Manager

“Functional Managers are often department heads.

Projects come and go, but departments generally remain. Functional mangers have
a large role in deciding how the project work in their functional area is done.
Functional mangers and Project Managers may negotiate who will be assigned to work
on the project.”
3.6.2. Project Manager

The Project Manager is an important person assigned to the project and spends a
large amount of time in communication with all people that have an interest in the
project. Leading, planning executing and closing of the project is carried out by
the Project Manager. The Project Manager should be someone that is flexible and a
facilitating leader among other skills.
The project manage is responsible for the project schedule and occupies a major role
in the decision of when and how project activities are to be accomplished.
Project Managers are trusted with delivering project results and therefore must be
worthy of such trust by possessing integrity, leadership and excellent communications
skills. “Effective Project Managers have strong leadership ability, the ability to develop
people, excellent communication skills, good interpersonal skills, the ability to handle
stress, problem solving skills, negotiating skills, and time management skills”
Gido and Clements,2015:324).
CHALLENGES – Project Managers deal with many challenges and one such
challenge is that they have more responsibility than authority. They need to
persuade people to accomplish tasks instead of ordering or instructing them to do so.
3.8. SUMMARY
This unit discussed the three organisational structures in detail and outlined the
advantages and disadvantages of each structure.
Projects are accomplished within organisations or between multiple organisations.
Project Managers. Managers, high level executives, sponsors, customers and teams
all play crucial roles in accomplishing projects.

Creating a consistent culture with the parent organisation is of utmost importance for
the Project Manager and sponsors as this contributes to the success of the project.
Project life cycles were also discussed in that projects have a start and end point.
Project life cycles do vary across organisations. Project Managers must understand
what project life cycle model is used in his or her organisation and must be able to
select or modify the project life cycles according to specific demands of the project.
You have now come to the end of this unit.
Do the following activities:
ACTIVITIES:
ACTIVITY: 3.1
State briefly what are the guidelines for Project Managers to instill?
ACTIVITY: 3.2
Name and discuss the three types of organisational structures.
ACTIVITY: 3.3
What are the four types of corporate culture?
ACTIVITY: 3.4
What are the five activities which revolve around the steering team?
ACTIVITY: 3.5
What is a sponsor?

CHAPTER 4
CHARTERING PROJECTS
4. INTRODUCTION
This unit discusses the project charter and its importance to project success. The
various elements of a charter and its application are discussed in detail. This unit also
covers how to create a charter for a small sample project and how to create a complete
charter for a real project. Initializing a project in Microsoft Project and setting up a
milestone schedule are also included in this unit. The unit ends with a summary
and end of unit activities. The learning outcomes are given below.
Learning Outcomes
Describe what a project charter is and why it is critical to project success.
List the various elements of a charter and tell of a charter and tell why each is
used.
Create each section of a charter for a small sample project using given
project information.
Work with a team to create a complete charter for a real project and present it to
a sponsor for ratification.
Initialize a project in Microsoft Project and set up a milestone schedule.

4.1. WHAT IS A PROJECT CHARTER?

The project charter is a vital project management concern. This small document acts
as an informal contract between the project team and the sponsor. Since a
charter is like a contract, it is helpful to remember what a contract is. The charter
signing signifies the move of the high-level project initiation stage into the more
detailed project planning stage.
Exhibit 4.1 for a review of the project life cycle. (Source: Kloppenborg, 2015:84)
The project charter is the deliverable that grants a project team the right to continue
into the more detailed planning stage of a project” (Kloppenborg, 2015). This may
include only permission:
To plan the project.
To make decisions that would slow the project if delayed.
To plan and perform the entire project in the case of a small, simple project.
Either the sponsor or project team can compose the draft. Ideally, the project team and
the sponsor openly discuss each part of the charter. “Like a contract, the people
who sign a charter are wise to ensure that they understand and agree to all of it.
Unlike a contract, however, both parties feel obligated to the spirit (as opposed to the
letter) of the charter since the project details have not yet been worked out and
specifics will certainly change” (Kloppenborg, 2015:84).
4.2. WHY IS A PROJECT CHARTER USED?
There are four major purposes that a project charter is used for. A project charter is
used to:

1. Authorize the Project Manager to proceed.

2. Help the project team and sponsor develop a common understanding.
3. Help the project team and sponsor commit.
4. Quickly screen out obviously poor projects.
Firstly, many Project Managers are not authorized to commit resources without a
charter. The charter gives the project and the Project Manager official status within the
parent organisation.
Second, everyone involved in the imminent project must establish a

common understanding of what the project requires. This generally is a broad
justification of the project and includes:
How it aligns with goals of the parent organisation.

Determination of what is included and excluded.
Rough schedule.
Success measures.
Major risks.
Rough estimate of resource needs and stakeholders.
When there is a clear and common understanding of project goals there are
added benefits as mentioned below:
Teamwork develops.
There is agreement, trust, communication, and commitment that develops
between the sponsor, Project Manager, and project team.
The project team does not need to worry if management will accept a decision.
The sponsor is highly unlikely to unilaterally change the original agreement.
Third, each person must personally and formally commit to doing their level best to
reach the agreed-upon project results.
This formal commitment encourages members to work hard on a project when things
are not going well.

Fourth, a charter is used to evaluate potential projects to determine which

appear to be poor choices. If a charter determines that a particular project is likely to
fail, planning time and money will be saved.
4.3. WHEN IS A CHARTER NEEDED?
“Project methods can be scaled from very simple to very detailed. A Project Manager
wants to use just enough detail” (Kloppenborg, 2015).
4.4. TYPICAL ELEMENTS IN A PROJECT CHARTER
Typical key elements of a project charter is discussed in the following section. The
majority of these sections are included in many charters however, one or two sections
are left out on other charters.
4.4.1. Title
Establishing a meaningful project title is essential. In an organisation with several
projects, the title can be used to easily recognize which project is being referenced.
4.4.2. Scope Overview

The scope overview and business case sections are the high-level “what and why”
of the project. The scope overview does the following:
Quickly describes the project work and results.
Distinguishes between what the project will and will not do.
Helps to prevent scope creep, which is the uncontrolled expansion to product or

project scope without adjustments to time, cost, and resources.
Can be considered to be the project boundaries. It states what is included
a n d what is not-at. This helps the project team to accurately estimate cost,
resources, and schedule needs and to understand and handle project risks.
4.4.3. B u s i n e s s Case
“The business case is the project’s purpose or justification statement. A business case
is used to justify the necessity of the project” (Kloppenborg, 2015:88).

4.4.4. B a c k g r o u n d
Some stakeholders may require more detail to understand the scope overview and
business case statements. A more detailed background statement may be useful in
such a case. The background statement can be any length. The background statement
is optional.
4.4.5. M i l e s t o n e Schedule with Acceptance Criteria

The milestone schedule is “a summary-level schedule that identifies the major
schedule milestones or significant points or events in the project” (Kloppenborg,
2015:88). It separates the project into a few milestones and the team estimates a date
when they expect to complete each milestone. A milestone schedule should list major
milestones and deliverables that the project team specifically wants to ensure are
finished on time and to the satisfaction of major decision makers. A deliverable is “any
unique and verifiable product, result, or capability to perform a service that is required
to be produced to complete a process, phase, or project” (Kloppenborg,2015:88).
Including a column for acceptance criteria factors to the milestone schedule helps the
project teams recognize who will judge the quality of the deliverable related to each
milestone. Acceptance criteria are “standards, rules, or tests… by which a product,
service, result, or process can be evaluated” (Kloppenborg, 2015:89)
4.4.6. Risks, Assumptions, and Constraints

A risk is “an uncertain event or condition that, if it occurs, has a positive or negative
effect on one or more project objectives” (Kloppenborg, 2015:89).
Assumptions are “factors in the planning process that are considered to be true,
real, or certain without proof or demonstration” (Kloppenborg, 2015). Project teams
often identify, document, and validate assumptions as part of their planning process.
Assumptions generally involve a degree of risk.
A constraint is “a limiting factor that affects the execution of a project”
4.4.7. Resource Estimates

Resources are: skilled human resources, equipment, services, supplies or funds and
are required for the project deliverable to be accomplished. How much of resources
does a project require? This has to be estimated.

The amount of staff time, equipment, or materials that are in short supply and/or the
amount of money that is required must be estimated as at this stage there is only a
general understanding of the project.
There will be approximate budgets and this should be stated and called the
preliminary budget which also includes the level of confidence one has in the
estimate. The level of confidence can be expressed in percentage terms.
4.4.8. Stakeholder List

Part of project success is in identifying and prioritizing stakeholders and managing
strong relationships with them and making decisions that satisfy stakeholder
objectives. It is good practice to identify and prioritize stakeholders at an early stage in
a project.
4.4.9. Team Operation Principles

Team operating rules or principles are sometimes created to improve team
functioning. The aim is to raise team efficiency and ensure that all parties are mindful
of what is expected. Team operating principles that are useful are those that deal
with conducting meetings, making decisions, accomplishing work, and treating each
other with respect.
4.4.10. Lessons Learned

A lot can be learned from the successes and failures of previous projects. Lessons
learned are the knowledge gained from past projects. To ensure that lessons learned
are used, a sponsor should only authorize the project to start once a few lessons from
recently completed projects are included in the charter. This forces the new Project
Manager and team to look at the organisation’s lessons learned knowledge
base to find appropriate learnings.
4.4.11. Signatures and Commitment

“The commitment section of charter lists who is involved and sometimes describes the
extent to which each person can make decisions and/or the expected time
commitment for reach person. This is where the project sponsor, Project Manager,
and core team members publicly and personally show their commitment to the project
by signing the charter. By formally committing to the project, the key players are

more likely to keep working hard formally committing to the project, the key players
are more likely to keep working hard during difficult periods and see the project through
to a successful conclusion” (Kloppenborg,2015:91).
4.5. CONSTRUCTING A PROJECT CHARTER

It is good for the sponsor to work with the team when creating the charter. However,
the sponsor, often does not have time to be present for the entire chartering period.
In such a case, it is very useful for the sponsor to produce the first draft. Once the
sponsor states what the project is and why it is important, the team use this as a
good start. If the sponsor wants the team to consider any important constraints,
assumptions, risks, or other factors, he/she can help the team by indicating that up
front.
4.5.1. S c o p e Overview and Business Case Instructions

The first draft of these two sections should be delivered by the sponsor or the
leadership team. Since these are the “what and why” of the project, teams feel it is
easier to work on them at the same time. If the sponsor delivers a first draft of these
sections, the Project Manager and core team carefully assess it together to ensure
they both understand and agree.
4.5.2. B a c k g r o u n d Instructions
The Project Manager and team decide whether this section is needed for their project
as they create the scope overview and business case. If the scope overview and
business case seem detailed enough for all important stakeholder, the background
section may not be required.
4.5.3. M i l e s t o n e Schedule with Acceptance Criteria Instructions

This section of the charter can be formed by focusing on why you are doing a project
before going into the details. “A method of depicting all of this information so it is
simple to understand is to set up a four-column table with Milestone, completion Date,
Stakeholder Judge, and Acceptance Criteria heading the columns.
SIX STEPS IN CONSTRUCTING A MILESTONE SCHEDULE - The most effective

way to construct the milestone schedule with acceptance criteria is to use the six-step
procedure described below.

Step 1 - The first task is to briefly describe the current situation that requires the
project and place this description in the first row of the milestone column. The current
state may be a summary of the business case. In exhibit 4.6, the problem, was paper
records that were not centralized.
Step 2 - The next task is to describe the project at its successful completion in three or
four words. This description must go into the last row of the milestone column. It is
hard for many core teams to filter this into three or four words, but keeping it brief
enables the team to understand what is really most important. In Exhibit 4.6, the
desire is to have records centralized and accessible in electronic form, and the final
goal is for continuous information flow throughout the organisation.
Step 3 - Next, define the acceptance criteria for the final project deliverables (in the
future). On what basis will stakeholders evaluate the deliverables? Stakeholders will
usually demand a demonstration of project results. In Exhibit 4.6, the sponsor wants
a representative from each division to demonstrate how they can enter and recover
relevant information.
Step 4 - Now, revert back to the milestone column. Express the vital points where
quality needs to be confirmed. Begin by stating the three most significant
intermediate points, and add more if required.
The project in Exhibit 4.6 has four milestones. “On agile project the first iteration is
planned as a milestone with acceptance criteria just as described above. However,
subsequent milestones and acceptance criteria are determined on a just-in-
time (JIT basis)” (Kloppenborg, 2015:94).
Step 5 - Now for each milestone, identify the primary stakeholders and how
they will evaluate the final deliverable. Since these are intermediate deliverables, it is
not easy to determine desired performance.
One method is to ask the person who will evaluate the project’s end results, to judge
the intermediate deliverables also to ensure you are on the right path. Several
stakeholders will evaluate various milestones in the project in Exhibit 4.6.

Step 6 - Finally, establish the expected accomplishment dates for each

milestone. An example of a template for the milestone schedule and acceptance
criteria for a Six Sigma project is shown in exhibit 4.7.
4.5.4. Risks, Assumptions, and Constraints Instructions

Firstly, the Project Manager and team should determine all the risks that could affect
the project schedule, budget, usefulness of project deliverables, or approval of any
project stakeholder.
In this way, constraints that limit choices and unconfirmed assumptions can be
recognised. Assumptions are particularly significant when a cross-functional team is
executing the project as some team members may be proficient in their own divisions.
Going forward, all risks, assumptions, and constraints are referred to as risks.
Risks can be evaluated on likelihood of occurring and impact if realized. Both

dimensions can be revealed with a basic continuum of low to high using a flip chart or
marker board.
Once all risks are evaluated, the team must determine which of the risks are so
major that they require an official response plan with someone assigned responsibility.
The minor risks are not formally considered further in the charter, but may gain
attention in the planning of its contingency plan.

4.5.5. Resources Needed Instructions

Armed with the milestone schedule, the Project Manager and team may be prepared
to make simple estimates of the project budget and other resources needs.
It is essential to define how the estimates were formed and the level of confidence
the team has in them. Also, a limit of spending authority for the Project Manager is
usually established. An example of resources needed for a project is presented in
Exhibit 4.10.

4.5.6. Stakeholder List Instructions

Stakeholders are all the people that are internal or external to the organisation who
have an interest in the project. Stakeholders may be for or against the project.
Stakeholders have an interest on the project process and/or results. The Project
Manager and team begin to create a list by first recognizing and prioritizing all
stakeholders. Thereafter they find out what each stakeholder’s interest is in the
project. See Exhibit 4.11 for a stakeholder list for a clinical research project.
(Source: Kloppenborg, 2015: 97)
4.5.7. Team Operating Principles Instructions

The operating principles that will be used is decided upon by the Project Manager
and team. Operating principles establish the following:
How meetings will be conducted.

How decisions will be made.
How the work will get done.
How to treat each other with respect.
4.5.8. L e s s o n s Learned Instructions

As previously mentioned, projects are unique. However, certain commonalities
exist in how projects can be planned and managed. A Project Manager and team
must identify what has worked well and poorly on previous projects. This must be
done prior to commencing on a new project.

A smart sponsor will refuse to sign a project charter authorizing work until the
Project Manager and team demonstrate that they have learned lessons from previous
projects. An easy method to achieve this is to have each project report lessons
learned at key reviews and at project completion and to have an easily accessible
lessons learned knowledge base. In this way, the Project Manager and team can look
at the lessons until they find some that can aid them on their project. These lessons
are then incorporated in the charter. “The more specific the lessons, the more likely
the team will find them useful” (Kloppenborg, 2015:98).
4.5.9. S i g n a t u r e s and Commitment Instructions

The project sponsor, manager, and team members sign the charter to publicly
accept their commitment. Other major stakeholders may also sign.
An example of a charter signature section is presented in Exhibit 4.14.
4.6. RATIFYING THE PROJECT CHARTER

The Project Manager and team officially present the project charter to the
sponsor for authorization. The sponsor (and leadership team members if present)
ideally are supportive, but are also prepared to ask questions concerning any section
of the charter. These enquiries are for clarification and agreement. After all questions

are adequately answered, the sponsor, Project Manager, and core team all sign the
project charter and are bound by it.
4.7. STARTING A PROJECT USING MICROSOFT PROJECT
A convenient tool to capture and display a variety of important project data is Microsoft
(MS) Project.See Exhibit 4.15 which shows where MS Project is demonstrated in the
prescribed text book. Each process is described in a step-by-step manner using
screen shots from a single integrated project throughout the text.
4.7. SUMMARY
This section concluded that the project charter is a vital document that enables the
project sponsor, Project Manager and core team to reach mutual understanding and
agreement on the project at a high level. The sections of a charter include scope
overview, business case, milestone schedule, acceptance criteria, risks and

signatures. The draft of the business case and scope overview may be written
by the sponsor or leadership team however, the majority of the draft of the charter is
written by the Project Manager and core team. The sponsor together with the
Project Manager and core team go over the charter in detail to ensure understanding
and reach agreement. The charter is the document that completes the initiating
stage of a project and once the charter is complete the project team can attend to
the planning details of the project. (Kloppenborg, 2015:105)
You have come to the end of unit four.

Complete the end of unit activities to expand your knowledge on this section.
ACTIVITIES:
ACTIVITY: 4.1
What are the four purposes of a project charter?
ACTIVITY: 4.2
What is scope creep?
ACTIVITY: 4.3
What are the three reasons why Project Managers and teams look at risks?
ACTIVITY: 4.4
What is a charter?
ACTIVITY: 4.5
What are some of the benefits that occur once everyone has a common
understanding of the project goals?

CHAPTER 5
STAKEHOLDER ANALYSIS AND COMMUNICATION
PLANNING
5. INTRODUCTION
This unit deals with quantifying, describing, and prioritizing stakeholders. It also
states how to build project relationships and discusses relationship importance to
communications. The segments of a project communications plan are discussed. This
unit then focuses on planning, conducting and improving project meetings. Lastly, the
communication challenges faced by virtual and global teams are highlighted. The
unit ends with a summary and end of unit activities. The learning outcomes are given
below.
Learning Outcomes
Enumerate, describe, and prioritize each set of stakeholders for a project.

Explain how to build project relationships and discuss the importance in
communications.
Enumerate each section of a project communications plan and describe the
role each plays.
Develop a project communications management plan for a real project.
Plan, conduct, and improve project meetings.
Describe communication challenges of virtual and global project teams.
5.1 DEVELOP THE PROJECT MANAGEMENT PLAN

Since each project is unique, a project team must plan precisely for each project.
While the specifics of each plan will vary, projects have many common aspects that
must be planned. For example, all projects are embarked on to accomplish a goal.
This means that a group of stakeholders need the project outcomes and that the
outcomes have work and quality concerns.

All projects are subject to cost and scheduling limitations and are achieved with and
through people and other resources. The planning for people contains both decisions
of who will be part of the project and how they will cultivate an effective team and
stakeholder relationships. Project planning must incorporate the 10 knowledge
segments outlined in the PMBOK Guide into a single Project Management plan.
Develop Project Management plan is “the process of defining, preparing, and
coordination all subsidiary plans and integrating them into a comprehensive Project
Management plan” (Kloppenborg, 2015:116). Project planning is iterative because
planning starts at a high level and then the planning is repeated more thoroughly as
more information surfaces.
Project planning is collaborative since there are several stakeholders to be satisfied

and a team of workers with many abilities and ideas who must work with each other.
For simplicity, planning has been separated into units in this guideline. A team
cannot accomplish all the planning in an ordered way. Choices made in planning one
task usually entails adjustments on another task. For example, if the projected
schedule is too slow, a client may approve the use of overtime pay, which will
probably raise the budget. See Exhibit 5.1

Good project planning sets the base for effective project execution, monitoring,
control, and closeout.
Establishing effective team and stakeholder relationships leads to respect and trust,
which, in turn, leads to project achievement. See how this is illustrated in Exhibit
5.2. Thus, during project planning, specifics of the numerous functions must be
planned, and the foundation needs to be set for effective team and stakeholder
relationships. Projects differ in size and intricacy. When a project team is deciding how
thorough the planning needs to be, they must remember that the purpose of the Project
Management plan is to become a base for executing, monitoring, controlling, and
closing all project work. It is sensible to spend R100 in planning to save R1000
in execution, but not the other way around. A good way to start planning is to
establish the framework of a Project Management plan. This document describes
how the project will be executed, monitored, and controlled.
Plan stakeholder management is described as “the process of developing

appropriate management strategies to effectively engage stakeholder throughout the
project life cycle, based on the analysis of their needs, interest, and potential impact on
project success” (Kloppenborg, 2015:118). Plan communications management is
“the process of developing and appropriate approach and plan for project
communications based on stakeholder’ information needs and requirements and
available organisational assets” (Kloppenborg, 2015:118).

A communication management plan is a component of the project management

plan is then developed. It describes how, when, and by whom project information will
be administered and distributed.
Following this the project team will establish the scope and when this is determined
they plan for other aspects of the project as listed below:
Schedule
Budget
Resources needs
Risks
Quality.
Some of these issues influence others, so the team sets the Project Management plan
to safeguard that all of these minor plans work successfully together.
It is important to bear in mind that the Project Management plan can only be altered
and reviewed by formally accepted changes. Changes are often identified when
the project is in progress and require re-planning all through the project life cycle.
Agile and other forms of adaptive planning will not create as much preliminary
planning, but will have much of the planning transpire on a just-in-time (JIT) basis.
5.2 IDENTIFY STAKEHOLDERS
A project must gratify its users to be effective. Project Managers must understand their
stakeholders, develop relationships with them, and then create a
communications management plan for handling them. There are four categories of
uses as follows;
1. Multiple users whereupon each may have a different want and need.
2. Users who do not fully understand what they want. They do not know what
alternatives may be available.
3. The customer who pays for the project is not the actual person that will
necessarily use the project deliverable. The user/s could be someone else and
therefore the customer who pays will not have a full understanding of what is required
by the user.

4. When someone else is paying for the project some user will request more
project outcomes that are expensive or time consuming to deliver.
5.2.1 Find Stakeholders

To recognise who stakeholders are one must understand who will be affected by or
who will utilise the project outcome. Identifying stakeholders is “the process of
identifying the people, groups, or organisations who could impact or be impacted by
a decision, activity, or outcome of the project; and analysing and documenting relevant
information regarding their interests, involvement, interdependencies, influence, and
potential impact on project success” (Kloppenborg,2015:119).
Who are the stakeholders?

Stakeholders can be people that:
Work on project.
Provide people or resources for the project.
Have their routines disrupted by the project.
An alternative way to recognise stakeholders is to find out whether they are internal to
the organisation that is carrying out the project or if they are external to the project
organisation. See Exhibit 5.3 for examples of project stakeholders based on these
categories. Often, there are more kinds of stakeholders that are affected by the
process of carrying out the project than by the project outcome and more external than
internal stakeholders.

Project Managers and project core teams can utilise the examples in Exhibit 5.3 to
discover likely stakeholders. This can be actioned in a brainstorming session.
Another idea is to explicitly recognise stakeholders by name. Examine both financial
and emotional concern of possible stakeholders. The project charter is suitable for
this. Once the stakeholders and their interests have been recorded, they may be
pooled into like groups with the same interest.
5.2.2 Analyse Stakeholders

Stakeholder analysis is “systematically gathering and analysing quantitative and
qualitative information to determine whose interest should be taken into account
throughout the project” (Kloppenborg, 2015:120). Prioritization of stakeholders is
important to stakeholder analysis because it takes a great deal of time. It is imperative
not to overlook any stakeholder, but it is sensible to focus on those who are of most
importance. Stakeholders can be prioritized by the following factors:
1. Authority (power)
2. Concern (interest)
3. Active involvement (interest)
4. Ability affect changes (impact)
5. Need for immediate influence (urgency) or
6. Appropriateness of their involvement (legitimacy).
Each aspect utilised can be rated on a basic scale of 1 to 3, with 3 signifying

maximum importance. In terms of power, a stakeholder who could command the
project shut down or change it in a big way would be a 3.
A stakeholder who could not change the project much would be a 1. The other aspects
can be analysed in the same way. The scores from the aspects are tallied to give a
total prioritization score. See Exhibit 5.4 that shows stakeholder identification and
prioritization.


By determining who the stakeholders are and what each group wants Project
Managers are able to do the following more effectively:
Set clear direction for further project planning, negotiating, and execution.
Prioritize amid competing objectives.
Learn to recognize complex trade-offs and the consequences of each.
Make and facilitate necessary decisions.
Develop a shared sense of risk.
Build a strong relationship with their customers.
Lead associates, customers, and suppliers with an empowering style.
Serve as good stewards of the resources of both the parent and

customer organisations. (Kloppenborg, 2015:120).

The project team should then choose the top 10 to 15 stakeholders for priority in the
rest of their planning. The stakeholders with the highest total scores are usually
considered to be major influencers for the project. The Project Manager and core team
should also plan to occasionally review this prioritized list of stakeholders
because the ranking can change as the project moves forward.
An added concern is that stakeholders generally have opposing interests. Usually,

when a conflict occurs, external paying customers and top management are seen as
major stakeholders. If the project team established the stakeholder identification and
prioritization matrix without their sponsor, now would be an ideal moment to share it
with the sponsor for advice. Odds are that the sponsor will want to make some
alterations before the team proceeds. Sponsors are handy in assisting with the
resolution of conflicting priorities. In developing a communications plan;
preparing project scope; identifying threats; prioritizing among cost,
schedule, scope, and quality objectives and opportunities and determining
quality standards, the project team primarily considers the top
stakeholders when doing all of this.

Teams use classification of stakeholders to develop strategies to take

advantage of stakeholder support or to diminish the effect of their opposition. The
stakeholder register aids in relationship building with each stakeholder
and determines their needs, which is the core of developing project scope. The
stakeholder register is a living document that changes when necessary. A
stakeholder matrix for the alternative breaks
5.3 BUILD RELATIONSHIPS

“Project Managers and teams seek to develop strong working relationships with
important stakeholders. This is an ongoing process throughout the life of the project.
In fact, the Project Manager normally continues to nurture the relationship even after
the project is completed to increase the chances of securing future project work. In
building relationships both within the project core team and with other
stakeholders, Project Managers need to remember that mutual respect and trust
greatly enhance the prospect should be planned and carried out carefully”
“A principle idea in agile is that relationships with stakeholders need to be based upon
collaboration, communication, and trust. Analysing stakeholder information helps the
team understand them better and leads to effective relationship building”
(Kloppenborg,2015:123).
Relationship building activities are most effective when used in the planning process of
project.
Project relationship-building activities are very useful in doing the following:

Sharing of individual motives.
Encouraging open communication.
Jointly establish agendas.
Using shared learning.
Regularly celebration of successes.
Using appropriate decision making and problem solving.
5.3.1 Relationship Building within the Core Team

In order to create productive workplaces it is essential that the core team:
Comprehend what is expected of them.

Have the opportunity to work on tasks they well-matched to perform.

Receive fitting recognition.
Have good co-workers.
Have their views considered.
Have the opportunity to grow and develop.
The sponsor and the Project Manager preferably start by asking one another about
their own expectations from the project. Each may have project goals and individual
motives. The Project Manager then asks each core team member what he/she
personally expects from involvement in the project. These questions aid the Project
Manager in understanding priorities and motives. For example, core team members
may want to participate to increase their skills, or receive a promotion. Understanding,
these motives will enable the Project Manager to handle them.
The Project Manager can boost open communication by:

Keeping members up-to-date - showing that everyone’s input is respected.
Personally sharing feelings.
Respecting privacy.
The Project Manager should ensure that all team members also practice these habits.
Joint establishment of project meeting agendas helps with relationship building
because all team members feel their concerns are dealt with. Team members then
develop a superior sense of belonging in meetings. Regular celebration of small
successes enables project member’s to share the delight of working on a project
which then helps them stay devoted to completing the project.
Another relationship-building activity that must start early and carry on throughout the
project entails proper decision-making and problem solving. The Project Manager and
core team need to comprehend who makes each type of project decision and how
each is made. Group decisions tend to take longer, while others are best made by a
group that encompasses several points of view. See Exhibit 5.7 which gives general
advice that can be useful in determining who should make which type of decisions.

(Source: Kloppenborg, 2015:125).
5.3.2 Relationship Building with All Other Stakeholders

Creating a good relationship early on with all major stakeholders is important
for two reasons. First, it helps build a desire on the stakeholders’ part to give
confident support to the project, or at least desist from disturbing the project.
Second, it functions as the communications basis for the project. The rest of the
project planning and completion are significantly improved by effective
communication channels with vital project stakeholders. Project teams create a
stakeholder management plan which is “a subsidiary plan of the Project
Management plan that defines the processes, procedures, tools, and techniques to
effectively engage stakeholders in project decisions and execution based on the
analysis of their needs, interests, and potential impact” (Kloppenborg, 2015:125).A
major tool utilised in this plan is the stakeholder engagement matrix. Engagement
levels can be categorised as unaware, resistant, neutral, supportive, or leading. Exhibit
5.8 is an example showing both where each stakeholder is currently C and where the
team wants the stakeholder to be (D).


The sponsor, Project Manager, and core team can create strong relationships with
major stakeholders by:
Honouring all promises.

Providing unbiased treatment.
Creating a sense of pride by association.
Helping the stakeholder develop a passion for the project.
Displeased stakeholders are a sign of project failure. Stakeholders are more likely
to take ownership in the project by expressing their needs to the project team and
making timely project decisions. In doing so stakeholders are more likely to feel
their hopes correspond with the project team’s plans. They may partake early and
often when their contribution is meaningful and when they feel that the project is
successful. Project Managers must bear in mind that gaining respect and trust among
all project stakeholders is a goal that must be started early and continued throughout
the project.
5.4 PLAN COMMUNICATIONS MANAGEMENT

The project team should now form the communication management plan. This plan
guides the project communications and needs in a document that adjusts to fluctuating
project needs.

5.4.1 Purposes of a Project Communications Plan

Technical, cost, and schedule constraints occur in every project. These challenges
must be managed well as they can negatively affect a project. Another very common
problem to project success is communication. People that are unfamiliar with each
other are required to work together on projects. Projects may include diverse people
that have their own unique challenges. People from various corporations may end up
collaborating on projects. All projects are different and therefore have diverse sets of
stakeholders. “Communication leads to cooperation, which leads to coordination,
which leads to project harmony and this leads to project success” (Kloppenborg,
2015:126).
5.4.2 Communications Plan Considerations

Several considerations must be kept in mind when creating a communications
plan. A project team can create a practical communications plan, utilise it, and adjust
it as the project advances. Purpose Column - The first column in Exhibit 5.10 requires
a project team to establish the purpose for each communication. One communication
purpose is to plan and manage matters that cannot be dealt with timeously by the
Project Manager. Communications plans ensure that at the end of a project,
significant lessons can be noted to assist future projects.

Structure Column - The second column indicates that if there are prevailing
organisational communication structures, use them. When no specific organisational
model is offered to follow for a certain communication, one may utilise a template,
which is simpler than generating a completely new form of document. Methods
Column - The third column in the exhibit focuses on techniques of communication.
Projects depend on “Push” techniques in which communications are sent or pushed;
“Pull” techniques where communications are posted on paper or in automated form
and potential stakeholders must take the initiative to obtain the communication; and
interactive techniques in which communications flow many directions. A variety of
these methods will be used in a typical project communication plan.
Timing Column - The fourth column is a reminder that a project team must consider
timing concerns when establishing a project communications plan. Communications
are normally sent according to one of three types of timing schedules:
First is the project life cycle; with communications normally required at the end
of each key phase in the project and at the end of each key project deliverable.
The second timing schedule deals with formal organisational structure.
Project progress if regularly stated at frequently scheduled meetings.
The third timing scheme is an as-needed basis. Usually, a stakeholder would
want to know a specific detail about a project and cannot wait until the next
meeting or report. Project teams must keep themselves well-informed so they
can deal with the requests.
5.4.3 Communications Matrix

Project teams usually create a project communications matrix consisting of the
following:
Who does the project need to learn from?
What does the team need to learn from this stakeholder?
Who does the project team need to share with?
What does this stakeholder need to know?
When do they need to know it?
What is the most effective communications method for this stakeholder to
understand?
Who on the project team is responsible for this communication?

Exhibit 5.11 provides an example of a completed project communications matrix.
5.4.4 Knowledge Management

If a company does extensive project work and requires Project Management skills as
an organisational strength then it is important to keep developing knowledge on it. One
method to develop and increase capability is to gather and re-use the knowledge
gained. Knowledge is “a conclusion drawn from information after it is linked to other
information and compared to what is already known” (Kloppenborg, 2015:129). To
boost knowledge and the positive use and re-application of it, organisations form a
lessons learned database. It is important to communicate project success and failures
in order for the database to be useful.
5.5 PROJECT MEETING MANAGEMENT

There are various meetings that are required in planning and conducting projects as
listed below:
Establish project plans.

Conduct the project activities.

Verify progress.
Make decisions.
Accept deliverables.
Close out projects.
Meetings are essential to projects since many important decisions are taken at
meetings and much time is spent in meetings. Agile projects use the “stand-up
meeting” feature. These brief (15 minute or less) meetings are often held at the start
of each day with no coffee or chairs to be comfortable. Each team member states what
he/she achieved the previous day, what they plan to accomplish today, and what
difficulties may challenge them.
THINK POINT
Think about what would happen if regular project meetings were not carried out.
5.5.1 Improving Project Meetings

Project meetings should occur in an efficient and effective manner. The plan-do-
check-act (PDCA) model may be utilised to improve the meeting process.
PDCA Model - The idea behind PDCA is that any process improves over time,
when practiced repeatedly, focusing on re-using and adjusting things that worked
well. Exhibit 5.12 depicts the PDCA model as it is applied to project meetings.

Project Meeting Agenda Template - When applying the PDCA model to improve
project meetings, the first step is planning the project meeting ahead of time. The
Project Manager ensures that the schedule is ready and circulated in advance. If a
project team is meeting often, the agenda may be circulated at the end of each
meeting for the next meeting. That way, everyone knows what will be covered in the
next meeting. The agenda may also be utilised in deciding whether to call a specific
subject matter expert (SME) or other guests to the meeting. See Exhibit 5.13 for a
project meeting agenda template.
Project Meeting Minutes Template - The second part of the PDCA process “do”
means to carry out the meeting and to take minutes as the meeting proceeds. Project
teams swap the minute’s taker role so each member feels equal.
5.5.2 Issues Management

The four primary types of information gathered in a project meeting are:
1. Decisions made.
2. New issues surfaced and old issues resolved.
3. Action items agreed to.
4. An evaluation of the meeting.

Decisions and Issues - First, any decisions taken should be recorded. Second, any
new issues raised or current issues that were fixed should be noted. The issues log
makes sure that important issues are not overlooked.
Action Items - The third form of project information is action items. Each of these is a
task that one or more project members agree to complete by a specific date. These
are noted, and at the end of the meeting, the Project Manager reiterates what each
member agreed to do.
Evaluation - The last item to be noted on the project meeting minutes is an

assessment of both good points that the project team would like to repeat or adapt
and poor points that the project team would like to avoid going forward.
“On agile project this evaluation is called retrospectives” (Kloppenborg, 2015:134).
Finally, the “act” part of the PDCA model is for every team member to complete the
action items they pledged and for the Project Manager to converse with the team
members to ensure nothing is hindering their ability to complete their part of the
project.
Once all the steps of the PDCA model are applied to project meetings the following
occurs:
The meetings improve.
The team members gain satisfaction.
The project makes better progress.
5.6 COMMUNICATIONS NEEDS OF GLOBAL AND VIRTUAL PROJECT TEAMS

As organisations evolve, more projects are embarked on with team members from
various parts of the organisation, from different organisations, and even from different
parts of the world. Therefore, these project teams benefit from a wide pool of
resources.
5.6.1 Virtual Teams

“These benefits, however, come with challenges. Since the team is not all co-located,
the Project Manager relies even more on persuasion to complete work. A virtual team
is a group of people with a shared goal who fulfil their roles with little or no time spent

meeting face to face. When project teams function in a virtual mode, the following
characteristics are present:
Team members are physically dispersed.

Time boundaries are crossed.
Communication technologies are utilised.
Cultural, organisational, age, gender, and functional diversity is present”
5.6.2 Cultural Differences

Cultural patterns vary across the world so project team members must be more
understanding towards how their actions are interpreted. For example, in some
cultures direct eye contact shows you are paying attention, while in other parts of the
world people avoid eye contact in deference to superiority. In those cultures, direct eye
contact might be difficult. When people do not meet physically, they do not have the
chance to see and learn from a person’s body language. Project Managers handling
global and virtual project teams need to be mindful of the greater need for
communications. See Exhibit 5.17 in your prescribed text book on page 135 for
increased challenges for virtual and global project team.
5.6.3 Countries and Project Communication Preferences

It is helpful if the project team members physically meet each other even once. This
can be very costly, but it is worth it since it enables the project team to perform well on
the project.
Usually, the core project team is gathered to develop and approve the project
charter. The core team members then know each other and are motivated to give each
other the benefit of doubt if there is a mistake. By recording decisions, it is easier to
recall what happened and to reveal lessons learned when the project is complete.
See Exhibit 5.18.

5.7 COMMUNICATIONS TECHNOLOGIES

One of the most rapidly changing aspects of Project Management work is
communications technologies.
5.7.1 Current Technology Types

Project team members and stakeholders must to be able to communicate wherever
they are. They need to be able to work inventively together, have access to project
documentation. It is important to bear in mind is that communications technology
should make the project easier- not harder. Select whatever technology will help get
the job done. Communication technologies allow team members to work successfully
from different locations.
5.8 SUMMARY
This unit covered project planning. We have learnt that planning is iterative on
projects in that while there is a logical order to planning, many times information that is
developed while planning one function causes a project team to modify earlier
planning.
Planning is done by identifying and analysing the stakeholders. This unit also
covered relationship building, diversity, culture, communication plan, managing
and improving meetings and communications technology.

You have now come to the end of unit five.

Do the activities at the end of this unit to expand your knowledge on this
section.
ACTIVITIES
ACTIVITY: 5.1
Once a scope is determined, what are some of the other aspects which the project
team need to plan?
ACTIVITY: 5.2
Who are stakeholders and on what basis can they be prioritized?
ACTIVITY: 5.3
What are the four primary types of information which can be captured in a project
meeting?
ACTIVITY: 5.4
What are the characteristics of a virtual team?
ACTIVITY: 5.5
Why is communication important to the success of a project?

CHAPTER 6
SCOPE PLANNING
6. INTRODUCTION
This unit comprises of scope management in how to collect requirements, define
scope processes, create a requirements traceability matrix, project management
statement and change request form. In this unit the student will also learn how to
describe a work breakdown structure (WBS), understand why WBS is important to
project planning and control and be able to compare and contrast various methods of
developing a WBS. The creation of a WBS is included together with work packages
and a numbering system for the code of accounts manually and by using MS
Project. This unit must be read in conjunction with chapter six of the prescribed
text book. This unit then ends with a summary and activities. The learning outcomes
are mentioned below.
Learning Outcomes
Describe the Plan Scope Management, Collect Requirements, and define Scope
Processes.
Create a Requirements Traceability Matrix, Project Scope Statement, and Change
Request Form.
Describe what a Work Breakdown Structure (WBS) is.
Explain why a WBS is vital to project planning and control.
Compare and contrast different methods of developing a WBS.
Create a WBS that includes work packages and a numbering system for the
code of accounts both by hand and by using MS Project.

6.1 PLAN SCOPE MANAGEMENT
Managing scope can be done in various ways from. This can range from traditional
waterfall to agile approaches however scope must be managed to deliver the right
solution in an efficient manner.
In a Traceability Matrix the requirements tie “end to end” that is from the contract
through to the project testing and to customer acceptance. Up front time spent in
requirements management will pay dividends during project testing and customer
acceptance. Without requirements management it would be time consuming and
expensive as unknown requirements are discovered.
All of the requirements are managed under change control. This becomes an
important process, to balance control and flexibility. There must also be a meeting
and agreement with the relevant individuals on changes to the project cost and
schedule parameters. The Project Manager facilitates and analyses the technical,
schedule, and cost impact. Thereafter all parties reach a mutual agreement on how to
move the project forward.
Once all stakeholders have been identified the following planning processes will occur:
Plan Scope Management.
Collect Project Requirements.
Define the Project’s Scope.
Create the Work Breakdown Structure (WBS).
In planning Scope it is wise to also plan for changes although this is not technically
part of scope planning. See Exhibit 6.1 for the flow of scope planning. In this exhibit
you will find the boxes represent the project work processes involved. The documents
shown before and after the boxes represent major inputs that are needed to perform
the processes. This also indicates the major outputs created by the work processes.
The Charter and Stakeholder Registers were covered in chapters 4 and 5 respectively
are documents that are needed inputs for the first two processes.

The first step in Project Management Scope is to have mutual agreement on what a
project will deliver. Very often projects will use a Statement of Work (SOW). A
similar document to a SOW could also be used to outline the high-level scope. The
first Scope Process is Plan Scope Management – which is the process of
creating a Scope Management plan that documents the following:
How the project scope will be defined
How it will be validated
How it will be controlled.
Basically the Project Scope are the features or functions that characterize a
product, service or result. The project team needs to determine the Project Scope in
order to deliver a product, service or result according to the specified features and
functions. The total Scope is formed on the outputs the project team will deliver to its
customers and according to the work the project team needs to perform to create the
projects outputs. This means the project team members determine what they must do
to ensure they have identified and organised all of the project work that will be used as
the basis of all other planning and thereon as the basis for executing and controlling
the project work.
6.2 COLLECT REQUIREMENTS
According to Kloppenborg (2015) Collect Requirements is a process that defines,

documents and manages stakeholder needs and requirements to meet project
objectives.

Step one in Collecting Requirements is to ensure that the project team is

absolutely clear on the project objectives. When the project team has clarity on
the project objectives they can then describe in more depth what they individually
believe the expected project benefits are and/or what problems the project is
attempting to overcome.
This can take only a few minutes on simple projects however, on complex projects, a
Project Manager may choose to use idea generation, grouping, and/or cause-and-
effect techniques to ensure that everyone on the project team clearly understands why
the project is being conducted.
The benefits of understanding broad project objectives are as follows:

It helps in making more detailed decisions later
Project importance is reinforced
Can help in motivating team members and other stakeholders during challenging
times
It is especially useful with multifunctional, virtual, and global project teams
. It is helpful if the project needs to be re-planned at some point.
6.2.1 Gather Stakeholder Input

Step two in Collection Requirements is to gather input from the various project
stakeholders. This is done by listening closely to the customer to fully understand the
customer’s needs and to understand what risks and issues the Project Manager and
the project team may confront during the project. This understanding of customer
needs and wants and risks are helpful to the Project Manager and the project team in
ensuring a successful project outcome. The methods of developing deep
understanding of customer needs can vary extensively from one industry to another.
Once the customer wants and needs are captured and stated in operational
terms, the people performing the project work can use this to plan their work. If the
customer wants blue paint in a specific room of his house (assuming that the house is
the project that is to be completed upon renovation) then the project team involved in
this project needs to know the precise desired shade of blue that is required by the
customer to satisfy the customer wants and needs.

The Project Manager must be able to understand how a project’s success

will be determined from the customer’s perspective. The Project Manager can gain
this understanding and at the same time will begin building a strong relationship
with customers. This is done by directly asking customers to specify clearly what
will satisfy their wants and needs with respect to the particular project.
6.2.2 Information systems

A team may use a session on joint application design (JAD) to extract customer
requirements on an information systems project. Users of this software often state
what their preferences are on how the software should work. Often, communication
takes place from the Project Manager and project team who will send the user their
understanding of the project objectives and deliverables well in advance. This is
done so that the users are better prepared to discuss user needs. “Only one group of
users is normally in this meeting at time, while the Project Manager and the technical
workers are in the session the entire time. Each possible feature of the system
should be discussed. If the system is large and complicated, the amount of time that
can be spent per item may be restricted. Users often wish to talk in depth about
how they want to use the system, and developers often want a detailed discussion
about how they plan to create the feature. To avoid sinking into too much detail, the
Project Manager can ask the users to guide start with only a high-level description of
their reason for the requested feature and then guide the discussion with the following
five questions:
1. What do we not understand about the request?
2. What is the business reason for the request?
3. What is the impact of not providing this feature?
4. What impact will this have on other parts of the project or elsewhere?
On some types of projects, the customers can give their ideas using one of the
techniques above, and the project team can be confident that the customers’ wants
and needs have been captured.

On other projects, once the customers’ viewpoint is captured, it makes sense to

create a model or prototype of some sort so the customers can decide if their wishes
have been fully and accurately captured. Often, this extra step helps the customers to
be more fully vested in the project and creates a strong working relationship that is
helpful when difficulties arise during project execution. It is helpful to list requirements
and their supporting information in a Requirements Traceability Matrix such as that
shown in Exhibit 6.2” (Kloppenborg, 2015:47).
The completed requirements should be as follows:

Traceable back to the business reason for it.
Identified with the stakeholder(s) who need it.
Clear so everyone understands it the same way.
Measurable so its value and completion can be verified.
Prioritized according to value, cost, time risk, or mandate so trade-off decisions
can be made if needed.
6.3 DEFINE SCOPE

Define scope according to Kloppenborg (2015) is the process of developing a
detailed description of the project and product. The Project Scope statement includes
three things that make up the total scope as follows:
1. First, the team needs to determine what they will deliver to the
project stakeholders upon completion of the project. They also need to determine
what they will need to deliver along the way to ensure their success of the project in the
end. These are the deliverables– the product scope.

2. Second, the team must decide on what work to do in order to create

the deliverables. This is the project work statement – the project scope.
3. Third, the team needs to determine the limitations or influence of the
project work. These could be exclusions, constraints, and assumptions.
6.3.1 What are the reasons to Define Scope

Scope definition is an important part of project planning as all other planning is based
upon the project scope.
The Requirements Collected represent the customers’ statement of what the

customer needs and the Defined Scope is the project team’s response. In other
words it asks the customer “if we provide x, y and z, will this solve your problem?”
If there is little or no understanding what the work of a project will include it will
be highly impossible to estimate the following:
What it will cost to complete a project?

How many workers will be required to do the work?
What type of workers will be required?
How long a project will take?
What are the risks involved?
What quality standards will be invoked?
Scope definition is vital in the prevention of scope creep. There are two common
reasons for scope creep occurring:
1. If there is no clarity on how the scope is defined and what is agreed
upon. Adding can be easy to the project without realizing the knock on effects
that more time and money will be required.
2. It can also easily happen that a customer who is excited about a project that
may be going well and will ask an innocent question such as “Can the project
output also do…?” The person heading the project may be flattered and agree
to the customer’s request without understanding the implications. It is
therefore, better to gain customer understanding when the project team is
defining the scope and not while working to implement the project.

6.3.2 How to Define Scope?

Scope definition varies from one project to another. Small projects such as routine
construction project for example may be quite simple to determine project outputs and
the work involved in creating these outputs. On other projects, such as one large
company acquiring another, it becomes very difficult to determine the total amount of
work that is required to accomplish the project deliverable. Although, on some projects
it may be easy and on other projects it may be difficult to determine scope each part of
the process should be completed by project teams.
6.3.3 List of Deliverables and Acceptance Criteria

Project deliverables is the first step in defining scope. Project teams need to:
Understand that there are often multiple deliverables.
List intermediate deliverables – these are the things that need to be developed
for the project to progress. Although, some of these things may have been
listed in the charter, there are other things that may not yet be identified.
To determine the acceptance criteria for each deliverable.
6.3.4 Establish Project Boundaries

Establishing project boundaries is the second step in defining scope. Simply stated,
project team members need to know when to play and when to stop. It has to be
decided what features and work elements should be included and what should be
excluded in the scope. It is not unusual for users to request far more work than a
project can deliver. The project team must decide what is included and what is not. It
can be that at times, the sponsor of a project would make the larger scope decisions
however, the Project Manager and project team still have many detailed scope
decisions that they make.
On any project expectations need to be managed. Any constraints imposed upon

the project must be understood by the project team. Time and lack of resources
can constrain a project. A project team should be careful in promising what can be
delivered because it is easy to make assumptions in the planning stages on dates and
times. Delays can occur from the supplies side in sending the materials timeously for
example and this would delay the project. An increase in the cost of materials will also

have an impact on the project. Assumptions should be stated. False assumptions can
lead to project risk and can also limit the project scope.
6.3.5 How to Create a Scope Description

This is the final step in the process. A sentence or two describes the work that is to
be accomplished in order to create the project deliverables. The purpose of a scope
statement is used to guide the project team during subsequent planning and execution.
A scope statement is necessary prior to development of the WBS for most projects.
See Exhibit 6.3. for an example of scope statement.
6.3.6 How to Define Scope in Agile Projects

“On agile project, the scope definition starts with user stories. The team creates
“personas,” which are fictional people who represent user types and then asks what
they will do with the project deliverables and how will they benefit. These user stories
define scope and functionality. Acceptance tests will also be agreed upon at this time
by describing the manner in which project deliverables will be tested and how they
should prove workable. At the project outset, the overall scope is only defined at a
high level and a backlog of possible work is identified. The customer representative

(sometimes called the owner) prioritizes the scope based upon business need, value,
cost, and risk. The team then commits to the amount of work they can perform in the
first iteration, As the project progresses, the scope is described more specifically
and is documented more closely” (Kloppenborg, 2015:150).
6.4 WORK BREAKDOWN STRUCTURE (WBS)

WBS is a tool that is used on almost all projects. In this section WBS is defined
and its importance is discussed and several formats are shown when constructing on.
The steps required to construct a WBS is also shown.
6.4.1 What is the WBS?

WBS is a tool used by project teams to progressively divide the deliverables of a
project into smaller and smaller pieces. Note that the WBS is not a list of work
activities, or an organisational chart, or even a schedule as there are other tools that
follow that are used for these purposes.
So what is the WBS? It is a framework that is used as a basis for:

Further planning
Execution and control.
Usually on large projects, the WBS is created once the Scope is defined. WBS may
be created concurrently with the Scope statement within small to medium sized
projects. The WBS is normally developed by listing firstly major deliverables and then
progressively smaller ones. This continues until the team is satisfied that every
deliverable has been identified. “Developing the WBS and defining the activities from
an example of how to separate work processes are sometimes performed together
(especially on small or simple projects) and sometimes separately (especially on large
or complex projects)” (Kloppenborg, 2015:151).
6.4.2 Why Use a WBS?

There are many reasons for using a WBS as planning projects requires
discipline and visibility. A WBS can be used as a pictorial representation of project
deliverables which helps project team members to remember they remember all
deliverables that need to be created. Schedule delays and budget overruns will occur
if there is no planned deliverables.

The WBS is the basis for all subsequent planning of such important functions such
as:
The schedule.
Resources cost.
Quality, and risk.
WBS serves as an outline for the integration of these various functions, is easily
modified, therefore, can handle changes that can often happen on projects.
The impact of these changes reflect on:
The schedule.
The budget.
Other control documents.
WBS is helpful in understanding problems that occur during project execution precisely
when and where such problems occurred. WBS is therefore useful in that the
quality of the project deliverable can be managed and all other facets of the
project are kept on schedule while the identified problem is fixed.
WBS is also helpful in project communications because those stakeholders that help
develop the WBS helps them to understand the project. “Microsoft Project software
enables a WBS to be shown in its entirety to people who need to understand the
details, but it also allows project details to be hidden so that others can see the big
picture” (Kloppenborg, 2015:151).
6.4.3 WBS Formats

There are various formats that can be used to construct a WBS with the same purpose.
The first level is the overall project. See Exhibit 6.4 for an example of a WBS for a
house as is represented in the indented outline format.
The second level is intended one tab and depicts major deliverables as depicted
in the example of the house project. This is the house in its framed state to when it
is wired and then to when it is dry walled. A section is also included for the work of
planning and managing the project in the example given.

“A WBS usually has one or more intermediate levels, which generally represent items
that need to be created in order to produce the final deliverables, such as drafts,
prototypes, designs, and so on. These are frequently called interim deliverables. All
levels of the WBS with at least one level below are considered summary levels. The
completion of summary-level elements is based upon completion of all levels
underneath. For example, in Exhibit 6.4, the house would not be framed until the
framing contractor, wood, and assembled frame interim deliverables were complete.
Exhibit 6.4 used the indented outline format for WBS method, but other methods are
sometimes used. One other method is the hierarchical or “org chart” (short for
organisational chart, which it resembles) method. A third method is called free format
because the facilitator is free to draw it in any manner. The same house project
shown in Exhibit 6.4 in indented outline format is shown in Exhibit 6.5 in org chart
format and in Exhibit 6.6 in free format” (Source: Kloppenborg, 2015:152-153)


“Both of these methods allow a team to use a marker board or flip chart and have
plenty of room to add additional elements as people think of them. The WBS method
using indented outlines can easily be imported into MS Project. Teams using the org
chart or free format methods to develop their WBS generally translate it into the
indented outline format for input into software” (Kloppenborg, 2015:152).
6.4.4 Work Packages

There are three levels in the house example shown above and these are as follows:
1. The first level, or project title level.
2. One intermediate level, or summary level.

3. The lowest level, or work package level.
An element at the lowest level in a WBS, is called a work package which is the basis
for all subsequent planning and control activities.
This work package is work that is defined at the lowest level of the WBS and
cost and duration can be estimated and managed. See Exhibit 6.7 for a WBS in org
chart format with work packages in solid boxes.

You will find that in Exhibit 6.7, work packages occur at levels 3, 4 and 5 (smaller
and smaller pieces of work). The work package is the point from which:
Work activities are defined.
The schedule is formed.
Resources are assigned.
Many of the control features are developed.
Work packages need to be detailed enough to facilitate further planning and

control – being too detailed increases the burden of tracking details.

The Project Manager must be confident that the work to create the deliverable can
be assigned to one person who can estimate the schedule and cost. This person
must also be held responsible for completion of the work.
By understanding the work a single deliverable can be produced and there is

clarity on how the deliverable will be judged for its quality and its completeness.
If the person assigned to the task has proven to be reliable in the past then there is no
need for the level to be too detailed. However, if there is poor understanding of the
deliverable and how it will be judged as well as if the assigned worker has yet to prove
his/her reliability then it will make sense to have a more detailed level. Work packages
and other components on a WBS are briefly so that it will be easy to
understand this. Detailed deliverable, activity, and scheduling information about each
component in the WBS can be looked up in a WBS dictionary. See Exhibit 6.8 for an
example of a WBS dictionary.

6.4.5 How to Construct a WBS

“When a project team needs to construct a WBS, it needs to include in its planning
team a subject matter expert (SME) who understands how each portion of the work will
be accomplished. Teams approach this in two ways. Some teams include only the
core team members and plan the WBS as far as they can. Other teams invite the
SMEs to the WBS planning meeting right from the start and utilize their input right
away. The choice of how to include SMEs often is determined by the size and
complexity of the project and by the cultural norms of the company.
The planning team uses a top-down approach in creating the WBS. This is easy to
start when the type of project is familiar and at least some members of the planning
team are likely to understand the general flow of work. If the project is similar to others
performed, either a template or the WBS from a previous project can be used as a
starting point, with the team then asking what else this project needs and what items
from the template of previous project can be skipped. Templates and previous
examples can save teams a great deal of time, but they must be used with caution
because each project is different. Sometimes, however a project is so different from
previous work that the team finds it useful to jump-start the WBS construction by
brainstorming a list of project deliverables just to understand the overall structure
of the project. However, once the overall structure is understood, the team proceeds
with the typical top-down approach for the remainder of the WBS construction:
IDENTIFY MAJOR DELIVERABLES - Project teams review the project planning

scope so that they can define the project product. In order to state the project
deliverables, team members review the project charter, requirements matrix, and
scope statement. Most projects have additional deliverables dealing with
documentation and customer enablement. This is unlike a primary project of
building a house for example. Additional deliverables could include training, service, or
other means that can help the customer use the project’s products effectively.
DECOMPOSE DELIVERABLES - When the major deliverables have been defined

these are then broken up into smaller deliverable or components. A top-down
approach can be used by the project team to find out what the components of each
major deliverable. As an alternative measure the project team may use a bottom-up

approach to find out this information. Read up on this section on page: 156 of the
prescribed textbook.
CONTINUE UNTIL DELIVERABLES ARE THE RIGHT SIZE - The WBS has been
formed and as such it can be reviewed for completeness.
A decision can be taken on whether to the deliverables at the lowest level need to be
divided again to be at the proper size. This is done for further planning and control.
REVIEW - At this stage several things should be considered to ensure that the WBS is
structured properly.
“One consideration with WBS construction is the parent-child concept. The higher
level is considered the parent and the lower-level elements are considered children.
For example, in Exhibits 6.4 through to 6.6, “Framed House” is a parent to the children
components are complete.
THINK POINT
Why do you think that it is easier to understand a WBS if it has fewer

levels?
The team asks if, once these elements are complete, the framing is complete. In an
effort to simplify the WBS, where only one child element for a parent exists, you would
not break it down. In fact, a good rule of thumb is to have somewhere between
three and nine child elements for each parent. The fewer levels a WBS has, the
easier it is to understand. To avoid confusion, each component in the WBS needs to
have a unique name. Therefore, two similar components may be “draft report” and
“final report,” instead of merely calling each “report.” The team also assigns a unique
number to each component. In one common numbering system the number for a child
item starts with the number assigned to its parent and adds a digit. Different
organisations sometimes develop their own unique variations of project planning and
control techniques.

6.5 ESTABLISH CHANGE CONTROL

Formal change and control procedures are used to change (and is also used for
comparison) a baseline which is the approved version of a work product. The Scope
statement and WBS is looked at by the project team at to ensure completeness and
the team seeks to validate the scope by consultation with the sponsor, customers,
and/or other stakeholders.
The project team can simultaneously be planning other aspects of the project. These
aspects are: schedule, resources, budget, risks, and quality. The scope statement
and the entire project plan is baselined only after all of these plans are completed and
when any impacts to scope have been accounted for. Most projects are:
Planned and conducted in an atmosphere of uncertainty.
Planned making assumptions based upon the best information available.
There are things that can change during the course of a project which is why the
project teams deal with change by establishing and using a change control system.
In this system the approved set of procedures describes how modifications to the
project deliverables and documentation will be managed and controlled.
Uncontrolled change is known as scope creep. Scope creep on a project can be
severe and affect a project that is already well-started negatively. Documenting
changes is a method that is a critical portion of a change control system.
6.6 USING MS PROJECT FOR WORK BREAKDOWN STRUCTURES (WBS)

Microsoft Project is a tool that is typically used as a scheduling tool making it easier
to track and communicate the status of each deliverable according to the plan that is
on the WBS. “The WBS is a building block for the remaining detailed project planning
tools. This is the place where the value of software to automate detailed work
becomes apparent. Our coverage of MS Project in this chapter describes how to set
up a WBS in MS Project: (Kloppenborg, 2015:160).
6.6.1 Setting up the WBS

There are five steps in setting up the WBS as follows:
1. Understand WBS definitions and displays.
2. Enter summaries.

3. Create the outline for your WBS.

4. Insert row number column.
5. Hid (or show) the desired amount of detail.
6.7 SUMMARY
Once a project is formally approved by a sponsor or customer ratifying its
charter, the detailed planning then takes place. The first steps of the project planning
are to identify stakeholders, plan communications and determine what will be created
from the project. This is done by the project team who starts to find out from
customers on what end of project deliverables they seek. Based on the customers
response, it can be determined what interim deliverables need to be created and the
work that needs to be performed to create all of these deliverables. It is also important
to determine what will not be produced. These boundaries of what will be produced
and what will be excluded, constitute the project’s scope.
Upon defining the scope, the WBS is constructed. A WBS decomposes the project
into smaller and smaller pieces of work until each can be assigned to one person for
planning and control. The WBS serves as basis for determining the project schedule,
the budget, personnel assignments, quality requirements and risks. In the planning of
other functions any items that are identified should be added to the WBS. WBS
can be created manually using the organisational chart for free format methods
and can also be directly typed onto a project scheduling software such as Microsoft
Project. The preference is left to the teams in charge.

You have now come to the end of unit six. Complete the activities at the end of
this unit to expand your knowledge.
ACTIVITIES:
ACTIVITY: 6.1
What is product scope and project scope?
ACTIVITY: 6.2
Why is it important for Project Managers to listen to internal and external customers?
ACTIVITY: 6.3
What are user stories?
ACTIVITY: 6.4
What is the WBS and how is it developed?
ACTIVITY: 6.5
What are the five steps for setting up WBS?

CHAPTER 7
SCHEDULING PROJECTS
7. INTRODUCTION
Unit Seven is on Scheduling Projects and focusses on Project Schedule limitations

and how to deal with these limitations. Potential problems in the accurate estimation of
time and overcoming such problems, use of the activity on AON to develop a
project schedule and how to adjust a project’s sequence logic are included in this unit.
Identification of the critical path is explained by using the two-pass and

enumeration methods. The Gantt chart is discussed on how it can be used to depict a
project schedule both manually and by using MS Project 2013. This unit ends with
a summary and end of unit activities. The learning outcomes are given below.
Learning Outcomes
Describe five ways in which a Project’s Schedule is limited and how to deal
with each limitation.
Describe potential problems in estimating time accurately and how to
overcome these problems.
Use the activity on node (AON) method to develop a project schedule.
Describe how to adjust a project’s sequence logic using leads, lags, and
alternative dependencies.
Identify the critical path using both the two-pass and enumeration methods,
and identify all float.
Depict a project schedule on a Gantt Chart both by hand and using MS Project
2013, showing the critical path and all float.

7.1 PLAN SCHEDULE MANAGEMENT

Planning for time is iterative in plan schedule management. A Project Manager and
the project team will usually develop much of the schedule from information in the
WBS. The communication plan, requirements traceability matrix, and scope statement
are usually complete or in draft form at this stage. Once a project is scheduled the
following can then take place:
Formulation of the budget
Identification of resource needs
Assigning of resources
Identification of risks
Plans are in place to deal with the identified risks
Creation of quality management plan
The above may not be treated as discrete activities in some projects and some of
these activities may be performed together. Activities are the building blocks of a
Project Schedule. What do we mean by this? It means that an activity is a specifically
scheduled piece of work that is performed during the course of a project in
contribution to the entire project.
The following characteristics ensure that activities will be useful as schedule building
blocks:
There must be clear starting and ending points.
Output must be tangible and can be verified.
Scope should be small enough to understand and control without micro-
managing.
Labour costs, other costs, and schedule that can be estimated and controlled.
One person to be held accountable for each activity even if more people do the
work.
Activities should be listed in verb-noun format, such as “prepare budget,” “build

frame,’ “test code,” “transmit information,” “analyse data,” and “develop plan”
because these are still to be done.

There should be a clear differentiation format in activities such as “write draft report”
and “write final report.”
Below are seven work processes of how project time management has been
divided by The Project Management Institute (PME):
1. Plan schedule management

This is the process used to establish policies, procedures, and documentation for
planning, developing, managing, executing, and controlling the project schedule.
2. Define activities
This is the process used to identify the specific action/s that need to be performed in
order to produce the project deliverable.
3. Sequence activities
This is the process to identify and document dependencies among the project
activities.
4. Estimate activity resources

This the process where the type and quantities of material, human resources,
equipment, or supplies required to perform each activity are estimated.
5. Estimate activity durations

This is the process where the number of work periods that are needed are
approximated in order to complete individual activities with the project’s estimated
resources.
6. Develop schedule
This is the process where activity sequences, durations, resources requirements, and
schedule constraints to create the project schedule are analysed.
7. Control schedule
This is the process where the status of the project activities are monitored. The same
will apply to update project progress and manage changes to the schedule baseline.
This is done to achieve the plan.

7.2 PURPOSES OF A PROJECT SCHEDULE
What is the purpose of Project Schedule? Some projects are undertaken to

accomplish important business purposes and business people want to be able to use
the project results as soon as possible. Therefore, by having a complete and workable
schedule the following questions can be answered:
When will the project be completed?
What is the earliest date a particular activity can start and end?
That activity mush begin prior to so that other activities can take place?
What would be the case of if a delivery of materials were a week late?
Can a key worker take a week of vacation in the first week of March for
example?
If one worker is assigned to do two activities, which activity should be done first?
How many hours are required from each worker in the next week or month?
Which worker or other resource is a bottleneck that is limiting the speed and pace
of our project?
What will the impact be if the client wants to add another module?
If more money for example an extra $10,000 is put into the project will the
project be completed much faster?
Are all of the activities completed as they should be by this stage of the project?
7.3 HISTORICAL DEVELOPMENT OF PROJECT SCHEDULES

Projects have been performed throughout history however, many early projects
such as cathedrals in Europe took decades or even longer to be completed.
Competition was the driving force for more rapid completion of projects. Systematic
methods were designed developed for scheduling projects.
In the 1950s, two project scheduling methods were developed and are known as:

Program evaluation and review technique (PERT)

and critical path method (CPM)
CPM is a method that is used to estimate the minimum project duration. It determines
the amount of scheduling flexibility on the logical network paths within the schedule
model. CPM and PERT were founded on the concepts that are still in place today.
These identify activities, determines their logical order, and estimates the duration
for each activity. The development of networks represents the activities and the
schedule calculations. Each of the techniques in CPM and PERT also boasted a
capability the other did not possess.
Read pages: 173-174 in the prescribed text book for an in-depth understanding of this
section.
7.4 HOW PROJECT SCHEDULES ARE LIMITED AND CREATED

The below listed five factors enable one to understand project limitations on project
schedules and the construction of these schedules.
These factors are:

1. Logical order - in which activities need to be completed
2. Activity duration - how long each individual activity will take
3. Resource availability - how many key resources are available at specific points
in the project?
4. Imposed dates – There can be a delay in beginning a project due to
imposed dates.
5. Cash flow – A project can only begin once money is approved. Project
progress can be slowed until enough revenue arrives to cover expenses.
Consider the first factor – once activity may have to be done first for example in
building a new office block, the foundation has to be prepared before concrete can
poured to complete the foundation stage.
Activity duration must be estimated to have an idea how long the activity will take.
Use the example of preparing the foundation as given above, how long digging up the

earth take before the concrete is poured. Remember if there was no estimation on
this activity, there will be no guide on when to order the concrete.
Resources are vital to the success of any project. These can be capital, workers,
equipment and so on. How many workers will be required to do specific activities or
how much will it cost? What equipment will be required to perform a specific activity?
If there is no planning on resources how can there be an estimation?
Cash flow is also vital to any project. Delays will occur to a project if monies are
not approved and released to the Project Manager. No work can take place without
any money. These five factors limit project schedule therefore a realistic schedule has
to be created.
7.4.1 A Common Method to Develop a Schedule

The following can be done as a common method to develop a schedule:
Firstly identify all of the activities
Then to determine the logical order by creating a network diagram.
Then assign resources to each activity
Give an estimate of the time required for each activity
Make an adjustment of some kind in the absence of an assigned resource

that is not available when the activity is scheduled
Compute all of this information onto the schedule
Compare the emerging schedule with any imposed dates and cash flow
estimates
Ensure there are no inconsistencies as these can demands on the team and
create risk factors.
When all of these have been planned, the final schedule can be approved.
More often than not there is great pressure to complete a project as quickly as
possible. It may be that the sponsor or customer tries to dictate a schedule prior to
anyone having knowledge whether the schedule will be feasible or not. It is wise for the

Project Manager to first understand what makes sense in terms of a schedule and
to understand his/her own position is and then consider if he/she can accept the
sponsor’s suggestions or to discuss with the sponsor why such a suggestion may be
impractical. The Project Manager has the ethical responsibility to determine a
schedule and to ensure that it will be possible to achieve project deliverables. The
Project Manager must be able to persuade the relevant stakeholders that the schedule
makes sense. The Project Manager has the task to ensure that the project is delivered
according to the agreed-upon schedule.
7.5 DEFINE ACTIVITIES
In developing a project schedule the first step is to define all the work activities.
On a WBS the last row represents the work packages which indicates the
lowest-level deliverables. The next step is to determine the work activities that are
required so that the project deliverables are can be created. See Exhibit 7.2 below on a
WBS that shows deliverables identified by representation of numbers: 1 through to 9.
See Exhibit 7.3 which reflects the same project with the activities that are required to
create the listed deliverables. Note that the first section of the WBS is project
management and that each row in both Exhibits are assigned a unique number.
Each number of each activity indicates the deliverable it helps to create. For
example, see activity 4.2, which is to contact local bands now this is needed for
deliverable 3 which is entertainment. Can you see the link?


Teams should be careful not to omit activities as the activities are defined. It is always
a good idea to request a project team member to play devil’s advocate so that the
team is challenged to identify additional activities. The team may think of all of the
activities that have to be identified; however, when the next process is performed
which is activity sequencing, it may become obvious at this point that some activities
have been forgotten! However, another activity can always be added later on.
Remember the schedule will not be approved until all of the related planning is in
place.
It is better to discover a missing activity in the later stages of planning than after the
schedule is approved.
Adding Activities to the Final Approved Schedule - By adding activities after the
final approval of schedule will result in added time and money to the project. The
budget will be affected because more money will be required to be spent on the newly
added activities. The planned time to do specific activities will be affected as new
activities will also require time to complete these activities. More time and money
can cause the project to fall behind schedule.
Referring and Using Past Projects Similar to Current Project - Past project
that are similar to a current project can be looked at for defining activities and for other
planning that follows in the current project.
The project team can refer to the organisations past project templates or checklists for
certain types of projects (provided these have been kept as records) and use these as
a starting point towards defining activities for a new similar type project. However,
teams must ask themselves how the current project differs from a previous one. It is
not unusual for a new project to have some unique activities that require to be included
into it.
Project Milestones - The project milestones which is an important point in a project
schedule must also be listed in addition to the activity list. The project milestones
are used as a checkpoint by the project sponsor and manager.
Often a few major milestones are identified in the project charter and more commonly
more milestones are identified during project schedule planning.

The following are included in common milestones:

Completion of a major deliverable
Completion of a critical activity
Time – needed just before a large amount of money is required to be
committed to the project.
A project team may decide to place a milestone at a merging point in the project
schedule where multiple activities must be completed before progress can continue.
THINK POINT
How does management determine the progress of the project that it is

going the way that they want it to?
Management can use a common denominator in each of these decisions to identify a

few key points in the life of a project to help them determine whether or not the project
is progressing in the way they want.

7.6 SEQUENCE ACTIVITIES
After activities have been identified the logical order is then determined in how
these activities can be accomplished. A commonly used method for determining this
sequence is to place each defined activity on a Post-it Note and then display each of
these notes on a large work space. This workspace can be a white board, several flip
chart sheets on a wall and so on.
This is how this technique should work:

1. Those activities to be accomplished early in the project should be placed on
the left portion of the work surface.

2. The activities to be accomplished midway in the project should be placed near to

the middle of the work surface.
3. The activities expected to be last should be placed on the right of the work
surface.
Once the above three steps are complete, one person can serve as a facilitator. This
facilitator can ask the question on which activity or activities can be started
immediately without such activities depending on other activities.
As one or more of these initial activities are identified, the facilitator can ask which
activity or activities can be started immediately. The initial activity is known as a
predecessor activity. This is an activity that logically comes before a dependent
activity in a schedule.
The activity that follows the initial activity is known as a successor activity. The
successor activity is a dependent activity that logically comes after another activity in a
schedule. An arrow is used or drawn by the facilitator who places the successor
activity after its predecessor activity to show the relationship. The project team
continues with this analysis up until the placing of all activities on the work surface is
completed with the arrows that are joined to show the predecessor-successor
relationships. At this point the team should mentally go through the network to ensure
that there are no “dead-ends” that are present at the point where the chain of arrows
from the project start to end is broken. See Exhibits 7.5 and 7.6 which illustrates
sequencing activities with the simple example of upgrading a product. The activities
are identified in Exhibit 7.5 and their sequence is shown in Exhibit 7.6. The first
activity is to determine the product features. As soon as that is done, two other
activities can be performed.

“This product upgrade example illustrates the basic logic of showing predecessor-
successor dependency relationships. Dependencies can be either mandatory or
discretionary. A mandatory dependency is “a relationship that is contractually
required or inherent in the nature of work.” A discretionary is “a relationship that is

established based on knowledge of best practices… where a specific sequence is

desired.’ A mandatory example is “the hole must be dug before concrete can be
poured into it” and a discretionary example is “past experience tells us it is better to
delay designing product graphics until the marketing plan is complete.’ The team
needs to include all of the mandatory dependencies and use its judgement on which
discretionary dependencies to include. Most teams include no more dependencies
than necessary since more dependencies give the Project Manager fewer
choices as the project progresses” (Kloppenborg, 2015:179).
7.6.1 Leads and Lags

See Exhibit 7.6 which reflects the most common type of logical dependency from
finish-to start (FS). This is “a logical relationship whereby a successor activity cannot
begin unless the predecessor activity is completed. In the example, that the marketing
plan has to be completely designed, before the graphics design can begin. It is
possible however, that the graphics design could begin five work days prior to the
completion of the marketing campaign design. This process could be modelled as a
lead. “With this lead of five work days, the arrow connecting design marketing
campaign and design graphics would still represent a finish-to-start relationship,
only with a five-day overlap during which time people could work on both activities.
Leads are helpful if a project needs to be completed quickly since they show how a
successor activity can be overlapped with its predecessor instead of waiting until the
predecessor is completely finished” (Kloppenborg, 2015:179).
7.6.2 Alternative Dependencies

Other types of relationships exist besides finish-to start which includes the following:
Finish-to finish (FF)

As explained above this is a logical relationship whereby a successor activity cannot
be completed unless the predecessor activity is completed.
Start-to start (SS)

In this logical relationship a successor activity can only begin when the
predecessor activity has already begun

Start-to finish (SF)

In this logical relationship a successor activity cannot finish until a predecessor activity
has begun. This is the least used or favoured relationship.
7.7 ESTIMATE ACTIVITY DURATION
Estimating activity resources and estimating activity durations can take place once the
activities have been defined and sequenced.
Duration is the total number of work periods (excluding holidays or other non-work
periods) that are required to complete a schedule activity. This is usually expressed
as workdays or workweeks.
It makes sense to identify the correct people with the right knowledge that will work on
each activity as soon as possible as they will know how to actually do the work and
how long each activity will take. It must be noted that the length of time taken to
perform an activity often depends on the person that will do that specific piece of work.
Each activity must be evaluated independently so that an estimation can be made on

how long each activity will take to be completed.
When estimating, assumptions and constraints this should be documented so that

any changes can be managed as this would affect the initial estimate.
In making the first estimate of exact activity an assumption is made on a normal

level of labor, equipment and work week.
In the case of overtime that is planned at the very beginning of the work, there will not
be much flexibility should the schedule needs to be accelerated.
Key points to note:

The Project Manager can identify what level of skill will be required for each
activity that is required to create the output.

Predetermined completion date can be disregarded at this point and if negotiate

with a customer or supplier. The Project Manager must understand what is
reasonable under normal circumstances before he/she enters any negotiations.
Use a past project as a guide for the current project (which is similar) to
determine the actual time it took to perform the activities on that project and not the
time that was initially estimated.
See Exhibit 7.7 for a continuation of the product upgrade example with estimated times
applicable to individual activities. The times in this example are given in work days.
Time estimates should be kept in the same unit of measure bit hours, days; weeks or
another measure. See Exhibit 7.8 which includes suggestions for creating realistic
time estimates.

7.7.1 Problems and Remedies in Estimating Duration

Many factors can have an impact on the accuracy of activity duration estimates. See
Exhibit 7.9 for a list of potential problems and remedies for these problems. These
problems have also been discussed in specific units of this course guideline and in
specific chapters in your prescribed text book. These techniques recommended are
not mutually exclusive as there are many organisations that use several of these;
however, few organisations may use all of these. Business students should be aware
of these techniques and their potential benefits as companies do use some of them.
The mechanics of how to use some of these techniques are customised by many
companies.
7.7.2 Learning Curves

Learning curves become simple when there is repetition of a similar activity. In other
words the more times a person does the same activity the better and faster he/she
becomes at it. This concept is sometimes applied to activity duration estimating. A
project planner can predict the time it will take to perform an activity based on

projects where certain activities are performed repeatedly. The factors given below
contribute to the rate of improvement:
How much the culture of the organisation stresses continual improvement
How much skill is involved in the activity
How complex that activity is
How much of the activity is dependent on the worker versus dictated by the pace
of a machine
See the learning curve tables shown Exhibit 7.10 for the time estimates for each time
the activity is performed. The rate of learning is very important because more rapid
learning will lead to much faster performance times.
“On agile projects, duration estimates improve as early iterations are completed.
Armed with more specific knowledge of how long certain activities take later iterations
can be estimate more accurately. However, since the estimate are for a specific
duration of generally two-or four-week iterations, the estimate is for velocity ‘a measure
of a team’s productivity rate and which deliverables are produced, validated, and
accepted within a predetermined interval.” This means the Project Manager estimates
how much can get done in the next iteration” (Kloppenborg, 2015:184).
7.8 DEVELOP PROJECT SCHEDULES

To develop the Project Schedules all of the scheduling processes discussed up to this
point must first be completed. This also applies if you use Microsoft Project or another

scheduling tool. The scheduling processes discussed up to this point are that
you have now defined, sequenced, and estimated the duration for all the schedule
activities and it is time to use all of this information in developing a project schedule.
Let’s have a look at the tasks involved in developing the Project Schedule! Major task
one – is to identify the critical path. The question to ask here is “which is the sequence
of activities that represents the longest path through the project, which will determine
the shortest possible duration?” The critical path determines the earliest possible
end date of the project by considering longest sequence of activities. Remember
that any time changes to an activity on the critical path will affect the end of the entire
project. An increase in the amount of work for an activity on the critical path will affect
the whole project in that the end date will take longer. However, if the activity on the
critical path is performed faster than planned then of course the entire project will be
completed earlier. “The critical path gets its name not because it is the most critical in
terms of cost, technical risk, or any other factor, but because it is most critical time, the
critical path gets a great deal of attention. The two methods for determining the critical
path are the two-pass and enumeration methods. Each uses the same activity
identification, duration estimate, and activity sequencing data but processes the data
in a different manner. While both determine the critical path, each also determines
other useful information” (Kloppenborg 2015:184).
7.8.1 Two-Pass Method

“The two-pass method is used to determine the amount of slack each activity
has. The first pass is called the forward pass. The forward pass is ‘a critical path
method technique for calculating the early start and early finish dates by working
forward through the schedule model from the project start.” On the forward pass, the
project team starts at the beginning of the project and asks how soon each activity can
begin and end. If the project is being scheduled with software, actual calendar dates
are used. Often, when calculating the schedule by hand, a team starts at date zero.
In other words, the first activity can begin after zero days. To envision this, consider
Exhibit7.11, where all of the previously determined information has been displayed.


A legend is shown in the lower right corner of Exhibit 7.11. This explains each bit
information that is displayed for each activity. For example, the first activity name
is “Determine new product features.” The estimated duration for this activity is five
days. This activity is coded with the letter A. The four corners of each block display
four important times for each activity:
Early start date (ES) – this is the earliest possible point in time on which
uncompleted portions of a schedule activity can begin. This is based upon the
schedule network logic, the data date, and any schedule constraints.
Early finish date (EF) - This is the earliest point in time on which uncompleted
sections of a schedule activity can finish. This is based upon the schedule network
logic, the data date, and any schedule constraints.
Late start date (LS) – This is the latest possible point in time in which
uncompleted sections of a schedule activity can begin. This is based upon the
schedule network logic, the project completion date, and any schedule
constraints.

Late finish date (LF) – This is the latest possible point in time when the
uncompleted sections of a schedule activity can finish. This is based upon the
network logic, the project completion date, and any schedule constraints.
First Or Forward Pass - The first pass is the used to calculate the early finish, which
is the early start plus the estimated duration (ES + Duration = EF). In this case, 0+5 =
5 means the activity Determine new product features” can be completed after five
days. Each activity that is a successor can begin as soon as its predecessor activity
is completed.
Therefore, the next two activities can each start after five days. “To calculate the early
finish for each of these activities, add its duration to the early start of 5, for early
completion times of 25 and 15 respectively” (Kloppenborg, 2015: 186).
The difficult part of calculating the first pass comes when an activity has more than
one predecessor. For example, “Perform sales calls” cannot begin until all three
preceding activities (Produce prototypes,” ”Design graphics,” and “Conduct marketing”)

are completed. Therefore, its early start is 4. This is true even though “Produce
prototypes” and Design graphics” have earlier finish times, because “Conduct
marketing” cannot be completed until day 45. The later time is always taken. The
results of the first pass are shown in Exhibit 7.12. Note that the earliest the entire
project can be completed is 70 workdays.” (Kloppenborg, 2015:186).
Second Or Backward Pass - The second pass is also known as the backward pass.
This is a critical path method technique that is used to calculate the late start and the
late finish dates. This is done by working backwards through the schedule model from
the project end date.
“When performing the backward pass, teams start at the end and work backward
asking, “How late can each activity be finished and started?” Unless there is an
imposed date, the late finish for the last activity during planning is the same as the
early finish date. In our example, we know the earliest we can finish the entire project
is 70 days, so we will use that as the late finish date for the last activity. If the activity
“Perform sales calls” must end no later than 70 and it takes 25 days, then it must start
no later day 45. In other words, calculate the late start by subtracting the duration from
the late finish (LF – duration = LS).
The confusing part of calculating the second pass is when there is more than one
successor. In Exhibit 7.13, one place this occurs is at the first activity,
‘Determine new product features,” since two activities are immediate start soonest
dictates the late finish date of the predecessor. In this example, ‘Design marketing
campaign” must start no later than after day 5; therefore, five days is the late finish for
the first activity” (Kloppenborg, 2015:187).

Float And The Critical Path - After completion of both passes the early and late start
dates for every activity and the amount of time that will be taken over the entire project
is known. The project team must still know the critical path.
The critical path is calculated easily by first determining each activity’s float
(sometimes float is called slack).
“Float can be total float, which is “the amount of time a schedule activity may be
delayed or extended from its early start date without delaying the project finish date: or
free float, which is “the amount of time a schedule activity can be delayed without
delaying the early start of any successor” (Kloppenborg, 2015:188).
“A Project Manager wants to know how much float each activity has in order to
determine where to spend her time and attention. Activities with a great deal of float
can be scheduled in a flexible manner and so not cause a manager much concern.

Activities with no float or every little float, on the other hand, need to be scheduled
very carefully: (Kloppenborg, 2015:188).Float is calculated by the equation Float =
Late start - Early start (Float = LS – ES). The critical path is the sequence of
activities from start to finish in the network that have no float.
In Exhibit 7.14, activities A, S, F and G have no float and therefore, create the critical
path. It is a typical to mark the critical path in red or in boldface to call attention to it.
Activities B, C, and E each have float and are not on the critical path. If activity B is
delayed, it will delay the start of activity C; therefore, activity B has total float.
While activity B can be delayed up to 10 days without delaying the entire project, any
delay to activity B would delay the start of activity C. On the other hand, activities C
and E can be delayed by 10 and 20 days, respectively, without causing any other
activity to be delayed. Therefore, their float is free float – impacting neither the
overall project nor any activity in it. “Protect managers carefully monitor the
critical activities. They also closely watch activities with little float – think of these as
“near-critical” activities. A project with many activities that have little float is not
very stable.
Even small delays on near-critical activities can change the critical path. Project
Managers can sometimes “borrow” resources form an activity with plenty of float to
use first on an activity that is either already critical or nearly critical.

7.8.2 Enumeration Method

The enumeration method is the second method in calculating the critical path which is
completed by listing or enumerating all of the paths through a network.
This method has an advantage in that since all of the paths are identified and
timed. If a project team requires to compress the project schedule they have
knowledge of the critical path and the other paths that may be nearly critical or those
paths with very little float. In compressing a schedule it is imperative to keep track of
both critical and near-critical paths.
See Exhibit 7.15, where three paths are identified and the total duration is calculated
for each of these paths. “ADFG is the critical path with an expected duration of 70
days, just as was determined with the tow-pass method. Now, however, we also
know that path ADEG is expected to take 50 days (20 less than the critical path)”

7.9 UNCERTAINTY IN PROJECT SCHEDULES
On some project there are so many uncertainties that exist and that Project Managers
have far less confidence in their ability to accurately estimate completion times.
However, sponsors and clients must still be informed by the Project Managers on how
long they believe a project will take. Project Managers are then held accountable
for meeting these deadline dates. A common strategy to handle this sort of potential
problem is to construct the best schedule possible and the project will must be
monitored very closely. Another strategy is to estimate a range of possible times
that each individual activity may take and then consider what impact this will have
on the entire schedule. PERT and Monte Carlo are two methods that can sometimes
be used for this approach.
7.9.1 Program evaluation and Review Technique

A project team must begin by sequencing the activities into a network in order to use
PERT. The project team will create three estimates; optimistic, most likely, and
pessimistic for each activity.
Optimistic + 4 (Most likely + Pessimistic
Estimated time = ------------------------------------------------

6
Therefore, for the first activity, the estimated time = 4 + 4 (5) = 12 = 6

`
6
The primary advantage of PERT - it helps everyone to realize the amount of

uncertainty that exists in the project schedule. It makes uncertainty levels very visible
and the calculations often indicates that expected time is actually longer than the
most likely time. If many things go very well on an activity then a little time can be
saved however if things go very wrong a great deal of time can be lost. The use of
PERT does involve difficulties as listed below:
1. It is not easy to create one estimate of how long an activity will take. Therefore it
takes more effort money to create three estimates.
2. There are not guarantees on how worthwhile any of the three estimates are going
to be.

3. PERT does not accurately address when two or more activities need to be done
prior to the third activity commencing. This risk is underestimated by PERT in that the
schedule can run over a longer time.
PERT highlights uncertainty in project duration and its logic is therefore useful to
Project Managers but since it also has some problem there is a reluctance of its use to
fully calculate and monitor project schedules by many Project Managers.
7.10 SHOW THE PROJECT SCHEDULE ON A GANTT CHART

A Gantt or Bar Chart is a tool for communicating a project’s schedule. “The Gantt chart
is a horizontal bar chart showing each activity’s early start and finish. The simplest
Gantt charts show a bar for each activity stretched out over a tie line. Many
stakeholders also want to see which activities are critical and the amount of float
noncritical activities have. Therefore, critical activities are normally shown in
red or boldface, noncritical activities are normally shown in blue or normal face, and
the amount of float is shown in muted or thin line out to the late finish of each
noncritical activity.
The units of time are the units the project team used in creating the schedule, whether
that is hours, days, weeks, or another measure. A Gantt chart is shown in Exhibit
7.19. It is easy to understand when each activity should performed.
However, the basic Gantt chart does not show other useful information such as
predecessor – successor relationships, late state dates, and so forth. These can all
be easily displayed on a Gantt chart that is developed using scheduling software such
as Microsoft Project. The instructions for using MS Project to create and print Gantt
charts are covered in the following section” (Kloppenborg, 2015:192-193).

7. 11 USING MICROSOFT PROJECT FOR CRITICAL PATH SCHEDULES

“Remembers that five different things can limit how fast a project can be
completed: the logical order to the activities, the duration of each activity, the
number of key resources available when needed, any imposed dates, and cash flow.
It is helpful to use MS Project to construct schedules by considering each of
these limitations in order. That is, first the logical order is determined, and then
duration estimates are applied. It is often helpful to confirm the logical order first
because if people also apply the estimated durations right away, MS Project
generates dates that may not please some decision makers. You may secure
approval of a more realistic schedule if you allow people to first concentrate on the
order of work and then how long each activity takes” (Kloppenborg,2015:193-194)
Read up on page: 194-199 in our prescribed textbook on how to set up the project
schedule, build a logical network diagram, understand the critical path and display and
print schedules with MS Project. Also see Exhibit 7.22 - A Gantt chart with WBS and
tasks data.

7.12 SUMMARY
This unit discussed the potential problems in estimating time accurately. Project
Schedule limitations and how to deal with each limitation, potential problems and how
to overcome these problems in estimating time accurately and how to use the activity
on node (AON) method to develop a project schedule. Adjusting a project’s sequence
logic using leads, lags, and alternative dependencies were also covered in this unit.
The Critical Path, Gantt Chart and use of MS Project 2013 are other important topics
that were discussed in this unit.

You have now come to the end of unit seven. Do the activities to
expand your knowledge on this section.
ACTIVITIES
ACTIVITY: 7.1
What are the concepts upon which the CPM and PERT were founded?
ACTIVITY: 7.2
What are the five factors which may limit how fast a project is completed?
ACTIVITY: 7.3
What are leads and lags?
ACTIVITY: 7.4
What is a critical path and what are the methods that may be used to determine it?
ACTIVITY: 7.5
What does the Monte Carlo Simulation process generate?

ACTIVITY ANSWERS
Unit one activities
1.1) Projects are temporary and no two are identical. Operations consist of
ongoing work needed to ensure that an organisation continues to function effectively.
1.2) Soft skills include communication and leadership activities. Hard skills can
include risk analysis, quality control, scheduling, budgeting, and so forth.
1.3) Prioritization efforts should include asking the following questions:
What value does each potential project add to the

organisation?
Are the demands of performing each project
understood?
Are the resources needed to perform the project
available?
Is there enthusiastic support from external customers and from one
or more internal champions?
Which projects will best help the organisation achieve its
goals?
1.4) The four project executive-level roles are the:
Steering team: role for this team is to select, prioritize, and resource projects
in accordance with the organisations strategic planning and to ensure that
accurate progress is reported and necessary adjustments are made.
Sponsor: the person/group that provides resources and support for the
project and is accountable for enabling success.
Customer: this person ensures that the needs and wants of the various
constituents in the customer’s organisation are identified and prioritized and
that project progress and decisions continually support the customer’s desires.
Chief projects officer: sometimes defined as an organisational structure that

standardizes the project related governance processes and facilitates the
sharing of resources, methodologies, tools and techniques.
1.5) In agile projects the scrum master is a project manager who serves and
leads in a collaborative, facilitating manner.

Unit two activities
2.1) A SWOT (Strengths, Weaknesses, Opportunities and Threats) analysis is a

strategic analysis used to analyse both the internal and external environments and
determine how they will enhance or limit the organisations ability to perform.
2.2) Once a SWOT analysis is complete, the organisations leadership should

establish guiding principles such as the vision and mission.
2.3) A subproject is a smaller portion of the overall project created when a

project is subdivided into more manageable components or pieces.
2.4) Some of the typical reasons for project

failure are:
Not enough resources.

Not enough time.
Unclear expectations.
Changes to the project.
Disagreement about expectations.
2.5) Several Cost-Benefit models have weaknesses
such as:
Payback period model does not consider the amount of profit that
may be generated after the costs are paid.
Benefit-Cost Ratio would not be acceptable unless all costs and
benefits were calculated in the present value of money.
IRR and BCRs are problematic if used for choosing between mutually
exclusive projects because they can favour smaller projects that create
less total value for the firm but have high percentage returns.
IRR is sometimes difficult to calculate when a project has
nonconventional cash flows.

Unit three activities
3.1) PMI Code of Ethics and Professional Conduct indicates guidelines for
project managers to instill as follows:
Responsibility – take ownership for decision

Respect – show high regard for ourselves, others, and resources
Fairness – make decisions and act impartially
Honesty – understand the truth and act in a truthful
manner.
3.2) Functional organisation: a hierarchical organisation where each employee

has one clear supervisor, staff are grouped by areas of specialization,
and managed by a person with expertise in that area.
Projectised organisation: defined as any organisational structure in

which the project manager has full authority to assign priorities, apply
resources, and direct work of persons assigned to the project.
Matrix organisation: any organisational structure in which the project

manager shares responsibility with the functional managers for assigning
priorities and directing work of persons assigned to the project.
3.3) Power culture, role culture, task culture, personal culture.
3.4) (a) Overall priority setting.
(b) Project selection and
prioritization. (c) Sponsor selection.
(d) General
guidance. (e)
Encouragement.
3.5) The person or group who provides resources and support for the
project and is accountable for enabling success for the project.

Unit four activities
4.1) (a) Authorize the project manager to proceed.
(b) Help the project team and sponsor develop a common
understanding. (c) Help the project team and sponsor commit.
(d) Quickly screen out obviously poor

projects.
4.2) Scope creep is the uncontrolled expansion to product or project scope

without adjustments to time, cost, and resource.
4.3) First, any negative risk that is a threat that may inhibit successful project
completion needs to be identified and, if it is a major risk, a plan must be
developed to overcome it.
Second, a positive risk is an opportunity to complete the project better,

faster, and/or at lower cost or to capitalize upon the project in additional ways,
and a plan should be developed to capitalize upon it.
Third, sometimes there is more risk to the organisation if the project

is not undertaken- and this provides additional rationale for doing the project.
4.4) A project charter is the deliverable that grants the project team the right to
continue into the more detailed planning stage of a project.
4.5) - Team work develops.
- Agreement, trust, communication, and commitment between the sponsor,

project manager, and project team develop.
- The project team does not worry if management will accept a

decision.
- The sponsor is less likely to unilaterally change the original

agreement.

Unit five activities
5.1) Once the scope is determined, other aspects of the project can be planned
such as:
Schedule.
Budget.
Resources
Needs.
Risks.
Quality.
5.2) Stakeholders include people who:
Work on the
project.
Provide people or resources for the
project.
Have their routines disrupted by the
project.
Stakeholders can be prioritized based upon
level of:
Authority
(power),
Concern (interest),
Active involvement (interest),
Ability to affect changes (impact),
Need for immediate influence (urgency), or
Appropriateness of their involvement (legitimacy).
5.3) The four types of information which should be captured in a project meeting
are:
Decisions made.
New issues surfaced and old issues resolved.
Action items agreed to.
An evaluation of the meeting.
5.4) Characteristics of a virtual team are as follows:
Team members are physically dispersed.

Time boundaries are crossed.

Communication technologies are used.
Cultural, organisational, age, gender, and functional diversity is present.
5.5) Communication leads to cooperation, which leads to coordination, which
leads to project harmony, which leads to success.
Unit six activities
6.1) Product scope is the features and functions that characterize a product,
service or result.
Project scope is the work performed to deliver a product, service or result

with the specified features and functions.
6.2) When a project manager and team listen closely to both external and
internal customers, they understand better both what their needs are and
what risks and issues may confront them during the project.
6.3) User stories are instances where the team creates personas, which are
fictional people who represent user types and then asks what will they do with
the project deliverables and how will they benefit. These user stories define
scope and functionality.
6.4) The work breakdown structure is a tool that project teams use to
progressively divide the deliverables of a project into smaller and smaller
pieces.
The WBS is normally developed by listing deliverables - first major

deliverables and then progressively smaller ones until the team feels that
every deliverable has been identified.
6.5) Setting up the WBS has five steps, as follows:
Enter summaries.
Create the outline for your WBS.
Insert row number column.
Hide (or show) the desired amount of
detail.

Unit seven activities
7.1) The CPM and PERT were founded on concepts still in place today of
identifying activities, determining their logical order, and estimating the
duration for each.
7.2) The five factors which may limit how fast a project can be completed are:
o Logical order.
o Activity duration.
o Resource availability.
o Imposed dates.
o Cash flow.
7.3) A lead is the amount of time whereby a successor activity can be
advanced with respect to a predecessor activity.
A lag is the amount of time whereby a successor activity is required to be

delayed
with respect to a predecessor
activity.
7.4) A critical path is the sequence of activities that represents the longest path
through the project, which determines the shortest possible duration.
The two methods for determining the critical path are the two-pass and
enumeration methods.
7.5) The Monte Carlo simulation is a process which generates hundreds and
thousands of probable performance outcomes based on probability
distributions for cost and schedule on individual tasks.

BIBLIOGRAPHY
Bricknell., Fraser., Goldman., Kara., Labuschagne., Maritz., McGregor., Radford.,
(2014). Project Management in Perspective. (4th Edition). Oxford University Press,

South Africa.
Gido, J and Clements, JP. (2015). Successful Project Management. (6th Edition).
Cengage
Learning, USA.
Van der Waldt, G and William, F. (2015). A Guide to Project Management. (2nd
Edition). Shumani Mills Communications, Juta and Company (Pty) Ltd, SA.
Kloppenborg, TJ. (2015). Contemporary Project Management. (3rd Edition). Cengage

Learning, USA.

Bcomscm Project Management

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Bcomscm Project Management

Caricato da

Copyright:

Formati disponibili

BACHELOR OF COMMERCE IN

SUPPLY CHAIN MANAGEMENT

Chapter 2 Project Selection and Prioritization 21

Chapter 3 Organisational Capability - Structure, Culture, and Roles 45

Stakeholder Analysis and Communication Planning

REGENT BUSINESS SCHOOL 1

INTRODUCTION TO PROJECT MANAGEMENT STUDY GUIDE

REGENT BUSINESS SCHOOL 2

Essential (Prescribed and recommended) Reading

Kloppenborg, TJ. (2015). Contemporary Project Management. (3rd Edition). Cengage

Additional Recommended Reading:

3 Bricknell., Fraser., Goldman., Kara., Labuschagne., Maritz., McGregor., Radford.,

REGENT BUSINESS SCHOOL 3

INTEGRATED EXIT LEVEL OUTCOMES &

 To understand the roles, skills and techniques a project manager uses.

 To be able to define the objectives and scope of a project.

 To communicate with all stakeholders in the project.

 To plan, control and allocate the project schedule and resources.

 To implement and assist with basic project monitoring and control

REGENT BUSINESS SCHOOL 4

INTRODUCTION TO PROJECT MANAGEMENT

This is an introduction unit on Project Management and discusses what a project

1.1. WHAT IS A PROJECT?

“A project is an endeavour to accomplish a specific objective through a unique set of

REGENT BUSINESS SCHOOL 5

The project output is a collection of primary and supporting deliverables. A

Projects have unique combinations of stakeholders- “an individual, group, or

According to Gido and Clements, (2015), stakeholders can be the

Project Management is “the application of knowledge, skills, tools and techniques to

During these processes, trade-offs must be made among the following

 Meet the agreed upon requirements.

REGENT BUSINESS SCHOOL 6

Project Management includes:

 Administrative tasks: for planning, documenting, and controlling work.

1.2. HISTORY OF PROJECT MANAGEMENT

1.3. HOW CAN PROJECT WORK BE DESCRIBED?

REGENT BUSINESS SCHOOL 7

 Projects are temporary while other work (operations), are continuous.

 Project Managers frequently have more responsibility than authority.

 Projects go through predictable stages called a life cycle.

1.3.1. Projects versus Operations

Think of the consequences if an operations manager did not use

1.3.2. S o f t Skills and Hard Skills

To successfully manage and lead in a project environment, a person needs to develop

1.3.3. Authority and Responsibility

REGENT BUSINESS SCHOOL 8

1.3.4. Project Life Cycle

REGENT BUSINESS SCHOOL 9

1.4. UNDERSTANDING PROJECTS

1.4.1. Project Management Institute

“Project Management has professional organisations just as do many other

1.4.2. Project Management Body of Knowledge (PMBOK)

The Project Management Body of Knowledge consists of a project life cycle

The ten knowledge areas are:

REGENT BUSINESS SCHOOL 10

10. Stakeholder management.

Read up more on this section on page 9 of the prescribed text book.

1.4.3. Selecting and Prioritizing Projects

Think about what would happen if all members of an organisation

The prioritization efforts should include asking the following questions:

Are the resources needed to perform the project available?

REGENT BUSINESS SCHOOL 11

1.4.4. Project Goals and Constraints