1
Version 1
Learner Guide
Learner Guide
LP 1:
Project Management
introduction
2
Version 1
Learner Guide
SAQA ID 120372: Explain Fundamentals of Project Management; NQF Level 4, 5 Credits
SAQA ID 120373: Contribute to project initiation, scope definition and scope change control;
NQF Level 4, 9 Credits
3
Version 1
Learner Guide
Table of Contents
PROGRAMME OVERVIEW ............................................................................................................................ 8
Programme entry level requirements ......................................................................................................... 8
Programme Outcomes ................................................................................................................................ 8
Assessment ................................................................................................................................................ 12
Learning map (delivery structure) ........................................................................................................ 14
Learner Support ......................................................................................................................................... 14
MODULE 1 THE NATURE OF A PROJECT ............................................................................................ 15
THE NATURE OF A PROJECT ....................................................................................................................... 16
1.1 The characteristics of a project ................................................................................................ 17
Major variables or parameters of projects ................................................................................................ 18
1.2 The differences between project and non-project work .......................................................... 19
1.3 The reasons for undertaking projects ...................................................................................... 19
1.4 A range of types of projects and their complexity.................................................................... 20
Major types of projects based on product of project ................................................................................ 20
Other variables used to categorise projects .............................................................................................. 21
Situational classification of projects .......................................................................................................... 22
1.5 The basic project life cycle........................................................................................................ 23
Class Activity 1: The nature of a project ............................................................................................... 25
MODULE 2 THE NATURE OF PROJECT MANAGEMENT ...................................................................... 26
THE NATURE OF PROJECT MANAGEMENT .................................................................................................... 27
2.1 Define project management .................................................................................................... 27
PMBOK ...................................................................................................................................................... 32
PRINCE2 ..................................................................................................................................................... 33
Project management terminology ........................................................................................................ 35
Project Management Software............................................................................................................. 36
2.2 The differences between project management and general management ............................. 38
2.3 Relationship between project management processes and technical (end product related)
processes ........................................................................................................................................ 40
2.4 Role of the project team member and the project manager ................................................... 43
Role of the project team member ............................................................................................................. 43
Role of the project manager ...................................................................................................................... 44
2.5 Stakeholders, roles and responsibilities ................................................................................... 45
2.6 Project stakeholders: Roles, needs and expectations ............................................................... 49
Stakeholders and how they interact with the project ............................................................................... 49
2.6.1 Identify Project Stakeholders ........................................................................................................... 52
2.6.2 Verify project deliverables against the needs of stakeholders ......................................................... 59
2.6.3 Document approved modifications to stakeholder needs and communicate them to relevant
parties........................................................................................................................................................ 62
Class Activity 2: The Nature of Project Management ........................................................................... 62
MODULE 3 STRUCTURES IN THE PROJECT ENVIRONMENT ............................................................... 63
STRUCTURES IN THE PROJECT ENVIRONMENT ................................................................................................ 64
3.1 Reasons for defining structures for a project ........................................................................... 64
3.2 Programme and project hierarchies ........................................................................................ 64
Programme ................................................................................................................................................ 64
Programme and project hierarchies .......................................................................................................... 65
3.3 Structures for work, product and cost breakdown ................................................................... 66
Work Breakdown Structure (WBS) ............................................................................................................ 66
Product Breakdown Structure ................................................................................................................... 68
Cost Breakdown Structure......................................................................................................................... 69
4
Version 1
Learner Guide
Class Activity 3: Structures in the project environment ....................................................................... 69
MODULE 4 APPLICATION OF ORGANISATION STRUCTURES IN A PROJECT ENVIRONMENT ............... 70
THE APPLICATION OF ORGANISATION STRUCTURES IN A PROJECT ENVIRONMENT ................................................... 71
4.1 Basic differences between a functional and matrix organisation structure ............................ 71
Functional organisation structure ............................................................................................................. 71
Process or functionally structured team ................................................................................................... 72
Divisional organisation structure ............................................................................................................... 73
Matrix organisation structure.................................................................................................................... 75
Class Activity 4: The application of organisation structures in a project environment ......................... 78
MODULE 5 PROJECT MANAGEMENT PROCESSES AND ACTIVITIES .................................................... 79
PROJECT MANAGEMENT PROCESSES AND ACTIVITIES ....................................................................................... 80
5.1 Key processes and activities that take place to manage a project from beginning to end ...... 81
Key project management processes .......................................................................................................... 81
Initiation ............................................................................................................................................... 81
Planning and design .............................................................................................................................. 82
Production or execution ....................................................................................................................... 82
Monitoring and controlling ................................................................................................................... 82
Closing (close-out) and Maintenance ................................................................................................... 83
Evaluation ............................................................................................................................................. 84
Supplementary sub-processes and activities ............................................................................................. 84
5.2 Reasons for planning and controlling a project and consequences of not planning and
controlling ...................................................................................................................................... 88
Project Risk Management ..................................................................................................................... 92
Class Activity 5: Project processes and activities .................................................................................. 95
MODULE 6 PROJECT NEEDS, EXPECTATIONS, CONSTRAINTS, ASSUMPTIONS, EXCLUSIONS,
INCLUSIONS AND DELIVERABLES ...................................................................................................... 96
PROJECT NEEDS, EXPECTATIONS, CONSTRAINTS, ASSUMPTIONS, EXCLUSIONS, INCLUSIONS AND DELIVERABLES ............ 97
6.1 Agree objectives with all relevant parties ................................................................................ 98
The Purpose (or Mission)........................................................................................................................... 98
The Goals ................................................................................................................................................... 98
The Beneficial Gains or Scope: The importance of scope .......................................................................... 99
Objectives ................................................................................................................................................ 100
6.2 Identify and record assumptions, needs, expectations, constraints, exclusions, inclusions and
deliverables according to the agreed format ............................................................................... 103
Key Success Criteria (KSC): Project success factors ................................................................................. 103
Assumptions ....................................................................................................................................... 103
Needs and expectations ..................................................................................................................... 104
Constraints.......................................................................................................................................... 104
Exclusions and inclusions .................................................................................................................... 105
Deliverables ........................................................................................................................................ 105
6.3 Develop work packages to present overall view of the project scope .................................... 107
Concepts for breaking down work into manageable work packages ...................................................... 107
6.4 Develop and document a work breakdown structure within agreed time frames ................. 108
Decomposition.................................................................................................................................... 108
Build a work plan ..................................................................................................................................... 111
Small projects ..................................................................................................................................... 111
Medium and Large Projects ................................................................................................................ 111
WBS Examples ......................................................................................................................................... 114
Generic (classic) WBS.......................................................................................................................... 114
WBS by major project phase or stage ................................................................................................. 115
WBS by timeline ................................................................................................................................. 117
5
Version 1
Learner Guide
WBS by deliverable ............................................................................................................................. 117
Class Activity 6: Project needs, expectations, constraints, assumptions, exclusions, inclusions and
deliverables ........................................................................................................................................ 118
MODULE 7 INPUTS TO BE USED FOR FURTHER PLANNING ACTIVITIES............................................ 119
INPUTS TO BE USED FOR FURTHER PLANNING ACTIVITIES ................................................................................ 120
The principles, methods and techniques for scoping a project ............................................................... 120
7.1 Compile scope documentation in accordance with instructions and procedures .................. 121
7.2 Ensure that scope document contains a rudimentary sequence of events and/or milestones
..................................................................................................................................................... 123
Small projects ..................................................................................................................................... 126
Medium Projects ................................................................................................................................ 130
Large Projects ..................................................................................................................................... 133
7.3 Ensure that scope document is communicated to stakeholders for approval ........................ 136
7.4 Record measures for project success in the agreed format ................................................... 137
Dimensions of Project Success ................................................................................................................ 137
Product Success .................................................................................................................................. 138
Class Activity 7: Contribute to preparing and producing inputs to be used for further planning
activities.............................................................................................................................................. 139
MODULE 8 MONITOR ACHIEVEMENT OF THE PROJECT’S SCOPE .................................................... 140
MONITOR ACHIEVEMENT OF THE PROJECT’S SCOPE....................................................................................... 141
8.1 Ensure that feedback of progress towards delivering the scope is communicated in agreed
manner......................................................................................................................................... 141
8.2 Identify deviations from scope and communicate opportunities for corrective action or
improvement to the relevant individuals/teams .......................................................................... 146
8.3 Identify, analyse, describe and report the impact of scope change according to agreed
procedures ................................................................................................................................... 146
8.4 Process approved change requests to scope in accordance with project change control
procedures ................................................................................................................................... 148
Requested Changes ................................................................................................................................. 148
Change Control System....................................................................................................................... 148
Variance Analysis ................................................................................................................................ 148
Replanning .......................................................................................................................................... 148
Small Projects .......................................................................................................................................... 149
Medium Projects ..................................................................................................................................... 149
Large Projects .......................................................................................................................................... 150
Controlling Small Scope Change Requests............................................................................................... 152
Batching Small Requests ..................................................................................................................... 152
Project Manager Discretion ..................................................................................................................... 152
Scope Change Contingency Budget .................................................................................................... 152
Freezing Scope Change Requests ....................................................................................................... 153
Backlog ............................................................................................................................................... 154
8.5 Verify project deliverables as complete as per agreed scope definition or specified
requirements ................................................................................................................................ 156
Scope verification ............................................................................................................................... 156
Inspection ........................................................................................................................................... 156
Accepted Deliverables ........................................................................................................................ 156
Class Activity 8: Monitor achievement of the project’s scope ............................................................ 156
Reflection............................................................................................................................................ 156
Facilitator Observation Checklist ........................................................................................................ 156
SUMMATIVE ASSESSMENT ....................................................................................................................... 158
Knowledge Questions ......................................................................................................................... 158
Practical Activities ............................................................................................................................... 158
6
Version 1
Learner Guide
Witness Testimony ................................................................................... Error! Bookmark not defined.
Logbook .............................................................................................................................................. 158
REFERENCES AND FURTHER READING ........................................................................................................ 160
APPENDIX A: ........................................................................................................................................ 161
Glossary ....................................................................................................................................... 169
7
Version 1
Learner Guide
Programme Overview
Welcome to this learning programme that will lead you to greater understanding of how to:

Explain fundamentals of project management

Contribute to project initiation, scope definition and scope change control
As you work your way through the learning programme you will gain competence against the
following Unit Standard:
Programme
LP1: Project Management Introduction
Unit Standards
SAQA ID 120372: Explain Fundamentals of Project Management; NQF Level 4, 5 Credits
SAQA ID 120373: Contribute to project initiation, scope definition and scope change
control; NQF Level 4, 9 Credits
This learning programme is intended for all persons who need to:

explain fundamentals of project management. The person credited with this unit
standard is able to begin operating in a project environment by understanding the
terminology used and interpreting and explaining fundamental concepts of project
management. This standard will also add value to learners who are running their own
business and recognise that project management forms an integral component of any
business

contribute to project initiation, scope definition and scope change control. The person
credited with this unit standard is able to participate in the identification of
stakeholders and their needs and expectations, as well as preparing scope
documentation and assisting in monitoring scope. Learners accessing this standard will
be involved in project management teams or involved in building small project
management teams. These projects may be technical projects, business projects or
developmental projects and will cut across a range of economic sectors. This standard
will also add value to learners who are running their own business and recognise that
project management forms an integral component of any business. Learners accessing
this standard will be working as a leader in the context of a small project/sub-project
involving few resources and having a limited impact on stakeholders and the
environment or working as a contributing team member on a medium to large project
when not a leader
Programme entry level requirements
It is assumed that people learning towards this Unit Standard are already competent in:

mathematics and communication skills at NQF level 4 or equivalent

computer literacy and applicable software at NQF level 4 or equivalent
Programme Outcomes
This learning programme is outcomes-based which means we take the responsibility of
learning away from the facilitator and place it in your hands.
8
Version 1
Learner Guide
Learning will begin in the workshop where you will identify the skills and knowledge you
require in order to meet the specific outcomes and assessment criteria contained in the unit
standard.
9
Version 1
Learner Guide
In this learning programme, we will be covering the following learning outcomes:
Module 1:
Module 2:
he Nature of a Project
The Nature of Project Management

Explain the characteristics of a project with
examples

Explain the differences between project and
non-project work with examples of each

Explain a basic project life cycle with examples
of possible phases

Explain the reasons for undertaking projects
with practical examples

Explain a range of types of projects and their
complexity in simple terms

Describe the major project management
processes and explain it according to recognised
best practice

Explain the differences between project
management and general management with
examples of each

Explain the difference between project
management processes and technical (end
product related) processes with examples of
each

Explain the difference between a project team
member and the project manager in accordance
with role descriptions
Structures in the project environment
Application of organisation structures in a
project environment



Module 4:
Explain the reasons for defining structures for a
project with examples

Define project management and explain its
application according to recognised published
standards
Module 3:




Explain the concept of programme and project
hierarchies with an example
Explain the basic differences between a matrix
and functional organisation structure with
examples of each

Explain the purpose of decomposing a project
into manageable components or parts with
practical examples
Describe and explain the project organisation
structure in a written format

Describe the purpose and key responsibilities of
two roles on a project in a written format

Explain stakeholders with examples of at least
six different stakeholders
Explain the concepts of breakdown structures
for product, work and cost in simple terms
Module 5:
Module 6:
Project management processes and activities
Project needs, expectations, constraints,
assumptions, exclusions, inclusions and
deliverables
Describe key processes and activities that take
place to manage a project from beginning to end
Briefly describe the supplementary management
sub-processes and activities required to support
the key processes and activities with examples
of each

Agree objectives with all relevant parties

Identify and record assumptions, needs,
expectations, constraints, exclusions, inclusions
and deliverables according to the agreed format

Develop work packages to present overall view
of the project scope
10
Version 1
Learner Guide

Explain the reasons for planning and controlling
a project with examples of the consequences of
not planning and controlling

Develop and document a work breakdown
structure within agreed time frames
11
Version 1
Learner Guide
Module 7:
Module 8:
Inputs to be used for further planning activities
Monitor achievement of the project’s scope

Compile scope documentation in accordance
with instructions and procedures




Ensure that scope document contains a
rudimentary sequence of events and/or
milestones
Ensure that feedback of progress towards
delivering the scope is communicated in agreed
manner

Ensure that scope document is communicated
to stakeholders for approval
Identify deviations from scope and communicate
opportunities for corrective action or
improvement to the relevant individuals/teams

Record measures for project success in the
agreed format
Identify, analyse, describe and report the impact
of scope change according to agreed procedures

Process approved change requests to scope in
accordance with project change control
procedures

Verify project deliverables as complete as per
agreed scope definition or specified
requirements
During the workshop you will complete a number of class activities that will form part of your
formative assessment. In this you have the opportunity to practice and explore your new skills
in a safe environment. You should take the opportunity to gather as much information as you
can to use during your workplace learning and self-study.
The workshop will be followed by summative assessment tasks to be completed through selfstudy in your workplace. In some cases you may be required to do research and complete the
tasks in your own time.
Assessment
It is important to note that the onus is on you, as the learner, to prove your competence. You
therefore need to plan your time and ensure that your Portfolio of Evidence is kept up to date
and handed in timeously.
A Portfolio of Evidence is a collection of documents of work you have produced to prove your
competence. You will compile your portfolio from activities, tools and checklists associated
with the unit standard and relevant to the unit standard being assessed.
You will be given the following documents to assist you in creating a portfolio of evidence:

Learner Guide: The Learner Guide is designed to serve as a guide for the duration of
your learning programme and as the main source document for transfer of learning.
It contains information (knowledge and skills required) and application aids that will
assist you in developing the knowledge and skills stipulated in the specific outcomes
and assessment criteria. The learner guide also indicates the formative assessment
class activities that you need to complete towards your Portfolio of Evidence.

Learner Workbook: The learner Workbook contains all the class activities that you
will be completing to show formative learning. These will be assessed as part of your
12
Version 1
Learner Guide
portfolio of evidence as formative assessment. You will be handing in the Learner
Workbook as part of your Portfolio of Evidence.

Learner Portfolio of Evidence Guide: The Learner Portfolio of Evidence Guide
provides details about the assessment, such as the assessment preparation, plan and
specific summative assessment activities that you need to complete in the workplace.
Both formative and summative assessment is used as part of this outcomes-based learning
programme:

Formative Assessment: In order to gain credits for this Unit Standard you will need to
prove to an assessor that you are competent. The Class Activities throughout your
Learner Workbook are designed not only to help you learn new skills, but also to prove
that you have mastered competence. You will be required to develop a Portfolio of
Evidence to hand in to an assessor so that you can be assessed against the outcomes
of this Unit Standard. Where you encounter a Class Activity icon, you must complete
the formative assessment activity in the Learner Workbook. Comprehensive
guidelines for the development of your Portfolio of Evidence may be found in the
Learner Portfolio of Evidence Guide for the particular learning programme that you
are working with.

Summative Assessment: The NQF’s objective is to create independent and selfsufficient learners. This means that you will also be required to do independent
research and assignments, such as Knowledge Questions, Practical Activity (completed
in the workplace), Witness Testimony and Logbook.
The assessment process is discussed in detail in the Learner Portfolio of Evidence
Guide. When you are ready, you will advise your mentor that you are ready for
assessment. He or she will then sign off the required sections in the Learner Portfolio
of Evidence Guide and you will be able to submit your Portfolio of Evidence for
assessment. The summative assessment activities placed in the Learner Portfolio of
Evidence Guide for your convenience. If any of your assessment is conducted using
observation, role plays or verbal assessment, place a signed copy of the checklists,
once completed by your mentor or line manager in your Learner Portfolio of Evidence
Guide, as indicated.
The Training Provider will assess your portfolio. If successful, you will receive the credit value
of this learning programme. The entire assessment process is explained in the Learner
Portfolio of Evidence Guide and you are urged to read this guide as soon as possible as it
explains the assessment process in detail and clarifies your rights and responsibilities to ensure
that the assessment is fair, valid and reliable.
If you are not successful, you will receive all the guidance needed to resubmit your Portfolio
of Evidence within a specific time period, as per the Training Provider requirements.
13
Version 1
Learner Guide
Learning map (delivery structure)
Assessment
Learning activities
for 140 hours of
notional learning
Formative Assessment 30%
Summative Assessment70%
Contact Learning
Theory input
Formative assessment
(workbook activities):
group activities,
simulations
Prescribed
reading, support,
coaching
Learning and
application at the
workplace
Summative assessment
in PoE:
knowledge questions,
practical workplace
activity, Witness
Testimony, logbook
42 hours
0 hour
82 hours
16 hours

Complementary workplace practices



Compilation of Portfolio of Evidence
Coaching and Mentoring; Performance Management
LP1:
Project Management
introduction
LP2:
Assist with project
planning
LP3:
Participate in project
budgeting and risk
management
LP6:
Use second language
communication during
the project
LP5:
Support project
meetings
LP4:
Assist with project
implementation
LP7:
Provide project admin
support
LP8:
Supervise a project
team
Learner Support
Please remember that as the programme is outcomes based – this implies the following:

You are responsible for your own learning – make sure you manage your study,
practical, workplace and portfolio time responsibly.

Learning activities are learner driven – make sure you use the Learner Guide, Learner
Workbook and Learner Portfolio of Evidence Guide in the manner intended, and are
familiar with the Portfolio requirements.

The Facilitator is there to reasonably assist you during contact, practical and
workplace time of this programme – make sure that you have his/her contact details.
14
Version 1
Learner Guide
Module 1
The Nature of a Project
After completing this module, the learner will be able to explain the nature of a project, by
successfully completing the following:

Explain the characteristics of a project with examples

Explain the differences between project and non-project work with examples of
each

Explain a basic project life cycle with examples of possible phases

Explain the reasons for undertaking projects with practical examples

Explain a range of types of projects and their complexity in simple terms
15
Version 1
Learner Guide
The Nature of a Project
The word project 1comes from the Latin word projectum, "to throw something forwards",
which is made up of the prefix pro-, which denotes something that precedes the action of the
next part of the word in time and jacere, "to throw". Thus the original meaning of “project” is
something that has, in a figurative sense, been thrown forward, i.e. a proposal.
The meaning has gradually been extended to include the
process of realising or actualising the proposal, as well as the
people who perform the realisation.
We can therefore see that the concept of people working
together or “organisation” forms an integral part of the
definition of a project. The kind of tasks solved by the
organisation of people working together distinguishes a
project from other organisational units.
We can say that a project is an organisational unit that solves
a unique and complex task.
We can also look at the way in which the people coordinate their work, or the prime
coordinating mechanism. Mintzberg (1983) lists five different coordinating mechanisms:

Direct supervision

Standardisation of work processes

Standardisation of work outputs

Standardisation of worker skills

Mutual adjustment
All of these coordinating mechanisms are used in all organisations, but in any organisation
some mechanism is the most important and can be used as a defining characteristic.
In the case of a project, standardisation will not be appropriate or cost effective, as we have
said that each project is unique.
Direct supervision scales badly, so any medium-sized or larger task will overload the supervisor.
Therefore we can also say that a project is an organisational unit where the prime
coordinating mechanism is mutual adjustment.
APM2 define a project as follows:
unique set of co-ordinated activities, with definite starting and finishing
points, undertaken by an individual or organisation to meet specific objectives
within defined time, cost and performance parameters….human, material and
financial resources are organised in a novel way to deliver a unique scope of work
“…a
1
2
Retrieved from "http://en.wikipedia.org/wiki/Project"
Association of Project Managers: www.apm.org.uk
16
Version 1
Learner Guide
of given specification, often within constraints of cost and time, and to achieve
beneficial change defined by quantitative and qualitative objectives.”
1.1 The characteristics of a project
Based on the definitions of a project, we can see that the characteristic elements of a project
are:

Uniqueness
A project is a one-time set of events. By stating that each project or task is
unique, we are saying that task repetition cannot be a prominent feature,
otherwise we would be able to solve the task once and just copy or standardise
the processes. A project may be similar to prior projects but it is unique in
terms of timeframes, resources, business environment, etc.

Constraints of time and scope
The feature of uniqueness also entails that a project must be delimited both in
scope (totality of work needed to complete a project) and time (there must
be a beginning and an end). This delimitation may not be entirely clear from
the outset, and it could even change during the course of the project, but if
we experienced a permanent stream of changing tasks, we could say that this
was no longer a single project.

Complexity
A project consists of complex and numerous activities. The task must have
some complexity before it belongs to a project. If the task were simple, most
people would know how to solve it and the amount of organisational overhead
normally associated with a project would not be needed.
Note that both the elements of uniqueness and complexity are relative to the project
participants. According to Munk-Madsen3 the fact that “somebody on the other side of the
earth has great experience in solving the actual task and considers it simple is irrelevant if our
participants (in a project) are not aware of this.”

Limited resources and budget

Many people involved, usually across several functional areas in organisations

Sequenced activities

An end-product or service must result from the project
Define Project, by Andreas Munk-Madsen of the Department of Computer Science, Aalborg
University
3
17
Version 1
Learner Guide
Major variables or parameters of projects
The following is a breakdown of the different characteristics that relate to different projects:
Variable
Project
Construction is a contract business
where the scope is laid out in detail
before the project starts
1.
2.
Stability of scope
Degree of uncertainty or risk
Computer Software Development:
Software projects are notorious for
having the scope change radically during
the project
In construction the level of risk is
relatively small for the size of the
investment
Event: scope may change during the
project and uncertainty is high.
Administrative projects involve
intellectual workers
3.
Type of worker
Construction workers, on the other hand,
are almost entirely craft or blue collar
Equipment or System Installation: speed
is essential.
Event: Time is critical to meet a specific
date.
4.
Importance of time (Pace)
Maintenance of Process Industries:
Turnarounds and outages are short in
which down time can cost as much as a
million rand per day and speed is critical.
Design of plans: Quality is of a higher
priority than either time or cost
5.
Importance of cost
Design of plans: Quality is of a higher
priority than either time or cost
Range*
High stability
Low Stability
Low risk
High risk
Intellectual
(white collar)
Craft (blue
collar)
High
importance
High
importance
High
importance
Low
importance
Medium
importance
18
Version 1
Learner Guide
Variable
6.
Level of new technology
7.
Series of projects or one of a
kind
8.
9.
Project
Range*
New Product Development: Developing
a new product is a risky business. By
definition you are pushing the state of
the art.
High level of
risk
Event: It is probably a complex, one of a
kind project
High level of
complexity;
unique
Form of commitment
Research: Research projects are usually
long term where quality takes
precedence over time. It is an intellectual
process where scope may not be defined
at all in the beginning. Internal work or
external contract, depending on topic or
focus of research project.
External
contract or
internal work
Level of detail in plans
Maintenance of Process Industries: A
large number of different craft workers
are involved. They often work three shifts
per day and plans are detailed in hours.
High level of
detail
1.2 The differences between project and non-project work
A project is a temporary and one-time endeavour undertaken to create a unique product or
service; e.g. a new type of toothpaste, or a new marketing campaign.
This property of being a temporary and a one-time undertaking, contrasts with processes, or
operations, which are permanent or semi-permanent ongoing functional work to create the
same product or service over and over again- an organisation's on-going, repetitive activities,
such as accounting or production.
1.3 The reasons for undertaking projects
Projects begin because a problem creates a need. In order to solve the problem or fulfil the
need, you need to formulate a measurable goal. Once a goal is set, you can develop a strategy
to meet it. A project is the strategy to meet this goal.
19
Version 1
Learner Guide
Therefore, we can say that a project is a temporary endeavour undertaken to achieve a
particular aim.
Projects are initiated in the following scenarios:

When starting a new business.

In order to develop/ modify a product or service.

For relocating and/or closing a facility.

For regulatory purposes.

For some community issues.

In order to re-engineer the process so as to reduce complaints, reduce cycle time,
and eliminate errors.

For implementing a new system or process.

To introduce new equipment, tools or techniques.
1.4 A range of types of projects and their complexity
There are a four basic ways in which one can classify projects:

Geographical location

Industrial sector (Standard Industrial Classification System)

Stage of the project life cycle

Product of the project (construction of a building or development of a new
product)
The most useful classification of types of project is by the product of the project, or deliverable
that the project is producing, such as constructing a building, developing a new product,
developing a new computer software program, or performing a maintenance turnaround or
outage on a chemical plant or electricity generating station.
Each of these types of projects has more in common with other similar projects producing the
same type of product than with other types of projects.
Conversely there is much less commonality between different types of projects in the same
industrial sector or company. For example, there is much more commonality between projects
for developing a new software system in a construction company and a bank than there is
between three projects in the same bank for constructing a new building, developing a new
product and developing a new computer software system.
Major types of projects based on product of project
The following are examples of nine different types of projects based on the product they
produce:
Type of Project
Product of Project (Examples)
20
Version 1
Learner Guide
1.
Administrative
Installing a new accounting system
2.
Construction
A building or road
3.
Computer Software Development
A new computer program
4.
Design of Plans
Architectural or engineering plans
5.
Equipment or System Installation
A telephone system or IT system
6.
Event or Relocation
Soccer World Cup or a move into a new building
7.
Maintenance of Process Industries
Petro-chemical plant or electricity generating station
8.
New Product Development
A new drug or defence product
9.
Research
A feasibility study or investigating a chemical
Other variables used to categorise projects
The following factors are important in projects but are not specific to any project type. They
could relate to any of the types. These factors could be used in other types of project
classification.







Size
Duration (Length of project time)
Number of workers involved
Cost (large, medium or small)
Complexity
Urgency
Organisational design
21
Version 1
Learner Guide
Situational classification of projects4
Lost in the Fog
The objectives and activities are unclear, either at the start and/or during the project. The
types of projects where process and tools could be unclear, are change initiatives and firsttime projects. You will proceed with goal-setting in a step-by-step manner, as if finding your
way in dense fog.
Quest
Situations in which the main objectives of the project or next stage are known, but how to
tackle the project is problematic. Business improvement and product development projects
fall into this category. Process and tools are generally not very well understood or developed.
Considerable research will be required in the project initiation and definition phases, in order
to get clarity and buy-in.
4
Checkland, P., & M. Winter, Soft Systems: a fresh perspective for project management, New Civil Engineer
International, February 2004 pp 25-30
22
Version 1
Learner Guide
Movie
Situations in which the know-how generally exists, but the main project goal or the
next stage goals are unclear. Systems development and prototype development fall
into this category. Process and tools are well understood and developed, but
objectives need to be clearly defined at the beginning of the project.
Paint by numbers
Relatively straightforward situations in which the objectives and activities are known: these
will be construction and engineering projects, or projects which are similar to others that have
been done in the past. Therefore processes are well understood and tools are well developed.
1.5 The basic project life cycle
The collective activities associated with building the project deliverables are referred to as the
project life cycle.
The project life cycle can be defined as “the complete set of time periods through which a
project passes sequentially in a logical and orderly manner”.
While there are many different versions of the project life cycle, all essentially contain the steps
of:

Germination of the idea

Proposal and initiation

Design and appraisal

Mobilisation of the team

Execution and control

Integration of the team and their work

Testing

Handover of the project's product

Closeout of the work.
In its simplest form the life cycle consists of four major periods or phases:

Concept (the project concept as a need solution is selected and defined)

Development/ Definition (the concept is verified and developed into a workable plan
for implementation)

Implementation (the implementation plan is carried out)

Closeout (the project process is completed and documented, and the finished product
is transferred to the care, custody and control of the owner)
23
Version 1
Learner Guide
This model provides a basic outline that can be used on any project. You start off
understanding the requirement of the solution, designing a solution, building and testing a
solution and then implementing the solution. Each of these major areas of focus is called a
phase.
The figure below5 shows a typical project life cycle separated into its generally accepted four
fundamental phases. The figure also lists the activities to be expected in each phase.
The phase separations correspond to key decision points for purposes of executive
level control.
Not all projects, of course, conform rigorously to the stages shown and the activities within
each may vary somewhat. However, less than satisfactory project performance and lack of
control can frequently be traced to significant departures from the division of activities as
shown.
The simple model described above can be applied to all projects. Even if you have a small
project, you still have to go through these basic steps, although some of them may only be a
mental exercise. When you receive some type of service request, it describes the work
required (analysis and requirements), which you take and mentally map into the work to be
performed (design). You then make the changes required, test them (test) and implement
them (construct, test, implement). This approach is the life cycle model you would probably
5
Adams, J. R. and Barndt, S. E. "Organizational Life Cycle Implications for Major Projects." Project Management
Quarterly, Vol. IX, No. 4, Dec. 1978
24
Version 1
Learner Guide
end up with even if you knew nothing about methodology and just had to build a project work
plan from scratch.
The important point is that a common, scalable project management process can be used
effectively on all your projects. The detailed work to build your deliverables is referred to as
the “project life cycle”.
Class Activity 1: The nature of a project
In small groups or individually as per your facilitator’s instructions, complete
the formative activities in your Workbook
25
Version 1
Learner Guide
Module 2
The Nature of Project Management
After completing this module, the learner will be able to explain the nature and application of
project management, by successfully completing the following:

Define project management and explain its application according to recognised
published standards

Describe the major project management processes and explain it according to
recognised best practice

Explain the differences between project management and general management with
examples of each

Explain the difference between project management processes and technical (end
product related) processes with examples of each

Explain the difference between a project team member and the project manager in
accordance with role descriptions
26
Version 1
Learner Guide
The Nature of Project Management
As a discipline, project management developed from several different fields of application,
including construction, mechanical engineering, military projects, etc.
In the United States, the forefather of project management is
Henry Gantt, called the father of planning and control
techniques, who is famously known for his use of the “bar”
chart as a project management tool. He was an associate of
Frederick Winslow Taylor and subscribed to his theories of
scientific management. Henry Gantt is also known for his
study of the work and management of Navy ship building. His
work was the forerunner to many modern project
management tools, including the work breakdown structure
(WBS) and resource allocation.
Prior to the 1950's, projects were managed on an ad hoc basis using mostly Gantt Charts, and
informal techniques and tools. The 1950's heralded the true beginning of the modern project
management era. At that time, two mathematical project scheduling models were developed:
(1) the "Program Evaluation and Review Technique" or PERT, developed as part of the United
States Navy’s (in conjunction with the Lockheed Corporation) Polaris missile submarine
program; and (2) the "Critical Path method" (CPM) developed in a joint venture by both
DuPont Corporation and Remington Rand Corporation for managing plant maintenance
projects. These mathematical techniques quickly spread into many private enterprises.
In 1969, the Project Management Institute (PMI) was formed to serve the interest of the
project management industry. The premise of PMI is that the tools and techniques of project
management are common even among the widespread application of projects from the
software industry to the construction industry. In 1981, the PMI Board of Directors authorised
the development of what has become The Guide to the Project Management Body of
Knowledge, containing the standards and guidelines of practice that are widely used
throughout the profession.
Today, project management is used globally by multi-national corporations, governments, and
smaller organisations alike as a means of meeting their customers’ needs by both
standardising and reducing the basic tasks necessary to complete a project in the most
effective and efficient manner.
As a result, project management leadership is a highly desirable and sought-after skill as
intense global competition demands that new projects and business development be
completed on time and within budget.
2.1 Define project management
We have learnt that a project is a carefully selected set of activities chosen to use resources
(time, money, people, materials, energy, space, provisions, communication, quality, risk, etc.)
to meet pre-defined objectives.
27
Version 1
Learner Guide
Therefore a project is a temporary endeavour undertaken to achieve a particular aim and to
which project management can be applied, regardless of the project’s size, budget or timeline.
28
Version 1
Learner Guide
So, what is meant by the term “project management”?
Project management is “the application of knowledge, skills, tools, and techniques to a broad
range of activities in order to meet the requirements of a particular project”.6
The term “project management” refers to a set of well-defined methods and techniques for
managing a team of people to accomplish a series of work tasks within a well-defined
schedule and budget.
When we deconstruct this definition, we can see that project management is subject to very
well-defined outcomes and challenges:

Effective management of resources
The challenge is the optimised allocation and integration of the inputs needed to meet
pre-defined objectives

Delivery on time and on budget
Ensure that a project is delivered within the defined constraints. All projects must be
defined in terms of time, budget, and performance. These are commonly referred to
as the ‘Triple Constraints’. The one constraint that has the highest priority becomes
the driver of the project.

Well-defined methods and techniques
Project management standards and best practices are used to increase the likelihood
of overall success. Individual standards and practices may vary in complexity and
application, but the goals are usually the same - to produce desired project results
within the boundaries of time, costs and available resources.
Any effective programme for project management standards and best practices must
provide relevant steps and strategies to guide the selection, management and control
of projects pending and underway.
The discipline of project management is subject to well-defined standards. Some of
these are:
6
As defined in the 2000 edition of A Guide to the Project Management Body of Knowledge (PMBOK® Guide)
29
Version 1
Learner Guide
-
Association for Project Management Project Management Body of Knowledge
(APM BoK)
-
Project Management Institute Guide to the Project Management Body of
Knowledge (GPMBOK)
-
International Organisation for Standards (ISO)
ISO 9001 certification of a fish wholesaler
Each standard is applied to particular national and international project management
undertakings.
There is also a global network of Universities for research on project management academic
and competency requirements. The International Research Network on Organizing by
Projects (IRNOP) is a collegial association of academic institutions that meets each year to
consider project management research.
In addition, there are many corporations globally which have developed proprietary as well
as open standards for project management:

IBM (RUP)

CGI

ITIL
Several national and professional associations exist which have as their aim the promotion
and development of project management and the project management profession. The most
prominent associations include:

The Australian Institute of Project Management (AIPM)

The International Project Management Association (IPMA)

The Project Management Institute (PMI) - In 1987, PMI published the first PMBOK® in
an attempt to document and standardise generally accepted project management
information and practices. The current edition, the third edition copyright 2004, was
released on October 31 2004 and provides a basic reference for anyone interested in
project management. It provides a common lexicon and consistent structure for the
field of project management.
30
Version 1
Learner Guide

The International Association of Project & Program Management (IAPPM)

The International Project Management Commission (IPMC)

Association for Construction Project Managers (ACPM)

Cost Engineering Association of South Africa (CEASA)

Project Management South Africa (PMSA)
Please explore the websites for these associations on the internet.
31
Version 1
Learner Guide
International Standards are contained in the following documents:

A Guide to the Project Management Body of Knowledge (PMBOK Guide) The PMBOK
Guide is widely accepted to be the standard in project management

APM Body of Knowledge. 5th ed. (APM - Association for Project Management (UK))
PMBOK
The Project Management Body of Knowledge (PMBOK) is a collection of processes and
knowledge areas generally accepted as best practice within the project management
discipline.
As an internationally recognised standard (IEEE Std 1490-2003) it provides the fundamentals
of project management, irrespective of the type of project be it construction, software,
engineering, automotive etc.
PMBOK recognises 5 basic process groups and 9 knowledge areas typical of almost all projects.
The basic concepts are applicable to projects, programs and operations. The five basic process
groups are:
1. Initiating
2. Planning
3. Executing
4. Monitoring and Controlling
5. Closing
Processes overlap and interact throughout a project or phase. Processes are described in terms
of:

Inputs (documents, plans, designs, etc.)

Tools and Techniques (mechanisms applied to inputs)

Outputs (documents, products, etc.)
The nine knowledge areas are:
1. Project Integration Management
2. Project Scope Management
3. Project Time Management
4. Project Cost Management
5. Project Quality Management
6. Project Human Resource Management
7. Project Communications Management
8. Project Risk Management
32
Version 1
Learner Guide
9. Project Procurement Management
Each knowledge area contains some or all of the project management processes. For example,
Project Procurement Management includes:

Procurement Planning

Solicitation Planning

Solicitation

Source Selection

Contract Administration

Contract Closeout
Much of PMBOK is unique to project management e.g. critical path and work breakdown
structure (WBS). Some areas overlap with other management disciplines. General
management also includes planning, organising, staffing, executing and controlling the
operations of an organisation. Financial forecasting, organisational behaviour and planning
techniques are also similar.
PRINCE2
PRINCE (Projects IN Controlled Environments), currently PRINCE2, was originally developed for
the needs of IT projects, the method has also been adopted on many non-IT projects.
PRINCE2 in a nutshell:
The key features of PRINCE2 are a:

focus on business justification

defined organisation structure for the project management team
33
Version 1
Learner Guide

product-based planning approach

emphasis on dividing the project into manageable and controllable stages

flexibility that can be applied at a level appropriate to the project.
34
Version 1
Learner Guide
Despite the dissimilarities among them, all project management methods include these basic
elements:

A general set of rules for project administration and reporting;

The break-down of projects into phases, the so-called ‘project lifecycle’, and further
down into smaller manageable parts (typically consolidated into programs when
projects are very large, work-packages when they are large, and tasks when they are
small)

A definition of a statement of work for the project and a set of deliverables for each
task

Regular milestones, generally every 3 to 6 months, with a set of deliverables

A dedicated team (not necessarily full-time); and

A project quality plan (a set of pre-defined quality standards to be used during the life
of the project) which should precede all other project activities, except safety.
Currently, there is only one recognised project management standard developed initially by
the PMI and adopted by the Association of Electrical Engineers and published as IEEE Std 14901998. This standard is mostly used in the software development and electrical industries. The
ISO9000:2000 standard creates constraints for the project team that necessarily influence the
way projects are handled and organised. This standard has become so widely adopted that it
would not be wise to put in place any method of project management that does not fully
comply with it.
We will explore project management further using PMBOK as the basis for all project
management topics in this learner guide.
Project management terminology
Project life cycle
Phase
Stage
The Project Life Cycle refers to a series of activities which are
necessary to fulfil project goals or objectives.
A major logical grouping of work on a project. A phase also
represents the completion of a major deliverable or set of
related deliverables.
A project that is too large to be managed as one piece of work
is separated into more manageable sections. These sections
are called Stages in PRINCE 2. Alternatively terminology for a
stage is a ‘phase’.
Scope
Project scope is the part of project planning that involves
determining and documenting a list of specific project goals,
deliverables, tasks and deadlines.
Change control
Change control is a systematic approach to managing all
changes made to a product or system. The purpose is to ensure
35
Version 1
Learner Guide
that no unnecessary changes are made, that all changes are
documented, that services are not unnecessarily disrupted and
that resources are used efficiently. The change control process
is usually conducted as a sequence of steps proceeding from the
submission of a change request.
Procurement
Project procurement is the systematic process of identifying
and procuring goods and services for a project.
Scheduling
Project scheduling looks at which tasks need to be performed
for a project and assigns deadlines for their completion. The
project scheduler sets these deadlines by calculating how long
each task should take to perform. Scheduling requires a
comprehensive understanding of which action steps need to get
done and when.
Milestone
A milestone is an event that receives special attention. It is often
put at the end of a stage to mark the completion of a work
package or phase.
Deliverable
In project management, a deliverable is a product or service
that is given to your client. A deliverable usually has a due date
and is tangible, measurable and specific. A deliverable can be
given to either an external or internal customer and satisfies a
milestone or due date that is created and produced in the
project plan. A deliverable can be a software product, a design
document, a training program or other asset that is required by
the project plan.
Close out
The practice of project close-out finalises all project activities
completed across all phases of the project to formally close the
project and transfer the completed project to the client. During
this phase of the project lessons learned and best practices are
documented for use in future projects.
Project Management Software
MS Project, Agile, and Primavera are very popular project management software tools. MS
Project is by far the most widely used scheduling software while Agile has been developed for
the development of ERP systems. Among the top vendors we can name Artemis, Microsoft,
Pacific, Edge, PlanView, NIKU/ABT, PeopleSoft, Primavera, and ProSight.
Project management software provides:
Powerful Project Management Capabilities:
 Processes and guidance to manage projects in a consistent manner
 Powerful scheduling engine to keep project teams on track in meeting customer expectations
36
Version 1
Learner Guide

Reporting and issue tracking to improve decision making and performance’
Accurate Planning & Scheduling to Meet Customer Demands:
 Monitor the flow of work and the status of projects
 Provide teams with clear objectives and task assignments
 Share accurate and timely project information with all stakeholders
37
Version 1
Learner Guide
Resource Management:
 Resource Manager can evaluate resource
availability across projects throughout the
entire organisation
 Resource grouping and filtering to help
Resource Managers to find quickly
potential project team members
Make Better Business Decisions with Portfolio
Analysis Tools:
 Obtain comprehensive, real-time portfolio
data to make the right business decisions
 Compare current portfolio progress against
forecasted performance
 Identify trends over time to address
problem areas
2.2 The differences between project management and general management
Project management and general management overlap in many ways, but there are also
significant differences, as you will see below:

Functions
"Management" (from French ménagement "the directing", from Latin manu agere "to
lead by the hand") characterises the process of leading and directing all or part of an
organisation, often a business, through the deployment and manipulation of
resources (human, financial, material, intellectual or intangible). Early twentiethcentury management writer Mary Parker Follet defined management as "the art of
getting things done through people."
One can also think of management functionally, as the action of measuring a quantity
on a regular basis and of adjusting some initial plan, and as the actions taken to reach
one's intended goal. This applies even in situations where planning does not take
place. From this perspective, there are five management functions: planning,
organising, leading, coordinating and controlling.
Project management is quite often the province and responsibility of an individual
project manager. This individual seldom participates directly in the activities that
produce the end result, but rather strives to maintain the progress and productive
mutual interaction of various parties through the five management functions in such
a way that overall risk of failure is reduced.
38
Version 1
Learner Guide

Governance
Projects are typically governed by a simple management structure; for example, the
project manager is responsible for day-to-day direction, a senior IT executive
integrates technology with business interests, and a business sponsor is accountable
for ensuring that the deliverables align with business strategy.
Organisational governance is usually in the hands of a steering committee which
makes decisions that may eventually filter up to the board of directors. Organisationwide initiatives and programmes usually involve a more complex governing structure
because they involve fundamental business change and expenditures with significant
bottom-line impact. In fact, in some instances their outcomes determine whether the
enterprise will survive as a viable commercial/ governmental entity.

Management
Therefore, project management is the planning, organising, directing, and controlling
of company resources... for a relatively short-term objective.
It is clear from this definition that project management is concerned with the dynamic
allocation, utilisation, and direction of resources (both human and technical), with
time - in relation to both individual efforts and product delivery schedule - and with
costs, relating to both the acquisition and consumption of funding. As a corollary, it is
safe to say that without the direction project management provides, work would have
to proceed via a series of negotiations, and/or it would not align with the goals, value
proposition, or needs of the enterprise.
Within an organisation, these same responsibilities (i.e., allocation, utilisation, and
direction) are assigned to people at three levels in the management hierarchy; the
higher the level, the more general the responsibilities. For example, at the bottom of
the management hierarchy, project managers are assigned to the various projects
within the overall programme. Each manager carries out the management
responsibilities described above.
At the middle of the hierarchy is the programme manager/director, whose major
responsibility is to ensure that the work effort achieves the outcome specified in the
business strategies. This involves setting and reviewing objectives, coordinating
activities across projects, and overseeing the integration and reuse of interim work
products and results. This person spends more time and effort on integration
activities, negotiating changes in plans, and communicating than on the other project
management activities described above (allocating resources, ensuring adherence to
schedule, budget, etc.).
At the top of the management hierarchy are the program sponsor(s) and the program
steering committee. Their major responsibility is to own and oversee the
implementation of the underlying business strategies, and to define the connection
to the enterprise's overall business plan(s) and direction. Their management activities
include providing and interpreting policy, creating an environment that fosters
39
Version 1
Learner Guide
sustainable momentum (i.e. removing barriers both inside and outside the
enterprise), and periodically reviewing progress and interim results to ensure
alignment with the overall strategic vision. These individuals receive periodic
summary reports and briefings on funding consumption, resources and their
utilisation, and delivery of interim work products and results. Typically, they will focus
on these reports only if there is significant deviation from the plan.
Therefore, we can see that the executive leaders at the top of the hierarchy who set
goals and oversee the implementation of the organisation’s strategies certainly do not
perform the same detailed activities as project managers.
2.3 Relationship between project management processes and technical (end product
related) processes
Project management processes are those associated with the management of a project and
technical processes are those required to produce the required deliverables to satisfy the
objectives of the project.
Projects can be managed using a common set of project management processes. In fact, a
similar set of project management processes can be utilised regardless of the type of project.
For instance, all projects should be defined and planned and all projects should have processes
to manage scope, risk, quality, status, etc.
These processes are:

Initiating/ starting
The project starts with idea realisation through to the development and evaluation of
a business case and prioritisation of the potential project investments against the
objectives and other organisational priorities and resource constraints.

Planning
This stage is critical to successful resourcing and execution of the project activities and
it includes the development of the overall project structure, the activities and work
plan/ timeline that will form the basis of the project management process throughout
the project lifecycle.

Executing/ Implementing
The project activities are executed in terms of the project plan and project
organisation structure defined in the previous stage.

Controlling
The success and contribution of this effort are evaluated and there is a continual
review and reflection of project status and outstanding issues against the original
project business case.
40
Version 1
Learner Guide

Closing/ wrapping up
One of the key success criteria for continuous process improvement involves defining
a formal process for ending a project. This includes evaluating the successful aspects
of the project as well as identifying opportunities for improvement, identification of
project "best practices" that can be leveraged in future projects, and evaluating the
performance of project team members.
We can see that processes overlap and interact throughout a project or phase:
Technical processes are described in terms of:

Inputs (documents, plans, designs, procedures, etc.)

Tools and Techniques (mechanisms applied to inputs)

Outputs (documents, products, etc.)
During end-product or technical development the life cycle phases or processes are:

Planning

Information gathering

Design

Cost Trade-Off analysis

Prototyping

Modelling and Simulation

Measurement and Metrics
In the broadest sense of the term, all professions deal with technical information. For
example:

The structure, components, and behaviour of the human body form a highly technical
set of information studied by doctors.

The complexity of legal processes, precedents, and law is another set of technical
information required by lawyers.

The rules, procedures, and legal issues in business accounting provide another
example of technical information understood by accountants.
The distinction between technical and managerial information in a project is critical in
understanding project management.
To understand a project and manage a project, you must make a distinction between the
information dealing with the business aspects of a project and the information that
41
Version 1
Learner Guide
represents the technical issues such as the development technologies and deliverables that
are being developed in the project.
A technical manager would use his or her technical expertise to arrange various
benchmarking, referential integrity, efficiency, and other technical evaluations, undertaking
some of the more difficult technical tests him/herself.
A project manager would ask the team what skills and assistance the members need to make
the decision and arrange for the team members to get the help they need. In addition, the
project manager would evaluate the risks, costs, schedule, and impact on project objectives
of each option.
42
Version 1
Learner Guide
2.4 Role of the project team member and the project manager
Role of the project team member
Team members can come from many areas of the
organisation, or they can be outside consultants.
Depending on the nature of the project, they can fill
the following roles on the project:

Technical Managers (Leads*)

Functional Managers (Leads*)

Program analysts

Functional business analysts

Subject matter experts

Data delivery specialists

External consultants with in-depth knowledge of the product or process for
implementation

Trainers

Infrastructure experts, etc.
*
On larger projects, some project team members may serve as Team Leads, providing
task and technical leadership, and sometimes maintaining a portion of the project
plan.
To face the complex challenges of project work, we need to incorporate a wide range of styles,
skills, and perspectives. That is why cross-functional teams are formed, as they are regarded
as a means to manage social collaboration and concept creation.
A cross-functional team is a group of employees from various functional areas of the
organisation – research, engineering, marketing, finance, human resources, and operations,
for example – who are all focused on a specific objective, namely completing the project, and
are responsible to work as a team to improve coordination and innovation across divisions
and resolve mutual problems.
Some examples of cross-functional teams are teams established to work on projects, such as:

Designing and developing new products

Choosing and implementing new technologies throughout an organisation
The team members work in unison, supporting one another. The team, not the leader,
manages the project. Team members make adjustments to keep the deliverables on track;
they monitor progress and manage change. The team takes full ownership and accountability,
not only for the work to be done, but for the team dynamics as well. Team members monitor
progress and solve problems as they arise.
43
Version 1
Learner Guide
Each team member needs to know what function s/he fulfils in the team, how that role fits
with the other team members' functions and what happens if s/he doesn't do the job.
Everyone needs to realise that the team isn't only accountable to the project manager/ leader,
but also to one another, because if one person fails, the whole team fails. Meeting or missing
deadlines and deliverables is a team issue and should be exposed to the entire team. Each
member needs to feel accountable for his or her work and needs to experience the discomfort
of failure as well as the joy of success.
Depending on the industry or functional discipline, the project manager may employ standard
or customary team roles on the project. Standard roles are typical for certain types of projects,
but sometimes one would need to deviate from the standard and create a role, for example,
if a particular project warrants a role that is unique. Likewise, if a project doesn't require a
particular standard role, it can be eliminated. Results are always what matter most, not how
well a team adhered to the standard project role structure.
If a project is unique or the environment doesn't lend itself to standard or customary project
roles, the project manager can identify three to six aspects of the project that are most
important, or that pose the most risk and create roles that encompass the concerns or risk
areas. Then s/he needs to ensure that all major roles are defined correctly by cross-checking
the roles with the work that needs to be done.
Role of the project manager
The project manager is the person who has
the overall responsibility for the successful
planning and execution of any project. This
title is used in the construction industry,
architecture
and
many
different
occupations that are based on production
of a product or service.
The project manager must possess a
combination of skills, including an ability to
ask penetrating questions, detect unstated
assumptions and resolve interpersonal conflicts, as well as more general management skills.
Key amongst his/her duties is the recognition that risk directly impacts the likelihood of
success and that this risk must be both formally and informally measured throughout the
lifetime of the project.
Risk arises primarily from uncertainty and the successful project manager is the one who
focuses upon this as the main concern. Most of the issues that impact a project arise in one
way or another from risk. A good project manager can reduce risk significantly, often by
adhering to a policy of open communication, ensuring that every significant participant has an
opportunity to express opinions and concerns.
It follows from the above that the project manager is the one who is responsible for making
decisions, both small and large, in such a way that risk is controlled and uncertainty minimised.
44
Version 1
Learner Guide
Every decision taken by the project manager should be taken in such a way that it directly
benefits the project.

Responsibility for the project
The definition of responsibility in the Concise Oxford English Dictionary is “authority; the
ability to act independently and make decisions.” This is, in effect, the first criterion of a
project manager: can s/he independently make decisions regarding the project, without
recourse to a higher authority? Within the overall envelope of approved time, cost and
scope, does s/he have the freedom to make decisions? Can s/he change strategy,
approach or activity definitions to accomplish the same results within the same
window? The answers to these questions will depend on size, type and complexity of
the project.

Accountability for project results
The next attribute that defines a project manager is accountability for the results of the
project. The project manager is the person who is accountable to either the owner or
sponsor of the project for delivery of the overall results of the project. This may or may
not equate with the delivery of the full business case of the project--for many systems
projects, for example, management of the organisational change associated with the
results of a project may not be within the scope of responsibility of the project team.
Whatever is within scope, however, must be clearly defined and measurable, and the
project manager must be fully accountable for the delivery of those results.

Authority to execute the project to get the results
Finally, the key attribute of project management is the authority to execute the project
in order to realise the intended results. Authority can be defined as “the power to
enforce or influence behaviours or actions.” In essence, project management requires
being able to influence or enforce the behaviours that are necessary to attain the results
for which one is being held accountable.
While the project manager may have the responsibility to make decisions inside the
project, and the accountability for the results of the project, s/he must also have the
ability on behalf of the organisation to ensure availability of resources and require the
changes of behaviours that are necessary. While authority can take many forms,
whether it is derived from position, expertise or influence in an organisation, it must be
assumed that the project manager is expected and permitted to exercise this power in
order to realise the end goals of the project.
Based upon these attributes, a reasonable definition of project management is “The exercise
of responsibility and decision-making about a project, the authority to execute within the
boundaries of the project, and the accountability to deliver the results of a project in the
context of agreed-upon customer expectations, commitments and constraints.”
2.5 Stakeholders, roles and responsibilities
A stakeholder is everybody who is involved in a project or whose work or interest might be
affected by a project.
45
Version 1
Learner Guide
Stakeholders may have varied levels of interest, involvement, and influence on the project. It
is extremely important to identify all the stakeholders and manage them as they can have
either a negative or a positive influence on the project.
It is also important to have a defined formal structure for the project and for the project staff.
This provides each individual with a clear understanding of the authority given and
responsibility necessary for the successful accomplishment of project activities. Project team
members need to be accountable for the effective performance of their assignments and
achievement of the project goals and objectives.
The roles and responsibilities of project participants will vary. The requirements placed on
participants will be determined and defined during the project planning process phase,
however, the following is a good “rule of thumb” perspective:

On a large project, individual role assignments may require full-time attention to the
function.

On smaller projects, role assignments may be performed part-time, with staff sharing
in the execution of multiple functions.
Tasking and individual responsibilities are often covered in the Organisational Breakdown
Structure as activity assignments are defined during the planning phase. Typically these
assignments are shorter term and exist only to the completion of the activity deliverable.
Here are some common project stakeholders and their roles along with a brief explanation of
each7:
Role
Explanation
Project sponsor
The person who saw a need for change and had the authority to make
something happen. There may be several sponsors who collectively have
this role. It may be that even higher authority and support is required
such that others should also be drawn into this role.
Supporting Sponsors
To succeed in all aspects of the project in all parts of the organisation it
may be necessary to establish many supporting sponsors at different
levels and in different organisational units.
Project Director
The person with genuine executive authority over the project. The Project
Director has full accountability and responsibility for the project's success,
and has the power to make all decisions, subject to oversight by the
executive bodies.
Executive Committee
A body of people representing the overall executive authority of the
organisation. This might, indeed, be the Board of Directors, or it could be
a delegated sub-committee of the Board
7Retrieved
from: http://www.epmbook.com/structure.htm
46
Version 1
Learner Guide
Role
Explanation
Steering Committee or
Project Board
The group of people charged with regular oversight of the project.
Collectively they should represent all significant areas of participation in
the project and they should have authority to take decisions on behalf of
those areas. Members would typically be departmental heads, Vice
Presidents, or Directors, along with external representatives. The Project
Director and Project Manager would normally report to the Steering
Committee.
Project Manager
The person with day-to-day responsibility for the conduct and success of
the project. The Project Manager would normally have control over all
project resources.
Project office
manager/staff
The "Project Office" provides supporting shared services to the Project
Manager and to the overall Project Team. Often this function has a
manager plus support staff. Typical responsibilities include controlling and
tracking the detailed plan, managing documentation, preparing reports,
etc. It may also be the place to house part-time specialists supporting the
team, for example, a Training Designer.
Project Accountant
A large project may require its own accountant to deal with procurement,
sub-contractor expenditure, joint venture accounting, progress tracking
and financial reporting, etc.
Team Leader
Typically the project will be divided into various sub-teams - each with its
own Team Leader. Team Leaders would be responsible for the
management and coaching of that sub-team. They may also have
responsibility for managing and tracking the detailed sub-plan for their
team.
Organisational Change
Manager / Facilitator
A specialist in identifying issues, requirements and solutions regarding
organisational change, i.e. corporate or individual rational, political and
emotional factors in bringing about the desired business change.
Communications
Specialist
A specialist in communicating messages within the organisation. There
will normally be a range of communications media that the project should
exploit in achieving its goals.
Business Process
Reengineering
Specialist
A specialist in the process and techniques of re-engineering business
processes to gain optimum performance.
Process Owner
The person within the organisation with overall control, authority, and
accountability for any given business process.
Process Specialist
An expert in best practice solutions for a given business process.
Process Manager
A manager within the organisation with detailed understanding and
experience of how a given process operates.
Process Modeller
A specialist in modelling business processes such that potential
improvements can be defined and quantified.
Solution Architect
A specialist in defining overall business solutions with responsibility for
the "big picture".
47
Version 1
Learner Guide
Role
Explanation
Technical Architect
A specialist in defining technical components of a business solution with
responsibility for the technical architecture of the solution.
Organisational Design
Specialist
A specialist in the assessment of resourcing needs and capability levels,
plus the design and achievement of the revised resourcing and
organisational structure.
Solution Designer
A specialist in the detailed design of solution components. There will, in
fact, be many different types of specialists in this category as each needs
to be a specialist in the aspect of the solution they design, e.g. database
designer, website designer, program designer, procedure designer, etc.
Developer
A specialist in the creation of solution components. Again, there will be
different types of developer depending upon what is being developed.
Network and
Telecommunications
Specialist
A specialist in the design and construction of networking and
telecommunications. They would deal with internal and external
networking issues, such as architecture, hardware, capacity/bandwidth,
etc.
Marketing Specialist
A specialist in marketing. Where the solution has an external element, it
is important to consider how to make it attractive to the external people
and bodies concerned.
Training Specialist
A specialist in identifying training needs then designing training
approaches and content to meet those needs.
Training Developer
A specialist in the development of training materials.
Trainer/ Facilitator
A person with the skills and knowledge required to deliver training
content.
Documenter /
Technical Writer
A specialist in the creation of accurate, usable documentation - both for
the day-to-day use of the solution and as design documentation for future
reference. Documentation in modern solutions will normally be
supported electronically, e.g. using workflow software and contextsensitive help information.
End User
End users form valuable resources in the team - they can be used for
many purposes related to the design, construction and delivery of the
business solution. As former members of the team they will return to
their departments as experts and coaches for the new solution.
Computer Operations
Analyst / Staff
A specialist in the way the live technical solution should be operated.
Operating procedures would include routine operations, controls,
security, backup/recovery, disaster plans, etc.
Facilities Manager /
Staff
The people responsible for the provision of appropriate accommodation
for the revised organisation to perform the new processes. This may be
simply some adjustment of existing facilities or it might amount to the
acquisition and construction of entire new facilities.
Lawyer / Legal Adviser
A legal specialist who would deal with various contractual matters such as
detailed contracts for the provision of equipment or services.
48
Version 1
Learner Guide
Role
Explanation
External Auditor
The external accountants who are responsible for the audit of the
organisation. They may need to review the plans, designs and completed
solution to ensure it meets an adequate standard from an audit
perspective.
Internal Auditor
An employee of the organisation charged with responsibility within the
organisation for maintaining standards and procedures.
External Regulator
Many industries and organisations are subject to various forms of
regulation by external regulators. There may be a need to co-operate with
these regulators or to maintain specific records or information to meet
their requirements.
Quality manager
A person responsible for processes and procedures that ensure required
levels of quality are achieved.
Quality auditor
A person responsible for the Quality Audit – i.e. checklist adherence to
declared procedures and deliverables.
A successful project requires that the project team have the authority to complete a project,
be participants (at some level) in the planning process, have ownership and buy-in to the
project plan, and be responsible and accountable for completion of the project.
2.6 Project stakeholders: Roles, needs and expectations
Projects are strongly stakeholder-driven. It’s their wishes, fears, dreams,
their “stakes” that determine and drive the course of projects. For
successful projects, it’s not enough to deliver on the customer’s demand;
projects have to meet all stakeholder expectations.
Identifying stakeholders is a primary task because all the important
decisions during the initiation, planning and execution stages of the
project are made by these stakeholders.
Stakeholders and how they interact with the project
Project stakeholders are individuals and organisations that are actively involved in the project,
or whose interests may be affected as a result of project execution or project completion.
Stakeholders may also exert influence over the project’s objectives and outcomes.
The project management team must identify the stakeholders, determine their requirements
and expectations, and, to the extent possible, manage their influence in relation to the
requirements to ensure a successful project. The figure below illustrates the relationship
between stakeholders and the project team.
49
Version 1
Learner Guide
The Relationship between Stakeholders and the Project Team
A stakeholder can be a project team member, an employee of the user organisation, or a
senior manager; anyone who has an interest in the project.
The following are examples of project stakeholders8 :

8
Project leader (or project manager) – The person responsible for managing the
project; the head of the project; defines, plans, controls, and leads the project

Project team members – The group that is performing the work of the project; they
produce the outputs (deliverables) for the project; participate in the project
management process; contribute their skills and effort to perform tasks

Sponsor (or upper manager) – The person or group that provides the financial
resources, in cash or in kind, for the project; the person with formal authority who is
ultimately responsible for the project; oversees the project; acts as a liaison between
the upper management team and the project leader; provides authority, guidance,
and maintains project priority

Project customer – The person or organisation that will use the project’s product;
the person or group whose needs and requirements drive the project; receives the
final output(s) that the project produces; provides product requirements and
funding. There may be multiple layers of customers. For example, the customers for
a new pharmaceutical product can include the doctors who prescribe it, the patients
who take it and the insurers who pay for it. In some application areas, customer and
user are synonymous, while in others, customer refers to the entity acquiring the
project’s product and users are those who will directly utilise the project’s product.

Functional managers (also known as resource managers or line managers) – provide
company policy an resources, particularly people who are involved in the project
Retrieved from "http://en.wikipedia.org/wiki/Project_stakeholders"
50
Version 1
Learner Guide

Performing organisation. The enterprise whose employees are most directly involved
in doing the work of the project.

Project management team. The members of the project team who are directly
involved in project management activities.

Influencers. People or groups that are not directly related to the acquisition or use of
the project’s product, but due to an individual’s position in the customer organisation
or performing organisation, can influence, positively or negatively, the course of the
project.
In addition to these key stakeholders, there are many different names and categories of project
stakeholders, including internal and external, owners and investors, sellers and contractors,
team members and their families, government agencies and media outlets, individual citizens,
temporary or permanent lobbying organisations, and society-at-large. The naming or grouping
of stakeholders is primarily an aid to identifying which individuals and organisations view
themselves as stakeholders. Stakeholder roles and responsibilities can overlap, such as when
an engineering firm provides financing for a plant that it is designing.
Stakeholders have varying levels of responsibility and authority when participating on a project
and these can change over the course of the project’s life cycle. Their responsibility and
authority range from occasional contributions in surveys and focus groups to full project
sponsorship, which includes providing financial and political support. Stakeholders who ignore
this responsibility can have a damaging impact on the project objectives. Likewise, project
managers who ignore stakeholders can expect a damaging impact on project outcomes.
The stakes are the wants or needs of the holders. They stick to them; they defend them; they
are married to them. The stakeholders will take all actions necessary to defend their stakes,
or to get as near to their realisation as possible.
Stakes can be two-fold: they can either relate to stakeholder fears or wishes. With the former,
there is something to lose; with the latter, there is something to gain. Either way, stakes are
important to the stakeholders and no-one, not even the project manager, should ignore or
underestimate them.
Therefore, the project management team must identify the stakeholders, determine their
requirements and expectations, and, as far as possible, manage their influence in relation to
the requirements to ensure a successful project.
In order to identify and accommodate the stakeholders’ requirements, as well as the
constraints of the project, the project manager needs to be an excellent negotiator, as well as
understand human nature, as it’s not always clear what the stakes are.
Sometimes stakeholders communicate them directly; often they don’t. The level of
communication is indirect; stakes are contained in the requirements of the project, process
and products. Requirements are always a clearly-defined statement of a desired outcome.
This is often in contrast with stakes, which are generally vague and abstractly formulated (if
formulated at all). For example: A stakeholder formulates a requirement for a software
project; e.g. senior management states that “the project should be finished before the end of
51
Version 1
Learner Guide
August.” The project manager has to comply. When this deadline is no problem, he can rest
assured. However, it’s a software project, so as we know from our previous unit standard
(120372) the deadline will invariably be a problem. The way to handle it is to get some
information on the stakes that caused the stakeholder to formulate this requirement. Perhaps
it’s a case of, “I don’t want to lose face when my projects get delayed.” If that is the case, the
project manager can offer alternatives that don’t violate that stake, like keeping the deadline,
but postponing a subsystem or strand. The stakeholder could possibly accept alternatives that
support his/her stakes or wants; with some persuasion from the project manager, of course.
In order to have a successful project, a project manager should respect the flow of the stakes,
as illustrated in the diagram9 below, and must ensure that stakes go “full cycle”.

Stakeholders have stakes

Stakeholders communicate their stakes by means of requirements to the process or
the product

Project management should make every stakeholder a winner by accepting and
inventing requirements that keep satisfying the stakes of individual stakeholders and
are not conflicting with the general process and product

Project management should give continuous feedback on the state of the stakes

Based upon the feedback, the requirements might change. In this way, a new cycle
starts.
2.6.1 Identify Project Stakeholders
“Stakeholder management is critical to the success of every project in every organisation I have
ever worked with. By engaging the right people in the right way in your project, you can make
a big difference to its success... and to your career.”
9Retrieved
from: http://www.softwareprojects.org/project_management_end18.htm
52
Version 1
Learner Guide
Experienced Project Manager10,
One technique for dealing effectively with the project’s external environment is to prioritise
the required stakeholder linkages by conducting a stakeholder analysis. Such an analysis
would be designed first to identify all the potential stakeholders who might have an impact
on the project, and then to determine their relative ability to influence it.
As you become more successful in your career, the actions you take and the projects you run
will affect more and more people. The more people you affect, the more likely it is that your
actions will impact people who have power and influence over your projects. These people
could be strong supporters of your work – or they could block it.
Stakeholder Management is an important discipline that successful people use to win support
from others. It helps them ensure that their projects succeed where others fail. Stakeholder
Analysis is the technique used to identify the key people who have to be won over. You then
use Stakeholder Planning to build the support that helps you succeed.
The benefits of using a stakeholder-based approach are:

You can use the opinions of the most powerful stakeholders to shape your projects at
an early stage. Not only does this make it more likely that they will support you, their
input can also improve the quality of your project

Gaining support from powerful stakeholders can help you to win more resources – this
makes it more likely that your projects will be successful

By communicating with stakeholders early and frequently, you can ensure that they
fully understand what you are doing and understand the benefits of your project – this
means they can support you actively when necessary

You can anticipate what people’s reaction to your project may be, and build into your
plan the actions that will win people’s support.
The first step in Stakeholder Analysis is to identify who your stakeholders are. The next step is
to work out their power, influence and interest, so you know on whom you should focus. The
final step is to develop a good understanding of the most important stakeholders so that you
know how they are likely to respond, and so that you can work out how to win their support
– you can record this analysis on a stakeholder map. After you have created a stakeholder
map, you can plan how you will communicate with each stakeholder.
The steps of Stakeholder Analysis are explained below:
Step 1: Identify Your Stakeholders
The first step in your stakeholder analysis is to brainstorm who your stakeholders are. As part
of this, think of all the people who are affected by your work, who have influence or power
over it, or have an interest in its successful or unsuccessful conclusion.
Stakeholders may have a positive or negative influence on a project. Positive stakeholders are
those who would normally benefit from a successful outcome from the project, while negative
10Retrieved
from http://www.mindtools.com/pages/article/newPPM_07.htm
53
Version 1
Learner Guide
stakeholders are those who see negative outcomes from the project’s success. For example,
business leaders from a community that will benefit from an industrial expansion project may
be positive stakeholders because they see economic benefit to the community from the
project’s success. Conversely, environmental groups could be negative stakeholders if they
view the project as doing harm to the environment. In the case of positive stakeholders, their
interests are best served by helping the project succeed, for example, helping the project
obtain the needed permits to proceed. The negative stakeholders’ interest would be better
served by impeding the project’s progress by demanding more extensive environmental
reviews. Negative stakeholders are often overlooked by the project team at the risk of failing
to bring their projects to a successful end.
54
Version 1
Learner Guide
Stakeholders can also have very different or conflicting objectives. For example:

The manager of a department that has requested a new management information
system may desire low cost, the system architect may emphasise technical excellence,
and the programming contractor may be most interested in maximising its profit.

The vice president of research at an electronics firm may define new product success
as state-of-the-art technology, the vice president of manufacturing may define it as
world-class practices, and the vice president of marketing may be primarily concerned
with the number of new features.

The owner of a real estate development project may be focused on timely
performance, the local governing body may desire to maximise tax revenue, an
environmental group may wish to minimise adverse environmental impacts, and
nearby residents may hope to relocate the project.
The table below shows some of the people who might be stakeholders in your projects:
Your manager
Senior executives
Your co-workers
Your team
Customers
Prospective customers
Shareholders
Alliance partners
Suppliers
Lenders
Analysts
Future recruits
Government
Trade associations
The press
Interest groups
The public
The community
Remember that although stakeholders may be both organisations and people, ultimately you
must communicate with people. Make sure that you identify the correct individual
stakeholders within a stakeholder organisation.
Step 2: Prioritise Your Stakeholders
You may now have a long list of people and organisations that are affected by your work. Some
of these may have the power either to block or advance. Some may be interested in what you
are doing; others may not care.
Map out your stakeholders on a Power/Interest Grid as shown in figure 111, and classify them
by their power over your work and by their interest in your work.
11
Retrieved from http://www.mindtools.com/pages/article/newPPM_07.htm
55
Version 1
Learner Guide
For example, your manager is likely to have high power and influence over your projects and
high interest. Your family may have high interest, but are unlikely to have power over it.
Someone’s position on the grid shows you the actions you have to take with them:

High power, interested people: these are the people you must fully engage and make
the greatest efforts to satisfy

High power, less interested people: put enough work in with these people to keep
them satisfied, but not so much that they become bored with your message

Low power, interested people: keep these people adequately informed, and talk to
them to ensure that no major issues are arising. These people can often be very helpful
with the detail of your project

Low power, less interested people: again, monitor these people, but do not bore
them with excessive communication.
Also bear in mind that the stakeholders’ influence wanes as the project nears completion. The
ability of the stakeholders to influence the final characteristics of the project’s product and
the final cost of the project is highest at the start, and gets progressively lower as the project
continues. The figure below illustrates this. A major contributor to this phenomenon is that
the cost of changes and correcting errors generally increases as the project continues.
56
Version 1
Learner Guide
Stakeholders’ Influence over Time
Step 3: Understand your key stakeholders
You now need to know more about your key stakeholders. You need to know how they are
likely to feel about and react to your project. You also need to know how best to engage them
in your project and how best to communicate with them.
Key questions that can help you understand your stakeholders are:

What financial or emotional interest do they have in the outcome of your work? Is it
positive or negative?

What motivates them most of all?

What information do they want from you?

How do they want to receive information from you? What is the best way of
communicating your message to them?

What is their current opinion of your work? Is it based on good information?

Who influences their opinions generally, and who influences their opinion of you? Do
some of these influencers therefore become important stakeholders in their own
right?

If they are not likely to be positive, what will win them around to support your project?

If you don’t think you will be able to win them around, how will you manage their
opposition?

Who else might be influenced by their opinions? Do these people become
stakeholders in their own right?
57
Version 1
Learner Guide
A very good way of answering these questions is to talk to your stakeholders directly – people
are often quite open about their views, and asking people’s opinions is often the first step in
building a successful relationship with them.
You can summarise the understanding you have gained on the stakeholder map, so that you
can easily see which stakeholders are expected to be blockers or critics, and which
stakeholders are likely to be advocates and supporters or your project. A good way of doing
this is by colour coding: showing advocates and supporters in green, blockers and critics in
red, and others who are neutral in orange.
Figure 212 shows an example of this – in this example, you can see that a lot of effort needs to
be put into persuading Piers and Michael of the benefits of the project – Janet and Amanda
also need to be managed well as powerful supporters.
Conduct a full stakeholder analysis. Ask yourself whether you are communicating as
effectively as you should be with your stakeholders. What actions can you take to get more
from your supporters or win over your critics?

Stakeholder Groupings
Project stakeholders may be recognised in any of the following groupings:
12
-
Those who are directly related to the project, for example suppliers of inputs,
consumers of outputs, and managers of the project process
-
Those who have influence over the physical, infra-structural, technological,
commercial/ financial/ socioeconomic, or political/legal conditions
Retrieved from http://www.mindtools.com/pages/article/newPPM_07.htm
58
Version 1
Learner Guide

-
Those who have a hierarchical relationship to the project, such as government
authorities at local, regional and national levels
-
Those individuals, groups and associations, who have vested interests, sometimes
quite unrelated to the project, but who see it as an opportunity to pursue their
own ends.
Stakeholder Categories
Having identified the various stakeholders, each may be assigned to a category
according to their relative ability to influence the project. Three categories are
envisaged, namely:
-
Those who are controllable
-
Those who can be influenced
-
Those who need to be appreciated
Within each category, each stakeholder may then be further rated by degree of
importance according to their ability to influence the project. Appropriate members
of the project team can then prioritise their efforts accordingly to maintain the
necessary stakeholder linkages, and thus give rise to the best chances of ultimate
project success. If the project is large enough, or the stakeholder linkages are
sufficiently intense, the project team’s efforts may be assigned to a specific group
within the project team.
Having conducted a Stakeholder Analysis, you now have most of the information you need to
plan how to manage communication with your stakeholders.
2.6.2 Verify project deliverables against the needs of stakeholders
The purpose of the Stakeholder analysis is to determine the needs and expectations of the
stakeholders
It is the project manager’s responsibility to identify all the stakeholders and determine their
needs and expectations. These needs and expectations should then be managed, influenced
and balanced, to ensure project success.
Any differences between the stakeholders should be resolved in favour of the client and
customers, but not necessarily at the expense of the other stakeholders. It is the project
manager’s responsibility to build favourable relationships among the various stakeholders.
59
Version 1
Learner Guide
What do stakeholders want and need from your project?

Some stakeholders simply need to feel appreciated throughout the project process

Some stakeholders outline specific requirements they want the project to meet. The
project team can advise the stakeholders if their requirements for a project are not
going to be completely fulfilled

Some stakeholders have specific requirements they want the project to meet, and
their stake in the project is large enough that the project team should strive to meet
their needs under most circumstances
Let’s take the example of a product you are creating for a client. The client’s needs will be the
following:

The product must operate in a specific environment

The product must have a working life of so many years

The project must meet certain specifications and standards

The product must meet statutory health and safety regulations

Ease of maintenance and repair must be incorporated into the design

The product must provide opportunities for further expansion

The project must be operational by a predefined date

The end product must be marketable and profitable
You have now identified the stakeholders in your project, and will have marked out their
positions on a stakeholder map. The next stage is to plan your communication so that you can
win them around to support your project. Stakeholder Planning is the process by which you
do this.
To carry out a Stakeholder Planning exercise, use a table13 like the one below:
Stakeholder
Name
13
Communicati
ons
Approach
(from Power/
Interest
Grid)¹
Key Interests
and Issues
Current
Status²
Desired
Support³
Desired
Project Role
(if any)
Actions
Desired (if
any)
Messages
Needed
Actions and
Communicati
ons
Retrieved and adapted from http://www.mindtools.com/pages/article/newPPM_07.htm
60
Version 1
Learner Guide
1. Manage closely/ Keep satisfied/ Keep informed/ Monitor
2. Advocate/ Supporter/ Neutral/ Critic/ Blocker
3. High/ Medium/ Low
Using this table, work through the planning exercise using the steps below:
Step 1: Update the worksheet with Power/Interest Grid information
Based on the Power/Interest Grid you created in your stakeholder analysis, enter the
stakeholders’ names, their influence and interest in your job or project, and your current
assessment of where they stand with respect to it.
Step 2: Plan your approach to Stakeholder Management
The amount of time you should allocate to Stakeholder Management depends on the size and
difficulty of your projects and goals, the time you have available for communication, and the
amount of help you need to achieve the results you want.
Think through the help you need, the amount of time that will be taken to manage this and
the time you will need for communication. Help with the project could include sponsorship of
the project, advice and expert input, reviews of material to increase quality, etc.
Step 3: Decide what you want from each stakeholder
Next, work through your list of stakeholders, thinking through the levels of support you want
from them and the roles you would like them to play (if any). Think through the actions you
would like them to perform. Write this information down in the ‘Desired Support’, ‘Desired
Project Role’ and ‘Actions Desired’ columns.
Step 4: Identify the messages you need to convey
Next, identify the messages that you need to convey to your stakeholders to persuade them
to support you and engage with your projects or goals. Typical messages will show the benefits
to the person or organisation of what you are doing, and will focus on key performance drivers
like increasing profitability or delivering real improvements.
Step 5: Identify Actions and Communications
Finally, work out what you need to do to win and manage the support of these stakeholders.
With the time and resources you have available, identify how you will manage the
communication to and the input from your stakeholders.
Focusing on the high-power/high-interest stakeholders first and the low-interest/low-power
stakeholders last, devise a practical plan that communicates with people as effectively as
possible and that communicates the right amount of information in a way that neither undernor over-communicates.
61
Version 1
Learner Guide
Think through what you need to do to keep your best supporters engaged and on-board. Work
out how to win over or neutralise the opposition of sceptics. Where you need the active
support of people who are not currently interested in what you are doing, think about how
you can engage them and raise their level of interest. Also, consider how what you are doing
will affect your stakeholders. Where appropriate, let people know as early as possible of any
difficult issues that may arise, and discuss with them how you can minimise or manage any
impact. Manage people’s expectations about likely problems as early as possible. This gives
them time to think through how to manage issues, and preserves your reputation for
reliability.
Once you have prepared your Stakeholder Plan, all you need to do is to implement it. As with
all plans, it will be easier to implement if you break it down into a series of small, achievable
steps and action these one-by-one.
2.6.3 Document approved modifications to stakeholder needs and communicate them to
relevant parties
Stakeholders might want to suggest enhancements to the product your project is going to
deliver. Such enhancement requests can be submitted by anyone (end users, customers, team
members, etc.), and are usually formulated in the submitter’s language.
In order to formalise these stakeholders’ needs, their requests for enhancements must be
documented in the team-developed common vocabulary, ensuring that all members of the
team have the same understanding of the need.
Enhancement requests must be analysed and approved by the appropriate authority role, who
determines their impact to the project, and assigns one of the following states to the
enhancement request:

Rejected if the enhancement request will not be considered;

Open if the enhancement request will be considered.
Documented Requirements must conform to a set of stringent criteria: compliant with the
project business case, correct, complete, verifiable, modifiable, understandable, traceable,
and unambiguous.
Requirements may represent a contractual obligation for the team to deliver functionality.
Customers must sign off on requirements documents and the new requirements must be
communicated to the relevant parties.
Class Activity 2: The Nature of Project Management
In small groups or individually as per your facilitator’s instructions, complete
the formative activities in your Workbook
62
Version 1
Learner Guide
Module 3
Structures in the project environment
After completing this module, the learner will be able to explain the types of structures that
are found in a project environment, by successfully completing the following:

Explain the reasons for defining structures for a project with examples

Explain the concept of programme and project hierarchies with an example

Explain the purpose of decomposing a project into manageable components or parts
with practical examples

Explain the concepts of breakdown structures for product, work and cost in simple
terms
63
Version 1
Learner Guide
Structures in the project environment
A structure refers to a set of interconnecting parts of any complex thing. It is a framework or
outline that defines how the work will be done on the project.
The main function of the project structure is to define standards and processes the team will
use during the project.
In this Module we will learn more about the different project structures.
3.1 Reasons for defining structures for a project
Running a project without a plan is foolish. It is like trying to find your way in a strange city
without a map. Working without knowing where you are going and how you are going to get
there is likely to lead to problems and possible failure: "If you fail to plan, you are planning to
fail."
Projects deliver outputs/ deliverables/ products. These outputs blend together over time to
deliver outcomes. For a project to be effectively planned and controlled, i.e. managed, it needs
to be broken down (decomposed) into a detailed and measurable plan of the management
and control processes involved in the completion of the project; i.e. its structure. The structure
can therefore be defined as a set of interconnecting parts of a complex thing, a framework.
In the next sections we will look at the structures present in a project, namely:

programme to sub project hierarchy;

organisation structures;

product /work/cost/organisation breakdowns
3.2 Programme and project hierarchies
Programme
A Programme is a collection of Projects and other items of work managed coherently together
as a portfolio.
There are several types of Programmes, such as:

A Change Programme is a group of Projects and other items of work managed
coherently together. The change Programme must have a clear strategic vision and be
concerned with delivering big and important outcomes, while managing complex
change. Change management can be thought of as a giant Project containing a
number of smaller Projects. All change Programmes have a work Programme element
to them because they will need to manage priorities and move resources between
Projects.

A Work Programme is a group of initiatives which may or may not be related, but
which have to be co-ordinated because they call on the same pool of resources.
64
Version 1
Learner Guide

A Policy Programme is a change Programme that is focused on making societal
changes, i.e. changing things in society, or the community outside the organisation.
Programmes are responsible for delivering outcomes and ensuring that the strategy remains
coherent and relevant.
In structuring Programmes, you need to maintain a balance between empowering the
individuals tasked with activities, and the overall co-ordination and control necessary to
ensure that the outcomes will be delivered.
Programmes are normally broken down into a set of composite Sub-Programmes, Projects,
and/ or Work Strands:
Sub-Programmes
A Sub-Programme is a semi-autonomous set of activities. It is responsible for a set of
outcomes. It is also possible that it will be responsible for a set of key Deliverables, which will
be delivered by its component Projects. Groups of Projects that have a high degree of interconnectivity would benefit from being managed as a group or Sub-Programme, minimising
cross talk and sharing common outcomes.
Project
A Project is a temporary organisation, either as a free-standing entity or more commonly as
an integrated component of a Programme, set up to produce something or manage a
particular change. Projects are responsible for producing outputs that cause outcomes to be
achieved. Both Programmes and Projects can be temporary; however, most Programmes span
over a longer period of time than Projects.
Strands / Work Strands
A Strand is a mini Project within a Programme (or Project). Because of its size, it may not have
a separate Strand (i.e. ‘Project’) brief, but it will usually have its own risk and issue registers. A
strand might also be a specific big piece of work that is very closely linked to the Programme
(or Project) and that, by being a strand, allows the close link to be maintained and the
dependencies within the Programme (or Project) managed more effectively, whilst allowing
some autonomy for the Strand leader.
Programme and project hierarchies
A hierarchy (in Greek hieros: sacred, and arkho: rule) is a system of ranking and organising
things. A tree structure is a way of representing the hierarchical nature of a structure in a
graphical form. It is named a "tree structure" because the graph looks a bit like a tree, even
though the tree is generally shown upside down compared with a real tree; that is to say, with
the root at the top and the leaves at the bottom.
65
Version 1
Learner Guide
Illustration: A tree structure showing the possible hierarchical organisation of an encyclopaedia.14.
The lines connecting elements are called "branches," the elements themselves are called
"nodes."
The names of relationships between nodes are modelled after family relations:

The starting node is often called the "root."

A node is a "parent" of another node if it is one step higher in the hierarchy and
closer to the root node.

"Sibling" ("brother" or "sister") nodes share the same parent node.

A node that is connected to all lower-level nodes is called an "ancestor."
In the example, "encyclopaedia" is the parent of "science" and "culture," its children. "Art"
and "craft" are siblings, and children of "culture." Nodes without children are called "endnodes" or "leaves."
The activities and tasks required to complete a project, as well as their ranking in terms of
importance and relationship to one another can be depicted in a tree structure. Elements
within a project can be seen by parent (those above themselves in the tree), sibling and child
(those at the same or lower level than themselves).
3.3 Structures for work, product and cost breakdown
Work Breakdown Structure (WBS)
In order to identify the individual tasks in a project, it is useful to create a Work Breakdown
Structure. The WBS is the foundation for the detailed project plan. The purpose of a WBS is to
decompose the project into steps and sub-steps.
In project management, a Work Breakdown Structure (WBS) is an exhaustive, hierarchical
(from general to specific) tree structure of deliverables and tasks that need to be performed
to complete a project.
14
Retrieved from Wikipediahttp://en.wikipedia.org/wiki/Tree_structure
66
Version 1
Learner Guide
Its hierarchical arrangement allows for easy identification of the terminal elements (the actual
items to be done in a project).
Being an exhaustive document of the project scope, the WBS serves as the basis for much of
project planning. All the work to be done in a project must trace its origin from one or more
WBS entries. The Work Breakdown Structure is a very common and critical project
management tool.
One could list the activities required to complete a project, in the example below painting a
room, as follows:

Prepare materials
o Buy paint
o Buy a ladder
o Buy brushes/rollers

Prepare room
o Remove detachable decorations
o Cover floor with old newspapers
o Cover electrical outlets/switches with tape
o Cover furniture with sheets

Paint the room
67
Version 1
Learner Guide

Clean up the room
o Dispose or store left over paint
o Clean brushes/rollers
o Dispose of old newspapers
o Remove covers
Product Breakdown Structure
In project management, a Product Breakdown Structure (PBS) is an exhaustive, hierarchical
tree structure of components that make up a project deliverable. It is a product-oriented
"family tree" of project components, which organises and defines the total scope of the Project
A PBS can help clarify what is to be delivered by the project and can help build a Work
Breakdown Structure.
Each descending level represents an increasingly detailed definition of a project component.
Project components may be either products or services. As part of compiling a PBS, one can
draw up a product flow diagram.
Note that the Product Flow Diagram below:

Shows the relationship of products from different parts of the Product Breakdown
Structure

Indicates potential key points in the project plan

Demonstrates the relevance of products to the project and can identify products not
previously identified For instance, if a product cannot readily be linked to a
subsequent product it could be an indication either of a missing product in the flow
or that the product itself is not necessary to the project
Let’s decompose one of the nodes, namely Management Products, further:
68
Version 1
Learner Guide
Product Breakdown Structure: Management Products
From this breakdown, one can also see which products are required at which stage of the
project.
Cost Breakdown Structure
A CBS is a system for dividing a project into Cost categories. It is a hierarchical structure that
deconstructs budgeted resources into elements of costs, such as labour, materials and other
direct costs.
Cost can also be divided into internal and external expenses. External costs can
be controlled by contracts and budgets for each phase of a project and for each
deliverable or work product. Internal cost is the cost of project resources.
Costs, along with payables and receivables information, allow you to put
together a financial picture of your project, so that you can review and compare costs
regularly. By product, costs determine where you are spending your money. Labour costs can
be compartmentalised by employee grade. Department costs show where your greatest
investments in assets are located. You can even segregate costs by customer or job order.
Indeed, you want to be able to monitor the actual procurement and production of a project
against an estimate. You would like to sum up material, labour, overhead, subcontract and
other direct charges for each individual project and compare these costs against your total
estimate for the project. Then, you could determine, through any given period, your earned
value.
Class Activity 3: Structures in the project environment
In small groups or individually as per your facilitator’s instructions, complete
the formative activities in your Workbook
69
Version 1
Learner Guide
Module 4
Application of organisation structures in a project
environment
After completing this module, the learner will be able to explain the application of
organisation structures in a project environment, by successfully completing the following:

Explain the basic differences between a matrix and functional organisation structure
with examples of each

Describe and explain the project organisation structure in a written format

Describe the purpose and key responsibilities of two roles on a project in a written
format

Explain stakeholders with examples of at least six different stakeholders
70
Version 1
Learner Guide
The application of organisation structures in a project environment
The way a project team is structured can play a major role in how it functions. Different styles
of team will have different characteristics. For example, do we wish to encourage discussion
with the suppliers or to keep them at arm's length so the engineers can make good progress?
Careful consideration of team composition and reporting relationships can make a big
difference to the results.
The various roles in the team will depend on the nature of the project. As well as the main
team roles, consider the other participants and how they fit into the picture.
Project roles and resources will have been identified as part of
the planning, estimating and resourcing process. Note that the resources and optimum way
of working will normally change during the project. Often an initial high-powered team will
define the business solution, followed by a much broader team to deliver it, and then a line
management and operational team to operate it. There will be a core team who remain fully
involved throughout the project, but others will need to be brought in as required.
Team structure will probably be adjusted at each stage to meet the evolving nature of the
project. The right structure for a small, high-powered, business-design team is unlikely to work
for a large development team.
4.1 Basic differences between a functional and matrix organisation structure
We will be looking at the two main organisation structures in the project environment in this
Module, namely the functional/divisional organisation structure and the matrix structure.
Functional organisation structure
Most organisational structures departmentalise the work force and other resources by one of
two methods: by products or by functions.
Functional organisations are segmented by key functions. For example, activities related to
production, marketing, and finance might be grouped into three respective divisions. Within
each division, moreover, activities would be departmentalised into sub-departments. The
marketing division, for example, might encompass sales, advertising, and promotion
departments.
The chief advantage of functionally structured organisations is that they usually achieve a
fairly efficient specialisation of labour and are relatively easy for employees to understand. In
addition, functional structures reduce duplication of work because responsibilities are clearly
defined on a company-wide basis.
However, functional division often causes departments to become short-sighted and
territorial, leading to incompatible work styles and poor communication.
71
Version 1
Learner Guide
Process or functionally structured team
Diagram15 showing reporting
responsibility/accountability:




lines,
authority
levels,
a
single
point
of
The Project Manager is supported by a Project Office.
The Project Director is on the same level as the Steering Committee (and would probably be
seen as a full member of the committee).
The Project Manager reports to the Steering Committee.
There is an ultimate decision making body at an executive level above the Steering
Committee.
In the example below, we give more detail: The main teams have been defined to support the
major business processes within the scope of the project. Specialised shared service teams
have been set up - one for all the technical support areas and one for non-technical general
and specialised support, e.g. change management and training.
15
Retrieved from: www.epmbook.com/resources/projectstructure2.ppt
72
Version 1
Learner Guide




Project Office provides significant range of shared services - not just administration.
The Process Owner Directors within the organisation are matched with process teams for
efficient communication on a "one-to-one" basis instead of through various committees and
layers of management
Technically oriented members of the process teams have a secondary reporting relationship
to the technical team leader.
Although the analysts operate within the process team, the programmers are in a shared
service resource pool.
Divisional organisation structure
Companies that employ a product or divisional structure, by contrast, break the organisation
down into semi-autonomous business units and profit centres based on activities, or
"projects," such as products, customers, or geography.
Regardless of the project used to segment the company, each unit operates as a separate
business. For example, a company might be broken down into southern, western, and eastern
divisions. Or, it might create separate divisions for consumer, industrial, and institutional
products. Again, within each product unit there are sub-divisions.
One benefit of product or project departmentalisation is that it facilitates expansion (because
the company can easily add a new division to focus on a new profit opportunity without having
to significantly alter existing systems). In addition, accountability is increased because
divisional performance can be measured more easily. Furthermore, divisional structures
permit decentralised decision making, which allows managers with specific expertise to make
key decisions in their area.
The potential drawbacks to divisional structures include duplication of efforts in different
departments and a lack of horizontal communication. In addition, divisional organisations, like
functionally-structured companies, may have trouble keeping all departments focused on an
overall company goal.
73
Version 1
Learner Guide
Retrieved from: ramanchuk.com
74
Version 1
Learner Guide
Matrix organisation structure
Matrix structures combine functional and product
departmentalisation. They simultaneously organise part
of a company along product or project lines and part of
it around functional lines to get the advantages of both.
For example, a diagram of a matrix model might show
divisions, such as different product groups, along the top
of a table (See Figure 1 below)16. Along the left side of the
same table would be different functional departments,
such as finance, marketing, and production. Within the
matrix, each of the product groups would intersect with
each of the functional groups, signifying a direct relationship between product teams and
administrative divisions. In other words, each team of people assigned to manage a product
group might have an individual(s) who also belonged to each of the functional departments,
and vice versa.
Theoretically, managers of project groups and managers of functional groups have roughly
equal authority within the company. As indicated by the matrix, many employees report to at
least two managers. For instance, a member of the accounting department might be assigned
to work with the consumer products division, and would report to managers of both
departments. Generally, however, managers of functional areas and divisions report to a
single authority, such as a president or vice president.
16Retrieved
from:
http://www.referenceforbusiness.com/encyclopedia/Man-Mix/Matrix-Management-and-Structure.html
75
Version 1
Learner Guide
The main advantage of a matrix structure is that it facilitates rapid response to change in two
or more environments. For instance, a telecommunications company might be extremely
concerned about both unforeseen geographic opportunities and limited capital. By
departmentalising its company with the financial function on one axis and the geographic
areas on the other, it might benefit from having each of its geographic units intertwined with
its finance department. For example, suppose that an opportunity to purchase the cellular
telephone rights for a specific area arose. The matrix structure would allow the company to
quickly determine if it had the capital necessary to purchase the license and develop the area,
or if it should take advantage of an opportunity in another region.
Matrix structures are flatter and more responsive than other types of structures because they
permit more efficient exchanges of information. Because people from different departments
are cooperating so closely, they are eager to share data that will help them achieve common
goals. In effect, the entire organisation becomes an information web; data is channelled both
vertically and horizontally as people exchange technical knowledge, marketing data, product
ideas, financial information to make decisions.
In addition to speed and flexibility, matrix organisation may result in a more efficient use of
resources than other organic structures. This occurs because highly specialised employees and
equipment are shared by departments. For example, if the expertise of a computer
programmer is needed in another department, s/he can move to that department to solve its
problems, rather than idling about on tasks of low priority as might happen in a non-matrix
setting.
Other benefits of matrix management include improved motivation and more adept
managers. Improved motivation results from decision-making within groups becoming more
democratic and participatory because each member brings specialised knowledge to the
table- and since employees have a direct impact on day-to-day decisions, they are more likely
to experience higher levels of motivation and commitment to the goals of the departments to
which they belong. More adept management is the result of top decision makers becoming
more involved in, and thus better informed about, the day-to-day operations of the company.
This involvement can also lead to improved long-term planning.
Despite their many theoretical advantages, matrix structures are usually expensive to
maintain, partly because of more complex reporting requirements. In addition, many workers
become disturbed by the lack of a chain of command and a seeming inability to perceive who
is in charge, i.e. role ambiguity and conflict. For instance, a functional manager may tell a
subordinate one thing, and then a product/project manager will tell him/ her something
different. As a result, companies that change from a comparatively bureaucratic structure to
the matrix structure often experience high turnover and worker dissatisfaction.
Matrix structures work best for organisations that are managed and staffed mostly by
professionals or semi-professionals, e.g., engineers and scientists. A matrix structure further
requires a workforce that has a diverse set of skills and employees that have strong
interpersonal abilities. Finally, the matrix organisation structure is usually more effective
when a project manager, who is technically working under the authority of a product and a
functional boss, is given the authority to make critical decisions.
76
Version 1
Learner Guide
Because of their limitations, matrix organisation structures frequently are integrated into an
organisation as one facet of a larger project. For example, a research team organised to
develop a new product might be placed in a division of the company that is set up as a matrix.
After the initial stages of the project have been completed, the ongoing management of the
product might be moved to a division of the company that reflects a more conventional
functional or product/project structure.
77
Version 1
Learner Guide
Class Activity 4: The application of organisation structures in a project
environment
In small groups or individually as per your facilitator’s instructions, complete
the formative activities in your Workbook
78
Version 1
Learner Guide
Module 5
Project management processes and activities
After completing this module, the learner will be able to explain the major processes and
activities required to manage a project, by successfully completing the following:

Describe key processes and activities that take place to manage a project from
beginning to end

Briefly describe the supplementary management sub-processes and activities
required to support the key processes and activities with examples of each

Explain the reasons for planning and controlling a project with examples of the
consequences of not planning and controlling
79
Version 1
Learner Guide
Project management processes and activities
We have already seen that project management processes include, but are not limited to,
start-up/ initiation, planning, controlling, monitoring, execution/ implementation, closing/
wrapping up and evaluating.
17
In this Module we will be looking at these processes and activities in more detail, as well as
identifying the consequences of not planning and controlling a project properly.
17
http://weill.cornell.edu/its/staging/qa/pmo-old/
80
Version 1
Learner Guide
5.1 Key processes and activities that take place to manage a project from beginning
to end
Key project management processes
We can depict the key processes and their related activities as follows:
Retrieved from: Institute for Development Management, Botswana for the NGO Institute, STF
Initiation
81
Version 1
Learner Guide
The initiation stage determines the nature and scope of the development. If this stage is not
performed well, it is unlikely that the project will be successful in meeting the business’s
needs. The key project controls needed here are an understanding of the business
environment and making sure that all necessary controls are incorporated into the project.
Any deficiencies should be reported and a recommendation should be made to fix them.
The initiation stage should include a cohesive plan that encompasses the following areas:

A study analysing the business needs

Setting measurable goals.

Review of the current operations.

Conceptual design of the operation of the final product.

Equipment requirements.

Financial analysis of the costs and benefits, including a budget.

Selection of stake holders, including users, and support personnel for the project.

Project charter including costs, tasks, deliverables, and schedule.
Planning and design
After the initiation stage, the system is designed. Sometimes a small prototype of the final
product is built and tested. Testing is generally performed by a combination of testers and end
users, and can occur after the prototype is built or concurrently. Controls should be in place
that will ensure that the final product meets the specifications of the project charter. The
results of the design stage should include:
A product that

Satisfies the project sponsor, end user, and business requirements.

Functions as it was intended to.

Can be produced within quality standards.

Can be produced within time and budget.
Production or execution
The execution stage includes the actual implementation of the design or plan. For example, in
software systems, this includes conversion (transfer of data from an old system to a new
system), documentation, and training. Training is important because it helps users use the
new product/ software correctly. The bulk of the project's work and largest capital
expenditure is realised in this stage.
Monitoring and controlling
The Monitoring and Controlling process oversees all the tasks necessary to ensure that the
project is within scope, on time, and on budget. This process involves comparing actual
82
Version 1
Learner Guide
performance with planned performance and taking corrective action when significant
differences exist. The Monitoring and Controlling process is continuously performed
throughout the life of the project.
Closing (close-out) and Maintenance
Closing includes the formal acceptance of the project and the ending thereof. Administrative
activities include the archiving of the files and documenting the lessons learned.
83
Version 1
Learner Guide
Maintenance is an ongoing process, and it includes:

Continuing support of end users

Correction of errors

Solving of user problems
Evaluation
Project evaluation refers to the systematic collection, analysis and use of information to
answer questions about a project. It involves the analysis of costs, outcome or impact,
implementation as well as the successful completion of the project.
Supplementary sub-processes and activities
When describing project management activities in the most simplistic terms, the goal is to
answer four basic questions18:
1. What will be delivered?
2. When will it be done?
3. How much will it cost?
4. Who will do it?
These questions translate, respectively, into the four major project constraints of scope, effort
(time), budget, and resources.
Before the project manager can create a project plan to address these constraints, s/he must
spend some time defining the project to clearly understand the related requirements, risks,
constraints, and assumptions, as illustrated in the following diagram:
18
Business Intelligence Roadmap: The Complete Project Lifecycle for Decision-Support Applications Written by:
Larissa T. Moss, Shaku Atre, 07 Jun 2006 |
84
Version 1
Learner Guide
Work Breakdown Structure
Graphical Format
Project
Project
Description
Description
Conduct
Conductaaone-year
one-yearHIV/AIDS
HIV/AIDSawareness
awarenessand
andprevention
prevention
media
mediacampaign
campaigntargeted
targetedtoward
towardyouth
youthages
ages12-16.
12-16.
Deliverables
Deliverables
Youth
YouthAdvisory
Advisory
Board
Board
Activities
Activities
1.1.Establish
Establish
Youth
YouthAdvisory
Advisory
Board
Board
Youth
YouthMedia
Media
Campaign
Campaign
1.1.Develop
Develop
Media
MediaPlan
Plan
1.1 Meet youth
1.1 Meet youth
organization
organization
stakeholders
stakeholders
1.2
Write
1.2 Writepolicy
policy
memo
memo
1.3 Select youth
1.3 Select youth
board members
board members
1.4 Hold first board
1.4 Hold first board
meeting
meeting
Tasks
Tasks
2.1 Select team
2.1 Select team
2.2 Audit youth
2.2 Audit youth
media strategies
media strategies
2.3 Write-up 2 year
2.3 Write-up 2 year
media plan
media plan
2.4
2.4 Obtain
Obtain
management
management
approval
approvalofofplan
plan
2.2.Launch
Launch
Tabloid
TabloidYouth
Youth
Magazine
Magazine
3.1 Select
3.1 Select
magazine team
magazine team
3.2 Bid contract
3.2 Bid contract
3.3 Develop
3.3 Develop
samples
samples
3.4
3.4 Select
Selectdesign
design
3.5
Develop
3.5 Develop
content
contentplan
plan
3.6 Develop
3.6 Develop
distribution plan
distribution plan
Retrieved from: Institute for Development Management, Botswana for the NGO Institute, STF
Project planning includes creating a project charter, which defines the project in terms of:

Goals and objectives

Scope (the expected project deliverable)

Risks

Constraints

Assumptions

Change-control procedures
The project charter is the agreement made between the business sponsor and the project
staff for developing the product or service. If any component of the project charter changes,
the entire project has to be re-evaluated and all project constraints have to be renegotiated.
Drawing up a project structure entails defining communication standards, setting
documentation standards and change control processes, assigning roles appropriately, and
building risk assessment into the process so that the project can function effectively.
The table below contains a brief description of the main activities of the project and an
example of each:
Activity
Description and example
Project Communications
Defining a reporting structure under which team members
operate, procedures to elevate project issues, regular mandated
status meetings, and any other project-specific communication
standards is basic to any managed project.
85
Version 1
Learner Guide
Documentation
Standards
Project Scope
Project Schedule
Project Cost
Project Quality
Project Resources
The project structure can also define standards on how to create
training materials and documentation related to the project,
including standards that prescribe the templates and applications
the team should use to create documents.
Project scope is the part of project planning that involves
determining and documenting a list of specific project goals,
deliverables, tasks and deadlines; for example, if the objective is
to construct a high-quality, custom home within five months at
cost not to exceed R450 000, you will state specific deliverables,
such as the kitchen appliances that are included and specific
milestones such as when to obtain permits and when the building
inspector will need to inspect a phase.
The schedule is a critical part of planning a project. It identifies
and organises project tasks into a sequence of events that create
the project management plan; for example, when you’re
planning a workshop, you will sequence the tasks from setting
the agenda and booking the venue right through to organising
the cleaning up operations at the end. You will determine which
of the tasks can happen simultaneously, and which will happen in
sequence.
The project cost is the total project cost which includes design
fees, material costs, construction costs, permit fees, land,
furnishings, financing and all other costs that were incurred in
completion of the project
The definition of quality often depends on the stakeholders.
Stakeholders are, as the name implies, people with some stake
or concern in the process.
Stakeholders might be:
 Management, who wants to see improved production
numbers with acceptable quality.
 Union officials, who want the best conditions and highest
pay for employees
 Employees, who want consistent work in a safe
environment.
 Customers/purchasers, who want value for their money.
In manufacturing, the definition of quality can be fairly
straightforward. Products should work as intended with a
minimum number of faults or failures.
In service industries, customer satisfaction is often the primary
measure.
Resources are required to carry out the project tasks. They can be
people, equipment, facilities, funding, or anything else required
for the completion of a project activity. The lack of a resource will
86
Version 1
Learner Guide
therefore be a constraint on the completion of the project
activity.
Change control
Project Risk
Management
Project Procurement
Stakeholder
Management
Change control is a systematic approach to managing all changes
made to a product or system. The purpose is to ensure that no
unnecessary changes are made, that all changes are
documented, that services are not unnecessarily disrupted and
that resources are used efficiently. The change control process is
usually conducted as a sequence of steps proceeding from the
submission of a change request. Typical change requests include
the addition of features to a product, an increase in resources or
upgrades to equipment.
Risk Management is the process of identifying, analysing and
responding to risk factors throughout the life of a project and in
the best interests of its objectives. Proper risk management
implies control of possible future events and is proactive rather
than reactive. For example: An activity in a network requires that
a new technology be developed. The schedule indicates six
months for this activity, but the technical employees think that
nine months is closer to the truth. If the project manager is
proactive, the project team will develop a contingency plan right
now. They will develop solutions to the problem of time before
the project due date. However, if the project manager is reactive,
then the team will do nothing until the problem actually occurs.
The project will approach its six month deadline, many tasks will
still be uncompleted and the project manager will react rapidly
to the crisis, causing the team to lose valuable time
Project procurement involves a systematic process of identifying
and procuring, through purchase or acquisition, necessary
project services, goods, or results from outside vendors who will
carry out the work. For example, a project with a time constraint
to complete a project by a given deadline may be forced to
procure additional labourers to complete the project on time.
A stakeholder is the person, or organisation that is actively
involved in the project, or whose interests may be positively or
negatively affected by execution or completion of the project. A
stakeholder may also exert influence over the project and its
deliverables. The project manager’s goal is to leverage
stakeholder relationships and build coalitions that foster project
success. Stakeholder management identifies each stakeholder or
stakeholder group, the role they play on the project, what must
be communicated, when (how often), how (format of
communication) and whether a response is required. At
minimum, regular progress reports should be distributed to a
wide audience.
87
Version 1
Learner Guide
We can summarise the project manager’s main activities as follows:

Set a clear project goal. (As Stephen Covey says, “Begin with the end in mind”.)

Determine the project objectives. (Sub-units or Sub-goals)

Establish checkpoints (milestones), activities, relationships (how tasks are
interrelated), and time estimates.

Draw up the project schedule.

Direct people individually and as a project team (Leadership).

Reinforce commitment (walk the talk) and excitement of team members (Motivation)

Build agreements that vitalise (win/win) the project team (Negotiation).

Keep everyone connected with the project informed. (Communication)

Empower yourself and others of the project team. (Training, coaching and mentoring)

Encourage risk taking and creativity but manage it closely. (Innovation/ generic
management skills)
It has often been said that 'to improve, one must be prepared to measure the improvement'
and that “one must inspect what one expects.”
5.2 Reasons for planning and controlling a project and consequences of not planning
and controlling
Projects don't just happen: they are planned. A good project plan will provide the following:

A roadmap everyone in the team can follow with clear milestones

A realistic project timescale

Details of resource requirements

Validation of the estimated cost

Early warning of problems
www.dilbert.com
88
Version 1
Learner Guide
A lack of proper and thorough planning will rapidly become obvious as the project moves into
the subsequent phases. As a result, much time and energy must be dedicated to this activity.
A project plan can be considered to have five key characteristics that have to be managed:

Scope: defines what will be covered in a project.

Resource: what can be used to meet the scope?

Time: what tasks are to be undertaken and when.

Quality: the spread or deviation allowed from a desired standard.

Risk: defines in advance what may happen to drive the plan off course, and what will
be done to recover the situation.
Therefore, your project plan must balance the scope, and quality constraint against
the time and resource constraint, while minimising the risks.
How do we measure project success? By answering the following questions:

Has the project satisfied the business requirements of the primary stakeholders?

Were the deliverables produced on time and within the budget (as amended by
formal change control)?

Do the business owners believe the project was successful?

Has the project delivered the business value promised?
Let’s have a look at some of the most common reasons for project failure:

Lack of User Involvement
Lack of end user involvement has proved fatal for many projects. Without user
involvement, nobody in the business feels committed to a system, and can even be
hostile to it. If a project is to be a success, senior management and users need to be
involved from the start, and continuously throughout the development. This requires
time and effort, and when the people in a business are already stretched, finding time
for a new project is not high on their priorities. Therefore senior management need to
continuously support the project to make it clear to staff that it is a priority.

Long or Unrealistic Time Scales
Long timescales for a project have led to systems being delivered for products and
services no longer in use by an organisation. Project timescales should be short, which
means that larger systems should be split into separate projects.
Many managers are well aware of the need for fast delivery, leading to the other
problem of unrealistic timescales. These are set without considering the volume of
work that needs to be done to ensure delivery. As a result these systems are either
delivered late or only have a fraction of the facilities that were asked for. Review all
89
Version 1
Learner Guide
project plans to see if they are realistic and to challenge the participants to express
any reservations they may have with it.

Poor or No Requirements
Many projects have high level, vague, and generally unhelpful requirements This has
led to cases where the developers, having no input from the users, build what they
believe is needed, without having any real knowledge of the business. Inevitably when
the system is delivered, business users say it does not do what they need it to. This is
closely linked to lack of user involvement, but goes beyond it. Users must know what
it is they want, and be able to specify it precisely. As non- specialists this means they
normally need skills training.

Scope Creep
Scope is the overall view of what a system will deliver. Scope creep is the insidious
growth in the scale of a system during the life of a project. As an example for a system
which will hold customer records, it is then decided it will also deal with customer bills,
then these bills will be provided on the Internet, and so on and so forth. All the
functionality will have to be delivered at one time, therefore affecting time scales, and
all will have to have detailed requirements. This is a management issue closely related
to change control. Management must be realistic about what is it they want and when,
and stick to it.
Below is a depiction of potential project failure:
Time
RISK
RISK
SCOP
E
RISK
Resource
Quality
RISK
The scope is so large that there is no way the time, resource, and quality constraints can result
in the project delivering, which means there are enormous risks.
To salvage this plan would require reducing the scope, increasing the time, or resource, or
lowering the quality standard- any of which will reduce the risk of failure. The key lesson is
that plans have to be balanced within the project constraints if they are to deliver.
90
Version 1
Learner Guide

No Change Control System
Despite everything, businesses change and change is happening at a faster rate than
ever before. So it is not realistic to expect no change in requirements while a project
is underway. However, uncontrolled changes play havoc with a system/ product under
development and have caused many project failures.
This emphasises the advantages of shorter timescales and a phased approach to
projects, so that change has less chance to affect development. Nonetheless change
must be managed like any other factor of business. The business must evaluate the
effects of any changed requirements on the timescale, cost and risk of project. Change
Management can be taught.

Poor Testing
The developers will do a great deal of testing during development, but eventually the
users must run acceptance to see if the system/ product meets the business
requirements. However acceptance testing often fails to catch many faults before a
system goes live.
Some of the causes of these faults are:
-
Poor requirements, which cannot be tested
-
Poorly, or non-planned tests meaning that the system is not methodically
checked
-
Inadequately trained users who do not know what the purpose of testing is
-
Inadequate time to perform tests as the project is late
-
Too high user expectations
-
Project scope was not fully appreciated and/or user needs not fully
understood.
-
Irrational promises made due to a failure to take into account the variable
nature of task performance.
-
Lack of management continuity and an incentive system that encourages
overly optimistic estimates of the benefits that can be attained from doing the
project
-
Project managers too often act as “process cops and report compilers and lose
sight of what they’re supposed to be doing – to make sure projects are running
effectively”.
-
Wasting of resources through under-utilisation because they aren't the "best
resource" for the job
-
Wasting of the "best" resources through over-utilisation, multi-tasking, and
burn-out.
91
Version 1
Learner Guide
-
Delivering original scope when conditions/needs change/ or the flip-side:
accepting changes to scope without sufficient analysis of impact on the
project (or on other projects)
Some more reasons for project failure can be ascribed to the human resources involved; for
example:

Inadequately trained and/or inexperienced project managers

Failure to set and manage expectations

Poor leadership at any and all levels

Failure to adequately identify, document and track requirements

Cultural and ethical misalignment

Misalignment between the project team and the business or other organisation it
serves

Inadequate communication, including progress tracking and reporting
How to Avoid the Perception of Failure
To avoid the perception of failure, it's not enough to succeed--but it's a start. Here is some advice
regarding dodging the perception of failure. Define the boundaries of your project well, including:

when it starts and ends

how much budget it has

what its goals and deliverables are

who the stakeholders are, and what benefits they expect

what level of quality is required and how quality will be measured
In addition, the change control process must be well defined and executed.
Finally, make sure the stakeholders and other important interested parties such as management
know that what you are doing is in fact a project with expected results that will benefit many of
them. Use the well-defined project boundaries to build an appropriate level of expectation.
Then deliver within the boundaries and meet or exceed the expectations you have set.
Finally, and perhaps most importantly, make certain everyone who should know does know about
your success. Don't let false modesty deter you in this regard. The public relations/political aspect
of perceived project success can't be overlooked or your project could be misunderstood (a terrible
fate for a successful project!).
Retrieved from: http://www.gantthead.com/article.cfm?ID=187449
Project Risk Management
92
Version 1
Learner Guide
The basic concept of risk management identifies anything significant that could possibly go
wrong with the project. A risk management plan will then seek to moderate or eliminate those
risks, hopefully avoiding their consequences.
One of the best uses of risk management is to have a ‘risk’ item in your regular project
meetings to highlight to everyone the risks that the project currently faces.
In some larger-scale projects a risk management officer is appointed. The risk management
officer’s responsibility is to identify all the risks to a project and to prioritise and present them
to the project team for resolution. In smaller-scale projects, risk management is often central
to the role of the project manager and is not considered separately.
Risk to a project can be measured on two major axes:

Likelihood of failure

Impact of failure
The more likely a problem is to occur, the more risk it poses to the project. Even fairly minor
problems or issues can become a threat to the project if they occur so frequently that they
can’t be avoided. Similarly, the impact or consequences of a problem are also important. Some
problems can stop a project in its tracks all by themselves. Many systems exist for categorising
risks into different categories but the one presented here is fairly simple. In this system, each
risk item is qualified on two scales: likelihood and impact. Each scale is divided into two
categories of ‘low’ or ‘high’ and risks are rated according to each scale:

A ‘critical’ issue represents one that will stop the project in its tracks (known as a
‘show stopper’) and must be dealt with immediately.

‘Major’ risks represent a significant threat to the project because of their frequency
or because of the seriousness of their impact; these threats usually have to be dealt
with as soon as possible.

The third category of risks are ‘minor’ risks which are neither likely nor particularly
serious and can be left until others have been dealt with. Minor risks however, have
an annoying habit of turning into major ones when your back is turned.
93
Version 1
Learner Guide
Once you have profiled the risks they can be ranked into an ordered list representing the
various threats to the project to be dealt with. The more significant can then be examined and
assigned an action by the project team.
Typical actions include:

Research: The risk is not yet fully understood. Its impact or likelihood of occurrence may
be unclear or the context in which it may occur could seem unreasonable. Further research
by members of the project team is warranted.

Accept: The risk is unavoidable and must be accepted as-is. This category of risks become
extremely important to a project since they cannot be resolved but still represent a threat
to completion. Anticipation therefore becomes the key to dealing with this category of
risk.

Reduce: The risk as it stands is unacceptable. The project team must act to reduce the risk
and to establish contingency plans should the risk occur. The risk will have to be reviewed
in future to define the threat it poses.

Eliminate: The risk is unacceptable under any circumstances and must be eliminated as a
possibility. The project team must put in place processes and procedures not only to
ensure the immediate threat is eliminated but that it does not re-occur in the future.
Recording Risks
The simplest way of recording risks is with a table or spreadsheet that lists the risks and their
priorities. This can then be regularly reviewed by the project team and action taken
appropriately to mitigate or eliminate those risks. An example of a sample risk table for a
project:
94
Version 1
Learner Guide
In the table (previous page), failure by suppliers to deliver some components has been rated
as a minor risk. This sort of judgement can only be made on the basis of experience and within
the context of the current project. If the supplier is well known and trusted, then the likelihood
of them delivering late is likely to be low and hence the risk can be classified as minor.
It is often recommended that risks are communicated early and often at all phases to the
drivers and supporters of your project.
Class Activity 5: Project processes and activities
In small groups or individually as per your facilitator’s instructions, complete
the formative activities in your Workbook
95
Version 1
Learner Guide
Module 6
Project needs, expectations, constraints, assumptions,
exclusions, inclusions and deliverables
After completing this module, the learner will be able to contribute to the identification,
description and analysis of the project needs, expectations, constraints, assumptions,
exclusions, inclusions and deliverables, by successfully completing the following:

Agree objectives with all relevant parties

Identify and record assumptions, needs, expectations, constraints, exclusions,
inclusions and deliverables according to the agreed format

Develop work packages to present overall view of the project scope

Develop and document a work breakdown structure within agreed time frames
96
Version 1
Learner Guide
Project needs, expectations, constraints, assumptions, exclusions,
inclusions and deliverables
How many times have you heard about or been involved in a project that failed miserably? Or
perhaps it just was not as successful as it needed to be. Did you ever spend time looking back
to see what caused the project to go wrong? If you did, chances are that you will have said,
“You know, we should have spent more time planning.”
Most projects have deadlines, and it seems they are getting shorter and shorter. Hitting
aggressive deadlines puts pressure on the project manager to start the project as soon as
possible. However, before the project work begins, you need to spend time in up-front
planning to make sure that the work is properly understood and agreed to. This is not wasted
time or ‘overhead’ time. This is the time the project manager spends ensuring that the project
team and the client have common perceptions of what the project is going to deliver, when it
will be complete, what it will cost, who will do the work and how the work will be done.
Benefits of planning a project thoroughly:

Understanding and gaining agreement on project objectives, deliverables, scope, risk,
cost, approach, etc. (from the Project Definition). This work simply ensures that the
project team and sponsor agree on the work that is required.

Determining if the original business case is still valid. When the project was initially
approved, the project cost and duration were probably estimated at a high-level –
maybe up to +/- 50%. Now that the project is starting, the estimates should be
revalidated to get them closer to +/- 10%. This additional refinement may result in the
estimates ending up higher than before, and these higher numbers may make the
business case unattractive. For instance, a project that requires 10 000 effort hours
97
Version 1
Learner Guide
might make business sense. If the more detailed planning process results in a more
refined estimate of 20 000 hours, the project may not make business sense any more.

Making sure the resources you need are available when you need them. This is a result
of understanding the project organisation and creating your schedule with resources
assigned.

Providing a high-level baseline from which progress can be compared. This is a result
of creating the milestone schedule based on the more detailed work plan.

Validating the processes used to manage the project ahead of time with the client.
The Project Management Procedures that are used to manage the project should be
discussed and explained to the clients and team members.
6.1 Agree objectives with all relevant parties
Clear and accurate definition of a project is one of the most important actions you can take to
ensure the project’s success. The clearer the target, the more likely you are to hit it. Defining
a project is a process of selection and reduction of the ideas and perspectives of those involved
into a set of clearly defined objectives, key success criteria and evaluated risks.
This definition process should culminate in the production of a Project Definition document,
sometimes called a Project Charter.
The Project Definition document should be approved and issued by a manager with the
authority to apply organisational resources to the project activities. Therefore, the seniority
of the manager or the management team will be commensurate with the size, cost and
business value of the project.
As a minimum, the Project Definition should include a statement of the business need that
the project seeks to address and the description of the product, service or deliverable business
objectives that will be its output.
The way to define a project is to ask a standard set of questions of yourself (as project leader)
the project team, colleagues with particular expertise and senior managers. The questions fall
into the categories given below:
The Purpose (or Mission)
This is the reason for doing the project

What is the project about in broad terms?

Who wants it done and why?

What is its title?
The Goals
These are the targets we want to meet
98
Version 1
Learner Guide

What is it we want to achieve?

When do we want to achieve it?

What are our specific aims?

Why are these goals essential to the project?
Goals are high-level statements that provide the overall context for what the project is trying
to accomplish. For example one of the goals of a project might be to “increase the overall
satisfaction levels for clients calling the company helpdesk with support needs”.
A goal may take more than one project to achieve. In the above example, for instance, there
may be a technology component to increasing client satisfaction. There may also be new
procedures, new training classes, reorganisation of the helpdesk department and modification
of the company rewards system. It may take many projects over a long period of time to
achieve the goal.
The goal should reference the business benefit in terms of cost, speed and / or quality. In this
example, the focus is on quality of service.
Even if the project is not directly in support of the business, there should be an indirect tie.
For instance, an IT infrastructure project to instal new web servers may ultimately allow faster
client response, better performance or some other business benefit. If there is no business
value to the project, the project should not be started.
A goal statement that says you are trying to achieve a perfect client experience is not possible
with any combination of projects. It may instead be a vision statement, which is a higher level
statement showing direction and aspiration, but which may never actually be achieved.
The Beneficial Gains or Scope: The importance of scope
This is how our organisation will gain. Here we define our performance criteria and set our
quality standards for the project.

How will things be different if the project is successfully completed?

Is there a clear need and can it be quantified?

Who will benefit, how will they benefit and what will they gain?

Do the beneficiaries agree about the need and the proposed solution?

Is the project to identify that need and/or that solution?

How will they react to that solution?

What are the alternatives?

Are those alternatives more or less acceptable (satisfactory).

Is how we are going to achieve the goals an important part of the beneficial gain?

What is it worth to you or to others to have the need satisfied?
99
Version 1
Learner Guide
First, imagine that you have no constraints. Use brainstorming and other techniques to
generate ideas that most succinctly describe the Purpose, Goals and Beneficial Gains. Now
reduce these down to the fundamentals.
Objectives
Objectives are concrete statements that describe the things the project is trying to achieve.
An objective should be written at a lower level, so that it can be evaluated at the conclusion
of a project to see whether it was achieved.
100
Version 1
Learner Guide
Goal statements are generally rather vague. A well-worded objective will be Specific,
Measurable, Attainable/Achievable, Realistic and Time-bound (SMART).
(Remember, SMART is a technique for wording the objective. An objective does not absolutely
have to be SMART to be valid.)
An example of an objective statement might be to “upgrade the helpdesk telephone system by
December 31 to achieve average client wait times of no more than two minutes”.

The objective is measurable in terms of the average client wait times the new phone
system is trying to achieve.

You can assume that the objective is achievable and realistic.

The objective is time-bound, and should be completed by December 31.
Objectives should refer to the deliverables of the project. In this case, the objective refers to
the upgrade of the telephone system.
If you cannot determine the deliverables that are created to achieve the objective, the
objective may be written at too high a level.
On the other hand, if an objective describes the characteristics of the deliverables, it is written
at too low a level. If the statements describe the features and functions, they are
requirements, not objectives.
If the project is a part of a larger program, the objectives of all the underlying projects should
be in alignment with the program objectives.

Importance of Objectives
Objectives are important because they show a consensus of agreement between the project
manager and the project sponsor on the main purpose of the project. The specific deliverables
of an IT project, for instance, may or may not make sense to the project sponsor. However,
the objectives should be written in a way that they are understandable by all of the project
stakeholders.
The project objectives and the business goals they support should be defined and agreed upon
before the project starts. The deliverables of the project are created based on the objectives
– not the other way around. That is, you don’t agree on the deliverables first and then establish
objectives to match. You must understand the objectives of a project and then determine what
deliverables are needed to achieve them.
A facilitated meeting between all major stakeholders is a good way to create the objectives
and gain a consensus on them at the same time.
We need to define specific measurable objectives from our broad aims. These objectives
will tell us if we have met our goals and to what standard.
101
Version 1
Learner Guide
From our list of specific goals for the project we must develop a set of measurable objectives
that will confirm that we have reached certain project milestones (or way points) including
the final one of project completion.
The measurable objectives (when achieved) demonstrate the extent to which the beneficial
gains have been achieved, the goals have been met and the purpose of the project has been
achieved.
102
Version 1
Learner Guide
Example:
Aim:
A Local Authority has a statutory duty to provide accommodation for homeless people. It needs
to develop a temporary housing strategy that removes the need for expensive bed and
breakfast accommodation for homeless people.
Measurable Objectives:

Develop links with Housing Associations and Shelters to ensure that we have sufficient
capacity to meet our expected (150 per annum) homeless needs.

Reduce the number of bed and breakfast lets over 2 years from 100 to 0.

Verify that annual cost of accommodating homeless people has reduced by at least
10%.
6.2 Identify and record assumptions, needs, expectations, constraints, exclusions,
inclusions and deliverables according to the agreed format
We need to identify and record the objectives that, if all else fails, we must meet and/or those
that we must meet for the project to be deemed successful.
Key Success Criteria (KSC): Project success factors
From the list of objectives, select those that are critical or key to the success of the project.
These are the items that are critical to those who will benefit from the project and those with
the responsibilities for judging success criteria (Managers, Customers, Members,
Shareholders, Stakeholders, etc.).
The purpose of this is twofold:

Firstly, to clarify in the minds of the project team and managers what the essential
benefits are that the project will deliver and manage their expectations.

Secondly, if circumstances change within the life of the project, then it is often
extremely useful to see what the agreed success criteria were at the start of the
project.
The project may then be replanned to ensure the KSC are met, or the KSC may be formally
changed (by Senior Managers in the light of changed circumstances) and the project redefined
and replanned to ensure they are met.
Assumptions
To assume is to “take something for granted.” In other words, an assumption is something
that we cannot establish as being true at this point in time, but is likely to be/become true.
In a project, there is always a high degree of unknown. If we waited until all information were
available, we would probably never start; for example, we assume that resources will be
103
Version 1
Learner Guide
available and that funding will not be withdrawn. These are risks for which we can prepare
contingency plans.
We need to identify, quantify and make contingency plans to deal with project risks.
The constraints on a project are one form of risk. The project may well have specific
constraints that lead to identifiable risks.
What do we mean by project risk? A risk is anything that will have a negative impact on any
one or all of the primary project constraints, namely time, resources and Performance
Criteria.
Some examples might be:

A key person with specialist skills is required for several projects. If one of those
projects over runs then that person will be required to work on several projects at the
same time. If this is not practical, then the other projects will be delayed.

A person selected to do work on a project may not have the skills to do the work. If
this risk is identified then the project plan can allow for training time and learning
curve time. Alternatively, another resource may be identified.

A vital machine may be scheduled for maintenance during the time it is required for
the project. The maintenance schedule must be known and the effect of early or late
maintenance or even machine substitution must be assessed and built into the
project plan.
Needs and expectations
Defining scope is perhaps the most important part of the upfront definition and planning
process as it formalises needs and expectations.
If you don’t know for sure what you are delivering and what the boundaries of the project are,
you have no chance for success. If you have not done a good job of defining scope, managing
scope will be almost impossible.
The purpose of defining scope is to clearly describe and gain agreement on the logical
boundaries of your project. Scope statements are used to define what is within the boundaries
of the project and what is outside those boundaries. The more aspects of scope you can
identify, the better off your project will be.
Constraints
At the end of the Definition and Planning process you should have an agreement with your
sponsor on the work that will be completed and the cost and duration (time) that are needed
to complete the work. These three items form a concept called the “triple constraint”.
104
Version 1
Learner Guide
The key aspect of the triple constraint is that if one
of the three items changes, at least one, if not both,
of the other items need to change as well. The cost
item can also be referred to as effort. Sometimes,
the scope item is referred to as quality, which then
focuses on delivering a certain quality level for a
certain cost and duration. This concept is easy to
visualise if you think of the triple constraint as a
triangle, with the sides representing cost, duration
and scope of work.
If the scope of work increases, the cost and/ or
deadline must increase as well. This makes sense. If
you have more work to do, it will take more cost
(effort) and perhaps a longer duration. (Likewise if
you reduce the scope of work, the cost (effort) and
/ or the duration should decrease as well.)
If you are asked to accelerate the project and
complete it earlier than scheduled, it would also be
logical to ask for less work. However, if you are
asked to deliver the same work with less duration,
the third leg of the triple constraint must increase to
maintain the balance. You will need to increase costs
(effort), perhaps by working overtime hours or
perhaps by bringing in more resources to complete
the same amount of work earlier.
Exclusions and inclusions
In the project context, the term scope refers to:

The features and functions that characterise a product, service, or result

The work that needs to be accomplished to deliver a product, service, or result with
the specified features and functions.
Scope is also the term used to describe the boundaries of the project. Scope is used to define
what the project will deliver (inclusions) and what it will not deliver (exclusions); i.e. which
features and functions a product will have and which it will not have.
Deliverables
The fundamental objective of a project is to deliver something new.
It is not always easy to distinguish between aims (goals), objectives and deliverables. If the
project is to create new products or modify existing ones, then the list of deliverable items
may be as simple as a set of part or product numbers. It may be 3 sets: new parts or products,
obsolete parts or products and products or parts not affected by the project. These
deliverables are easily distinguishable from the goal; which may be to increase market share
by 7%, and the objectives; to have the product shipping by the 3rd quarter of the year, at a
105
Version 1
Learner Guide
works cost price of R300, with shipments reaching or exceeding 5000 per month by end of the
year.
However, the deliverable items may be less easy to distinguish in some projects. A project to
deliver the implementation of a new integrated housing management computer system will
deliver parameter set-up, data transfer, staff training, etc. But these look very little different
from the objectives; parameter set-up by 30th March, data conversion by 15th June, and staff
training by the end of July.
In the first example, a new product will have a specification (or a set of specifications) which
defines its essential elements, its functions, its quality standards, its marketing requirements,
etc. These will form part of the project’s deliverables, or they may have been deliverables of
a previous research project. Thus the deliverables may be reduced to a simple set of inventory
numbers.
The deliverables of the second project should concentrate on the qualitative and quantitative
aspect of the project. In effect, the deliverables list becomes a set of specified outputs (a
quantity and quality specification) for each milestone or way point of the project.
106
Version 1
Learner Guide
6.3 Develop work packages to present overall view of the project scope
Concepts for breaking down work into manageable work packages
The project scope statement describes, in detail, the project’s deliverables and the work
required to create those deliverables. The project scope statement also provides a common
understanding of the project scope among all project stakeholders and describes the project’s
major objectives.
It also enables the project team to perform more detailed planning, guides the project team’s
work during execution, and provides the baseline for evaluating whether requests for changes
or additional work are contained within or outside the project’s boundaries.
The degree and level of detail to which the project scope statement defines what work will be
performed and what work is excluded can determine how well the project management team
can control the overall project scope. Managing the project scope, in turn, can determine how
well the project management team can plan, manage, and control the execution of the project.
If you look at the reasons that projects fail, it is usually the result of two problems. Either the
team did not spend enough time defining the work and/or there was a lack of scope
management. Even if the project manager did a good job of defining scope, the hard part
comes in having to manage the project to that agreed-upon scope.
Work packages that are discussed and defined with each team member will prevent team
members saying things like:
“Oh, NOW I understand what you actually wanted!” or “I had no idea you wanted THAT!”
The elements you should include in a work package are:

ID information- identify the project, the team member and the achievement the team
member will be accountable for delivering (not the activities s/he will perform).

Approach statement- the project manager and the team member discuss and make
notes on the approach/ strategy the team member will take to the task.

Input and output deliverables- the project manager and team member discuss the
deliverables from previous tasks which the team member needs to start work on this
one. Identify the inputs the team member needs and identify the tasks and the people
responsible for delivering them. Likewise, explicitly identify and describe the outputs
the team member will create in addition to the primary deliverable from this task.
These outputs might include documentation of the design, calculations or supporting
information that the team member gathered. Reach agreement on the work that has
to be done.

Time commitment- discuss the kind of work effort the task will require. If approval has
to be secured from the team member’s departmental head, it is good practice to have
that superior sign the team member’s work package, agreeing to the time
commitment, output deliverables and estimate.

Risk assessment- identify risks that could cause the task to take more time and more
work, such as lack of cooperation or delays in supplier deliveries.
107
Version 1
Learner Guide

Estimates- the team member and project manager agree on a work estimate and a
duration estimate that takes into account the team member’s availability.
The best way to complete the work package is to make it a joint effort between the team
member and the project manager. This also encourages buy-in and commitment.
Using work packages as a foundation for estimating and controlling scope helps project
managers to build smaller and more flexible work breakdown structures (see below), thus
improving the scope control process.
6.4 Develop and document a work breakdown structure within agreed time frames
The WBS is a deliverable-oriented hierarchical decomposition of the work to be executed by
the project team, to accomplish the project objectives and create the required deliverables.

The WBS organises and defines the total scope of the project.

The WBS subdivides the project work into smaller, more manageable pieces of work,
with each descending level of the WBS representing an increasingly detailed definition
of the project work.
The planned work contained within the lowest-level WBS components, which are called work
packages, can be scheduled, cost estimated, monitored, and controlled.
The WBS represents the work specified in the current approved project scope statement.
Components comprising the WBS assist the stakeholders in viewing the deliverables of the
project.
Although each project is unique, a WBS from a previous project can often be used as a
template for a new project, since some projects will resemble another prior project to some
extent. For example, most projects within a given organisation will have the same or similar
project life cycles and, therefore, have the same or similar deliverables required from each
phase. Many application areas or performing organisations have standard WBS templates.
The Project Management Institute Practice Standard for Work Breakdown Structures provides
guidance for the generation, development, and application of work breakdown structures. This
publication contains industry-specific examples of WBS templates that can be tailored to
specific projects in a particular application area.
Decomposition
Decomposition is the subdivision of project deliverables into smaller, more manageable
components until the work and deliverables are defined to the work package level. The work
package level is the lowest level in the WBS, and is the point at which the cost and schedule
for the work can be reliably estimated. The level of detail for work packages will vary with the
size and complexity of the project.
Decomposition may not be possible for a deliverable or subproject that will be accomplished
far into the future. The project management team usually waits until the deliverable or
108
Version 1
Learner Guide
subproject is clarified so the details of the WBS can be developed. This technique is sometimes
referred to as rolling wave planning.
Different deliverables can have different levels of decomposition. To arrive at a manageable
work effort (i.e., a work package), the work for some deliverables needs to be decomposed
only to the next level, while others need more levels of decomposition. As the work is
decomposed to lower levels of detail, the ability to plan, manage, and control the work is
enhanced. However, excessive decomposition can lead to non-productive management
effort, inefficient use of resources, and decreased efficiency in performing the work. The
project team needs to seek a balance between too little and too much in the level of WBS
planning detail.
Decomposition of the total project work generally involves the following activities:

Identifying the deliverables and related work

Structuring and organising the WBS

Decomposing the upper WBS levels into lower level detailed components

Developing and assigning identification codes to the WBS components

Verifying that the degree of decomposition of the work is necessary and sufficient.
Identifying the major deliverables of the project and the work needed to produce those
deliverables requires analysing the detailed project scope statement. This analysis requires a
degree of expert judgment to identify all the work including project management deliverables
and those deliverables required by contract.
Structuring and organising the deliverables and associated project work into a WBS that can
meet the control and management requirements of the project management team is an
analytical technique that may be done with the use of a WBS template or even using Post-Its:
It might surprise you to know the number of people that use yellow sticky pads and a blank
wall to create the first draft of the Work Breakdown Structure. This technique is very easy. You
first get the appropriate people into the same room. These are the project team members and
clients who have the expertise to build the WBS. Typically you start off by writing the names
of the major deliverables on Post-it notes – one deliverable per note. Make sure the attendees
agree on the major deliverables to begin with. If any of the deliverables are very large, you can
create new Post-it notes that describe the deliverables at a lower level, or individual work
products. These are arranged under the higher-level deliverable. The deliverable needs to be
identified at a level low enough that you understand what it takes to build it. In general two
levels should be enough. One level is typical.
Next, for each deliverable, describe the activities that must take place to complete it. Each
activity goes on a separate Post-it note, Again, these are arranged under the specific
deliverable they refer to. If you have a sense for the order that the activities need to be
completed, you can arrange the Post-it notes sequentially. However, this is not important at
this point. The important thing is to identify all the work.
109
Version 1
Learner Guide
Look at the activities that are required to build each deliverable (or work product) and estimate
the work associated with each activity. If the effort associated with an activity is larger than
your estimating threshold, identify the more detailed activities that make up the higher-level
one. Each of these activities is represented by new Post-it notes under the higher-level activity
(which now becomes a summary activity). Continue with this process until the work required
to complete all of the deliverables is defined, as best you know today. The levels of activities
will not be the same for each deliverable. Some simple deliverables may meet the threshold
criteria in one or two levels. Others may take three or four, or more.
The advantage of this approach is that your team can visually see the work and they can help
ensure all the work is identified to complete the project. The Post-it sheets also give you the
ability to easily move things around. If you add an activity and then decide to remove it, you
just pick up the Post-it sheet. Likewise, if a deliverable or group of activities is in the wrong
place, you just move the Post-it notes to where they need to be.
When you are all done, you can enter the summary and detailed work activities into your work
plan management tool.
The resulting structure can take a number of forms, such as:

Using the major deliverables and subprojects as the first level of decomposition

Using subprojects, where the subprojects may be developed by organisations outside
the project team. For example, in some application areas, the project WBS can be
defined and developed in multiple parts, such as a project summary WBS with multiple
subprojects within the WBS that can be contracted out. The seller then develops the
supporting contract work breakdown structure as part of the contracted work.

Using the phases of the project life cycle as the first level of decomposition, with the
project deliverables inserted at the second level.

Using different approaches within each branch of the WBS, where test and evaluation
is a phase, the air vehicle is a product, and training is a supporting service.
Decomposition of the upper level WBS components requires subdividing the work for each of
the deliverables or subprojects into its fundamental components, where the WBS components
represent verifiable products, services, or results.
Each component should be clearly and completely defined and assigned to a specific
performing organisational unit that accepts responsibility for the WBS component’s
completion.
The components are defined in terms of how the work of the project will actually be executed
and controlled. For example, the status reporting component of project management could
include weekly status reports, while a product to be manufactured might include several
individual physical components plus the final assembly.
Verifying the correctness of the decomposition requires determining that the lower-level WBS
components are those that are necessary and sufficient for completion of the corresponding
higher-level deliverables.
110
Version 1
Learner Guide
Build a work plan
Small projects
Usually there is not a formal process used to build a work plan for a small project. The projects
are of the size where it is easy to mentally lay out the steps that need to be performed and the
order in which the steps need to be performed.
There are probably only one or two people involved, so it is not hard to figure out who does
what.
Although it may be possible to develop a work plan in your head, the final work plan should
be documented.
For a small project, you can use a project management package like MS Project or you can use
a spreadsheet, or even a piece of paper.
The point is to sit down, with other team members if appropriate, and lay out the work to be
performed.
Having the work plan written down will allow the other team members and your client to
understand the work to be performed.
Likewise, the budget for a small project should be easy to determine. You are generally going
to have a straightforward combination of labour and specific non-labour costs. You are
probably not going to have things like training costs or team-building costs on a small project.
Once you have your initial estimates on effort, cost and duration, you can complete the Service
Request form for a small project.
Medium and Large Projects
At the smaller end of a medium project, you may have the ability to use the same techniques
as for a small project. However, the larger the project, the harder this informal process
becomes. The best way to build a work plan is to start with a Work Breakdown Structure (WBS)
and define the work plan from there.
The general process is as follows:
Step 1: Gather Pre-existing Baseline Documents
Review the Project Definition to ensure you understand the deliverables to produced, the
overall timeframe, risks and assumptions, etc. The Project Definition may not be complete, but
it needs to be in decent first draft form so that the draft work plan can be built. For a larger
project, the Project Definition should also contain the project approach, which provides a highlevel description of how the project will be completed.
Step 2: Create a Work Breakdown Structure
111
Version 1
Learner Guide
112
Version 1
Learner Guide
First determine the large chunks of work that must be completed for the entire project to be
completed.
At this point, it does not matter how you define the large chunks of work. It is only important
that all the work is identified at the end of the process.

A traditional breakdown might be ‘planning / analysis / design / construct / test /
implement’, which lays out the project in a high-level timeline.

The breakdown could also be by deliverable – for instance ‘online application / data
warehouse / user query tools’.

It could also be by some functional breakout such as ‘extract data / load data / report
on information’.
You can break down the work into whatever structure makes sense for your project.
The high-level project itself is referred to as level 0 and the first high-level breakdown of work
is called level 1.
The point of the Work Breakdown Structure is to capture all the elements of work.
Sequencing is not important at this time. It is important to identify an estimating threshold so
that you know how small to break the work down
This process of breaking larger work components into smaller work components is called
“decomposition”.
After you have finished your initial work breakdown, estimate the effort required to complete
each individual work component. You should determine whether any of the just-completed,
lower-level components require a level of effort that is larger than the estimating threshold.
Any work components that are estimated to have a level of effort smaller than the estimating
threshold do not need to be broken down further. Work components that are estimated to
require more effort than the estimating threshold should be broken down further. If you have
a medium to large project, most of the work components at the first level will still be larger
than the estimating threshold and will need further decomposition.
Review each remaining work component to determine the set of lower-level activities that
are required to complete them (you can also break down work components that are already
less than the estimating threshold, but you do not need to). This gets you to level 2 of the
Work Breakdown Structure. When this second level of work components is completed, again
estimate whether any of the second-level activities are greater than the estimating threshold.
If so, these components need to be broken down further. Work components that are already
less than the estimating threshold can be left as they are.
This process of breaking the work components into a lower level set of activities should
continue until all of the work components are represented as granularly as necessary, with no
activities having estimated effort larger than the estimating threshold. This takes you to levels
3, 4, 5 etc. It would be rare that you would need to break the work down further than five
levels.
The objective when you have completed the WBS is that you will have broken down the entire
work effort into activities that are smaller than your estimating threshold.
113
Version 1
Learner Guide
However, if your project is large, it is likely that you may not know enough to be able to break
all of the work down to that level.
If you cannot break the work down into small enough components you may still be okay as
long as those higher-level components do not need to be worked on any time soon.
You may not have enough information to break down larger work components that do not
need to be executed until sometime in the distant future. In that case, you can leave the
components at the higher level until you get closer to execution (three months), at which time
you will know enough to be able to break the work down at a more granular level.
Of course, the problem is that because you have not sequenced the work yet, you may not
know whether the work needs to be done sooner or later. Nevertheless, if you do not know
enough to break down the work lower that the estimating threshold, leave it at that level until
the work is sequenced later. At that point you will know if you have a problem. If the work
needs to be done relatively soon, you will need to figure out how to break the larger
components into a lower level of detail so that you can assign the work to a team member. If
the work ends up being executed in the more distant future, the components can be left at
the higher level for now.
You have already done a high-level estimate of effort to determine if the work for each activity
is greater than the estimating threshold. When the Work Breakdown Structure is complete,
you need to review all the detailed activities and assign initial estimates of effort hours to all
of them (the detailed activities are the ones at the lowest level that are not broken down
further). For instance, you may determine, by expert opinion, that a certain activity is 70 effort
hours. Then you can use an analogy technique to determine that other activities that are about
the same size will also take 70 hours to complete.
When the Work Breakdown Structure is complete you have an inverted (upside down) tree
structure of activities.
WBS Examples
There are a number of ways to create the Work Breakdown Structure (WBS). Remember that
the WBS is the first step toward creating the project work plan. It is not the work plan itself. It
is important to use the WBS to identify all the major work to be done. It is not important to
break the work down into levels or patterns that provide a sense for the timing and
sequencing. This will all be done later.
Here are some examples of how the WBS can be structured.
Generic (classic) WBS
This example shows a generic example of breaking down a deliverable into work packages, and
then breaking work components into activities, and then breaking activities down into tasks.
Remember that you can break the work into deliverables first or into other categories first.
However, regardless of how you start the top level WBS, you will have to transition to
deliverables and then to activities. The activities of the project are usually for the purpose of
building deliverables, so at some point this deliverable activity breakdown needs to occur.
114
Version 1
Learner Guide
Notice that the Work Package level and the Task level are both optional. Your WBS may go
from deliverable to activities and stop there.
WBS by major project phase or stage
This example shows the major phases required for a project. They do not have to be in the
correct time-sequence. Just determine what the major pieces of work are and break each one
down further. (Many of these boxes will be broken down much further into the activities
required to execute the work.)
115
Version 1
Learner Guide
116
Version 1
Learner Guide
WBS by timeline
In this example, the team has built a WBS-based on the order in which the major work
components should be performed. This may be easier to think through in some projects where
there is some experience in knowing how the timeline will lay out.
WBS by deliverable
First determine all the deliverables that the project will produce, and then break them down
into the work required. Again, this does not imply sequencing. Many of these activities may
end up being executed in parallel.
117
Version 1
Learner Guide
Class Activity 6: Project needs, expectations, constraints, assumptions,
exclusions, inclusions and deliverables
Individually or in groups as per your facilitator’s instructions, complete the
formative activities in your Workbook
118
Version 1
Learner Guide
Module 7
Inputs to be used for further planning activities
After completing this module, the learner will be able to contribute to preparing and producing
inputs to be used for further planning activities, by successfully completing the following:

Compile scope documentation in accordance with instructions and procedures

Ensure that scope document contains a rudimentary sequence of events and/or
milestones

Ensure that scope document is communicated to stakeholders for approval

Record measures for project success in the agreed format
119
Version 1
Learner Guide
Inputs to be used for further planning activities
Manage client expectations with a project scope
document: it is too late to begin managing a
client’s expectations when you’ve reached the
middle of delivering a service or project
deliverable. To be successful, you have to start
managing expectations at the beginning of every
client request.
It would be nice to be able to take the quick and
easy path of just discussing an issue or request with
a client and then doing the work. The challenge is
that people hear and interpret the same message in different ways. To protect your client and
yourself, take the time to develop a detailed scope document on the front end of any project
to manage both of your expectations.
What does a scope document achieve?
The essence of the scope document is always to state to your client, “This is what I heard you
say, this is what I plan to do, and this is the cost of the effort.” Making this statement:
 Forces you to think through the elements of the project or request.

Gives the client your interpretation.

Verifies the project’s who, what, when, where, and how.

Forces the client to validate your interpretation of the planned work.
The level of detail you put into a scope document will vary based on the project and your
client. In some cases, you could simply use a follow-up e-mail or short letter to clarify what
you’re planning to do based on a conversation, but usually it’s standard practice to create some
type of scope document before you do any work for a new or existing client.
The principles, methods and techniques for scoping a project
Project Scope is the primary measure of project performance that deals with the client's
requirements for function, capacity, and content is defined as follows: "The bounded set of
verifiable end products, deliverables, or outputs that the project team undertakes to provide
to the client (the owner or sponsor) of the project"
The undertaking by a project team to carry out a project for a client is comprehensively
described in three categories:

Scope: The required set of end results or products with specified physical and
functional characteristics; the outputs

Deadlines: Dates by which the results are due

Budget: Upper limits on the inputs, i.e. money or other scarce resources that may be
consumed in creating the results.
120
Version 1
Learner Guide
These three objectives or performance standards are shown on the left hand side of the table
presented in the table below:
Project Objectives
Project Management
Strategies
Ends, Aims, Targets,
Goals, Baseline
Performance Standards
Means, Methods, Plans
Management Intentions
SCOPE - Results
TIME - Deadlines
COST - Budgets
Vs.
Client's
Choices
Configuration designs
Working Schedules
Estimates, resource
assignments
Project Manager's
Choices
The choice of these three measures as tests of success is consistent with Cleland's19 contention
that project success is meaningful only if the scope (technical performance) objective was
obtained on time and within budget, and provided that it made a contribution to the strategic
mission of the enterprise. Satisfying the latter criterion normally is not an exclusive duty of
the project team. These measures also agree with McCoy's20 proposal that project
performance be measured against an integrated baseline which incorporates criteria that
cover "all three dimensions of a project (i.e. cost, scope and schedule)".
The objectives of scope, time, and cost shown in the table include both objectives and goals,
as defined by Cleland. These are the second and third highest layers of his pyramidal model.
Together with the organizational mission, the topmost layer, they constitute the triad of
organizational direction," and by implication, they have the authority of approval from outside
the project team. On the right hand side of the table are strategies decisions made within the
project team regarding design configurations, courses of action, and resource allocations as
means of achieving the goals and objectives.
7.1 Compile scope documentation in accordance with instructions and procedures
A Scope document is one of those fundamental documents that define and guide any major
project.
The Scope comes right after the Vision document:

The Vision document expresses what the company/project ideally and ultimately
tries to accomplish, if no limits (time, staff, finances, technology, etc.) were involved.

The Scope document, on the other hand, is all about realistic limits, boundaries, and
how to achieve the project’s goals despite such limitations. That’s why
most scope documents also do include a section on risk analysis and management.
19
Cleland, D.I. Measuring Project Success: The Owner's Viewpoint. Proceedings of the 1986 Seminar/Symposium
Drexel Hill, PA: The Project Management Institute, 1986, p6
20
McCoy, F.A. Measuring Success. Establishing and Maintaining a Baseline. Proceedings of the 1986
Seminar/Symposium Drexel Hill, PA: The Project Management Institute, 1986, p47
121
Version 1
Learner Guide
The worst-case scenarios and how to cope with them are usually included with a Scope
document as well.
Scope documents differ widely from one project to another, but the detailed project scope
statement usually includes, either directly or by reference to other documents, the following:

Project objectives: Project objectives include the measurable success criteria of the
project. Projects may have a wide variety of business, cost, schedule, technical, and
quality objectives. Project objectives can also include cost, schedule, and quality
targets. Each project objective has attributes such as cost, a metric such as rands, an
absolute or relative value such as less than 1.5 million rands.

Product scope description: Describes the characteristics of the product, service, or
result that the project was undertaken to create. These characteristics will generally
have less detail in early phases and more detail in later phases as the product
characteristics are progressively elaborated. While the form and substance of the
characteristics will vary, the scope description should always provide sufficient detail
to support later project scope planning.

Project requirements: Describe the conditions or capabilities that must be met or
possessed by the deliverables of the project to satisfy a contract, standard,
specification, or other formally imposed documents. Stakeholder analyses of all
stakeholder needs, wants, and expectations are translated into prioritised
requirements.

Project boundaries: Identify generally what is included within the project. It states
explicitly what is excluded from the project, if a stakeholder might assume that a
particular product, service, or result could be a component of the project.

Project deliverables: Deliverables include both the outputs that comprise the product
or service of the project, as well as ancillary results, such as project management
reports and documentation. Depending on the project scope statement, the
deliverables may be described at a summary level or in great detail.

Product acceptance criteria: Define the process and criteria for accepting completed
products.

Project constraints: List and describe the specific project constraints associated with
the project scope that limit the team’s options. For example, a predefined budget or
any imposed dates (schedule milestones) that are issued by the customer or
performing organisation are included. When a project is performed under contract,
contractual provisions will generally be constraints. The constraints listed in the
detailed project scope statement are typically more numerous and more detailed than
the constraints listed in the project charter.

Project assumptions: List and describe the specific project assumptions associated
with the project scope and the potential impact of those assumptions if they prove to
be false. Project teams frequently identify, document, and validate assumptions as
part of their planning process. The assumptions listed in the detailed project scope
statement are typically more numerous and more detailed than the assumptions listed
in the project charter.
122
Version 1
Learner Guide

Initial project organisation: The members of the project team, as well as stakeholders,
are identified. The organisation of the project is also documented.

Initial defined risks: Identify the known risks.

Schedule milestones: The customer or performing organisation can identify
milestones and can place imposed dates on those schedule milestones. These dates
can be addressed as schedule constraints.

Fund limitation: Describes any limitation placed upon funding for the project, whether
in total value or over specified time frames.

Cost estimate: The project’s cost estimate factors into the project’s expected overall
cost.

Project configuration management requirements: Describe the level of configuration
management and change control to be implemented on the project.

Project specifications: Identify those specification documents with which the project
should comply.

Approval requirements: Identify approval requirements that can be applied to items
such as project objectives, deliverables, documents, and work.
7.2 Ensure that scope document contains a rudimentary sequence of events and/or
milestones
Project Scope Management21 includes the processes required to ensure that the project
includes all the work required, and only the work required, to complete the project
successfully. Project scope management is primarily concerned with defining and controlling
what is and is not included in the project.
Defining and managing the project scope influences the project’s overall success. Each project
requires a careful balance of tools, data sources, methodologies, processes and procedures,
and other factors to ensure that the effort expended on scoping activities is commensurate
with the project’s size, complexity, and importance. For example, a critical project could merit
formal, thorough, and time-intensive scoping activities, while a routine project could require
substantially less documentation and scrutiny.
The project management team documents these scope management decisions in the project
scope management plan.
The project scope management plan is a planning tool describing how the team will:

Define the project scope

Develop the detailed project scope statement

Define and develop the work breakdown structure (WBS)

Verify the project scope, and
21Adapted
from: http://www.tensteppb.com/5.0ProjectScopeManagement.htm
123
Version 1
Learner Guide

Control the project scope.
124
Version 1
Learner Guide
The project scope management plan provides guidance on how project scope will be defined,
documented, verified, managed, and controlled by the project management team. The
components of a project scope management plan include:

A process to prepare a detailed project scope statement based upon the preliminary
project scope statement

A process that enables the creation of the WBS from the detailed project scope
statement, and establishes how the WBS will be maintained and approved

A process that specifies how formal verification and acceptance of the completed
project deliverables will be obtained

A process to control how requests for changes to the detailed project scope statement
will be processed. A project scope management plan is contained in, or is a subsidiary
of, the project management plan. The project scope management plan can be informal
and broadly framed, or formal and highly detailed, based on the needs of the project.
The preparation of a detailed project scope statement is critical to project success and builds
upon the major deliverables, assumptions, and constraints that are documented during
project initiation in the preliminary project scope statement.
During planning, the project scope is defined and described with greater specificity because
more information about the project is known. Stakeholder needs, wants, and expectations are
analysed and converted into requirements. The assumptions and constraints are analysed for
completeness, with additional assumptions and constraints added as necessary.
All projects should spend time up-front in a definition step. There is not a lot of information
required to define a small project and therefore this work is usually pretty short. However, as
the project becomes bigger and bigger, the need to fully understand what is being requested
is more important, and gaining agreement on what is to be delivered is more difficult.
Therefore, more time needs to be spent planning the work.
It should make sense that small projects need a shorter planning cycle and larger projects need
a longer planning cycle. The effort required to plan the project depends on the amount of
information, and the level of detail, that needs to be understood and documented. The
duration required to define the work depends on the length of time necessary to discover and
document the information, as well as the time required to gain agreement and approval from
the client. At times, the project manager can get frustrated because of the difficulty in gaining
agreement with the client on scope, timeline and cost. But that is exactly the reason this work
is done ahead of time. Think of the problems you will encounter trying to gain agreement with
the client on scope, schedule or cost when the work has started and the deliverables are
actually being produced.
Before the project lifecycle begins (analysis, design, construct, etc.), a number of items need
to be in place. For smaller projects, many of these conditions are met informally or implicitly.
However, the larger a project gets, the more important it is that these criteria be met formally
and explicitly.

Client gives approval to begin planning. Normally, implicit approval is assumed to have
occurred for the project to even get this far to begin with. However, if the project did
125
Version 1
Learner Guide
not have a business case prepared and if it did not go through an authorisation
process, then explicit approval should be sought before project planning begins.

Project is formally defined. This is documented in the Project Definition, which
contains objectives, scope, assumptions, deliverables, budget, etc. (For medium or
small projects, this might be the Abbreviated Project Definition or a Service Request.)

Project work plan (schedule) is created. A work plan must be prepared and used to
manage the effort. This includes checkpoints, or milestones, when the project can be
evaluated to ensure that it is appropriate to continue.

Client gives approval to begin project. This is signified through an approved Project
Definition. The Sponsor should sign the document to ensure agreement.

Project Management Procedures are defined and approved. Procedures must be in
place to describe how the project manager will manage issues, communication, risks,
quality, scope, etc. This is especially true for large projects and less important as a
project gets smaller.

Project team resources are assigned. You must have the right people to staff and
execute the project. Sometimes valid, approved projects must be delayed because
people with the right skills are not available.
Small projects
The definition of small projects covers many types of work. In most companies, these small
projects are not viewed as “projects” at all, but in fact they meet all the criteria of a project:
the work is unique, has a beginning and end-date, results in the creation of a deliverable, etc.
It’s just that the work is small and so the project itself is small.
In many organisations, small projects are considered a part of support or operations, because
they originate with some type of problem or failure to a production process. Sometimes it is
critical to resolve them immediately, and sometimes the failure is minor and can be allowed
to continue unresolved for a long time.
It can sometimes be hard to decide whether a small piece of work should be managed as a
support request or managed as a small project. One should look at whether there is discretion
in when the work is completed. If a problem arises that requires a fix to be performed quickly,
the work is definitely support. If a problem arises that can be prioritised and worked on some
time in the future, it is considered a small project.
In general then, small projects can include the following:

Unique work efforts that are clearly projects but have a short duration and small
numbers of effort hours.

Enhancements to existing production processes and systems.

Bugs and errors in production processes that are nuisances, but can be scheduled for
resolution at a later time. That is, fixing the problem is a lower business priority than
other work.
126
Version 1
Learner Guide

Small process improvements.

Discovery or fact-finding work that may lead to further Service Requests or a project.

Small changes to production processes that are the result of legal, tax or auditing
requirements. These requests may not be considered enhancements, since they do
not provide any additional business value. However, they fit the definition of a project.
If work is classified as a discretionary small project, it does not diminish the criticality or the
value of the request. It only means that there is discretion as to when the work gets done. For
example, if a request is important enough, it may push to the top of the work queue and be
started immediately. However, later an even more urgent request could come up that would
require the other request to be put on hold. The nature of discretionary work is that it is
subject to prioritisation decisions. This is in contrast to true support work. If a production
process is down, or is producing inaccurate results, typically the problem needs to be resolved
immediately, and cannot be stopped because of a discretionary request.
In general, all small discretionary work can be documented, evaluated and prioritised through
a Service Request Process.
In a small project, there is usually not a lot of effort associated with formally defining the work.
However, some definition work still needs to be done. The result of this short definition is a
one-to-two page document called a Service Request.
Along with a much shorter project definition, the process for assigning the work is different as
well. When the work definition for a larger project is completed, the project is usually ready
to begin. However, for smaller efforts, there may be many more Service Requests than can
actually be worked on at any given time. Therefore, a process needs to be established for
gathering Service Requests and assigning them to team members based on client priorities.
Since there will likely be many Service Requests, it is important to have some way to keep track
of them, and a way to ensure that the higher priority requests are being worked on.
The following Service Request Process can be used:
1. Client submits the request. The client, with the help of the project manager if
necessary, completes a simple Service Request form that documents the work
requested. Even though the work may be small, the Service Request serves as the
formal document describing the work to be done and contains the appropriate client
approvals. A Service Request typically contains the work that is requested, the priority
of the work and the business value of the work.
2. Project manager reviews and clarifies. The project manager reviews the Service
Request to ensure that the work is understood. The project manager asks questions
of the client if necessary, to clarify what is being requested. The project manager must
also understand the criticality of the request and whether any prerequisite work needs
to be completed first.
3. A high-level estimate of effort, cost and duration is prepared.

If the project manager understands the work well enough, and if he or she
has the proper level of expertise, s/he provides a high-level estimate of the
hours and duration and includes this information on the Service Request. It is
127
Version 1
Learner Guide
possible that once the client sees the estimated effort, s/he may change
his/her mind regarding the relative priority. For instance, if the effort is much
larger than the client realised, the priority may be lowered. If the estimate is
much smaller than the client realised, s/he may raise the priority higher so
that the work can be completed sooner.

If the project manager cannot estimate the work, s/he assigns a team member
to create the estimates. If no one on the team has the time or expertise to
create a high-level estimate, then the estimation process must itself be placed
on the backlog. The client must decide if the effort required gathering
information to create the estimate is of a high enough priority that s/he is
willing to assign a team member to work on it rather than other Service
Requests. This high-level estimate is used for prioritisation purposes only.
When the work is actually assigned, a more detailed estimate can be
prepared, if necessary.
4. The request is assigned or backlogged. The project manager and client evaluate the
request against the other work that is assigned and on the backlog. They also review
the available capacity and skills on the team to determine if the work can be started
immediately. If the required resources are not available, or if the work is of lower
priority than other Service Requests, the new request is placed on a backlog list. The
backlog contains all work that has been requested, estimated and prioritised, but is
not assigned to begin yet.
5. Periodically review the backlogged work. The project manager and client review the
backlog on a regular basis, probably weekly, bi-weekly or monthly. During this review,
requests on the backlog should be reprioritised taking into account new Service
Requests, completed Service Requests and the current realities. When the priority of
a Service Request is high enough and the right resources are available, the work can
be assigned to begin. If a Service Request on the backlog is more critical than work
that is in-progress, the previously assigned work is placed on-hold, put back on the
backlog or used as filler while the new request is begun.
6. Revalidate the initial information. When the work is assigned to begin, the person(s)
doing the work should validate that the information on the Service Request is correct
and that the estimates are accurate. If they are not, the new information should be
documented and discussed immediately to see if it will have an impact on the
priority. For instance, the client may want to proceed with a small project of 40 hours.
However, if the more detailed estimate ends up closer to 80 hours, they may not want
to perform the work at that time. There may be other requests that are more critical
and take less time to complete.
7. Execute the work. If the work is still approved after the details of the request are
validated, the actual execution of the work begins. This would follow a typical short
lifecycle for a small project.
8. Manage the work.
9. Close the work. When the work is completed, the client should signify his/her
approval. The Service Request should then be closed and moved to a closed queue
128
Version 1
Learner Guide
that tracks these requests for historical purposes. The new or modified deliverables
can be moved into production. This move may happen immediately, on a scheduled
basis or as a part of a new release. In some organisations, the Service Request is not
closed until the client signs off again to signify that the deliverables are working as
expected in production.
129
Version 1
Learner Guide
Medium Projects
The project needs to be defined clearly, but the resulting deliverable does not need to be as
long or as detailed as a formal Project Definition. For a medium-sized project, an Abbreviated
Project Definition is utilised instead. It is usually straightforward to uncover the information
needed to define a medium-sized project.
1. Look for all the information that may already be available for this project. This includes
any previous project deliverables, memos, e-mails, etc. In many cases, before the
project begins, the client must perform some type of high-level cost/benefit analysis
or value proposition, although this might not be mandatory for these medium
projects. All of this information should be gathered as a starting point for
understanding the work to be done.
2. Work with your manager and the project sponsor to understand the approval process
for the Abbreviated Project Definition. For instance, determine whether the sponsor
wants to approve the definition before other stakeholders, or whether the sponsor
wants to have the final approval after other stakeholders have reviewed the
information. You should also determine people that actually have to approve the
document versus those that should just receive a final copy. This is important for
medium projects because they often are too small to require much sponsor and
management oversight. Therefore, the deliverable approval process may be different
than what you would expect of a larger project.
3. Meet with the appropriate stakeholders (managers, clients, interested parties) and try
to understand their perceptions of the work requested. Before you meet with the
various stakeholders, make sure that you are familiar with the basic information that
is required to define a project of this size. If you are not sure of the information to
gather, you will not be prepared to ask the right questions. In general, this information
includes:

Project Overview. State the purpose of the project and why it is being
performed.

Scope. Define the deliverables created by this project and provide some
explanation regarding what the deliverable will look like. Scope can be defined
in many ways but the focus for medium projects should be on the deliverables.

Estimated Effort Hours. Estimate the effort required, and provide information
on how the estimate was prepared.

Estimated Duration. Once the effort hours are known, you can estimate how
long the project will take to complete (duration) based on an assumption of
how many resources will be applied. If the start date is known, the estimated
end-date can be determined as well.

Estimated Cost. Estimate the cost for labour based on the effort hours, and
add any non-labour expense such as hardware, software, training, travel, etc.

Major Assumptions. Assumptions are external events or conditions that must
occur for the project to be successful. If it looks more than likely that these
130
Version 1
Learner Guide
events will occur then they should be listed as assumptions. Assumptions can
be identified through the experience of knowing the types of conditions or
events that are likely to occur over the life of the project; brainstorming
sessions with the clients, stakeholders and team members; and by looking at
items that were identified as low risk in the risk management process.

Major Risks. Risks are future, external conditions or events that will cause
problems to the project if they occur. If there is a good likelihood that any of
these events will occur, they should be identified as risks.
4. Create your first draft of the Abbreviated Project Definition. Make sure you write the
content for the benefit of the reader – not for your benefit. The information should be
easily understood by the reader.
5. Start a draft of the project work plan and budget, giving as much information as is
known at this time. Information from the work plan is used as input into the
Abbreviated Project Definition and information from the Abbreviated Project
Definition is used to help build the work plan and budget.
6. Document the Project Management Procedures for this project. It is important to
document the procedures ahead of time and get buy-in from management, clients and
stakeholders. For instance, it is much easier to resolve a scope change request by
following an approved procedure than by having to invent the procedure and resolve
the scope change at the same time. These procedures do not need to be elaborate,
given the size of project you are defining. If you have a set of Project Management
Procedures from a similar project, or if your organisation has a common set of
procedures defined already, use them instead.
7. (Optional) Circulate the Abbreviated Project Definition and Project Management
Procedures in draft form to gather feedback and build consensus. The first drafts may
go to a small group of interested parties. The project work plan does not normally
need to be circulated unless there is a specific request to look at it. This step is optional
since a medium-sized project may not be very large or complex. It is possible that the
initial draft of the Abbreviated Project Definition can be sent directly to the Sponsor
for approval.
8. (Optional) Update the documents based on accumulated feedback.
9. (Optional) Circulate the revised documents to a larger group of interested parties for
one more round of feedback. Update the documents again based on this feedback.
10. Start the approval process.
11. After the approval process is complete, circulate copies of the approved Abbreviated
Project Definition and Project Management Procedures to all interested stakeholders.
12. Execute the work.
13. Manage the work. Once the work begins, it is managed through the Manage the Work
processes (manage scope, communication, risk, etc.). Since the work is medium-sized,
these project management processes should be utilised in a scalable manner as
needed. Generic procedures can be established to manage all medium sized projects.
131
Version 1
Learner Guide
14. Close the work. At some point after implementation, the work is completed and the
client should signify his/her approval and acceptance of the solution in writing. The
project should then be closed.
132
Version 1
Learner Guide
Large Projects
Large projects definitely need time up-front to define the work. If you do not adequately define
a small or medium project, the consequences will probably not be too drastic.
Even if your project is estimated to take 500 hours of effort, and it takes twice as long to
complete the work, it still won’t be catastrophic for your company.
However, you don’t have that same luxury in a large project. For instance, if you estimate the
work at 10,000 hours based on an inadequate definition process, and the actual project takes
20,000 hours instead, the results could have a material impact on your organisation and your
entire company.
In general, the larger a project is, the more time it takes to define the work. You need to have
enough information defined and documented so that you can gain agreement with your
sponsor on the project objectives, the deliverables, the estimated cost and duration, the
scope, etc.
The process of defining a large project is similar to that of a medium sized project. The
difference is that there is more information necessary to define, and the length of time
required to complete the definition process is necessarily longer and more complex.
The process for defining a large project is as follows:
1. Look for all the information that may already be available for this project. This includes
any previous project deliverables, memos, e-mails, etc. In many cases, before the
project begins, the client must perform some type of high-level cost/benefit analysis,
Business Case or value proposition. All of this information should be gathered as a
starting point for understanding the work to be done.
2. Work with your manager and the project sponsor to understand the approval process
for the Project Definition. For instance, determine whether the sponsor wants to
approve the definition before other stakeholders, or whether the sponsor wants to
have the final approval after the other stakeholders have reviewed the work. You
should also determine the people that actually have to approve the Project Definition
versus those that should just receive a final copy.
3. Meet with the appropriate stakeholders (managers, clients, interested parties) and try
to understand their perceptions of the work being requested. Before you meet with
the various stakeholders, make sure that you are familiar with the basic information
that is required to define a project of this size. If you are not sure of the information
to gather, you will not be prepared to ask the right questions. In general, this
information includes:

Executive Summary (optional). The full Project Definition document may tend
to become large and difficult for the senior managers to digest. You can
include an Executive Summary for managers to read. The Executive Summary
is an overview of the actual Project Definition document. It is not just an
overview of the project.
133
Version 1
Learner Guide

Project Overview. State the purpose of the project and what it is trying to
achieve. Add the business benefit of the project. Share the overall business
goals that this project is contributing to.

Project Objectives. State the objectives that the project will achieve. The
project objective should support the business goals and objectives. The
deliverables produced should support the project objectives.

Project Scope. Define the deliverables created by this project and provide
some explanation regarding what the deliverable will look like. Also add
information that describes what the project will not produce. In other words,
what is out of scope? It is very important to be clear about what things the
project could produce, but will not. This will make it much easier to manage
scope change throughout the project. In addition to the deliverables, you
should further describe scope in more specific terms such as:
o
The data the project needs and the data that is out of scope.
o
The organisations affected and those that are not affected.
o
The business processes that are in scope and out of scope.
o
The business transactions that are in scope and out of scope.
o
Describe any other projects that are impacted.
o
Define any other in-scope / out-of-scope qualifiers that make
sense.

Estimated Effort Hours. Estimate the effort required, and provide information
on how the estimate was prepared. You may need to be working on the work
plan at the same time to be able to provide an accurate estimate (+/- 10%).

Estimated Duration. Once the effort hours are known, you can estimate how
long the project will take to complete (duration) based on an assumption of
how many resources will be applied. If the start date is known, the estimated
end-date can be determined as well. You may need to be working on the work
plan at the same time to be able to provide an accurate estimate (+/- 10%).

Estimated Cost. Estimate the cost for labour based on the effort hours, and
add any non-labour expenses, such as hardware, software, training, travel,
etc. You may need to be working on the work plan at the same time to be able
to provide an accurate estimate (+/- 10%).

Major Assumptions. Assumptions are external conditions or events that must
occur for the project to be successful. If it looks more than likely that these
events will occur, they should be listed as assumptions. Assumptions can be
identified through your own experience of knowing the activities or conditions
that are likely to occur in your organisation over the life of the project;
brainstorming sessions with the clients, stakeholders and team members; and
by looking at items that were identified as low risk in the risk management
process.
134
Version 1
Learner Guide

Major Risks. Risks are future, external conditions or events that will cause
problems to the project if they occur. If there is a good likelihood that any of
these events will occur then they should be identified as a risk.

Approach. At a high level, describe in words the information that is
represented in the project work plan. This information is for the benefit of the
client and stakeholders that will not be able to easily interpret the actual work
plan. You should describe major project phases and milestones, and the
general sequence of the work. You should also communicate when the major
deliverables will be produced. Also take some time to explain any interesting
or out-of-the-ordinary techniques that will be utilised on the project.
Depending on the size of your project, this section could be fairly long, but
should not go over two pages.

Project Organisation. The organisation chart for a large project usually has
many boxes that reflect involvement from various stakeholders. For instance,
the project may have a formal project manager from the client organisation
that also reports to the project sponsor. There may be a high-level Executive
Sponsor, as well as a lower-level project sponsor to represent the sponsor on
a day-to-day basis. Key stakeholders may be organised into a Steering
Committee to provide overall strategic guidance to the project. Vendors or
suppliers may have a formal role and would need to be represented in the
organisational structure. Large projects may also benefit from defining how
deliverables get created and approved.
4. Create your first draft of the Project Definition. Make sure you write the content for
the benefit of the reader- not for your benefit. The information should be easily
understood by the reader.
5. A draft of the project work plan and budget should be started, giving as much
information as is known at this time. Information from the work plan is used as input
into the Project Definition, and information from the Project Definition is used to help
build the work plan and budget.
6. Document the Project Management Procedures for this project. It is important to
document them ahead of time and get buy-in from management, clients and
stakeholders. For instance, it is much easier to resolve a scope change request by
following an approved procedure than by having to invent the procedure and resolve
the scope change at the same time. The larger your project, the more formal and
disciplined your Project Management Procedures need to be. If you have procedures
defined from a similar project, or if your organisation has a common set of procedures
defined already for large projects, use them as your starting point.
7. If you are purchasing goods or services on your project, you should determine your
project procurement strategy and plans. In some cases, you will simply follow the
procurement contracts and plans that are already established by your company or
your organisation. For instance, you may purchase hardware from companies using a
standard company contract. You may acquire contactors using your company’s
preferred vendor list under prior master contractor agreements. In some cases, you
135
Version 1
Learner Guide
will need to work with your Procurement Department to establish your own projectlevel vendor management plans. Most project teams consider the vendor
identification and vendor selection processes to be part of the actual execution of the
project. In other words, they are done in the initial Analysis Phase after the project
execution has started. However, there may be times when you need to perform these
activities as a part of your up-front project definition process.
8. Circulate the Project Definition and Project Management Procedures in draft form to
gather feedback and build consensus. The first drafts may go to a small group of
interested parties. The project work plan does not normally need to be circulated
unless there is a specific request to look at it.
9. Update the documents based on accumulated feedback.
10. Circulate the revised documents to a larger group of interested parties for one more
round of feedback. Update the documents again based on this feedback.
11. Start the approval process.
12. After the approval process is complete, circulate copies of the approved Project
Definition and Project Management Procedures to all interested stakeholders.
13. Execute the work. The project is now ready to officially begin. This would follow a
typical lifecycle based on the characteristics of the project.
14. Manage the work. Once the work begins, it is managed through the Manage the Work
processes (manage scope, communication, risk, etc.). Since the work is large, these
project management processes should be utilised in a scalable manner as needed.
Generic procedures can be established to manage all large projects.
15. Close the work. At some point after implementation, the work is completed and the
clients should signify their approval and acceptance of the solution in writing. The
project should then be closed.
7.3 Ensure that scope document is communicated to stakeholders for approval
If a team doesn’t really understand the context in which a project is being run, they’re more
likely to make bad decisions over the course of the project. These bad decisions cost the team
valuable time to correct - or, if left uncorrected, cost the team goodwill with users when the
project doesn’t meet their needs.
Without a good understanding of the real scope of the project, the only thing that the team
sees is the urgency, and they lose track of the needs they’re trying to fill.
Members can see the individual problems that they are working to solve, but lose track of the
big picture. And this is the single biggest source of delays and project failure.
Luckily, there is a straightforward and easy-to-implement practice that can help the team
avoid these problems. Writing a vision and scope document (see Appendix A) should take
less than a day, but will help the team avoid weeks of rework and false starts.
136
Version 1
Learner Guide
The first step in writing a vision and scope document is to talk to project stakeholders.
Stakeholders are generally happy to talk about what they need.
The vision and scope document should be brief, no more than a couple of pages.
The Project Background section is a summary of the problem that the project solves. It should
provide a brief history of the problem and an explanation of how the organisation justified the
decision to embark on the project to address it. This section should cover the reasons why the
problem exists, the organisation’s history with this problem, any previous projects that were
undertaken to try to address it, and the way that the decision to begin this project was
reached.
The Stakeholders section is a bulleted list of the stakeholders. Each stakeholder may be
referred to by name, title, or role (“support group manager,” “SCTO,” “senior manager”). The
needs of each stakeholder are described in a few sentences.
The needs of the stakeholders are the most important part of this document. Unless the team
understands the needs that drive the project, they may end up with a narrow focus, causing
them to waste time addressing problems that are of little importance to the stakeholders.
The “vision” part of the vision and scope document refers to a description of the goal of the
project.
The team must identify the needs of the stakeholders and write down a Vision Statement (a
general statement describing how those needs will be filled).
The goal of the Vision Statement section is to describe what the project is expected to
accomplish. It should explain the purpose of the project. This should be a compelling reason,
a solid justification for spending time, money, and resources on the project.
As mentioned before, communication leads to understanding and commitment.
7.4 Record measures for project success in the agreed format
In order to measure success, we must first define it. Questions we will
be asked are:

Was the project finished within budget, on time, and
according to the specifications?

Did it meet quality criteria?

Were the stakeholders satisfied?
Dimensions of Project Success
In the same way that quality requires both conformance to the specifications and fitness for
use, project success requires a combination of product success and project management
success:

Was the product (service, result, or outcome) of the project a success?
137
Version 1
Learner Guide

Was the project well-managed?
Simple yes-or-no answers will not suffice. We should not be asking "was your project a
success?" We should be asking "how successful was your project?"
Different stakeholders will use different measures. The health and safety officer wants no
injuries. The manufacturing manager wants a product that is easy to build. The ISO 9000
compliance team cries "success" if the documentation is complete. The Marketing manager
will be delighted if you get to market before your competition.
So what is the format for developing project success criteria?
Here are a few examples:

Stock introduction: "one key success measure for this project is to have …"

Measurable item: "the completion date of every major milestone"

Comparison statement: "within"

Some number: "one week of the baseline schedule date"
Most projects will have at least three measures of project management success - one each for
cost, schedule, and stakeholder satisfaction. Larger projects may have more, but three is the
minimum.
Product Success
Useful product success measures are often hard to define. Many of the potential measures
such as revenue and cost savings are beyond the direct control of the project team and will
not be measurable until long after the project is finished. When this is the case, the team must
determine what it can influence. For example:

With a consumer product, unit manufacturing cost may be key.

For a web-based software application, 100% compliance with public standards might
be the target.

On an information technology project, training may be vital to user acceptance.
Use the following checklist to help ensure that your measures are good measures. They should
be:

Complete - anything unmeasured is likely to be compromised.

Relevant - variances clearly indicate a need for corrective action.

Valid - measuring what you intended to measure.

Easy to understand - so that people will accept them.

Economical to obtain - know the value of the information.

Timely - in comparison to the result measured.
138
Version 1
Learner Guide
The bottom-line is this. Your project will be measured. Your stakeholders will decide whether
it was well-managed. Someone will decide whether or not the project of your project was a
success. Do yourself, your team, and your organisation a favour and get these measures
documented and agreed to right from the start.
Class Activity 7: Contribute to preparing and producing inputs to be used for
further planning activities
Individually or in groups as per your facilitator’s instructions, complete the
formative activities in your Workbook
139
Version 1
Learner Guide
Module 8
Monitor achievement of the project’s scope
After completing this module, the learner will be able to contribute to the monitoring of the
achievement of the project’s scope, by successfully completing the following:

Ensure that feedback of progress towards delivering the scope is communicated in
agreed manner

Identify deviations from scope and communicate opportunities for corrective action
or improvement to the relevant individuals/teams

Identify, analyse, describe and report the impact of scope change according to agreed
procedures

Process approved change requests to scope in accordance with project change control
procedures

Verify project deliverables as complete as per agreed scope definition or specified
requirements
140
Version 1
Learner Guide
Monitor achievement of the project’s scope
Monitoring is performed while a project is
being implemented, with the aim of
improving the project design and
functioning while in action. It is the
continuous observation of a project’s
progress by systematically gathering key
performance data for regular analysis.
The aim of monitoring is to determine the
relevance and level of achievement of
project
objectives,
development
effectiveness, efficiency, impact and
sustainability.
8.1 Ensure that feedback of progress towards delivering the scope is communicated
in agreed manner
Feedback is essential, but easily forgotten in the hustle and bustle of meeting project
deadlines. If the project manager does not keep giving feedback, the slightest hint (or rumour)
of not sticking to the stakes, may set a stakeholder against the project.
Feedback during the course of the project could take the following forms:

Tests - This part of the process ensures that defects or variances are recognised as
soon as possible. A big culprit on any project is having either too little testing or, in
many cases—if a test team is involved—testing too late in the process. Both testing
and quality assurance feedback need to be built into the project from the day the
project is launched.

Prototypes - A prototype typically simulates only a few aspects of the final
solution/product, and may be completely different from the final product.
Prototyping has several benefits: The designer and/or implementer can get valuable
feedback from the users early in the project. The client and the contractor can
compare if the prototype matches the specification, according to which the product
is built. It also allows the developer some insight into the accuracy of initial project
estimates and whether the deadlines and milestones proposed can be successfully
met.

Reports - project status reports give feedback on:
o
o
o
o
o
o
Project Schedule. Is it on time? When is it likely to finish?
Project Budget. Are your expenses within budget?
Project Staffing. How much effort has been used to date?
Project Deliverables. Have they met the quality targets set?
Project Risks. Will any risks likely affect the project?
Project Issues. Are any issues impacting the project?
141
Version 1
Learner Guide

Evaluations - Project Evaluation is a step-by-step process of collecting, recording and
organising information about project results, including short-term outputs
(immediate results of activities, or project deliverables), and immediate and longerterm project outcomes (changes in behaviour, practice or policy resulting from the
project).
142
Version 1
Learner Guide
Common rationales for conducting an evaluation are:
o
o
o
o
o
response to demands for accountability;
demonstration of effective, efficient and equitable use of financial and other
resources;
recognition of actual changes and progress made;
identification of success factors, need for improvement or where expected
outcomes are unrealistic;
validation for project staff and partners that desired outcomes are being
achieved.

Benchmarks - the project manager uses data collected and the experiences of
stakeholders to compare results with best practice and identify effective
improvement strategies

Performance feedback - Tom Ferguson suggests the following:
Project management is a tough job. Where else would you be expected to manage something that
is temporary, has not been done before, is loosely defined, is constantly changing, is laden with
complexity risk and unrealistic expectations and is set within fixed constraints including resources,
budget, time, process, organisation and culture?
Projects depend very much on the team and teamwork. One of the fundamental roles of the
project manager is to provide feedback to team members on their performance. Feedback is
supposed to show someone the impact of their behaviour with a view to helping them improve
performance in the future.
Many of us do not know how to do feedback properly. This is not surprising as we tend to get very
little practice. It is very common for feedback to be given rarely or for it to be part of an annual
performance review process. Feedback is often therefore, too little, too late. And many of us avoid
giving feedback altogether as we see it as a potential source of conflict. The problem is that poorly
delivered feedback can alienate team members and stop them functioning effectively. And the
malaise can spread quickly through the team.
Part of the problem is the 'back' in feedback. Feedback tends to focus on past events. As such, it
can be a limited and static affair. In projects, we cannot afford to be limited or static or to focus on
the past. While we might hope to learn from the past, it's history and can't be changed. So given
these difficulties, why not try a little Feedforward?
Feedforward is a term coined by Marshal Goldsmith in his article "Try Feedforward Instead of
Feedback". Feedforward has a helping perspective and focuses on the future. It is thus particularly
suitable for a project environment for the following reasons:

The focus must always be on the future and the next deadline.

We can't afford to lose anyone - everyone must be kept on board.

Often we are stuck with the resources that we have and we must make the most of them.

Team morale can be delicately balanced and poorly delivered feedback can be a tipping
point.
143
Version 1
Learner Guide

We must be resilient. Project teams must have a high bounceability quotient. The
alienation caused by poorly delivered feedback can impact on a team's ability to bounce
back.
There are many good reasons to try a little Feedforward with your project teams including:
1.
It comes from a much more positive perspective i.e. we are all in this together so let's help
each other out. This changes the whole dynamic of the relationship.
2. It is not judgemental.
3. The negative connotations of past failures are banished. There is no such thing as failure
just Feedforward.
4. It is much easier to deliver. People are less defensive when discussing future performance.
Feedforward is taken less personally and provokes less resistance.
5. It is faster. Dwelling on past events can consume a lot of time. It can be much quicker to
suggest a few well thought out ideas for the future.
6. The past is history, today is the present and tomorrow is an adventure. We can only
change our behaviours from today onwards. What's the point in focusing on past failures?
Isn't it much better to focus on the future we desire?
7. Feedforward is much more aligned with coaching and is therefore better at building the
kind of relationships needed to develop the team towards maximum performance.
8. Most people actually like to be helped to improve their performance as this will ultimately
make them more successful in their careers.
9. Communication, the soul of successful projects, will be greatly enhanced.
10. Why invest time and energy in something that we all hate?
Consider the following example from an IT project.
A team member called Tom was responsible for installing and configuring a new server. During the
install, Tom forgot to install the anti-virus software. As a result, the server became infected with
multiple viruses and ground to a halt. The problems were difficult to diagnose and fix and the
project lost two full days from the schedule due to the testing phase being interrupted.
What is the project manager Bob, to do with Tom? The feedback approach will delve into what
happened, the consequences and the impact on the schedule. The negatives are restated and
emphasised. Let me ask you this question? In situations like this, who usually knows most about
the facts of what happened and the consequences? Of course, its Tom and Tom will more than
likely deeply regret his error and most definitely will not make that mistake again. So it can be
reasonably stated that this approach is useless.
Now let's try Feedforward. The Feedforward approach will focus on the future. Remember, there is
no such thing as failure, just Feedforward. Bob might say something like the following to Tom. "I
remember when I was a techie, I used to compile a checklist of tasks when installing servers. There
are so many things to be considered, that it is very easy to forget about something. Actually, it
would be great for this project and future projects if we had a standard checklist for all installs".
This is a completely different approach. Tom will more than likely see this as a great idea that he
will take on board. He will probably also see this as an opportunity to do something that will help
him and others now and in the future. The whole situation has been turned around and has
become an opportunity for Tom to develop, grow and shine! And just look at the positive results
for relationships. Tom's and Bob's relationship can only be stronger. When the news spreads
around the wider team, it will most likely strengthen more relationships and the regard the team
have for Bob.
144
Version 1
Learner Guide
Altogether a much better outcome, wouldn't you think?
Source: http://www.projecttimes.com/communication/forget-about-project-feedback-try-feedforward.html
145
Version 1
Learner Guide
8.2 Identify deviations from scope and communicate opportunities for corrective
action or improvement to the relevant individuals/teams
Every project depends upon specifications being firmly locked down prior to any work being
undertaken. Failure to do so is a leading cause for project failure.
You need to identify deviations from scope and communicate opportunities for corrective
action or improvement to the relevant individuals/teams.
Some of the most common deviations are:

Schedule slippage: Many times, project schedules spiral out of control when dates
and deliverables aren’t aggressively monitored and tracked on a daily basis. All too
often, managers leave issues unresolved for days, which then results in schedule
overruns.

Budget overrun: Projects that run over budget are sometimes more prone to being
cancelled because senior executives are concerned about cash going into and out of
company coffers. If a project starts showing gradual cost overruns, the project is often
still given a chance, but, as the losses mount and show no sign of recovery, cancelling
the project may be necessary. In reality, though, some projects are so critical to
business survival that they can’t be stopped. Therefore, the cost overruns are simply
absorbed or skilfully transferred elsewhere. This means that project managers must
manage their actual budgets against the planned budget and keep their stakeholders
aware of any deviation.

Scope creep: When clients insist on ever-increasing changes to the product being
developed, scope creep can jeopardise the project. An even more difficult situation
for a project manager surfaces when new changes are introduced after the project
has been launched. This usually drives up the cost, resource requirements,
deliverables, and completion time. Scope creep needs to be managed and the project
manager needs to have a change control process in place to assess the impact and
cost of the change and, possibly, negotiate the change for a future release.
One of the biggest reasons why any project goes bad is due to a lack of communication. Many
projects fail simply because no one understands what to do and receives no communication
as to current progress; this, inevitably, results in project failure.
Once you have identified the deviations, it is critical that you communicate with the relevant
individuals to ensure that corrective action is taken timeously.
8.3 Identify, analyse, describe and report the impact of scope change according to
agreed procedures
Uncontrolled changes are often referred to as project scope creep.
Change during the course of a project is inevitable, thereby mandating some type of change
control process.
Let’s define what we mean by change in the context of managing a project:
146
Version 1
Learner Guide
Scope Change
Where a request is considered to change the agreed scope and
objectives of the project to accommodate a need not originally
defined to be part of the project.
Change Control (sometimes
referred to as "Change
Management")
The management process for requesting reviewing, approving,
carrying out and controlling changes to the project's deliverables.
Change Control is usually applied once the first version of a
deliverable has been completed and agreed.
Configuration Management or
Version Control (sometimes
also called "Change Control")
Technical and administrative control of the multiple versions or
editions of a specific deliverable, particularly where the
component has been changed after it was initially completed.
Most typically this applies to objects, modules, data definitions
and documentation.
Change Management
Normally used to mean the achievement of change in human
behaviour as part of an overall business solution.
Change Programme
Usually used to mean a large, multi-faceted business solution
(not just the human behavioural element).
Change is inevitable. During a project there will be many good reasons why things need to
change. There will also be a few bad reasons - bad, but unavoidable.
Let's consider some of those reasons...
Change Driver
Comment
The business needs have
changed
Business needs are changing ever more rapidly, particularly as
competitors explore the new business models of eCommerce. All
businesses must be willing to change if they are to remain
competitive.
The organisation has changed
It is surprisingly common to find that the organisation undergoes
some form of restructuring during the life of a project. This could
involve mergers, acquisitions, being taken over, new
departments, new business leaders, new products, new
accounting structures, new locations etc.
Exploit technology
improvements
The available technology improves constantly. All the time your
Project Team are trying to exploit the various technology
components, each of those components has a large team of
people working to create a better version - and thus to make your
version obsolete.
The organisation's priorities
have changed
Although the scope and objectives of your project remain valid,
the organisation may decide that there are other business needs
that have high priority and should be addressed.
New business partners and
channels
Organisations are responding to the rapidly changing marketplace
by forming new business partnerships and alliances. New
business channels are becoming available through those
relationships, e.g. using industry hub portals and intermediaries.
147
Version 1
Learner Guide
Change Driver
Comment
New legislation and
regulations
There may be unavoidable external requirements over which you
have no control, such as new regulations for data privacy,
changed regulatory reporting requirements, etc.
Globalisation, standards etc
The organisation is making progress in presenting and managing
itself as a global entity and, hence, there are new or revised
standards for such things as website design, database definitions,
corporate knowledge sharing, data warehouses, etc.
Effect of other projects and
initiatives
Other initiatives within the organisation result in revised needs
for this project, e.g. there is a new accounting system so the
interface from our new system will have to be changed.
We messed up
Or, to put it more discreetly, elements of the project's design and
deliverables do not fully meet the defined need and will need to
be re-worked.
8.4 Process approved change requests to scope in accordance with project change
control procedures
Requested Changes
A recommended corrective action is any step recommended to bring expected future project
performance in line with the project management plan and project scope statement.
Project scope control is concerned with influencing the factors that create project scope
changes and controlling the impact of those changes. Scope control assures all requested
changes and recommended corrective actions are processed through the project Integrated
Change Control process.
Project scope control is also used to manage the actual changes when they occur and is
integrated with the other control processes.
Change Control System
A project scope change control system, documented in the project scope management plan,
defines the procedures by which the project scope and product scope can be changed. The
system includes the documentation, tracking systems, and approval levels necessary for
authorising changes. The scope change control system is integrated with any overall project
management information system to control project scope. When the project is managed under
a contract, the change control system also complies with all relevant contractual provisions.
Variance Analysis
Project performance measurements are used to assess the magnitude of variation. Important
aspects of project scope control include determining the cause of variance relative to the
scope baseline and deciding whether corrective action is required.
Replanning
148
Version 1
Learner Guide
Approved change requests affecting the project scope can require modifications to the WBS
and WBS dictionary, the project scope statement, and the project scope management plan.
These approved change requests can cause updates to components of the project
management plan.
Small Projects
Since small projects are much easier to define and are usually completed very quickly, they
typically do not have major scope change requests. If scope changes occur, they are typically
also small in nature. It should therefore be possible to perform the following processes quickly:
1.
Scope changes can be surfaced by anyone on the project team. They should be sent in
writing to the project manager by paper, e-mail, etc. No formal form is needed.
2.
The project manager validates that the request is, in fact, a scope change. If so, the
rest of this process is executed.
3.
The project manager determines the impact of the scope change to the project in
terms of cost, effort and duration. If there are multiple viable options, the project
manager determines their impact as well.
4.
(Optional) If the change request can be accommodated within the original project
cost, effort and duration, the project manager and client manager have the flexibility
to make the decision on whether the change should be approved. However, the
sponsor must have agreed to delegate this responsibility – usually up to a certain
threshold of cost or effort.
5.
The appropriate analysis, impact and alternatives are taken to the project sponsor for
resolution (if the request was not already approved in step 4 above). If the sponsor
does not approve the request and the corresponding impact, the scope request is not
pursued.
6.
If the scope change request is approved, the appropriate activities are added to the
work plan to ensure the change is implemented.
7.
The request, current status and resolution should be documented in the project Status
Report.
Medium Projects
Solicit potential scope changes from any project stakeholders, including the project team,
clients, sponsors, etc. Potential scope changes should be documented in writing to the project
manager through a short Scope Change Request Form (optional) or e-mail.
1.
Enter the item into the Scope Change Log for tracking purposes.
2.
The person making the scope change request should define the business value to the
project. The sponsor will need this information to make a final decision.
149
Version 1
Learner Guide
3.
The project manager must investigate the impact to the project in terms of effort, cost
and duration. If the time required to perform the scope investigation will cause
deliverable dates to slip, the request must first be taken to the project sponsor to
determine whether the request itself should even be investigated. If the sponsor gives
the initial approval to proceed, the workplan and budget may need to be updated to
reflect this new scope change investigation. If the Sponsor does not agree to
investigate the change request, then the request should be closed as ‘not approved’
on the Scope Change Log.
4.
Assign the scope change to a project team member for investigation. (The project
manager could assign it to himself or herself).
5.
(Optional). If the impact on project cost, effort and duration falls below a threshold
(say less than 20 hours) and the project will still be completed within the agreed upon
cost, effort and duration, the project manager and client manager may approve the
scope change request. This threshold needs to be identified and approved in advance
by the project sponsor. The purpose of this step is to keep from sending many small
changes to the sponsor for approval. However, the sponsor must have agreed to
delegate this responsibility – usually up to a certain threshold of dollars or effort.
6.
Take the scope change request, alternatives, business value and project impact to the
project sponsor for a resolution (if the project manager and client manager did not
approve, as above).
7.
Document the resolution on the Scope Change Log. If the Sponsor does not agree to
the change request, then the request should be closed and given a status of ‘not
approved’ on the Scope Change Log.
8.
If the scope change request is approved, the appropriate activities are added to the
work plan to ensure the change is implemented. The project budget and deadline
should also be updated, if necessary.
9.
The current Project Definition should be updated if an approved scope change results
in a substantial change to the scope of the project.
10. Communicate scope change status and resolution to project team members and other
appropriate stakeholders through the methods established in the Communication
Plan, including the project Status Report.
Large Projects
1.
(Optional) In a large project you may choose to define scope change management in
the context of an overall Configuration Management Plan. Configuration management
is the term given to the identification, tracking and managing of all the assets of a
project. This would include assets such as hardware, software, equipment, source
code components, documentation, etc. You can also track your requirements using
configuration management, and in that respect the changing of requirements would
trigger a scope change request and the execution of your Scope Change Procedure.
150
Version 1
Learner Guide
2.
Solicit potential scope change requests from any project stakeholders, including the
project team, clients, sponsors, etc.
3.
The scope change can be surfaced through verbal or written means, but it will be
formally documented using a Scope Change Request Form.
4.
Enter the request into the Scope Change Log for tracking purposes.
5.
The person making the scope change request should define the business value to the
project. The sponsor will need this information to make a final decision.
6.
The project manager must investigate the impact to the project in terms of effort, cost
and duration. If the time required to perform the scope investigation will cause
deliverable dates to slip, the request must first be taken to the project sponsor to
determine whether the request itself should even be investigated. If the sponsor gives
the initial approval to proceed, the work plan and budget may need to be updated to
reflect this new scope change investigation. If the Sponsor does not agree to
investigate the change request, then the request should be closed as ‘not approved’
on the Scope Change Log.
7.
Assign the scope change to a project team member for investigation. (The project
manager could assign it to himself or herself).
8.
(Optional). If the impact on project cost, effort and duration falls below a threshold
(say less than 20 hours) and the project will still be completed within the agreed upon
cost, effort and duration, the project manager and client manager may approve the
scope change request. This threshold needs to be identified and approved in advance
by the project sponsor. The purpose of this step is to keep from sending many small
changes to the sponsor for approval. However, the sponsor must have agreed to
delegate this responsibility – usually up to a certain threshold of rands or effort.
9.
Take the scope change request, alternatives, business value and project impact to the
project sponsor for a resolution (if the project manager and client manager did not
approve, as above).
10. Document the resolution or course of action on the Scope Change Request Form.
11. Document the resolution on the Scope Change Log. If the Sponsor does not agree to
the change request, then the request should be closed and given a status of ‘not
approved’ on the Scope Change Log.
12. If the scope change request is approved, the appropriate activities are added to the
work plan to ensure the change is implemented. The project budget and deadline
should also be updated, if necessary.
13. The current Project Definition should be updated if an approved scope change results
in a substantial change to the scope of the project.
14. Communicate scope change status and resolution to project team members and other
appropriate stakeholders through the methods established in the Communication
Plan, including the project Status Report.
151
Version 1
Learner Guide
Controlling Small Scope Change Requests
Everyone can recognise and appreciate that a scope change request process must be invoked
for large changes to the project. However, you may encounter resistance to formal scope
change management for small requests. The client and other project team members may
consider this to be unnecessary overhead for such small decisions.
They might be right. There are three alternate techniques to employ that may help with small
changes. Note that none of these options implies that you are not managing and tracking
scope changes. These are just additional techniques to use that may be more appropriate for
managing small scope changes.
If none of these options are in place, the project manager should utilize the normal default
scope change management process on all changes.
Batching Small Requests
It is not always practical to get the sponsor to approve all small scope change requests each
time one is requested. The project team usually does not have day-to-day access to the
sponsor and it is hard to get the sponsor's attention for these small requests. It is a better use
of time to batch the small changes up into a bundle. This means that you keep track of the
small scope changes, their business value and their impact on the project. Then, when they
hit a certain threshold, you take them all to the sponsor for approval. Instead of visiting the
sponsor ten times for small scope changes, you batch them all together and see the sponsor
once. At that meeting you and the client discuss all the proposed changes (or perhaps just the
larger ones in the batch) and get sponsor feedback on whether they should be done. Even
thought these are small changes, they should still go through scope change management.
Otherwise you are susceptible to scope creep. The benefit of having the sponsor approve the
small changes is that if the scope changes are approved, the sponsor should also approve the
incremental budget and time needed to get the work done.
Project Manager Discretion
There is a second technique for handling small scope change requests. From a practical point,
it may make sense for the project manager and client manager to be given discretion to
approve small scope change requests under some threshold of effort hours and cost. This
decision-making authority should not be assumed. This authority must be explicitly delegated
by the sponsor. This discretion assumes that the project is on or ahead of schedule, and that
the changes do not make the project exceed the agreed-upon cost or duration. If the project
is in any risk of not meeting its cost or duration commitments, this discretion should not be
used – even for a one-hour change request. If the project is at risk of missing its deadline or
budget commitments, all scope change requests must go to the sponsor for approval, either
individually or in batches. If the sponsor approves the changes, the project should receive
corresponding budget and schedule relief as well.
Scope Change Contingency Budget
152
Version 1
Learner Guide
In some organisations it is common to allocate a scope change contingency budget to handle
small changes. Your organisation may recognise that a certain level of scope change is
inevitable and you may be allowed to allocate a percentage of the total project budget to
account for this level of change. For example, you may have a 5% contingency added to your
budget for scope change. If your total project budget was R500 000, your scope change
contingency budget would be R25 000.
However, the implication here is that this contingency budget will be all that is allocated for
small scope change requests. The client must manage the budget to make sure all of the small
scope changes can be accommodated.
If the client uses the budget up early on small scope changes, there will be nothing left for
later change requests. This puts the client in a position of rationing the changes to ensure that
only the most important changes are approved. This budget is used for change requests under
a certain rand or hour threshold.
Larger requests can still be made but they would go through normal scope change
management and be evaluated by the sponsor.
Freezing Scope Change Requests
Do you think that as long as you are managing scope change requests diligently, the client
should be free to make changes all the way through the project? It is true that changes toward
the end of the project tend to take more time and effort to accommodate. However, you might
think that as long as the sponsor is willing to approve increases in budget and time to make
the change, the client should be able to do it.
This is, in fact, normally true, but only up to a point. There comes a time in a project where it
just doesn't make sense to make additional changes or absorb additional requirements. That
is the time to gain a commitment for a change freeze. Not only are new changes expensive to
implement, they are a distraction to the project team.
Depending on the nature of the project, this freeze is usually implemented after the user
acceptance testing is approved and the team is getting ready for the “drive to
implementation”.
At this point, the team is focused on implementing the solution. The team may be working
overtime. The project manager may be micromanaging the project to ensure all of the details
are carried out on time.
At this point in the project, scope change requests are not only costly, but they are also very
disruptive. The team can lose focus and become mentally deflated.
You may find that the next time there is a “drive to implementation” the team will get sloppy
and make mistakes, since this would be the second time they performed these
implementation activities.
The better approach is to hold these changes on a backlog and deal with them as enhancement
requests after the solution is implemented and stable. (This refers to change requests and not
bugs. The users may uncover bugs and errors in their testing and these errors do need to be
fixed before implementation.)
153
Version 1
Learner Guide
If you get agreement on a change freeze date, your team can focus on delivering the current
solution. Of course, if there is a change request that absolutely must go in, you can still allow
the sponsor to make the call. However, gaining agreement on a freeze date will eliminate the
need for additional changes on most projects.
Only the Sponsor Can Approve Changes – Not Users and Client Managers
A typical problem on a project is that the team does not understand the roles of the sponsor,
client and end users.
In general, the project sponsor is the person who is funding the project. If the client were
embodied in one person, it would be the project sponsor.
The sponsor is usually high up in the organisation and not easy to see on a day-to-day basis. In
most cases, the sponsor designates someone in his or her organisation to make most decisions
on a daily basis.
The people that the project team tend to work with most often are end users. End users are
the people that use the solution that the project is building. The end users are the ones that
will generally make requests for changes to deliverables.
It doesn't matter how important a change is to an end user, the end users cannot make scope
change decisions and they cannot give your team the approval to make a scope change.
In proper scope change management, the sponsor must give the approval. The end users can
request scope changes, but they cannot approve them. The end user cannot allocate
additional funding to cover the changes and they cannot know if the project impact is
acceptable. If the change is important enough to the Sponsor, he or she will approve it, along
with the appropriate budget and duration changes. If the change is not important enough, it
will not be approved. However, it will be the Sponsor making the decision, not the project
manager, client manager, project team or end users.
Is Saying 'Yes' to Scope Change Requests Showing Good Client Focus?
The project manager and project team sometimes think that they are being client-focused by
accepting scope change while still trying to deliver the project within the original
commitments.
However, if the project is delivered late or over-budget, it is usually not a good idea to point
out all the additional work that was included because of this 'client focus'.
The project sponsor and your managers don't want to hear about it. In most cases, the project
will not be seen as successful since it did not deliver as promised within the agreed upon
budget and delivery date.
The sponsor is the primary client representative. Allowing the sponsor to make scope change
decisions shows good client focus. If the project team or project manager approves scope
changes, he or she is not showing good client focus from the sponsor’s perspective.
Backlog
154
Version 1
Learner Guide
It is possible that the sponsor may not approve scope change requests during the project, but
they may be viable requests that can be done at a later time. These types of change requests
should be captured on a backlog list.
After the project is completed and the solution is moved to production, there may be
opportunities for enhancements or a Phase II project. However, even at a later date, these
changes will be implemented only if they are approved and if funding is available.
Typical change control process22
22

A potential change in the project scope is identified. This potential change is reviewed.
If it is not considered beneficial to the success of the project but will impact the project
result if left unattended, an issue is recorded in the Issues Register.

The change is then evaluated. If there is no impact on the project deliverables, budget
or
the
schedule,
the
change
is
made
and
documented.
Otherwise the calculations are made and the Change order Form is completed.

The Change Order Form is reviewed by the customer and / or the Change Control
Board. If the change is approved it is implemented and then documented.

If the change is not approved, there must be something that needs to be resolved, so
an Issue is raised and resolved through that process.
http://projectmagazine.com/scope/writing-a-scope-statement_2.html
155
Version 1
Learner Guide
8.5 Verify project deliverables as complete as per agreed scope definition or
specified requirements
Scope verification
Scope verification is the process of obtaining the stakeholders’ formal acceptance of the
completed project scope and associated deliverables. Verifying the project scope includes
reviewing deliverables to ensure that each is completed satisfactorily. If the project is
terminated early, the project scope verification process should establish and document the
level and extent of completion.
Scope verification differs from quality control in that scope verification is primarily concerned
with acceptance of the deliverables, while quality control is primarily concerned with meeting
the quality requirements specified for the deliverables.
Quality control is generally performed before scope verification, but these two processes can
be performed in parallel.
Inspection
Inspection includes activities such as measuring, examining, and verifying to determine
whether work and deliverables meet requirements and product acceptance criteria.
Inspections are variously called reviews, product reviews, audits, and walkthroughs. In some
application areas, these different terms have narrow and specific meanings.
Accepted Deliverables
The Scope Verification process documents those completed deliverables that have been
accepted. Those completed deliverables that have not been accepted are documented, along
with the reasons for non-acceptance. Scope verification includes supporting documentation
received from the customer or sponsor and acknowledging stakeholder acceptance of the
project’s deliverables.
Class Activity 8: Monitor achievement of the project’s scope
Individually or in groups as per your facilitator’s instructions, complete the
formative activities in your Workbook
Reflection
Individually, complete the formative activity in your Learner Workbook
Facilitator Observation Checklist
156
Version 1
Learner Guide
The facilitator will provide you with feedback about your participation during
the class activities in your Learner Workbook
157
Version 1
Learner Guide
Summative Assessment
You are required to complete a number of summative assessment activities in your Learner
Portfolio of Evidence Guide. The Learner Portfolio of Evidence Guide will guide you as to what
you are required to do:

Complete all the required administration documents and submit all the required
documentation, such as a certified copy of your ID, a copy of your CV and relevant
certificates of achievement:

Learner personal information form

Pre-assessment preparation sheet

Assessment plan document

Declaration of authenticity form

Appeals procedure declaration form

Place your complete Learner Workbook (with the completed Class Activities) in the
specified place in the Learner Portfolio of Evidence Guide.

Complete the other summative assessment activities in your workplace:
Knowledge Questions
Individually, complete this summative activity in your Learner Portfolio of
Evidence Guide
Practical Activities
Individually, complete this summative activity in your Learner Portfolio of
Evidence Guide
Witness Testimony
Individually, complete this summative activity in your Learner Portfolio of
Evidence Guide
Logbook
Individually, complete this summative activity in your Learner Portfolio of
Evidence Guide
158
Version 1
Learner Guide
Once you have completed all the summative activities in your Learner Portfolio of Evidence
Guide, complete the Assessment Activities Checklist to ensure that you have submitted all the
required evidence for your portfolio, before submitting your portfolio for assessment.
159
Version 1
Learner Guide
References and Further Reading

Lewis, James P. 2007. The Project Manager’s Desk Reference. 3rd Edition. New York:
McGraw-Hill

http://www.epmbook.com

http://projectmagazine.com

http://www.4pm.com/articles/workpackages.pdf

http://www.pmpartners.com/resources/defmeas_success.html
160
Version 1
Learner Guide
Appendix A:
Vision and Scope Document23
for
<Project>
Version 1.0 approved
Prepared by <author>
<organisation>
<date created>
Table of Contents
TABLE OF CONTENTS
161
REVISION HISTORY
163
1.
BUSINESS REQUIREMENTS
1.1. BACKGROUND
163
163
1.2. BUSINESS OPPORTUNITY
163
1.3. BUSINESS OBJECTIVES AND SUCCESS CRITERIA 163
1.4. CUSTOMER OR MARKET NEEDS
1.5. BUSINESS RISKS
2.
163
165
VISION OF THE SOLUTION
2.1. VISION STATEMENT
165
165
2.2. MAJOR FEATURES 165
2.3. ASSUMPTIONS AND DEPENDENCIES 165
3.
SCOPE AND LIMITATIONS
165
3.1. SCOPE OF INITIAL RELEASE 165
3.2. SCOPE OF SUBSEQUENT RELEASES
166
3.3. LIMITATIONS AND EXCLUSIONS
166
4.
BUSINESS CONTEXT
166
4.1. STAKEHOLDER PROFILES
166
4.2. PROJECT PRIORITIES
166
4.3. OPERATING ENVIRONMENT 167
23
Retrieved from: www.processimpact.com/process_assets/vision_and_scope.doc
161
Version 1
Learner Guide
162
Version 1
Learner Guide
Revision History
Name
Date
Reason For Changes
Version
Business Requirements
<The business requirements provide the foundation and reference for all detailed
requirements development. You may gather business requirements from the customer or
development organisation’s senior management, an executive sponsor, a project visionary,
product management, the marketing department, or other individuals who have a clear sense
of why the project is being undertaken and the ultimate value it will provide, both to the
business and to customers.>
Background
<This section summarises the rationale for the new product. Provide a general description of
the history or situation that leads to the recognition that this product should be built.>
Business Opportunity
<Describe the market opportunity that exists or the business problem that is being solved.
Describe the market in which a commercial product will be competing or the environment in
which an information system will be used. This may include a brief comparative evaluation of
existing products and potential solutions, indicating why the proposed product is attractive.
Identify the problems that cannot currently be solved without the product, and how the
product fits in with market trends or corporate strategic directions.>
Business Objectives and Success Criteria
<Describe the important business objectives of the product in a way that is quantitative and
measurable. The value provided to customers is described in section 1.4, so this section should
focus on the value provided to the business. This could include estimates of revenue or cost
savings, return on investment analysis, or target release dates. Determine how success will be
defined and measured on this project, and describe the factors that are likely to have the
greatest impact on achieving that success. Include things within the direct control of the
organisation, as well as external factors. Establish measurable criteria to assess whether the
business objectives have been met.>
Customer or Market Needs
<Describe the needs of typical customers or market segments, including needs that are not
yet met by the marketplace or by existing systems. You may wish to describe problems
customers currently encounter that the new product will (or will not) address and how the
product would be used by customers. Identify the customer hardware and software
environment in which the product must operate. Define at a high level any known critical
interface or performance requirements. Avoid including any design or implementation details.
163
Version 1
Learner Guide
Present the requirements in a numbered list so that more detailed user or functional
requirements can be traced to them.>
164
Version 1
Learner Guide
Business Risks
<Summarise the major business risks associated with developing this product, such as
marketplace competition, timing issues, user acceptance, implementation issues, or possible
negative impacts on the business. Estimate the severity of the risks and identify any risk
mitigation actions that could be taken.>
Vision of the Solution
<This section establishes a long-term vision for the system to be built to address the business
objectives. This vision will provide the context for making decisions throughout the course of
the product development life cycle. The vision should not include detailed functional
requirements or project planning information.>
Vision Statement
<Write a concise vision statement that summarizes the purpose and intent of the new product
and describes what the world will be like when it includes the product. The vision statement
should reflect a balanced view that will satisfy the needs of diverse customers as well as those
of the developing organization. It may be somewhat idealistic, but it should be grounded in
the realities of existing or anticipated customer markets, enterprise architectures,
organizational strategic directions, and cost and resource limitations.>
Major Features
<Include a numbered list of the major features of the new product, emphasising those features
that distinguish it from previous or competing products. Specific user requirements and
functional requirements may be traced back to these features.>
Assumptions and Dependencies
<Record any assumptions that were made when conceiving the project and writing this vision
and scope document. Note any major dependencies the project must rely upon for success,
such as specific technologies, third-party vendors, development partners, or other business
relationships.>
Scope and Limitations
<The project scope defines the concept and range of the proposed solution. It’s also important
to define what will not be included in the product. Clarifying the scope and limitations helps
to establish realistic expectations of the many stakeholders. It also provides a reference frame
against which proposed features and requirements changes can be evaluated. Proposed
requirements that are out of scope for the envisioned product must be rejected, unless they
are so beneficial that the scope should be enlarged to accommodate them (with accompanying
changes in budget, schedule, and/or resources).>
Scope of Initial Release
<Describe the intended major features that will be included in the initial release of the
product. Consider the benefits the product is intended to bring to the various customer
165
Version 1
Learner Guide
communities, and generally describe the product features and quality characteristics that will
enable it to provide those benefits. Avoid the temptation to include every possible feature that
any potential customer category might conceivably want some day. Focus on those features
and product characteristics that will provide the most value, at the most acceptable
development cost, to the broadest community.>
Scope of Subsequent Releases
<If a staged evolution of the product is envisioned over time, indicate which major features
will be deferred to later releases.>
Limitations and Exclusions
<Identify any product features or characteristics that a stakeholder might anticipate, but which
are not planned to be included in the new product.>
Business Context
<This section summarises some of the business issues around the project, including profiles of
major customer categories, assumptions that went into the project concept, and the
management priorities for the project.>
Stakeholder Profiles
<Stakeholders are individuals, groups, or organisations that are actively involved in a project,
are affected by its outcome, or can influence its outcome. The stakeholder profiles identify the
customers for this product and other stakeholders, and states their major interests in the
product. Characterise business-level customers, target market segments, and different user
classes, to reduce the likelihood of unexpected requirements surfacing later that cannot be
accommodated because of schedule or scope constraints. For each stakeholder category, the
profile includes the major value or benefits they will receive from the product, their likely
attitudes toward the product, major features and characteristics of interest, and any known
constraints that must be accommodated. Examples of stakeholder value include:

improved productivity

reduced rework

cost savings

streamlined business processes

automation of previously manual tasks

ability to perform entirely new tasks or functions

conformance to current standards or regulations

improved usability or reduced frustration level compared to current applications
Example:>
Stakeholder
Major Value
Attitudes
Major Interests
Constraints
166
Version 1
Learner Guide
executives
increased
revenue
editors
fewer errors in
work
legal aides
quick access to
data
see product as avenue
to 25% increase in
market share
highly receptive, but
expect high usability
resistant unless
product is keystrokecompatible with
current system
richer feature set than
competitors; time to
market
automatic error
correction; ease of use;
high reliability
ability to handle much
larger database than
current system; easy to
learn
maximum budget
= R1.4M
must run on lowend workstations
no budget for
retraining
Project Priorities
<Describe the priorities among the project’s requirements, schedule, and budget. The table
below may be helpful in identifying the parameters around the project’s key drivers (top
priority objectives), constraints to work within, and dimensions that can be balanced against
each other to achieve the drivers within the known constraints.24
Examples:>
Dimension
Schedule
Driver
(state objective)
Constraint
(state limits)
Degree of Freedom
(state allowable range)
release 1.0 to be
available by 10/1,
release 1.1 by 12/1
Features
70-80% of high priority features
must be included in release 1.0
Quality
90-95% of user acceptance tests
must pass for release 1.0, 9598% for release 1.1
Staff
maximum team size is 6
developers + 4 testers
Cost
budget overrun up to 15%
acceptable without executive
review
Operating Environment
<Describe the environment in which the system will be used and define the major availability,
reliability, performance, and integrity requirements. This information will significantly
influence the definition of the system’s architecture. Consider questions such as:
24
For more information, see chapter 2 of Creating a Software Engineering Culture by Karl E. Wiegers (Dorset House,
1996).
167
Version 1
Learner Guide

Are the users widely distributed geographically or located close to each other? How
many time zones are they in?

When do the users in various locations need to access the system?

Where is the data generated and used? How far apart are these locations? Does the data
from multiple locations need to be combined?

Are specific maximum response times known for accessing data that might be stored
remotely?

Can the users tolerate service interruptions or is continuous access to the system critical
for the operation of their business?

What access security controls and data protection requirements are needed?>
168
Version 1
Learner Guide
Glossary
Assumption
Client
Customers
Constraints
Critical path
Deliverable
Functional
manager
Gantt chart
Issue
Lifecycle
/
There may be external circumstances or events that must occur for the project to
be successful (or that should happen to increase your chances of success). If you
believe that the probability of the event occurring is acceptable, you could list it
as an assumption. An assumption has a probability between 0 and 100%. That is,
it is not impossible that the event will occur (0%) and it is not a fact (100%). It is
somewhere in between. Assumptions are important because they set the context
in which the entire remainder of the project is defined. If an assumption doesn't
come through, the estimate and the rest of the project definition may no longer
be valid.
The person or group that is the direct beneficiary of a project or service is the
client / customer. These are the people for whom the project is being undertaken
(indirect beneficiaries are stakeholders). In many organizations, internal
beneficiaries are called "clients" and external beneficiaries are called "customers,"
but this is not a hard and fast rule.
Constraints are limitations that are outside the control of the project team and
need to be managed around. They are not necessarily problems. However, the
project manager should be aware of constraints because they represent
limitations that the project must execute within. Date constraints, for instance,
imply that certain events (perhaps the end of the project) must occur by certain
dates. Resources are almost always a constraint, since they are not available in an
unlimited supply.
The critical path is the sequence of activities that must be completed on schedule
for the entire project to be completed on schedule. It is the longest duration path
through the workplan. If an activity on the critical path is delayed by one day, the
entire project will be delayed by one day (unless another activity on the critical
path can be accelerated by one day).
A deliverable is any tangible outcome that is produced by the project. All projects
create deliverables. These can be documents, plans, computer systems, buildings,
aircraft, etc. Internal deliverables are produced as a consequence of executing the
project and are usually needed only by the project team. External deliverables are
those that are created for clients and stakeholders. Your project may create one
or many deliverables.
The functional manager is the person you report to within your functional
organization. Typically, this is the person who does your performance review. The
project manager may also be a functional manager, but he or she does not have
to be. If your project manager is different from your functional manager, your
organization is probably utilizing matrix management.
A Gantt chart is a bar chart that depicts activities as blocks over time. The
beginning and end of the block correspond to the beginning and end-date of the
activity.
An issue is a major problem that will impede the progress of the project and that
can't be resolved by the project manager and project team without outside help.
Project managers should proactively deal with issues through a defined issues
management process.
Lifecycle refers to the process used to build the deliverables produced by the
project. There are many models for a project lifecycle. For software development,
the entire lifecycle might consist of planning, analysis, design, construct/test,
implementation, and support. This is an example of a "waterfall" lifecycle. Other
169
Version 1
Learner Guide
Milestone
Objective
Program
Program
manager
Project
Project
definition
(charter)
Project
manager
Project phase
lifecycles include iterative development, package implementation, and research
and development. Each of these lifecycle models represents an approach to
building the deliverables on your project.
A milestone is a scheduling event that signifies the completion of a major
deliverable or a set of related deliverables. A milestone, by definition, has duration
of zero and no effort. There is no work associated with a milestone. It is a flag in
the workplan to signify that some other work has completed. Usually, a milestone
is used as a project checkpoint to validate how the project is progressing. In many
cases there is a decision, such as validating that the project is ready to proceed
further, that needs to be made at a milestone.
An objective is a concrete statement that describes what the project is trying to
achieve. The objective should be written at a low level, so that it can be evaluated
at the conclusion of a project to see whether it was achieved. Project success is
determined based on whether the project objectives were achieved. A technique
for writing an objective is to make sure it is Specific, Measurable,
Attainable/Achievable, Realistic, and Timebound (SMART).
A program is the umbrella structure established to manage a series of related
projects. The program does not produce any project deliverables. The project
teams produce them all. The purpose of the program is to provide overall direction
and guidance, to make sure the related projects are communicating effectively, to
provide a central point of contact and focus for the client and the project teams,
and to determine how individual projects should be defined to ensure that all the
work gets completed successfully.
A program manager is the person with the authority to manage a program. (Note
that this is a role. The program manager may also be responsible for one or more
of the projects within the program.) The program manager leads the overall
planning and management of the program. All project managers within the
program report to the program manager.
A project is a temporary structure to organize and manage work and ultimately to
build a specific defined deliverable or set of deliverables. By definition, all projects
are unique, which is one reason it is difficult to compare different projects to one
another.
Before you start a project, it is important to know the overall objectives of the
project, as well as the scope, deliverables, risks, assumptions, project organization
chart, etc. The project definition (or charter) is the document that holds this
relevant information. The project manager is responsible for creating the project
definition. The document should be approved by the sponsor to signify that the
project manager and the sponsor are in agreement on these important aspects of
the project.
The project manager is the person with the authority to manage a project. The
project manager is 100 percent responsible for the processes used to manage the
project. He or she also has people management responsibilities for team
members, although this is shared with the team member's functional manager.
The processes used to manage the project include defining the work, building the
workplan and budget, managing the workplan and budget, scope management,
issues management, risk management, etc.
A phase is a major logical grouping of work on a project. It also represents the
completion of a major deliverable or set of related deliverables. On an IT
development project, logical phases might be planning, analysis, design, construct
(including testing), and implementation.
170
Version 1
Learner Guide
Project team
Requirements
Risk
Scope
Scope change
management
Sponsor
(executive
sponsor
and
project
sponsor)
Stakeholder
The project team consists of the full-time and part-time resources assigned to
work on the deliverables of the project. They are responsible for understanding
the work to be completed; completing assigned work within the budget, timeline,
and quality expectations; informing the project manager of issues, scope changes,
and risk and quality concerns; and proactively communicating status and
managing expectations.
Requirements are descriptions of how a product or service should act, appear, or
perform. Requirements generally refer to the features and functions of the
deliverables you are building on your project. Requirements are considered to be
a part of project scope. High-level scope is defined in your project definition
(charter). The requirements form the detailed scope. After your requirements are
approved, they can be changed through the scope change management process.
There may be potential external events that will have a negative impact on your
project if they occur. Risk refers to the combination of the probability the event
will occur and the impact on the project if the event occurs. If the combination of
the probability of the occurrence and the impact to the project is too high, you
should identify the potential event as a risk and put a proactive plan in place to
manage the risk.
Scope is the way you describe the boundaries of the project. It defines what the
project will deliver and what it will not deliver. High-level scope is set in your
project definition (charter) and includes all of your deliverables and the
boundaries of your project. The detailed scope is identified through your business
requirements. Any changes to your project deliverables, boundaries, or
requirements would require approval through scope change management.
The purpose of scope change management is to manage change that occurs to
previously approved scope statements and requirements. Scope is defined and
approved in the scope section of the project definition (charter) and the more
detailed business requirements. If the scope or the business requirements change
during the project (and usually this means that the client wants additional items),
the estimates for cost, effort, and duration may no longer be valid. If the sponsor
agrees to include the new work in the project scope, the project manager has the
right to expect that the current budget and deadline will be modified (usually
increased) to reflect this additional work. This new estimated cost, effort, and
duration now become the approved target.Sometimes the project manager thinks
that scope management means having to tell the client "no." That makes the
project manager nervous and uncomfortable. However, the good news is that
managing scope is all about getting the sponsor to make the decisions that will
result in changes to project scope.
The sponsor is the person who has ultimate authority over the project. The
executive sponsor provides project funding, resolves issues and scope changes,
approves major deliverables, and provides high-level direction. He or she also
champions the project within the organization. Depending on the project and the
organizational level of the executive sponsor, he or she may delegate day-to-day
tactical management to a project sponsor. If assigned, the project sponsor
represents the executive sponsor on a day-to-day basis and makes most of the
decisions requiring sponsor approval. If the decision is large enough, the project
sponsor will take it to the executive sponsor.
Specific people or groups who have a stake in the outcome of the project are
stakeholders. Normally stakeholders are from within the company and may
include internal clients, management, employees, administrators, etc. A project
171
Version 1
Learner Guide
Steering
committee
Workplan
(schedule)
can also have external stakeholders, including suppliers, investors, community
groups, and government organizations.
A steering committee is usually a group of high-level stakeholders who are
responsible for providing guidance on overall strategic direction. They don't take
the place of a sponsor but help spread the strategic input and buy-in to a larger
portion of the organization. The steering committee is especially valuable if your
project has an impact in multiple organizations because it allows input from those
organizations into decisions that affect them.
The project workplan tells you how you will complete the project. It describes the
activities required, the sequence of the work, who is assigned to the work, an
estimate of how much effort is required, when the work is due, and other
information of interest to the project manager. The workplan allows the project
manager to identify the work required to complete the project and also allows the
project manager to monitor the work to determine whether the project is on
schedule.
172
Version 1
Learner Guide