Вы находитесь на странице: 1из 160

Business, Accounting and Finance

BSBPMG511 - Manage project scope

Learner Materials and Assessment Tasks


1|Page
Table of Contents

About BSBPMG511 Manage project scope ........................................................................................... 3


Develop and confirm procedures for project authorisation with an appropriate authority .............. 6
Activity 1 ................................................................................................................................................. 8
Activity 2 ............................................................................................................................................... 18
Obtain authorisation to expend resources ......................................................................................... 19
Confirm project delegations and authorities in project governance arrangements ......................... 30
Activity 3 ............................................................................................................................................... 32
Activity 4 ............................................................................................................................................... 43
Identify, negotiate and document project boundaries ....................................................................... 45
Activity 5 ............................................................................................................................................... 51
Establish measurable project benefits, outcomes and outputs ......................................................... 58
Activity 6 ............................................................................................................................................... 67
Activity 7 ............................................................................................................................................... 71
Establish a shared understanding of desired project outcomes with relevant stakeholders ........... 73
Activity 8 ............................................................................................................................................... 75
Document scope management plan .................................................................................................... 77
Activity 9 ............................................................................................................................................... 83
Implement agreed scope management procedures and processes ................................................... 84
Activity 10 ............................................................................................................................................. 92
Manage impact of scope changes within established time, cost and quality constraints according to
change control procedures .................................................................................................................. 94
Identify and document scope management issues and recommend improvements for future
projects ............................................................................................................................................... 102
Activity 11 ........................................................................................................................................... 106

2|Page
About BSBPMG511 Manage project scope
Application

This unit describes the skills and knowledge required to determine and manage project scope. It
involves obtaining project authorisation, developing a scope management plan, and managing the
application of project scope controls.

It applies to individuals responsible for managing and leading a project in an organisation, business
or as a consultant.

No licensing, legislative, regulatory or certification requirements apply to this unit at the time of
publication.

Unit Sector

Management and Leadership – Project Management

Elements and Performance Criteria


ELEMENT PERFORMANCE CRITERIA
Elements describe the Performance criteria describe the performance needed to demonstrate
essential outcomes. achievement of the element.
1. Conduct project 1.1 Develop and confirm procedures for project authorisation with an
authorisation activities appropriate authority

1.2 Obtain authorisation to expend resources

1.3 Confirm project delegations and authorities in project governance


arrangements
2. Define project scope 2.1 Identify, negotiate and document project boundaries

2.2 Establish measurable project benefits, outcomes and outputs

2.3 Establish a shared understanding of desired project outcomes with


relevant stakeholders

2.4 Document scope management plan


3. Manage project scope 3.1 Implement agreed scope management procedures and processes
control process
3.2 Manage impact of scope changes within established time, cost and
quality constraints according to change control procedures

3.3 Identify and document scope management issues and recommend


improvements for future projects

3|Page
Foundation Skills

This section describes language, literacy, numeracy and employment skills incorporated in the
performance criteria that are required for competent performance.

Skill Performance Description


Criteria
Reading 1.3, 2.1, 3.1, 3.2  Interprets and analyses information from a range
of complex texts

Writing 1.1-1.3, 2.1-2.4, 3.3  Develops project documentation and procedures


using formats and language appropriate to context

Oral 1.1-1.3, 2.1- 2.3, 3.3  Participates in discussions and negotiations using
Communication clear language and appropriate non-verbal
features
 Uses active listening and questioning to elicit
views and opinions of others

Numeracy 2.2, 3.2  Interprets numerical information to determine


project timelines and measure outcomes against
project scope

Navigate the 1.3, 3.1, 3.2  Adheres to organisational policies and procedures
world of work and considers own role in terms of its contribution
to broader goals of work environment

Interact with 1.1-1.3, 2.1, 2.3, 3.3  Identifies and uses appropriate conventions and
others protocols when communicating with diverse
stakeholders
 Collaborates with others to achieve joint
outcomes, playing an active role in negotiating
and facilitating agreement

Get the work 1.1, 2.1, 2.2, 3.1,  Sequences and schedules complex activities,
done 3.2, 3.3 monitors implementation and manages relevant
communications
 Makes a range of critical and non-critical decisions
in relatively complex situations, taking a range of
factors into account
 Uses experience to reflect on ways variables
impact outcomes and identify future
improvements

4|Page
Unit Mapping Information
Code and title Code and title Comments Equivalence status

current version previous version


BSBPMG511 Manage BSBPMG511A Manage Updated to meet Equivalent unit
project scope project scope Standards for Training
Packages

Assessment requirements

Modification History
Release Comments
Release 1 This version first released with BSB Business Services Training Package
Version 1.0.

Performance Evidence

Evidence of the ability to:

 complete project authorisation activities


 collaborate with stakeholders to produce a scope-management plan
 implement scope-management plan according to procedures
 review and document scope-management implementation and recommend improvements.

Note: If a specific volume or frequency is not stated, then evidence must be provided at least once.

Knowledge Evidence

To complete the unit requirements safely and effectively, the individual must:

 identify components of a project scope-management plan


 describe factors likely to impact the project scope
 explain formal change-control processes
 describe methods for measuring work outcomes and progress against plans
 describe methods for segmenting and documenting a work breakdown structure
 identify and describe problem areas likely to be encountered in scope management
 explain procedures for reporting scope change
 explain project life cycle and the significance of scope management
 identify project management tools used for managing scope
 outline roles and responsibilities of project manager in relation to project planning
 identify types of project initiation documentation.

5|Page
Develop and confirm procedures for project authorisation with an
appropriate authority1
Project Scope Management refers to the set of processes that ensure a project's scope is defined
and mapped accurately. Scope Management techniques allow project managers and supervisors to
allocate just the right amount of work necessary to complete a project successfully. It is primarily
concerned with controlling what is and what is not part of the project's scope.

For a project manager, scope knowledge area is very important, and PMI (Project Management
Institute) also emphasizes this.

What is Scope?
Scope refers to the detailed set of deliverables or features of a project. These deliverables are
derived from a project’s requirements.

The PMBOK defines Project Scope as the "The work that needs to be accomplished to deliver a
product, service, or result with the specified features and functions."

The definition of Scope follows from the decision of setting out the work to be completed during the
lifecycle of a project. Included in this is also the identification of work that will not be counted in the
ongoing round of the service/product development.

The 3 Facets of Scope Management


Three processes form part of Project Scope Management - planning, controlling, and closing.

Planning
the planning process is when an attempt is made to capture and define the work that needs
competition.

Controlling
the controlling and monitoring processes are concerned with documenting tracking, scope creep,
tracking, and disapproving/ approving project changes.

Closing
the final process, closing, includes an audit of the project deliverables and an assessment of the
outcomes against the original plan.

The Scope Statement


The scope of a project is the clear identification of the work that is required to successfully complete
or deliver a project.

1
Source: Simplilearn, as at http://www.simplilearn.com/project-scope-management-importance-rar89-article,
as on 5th August, 2016; GPM First, as at http://www.gpmfirst.com/books/project-management/project-
authorization, as on 5th August, 2016.

6|Page
One of the project manager’s responsibilities is to ensure that only the required work (the scope)
will be performed and that each of the deliverables can be completed in the allotted time and within
budget.

The documentation of the scope of the project will explain the boundaries of the project, establish
the responsibilities of each member of the team and set up procedures for how work that is
completed will be verified and approved. This documentation may be referred to as the scope
statement, or the statement of work, or the terms of reference.

Steps Involved in Project Scope Management


As a project manager, you'll need to define project scope no matter what methodology you choose
to use.

A systematic process to capture, define, and monitor scope follows.

Step #1 - Define the needs


Defining the needs of the project is the first step toward the establishment of a project timeline,
allocation of project resources and setting project goals. Only with these steps defined will you be
able to understand the work that needs to be done – in other words, the scope of the project needs
to be defined. Once that is done, team members can be allocated tasks, and provided direction to
deliver a project in the given time and budget.

Step #2 - Understand the Project Objectives


To define the project scope, it is important to first establish the objectives of the project, which may
include a new product, creating a new service within the organization, or developing a new piece of
software. There are a number of objectives that could be central to a project and it becomes the role
of the project manager to ensure that the team delivers that result according to the specified
features or functions.

How do you define the project scope?

The resources and work that goes into the creation of a product or service is essentially
what defines the scope of the project. The scope generally outlines the goals to be met to achieve a
satisfactory result. It is important for project managers to understand how to define the scope of the
project.

Steps for defining the scope of a project


To define the scope of the project, it is important to identify the following:

 Project objectives
 Goals
 Sub-phases
 Tasks
 Resources
 Budget

7|Page
 Schedule

Once these parameters are established, the limitations and parameters of the project need to be
clarified and the aspects that are not to be included in the project identified. When doing this, the
project scope will make clear to the stakeholders, senior management, and team members what will
and will not be included in the final product or service.
Along with this, the scope of the project must have a tangible objective for the organization that is
undertaking the project. This is integral for the scope of the project, since it will play a vital role in
how project methodologies are applied to complete it.

Activity 1

Explain the term "Project Scope".

8|Page
Activity 1

9|Page
The Project Scope Management Processes

Plan Scope Management:


This is the first process in the Project Scope management process. The PMBOK Guide, Fifth Edition,
adds several processes to separate the initial planning activities from other activities. This process
creates the scope management plan. The scope management plan describes the project scope and
documents how it will be further defined, validated, and controlled.

The table below shows the Inputs, Tools and Techniques, and Outputs of the Plan Scope
Management Process.

10 | P a g e
The Scope management plan covers how the scope will be defined, validated, and controlled. It also
includes information on preventing or dealing with scope creep, handling of change requests, the
escalation path for any disagreement on the scope elements between stakeholders, the process for
the creation of the scope statement, the WBS, and how the deliverables will be accepted.

Collect Requirements
This process involves the documentation of the stakeholders' needs with the stated intent of
meeting the project's objectives. In this process, managers use several techniques and tools for
collecting project requirements from stakeholders. The process attempts to leave no stone
unturned, resulting in an in-depth list of project requirements. If this process if performed
thoroughly and correctly, it eliminates the possibility of nasty surprises as the project moves
toward completion.

The table below shows the Inputs, Tools and Techniques, and the Outputs of the Collect
Requirements process.

Define Scope
This process involves the preparation of a detailed description of the project and its major
deliverables.
The scope clearly states what the project is supposed to achieve and what it cannot accomplish.

11 | P a g e
The supporting documents are reviewed to ensure that the project will deliver work in line with the
stated goals. The scope that results will then state the stakeholders' needs and communicate the
expectations for the performance of the project.

The table below shows the Inputs, Tools and Techniques and the Outputs of the Defining process.

Create Work Breakdown Structure (WBS)


The Work Breakdown Structure (WBS) is an important element of the Scope management process
and the PMI lays great emphasis on this as many project maangers often skip this step, leading to
inaccurate plans. The WBS provides the project manager and his team with the opportunity to break
down a high-level scope statement to smaller, manageable units of work, called work packages. The
resulting WBS should provide a complete list of all work packages required to complete the project

the table below shows the Inputs, Tools and Techniques and the Outputs of the WBS process.

12 | P a g e
Work Breakdown Structure

The WBS is a hierarchical sub-division of the work to be performed by the project team. What
happens if you don't give it the importance it deserves?

If a project manager prepares a list of activities to be performed in the project straight after getting
the approved project charter, it's a huge mistake, because a list does not allow you to clearly break
the project down into small pieces. This makes it difficult for you and your team members.

What exactly is the WBS?

The WBS is a project management tool which breaks the project into smaller and more manageable
pieces. It decomposes the deliverables/output into the small pieces called as work packages.

Point to be noted: The work package should be designed in such a way that you can:

 Estimate the cost for the created work package


 Schedule the work package
 Monitor and control the work package

When should you create a WBS?

Ideally a project manager should create the WBS in the planning stage after collecting all the
requirements for that particular project. Please note that requirement here is not only of the
project but also what the stakeholders need from this project.

Whom to involve in creating the WBS

As per PMI, in creating WBS, the below-mentioned people should involve ideally:

13 | P a g e
 Project Manager
 Project Management team
 Project team
 All the identified stakeholders

The involvement of stakeholders in creating WBS is very critical and useful too.

ITTO required in the WBS:

Generally we need input as project scope statement, requirement documentation, and OPA
information for creating the standard WBS. The outputs are obviously finalized WBS, WBS dictionary,
and the scope baselines. Scope baselines are then monitored, verified, and controlled throughout
the life-cycle of the project by the assigned project manager. And the tool used to create WBS is
decomposition.

What is the WBS dictionary?

A WBS dictionary is the work/activities defined for every work package in WBS. So, if new members
join your project mid-way, you can get them to refer to this dictionary so they understand their role.

When WBS can be used

 If a new member joins your project


 When the client or stakeholders asks for a scope change

So it's evident that the WBS is a very important tool in modern day project management. PMI
especially recommends it. The interesting thing to note down on WBS is it can be re-used again and
again for several projects if the nature of the projects demands the same nature of output. If the
nature of the projects is different from the current one, then also it can be used with some nominal
changes. Isn’t interesting?

Scope Verification
The Validate Scope process focuses mainly on customer acceptance. It is when the project customer
formally accepts all the project deliverables. This process occurs at the end of each phase. During the
process, the customer gives their feedback on the work that was performed.

The table below shows the Inputs, Tools and Techniques and the Outputs of the Scope Verification
process.

14 | P a g e
Scope control
The Scope Control process involves the monitoring of the status of the project and management of
changes to the scope.

This process involves the assessment of additional requirements from the customer or proactively
overlooking the project scope. Managers will measure the work product against the scope baseline
to ensure that the project stays on track to prevent any unnecessary changes.

15 | P a g e
The table above shows the Inputs, Tools and Techniques and the Outputs of the Scope Control
process.

Common problems with Project Scope Management to avoid


Often, when performing Scope Management, project managers bump into issues along the way. The
problems that may arise when defining and documenting Project Scope are:

1. Ambiguity: Ambiguity in scope often leads to unnecessary work and confusion. To avoid this,
the scope needs to be clearly defined and to the point.
2. Incomplete definition: Incomplete scopes lead to schedule slips which lead to cost overruns.
To avoid this, the scope needs to be complete and accurate.
3. Transience: Transient scopes lead to scope creep which is the primary cause of late
deliveries and "never ending" projects. To avoid this, the scope document needs to be
finalized and remain unaltered for the duration of the project.
4. Un-collaborative scope: A scope that is not collaboratively prepared causes
misinterpretations in requirements and design. To avoid this, the scope document should be
shared with all stakeholders at every step of the scope definition process.

Why project managers need Scope Management


Effective scope management requires good and clear communication, as this ensures that members
on the team understand the scope of the project while agreeing on how the project goals will be
met.

Scope management helps avoid the challenges that a project might face with bloating scope and an
unruly requirements list. Project scope clearly sets out what is or is not included in the project, and
controls what gets added or removed as the project is executed. Scope management establishes
control mechanisms to address factors that may result in changes during the project life-cycle.

Without defining the project scope, the cost or time that the project will take up cannot be
estimated. At times, due to a lack of communication, scope may need to change. This directly affects
the cost and disturbs the schedule of the project, causing losses.

Scope management is not difficult to implement rigorously. It does, however, require some effort,
time and patience. It's well worth the investment. With proper scope management, it is easy to
specify a clear scope and to deliver the project with minimal overruns.

Successful Scope Management is a function of strategic management actions and utilizing suitable
tools that extend human thinking and aid in the definition scope at a fairly low level of granularity.

Project Authorisation

Project Authorisation is a general process of verifying a proposed project for initiation and
further development. This process aims to confirm that the project is feasible and cost-
effective, so it can step through the initiation phase and proceed to the planning phase.

16 | P a g e
It involves key stakeholders in review and analysis of the project to confirm this project is
worth initiation.

As a process, project Authorisation carries out a series of activities. In general, these


activities are:

 Propose the project. This activity involves identification and description of project
goals, deliverables, benefits and impact. It creates a proposal request that is
submitted to the sponsor and customer for review.
 Review the project. This activity aims to review the proposed project through
analyzing its feasibility and cost-effectiveness.
 Approve/reject the project. The final activity is intended to generate a response to
the proposal request and submit it to the development team. Such a response
authorizes or rejects the project for initiation and further development.

Company directors are responsible to shareholders and other stakeholders to ensure that the capital
invested in the company is used prudently. Directors are expected to maximize the return on
investment for that capital. The principal reason for having a project Authorisation procedure is to
ensure that money will only be spent on projects that promise to be profitable or are otherwise
essential in the interests of the organization and its stakeholders.

If there were no filter to block expenditure on inappropriate projects, one could imagine that
individuals within a company might embark willy-nilly on high-risk schemes, perhaps relying only on
their intuition or even on pressure from peers. Such laissez-faire acquiescence could also open easy
paths to fraud. Some spectacular failures by maverick investment bankers have occasionally hit the
news, when traders took risks with funds belonging to others, lost colossal sums and harmed their
employers in the process.

Thus the need to control capital expenditure on new projects and to strive for maximum possible
return on investment must top the following list of reasons why companies need formal project
Authorisation procedures. Those procedures are also necessary for administrative reasons. The
prime reasons for having a formal project Authorisation system are as follows:

1. to control the use of capital expenditure in the best interests of shareholders and other
stakeholders;
2. to deter fraud;
3. to announce that approval has been given for a new project;
4. to communicate details of the project throughout the organization;
5. to announce the project’s name and identification number as it will appear in all accounts
and reports;
6. to announce key objectives (including project milestones and cost budgets);
7. to announce the name of the project manager and confirm his/her authority to manage the
project;
8. to define any restrictions or limits on expenditure (particularly for provisional
Authorisations).

17 | P a g e
Project Authorisation as a Chain Reaction

Once a project of any significant size has begun it is common for many other companies to become
involved as contractors, subcontractors, suppliers, consultants and so on. Thus project Authorisation
can trigger a chain reaction. It begins with the project owner making the initial decision to invest
money in the project. When other contractors and external companies are engaged to take part in
the main project, they too will apply project Authorisation procedures within their own
organizations before they allow their staff to begin work or place external purchase orders and
further subcontracts. However, the Authorisation criteria for those contractors and external
companies will usually depend not on predicted longer-term post-project benefits, but on the more
immediate revenues to be earned for working on the project.

Project Authorisation Criteria for the Project Owner

The processes of project Authorisation used by project owners are particularly relevant to change
management and IT projects, and they often involve difficult decisions. This section will therefore
take a glimpse at the process of project Authorisation from the viewpoint of a project owner.

Activity 2

Should you commence a project prior to obtaining authorisation? Why/Why Not?

18 | P a g e
Activity 2

Obtain authorisation to expend resources

Authorisation of Minor Works and Very Small Projects

Clearly, every company will need to authorize internal projects of a minor nature from time to time,
when the full force of a formal authorisation procedure would be inappropriate. A prudent board of
directors will often allow discretionary power to nominated managers that will allow them to
authorize relatively minor projects on their own authority, without need for further reference to the
board. There are two ways in which this can be done:

1. By specifying a maximum project size that a named manager can authorize, that size
typically being defined by the estimated total project cost. In other words, a manager is
given an upper limit of discretionary spending authority.

19 | P a g e
2. By treating minor projects and small works as operational expenses within the annual
budgets allocated to and controlled by departmental managers. Maintenance work is one
example.

The second of these options is easier to control, given an adequate company accounting system and
good cost reporting.

However, whenever any manager is given independent authority to initiate expenditure, fraud
prevention demands that a different manager should approve all resulting invoices before payment
of significant sums to external suppliers and contractors. To explain the reason for such precautions,
consider the extreme (but not unknown) case of a manager who could authorize a project for work
on their private residence, fraudulently using company funds. Unless an independent manager sees
the incoming invoices for approval, the fraud might go unnoticed.

Authorisation Criteria for an Internally Funded Management Change or IT Project

Imagine that you have prepared a business plan for a new project, and that you have the task of
presenting the plan to your board of directors in the expectation of receiving Authorisation for the
project to go ahead. No doubt you will have prepared an impressive PowerPoint® presentation that
sets out the costs and benefits of your project, and you will hand out fact sheets to all those present
at the meeting. Which of the criteria in your presentation do you think would most influence the
directors’ decision?

Supposing, for the moment, that this is the only new project under consideration, the directors will
probably want to know the answers to several important questions, such as:

 Do all the cost/benefit predictions point to a return on investment (either as cash or


benefits) in line with corporate objectives? If not, what are the alternative justifications for
this project?
 How certain can we be that the cost estimates are safe and include all known items?
 Are there any special risks associated with the project that might prevent its success?
 Are the predicted benefits achievable or are they over-optimistic?
 Do we have, or can we get, the resources needed for the project?
 Will the project be difficult to implement: will it disrupt our current operations and what
impact will it have on our staff?
 Have other companies attempted similar projects, and what were their experiences?

If the answers to these questions are favourable, you should expect that the board will approve
your project and the Authorisation process can be put in motion.

Authorizing Projects That Have No Immediate or Apparent Benefits

There are projects that must sometimes be undertaken where there are no immediately obvious
tangible benefits. There are many examples in not-for-profit organizations.

Projects carried out in accordance with statutory instructions might have no obvious benefit.
Suppose, for instance, that the owner of a hotel has been served notice to carry out specified works
costing $500,000 before a Fire Certificate can be issued.

20 | P a g e
At first glance, this is a project with no tangible benefits, the net present value (NPV) would be a
huge negative value, and there would appear to be no reason for going ahead with the project on
purely financial grounds. But, if the owner failed to do that project, no Fire Certificate could be
issued and the hotel would have to close down.

Feasibility projects have no immediate benefit for their owners other than evaluating a possible
actual project and limiting its risks. One feasibility project for developing a new copper mining
complex took two years and cost the owner many millions of pounds in engaging external
consultants. Of course the consultants made money (as consultants usually do). But the owner had
to authorize the project as an essential and prudent precursor to the much larger mining
development project to follow, and pay the whole cost of the study from reserve capital.

There are countless other examples of such feasibility projects, many in the public eye. The new
Wembley Stadium project, for instance, underwent considerable preliminary studies and debate
before the actual construction project was authorized (and even then the outcome did not
immediately produce the expected benefits).

Authorisation Criteria for Additional Internal Management Change or It Projects

The authorisation decision for a new project will be complicated if other management change or IT
projects are already in progress in the organization, or if the application for the project is one of
several such applications. This takes us into the territory of ‘portfolio management’. Managing a
number of simultaneous projects within a company or group of companies is called ‘programme
management’.

Now new decision parameters must be added to those listed earlier in this chapter. Not only must
the board of directors consider the implications of each new project application on its own merits,
but they must also decide whether the organization will have enough resources to add the new
project to its portfolio. Very often, companies have to make a choice between different projects, any
one of which might appear to be justifiable on its own merits, but for which resources cannot be
made available.

Standardizing multiple business plan presentations

The authorisation decision process is often made more difficult for the directors of a large
organization or group of companies because business plans for proposed projects can be prepared in
a variety of different formats. Imagine keen managers in different companies within the group, all
potential initiators of new management projects, and all having their own individual ideas of how to
prepare a business plan. That difficulty can be eased by appointing a coordinator or portfolio
manager who will make certain that all proposals for new projects are accompanied by well-
reasoned business plans, all presented in a common standard format.

The board of directors must always be clear that the portfolio of authorized projects represents the
projects that fully deserve highest priority (which means that they have the highest claim on the
group’s available resources).

21 | P a g e
Authorisation Documents Issued by the Project Owner

The complexity of the project Authorisation procedure must depend to a large extent upon the
estimated cost of the project and the size of the impact that it would have on the business.
Management change projects of any significant size will usually require a ‘charter and contract’,
‘project initiation document’ or ‘works order’ procedure.

Authorisation by Charter and Contract

Some organizations invoke a lengthy authorisation procedure that consists of a project charter,
followed by a contract.

The charter is a form of specification that sets out the principal objectives and is prepared for
consideration and approval by the company’s senior management. It reflects the business plan, item
for item. Once the charter has been approved, a separate and subsequent exercise is undertaken to
translate the charter into a contract.

The contract is a working document that establishes the project in the organization under the
nominated project manager. The contract is internal, between the project manager and the board of
directors.

My own view is that the charter and contract method is cumbersome, expensive to administer, and
can delay the start of work unnecessarily for many months. It has to be used with discretion.

Authorisation Using a Product Initiation Document

Although still fully comprehensive, a project initiation document (PID) of a form similar to that
shown in Figure 8.1 is a concise and more practical alternative to the charter and contract
arrangement. The PID can fulfil both the role of the charter and the contract.

22 | P a g e
Figure 8.1 Example contents of a project initiation document (PID)

Authorisation by Internal Memorandum

Small in-house projects are often authorized by an internal memorandum issued by a senior
manager to the department or project manager responsible. For example, a company may decide to
refurbish a small area of its office premises, perhaps finding temporary occupation for the staff for
two or three weeks while the refurbishment takes place. That work must certainly be managed as a
project, but it hardly needs an elaborate Authorisation procedure. A memorandum from the
managing director to the facilities manager specifying the requirements and the budget is all that is
needed.

23 | P a g e
An internal memorandum that authorizes a small project constitutes a contract between the project
owner (represented by the board of directors or senior management in this case) and the
‘contractor’ (which, for an internal project, is the departmental manager to whom the memorandum
is issued).

Project Registration and Numbering

Once a new project of any kind has entered an organization it has to be formally ‘entered into the
system’ so that all the necessary accounting, planning, progressing and other administrative
procedures can be put in place.

One of the first steps is to allocate an identification number to the new project which, depending on
the procedures of the particular company, will be used henceforth as a basis for drawing and
specification numbers, cost codes and other important project documentation. Project numbers are
usually derived serially from a register, which might be a loose-leaf book or a computer file. The top
section of a typical project register page is shown in Figure 8.2.

The purpose of a project register is, of course, not only to allocate numbers. The register of current
projects lists all authorized work within the organization against which time may legitimately be
booked by staff on timesheets and against which the costs of project materials and expenses may be
charged.

Figure 8.2 Essential elements of a project register

Whenever it is necessary to retrieve information about a project, current or long past, the project
register is usually the best, often the only, place to begin the search. In most management
information systems (MIS) or archives, the project number is the essential element leading to the
various document files and project data. But the project number might not be known or
remembered. Very often historical searches start with only a vague recollection of the project
description, or the name of the customer, or the approximate dates. Each entry in the project
register should therefore record the following data:

 project title;
 start date and (eventually) closure date;
 project manager responsible;
 project number;

24 | P a g e
 the customer or client (obviously only applicable to projects sold externally);
 the customer’s order number or letter reference.

A well-kept register will enable any project to be identified even when only one or two of the
associated data items listed above are known. When projects are closed, the register information
should be kept in a secure but accessible archive. A computer record will allow search and retrieval
using keywords.

Project Authorisation in a Contracting Organization

Project Authorisation by a contractor usually means that the contractor has been instructed by the
owner, customer or client to proceed with the project on terms that have previously been
negotiated and agreed. This instruction might be received in the form of a contract, a purchase order
or (less desirably) a letter of intent.

The resulting Authorisation document issued within the contracting company might be entitled
‘project Authorisation’ or perhaps ‘works order’. This document carries essential data that deine the
levels of expenditure authorized (the departmental and purchasing cost budgets), planned start and
finish dates, details of the customer’s order, pricing information, invoicing and delivery instructions,
and so on.

One vital item on a project Authorisation is the signature of a member of the contractor’s senior
management. That is the signal that the project is properly authorized, that work can begin, and that
costs can be incurred or committed.

Format and General Content of a Project Authorisation

The data in project Authorisations are usually summarized, often to the extent that all the
information can be printed on one side of an A4 page. This can be true even for large capital
projects. Precise project definition is achieved by listing the relevant technical and commercial
documents on the Authorisation form. If, for example, the project has been won after in-depth
negotiation of a detailed contract, coupled with the discussion of technical and commercial sales
specifications, the project Authorisation must identify those documents without ambiguity by giving
their serial numbers and all approved amendments or revision numbers.

Figure 8.3 shows a works order form of a type that has been used for many years in manufacturing
companies handling special projects. The information given on budgets and schedules is necessarily
brief, and is provided on the form only to allow outline planning and to place overall limits on the
amount of expenditure authorized. Detailed budgets and work-to lists usually take some time to
prepare and may be delayed by several weeks after the project is authorized.

Figure 8.4 shows a project Authorisation form used by a mining engineering company to initiate and
authorize projects ranging from small feasibility studies and minor plant extensions to very large
capital projects. Again, the form summarizes the essential points (although this company did
tabulate more detailed budgets on the reverse side of the form). A fairly comprehensive MIS was in
use and the form was designed to provide the basic input data to the system (as well as informing
departmental managers about the new project).

25 | P a g e
Distribution of Project Authorisation Documents

Project Authorisations are distributed to all company departments for general information, but the
full supporting technical and commercial documents are handed over only to the project manager. It
becomes the project manager’s responsibility thereafter to ensure that all other managers in the
organization are made aware of their particular project requirements in detail, and sufficiently in
advance to enable them to make any necessary preparations.

Figure 8.3 Works order example for a manufacturing project

26 | P a g e
Authorizing Work Without a Contract or Customer’s Order

The Golden Rule

One thing that all managers are taught is that no expense shall be committed on any project unless
the customer’s written authority to proceed (and promise to pay) has first been obtained. The risks
for disobeying this rule are obvious. Once the customer knows that the contractor has already
become committed to actual costs, the contractor’s bargaining position in contract negotiations has
been weakened. Worse still, if the customer decides not to go ahead with the project or give the
work to another company, all the contractor’s committed costs will be forfeit.

27 | P a g e
Figure 8.4 Project Authorisation form used by a mining engineering company

For these good reasons, an internal project Authorisation document will not normally be issued
unless the customer’s written authority to proceed has been obtained.

Breaking the Rule

In spite of convention, there might be occasions when a very limited amount of work can be
authorized before receipt of a firm order from the customer.

28 | P a g e
This poses risks. Indeed, to many work-hardened managers it will sound like heresy. Nevertheless,
provided the risks can be quantified and contained within controlled limits it is often possible to gain
several weeks’ progress in the project calendar for the expenditure of only a tiny fraction of the total
project cost. Of course, no orders for materials can be placed, but it might be possible to carry out
activities from a preliminary project start-up checklist without committing more than one or two
people over the limited period concerned.

Naturally, such advance work in the absence of a customer order will only be authorized where this
strategy has advantages for the contractor. These advantages might include the avoidance of
possible trouble later on, if the overall project timescale is seen to be particularly tight.

If the contractor foresees a trough in the organization’s total workload, it could suit the contractor to
carry out a little preliminary work, to enable full-scale work on the new project to start as soon as
the order is received.

By these methods, progress on a new project might be pulled forward by a month or two.
Conversely, doing absolutely nothing and waiting until the official order is received from the
customer could mean that the main project workload will be delayed until it interferes with work for
other projects.

Graphs of project expenditure plotted against time display a characteristic S shape (see Figure 8.5).
The rate of expenditure usually starts very slowly, increases greatly during the middle part of the
project life cycle, and then falls off as the project nears completion. Any talk of authorizing advance
expenditure must be limited to the first few weeks, when the rate of expenditure is very low and
confined to preliminary engineering or administrative tasks. Steps must be taken to ensure that the
expenditure rate remains low. Any decision to allow advance work is always risky, and this must be
reflected in the conditions listed in the authorizing document. A preliminary issue of the project
Authorisation can be used but only with the following provisos:

29 | P a g e
Figure 8.5 A typical project engineering cost/time relationship

 authorisation must be limited to allow only one or two named individuals to do the work;
 the project accounting system should be programmed to reject time booked by people who
are not on the authorized list;
 no materials or equipment must be ordered;
 there must be a total budget allocation for this work, regarded as the ‘write-off’ value of the
risk;
 the work to be done should be defined and confined by a checklist or schedule;
 progress and costs must be monitored and reported to senior management so that work can
be stopped immediately at any time.

Confirm project delegations and authorities in project governance


arrangements2
Project management and the art of delegation

All project managers have numerous pressures on their time, and need to achieve a high rate of
productivity. Many also feel they are too busy to waste time delegating properly and try to do
everything themselves. One key to effective time management and getting a ‘life’ outside of the
office (which actually makes you more efficient in the office) is effective delegation. Unfortunately
the people who need to read this article are probably too busy being busy to have time.

2
Source: Project Manager, as at http://projectmanager.com.au/project-management-delegation/, as on 5th
August, 2016.

30 | P a g e
Delegation is when you assign responsibility to another person to carry out a specific task, and is one
of the most important management skills. You delegate, or assign responsibility for an action every
time you:

 Assign a resource to a schedule activity;


 Assign responsibility for an action item, issue or risk; or
 Decide to transfer a job on your to-do list to someone else as part of your personal time
management strategy.

To delegate effectively, you need to put yourself in a position where there are good people to whom
you can delegate responsibility and be mentally prepared to accept the fact that you need to
delegate to others. If you can delegate properly it is not quicker to do the thing yourself!

Process delegations: Many people forget that assigning work to a person through any of the project
management processes is in effect delegation. You need to assign the appropriate level of authority
and responsibility to an individual who accepts the responsibility for accomplishing the task.

Personal delegations: Based on the available skills in the people you can delegate to; all of the tasks
in your to-do list that have a low level of importance should be delegated and potentially some of
the important ones as well. You need to focus on tasks that are in your area of expertise – where you
can make the biggest difference for the entire team/project and allocate the rest of the items on
your list among the team, based on their individual skill sets. Let the team know the process you’ve
been through, the fact that you need their help, and the relevance and value of the tasks you are
delegating.

The process of delegating

To start the process, first select the people to delegate to, based on their positive attitude and
demonstrated willingness to challenge and contribute: people who already deliver what’s expected
of them in terms of timeliness and quality and go beyond what’s expected.

Having chosen the people, start small, build on what they already know and their existing skills but
also be prepared to use the delegation to help the person grow in confidences and capability by
adding incremental ‘extras’; make sure the additional challenges are seen as an opportunity, not a
punishment.

Each delegation requires the person to know how to do the task (preferably, they already have the
skills or have access to coaching and mentoring support); know why the task needs doing, its
relevance and their contribution to the greater objective; and know exactly what has to be
accomplished using the acronym SMARTER.

Each delegation should follow the SMARTER rules:

 Specific
 Measurable
 Agreed
 Realistic
 Timebound

31 | P a g e
 Ethical
 Recorded

Good delegation saves you time, develops your people, grooms a successor, and motivates. Whereas
poor delegation will de-motivate your team, confuse the other person and fail to achieve the task or
purpose. To maximise the outcomes, regularly assess how each person is doing, how you are doing
and where there have been ‘failures’ the cause of the failure, most of the time it’s caused by
management not the individual.

Delegation check list

To delegate work to team members, everyone needs to be clear about the following:

 Activity name: This comes from the schedule if it’s an activity, other delegations need a
clear, unique name to facilitate effective communication.
 An explanation: The reason the work being delegated needs to be clearly defined together
with authority levels and escalation options.
 The deliverable: The team member needs to understand the scope of the work and the
deliverable or work component (a portion of a larger deliverable) that s/he is expected to
complete. If there are quality criteria to meet, the team member should know these quality
requirements and any relevant acceptance criteria.
 Start-date and end-date: Everyone needs to be clear on when the activity can start and
when the activity is due to be completed. If the team member cannot meet the deadline
date, s/he needs to let the project manager know as soon as possible.
 Estimated effort hours (optional): The project manager should communicate the estimated
hours required to complete the activity. This is usually of secondary importance compared
to the due date unless the customer is getting charged for each hour worked. If the team
member cannot complete the activities within the estimated effort hours, s/he needs to let
the project manager know as soon as possible.
 Estimated costs (optional): If the team member cannot complete the work within the cost
estimate, s/he needs to let the project manager know as soon as possible with the reason, if
known, and any suggestions to resolve the problem.
 Dependencies: Make sure the team member knows the relationship between his/her work
and any other activities such as those waiting on the deliverable or those that must be
completed before his/her work can start (or continue).
 Other resources: Communicate if there are other people or resources working on the same
activities. The team member must understand their role and who has overall responsibility
for the activity.

If team members understand the work perfectly but don’t deliver on time, you may have a
performance problem. However, if the team member is not clear about the work they have been
assigned or the due date, the project manager may have a communication problem.

32 | P a g e
Activity 3

Explain why project delegation is necessary.

33 | P a g e
Activity 3

Project Governance3

The simplest definition of project governance is that it is the framework for effective project decision
making. The same holds true for portfolio or program governance. The framework comprises:

 The structure composed of the governance decision-making committees and roles;


 The people that populate the governance structure;
 The information that informs the decision makers.

A good program or project governance framework has these components working together to
ensure business investments (and this is what programs and projects are) deliver optimum
outcomes.

3
Source: Ross Garland and Associates, as at http://www.rossgarland.com/why-is-our-program-project-
governance-so-effective/, as on 5th August, 2016; QTC Consulting, as at http://www.qtc-
consulting.com.au/Project-Governance.html, as on 5th August, 2016; Wikipedia, as at
https://en.wikipedia.org/wiki/Project_governance, as on 5th August, 2016.

34 | P a g e
Why is good program and project governance so important? Good program and project governance
is about effective decision making. It’s the difference between focussing on building an asset and
focusing on achieving an outcome, realising benefits and delivering value for money. This is achieved
by taking a business focused approach to decision making. It means ensuring business ownership of
programs and projects, clarity of decision making and developing a quality, but not necessarily large,
business case.

Principles of effective program and project governance

The following are just some of the core principles to follow in the design of governance frameworks.
Bear in mind though that every situation is different and the way these principles are applied can
vary significantly.

 Treat business as usual differently to change.

Projects (change) require their own governance structure. The organisation structure is not
designed to deliver change.

 Ensure a single point of accountability.

This ensures clarity of decision making and empowers the accountable person.

 Service outcome ownership determines project ownership.

This places business interests at the heart of project delivery.

 Separate organisational governance and project governance.

This principle speeds up decision making since the project decision path does not follow the
organisational line of command.

35 | P a g e
 Ensure separation of stakeholder management and project decision making activities.

This prevents decision making forums becoming clogged with stakeholders, resulting in
laboured decision making.

 Develop and maintain the business case.

The business case is the key governance document.

 Ensure clarity of decision making responsibilities.

All stakeholders should be clear who makes what decisions and why.

Therefore, the role of project governance is to provide a decision making framework that is logical,
robust and repeatable to govern an organisation’s capital investments. In this way, an organisation
will have a structured approach to conducting both its business as usual activities and its business
change, or project, activities.

Several recent public sector projects have been uncovered by auditors and by the media and
severely criticised as delivering far too little benefit and not meeting projected outcomes, budgets or
deadlines. The executives responsible for projects cannot avoid their responsibility for such loss and
failure to deliver promised assets and services within promised/agreed parameters.

Current research shows that the majority of project failures are primarily caused by inadequate
project management and in particular project governance. The majority of these failures can be
attributable to the managers and executives at the head of the project decision tree. QTC will ensure
the following:

 The board has overall responsibility for governance of project management


 The roles, responsibilities and performance criteria for the governance of project
management are clearly defined
 Disciplined governance arrangements, supported by appropriate methods and controls are
applied throughout the project life cycle
 A coherent and supportive relationship is demonstrated between the overall business
strategy and the project portfolio
 All projects have an approved plan containing authorisation points, at which the business
case is reviewed and approved. Decisions made at authorisation points are recorded and
communicated
 Members of delegated authorisation bodies have sufficient representation, competence,
authority and resources to enable them to make appropriate decisions
 The project business case is supported by relevant and realistic information that provides a
reliable basis for making authorisation decisions
 The board or its delegated agents decide when independent scrutiny of projects and project
management systems is required, and implement such scrutiny accordingly
 There are clearly defined criteria for reporting project status and for the escalation of risks
and issues to the levels required by the organisation
 The organisation fosters a culture of improvement and of frank internal disclosure of project
information

36 | P a g e
 Project stakeholders are engaged at a level that is commensurate with their importance to
the organisation and in a manner that fosters trust

Core project governance principles

Project governance frameworks should be based around a number of core principles in order to
ensure their effectiveness.

Principle 1: Ensure a single point of accountability for the success of the project

The most fundamental project accountability is accountability for the success of the project. A
project without a clear understanding of who assumes accountability for its success has no clear
leadership. With no clear accountability for project success, there is no one person driving the
solution of the difficult issues that beset all projects at some point in their life. It also slows the
project during the crucial project initiation phase since there is no one person to take the important
decisions necessary to place the project on a firm footing. The concept of a single point of
accountability is the first principle of effective project governance.

However, it is not enough to nominate someone to be accountable – the right person must be made
accountable. There are two aspects to this. The accountable person must hold sufficient authority
within the organisation to ensure they are empowered to make the decisions necessary for the
project’s success. Beyond this however is the fact that the right person from the correct area within
the organisation be held accountable. If the wrong person is selected, the project is no better placed
than if no one was accountable for its success. The single person who will assume accountability for
the success of the project is the subject of Principle 2.

Principle 2: Project ownership independent of Asset ownership, Service ownership or other


stakeholder group

Often organisations promote the allocation of the Project Owner role to the service owner or asset
owner with the goal of providing more certainty that the project will meet these owner's
fundamental needs, which is also a critical project success measure. However, the result of this
approach can involve wasteful scope inclusions and failure to achieve alternative stakeholder and
customer requirements:

1. The benefit of the doubt goes to the stakeholder allocated with the Project Owner
responsibility, skewing the project outcome;
2. Project Owner requirements receive less scrutiny, reducing innovation and reducing
outcome efficiency;
3. Different skill sets surround Project ownership, Asset ownership and Service ownership
placing sound project decision making and procedure at risk;
4. Operational needs always prevail, placing the project at risk of being neglected during such
times;
5. Project contingencies are at risk of being allocated to additional scope for the stakeholder
allocated project ownership.

37 | P a g e
The only proven mechanism for ensuring projects meet customer and stakeholder needs, while
optimising value for money, is to allocate Project ownership to specialist party, that otherwise would
not be a stakeholder to the project. This is principle No. 2 of project governance.

The Project Owner is engaged under clear terms which outline the organisations key result areas and
the organisation's view of the key project stakeholders. Often, organisations establish a Governance
of Projects Committee, which identifies the existence of projects and appoints project owners as
early as possible in a project's life, establishes Project Councils which form the basis of customer and
stakeholder engagement, establishes the key result areas for a project consistent with the
organisations values, and, oversees the performance of projects. These parameters are commonly
detailed in a Project Governance Plan which remains in place for the life of the project (and is
distinct from a Project Management Plan which is more detailed and only comes into existence
during the development of the project).

Projects have many stakeholders and an effective project governance framework must address their
needs. The next principle deals with the manner in which this should occur.

Principle 3: Ensure separation of stakeholder management and project decision making activities

The decision making effectiveness of a committee can be thought of as being inversely proportional
to its size. Not only can large committees fail to make timely decisions, those it does make are often
ill considered because of the particular group dynamics at play.

As project decision making forums grow in size, they tend to morph into stakeholder management
groups. When numbers increase, the detailed understanding of each attendee of the critical project
issues reduces. Many of those present attend not to make decisions but as a way of finding out what
is happening on the project. Not only is there insufficient time for each person to make their point,
but those with the most valid input must compete for time and influence with those with only a
peripheral involvement in the project. Further not all present will have the same level of
understanding of the issues and so time is wasted bringing everyone up to speed on the particular
issues being discussed. Hence, to all intents and purposes, large project committees are constituted
more as a stakeholder management forum than a project decision making forum. This is a major
issue when the project is depending upon the committee to make timely decisions.

There is no question that both activities, project decision making and stakeholder management, are
essential to the success of the project. The issue is that they are two separate activities and need to
be treated as such. This is the third principle of effective project governance. If this separation can
be achieved, it will avoid clogging the decision making forum with numerous stakeholders by
constraining its membership to only those select stakeholders absolutely central to its success.

There is always the concern that this solution will lead to a further problem if disgruntled
stakeholders do not consider their needs are being met. Whatever stakeholder management
mechanism that is put in place must adequately address the needs of all project stakeholders. It will
need to capture their input and views and address their concerns to their satisfaction. This can be
achieved in part by chairing of any key stakeholder groups by the chair of the Project Board. This
ensures that stakeholders have the project owner (or SRO) to champion their issues and concerns
within the Project Board.

38 | P a g e
Principle 4: Ensure separation of project governance and organisational governance structures

Project governance structures are established precisely because it is recognised that organisation
structures do not provide the necessary framework to deliver a project. Projects require flexibility
and speed of decision making and the hierarchical mechanisms associated with organisation charts
do not enable this. Project governance structures overcome this by drawing the key decision makers
out of the organisation structure and placing them in a forum thereby avoiding the serial decision
making process associated with hierarchies.

Consequently, the project governance framework established for a project should remain separate
from the organisation structure. It is recognised that the organisation has valid requirements in
terms of reporting and stakeholder involvement. However dedicated reporting mechanisms
established by the project can address the former and the project governance framework must itself
address the latter. What should be avoided is the situation where the decisions of the steering
committee or project board are required to be ratified by one or more persons in the organisation
outside of that project decision making forum; either include these individuals as members of the
project decision making body or fully empower the current steering committee/project board. The
steering committee/project board is responsible for approving, reviewing progress, and delivering
the project outcomes, and its intended benefits, therefore, they must have capacity to make
decisions, which may commit resources and funding outside the original plan. This is the final
principle of effective project governance.

Adoption of this principle will minimise multi layered decision making and the time delays and
inefficiencies associated with it. It will ensure a project decision making body empowered to make
decisions in a timely manner.

Additional and complementary principles of governance

The board has overall responsibility for governance of project management. The roles,
responsibilities and performance criteria for the governance of project management are clearly
defined. Disciplined governance arrangements, supported by appropriate methods and controls are
applied throughout the project life cycle. A coherent and supportive relationship is demonstrated
between the overall business strategy and the project portfolio.

All projects have an approved plan containing authorisation points, at which the business case is
reviewed and approved. Decisions made at authorisation points are recorded and communicated.
Members of delegated authorisation bodies have sufficient representation, competence, authority
and resources to enable them to make appropriate decisions. The project business case is supported
by relevant and realistic information that provides a reliable basis for making authorisation
decisions. The board or its delegated agents decide when independent scrutiny of projects and
project management systems is required, and implement such scrutiny accordingly.

There are clearly defined criteria for reporting project status and for the escalation of risks and
issues to the levels required by the organisation. The organisation fosters a culture of improvement
and of frank internal disclosure of project information. Project stakeholders are engaged at a level
that is commensurate with their importance to the organisation and in a manner that fosters trust.

39 | P a g e
Principles for multi-owned projects

Multi-owned is defined as being a project where the board shares ultimate control with other
parties. The principles are:

 There should be formally agreed governance arrangements


 There should be a single point of decision making for the project
 There should be a clear and unambiguous allocation of authority for representing the project
in contacts with owners, stakeholders and third parties
 The project business case should include agreed, and current, definitions of project
objectives, the role of each owner, their incentives, inputs, authority and responsibility
 Each owner should assure itself that the legal competence and obligations and internal
governance arrangements of co-owners, are compatible with its acceptable standards of
governance for the project
 There should be project authorisation points and limiting constraints to give owners the
necessary degree of control over the project
 There should be agreed recognition and allocation or sharing of rewards and risks taking into
account ability to influence the outcome and creating incentives to foster co-operative
behaviour
 Project leadership should exploit synergies arising from multi-ownership and should actively
manage potential sources of conflict or inefficiency
 There should be a formal agreement that defines the process to be invoked and the
consequences for assets and owners when a material change of ownership is considered
 Reporting during both the project and the realisation of benefits should provide honest,
timely, realistic and relevant data on progress, achievements, forecasts and risks to the
extent required for good *governance by owners
 There should be a mechanism in place to invoke independent review or scrutiny when it is in
the legitimate interests of one or more of the project owners.
 There should be a dispute resolution process agreed between owners that does not
endanger the achievement of project objectives.

Roles

A key role in project governance is that of the project sponsor. The project sponsor has three main
areas of responsibility which are to the board, the project manager and the project stakeholders.

The board

For the board, the sponsor provides leadership on culture and values, owns the business case, keeps
the project aligned with the organisation's strategy and portfolio direction, governs project risk,
works with other sponsors, focuses on realisation of benefits, recommends opportunities to
optimise cost/benefits, ensures continuity of sponsorship, provides assurance and provides feedback
and lessons learnt.

40 | P a g e
The project manager

For the project manager, the sponsor provides timely decisions, clarifies decision making framework,
clarifies business priorities and strategy, communicates business issues, provides resources,
engenders trust, manages relationships, supports the project manager's role and promotes ethical
working.

Project stakeholders

For other project stakeholders, the project sponsor engages stakeholders, governs stakeholder
communications, directs client relationship, directs governance of users, directs governance of
suppliers and arbitrates between stakeholders.

Elements

Project governance will:

 Outline the relationships between all internal and external groups involved in the project
 Describe the proper flow of information regarding the project to all stakeholders
 Ensure the appropriate review of issues encountered within each project
 Ensure that required approvals and direction for the project is obtained at each appropriate
stage of the project.

Important specific elements of good project governance include:

 A compelling business case, stating the objects of the project and specifying the in-scope and
out-of-scope aspects
 A mechanism to assess the compliance of the completed project to its original objectives
 Identifying all stakeholders with an interest in the project
 A defined method of communication to each stakeholder
 A set of business-level requirements as agreed by all stakeholders
 An agreed specification for the project deliverables
 The appointment of a project manager
 Clear assignment of project roles and responsibilities
 A current, published project plan that spans all project stages from project initiation through
development to the transition to operations.
 A system of accurate upward status- and progress-reporting including time records.
 A central document repository for the project
 A centrally-held glossary of project terms
 A process for the management and resolution of issues that arise during the project
 A process for the recording and communication of risks identified during the project
 A standard for quality review of the key governance documents and of the project
deliverables.

41 | P a g e
It’s the Deliverables that Make Governance Happen4

The "Governance Plan" is the primary deliverable of the governance process, providing a roadmap
for how a given project is to be managed. These plans should be standardized to save time, but also
readily adaptable to the needs of the project at hand. Once the plan is produced, it becomes the
authoritative “go-to” guide for running the subject project. As such, "plan" content must answer the
following questions:

 What are the key governance goals and objectives for the current project?
 What are the expected governance results and anticipated benefits?
 Who are the governance stakeholders and what are their respective roles and
responsibilities?
 What are the established governance procedures to be followed and used (considering all
the various governance practices listed above)?
 Why is each procedure necessary and how will each contribute to project success?
 How will the governance plan be maintained and updated as the project proceeds?

In order to meet these requirements, governance plan deliverables must be produced using
standardized formats - to save time and provide an appropriate framework for "plan" production
(while also allowing sufficient flexibility to meet varying project needs). As such, standardized plan
formats should be made a integral part of any and all adopted project management practices.

Tips and Techniques for Governance Plan Production

1. Be Nimble and Flexible. Governance plan formats must be sufficiently flexible to account for
varying project sizes (i.e. smaller, less complex projects may not require the same extensive
governance planning as large, complex projects.)
2. Ensure Clean and Concise Consistency. Governance plan formats must provide a clean,
concise layout to ensure that all key governance variables are presented, including resource
management, project communication, project administration, procurement, financial
management, and related matters.
3. Explain and Justify. Governance plan contents must specify planned procedures and provide
explanatory justifications for each in terms of inclusions and exclusions.
4. Accept and Approve. Governance plan formats must provide the means to obtain and
record related approvals, ensuring appropriate stakeholder acceptance and buy-in.

Stick to "Define, Align and Approve" for Actionable Results

The “governance planning” deliverable should be produced according to the "define-align-approve"


management technique, designed to ensure actionable content, alignment with needs and
capabilities and tangible stakeholder approval. Furthermore, the governance plan workflow should
be executed in standardized phases, designed to ensure that all key planning, preparation,
production and processing needs are addressed.

4
Source: IT Toolkit, as at https://www.ittoolkit.com/how-to-it/projects/project-governance-plans.html, as on
5th August. 2016.

42 | P a g e
Applying the "Define, Align, Approve" Technique

“Define/Align/Approve (DAA)” provides a strategic approach to informed decision making,


formulated to ensure that all plans and solutions are properly specified in actionable terms
(defined), sufficiently matched to underlying needs (aligned) and appropriately accepted by the
designated stakeholders (approved). This approach puts all ideas, plans and decisions through
standardized “scrutiny and validation safety net”, as expressed in three stages:

1. Have needs and solutions been sufficiently defined? Defined needs and solutions are
specified for "action" - to be executed and measured against established benchmarks for
success, timeliness, and quality. Without definition, successful results may always be out of
reach.
2. Are needs and solutions sufficiently aligned? Aligned needs and solutions are designed to
match strategic goals and objectives, as well as business requirements, technical
requirements and existing organizational capabilities. Above all, needs and solutions must
be do-able.
3. Have needs and solutions been accepted and approved? In order to set realistic
expectations and achieve intended benefits, needs and solutions must be openly negotiated,
with specific terms for acceptance and approval, which must be openly secured from all
decision making stakeholders.

Activity 4

Describe 2 factors you would consider to ensure the effectiveness of the governance of a project.

43 | P a g e
Activity 4

44 | P a g e
Identify, negotiate and document project boundaries5

Have you ever been part of a project where not everyone has the same view of where the project is
heading?

This lack of clarity can breed confusion: People start pulling in different directions, building up
unrealistic expectations, and harbouring unnecessary worries and fears.

While it's normal as part of a project to put the detailed plans, controls and reporting mechanisms
into place, how do you get everyone on the same page to start with?

This is accomplished by creating a Project Initiation Document (PID) – the top-level project planning
document. In it, you bring together all of the information needed to get your project started, and
communicate that key information to the project's stakeholders. With a well-put-together Project
Initiation Document, you can let everyone understand where the project's heading from the outset.

Your Project Initiation Document does the following:

 Defines your project and its scope.


 Justifies your project.
 Secures funding for the project, if necessary.
 Defines the roles and responsibilities of project participants.
 Gives people the information they need to be productive and effective right from the start.

By creating a PID, you'll answer the questions: What? Why? Who? How? When?

You can also use a Project Charter instead of a Project Initiation Document for these purposes as
they are very similar documents. However, a Project Charter usually has less detail. So a Project
Initiation Document is more suited to projects where you have the resources to write a more
detailed document.

What Is a Project Charter?6


A project charter describes what your project is and how you will approach it, and it lists the names
of all stakeholders. It's a critical component of the project management initiation and planning
phases, and you'll refer to it throughout the life of the project.

 Defining the Project Charter


When you start a project, you must define what needs to be accomplished and decide how the
project is going to proceed. Each project begins with an idea, a vision, or a business opportunity--and
that is the starting point that must be associated with your organization’s business objectives.

5
Source: Mind Tools, as at https://www.mindtools.com/pages/article/newPPM_85.htm, as on 5th August,
2016.
6
Source: Bright Hub PM, as at http://www.brighthubpm.com/project-planning/5161-what-is-a-project-
charter/, as on 5th August, 2016.

45 | P a g e
The project charter is that starting point. The charter lays the foundation of the project. It includes a
statement of your business's needs. What is the history that has led to the need? How was it
recognized, and why is it planned now?
Next, you must stipulate the project's purpose. How will you reach your goals? What deliverables
can you promise? What are the risks? You must identify your project resources and technologies,
and reflect on task dependencies. It's also important to define your indicators of success.
Last, you must tie in to all this the roles and responsibilities of your project team. You must define
resources--both human and material--and specify who or what will fill them. The charter forms a
contract with all stakeholders involved in the project.
The project charter is a single, consolidated source of information about the project in terms of
initiation and planning. Basically, the project charter defines the boundaries of the project, no
matter what type of project management methodology you are using. It is much more than an
effective planning tool. It serves both as anchor, holding you to your objectives, and as navigator,
guiding you through the milestones that will mark your progress. The original project charter will not
change throughout your project's life cycle. Once it is approved by the stakeholders, you cannot
modify or change the original charter without agreement by all parties involved.

 What Does the Project Charter Include?


Many projects start with a top-down approach, meaning you move forward from your initial goal
and create your plan. Even if you prefer to work backward from your drop-dead date, start your
charter from the top. Just like any good story, you begin at page one.
 Structured management organization. Who is the project owner? Describe the hierarchy of the
project team. Identify your stakeholder groups and reflect on their input.
 Disciplined management processes. Provide references and documents to help both team
members and stakeholders understand the project's parameters and ramifications. It's a good
idea to describe project terminology. Also, identify your chosen methodology. Even if you always
prefer the same methodology, you must justify why it will work for this project.
 Project scope. What are the costs and scheduling needs? What goals that fall outside the project
scope will be achieved along the way? Are there subphases to your project?
 Project management best practices. Here you will identify ways to coordinate assignments,
schedule team members, and track progress and costs. You will describe preferred
documentation requirements.
 Internal/external communications. Who will meet and how often? Whether you are managing
an enterprise-level project or just supervising a small team that communicates by phone calls or
emails, spell out expectations for communication methods and frequency.

 Who Is Responsible for the Project Charter?


With a well designed project charter you will realize benefits such as improved client partnerships
and other relationships. Communication with project owners and external stakeholders will flourish,
and your sponsors will buy in to your project more eagerly. You can expect defined project
management processes to run more fluidly. With universal recognition of the senior manager, you
will achieve on-time and on-budget delivery of goals.

"Project Initiation Document" and "PID" are terms used in PRINCE2®. PRINCE2 is a registered trade
mark of AXELOS Limited.

46 | P a g e
The project management methodology that your organization uses may also determine whether you
should use a Project Charter or a Project Initiation Document.

To run such projects efficiently, project managers use formal project management methodologies
such as PMBOK or PRINCE2.

PMBOK, which stands for the “Project Management Body Of Knowledge”, was first published in
1996 as a manual called A Guide to the Project Management Body of Knowledge. It is now in its
fourth edition.

It is a standard that represents generally-recognized good practice, and is published by the Project
Management Institute. This is a not-for-profit membership association for the project management
profession, which administers the associated Project Management Professional (PMP) qualifications.
PMBOK is the dominant project management methodology used in North America.

PRINCE2, which stands for "PRojects IN Controlled Environments", is widely used in the UK and in
English-speaking countries outside North America, and was originally devised as a “best practice”
standard to be used for managing UK government information systems projects. Since then, it has
become increasingly widely used for projects of all kinds, in the private as well as the public sector,
and although copyright in it is retained by the Crown and managed by the Office of Government
Commerce (OGC), its methods are in the public domain and are free for organizations to use.

Various accredited training organizations offer PRINCE2 qualifications at Foundation level, for those
who need to be familiar with its terminology, and at Practitioner level, which is aimed at project and
program manages.

Constructing a PID

Although most project-driven organizations have their own templates for Project Initiation
Documents, the information contained in those documents is often quite similar, despite variations
in the terms used.

Here, we work through the most common sections, and look at the information that should be
covered in each.

47 | P a g e
Project Initiation Document Checklist

48 | P a g e
Note:

The checklist is for guidance only. In your situation, it may be appropriate to leave some items out
and/or add others.

Section 1: What?

This section tells the reader what the project is seeking to achieve. In it, describe the problem that
the project is seeking to solve, as well as a full definition of the project.

This section will typically cover the following topics:

Background

What is the context of the project, and why is the work needed? Briefly describe the idea or
problem, and discuss why this project is relevant and timely. The details will come later, so use this
section to highlight briefly how this project came to be.

49 | P a g e
Project Definition

 Purpose: Why are you doing this work? Describe the desired end result of this project.
 Objectives: What specific outcomes will be achieved, and how will you measure these
outcomes? Remember to limit the number of objectives for your project – four or five goals
are typically enough.
 Scope: What are the boundaries for this project (for example, type of work, type of client,
type of problem, geographic area covered)? List any areas excluded that you believe
stakeholders might assume are included, but are not. The more specific you are, the less
opportunity there is for misunderstanding at a later stage in the project.
 Deliverables: What will the project deliver as outputs? Where you can, describe deliverables
as tangible items like reports, products, or services. Remember to include a date that each
deliverable is expected. You'll use this information to monitor milestones.
 Constraints: What things must you take into consideration that will influence your
deliverables and schedule? These are external variables that you cannot control but need to
manage.
 Assumptions: What assumptions are you making at the start of the project? If necessary,
schedule work to confirm these assumptions.

Section 2: Why?

Build a business case to show why your project is going ahead. Describe the effect the project will
have on the business, and support this with a detailed account of the risks that should be
considered.

Business Case

 Benefits: Why are you carrying out this project, and what benefits do you expect it to
deliver? Include information on how these benefits will be measured.
 Options: What other courses of action were considered as this project was designed and
developed?
 Cost and Timescale: Provide a breakdown of project costs and related financing.
 Cost/Benefit Analysis: How are the costs of the project balanced against the expected
returns?

Risk Analysis

 Risk Identification: Identify the risks within the project, and that you'll either need to
manage or accept.
 Risk Prevention: Describe what you are going to do to mitigate or manage risks.
 Risk Management: Where you can't prevent risks, what are your contingency plans for
dealing with them? What actions will you take should the risk materialize?
 Risk Monitoring: What processes do you have in place to routinely assess the risks
associated with your project?

50 | P a g e
Section 3: Who?

Describe how the project will be organized and managed. Identify reporting lines, and outline
specific roles that will be filled. You need to be clear about staff roles so that you don't duplicate
responsibilities, and so that everyone is clear about what's expected of them. If this is a long-term
project, you may even consider developing job descriptions for team members.

Roles and Responsibilities

 Project Organization Chart/Structure: Create a diagram that shows the lines of authority
and reporting for each project team member.
 Project Sponsor: Who has the ultimate authority and control over the project and its
implementation?
 Project Manager: Who is the Project Manager, and what are his or her responsibilities?
 Project Team: Who are the key members of the project team? What are their roles and job
descriptions? What are their phone numbers and email addresses? What is their original
department or organization? And to whom do they report to on a daily basis?

Section 4: How and When?

Provide broad information about how the project will be implemented. Outline how the project will
roll out by defining timelines, resources, and management stages. This is a high-level overview that
will, as the project proceeds, be supported by more detailed project planning documents.

Initial Project Plan

 Assignments: What major tasks (with milestones) will be completed during the project?
 Schedule: Provide a report of the estimated time involved for the project. You've probably
already prepared a high level Gantt chart or similar schedule, so the PID simply summarizes
the anticipated schedule.
 Human Resources: How many days activity will be needed to complete the project? How
many support staff will be needed? Will you need to bring more people onto the project
team?
 Project Control: How will progress be monitored and communicated?
 Quality Control: How will the quality of deliverables be evaluated and monitored?

Key Points

A Project Initiation Document is a guide to a project, clearly laying out the justification for a project,
what its objectives will be, and how the project will be organized. This helps ensure that everyone
knows what's going on right from the outset.

The amount of detail included should be sufficient for the reader to understand the basic purpose of
the project and to determine, in principle, the overall feasibility of the project objectives and plan.
The PID is supported by many detailed planning documents that may not be entirely completed by
the time that the PID is prepared.

51 | P a g e
Activity 5

Why should senior management be involved in setting project boundaries?

52 | P a g e
Activity 5

Project Requirements7

After all the deliverables are identified, the project manager needs to document all the requirements
of the project. Requirements describe the characteristics of the final deliverable, whether it is a
product or a service. They describe the required functionality that the final deliverable must have or
specific conditions the final deliverable must meet in order to satisfy the objectives of the project. A
requirement is an objective that must be met. The project’s requirements, defined in the scope plan,
describe what a project is supposed to accomplish and how the project is supposed to be created
and implemented. Requirements answer the following questions regarding the as-is and to-be states
of the business: who, what, where, when, how much, and how does a business process work?

Requirements may include attributes like dimensions, ease of use, color, specific ingredients, and so
on. If we go back to the example of the company producing holiday eggnog, one of the major
deliverables is the cartons that hold the eggnog. The requirements for that deliverable may include
carton design, photographs that will appear on the carton, color choices, etc.

Requirements specify what the final project deliverable should look like and what it should do.
Requirements must be measurable, testable, related to identified business needs or opportunities,
and defined to a level of detail sufficient for system design. They can be divided into six basic
categories: functional, non-functional, technical, business, user, and regulatory requirements.

Functional Requirements

Functional requirements describe the characteristics of the final deliverable in ordinary non-
technical language. They should be understandable to the customers, and the customers should play
a direct role in their development. Functional requirements are what you want the deliverable to do.

Vehicle Example

If you were buying vehicles for a business, your functional requirement might be: “The vehicles
should be able to take up to a one ton load from a warehouse to a shop.”

7
Source: BC Open Textbooks, as at https://opentextbc.ca/projectmanagement/chapter/chapter-9-scope-
planning-project-management/, as on 5th August, 2016.

53 | P a g e
Computer System Example

For a computer system you may define what the system is to do: “The system should store all details
of a customer’s order.”

The important point to note is that what is wanted is specified and not how it will be delivered.

Non-Functional Requirements

Non-functional requirements specify criteria that can be used to judge the final product or service
that your project delivers. They are restrictions or constraints to be placed on the deliverable and
how to build it. Their purpose is to restrict the number of solutions that will meet a set of
requirements. Using the vehicle example, the functional requirement is for a vehicle to take a load
from a warehouse to a shop. Without any constraints, the solutions being offered might result in
anything from a small to a large truck. Non-functional requirements can be split into two types:
performance and development.

To restrict the types of solutions, you might include these performance constraints:

 The purchased trucks should be American-made trucks due to government incentives.


 The load area must be covered.
 The load area must have a height of at least 10 feet.

Similarly, for the computer system example, you might specify values for the generic types of
performance constraints:

 The response time for information is displayed on the screen for the user.
 The number of hours a system should be available.
 The number of records a system should be able to hold.
 The capacity for growth of the system should be built in.
 The length of time a record should be held for auditing purposes.

For the customer records example, the constraints might be:

 The system should be available from 9 a.m. to 5 p.m.Monday to Friday.


 The system should be able to hold 100,000 customer records initially.
 The system should be able to add 10,000 records a year for 10 years.
 A record should be fully available on the system for at least seven years.

One important point with these examples is that they restrict the number of solution options that
are offered to you by the developer. In addition to the performance constraints, you may include
some development constraints.

There are three general types of non-functional development constraints:

 Time: When a deliverable should be delivered


 Resource: How much money is available to develop the deliverable
 Quality: Any standards that are used to develop the deliverable, development methods, etc.

54 | P a g e
Technical Requirements

Technical requirements emerge from the functional requirements to answer the questions: how will
the problem be solved this time and will it be solved technologically and/or procedurally? They
specify how the system needs to be designed and implemented to provide required functionality
and fulfill required operational characteristics.

For example, in a software project, the functional requirements may stipulate that a database
system will be developed to allow access to financial data through a remote terminal. The
corresponding technical requirements would spell out the required data elements, the language in
which the database management system will be written (due to existing knowledge in-house), the
hardware on which the system will run (due to existing infrastructure), telecommunication protocols
that should be used, and so forth.

Business Requirements

Business requirements are the needs of the sponsoring organization, always from a management
perspective. Business requirements are statements of the business rationale for the project. They
are usually expressed in broad outcomes, satisfying the business needs, rather than specific
functions the system must perform. These requirements grow out of the vision for the product that,
in turn, is driven by mission (or business) goals and objectives.

User Requirements

User requirements describe what the users need to do with the system or product. The focus is on
the user experience with the system under all scenarios. These requirements are the input for the
next development phases: user-interface design and system test cases design.

Regulatory requirements

Regulatory requirements can be internal or external and are usually non-negotiable. They are the
restrictions, licenses, and laws applicable to a product or business that are imposed by the
government.

An Example of Requirements

Automated teller machines (ATMs) can be used to illustrate a wide range of requirements (Figure
9.1). What are some of the physical features of these machines, and what kinds of functions do they
perform for the bank’s customers? Why did banks put these systems in place? What are the high-
level business requirements?

55 | P a g e
Figure 9.1 Automated Teller Machine. ATM

The following represents one possible example of each type of requirement as they would be
applied to a bank’s external ATM.

 ATM functional requirement: The system will enable the user to select whether or not to
produce a hard-copy transaction receipt before completing a transaction.
 ATM non-functional requirement: All displays will be in white, 14-point Arial text on black
background.
 ATM technical requirement: The ATM system will connect seamlessly to the existing
customer’s database.
 ATM user requirement: The system will complete a standard withdrawal from a personal
account, from login to cash, in less than two minutes.
 ATM business requirement: By providing superior service to our retail customers,
Monumental Bank’s ATM network will allow us to increase associated service fee revenue by
10% annually on an ongoing basis.
 ATM regulatory requirement: All ATMs will connect to standard utility power sources within
their civic jurisdiction, and be supplied with an uninterrupted power source approved by the
company.

The effective specification of requirements is one of the most challenging undertakings project
managers face. Inadequately specified requirements will guarantee poor project results.

Documenting requirements is much more than just the process of writing down the requirements as
the user sees them; it should cover not only what decisions have been made, but why they have
been made, as well. Understanding the reasoning that was used to arrive at a decision is critical in
avoiding repetition. For example, the fact that a particular feature has been excluded, because it is
simply not feasible, needs to be recorded. If it is not, then the project risks wasted work and
repetition, when a stakeholder requests the feature be reinstated during development or testing.

Once the requirements are documented, have the stakeholders sign off on their requirements as a
confirmation of what they desire.

56 | P a g e
While the project manager is responsible for making certain the requirements are documented, it
does not mean that the project manager performs this task. The project manager enlists the help of
all the stakeholders (business analysts, requirement analysts, business process owners, customers
and other team members) to conduct the discussions, brain-storming, and interviews, and to
document and sign off the requirements. The project manager is responsible only for enabling the
process and facilitating it. If the project manager feels that the quality of the document is
questionable, his or her duty is to stop the development process.

The project manager reviews the requirements, incorporates them into the project documentation
library, and uses them as an input for the project plan.

Software Requirements Fundamentals

This section refers to requirements of “software” because it is concerned with problems to be


addressed by software. A software requirement is a property that must be exhibited by software
developed or adapted to solve a particular problem. The problem may be to automate part of a task
of someone who will use the software, to support the business processes of the organization that
has commissioned the software, to correct shortcomings of existing software, to control a device,
etc. The functioning of users, business processes, and devices is typically complex. Therefore, the
requirements on particular software are typically a complex combination of requirements from
different people at different levels of an organization and from the environment in which the
software will operate.

An essential property of all software requirements is that they be verifiable. It may be difficult or
costly to verify certain software requirements. For example, verification of the throughput
requirement on a call center may necessitate the development of simulation software. Both the
software requirements and software quality personnel must ensure that the requirements can be
verified within the available resource constraints.

Requirements have other attributes in addition to the behavioral properties that they express.
Common examples include a priority rating to enable trade-offs in the face of finite resources and a
status value to enable project progress to be monitored. Typically, software requirements are
uniquely identified so that they can be monitored over the entire software life cycle.

Measuring Requirements

As a practical matter, it is typically useful to have some concept of the volume of the requirements
for a particular software product. This number is useful in evaluating the size of a change in
requirements, in estimating the cost of a development or maintenance task, or simply in using it as
the denominator in other measurements (see Table 9.1).

57 | P a g e
Table 9.1: Table of Measuring Requirements.

Source: A Watt.

Establish measurable project benefits, outcomes and outputs8

When project objectives are set, the term "deliverables" is often used to specify those tangible
things produced by the project. Two key factors, however, are often overlooked.

Projects will produce two kinds of outputs. One kind are the tangible things the project intends to
produce. Some examples are a design for an improved process, a training program to develop or
refresh job skills, or specifications for a new product or service.

The other kinds of outputs are tangible plans, measurements, tracking processes and status reports
that pertain to planning, managing and closing the project itself.

All projects should address two kinds of anticipated outcomes: those planned payoffs measured in
real dollars, which the project intends to produce from the outputs, and those important but often
difficult-to-precisely-measure long-term results.

Examples of planned payoffs include:

 Market share increase from improved segmentation actions.


 Benefits from implementing or enhancing supply chain management.
 Benefits from achieving ISO 9001 certification.
 Benefits from quality or benchmarking initiatives.

Examples of the important but sometimes difficult-to-measure outcomes include:

 Improved public image of the organization.


 Increased customer satisfaction.

8
Source: Quality Progress, as at http://asq.org/quality-progress/2008/07/back-to-basics/back-to-basics-
outputs-versus-outcomes.html, as on 5th August, 2016.

58 | P a g e
 Improved acceptance of the organization by the communities in which the organization
operates.
 Positive change in the organization’s contribution to the health, safety and welfare of its
employees.

The primary factors that distinguish outputs and outcomes are time and measurability. Regarding
time, project outputs are considered complete on delivery and in accordance with agreed-on
specifications. Outcomes are documented through evaluative actions taken after some interval
following project completion.

Concerning measurability, outputs are typically tangible and more easily measured objectively.
Outcomes are often more difficult, but not impossible, to measure, and are typically measured
subjectively by approximation.

At times, project team members might confuse the two types of outputs. It is important to
differentiate the tools and documents of project planning and management from the products or
services derived from the work of the project team.

It is also vital that both types of outputs have defined metrics and tracking mechanisms to ensure
progress toward achieving the deliverables proceeds according to plan. If the progress deviates from
the plan, corrective actions need to be taken to bring the project back to its planned path.
Additionally, attempts should be made to measure a project’s outcomes in terms of real dollar
payoffs.

An organizational perspective

Taking the discussion to the macro level, strategic goals and objectives are achieved through
processes—inputs and transformation—and outputs.

These processes are affected by internal and external situational demands, such as customer
demands, capacity and regulations. Aligned with the processes are the human behaviors of
employees, which in an organizational setting are influenced by work climate, the predominant style
of managing and, above all, organizational culture.

Effective measurement and communication combined represent the channels that enable the
organization to ultimately achieve measurable outcomes. The transformation processes, coupled
with human performance—including expertise and experience—constitute the core competencies of
the organization. These concepts are deployed throughout the organization to enable achievement
of the strategic goals and objectives.

In moving from a functional orientation to a process orientation, the organization focuses on


achieving the strategic goals and objectives, as demonstrated through measurable outcomes.

Worthwhile outputs are still important when placed within the context of the previous statement,
assuming they ultimately will result in a positive outcome. After all, an organization can produce a
high-quality product or service output but still fail to produce a positive outcome—high quality
buggy whips and no customer demand.

59 | P a g e
Output, Outcome and Benefit - Managing today to shape the future9

One of the most interesting and fascinating themes in Prince2 project management approach is, for
what I am concerned, the business case one.
I find extremely interesting the constant focus on the project's business case and the continued
assessment of the project justification, viability, and sustainability.
Also, I have been so impressed by the distinction between Output, Outcome, and Benefit.

Figure 1.

Output Each specialist product that the project has to deliver, be it tangible or intangible. Outputs
are commonly delivered after the project’s closure and sometimes even during the project’s life.
Outcome Results of the changes derived from the use of the project's specialist outputs by the users.
Outcomes typically start to be achieved after the handover of the project's specialist products to
users.
Benefit Measurable improvement resulting from an Outcome. If the outcome is perceived as a
disadvantage, we are dealing with what is called a dis-benefit. Benefits generally start to be achieved
after the Outcomes and (should) continue to be achieved for a time span planned in advance.
Prince2 states the establishment of a specific plan that describes the methods and times to verify
the achievement of the expected benefits.

In Figure 2 we can see a quantitative representation of the relationship between these three ideas.
Obviously, the exact Outcomes/Benefits realization times heavily depend on the project’s
characteristics and peculiarity.

9
Source: PM Crumbs, as at

60 | P a g e
Figure 2.

Let’s make a simple example to better clarify this view.


The Buymybooks Limited is a small company that sells books via the internet. Orders are collected by
means of their internet site but after the initial collecting phase, orders are printed and processed
manually. Also, Buymybooks Limited does not have a software to manage its books warehouse.
Their sell and delivery processes are highly inefficient, resulting in delivery errors, high costs, high
customers turnover, and progressive reduction in the market share.
To face this situation, the board of director has decided to introduce a management software system
to manage the sale and delivery processes.

Output of the project will be an integrated software management system (orders and warehouse
management).
Outcome of the project will be an improvement of Buymybooks Limited sell and delivery processes
efficiency.
Benefits of the project will be delivery errors reduction, smaller costs, higher profits and greater
customers' fidelity.

So we can agree that there is need to pay a great deal of attention not only to the execution phase
of a project but also to the design, support and closure phases. Furthermore, it is of utmost
importance check the actual realization of benefits after the project closure. This action should be
performed by program or corporate management as prescribed in the project’s documentation.
As a consequence, I would advise to

1) Have a series of compatible and well-crafted benefits


This seems obvious, but it can be sometimes tricky. I have covered the topic in one old post. It has
been conceived for project objectives, but it is well suited for project benefits too.

61 | P a g e
2) Do not just focus on the outputs delivery
Sometimes, is easy to focus just on output delivery and lose contact with project’s outcomes and
benefits. It could happen if outputs are the only substantial point of contacts between the project
and the team members (that sometimes ignore the big picture), or between the project and the
external stakeholders.
Also, it is not uncommon to rely just on outputs delivery to measure project’s completion or success.

3) Choose the best possible approach to maximize benefits


Since a significant part of the project’s value will be realized after project’s closure, take care, during
project planning, in choosing the best possible project approach to maximize the expected benefits
and not just the outputs production.
In the same way, while drafting the business case, do not take into account just the specialist
products realization and delivery costs. Keep an eye also on handover, maintenance and operational
costs.
Manage and execute the project thinking also to the desired outcomes and benefits, trying to
increase the probability of success and to maximize their impact on business as usual.

4) Close a project if it has been proved to be no more justified, viable and sustainable
A project is a mean to reach an objective and not an objective in itself. Stop investing in a project if it
is not longer worth it, is not a failure. Honor to the project manager who conscientiously proposes
an early closure of its project, out of respect for the corporate vision.
Keep on throwing money out of the window. That surely is a failure.

To keep track of some of this aspects, I suggest the use of two very simple tools.

benefits/benefits matrix (Useful for points 1 and 4)


The first one is a matrix on which all project benefits are listed in columns and rows, sorted by
descending importance, from left to right and from top to bottom. Each benefit's importance is
recorded near the benefit's code. You can find an example of the benefits/benefits matrix in Figure
3.
At the intersection of each row and column of the matrix, there is a symbol that explains the
benefit's relationships.

62 | P a g e
Figure 3.

The “+” sign represents a high degree of correlation between two benefits' viability. This bond leads
to risky situations because there is a high probability to realize both the benefits (opportunity) or to
miss them both (threat).
The “-” sign accounts for a low consistency between two benefits. This bond leads to risky situations
because the realization of one of the two benefit could jeopardize the achievability of the other one.
In the example depicted in Figure 3, the achievability of benefits B2 and B3 is correlated. Benefits B1
and B4 are not consistent, but the real problem is that benefits B2 and B4 are not consistent too
and, as a consequence, also benefit B3 is jeopardized. So benefit B4 jeopardizes benefits B2 and B3,
that are the most significant benefits of our project.
Especially if one or both the benefits are assessed as paramount, strong “+” or “-” relationships have
to be dealt with the greatest attention by the project manager.
if too much “+” and/or “-” relationships appear in the benefits/benefits matrix, it could be wiser TO
conduct an additional analysis of the project's expected benefits and to reassess the project’s
riskiness.
If two benefits do not have specific relationships, the intersection between their columns and lines is
left empty. Obviously, the matrix is symmetric by construction and the slashes on the main diagonal
are inserted just for the sake of clarity.
Other symbols could be added to account for different relationships, even if I advise to keep things
as simple as possible.
Even in this very simple form, this tool could help in identifying dangerous (-) or risky situations (+),
and contribute to the definition of the project's objectives.

products/benefits matrix (Useful for points 2 and 3)


The second tool I want to present is a matrix on which all project products (outputs) are listed in
rows and all project benefits are listed in columns. Benefits are sorted by descending importance
from left to right. Each benefit’s importance is recorded near the benefit's code. You can find an
example of the products/benefits matrix in Figure 4.

63 | P a g e
Figure 4.

Each intersection between a row (product) and a column (benefit) contains project's outcome's
codes, and represents through which outcome a single product helps to achieve a benefit. The color
code states the degree of importance of the product to the expected benefit's realization (e.g., red
could mean high, orange average, and yellow low).
We can see, reading the matrix by columns, which product helps to achieve a benefit, and to which
degree each product is necessary to this end.
In this way, we can maintain a constant focus not only on project’s outputs but also on project’s
benefits, through project’s outcomes.
If we are forced to drop out a product, we can immediately see which benefits are at stake, their
importance for the project and how much they are at risk. It is a simple way to depict the effect of a
project scope modification on the project benefits.
In the same way, if we decide to sacrifice a benefit, we can immediately evaluate if there should also
be a project’s scope modification.

Delivering benefits is the primary reason why organisations undertake change. A benefit is a positive
and measurable impact of change. However, in some cases there may be unavoidable negative
impacts of change that are acceptable in the context of greater benefits. These are called
disbenefits.

Benefits can be tangible (e.g. money saved, jobs created) or intangible (e.g. corporate reputation,
capacity for change). They may, or may not, also be quantifiable in cash terms (e.g. reduced costs or
greater customer satisfaction).

The forecast benefits of a programme or project are the basis of its business case. The sponsor owns
the business case and is ultimately accountable for the realisation of the benefits.

64 | P a g e
In a cost/benefit analysis the costs are definitely tangible and quantifiable. The tangible and
quantifiable benefits will ideally outweigh the costs. It is dangerous to rely too much on intangible
and unquantifiable benefits to justify expenditure.

Benefits-driven change requires proactive management throughout the entire life cycle. An
organisation identifies the benefits it needs and initiates changes that are forecast to deliver
benefits. During the change, the organisation needs to monitor performance indicators that can
reliably predict benefits delivery.

Day-to-day responsibility for the implementation of change and realisation of benefits lies with one
or more business change managers. The relationship between the project or programme manager
and the business change manager is crucial. The delivery of outputs and the management of change
must be closely coordinated.

Benefits management is an iterative process with five main steps as illustrated in figure 3.7.

Figure 3.7: Benefits management process

Define benefits management plan: This explains how benefits will be managed. It sets out policies
for aspects such as measurement, roles and responsibilities, priorities and key performance
indicators (KPIs).

Identify and structure benefits: Requirements are captured from sources such as the project
mandate and stakeholders. Benefits depend on the delivery of outputs and the achievement of
outcomes. The interrelationships between these need to be understood through benefits modelling
and mapping. Each benefit (and disbenefit) should be documented in terms of priority,
interdependencies, value, timescales and ownership.

Plan benefits realisation: This step involves capturing baseline measurements and agreeing targets.
Baseline measurements identify the current performance of an operation so that improvements can
be measured. The benefits plan illustrates the timeline and milestones for realising benefits,
including any dependencies on project outputs or interactions between benefits.

Implement change: Benefits happen when something changes. This usually involves permanently
changing attitudes and behaviours as well as physical changes. While implementing change, new
opportunities for additional benefits should always be sought.

65 | P a g e
Realise benefits: Changes to the way people work need to be embedded to ensure that benefits
continue to be realised. A business change manager needs to track realisation and ensure that the
change is permanent. The bulk of the benefits may only be realised after a project or programme is
completed. Long-term actions and monitoring for continued realisation should be documented as
part of the handover to business-as-usual.

Project

In most cases the project ends with the delivery of an output. However, some projects will continue
through the extended project life cycle to deliver measurable benefits. A project needs to be clear
from the outset whether it is delivering outputs or benefits. This will govern how the project is
constituted and managed.

Where a project is only responsible for delivering outputs, it must interface with whoever is
responsible for delivering the benefits. This may be a programme, portfolio or business-as-usual
organisation.

Programme

The benefits associated with strategic organisational change are delivered through programmes of
multiple-aligned projects and change management activity. Such programmes can contain complex
interactions between the outputs of individual projects, outcomes and benefits.

The attribution of programme benefits to individual projects and double counting of benefits across
a programme can be difficult issues, particularly where investment approvals are impacted. These
should be approached in a pragmatic way and resolved through effective mapping and stakeholder
consultation. Where appropriate, the benefit should be attributed to a specific project based on the
principle of greatest contribution.

It is important to implement a consistent approach to benefits management across a programme,


particularly for consistency of measurement. Without a consistent approach, it is difficult to
aggregate benefits across multiple projects and assess their collective impact on business
performance across the organisation.

Portfolio

A portfolio will deliver a collection of strategically-aligned benefits. It will do this through its
component projects and programmes. Strategy mapping helps ensure that investment decisions,
and the scope of each project and programme, are driven by the contribution of benefits to
achieving the operational, organisational or business strategy.

A portfolio must have a consistent set of guidelines for benefits management practices for all
programmes and projects, including tracking, forecasting and reporting. This enables benefits to be
compared and aggregated across the portfolio. It also helps to minimise double counting and
facilitates an even-handed investment appraisal. This is essential for the categorise, prioritise and
balance phases of the portfolio life cycle.

66 | P a g e
A well-defined and flexible, portfolio-wide, policy for benefits management will greatly reduce the
work needed to develop governance policies at project and programme level.

At a portfolio level, it is possible to make use of data on the performance of benefits management
(e.g. optimism bias, which is the tendency to overestimate benefits and underestimate costs). This
can be used to improve benefits management practices by sharing and applying lessons learned.

Activity 6

What is the difference between a project benefit, output and outcome? Explain each.

67 | P a g e
Activity 6

"Benefits Management" is the process by which you ensure that your projects deliver what you
want. Done effectively, it helps ensure that your project's deliverables give value to the business,
and the appropriate return on investment10.

In the benefits management process, you answer questions like these:

 Why are we doing this?


 What business objective will this project help to meet?

10
Source: Mind Tools, as at https://www.mindtools.com/pages/article/newPPM_75.htm, as on 5th August,
2016.

68 | P a g e
 Have we defined all of the benefits we're expecting?
 Have we justified the time and expense of the project?
 How will we measure the benefits?
 Is the project still valid?
 Are the benefits still relevant?

Investing your time in benefits management helps you reduce the overall risk of the project. It forces
you to look at organizational issues that might hurt a project's success, and then deal with those
issues in the project plan. After all you begin by knowing what you want the end result to look like,
you'll likely improve your ability to predict and avoid many potential obstacles.

The Benefits Management Process

A benefit is the desired result of a project that was created to meet a particular operational need.
For example, a project designed to reduce the time it takes to process an order has benefits such as
improved customer service, increased sales, and reduced frustration for sales staff who have to deal
with customer complaints.

The whole point of benefits management is to make sure that your project provides clear benefits –
as opposed to simply making sure the project is completed within specific time and resource
limitations. So, while the success of project management is to deliver on time and on budget, the
success of benefits management takes it one step further – to ensure that the initiative delivers the
expected results.

Finding This Article Useful?

You can learn another 63 project management skills, like this, by joining the Mind Tools Club.

Here are the main phases of benefits management:

Phase One: Define and develop the benefits

During project initiation:

 Talk to all stakeholders to figure out which benefits and outcomes each expects – and why.
 Create a benefits statement.
o List the final benefits that you want, and make sure you've distinguished between
"must haves" and unaffordable "nice-to-haves".
o Identify how the benefits are aligned with the company's strategy, and the needs of
the business.
 Decide what must happen in connection with the project to maximize benefits.
o Identify the changes, or other projects, needed to support and achieve the outcome
of the main project, and make sure that these are in the plan. For example, do
workers need extra training? Do you need a new advertising campaign to tell the
market about your new feature? Or do you need to hire additional people, or buy
new equipment to take full advantage of the change?
 Extend the cost-benefit analysis to include the benefits you've identified.

69 | P a g e
 Remember to look for tangible and intangible benefits.

Phase Two: Develop the benefits plan

Again, during project initiation:

 Look at the overall project plan, and make sure that the appropriate supporting activities are
included, so that you can ensure that benefits are achieved on time. Use traditional project
management tools, like Gantt charts and PERT charts, to complete and track your benefits
schedule.
 Watch out for gaps in benefits, as well as additional benefits.
 Identify who is accountable for delivering these supporting activities.
 Establish metrics for each benefit, and determine when and how you'll determine that the
benefit has been delivered.
 Determine how the benefits will be reported. You can use milestone reports as well as a
benefits dashboard as reporting tools.
 Include a benefits management summary in the business case for the project.

Phase Three: Monitor the benefits during project implementation

As the project moves forward:

 Regularly monitor your progress towards delivering the expected benefits.


 Modify the benefits plan as needed when the overall project plan changes.
 Establish a communication system between yourself and the project manager (if this is a
different person). This helps ensure that you routinely discuss and consider the benefits.
 Provide support to the project team, and use the benefits statement to encourage their
work.
 Watch for "benefits creep" – make sure that people's expectations don't grow too much
during the project. When you start to expect too many benefits, this can weaken the
project's overall impact, and lead to disappointment when imagined benefits are not
delivered. If your benefits-required list keeps growing, it's often better to create separate
projects for each specific intention and focus. See more tips on scope control.

Phase Four: Complete the project, and review your benefits

Towards the end of the project:

 Identify the benefits that were achieved, and look for gaps and missed opportunities.
 Monitor your workers' ongoing needs to ensure that they continue to enjoy the benefits.
Consider setting up a system to communicate future needs. This is a way to collect ideas for
future projects.
 Record what went well and what needed improvement. This supports continuous learning
within your organization.

70 | P a g e
Key Points

Benefits are the reason any project is created and implemented.

Benefits management is all about ensuring that the hard work and investment that's gone into the
project gives the greatest possible business return. Projects tend to change over their lifecycles, and
even small shifts can produce different results. That's why it's important to focus on the project's
benefits, and not just its timely completion.

Benefits management forces you to stay focused on why you started the project in the first place.
And it doesn't stop after the project ends, like traditional project management – it continues until all
benefits are clearly achieved. You can use the same project planning framework as the rest of the
project to do this, but you'll need to build in benefit-specific milestones, as well as establishing
accountabilities clearly, and setting up appropriate communications systems. Done this way,
benefits management can be a smart addition to a comprehensive project management plan.

Activity 7

How and where would you document project benefits, outputs and outcomes?

71 | P a g e
Activity 7

72 | P a g e
Establish a shared understanding of desired project outcomes with relevant
stakeholders11

Creating project culture is an art

The project team will respond to a consistent message backed by the appropriate action, but the size
and complexity of the team requires patience – culture is built over time.

The project leader on a major project has a strong influence on the project direction, but they by no
means control it. It’s critically important that they work with the project partners to understand
their needs and drivers, bringing them on the journey to ensure a successful project outcome.

The first step is agreeing on and being clear about the sort of culture required for the successful
delivery of the project. What behaviours are needed from the team? What will a successful outcome
look like? Which is the most important factor – time, cost, quality, public profile or something else
entirely? How should the team be seen by stakeholders?

Capturing the vision for the project and the guiding principles for the team in a project charter can
be useful, but is not essential to achieving the objective. Generally each leader should choose an
appropriate approach which suits their style and conveys the message in a clear and consistent
manner.

Collaboration workshops are commonplace in industry with alliances, managing contractor and
EPCM contracting structures growing in popularity. They’re great in practice, but are often held too
early, before the relevant project phase starts in earnest. While an initial meeting to agree on the
desired project culture can be beneficial, we recommend holding the workshop about 6 - 9 months
into the phase, when the initial storming and norming periods have run their course and the project
partners are clearer on how they’d like to build a better team.

Communicate effectively

Email and project communication platforms such as Aconex have massively increased the efficiency
of project work over the last decade. However, nothing beats face to face interactions which are
critically important to communicate project principles effectively and provide and receive feedback,
particularly when the project team is spread across a number of locations. This level of engagement
also allows you to develop trust which is critical when dealing with complex and/or difficult issues.

The usual principles of good communication apply where written communication is needed – be
clear, succinct and only send it to those who actually need to read it. On a major project, the
consequences of sending out poorly worded or confusing communications can be significantly
greater, as is the potential for important information to be lost in the noise of misdirected comms.

11
Source: Coffey, as at http://www.coffey.com/en/ingenuity-coffey/improving-project-outcomes-through-
design-leadership/, as on 5th August, 2016.

73 | P a g e
Communicating and celebrating the team’s successes is really important, particularly during the
early phases of construction where the issues can be many and the milestones far away. It’s easy to
focus on what’s going wrong, but receiving communications about the project and team
achievements makes people feel appreciated and gives the stakeholders a real sense of progress –
which in turn helps in building a positive team culture.

A fantastic idea introduced by one of our team members on a recent project was the distribution of
‘Good News Friday’ – a two page summary of the week’s achievements. Great feedback was
received from a range of stakeholders, and it was also used to provide regular updates to senior
executives. A real sense of camaraderie resulted amongst the site team as they strived to get their
work mentioned in GNF.

Consistent decision-making

When delivering a major infrastructure project it’s impractical and inefficient for the project leader
to be directly involved in all aspects of the project. Good leaders rely heavily on their team to make
effective decisions and to keep them informed of developing risks and issues. It’s therefore
important that team members are mentored effectively, able to make good decisions, and are clear
about the principles that should be applied when they need to give direction.

Consistency is essential to building a project culture where effective decisions are the norm. Being
clear on the principals behind your decisions and explaining these to the team will ensure reliable
results, more often.

Work collaboratively to agree on and implement the right processes

Bringing together diverse experiences and backgrounds on a major infrastructure project presents a
fantastic opportunity to leverage new and different management ideas, and to work with some of
the best minds in industry to develop better processes to deliver successful outcomes.

It’s important that a project leader works closely with project partners to develop these processes.
Be clear on what the fundamental requirements are and where flexibility exists for improvement.
For example, most organisations have financial information that needs to be reported in a particular
format, and the process developed needs to deliver the required level of detail. Be prepared to listen
to new ideas and perhaps change the way things get done.

On another recent project, earned value management was introduced to integrate program, cost,
and technical performance measurements. Although this approach created significant benefits for
the client it was a new concept for the contractor – working together it took ten months before it
could be executed effectively. On the other hand, the contractor also introduced a cost management
system which significantly improved the efficiency of project processes and delivered more usable
information.

Engage with project partners at the executive level

Regular and open communication with the senior personnel of a project is clearly a necessity on
large projects. But it’s also important to understand that many of these people will have dual
responsibilities – to the project and to their own employers.

74 | P a g e
They’ll be engaged with the team on the day to day management of the project, but it’s their
executive staff that will make critical decisions on resourcing, commercial responses and dispute
resolution, and these decisions can potentially, and significantly, impact project outcomes.

Therefore it’s good practice to engage and develop appropriate relationships at the executive level
of the project partners. This initiative will ensure alignment of objectives, allow the identification of
common ground on commercial interests and facilitate the development of a shared understanding
of requirements and potential challenges on the project. This can reduce pressure on project
resources, and provide a strong basis where issues that do come up can be worked through more
effectively.

Activity 8

Describe one way to establish a shared understanding of desired project outcomes with a relevant
stakeholder. Provide specific examples.

75 | P a g e
Activity 8

76 | P a g e
Document scope management plan12
Each project's product and/or service is unique and requires its own careful balance of practices,
processes, tools and techniques, etc. to ensure the required work is completed as agreed upon by
key project stakeholders. The sum of these along with the product and/or service to be delivered by
the project is known as the project's scope. Getting key parties to agree upon what is the scope of
the project's work is known as project scope planning.

The practice of project scope planning is a key management practice for planning and delivering
projects successfully. Project scope includes high level features or capabilities that the business team
has committed to delivering to a customer as well as those they have not committed to delivering.
Project scope is often defined by executive sponsor, steering committee, project sponsor, and the
project's customer with input from other appropriate stakeholders.

Understanding and analyzing who project stakeholders are is an important early step in the scope
planning process. Project stakeholders are persons and/or organizations such as customers,
sponsors, the public, etc. that are actively involved in the project, whose interests may be affected
by the project, or who exert influence over the project and/or its deliverables.

What is a Scope Management Plan

 Documents the process to evaluate whether or not a request is within the contract’s scope
 Defines how approved requests are prioritized and scheduled
 Explains the roles and responsibilities for each participant in the scope management process

Benefits of a Scope Management Plan

When used properly, an SMP helps effectively manage the triple constraint elements
(time/schedule, budget, and quality) as well as other factors:

 Applicable to public (government) and private organizations and projects


 Helps prioritize and reduce ad hoc work requests, which can save time and money
 Allows for quantitative analysis to validate the need of an ad hoc request
 Facilitates productive communications with stakeholders and their team
 Serves as a tool to manage client expectations, work load balancing, and team morale

Applicable Contract Types

The SMP can be used on most contract types and has significant value if the project’s contract type is
firm fixed with broad scope and general requirements (which can lead to many ad hoc activities).

12
Source: Project Times, as at https://www.projecttimes.com/articles/benefits-of-a-scope-management-
plan.html, as on 5th August, 2016; CDC, as at
http://www2a.cdc.gov/cdcup/library/pmg/other/scp_description.htm, as on 5th August, 2016.

77 | P a g e
Key Areas of a Scope Management Plan

1. Defined roles and responsibilities


2. Developed process

The following table outlines general roles and responsibilities involved in the scope management
process.

*Note: The COR and CO roles and responsibilities may be combined based on an organization’s
structure and contracting policies.

Next, the process should be simple and easy to understand by all stakeholders. The figure below
provides a high-level graphical view of the scope management process. Although the client may
choose to terminate consideration of an ad hoc request at any point, boxes shown in yellow
represent key decision points. Each step in the process is described in the sections following the
diagram.

78 | P a g e
Step 1: Initiate Request

The process begins when a client formally or informally requests an ad hoc activity. Note that any
client may request ad hoc support. No work will be performed until the remaining steps in the
process are followed, including reaching agreement that the work is in scope and gaining the
COR/CO’s authorization to proceed.

Step 2: Document Details

To allow each request to be evaluated effectively, a standard set of key information is gathered and
documented in a standard scope analysis template. The expected outcome, task performance
expectations and a requested delivery date are among the information that will be gathered for each
request.

The template is still incomplete during this step. Several pieces of information need to be added in
step 3 and other information may change as the request proceeds through the scope management
process (e.g., the task’s priority).

Step 3: Evaluate

The PM adds the following information to the template:

 Initial assessment of whether the request falls within the contracted scope of work
 Number of resource(s) required to perform the work
 Level of effort (LOE) estimate of the required work in hours
 Initial determination of the scope request type

Once this information is added, the PM meets with the COR to discuss the request. If both parties
agree (a) the work is in scope and (b) it is sufficiently defined, the process continues to step 4.

If there is disagreement about whether the work is within the contracted scope that cannot be
quickly resolved, either the COR or the PM may request the CO be engaged to help resolve the issue.

79 | P a g e
If there is concern the work is not sufficiently defined to allow an effective outcome, the process will
return to step 2 to document additional details.

Step 3.1: Evaluate - Request Type Determination

The determination of the request type is critical to its overall assessment and management. The
request type serves as the reference point for the COR and PM to decide if the request is within the
scope of the current staffing capabilities or not. The following information identifies and defines
these request types:

 In scope - no impact to team resources’ activities


An in-scope request that can be supported by the current level of team resources and no
reprioritization of current activities is needed.
 In scope - impact to team resources’ activities
An in-scope request, but current activities being supported by existing team resources
require reprioritization to support it.
 In scope - requires additional team resources to meet the requirement
An in-scope request requiring additional team resources to support it. The client prepares a
statement of work and negotiates with the PM for a contract/project modification to meet
the requirement.
 Out of scope – no work will be performed
The CO, COR, and PM agree the work requested is outside of the scope of the contract and
will not be performed.

Step 4: Prioritize

The COR prioritizes all ad hoc activities. These priorities provide a foundation for estimating the
task’s delivery date.

Step 5: Estimate Delivery Date

The PM estimates the task’s delivery date based on factors including:

 Priority relative to other ad hoc tasks


 LOE estimated
 Skills required
 Current team members’ skill sets and availability to support ad hoc activities.

Once the delivery date is estimated, the PM and COR discuss it and, if necessary, the COR works with
the PM and the appropriate client staff to refine the task’s scope or change the priority to enable a
more aggressive target delivery date.

Step 6: Authorize Work

The COR provides authority to the PM to perform the requested ad hoc activity.

80 | P a g e
Step 7: Perform Work

The PM assigns the appropriate team member(s) to perform the work and designated formal and
informal progress reporting methods are used to keep the client apprised of the activity’s status.

Diligent scope planning works toward ensuring that key project stakeholders agree upon the project
work to be accomplished. Achieving this agreement is facilitated through a process of progressively
elaborating and documenting project work and communicating with project stakeholders. This
process forms the basis for an agreement between the project team and the customer by relating
the work of the project to the project's objectives and ensuring that the project includes all of the
work required, and only the work required to meet the agreed upon project objectives. At a
minimum the scope planning process should consider:

 Project justification – Defining the business need that the project was undertaken to
address. Such as, a customer request, market demand, etc.
 Product description – Documenting the relationship between the created product and/or
service and the business need the project was undertaken to address.
 Project objective – Outlining criteria the project needs to meet for it to be considered a
success. This includes measures of cost, quality, schedule, etc. to meet the business needs
behind why the project was chartered.

Four primary actions are conducted throughout the scope planning process:

 Scope Planning – Creating a project scope management plan that documents how the
project scope will be defined, verified, controlled, and how the work breakdown structure
(WBS) will be created and defined.
 Scope Definition – Developing a detailed project scope statement as the basis for future
project decisions.
 Scope Verification – Formalizing a plan for acceptance of the completed project deliverables.
 Scope Control – Establishing a mechanism for controlling changes to the project scope.

Scope Planning

The foundation for scope planning is a detailed project scope statement derived from the
preliminary scope statement documented within the project charter and business case documents.
Using a detailed scope statement as a foundation, the scope management planning process outlines
the processes that will govern how the project's scope will be defined, verified, and controlled. Some
of the activities conducted to accomplish this include:

 Conducting planning workshops


 Researching previous project experiences
 Developing strategies and plans
 Etc.

81 | P a g e
A scope management plan is the end result of the scope planning process and is used by the project
team to document scope management decisions. The scope management plan provides guidance to
stakeholders on how project scope will be managed and controlled throughout the life of the
project. The scope management plan is often created as part of the project management plan, but
may also be a separate subsidiary plan if necessary to meet the needs of the project.

Scope Definition

Defining project scope involves subdividing major project deliverables, as identified in the project
scope statement, into smaller, more manageable components. This effort results in the
development of the WBS and eventually the identification of resources and milestones that will
provide perspective on the project as a whole. The practice of scope definition accomplishes things
such as:

 Identifying major project work components, deliverables, and requirements


 More accurately estimating time, cost, and resource requirements
 Easier management of project components and performance measures
 Etc.

Scope Verification

A formal plan for verifying scope defines how project work will be confirmed and ultimately
accepted by the client. Scope verification activities include measuring, examining, and testing project
deliverables to ensure that they comply with agreed upon requirements. A plan for how this will be
accomplished needs to be documented and agreed upon by key stakeholders.

The ultimate objective of this process is a documented plan for formally accepting completed project
deliverables. The project team will need to comply with all agreed-upon acceptance procedures as
outlined within the scope management plan and ensure that all accepted deliverables have been
documented and signed-off on by the appropriate stakeholder(s).

Scope Control

Project scope sometimes needs to be adjusted to adapt to a dynamic project environment. Changes
may include fluctuations in resources, schedule, cost, client requirements, etc. Scope change itself is
not necessarily bad assuming that it is recognized early, addressed quickly, and that project
stakeholders are in agreement as to the impact of the change on project activities and objectives.
However, uncontrolled changes can become an issue quickly. Uncontrolled change is often referred
to as scope creep.

Establishing a mechanism for controlling project scope change is critical to project success. This
process is concerned with influencing the factors that create scope creep and controlling the impact
of those changes.

82 | P a g e
Planning and documenting within the scope management plan how changes to scope will be
controlled ensures that all requested changes and recommended corrective actions will be managed
through an agreed upon change control process. Scope change control involves activities such as:

 Influencing factors that create scope changes


 Identifying when scope change has occurred
 Helping to ensure that changes are beneficial to project objectives
 Managing the actual changes when and if they do occur
 Etc.

Activity 9

The project scope management plan, as a component of the project management plan, includes
which of the following?

(a) Preparation of a detailed project scope statement


(b) Creation of the work breakdown structure (WBS)
(c) Specifications for formal verification and acceptance of completed project deliverables
(d) All of the above
You are creating your WBS and find that you keep decomposing tasks into smaller and smaller
units. How can you tell when you are done?

(a) Keep decomposing tasks until you reach an amount of work that is small enough to reliably
estimate required resources and duration.
(b) Keep decomposing tasks until you reach an amount of work that can be accomplished in one
hour.
(c) Keep decomposing work until you reach an amount of work that can be accomplished in your
organization’s basic work unit.
(d) Keep decomposing work until you reach a predetermined number of hierarchy levels to keep the
WBS balanced.
Which of the following is a valid input to the collect requirements process?

(a) Project charter


(b) Requirements traceability matrix
(c) Validated deliverables
(d) Work performance information

83 | P a g e
Implement agreed scope management procedures and processes13

Collect Requirements and Define Scope processes

Collect Requirements and Defining the scope

In this article, I want to focus upon the collect requirements and scope management processes that
are carried out within the planning process group only.

The key document outputs which will be dealt with here are first:

From the collect requirements process:

 Requirements documentation
 Requirements management plan
 Requirements traceability matrix

And from the define scope process, the project scope statement.

Put at its simplest, a project scope defines precisely what is included and what is not included by
clarifying the boundaries. It is counter-intuitive in many ways, because often organizations try to
deliver more than was agreed upon, to exceed customer expectations.

This can be called ‘gold plating’, and can cause projects to overrun schedules, budgets and hence
increase risk. It is very easy in performing collect requirements that folks will ask for more than they
actually need.

To be in control of scope throughout the project requires close management of collect


requirements, the details etc, and the processes. Any scope changes must be handled in a
structured, linear, and controlled manner.

Each requirement is documented clearly along with its acceptance criteria as it is vital that the scope
is well defined and clearly communicated.

The key to the success of scope control is to ensure that if any change is requested, that it is first
evaluated, captured and documented and that no change should be implemented unless it is clear
that it is necessary, and that the right authority has first been given for its implementation. It is
important to compare this against the output from collect requirements.

From the planning process group perspective, the requirements for the product and project are first
gathered, then the deliverables forming part of the product and the project scope are defined and
documented, leading to the creation of the work breakdown structure (WBS). I shall cover the WBS
in a separate article.

13
Source: PM Primer, as at http://www.pm-primer.com/collect-requirements-and-define-scope-processes/, as
on 6th August, 2016.

84 | P a g e
I will now deal with each process in turn.

Collect requirements.

The detail contained within the requirements that lead to a clear understanding of what is needed to
satisfy the stakeholders so that their expectations can be managed. This key documentation is the
touchstone from which the schedule, budget, quality specifications, resource plans, and risks
emanate from.

The pre-requisites to the collect requirements process are the project charter and the stakeholder
register. The project charter provides an overview of the project’s product, service or result and this
is used to determine the requirements.

The stakeholder register lists all of the project stakeholders and it is important that the right
stakeholders are involved in helping to explain the requirements along with the underlying needs
from the earliest point in time of the project.

There are three documents that are created as a result of collect requirements and define scope
processes:

Collect requirements – Requirements documentation.

This lays out what needs to be performed and justifies why each requirement is important.

Information captured here should include:

 The source of the requirement and the core business problem that is being solved
 How each requirement addresses the problem
 Relevant measurements for each requirements
 How existing business processes interact with the requirements
 Constraints and assumptions
 Predicted impact of the requirements on others
 Business, legal, and ethical compliance

Collect requirements – Requirements management plan.

This is in effect, a strategy for how the requirements will be managed, and covers the team activities
to both gather and then manage the project requirements. This document forms part of the project
management plan, and covers how requirements will be obtained and decisions made, how the
requirements will be documented, and how requirements changes will be managed.

Requirements traceability matrix.

Part of the requirements documentation includes the source of each requirement, and identifying
the source is what this document does. Here the sources will be named, whether an individual,
group or organisation. The source origin could be a legal requirement, or clauses within a contract.
Additional information may include who owns the requirement for example.

85 | P a g e
There are eight tools that may be used to assist in the collect requirements process:

1. Interviews. Subject matter experts should be used here as they are more able to articulate what
the product should consist of and why this is important. The project manager or a business analyst
may conduct such interviews.

2. Facilitated workshops. These are a highly efficient way to capture and define the requirements,
but the use of an experienced facilitator is key, along with inviting all appropriate stakeholders of
course.

3. Group decision-making techniques. There are many techniques available to assist bringing the
stakeholders to a decision. These include unanimity, majority, consensus, plurality, and dictatorship.

4. Focus groups. As the name suggests these are carried out by a member of the project team
meeting with a group of stakeholders to determine their requirements, needs and expectations for
the project and its outcome.

5. Group creativity techniques. Generating a creative environment where people can openly discuss
their ideas is a powerful and creative way to ensure the requirements are fully captured. Techniques
can include; brainstorming, nominal group technique using votes and priorities, diagramming
techniques such as mind mapping, and where a participant’s real unbiased opinion is needed, the
Delphi technique.

6. Questionnaires and surveys. Using a standard questionnaire or survey allows requirements to be


gathered quickly among large groups of people and because of the standard format, analysis is also
quicker.

7. Observation. Put simply, an observer watches as a worker performance their job and note how
the worker performance this last capturing less obvious requirements that would be missed by other
methods.

8. Prototypes. A prototype’s use and style will depend upon the end product of the project and any
methodologies being used for its creation. One or more part-functioning prototypes can be a
powerful visualisation aid when attempting to understand requirements.

The define scope process.

Here, the project requirements (from collect requirements), are more thoroughly understood and
documented, and may be carried out in a simple informal manner or a complex formal and detailed
manner. If this were a construction project for example, then the define scope process will need to
be done in detail as errors here can have huge cost, resource and schedule implications.

Because projects are progressively elaborated, the collect requirements and define scope processes
will often be performed numerous times throughout the project.

The main input is the project charter itself, as it will detail the goals and objectives of the project, a
description of the scope, and any constraints and assumptions.

86 | P a g e
The requirements documentation is also an input as the define scope process translates these
requirements into more detail.

A final input is the organisational process assets. These can take many forms, including project plans
from previous similar projects, templates, policies procedures or guidelines, etc.

There are two main outputs from the scope management process, the project scope statement,
and project document updates.

The project scope statement provides the baseline agreement among all of the stakeholders of the
project and its deliverables. The project scope statement includes the objectives of the project, the
product description and requirements for the project, the constraints and assumptions, and the risks
are have been identified relating to the project scope. This document should also include the
acceptance criteria for the end product.

Project document updates. Obviously this relates to any documents that may need to be updated as
a result of defining the project scope, and typically includes the requirements documentation and
the requirements traceability matrix, and the stakeholder register. Estimating data, issues and risk
data may also need to be updated.

Tools that are used in the define scope process are:

Expert judgement. This is the use of technical experts helping to develop relevant parts of the
project scope statement.

Product analysis. This involves detailed analysis of the project product service or a result and the
output here is a better understanding of the requirements. Many tools are available to carry out
products analysis and these may include; requirements analysis, value engineering, product
breakdown, and systems analysis.

Facilitated workshops. This is described in the collect requirements process, and is here used to
further refine knowledge of the to the project scope.

Alternatives identification. Brainstorming is it method here with the aim of helping the team to
understand and consider all options relating to the project scope.

The TenStep Project Management Process recommends three main deliverables be created before
the actual work on the project begins. These are the Project Definition, project workplan, and the
Project Management Procedures. The Project Management Procedures describe how the project will
be managed, and are an effective way to communicate the processes to the project team,
customers, and stakeholders.
Although they may seem time consuming to develop, in most cases these procedures only need to
be created once. When you have a set of procedures that allow you to be successful, you can reuse
them on subsequent projects. In fact, these procedures can be written at the company or
organization level, and then used as the starting point for all projects in the company.

87 | P a g e
These procedures come from the TenStep process for large projects. They should be customized as
appropriate for your project, your team, and your organization. In most cases, the processes should
be simplified for smaller projects. Although this template is called Project Management Procedures,
this document really describes processes. Processes are at a higher level than procedures. You can
turn them into procedures by specifying the particular roles, people, and dates that make sense. For
instance, take the step “The project manager will review the Scope Change Log on a weekly basis.”
This can be made more specific by stating “The project manager, Sam Jones, will review the Scope
Change Log by Tuesday noon of each week.”

Workplan Review and Update Procedure


1. Review the workplan on a regular basis. For a medium project, this is probably still a weekly
process. For larger projects, the frequency might be every two weeks. Do not go any less
frequently than every two weeks.
2. Capture and update actual hours. If the project is capturing actual effort hours and costs,
update the workplan with this information. Identify activities that have been completed during
the previous time period and update the workplan to show they are finished.
3. Review your schedule situation. Determine whether there are any other activities that should
be completed, but are not. This information can be gathered by running the appropriate report
from the project management tool. If there are activities that are late, work with the
individual(s) who are assigned to see what is going on.
4. Reschedule the project. After the workplan has been updated to show the current reality, let
the tool reschedule the work to see if the project will be completed within the original effort,
cost, and duration.
5. Run additional workplan management reports. Run additional reports from the project
management tool to help determine how the project is progressing. For instance, look at
resource allocation.
6. Review your budget situation. Review how your project is performing against your budget.
Because of how financial reporting is done, you may need to manage the budget on a monthly
basis, even if you update the workplan on a weekly or biweekly basis
7. Look for other signs that the project may be in trouble. These could include
 Activities start to trend over budget or behind schedule early on in the project.
There is a tendency to think you can make it up, but usually these are a warning that
you will get further and further into trouble.
 A small variance starts to get bigger, especially early in the project.
 You discover that activities you think have already been completed are still being
worked on.
 You need to rely on unscheduled overtime to hit the deadlines, especially early in
the project.
 Team morale starts to decline.
 Deliverable quality or service quality starts to deteriorate.

88 | P a g e
 Quality control steps, testing activities, and project management time starts to be
cut back from the original schedule.
8. Evaluate the critical path of the project.
9. Adjust the workplan. Update the workplan so that it reflects how the remaining work will be
completed.
10. Communicate any schedule and budget risk. As soon as you feel at risk of missing your budget
or deadline, you should communicate this to the sponsor and stakeholders.
11. Add more details to future work. On a monthly basis, adjust future work to reflect any
additional information you know now. For instance, when the workplan was created, many of
the activities further into the future may have been vague and placed in the workplan at a high
level. On a monthly basis, this work needs to be defined in greater detail.

Issues Management Procedure


1. Solicit potential issues from any project stakeholders, including the project team, clients,
sponsors, etc. The issue can be surfaced through verbal or written means, but it must be
formally documented using an Issue Submission Form.
2. Enter the issue into the Issues Log.
3. Assign the issue to a project team member for investigation. (The project manager could assign
it to themselves.) The team member will investigate options that are available to resolve the
issue. For each option, they should also estimate the impact to the project in terms of budget,
schedule, and scope.
4. The various alternatives and impact on schedule and budget are documented on the Issue
Submission Form. Take the issue, alternatives, and project impact on the Issue Submission Form
to the Project Sponsor and other appropriate stakeholders for a resolution.
5. If resolving the issue will involve changing the scope of the project, close the issue now and use
the scope change management procedures instead to manage the resolution.
6. Document the resolution or course of action on the Issue Submission Form.
7. Document the issue resolution briefly on the Issues Log.
8. Make the appropriate adjustments to the work plan and project budget, if necessary.
9. If the resolution of an issue causes the budget, effort, or duration of the project to change, the
current Project Definition should be updated.
10. Communicate issue status and resolutions to project team members and other appropriate
stakeholders through the 6. Manage Communication step, including the Project Status Report.

Scope Management Procedure


1. Solicit potential scope change requests from any project stakeholders, including the project
team, clients, sponsors, etc. The issue can be surfaced through verbal or written means, but it
will be formally documented using a Scope Change Request Form.
2. Enter the request into the Scope Change Log.

89 | P a g e
3. Assign the scope change to a project team member for investigation. The team member will
investigate the impact on budget and schedule for various viable options. The team member will
first determine how much time it will take to investigate the scope change request. If the time
required to perform the analysis will cause deliverable dates to slip, the request must be taken
to the Project Sponsor to determine whether the request should be investigated or not. If the
sponsor gives the initial approval to proceed, the workplan and budget may need to be updated
to reflect this new work. The options are documented on the Scope Change Request Form. If the
Sponsor does not agree to investigate the change request, then the request should be placed
closed as “not approved” on the Scope Change Log.
4. (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. The purpose is to keep from surfacing
many small changes to the sponsor for approval.
5. Take the scope change request, alternatives, and project impact on the Scope Change Request
Form to the project sponsor for a resolution.
6. Document the resolution or course of action on the Scope Change Request Form.
7. Document the resolution briefly on the Scope Change Log. If the sponsor does not agree to the
change request, then the request should be closed as “not approved” on the Scope Change Log.
8. If the resolution is agreed upon, the appropriate activities are added to the workplan to ensure
the change is implemented. The project budget should also be updated, if necessary. If the
resolution is not approved, note it as closed on the Scope Change Log.
9. If an approved scope change results in a substantial change to the project, the original Project
Definition should be updated.
10. Communicate scope change status and resolution to project team members and other
appropriate stakeholders through the 6. Manage Communication step, including the Project
Status Report.

Risk Management Procedures


1. When you are defining the project, perform a complete assessment of project risk. The project
manager can take an initial draft based on what they know and circulate it for
additions/changes/comments. Another technique is to gather all the key stakeholders and
discuss potential risks during a facilitated meeting. Also see the Risk Assessment Checklist
template.
2. Assign a risk level to each risk identified. The risk level should be high, medium, or low,
depending on the severity of impact and the probability of the event occurring. Use the
following table as a starting point. For instance, a highly likely/high impact event is obviously a
high risk. However, each event must also be evaluated individually. If you have an event that is
not likely to occur, but the impact, if it occurred, would be devastating (e.g., someone could get
killed), you would still want to consider it a high risk and put together a risk plan accordingly.
Severity of Risk Impact/Probability of Risk Occurring Overall Risk
Level
High negative impact to project/Highly likely to occur High
High negative impact to project/Medium likely to occur High

90 | P a g e
High negative impact to project/Not likely to occur Medium/Low
Medium negative impact to project/Highly likely to occur Medium
Medium negative impact to project/Medium likely to occur Medium/Low
Medium negative impact to project/Not likely to occur Low
Low negative impact to project/Highly likely to occur Low
Low negative impact to project/Medium likely to occur Low
Low negative impact to project/Not likely to occur Low

3. Create a response plan for each high-level risk that you identified to ensure the risk is managed
successfully. This plan should include steps to manage the risk, people assigned, completion
dates, and periodic dates to monitor progress. There are five major responses to a risk—leave it,
monitor it, avoid it, move it to a third party, or mitigate it.
4. Evaluate the medium-level risks to determine if the impact is severe enough that they should
have a risk response plan created for them as well.
5. Look at any low-risk items and see whether they should be listed as assumptions. In this way,
you recognize that there is a potential for problems, but because the risk is low, you are
“assuming” that the condition will not occur.
6. (Large projects) For every high and medium risk where the project manager is creating a risk
mitigation plan, you should also create a contingency plan to document the consequences to the
project if the risk plan fails and the risk actually occurs.
7. Move the activities associated with the risk plans to the project workplan. Moving the activities
to the workplan should help ensure that the work is actually completed and keeps the workplan
the primary focus of all work planning and monitoring.
8. The project manager needs to monitor the risk plans to ensure they are being executed
successfully. New risk plan activities should be added if it looks like the risk is not being managed
successfully.
9. The project manager also needs to periodically evaluate risks throughout the project based on
current circumstances. New risks may arise as the project is unfolding and some risks that were
not identified during the 1. Define the Work step may become visible at a later date. This
ongoing risk evaluation should be performed on a regular basis, say monthly, or at the
completion of major milestones.

Communication Management
Larger projects should have a Communication Plan that guides the overall communication process.
The Communication Plan can be included here as part of the Project Management Procedures.

Document Management
Large projects should have document management procedures that describe how documents are
created, stored, and shared. This is a part of the knowledge management process. So much of
document management is dependent on site-specific tools and the particular project environment
that a general set of guidelines is not possible.

91 | P a g e
However, refer to the TenStep Manage Documents step for an understanding of what should be
taken into account for the smooth handling of documents on a project.

Quality Management
Larger projects should have a Quality Plan that guides the overall quality management process. The
Quality Plan can be included here as part of the Project Management Procedures document, or it
can be created as a separate document.

Activity 10

Develop a procedure for communicating project progress to relevant stakeholders.

92 | P a g e
Activity 10

93 | P a g e
Manage impact of scope changes within established time, cost and quality
constraints according to change control procedures14

Scope is defined at a high level by describing the boundaries and deliverables of your project. You
add more detail to that definition through the gathering of your business requirements. Once these
items are agreed to by your sponsor, you can manage overall scope change through a simple scope
change process. Remember that having your scope and business requirements approved doesn't
mean nothing can change from that point on. It means instead that you will manage the overall
change process from that point forward using a good scope change management process.

Here's a simple scope change process that you can use on your project.

1. Solicit potential scope change requests from any project stakeholder, including the project
team, clients, sponsors, etc.
2. Smaller projects can document the scope change in a short form or an e-mail. For larger
projects, the scope change request should be formally documented using a Scope Change
Request Form. The important thing is that you need to document the scope change in
writing. Don't act on scope change requests you receive verbally.
3. Enter the request into the Scope Change Log for tracking purposes.
4. 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.
5. The project manager will assign the scope change request to a team member for further
investigation. (The project manager could assign it to himself.) The team member will first
determine how much time it will take to investigate the scope change request. If the time
required to perform the analysis will cause deliverable dates to slip, the request must first be
taken to the sponsor to determine whether the request should be investigated or not. If the
sponsor gives the initial approval to proceed, the workplan and budget may need to be
updated to reflect this new work. If the sponsor does not agree to investigate the change
request, then the request should be placed closed as "not approved" on the Scope Change
Log.
6. Take the scope change request, alternatives, business value and project impact to the
sponsor for a resolution (yes we do it or no, we don't do it).
7. Document the resolution or course of action.
8. Document the resolution briefly on the Scope Change Log. If the Sponsor does not agree to
the change request, then the request should be closed as 'not approved' on the Scope
Change Log.
9. If the scope change request is approved, the appropriate activities are added to the
workplan to ensure the change is implemented. The project budget should also be updated,
if necessary.
10. The current Project Definition (Charter) should be updated if an approved scope change
results in a substantial change to the project.

14
Source: Tech Republic, as at http://www.techrepublic.com/article/follow-this-simple-scope-change-
management-process/, as on 6th August, 2016; EPM Book, as at http://www.epmbook.com/scope.htm, as on
6th August, 2016.

94 | P a g e
Throughout the process, make sure that you communicate all scope change status and resolution to
project team members and other appropriate stakeholders. This is usually done by attaching your
current Scope Change Log to your Status Report. This helps manage expectations and shows how
approved scope change requests are impacting the project end date and budget.

Scope Change Control

Why is there a distinction between scope change and other changes? In general, Project Managers
should pay a great deal of attention to managing scope. Allowing the project's scope to change mid-
course usually means added costs, greater risks and longer duration. Many projects fail due to poor
scope management. Very often it is a large number of small scope changes that do the damage,
rather than the big, obvious ones. The successful Project Manager has learned that rigorous scope
control is essential to deliver projects on time and on budget.

The world-class Project Manager would not express this imperative in the same terms. The prime
focus for the Project Manager should not be to deliver the agreed scope on time and on budget, but
to optimise the benefit that is generated by the project. If that means allowing the scope to change
then that scope change is a good thing, not a bad thing. It is wrong to resist all scope change. Where
a scope change generates improved benefit, it should be proposed to the project's decision making
body. Make clear the positive and negative impacts of allowing the change. Make sure the impact is
fully reflected in the project's definition and performance criteria.

Watch out for the use of "scope change" as a defensive behaviour. In many cases, people will discuss
scope changes in the context that a scope change is not the project's fault and must therefore be the
business's fault. This is particularly important if the work is being performed by a different
organisation under contract.

Watch out for the use of "scope change" as an aggressive behaviour. Sub-contractors may
intentionally try to expand the size of their contract by establishing scope changes that lead them to
do additional work outside the original agreement. Some contractor’s under-bid the cost of the work
to gain the contract, in the belief that they will be able to make their profit out of scope changes.

Change Control vs Issue Management

There are many similarities and much overlap between Issue Management and Change Control. A
large percentage of "issues" will directly or indirectly being asking for something to change.
Conversely, most changes reflect and generate issues.

Some Project Management approaches combine these into a single process, which can scare people
away from communicating issues. Some others treat them as separate processes, which can cause
practical difficulties, inefficiency and misunderstandings. Clearly there needs to be some linkage. The
best scenario is to present Issues Management as separate but related processes whereby an issue
can evolve into a change request where appropriate.

95 | P a g e
Basis of decision

The decision whether to accept or reject a change would be based on a number of rules. The
fundamental logic should be:

Is the change unavoidable (eg legislative changes, mergers, etc)?

or

Does the change increase the overall benefit to the organisation (taking into account any impact on
the costs, benefits, timescales and risks)?

and

Is the Project Team able to make such a change?

and

Is the change best done now, or would it be more beneficial to defer it until the current work is
complete?

Scope Management at Project Start

Scope should be clearly defined as part of the Project Definition. Much of the work at that time is
directed at agreeing the optimum definition of the project - both in terms of its deliverables and in
terms of how it will operate. This scope definition will form the baseline against which potential
changes are assessed and against which the project's performance is measured.

In defining how the project will operate, the Project Manager should try to influence those factors
that could lead to subsequent scope change. The importance of a sound Project Definition should be
emphasised. Make clear the dangers and potential costs of subsequent changes of direction, but,
equally, encourage the leadership to allow change where that would be beneficial. In the dynamic
world of eBusiness, rapid change is the norm.

All participants should understand that the later in the project that a change is addressed, the
greater the likely impact in terms of costs, risks, and timescale. It is wise to surface potential changes
as early as possible. The change control process should make it easy to do so.

96 | P a g e
An efficient Scope and Change Control process should be defined. There needs to be a balance
between flexibility and control. If the process is too onerous, either valuable changes will be lost or
the participants will ignore the rules - leading to uncontrolled scope and configuration. If the process
is too easy, then many changes may be applied with insufficient thought given to their merits and
consequences.

It is common to define various responsibilities and authority levels so that routine changes can be
dealt with efficiently but significant changes receive due management attention. Where a proposed
change affects the scope of the project it should be seen as a business decision requiring approval
from the business owners of the project (eg Project Sponsor, senior leadership, Steering
Committee). Where scope is not affected, it may be agreed that the Project Manager has the power
to approve the change within certain authority limits. In some projects, Change Control Boards are
defined and convened to consider and approve change requests on a regular basis, say every two to
four weeks. Different panels might be appropriate for handling different types of change request.
For example, a technical panel might look at technology issues, departmental leaders might look at
the business processes, and the HR managers might examine organisational issues. Above a certain
level of impact, the request would normally be referred to the overall Steering Committee.

97 | P a g e
The basis of decision for Change Requests should be agreed as part of the Project Definition work. It
should define how the Project Manager is allowed to exercise the power to approve minor changes,
and should provide guidance for the decisions of the Change Control Board(s) and Steering
Committee.

Particular considerations occur where the change impacts the relationship with an external sub-
contractor. Each time the work content increases the contractor might reasonably demand further
time, resources and fees. If the change is due to the contractor's own fault, then, arguably, there
should be no allowance made.

Case Study
A European public sector organisation had sub-contracted the development of a major new system
to a software house. Progress was slow and both sides were raising many concerns. We were asked
to investigate various problems that had been building up.

One area of concern was raised by the sub-contracting software house:

Changes - we have been inundated with changes. We've had to make thousands of changes to the
design and it's almost impossible to get the client organisation to recognise them or to allow for
them in the planning and performance criteria.

The client organisation had a different view:

Changes - yes, there's been one change so far; and we're working on a second. It's not really a
problem at all.

To the client organisation, a change meant, in effect, a formal re-negotiation of the contract - subject
to the same extensive procedures as the original procurement contract. It would take months to
approve a change request. To the software house, a change meant every instance where they were
forced to change any completed element of the work due to some unavoidable problem with the
original specifications. Given the enormous weight of the formal change approval process, it would
be unrealistic to wait for formal approval except in the largest cases. What is worse, they probably
would not get paid for those thousands of minor but essential changes.

Although it is not required for the Project Definition, this is a good time to establish the mechanism
that will be used, particularly if it involves a system that needs to be selected, acquired and
implemented. The Change Control system would normally be part of the same overall set of
procedures and tools that will be used to support the other project management activities. A
number of commercial software tools are available. It would also be straightforward to set up your
own local system using client server or web technology. In relatively simple projects, the needs could
be met by standard tools such as EMail and spreadsheets.

98 | P a g e
Starting up the Change Control Process

The Change Control process will involve a combination of procedures, responsibilities and systems.
The key to success is to have a well-controlled but efficient process. Define and agree:

 on what basis changes should be approved,


 who does what,
 the membership of the Change Control Board(s),
 the detailed procedures, forms, etc,
 protocols for levels of authority, eg what types of change can be approved without reference
to the project's business owners,
 linkage to other management procedures, eg the issue management process, configuration
management,
 which tools will be used to support and manage the process,
 how to communicate and promote the process and its importance to all participants.

Here is an example process for dealing with issues:

Example Scope and Change Control Process

Any participant or other concerned party may raise Change Requests. The Project Office team and
Project Manager will ensure they are captured and proactively manage them to conclusion.

99 | P a g e
An initial review should be made to examine the need for the change, how it could be achieved and
what the consequences would be. The most appropriate member of the Project Team would
normally perform this review. Based on those conclusions, the recommended action would be
proposed.

In this example, there are three possible courses for the approval of the change:

 Minor changes within scope can be approved by the Project Manager.


 Any change affecting an external sub-contractor would need to be reviewed with that
contractor who would agree any necessary contract revisions or payments etc.
 Changes of scope and contract revisions would require the approval of the Steering
Committee (or it might have been a Change Control Board).

In making the decision, the Project Manager, Change Control Board or Steering Committee would be
guided by the pre-established principles for making change decisions.

After the action is agreed the work is assigned for action by the Project Team and/or the external
sub-contractor. When complete, the action would be reviewed and the Change Request closed. It is
possible that the agreed action could have more than one stage. For example, it might be better to
introduce a temporary solution so that the overall benefit from the project can be delivered, and
then build a permanent solution after the system is live.

Managing Scope and Change Requests during the Project

Not all changes follow the approved process. Often team members will be persuaded to make a
change without using the approved procedure where it seems necessary but minor. Although this
can seem practical to those concerned, it represents a risk to the project. The Project Manager and
Project Office team should be alert for uncontrolled changes. Where necessary, changes should be
painlessly re-directed into the correct procedure.

The Change Control process will run continuously during the project, and potentially beyond that
into live running. The Project Office team and the Project Manager will administer and control the
process.

100 | P a g e
Here is an example Change Request Form.

In many ways it is similar to the Issue


Submission Form. The difference is that the
Change Request addresses specific changes
to be reviewed, authorised and made,
whereas the Issue Submission Form
captures less-well-defined information. In
the Change Request there is more attention
to the exact nature of the changes, whether
they are scope changes, where they lie in
the project lifecycle, which specific
document or deliverable references need
attention, etc.

Specific attention is paid to the cost and


implications, identifying where work will be
required and what its impact will be in
terms of cost, risk and timescale. In
particular, a benefit case will be prepared to
summarise why the change should be
made.

The Project Manager, Change Control Board


or Steering Committee will use this Benefit
Case in making a decision, in line with the
pre-established guiding principles.

The status of the Change Request and its approval level should be tracked. In addition to the
database of Change Requests, there would be logs and various management reports to allow the
project leadership to track and control the changes. The Technical and administrative tracking of the
actual changes would normally be made using the Configuration Management process.

At the End of the Phase

The Change Control process continues throughout the project, so no specific action is necessarily
required at the end of each phase. Nevertheless, phase end is a good time to review the status of
Change Requests, ensuring requests have been actioned in a timely fashion within the phase, and, in
particular, allowing for their impact in the detailed planning for the following phase.

At the End of the Project

Some Change Requests may have been deferred for processing after the project is complete. This
can be an easier option than disrupting the interrelated development and testing during the initial
project. It might also be non-beneficial to delay the entire project to accommodate a change that
could wait until benefit from the main functionality has been generated. At the end of the project, it
is important that any outstanding actions are reviewed and the appropriate procedure is initiated to
get them addressed. (It is easy to forget those promises after the project has finished.)

101 | P a g e
The Project Office should ensure all changes have been properly finalised. All Change Requests
should either have been completed or passed onwards for subsequent processing. The permanent
documentation and other deliverables (eg training) should have been updated to reflect the
changes.

Change Requests may often reflect lessons to be learned for future projects. It is always worthwhile
reviewing what can be learned and submitting any new knowledge or wisdom into the various
knowledge repositories. Note, in particular, any situations where existing approaches or sample
plans should be updated.

Identify and document scope management issues and recommend


improvements for future projects15

Issue Management

Why, What, How?

Issues will arise throughout a project and beyond. There is a temptation to try to avoid trouble by
discouraging people from raising their concerns. Of course, the opposite is the best policy. Any
potential problem should be surfaced as early as possible and dealt with efficiently.

Anyone concerned with the project may spot potential problems. The participants should be
encouraged and rewarded for bringing these to the attention of the project leadership. Once an
issue is raised, the Project Manager should ensure that it is proactively pursued and dealt with to the
satisfaction of all concerned parties. It should be easy for the participants to submit their concerns. It
is a good idea to stimulate the submission of issues, possibly by requesting input as part of the
participants' regular progress reporting. One way this might be done is by including an "issues"
section on the project timesheet.

A distinction is sometimes made between different types of issue, for example:

 software errors or "bugs" in the developed technical solution,


 more general problems that concern the project team,
 issues that represent a requested change to the system, and
 problems or "bugs" that need to be reported to an external supplier.

In some projects, different processes will be defined. Alternatively, a single mechanism would
present a less confusing interface for the participants, but would need to support variations in how
the issue is dealt with.

There certainly are some different considerations with issues reported to external suppliers. Very
often that supplier will have its own specific procedures, tracking system, reference numbers, liaison
points etc.

15
Source: EPM Book, as at http://www.epmbook.com/issues.htm, as on 6th August, 2016.

102 | P a g e
It is good practice to channel external links through a single point of contact - either a member of
the Project Office, a specialist within the project team, or a designated person in the wider
organisation.

Note that the project team will also need to set up a permanent operational mechanism for the
resolution of problems reported by users during the live running of the system. It may be based on
the approach used during the project, or it may be that the organisation has a good standard
procedure in place.

There are also some specific stages in a project that might warrant their own issue management
process and system, for example:

 evaluating loosely defined solutions options as part of the conceptual design thought
process,
 evaluating and selecting external service suppliers and systems components, and
 testing the solution components.

Although these are more part of the project work than part of the project management, it may be
appropriate to use some of the same techniques and tools but without the degree of administration
and control that should be found in the project's main issue management process.

Issue Management at the Start of the Project

Relatively little attention to Issue Management is required as part of the Project Definition work. It
would be normal to agree the overall approach and its importance with the Project Sponsor and
senior leadership.

The main activity at this time would be to establish the mechanism that will be used, particularly if it
involves a system that needs to be selected, acquired and implemented. The issue management
system would normally be part of the same overall set of procedures and tools that will be used to
support the other project management activities. A number of commercial software tools are
available. It would also be straightforward to set up your own local system using client server or web
technology. In relatively simple projects, the needs could be met by standard tools such as EMail and
spreadsheets.

Starting up the Issue Management Process

The issue management process will normally involve a combination of procedures, responsibilities
and systems. The key to success is to have a well-controlled but easy and efficient process. Define
and agree:

 who does what,


 the detailed procedures, forms, tools etc,
 protocols for levels of authority, eg what type of corrective action can be undertaken
without reference to the project's senior leadership,
 linkage to other management procedures, eg the scope change management process,
configuration management,
 linkage to external supplier's procedures,

103 | P a g e
 which tools will be used to support and manage the process,
 how to communicate and promote the process and its importance to all participants.

Here is a basic process for dealing with issues:

The first priority is to identify and capture the issue. It would then be examined by an appropriate
member of the project team to decide how best to deal with it. Specific actions would be proposed,
possibly alternative courses of action to be compared and agreed. Where the issue or action has a
significant impact upon the project's benefit model it would normally need to be referred to the
overall project leadership, probably using the project's scope change mechanism. In any event, the
impact would be reported to the steering committee. The agreed actions are then assigned and
carried out, subject to monitoring by the Project Office followed by a final review and sign off.

Running the Issue Management Process

The Issue Management process will run throughout the project, and potentially beyond that into live
running. Team members and other participants will be encouraged to submit issues. The Project
Office team and the Project Manager will administer and control the process.

It is normal to create standard forms for the submission of issues. Although this could be paper
based, it is more common to use EMail, client/server or web-based approaches.

104 | P a g e
Issue Submission Form

Here is an example of a web-


based Issue Submission Form.

From a control point of view, it is


important to record the
participants involved, the dates
and the status. The Project Office
team will monitor and chase
progress. The Project Manager
will review the status and take
further action as required.

Where necessary, the issue's


resolution will be referred to
other bodies such as the Steering
Committee, external suppliers,
other specialist departments etc.
It may also be necessary to
invoke other management
processes such as Scope Change
Control and Configuration
Management.

To support the process a variety


of enquiries, reports and control
documents may be generated.
The ideal model is a knowledge
sharing database accessible by all
participants.

Issue Control Log

The most important control tool is a log summarising the issues, their current status and who is
currently responsible for them, again this may take a variety of technical forms from paper to a fully
integrated database.

This version is a simple Excel file.

105 | P a g e
Issue Management at Phase End

Although the project team will be striving to resolve issues in the most beneficial way, some may
remain unresolved at the end of a phase. The Project Manager will need to review the status of the
outstanding issues and consider what impact they may have. The phase-end reporting should
include any significant outstanding issues and will summarise the overall impact on the benefit
model. Any consequences should be agreed with the Project Sponsor and Steering Committee.

Outstanding issues will form an input into the detailed planning process for the following phase of
work.

Completing the Issue Management Process

The Project Manager and Project Office staff will be reviewing the outstanding issues on a regular
basis and proactively chasing them to conclusion. By the end of the project there should be no
outstanding issue left to resolve. This does not mean that every issue can be dealt with during the
project. It may be that some concerns cannot be dealt with and appropriate responses should be
made to those concerned. Other issues may be deferred to be addressed either as part of the live
maintenance of the system or in a future project. Bear in mind that perfection may be expensive if
not unachievable. It is normal to accept a reasonable level of imperfection where that represents the
best value between cost, benefit, risk and time. With the amazing pace of eSolutions, a rapid
workable solution is often better than a high-quality one.

The final status of the issues should normally be reported and reviewed with the Project Sponsor
and project leadership as part of the finalisation of the work. Unsatisfactory conclusions will
normally have an impact on the final benefit model. Specific actions or requests for future work
would be passed into the relevant management processes.

Dealing with the project's issues and their resolution will have generated new wisdom and
understanding. The individuals concerned should have benefited from the experience. It is probably
worthwhile spending some time recapping the lessons that were learnt. The wisdom should be
shared where possible through whatever formal and informal mechanisms are available for
knowledge sharing.

106 | P a g e
Activity 11

Which project management plan guides the creation of the detailed project scope statement?

(a) Charter
(b) Project management plan
(c) Project scope plan
(d) Project scope management plan
Which one of the following is not needed to define the project scope?

(a) Project charter


(b)Organizational process assets
(c) Risk management plan
(d) Requirements documentation
You are the project manager of the BHY Project. Your project customer has demanded that the
project be completed by December 1. December 1 is an example of which one of the following?

(a) Constraint
(b)Assumption
(c) Project boundary
(d) Product acceptance criteria
Which two items are parts of the scope baseline for the project?

(a) Project scope management plan and the project charter


(b) Project scope management plan and the WBS
(c) WBS and WBS dictionary
(d) Time and cost baselines
Which system defines how the project scope and the product scope can be changed?

(a) Project scope change control system


(b) Project integrated management system
(c) Project management information system
(d) Change control
A change has been approved in Marcy’s project. All of the following must be updated to reflect the
change, except for which one?

(a) Project scope statement


(b) WBS
(c) WBS dictionary
(d) Defect repair review
You are the project manager for the JHG Project. Your project is to create a new product for your
industry. You have recently learned that your competitor is also working on a similar project, but
their offering will include a computer-aided program and web-based tools, which your project

107 | P a g e
Activity 11

does not offer. You have implemented a change request to update your project accordingly. This is
an example of which of the following?

(a) A change due to an error and omission in the initiation phase


(b) A change due to an external event
(c) A change due to an error or omission in the planning phase
(d) A change due to a legal issue

108 | P a g e
Business, Accounting and Finance
BSBPMG511 MANAGE PROJECT SCOPE
BSBPMG511 Manage project scope

Conduct project
authorisation activities

Define project scope

Manage project scope


control process

WHAT IS PROJECT SCOPE PROJECT SCOPE MANAGEMENT


MANAGEMENT? PROCESSES
• Scope planning: deciding how the scope will be defined, verified,
• Scope refers to all the work involved in creating the
and controlled
products of the project and the processes used to create
• Scope definition: reviewing the project charter and preliminary
them scope statement and adding more information as requirements are
• A deliverable is a product produced as part of a project, developed and change requests are approved
such as hardware or software, planning documents, or • Creating the WBS: subdividing the major project deliverables into
meeting minutes smaller, more manageable components
• Scope verification: formalizing acceptance of the project scope by
• Project scope management includes the processes
key project stakeholders
involved in defining and controlling what is or is not
• Scope control: controlling changes to project scope which impact
included in a project
project cost and time goals

PROJECT SCOPE MANAGEMENT


SUMMARY
SCOPE PLANNING AND THE WHAT WENT RIGHT?
SCOPE MANAGEMENT PLAN
• Many financial service companies use customer
relationship management (CRM) systems to improve their
• The scope management plan is a document that includes
understanding of and responsiveness to customers
descriptions of how the team will prepare the project scope
• A senior management team at the Canadian money
statement, create the WBS, verify completion of the project
management company Dynamic Mutual Funds (DMF)
deliverables, and control requests for changes to the launched an enterprise-wide, national program to build
project scope and manage its customer relationships
• Key inputs include the project charter, preliminary scope • They needed a faster and more organized, highly
statement, and project management plan participative approach, so they proposed a new seven-step
concept called project scope design
• It should be reviewed with the project sponsor to make sure
• DMF won an eCustomer World Golden Award for world-
the approach meets expectations class innovation

WHAT WENT RIGHT?


SAMPLE SCOPE MANAGEMENT
The Seven Steps PLAN
1. Analyze the project atmosphere, staekholders and centers of
influence
2. Align the project scope with the organization’s strategic
objectives and business challenges
3. Determine where to add value to the business
4. Study the process flow between the business units
5. Develop an efficient communication strategy
6. Develop the project approach
7. Coordinate the new project with the other initiatives already
under way

SAMPLE PROJECT CHARTER


SCOPE DEFINITION AND THE
PROJECT SCOPE STATEMENT
• The project team develops a preliminary scope
statement in initiating a project as part of the
project integration management knowledge area
• The preliminary scope statement, project charter,
organizational process assets, and approved
change requests provide a basis for creating the
more specific project scope statement

SCOPE DEFINITION AND THE


PROJECT SCOPE STATEMENT FURTHER DEFINING PROJECT
SCOPE
• Project scope statements should contain at a
minimum:
• Description of the project – overall objectives,
justification
• Detailed descriptions of all project deliverables
• Characteristics and requirements of products and
services produced as part of the project
• Other helpful information:
• Project success criteria
• Project boundaries
• Product acceptance criteria
• Schedule milestones
• Order of magnitude costs estimates…

WORK BREAKDOWN STRUCTURE WORK BREAKDOWN STRUCTURE


(WBS) (WBS)
• A WBS is a deliverable-oriented grouping of the work involved in a
• The project scope statement and project management
project that defines the total scope of the project
plan are the primary inputs for creating a WBS
• WBS is a foundation document that provides the basis for planning and
managing project schedules, costs, resources, and changes • The outputs include the WBS itself, the WBS dictionary,
• Decomposition is subdividing project deliverables into smaller pieces a scope baseline and updates to the project scope
• A work package is a task at the lowest level of the WBS statement and scope management plan
• Tasks on a WBS represent work that needs to be done to • The WBS is often depicted as a task-oriented family
complete the project, not specifications (e.g., type of tree of activities
server) • The WBS can be organized around project products, project phases or
using the project management process groups
PARTIAL WBS ORGANIZED BY
PARTIAL WBS ORGANIZED BY
PRODUCT AREAS PROJECT PHASE

PARTIAL INTRANET WBS IN TABULAR


FORM
1.0 Concept
1.1 Evaluate current systems
1.2 Define Requirements
1.2.1 Define user requirements
1.2.2 Define content requirements
1.2.3 Define system requirements
1.2.4 Define server owner requirements
1.3 Define specific functionality
1.4 Define risks and risk management approach
1.5 Develop project plan
1.6 Brief Web development team
2.0 Web Site Design
3.0 Web Site Development
4.0 Roll Out
5.0 Support

INTRANET WBS AND GANTT


CHART IN MICROSOFT PROJECT
INTRANET GANTT CHART
ORGANIZED BY PROJECT
MANAGEMENT PROCESS GROUPS

APPROACHES TO DEVELOPING WBSS MIND MAPPING


• Using guidelines: some organizations, like the • Mind Mapping is a way of creating pictures
DOD, provide guidelines for preparing WBSs that show ideas in the same way that they
• The analogy approach: review WBSs of similar are represented in your brain.
projects and tailor to your project • Your brain uses words, pictures, numbers,
• The top-down approach: start with the largest logic, rhythm, color and spatial awareness
items of the project and break them down to build up unique pictures of information.
• The bottom-up approach: start with the specific • The ideas are linked together in a way that
tasks and roll them up makes it easy to understand and
• Mind-mapping approach: mind mapping is a remember.
technique that uses branches radiating out from a • http://www.novamind.com/mind-mapping/
core idea to structure thoughts and ideas • http://www.youtube.com/watch?v=MlabrWv25qQ

MIND MAPPING
MIND MAPPING • Use just key words, or wherever possible images.
• Start from the center of the page and work out.
• Make the center a clear and strong visual image that depicts the general theme of
the map.
• Create sub-centers for sub-themes.
• Put key words on lines. This reinforces structure of notes.
• Print rather than write in script. It makes them more readable and memorable.
Lower case is more visually distinctive (and better remembered) than upper case.
• Use color to depict themes, associations and to make things stand out.
• Anything that stands out on the page will stand out in your mind.
• Think three-dimensionally.
• Use arrows, icons or other visual aids to show links between different elements.
• Don't get stuck in one area. If you dry up in one area go to another branch.
• Put ideas down as they occur, wherever they fit. Don't judge or hold back.
• Break boundaries. If you run out of space, don't start a new sheet; paste more
paper onto the map. (Break the 8x11 mentality.)
• Be creative. Creativity aids memory.
• From http://www.peterrussell.com/MindMaps/HowTo.php
SAMPLE MIND-MAPPING APPROACH RESULTING WBS IN CHART
FOR CREATING A WBS FORM

THE WBS DICTIONARY AND SCOPE


BASELINE SAMPLE WBS DICTIONARY
• Many WBS tasks are vague and must be explained ENTRY
more so people know what to do and can estimate
how long it will take and what it will cost to do the
work
• A WBS dictionary is a document that describes
detailed information about each WBS item
• The approved project scope statement and its WBS
and WBS dictionary form the scope baseline, which
is used to measure performance in meeting project
scope goals

CREATING A WBS AND WBS DICTIONARY*


• A unit of work should appear at only one place in the WBS
• The work content of a WBS item is the sum of the WBS
items below it
• A WBS item is the responsibility of only one individual,
even though many people may be working on it
• The WBS must be consistent with the way in which work is
actually going to be performed; it should serve the
project team first, and other purposes only if practical

*Cleland, David I. Project Management: Strategic Design and Implementation, 1994


CREATING A WBS AND WBS SCOPE VERIFICATION
DICTIONARY *
• Project team members should be involved in • It is very difficult to create a good scope
developing the WBS to ensure consistency and buy-in statement and WBS for a project
• Each WBS item must be documented in a WBS • It is even more difficult to verify project scope
dictionary to ensure accurate understanding of the and minimize scope changes
scope of work included and not included in that item • Scope verification involves formal acceptance
• The WBS must be a flexible tool to accommodate of the completed project scope by the
inevitable changes while properly maintaining control stakeholders
of the work content in the project according to the scope • Acceptance is often achieved by a customer
statement inspection and then sign-off on key
*Cleland, David I. Project Management: Strategic Design and Implementation, 1994
deliverables

WHAT WENT WRONG? SCOPE CONTROL


• A project scope that is too broad and grandiose can cause severe
problems
• Scope control involves controlling changes to the
project scope
• Scope creep and an overemphasis on technology for
technology’s sake resulted in the bankruptcy of a large • Goals of scope control are to:
pharmaceutical firm, Texas-based FoxMeyer Drug • Influence the factors that cause scope changes
• In 2001, McDonald’s fast-food chain initiated a project to • Assure changes are processed according to procedures
developed as part of integrated change control
create an intranet that would connect its headquarters
• Manage changes when they occur
with all of its restaurants to provide detailed operational
information in real time; after spending $170 million on • Tools for performing scope control include a change
consultants and initial implementation planning, control system and configuration management
McDonald’s realized that the project was too much to • Variance is the difference between planned and actual
handle and terminated it performance

BEST PRACTICES FOR AVOIDING SCOPE SUGGESTIONS FOR IMPROVING


PROBLEMS
USER INPUT
1. Keep the scope realistic: Don’t make projects so large that they can’t be
completed; break large projects down into a series of smaller ones • Develop a good project selection process and insist that
2. Involve users in project scope management: Assign key users to the sponsors are from the user organization
project team and give them ownership of requirements definition and • Have users on the project team in important roles
scope verification
• Have regular meetings with defined agendas, and have
3. Use off-the-shelf hardware and software whenever possible: Many IT
people enjoy using the latest and greatest technology, but business users sign off on key deliverables presented at meetings
needs, not technology trends, must take priority • Deliver something to users and sponsors on a regular basis
4. Follow good project management processes: As described in this
• Don’t promise to deliver when you know you can’t
chapter and others, there are well-defined processes for managing
project scope and others aspects of projects • Co-locate users with developers
SUGGESTIONS FOR REDUCING SUGGESTIONS FOR REDUCING
INCOMPLETE AND CHANGING INCOMPLETE AND CHANGING
REQUIREMENTS REQUIREMENTS
• Develop and follow a requirements • Provide adequate testing and conduct testing
throughout the project life cycle
management process • Review changes from a systems perspective
• Use techniques such as prototyping, use case • Project scope changes must include associated cost
modeling, and JAD to get more user and schedule changes
involvement • Focus on approved scope goals and don’t get side
tracked
• Put all requirements in writing, keep them • Emphasize completion dates to help focus on what’s
current and readily available most important
• What should we drop in order to add something
• Create a requirements management database new?
for documenting and controlling requirements • Allocate resources specifically for handling change
(CASE tools) requests/enhancements like NWA did with ResNet

USING SOFTWARE TO ASSIST IN


BAD PLANNING
PROJECT SCOPE MANAGEMENT
• Word-processing software helps create several
In 1975, the military government of Nigeria decided
scope-related documents
on a major program of construction and road
• Spreadsheets help to perform financial calculations
and weighed scoring models, and develop charts building.
and graphs
• Communication software like e-mail and the Web They decided to order all their cement requirements
help clarify and communicate scope information in one go.
• Project management software helps in creating a
WBS, the basis for tasks on a Gantt chart
• Specialized software is available to assist in project
scope management

BAD PLANNING BAD PLANNING

• Nigeria only had one harbour big enough to unload


This totalled two-thirds of the estimated needs of all of the supply vessels
Africa and exceeded the productive capacity of
Western Europe and the Soviet Union combined! • 400 cargo ships, 250 of them carrying 1.5 million
tons of cement arrived at Lagos harbour.

• The harbour was clogged for 15 months.

• The cement started to set and many ships failed to


unload.
BAD PLANNING A "PROJECT"

• The cost to Nigeria was US$2 billion!!! • is a set of activities which ends with a
specific accomplishment (the goal) and
which has:-
• Interdependent tasks
• Distinct start/finish dates
• Resource constraints
(time/money/people/equipment).

THE PLANNING PROCESS DEFINITIONS

•The project management • Deliverable


• A tangible and measurable result, outcome, or item
process means planning the that must be produced to complete a project or part
work and then working the of a project.
• Milestone
plan.
• A reference point marking a major event in a project
and used to monitor the project's progress.

PROJECT SCOPE PROJECT SCOPE (CONTINUED)

• Is a broad framework that defines what the project is • What are their expected outcomes in terms of time,
about quality and cost?
• How long will the project take?
• Involves creating agreements with clients and
• What sort of activities will you need to undertake in
stakeholders
order to complete the project?
• To determine the scope of our project we should ask • What are the broad risks involved in completing the
the following questions. project?
• What do you intend to achieve in order to met the • Who else, individuals & organisations do you need to
consult?
needs of the client and stakeholders?
PLANNING CLEARLY DEFINE THE PROJECT
GOAL
• Clearly define the project goal
• The goal
• Project usually has one major goals • Defines the final outcome in terms of
and several objectives that support end product or services
• Is the continual point of reference for
that goal settling disputes or misunderstandings
about the project
• Is the guide that keeps all the
objectives and the work associated
with them on track.

CLEARLY DEFINE THE PROJECT


GOAL
PROJECT OBJECTIVES

• Project objectives –support the project goal


• Goal statement should be action-orientated, short, simple, easy
to understand. • stated clearly, simply & realistically
• “To develop a production process capable of delivering 300 • Have definable & measurable end result
defect free portable “Alaska” refrigerator units per week by
24 May 2007 within a budget of $125, 000. to be accomplished
• Project goal • Are finite –i.e. they have a beginning and
• The desired end result of project is stated in the goal an end.
• The goal can be realistically accomplished
• S.M.A.R.T
• The goal is manageable

PROJECT OBJECTIVES PROJECT OBJECTIVES

• SMART Goals And Objectives • A project's objectives may include:


• Specific to the overall stakeholder requirements • A list of project deliverables.
• Measurable
• Specific due dates, both for the ultimate completion
• Achievable
of the project and for intermediate milestones.
• Realistic
• Time and Cost Bound • Specific quality criteria the deliverables must meet.
• Cost limits the project will not exceed
CAUSES OF SCOPE CREEP OR
SCOPE CREEP OR SLIPPAGE
SLIPPAGE
• refers to uncontrolled changes in a project's scope, • Unstated or conflicting aims & objectives
where the intentions, agreements and risks can be • Scope poorly formatted and presented
overlooked, ignored or misinterpreted
• Vague details of the description of work to be
• This phenomenon can occur when the scope of a undertaken
project is not properly defined, documented, and
• Failing to acknowledge polices, procedures to
controlled.
specifications relevant to the project
• Over-enthusiasm for the project
• Overcaution or ignorance of project risks

PROJECT SCOPE-CREEP Failure to define what is part of the project,


MANAGEMENT as well as what is not, may result in work
being performed that was unnecessary to
create the product of the project and thus
lead to both schedule and budget
overruns.
Olde Curmudgeon, PM Network Magazine, 1994.

BENEFITS OF SCOPE MYTHS OF SCOPE


CONTROL MANAGEMENT
• Myth 1: User involvement will result in an
• Keep project manager in control of IS project grounded in the realities of
project business needs.
• Myth 2: A scope statement will clearly
• Allow project manager to control define what a project will do.
project’s schedule and budget • Myth 3: Once the scope of the project is
• Allow project team to stay focused defined, hold firm because any deviation
from the original plan is a sign that the
and on track project is out of control.
MYTHS OF SCOPE SCOPE CHANGE
MANAGEMENT
CONTROL
• Myth 4: A function of a scope change committee is to
arbitrate user requests for additional features or
functionality beyond the original project charter. •Concerns
• Myth 5: Regular and frequent meetings with senior • Scope grope
management will ensure they are kept up to date
and will result in goodwill and support. • Scope creep
• Myth 6: You can always make up schedules and • Scope leap
budgets later on if they slip a little bit.

FACTORS CAUSING IT PROJECT


PROBLEMS

SCOPE CHANGE CONTROL


PROCEDURES
SCOPE CHANGE REQUEST FORM
SCOPE CHANGE CONTROL
PROCEDURES SCOPE MANAGEMENT PLAN
SCOPE CHANGE REQUEST LOG

SCOPE MANAGEMENT PROCESS

SCOPE BOUNDARY
SUGGESTIONS FOR REDUCING
SUGGESTIONS FOR IMPROVING INCOMPLETE AND CHANGING
USER INPUT REQUIREMENTS
• Develop and follow a requirements management
• Develop a good project selection process and insist process
that sponsors are from the user organization • Use techniques like prototyping, use case modeling,
• Have users on the project team in important roles and JAD to get more user involvement
• Have regular meetings • Put requirements in writing and keep them current
• Provide adequate testing and conduct testing
• Deliver something to users and sponsors on a throughout the project life cycle
regular basis
• Review changes from a systems perspective
• Co-locate users with developers • Emphasize completion dates to help focus on what’s
most important
• Allocate resources specifically for handling change
requests/enhancements

USING SOFTWARE TO ASSIST IN PROJECT RISK


PROJECT SCOPE MANAGEMENT
• Word-processing software helps create several scope- • Definition of risk in terms of project management
related documents
• Spreadsheets help to perform financial calculations, “the chance of something happening that will have
create weighted scoring models, and develop charts an impact on objectives. It is measured in terms of
and graphs
• Communication software like e-mail and the Web help
consequences and likelihood”
clarify and communicate scope information
• Project management software helps in creating a WBS,
the basis for tasks on a Gantt chart
• Specialized software is available for applying the
balanced scorecard, creating mind maps, managing
requirements, and so on

WHAT IS RISK? CONSTRAINT RISKS


• Product risk
• Risk is the possibility that you may not achieve: • A risk that prevents you from meeting the product/project
• Product/project specification – it doesn’t do what it specification

was supposed to do • Schedule risk


• Schedule target - the project is late • A risk that prevents project element from being completed
on time
• Resource target – the project costs too much or uses
• Resource risk
too much staff time
• A risk that prevents enough or appropriate resources from
being available to complete a project element
FAMILIARITY & RISK PROJECT RISK INCREASES

• Risk is higher if we are dealing with the unfamiliar. • The longer your project runs
• The task itself may be unfamiliar.
• The setting may be unfamiliar. • The longer the time span between
• The less experienced you, your team, completion of the project schedule and
your organisation has of carrying out actually starting work
similar projects the greater the risk
• The newer the technology or work
approach being used

RISK MANAGEMENT MANAGING RISK

• The process of identifying possible risks • Requires a systematic approach. Project managers
may ask themselves
• Assessing their potential impact
• Where might the risks of my project come from?
• Developing plans for minimising their negative
effects • How large are the risks?

• Reviewing them throughout the project • Who or what might pose a risk to my project?
• What situations and/or activities create the possibility
of risks occurring?

Internal / External Risks PROBABILITY OF RISK

External Environment • The process of risk assessment requires the project


Things outside of the projects direct control that may result in team to identify the likelihood of risk occurring and
its failure, but can be identified and monitored via a watching the consequence to the project
brief, i.e. fire, flood, famine, pestilence and war!
• The following slide is an example
Internal Environment: • The project goal
Those that can occur as part of
• “Design and replant Botanical Gardens by
the project itself - something
can usually be done about these September 06, budget $65.000”
ANOTHER TYPE OF RISK MATRIX
RISK EVENT RATING IMPACT
* ** RISK EVENT Probability Consequence
Very high rain levels (more than 3 5 Bad weather Likely Serious –
3 days a week) schedule delayed
Equipment failure 2 5 Scope changes Certain Major -variations
in time, budget etc
Staff shortfall 3 4 Budget reductions Rare Major-downgrade
of resources etc
Specified plants unavailable 2 3
Lack of available Certain Major-schedule
resources delays due to
* 1 unlikely – 5 certain **1 Low – 5 High rescheduling
resources

RISK ANALYSIS

• Description: What is the risk?


• Impact: Will it affect success of project?
• Likelihood: Is it realistic to worry?
• Warning Mechanism: How do we predict that
something is about to go wrong?
• Mitigating Action: How do we prevent it affecting
the success of the project?

RISK RESPONSE STRATEGIES- RISK RESPONSE STRATEGIES-


ACCEPTANCE, MITIGATION, ACCEPTANCE, MITIGATION,
AVOIDANCE AVOIDANCE
• Acceptance – the risk and the implications for the • Mitigation – reserves or contingencies that can be
project’s outcome are accepted. No contingency is executed should the event occur, or the task may be
prepared to counter the risk rescheduled to a later date so the risk is minimised

• E.g. Wedding party planning outdoor wedding and • E.g. Postponing landscaping tasks until the wet
hoping that it wont rain during the ceremony, season is finished
therefore not organising shelter.
Any Questions?
RISK RESPONSE STRATEGIES-
ACCEPTANCE, MITIGATION,
AVOIDANCE

• Avoidance-aims at eliminating the actual cause (or


probability and/or consequences) of the risk from
impacting on the project. Transfer the risk to
someone more capable of dealing with the problem
• E.g. hiring specialist contractors to perform work at
their risk, not yours
Student Assessment Information
The process you will be following is known as competency-based assessment. This means that
evidence of your current skills and knowledge will be measured against national and
international standards of best practice, not against the learning you have undertaken either
recently or in the past. (How well can you do the job?)

Some of the assessment will be concerned with how you apply the skills and knowledge in your
workplace, and some in the training room.

The assessment tasks utilized in this training have been designed to enable you to demonstrate the
required skills and knowledge and produce the critical evidence required so you can successfully
demonstrate competency at the required standard.

What happens if your result is ‘Not Yet Competent’ for one or more assessment tasks?

The assessment process is designed to answer the question “has the participant satisfactorily
demonstrated competence yet?” If the answer is “Not yet”, then we work with you to see how we
can get there.
In the case that one or more of your assessments has been marked ‘NYC’, your Trainer will provide
you with the necessary feedback and guidance, in order for you to resubmit/redo your assessment
task(s).
What if you disagree on the assessment outcome?

You can appeal against a decision made in regards to an assessment of your competency. An appeal
should only be made if you have been assessed as ‘Not Yet Competent’ against specific competency
standards and you feel you have sufficient grounds to believe that you are entitled to be assessed as
competent.
You must be able to adequately demonstrate that you have the skills and experience to be able to
meet the requirements of the unit you are appealing against the assessment of.
You can request a form to make an appeal and submit it to your Trainer, the Course Coordinator, or
an Administration Officer. The RTO will examine the appeal and you will be advised of the outcome
within 14 days. Any additional information you wish to provide may be attached to the form.
What if I believe I am already competent before training?

If you believe you already have the knowledge and skills to be able to demonstrate competence in
this unit, speak with your Trainer, as you may be able to apply for Recognition of Prior Learning
(RPL).
Credit Transfer
Credit transfer is recognition for study you have already completed. To receive Credit Transfer, you
must be enrolled in the relevant program. Credit Transfer can be granted if you provide the RTO with
certified copies of your qualifications, a Statement of Attainment or a Statement of Results along
with Credit Transfer Application Form. (For further information please visit Credit Transfer Policy)

109 | P a g e
LEARNING OUTCOMES
The following critical aspects must be assessed as part of this unit:

1. Interact with customers, collect the necessary information and match customers' needs to
company products or service
2. Sell products and services including matching customers' requirements to company products and
services and finalise and record the sale

LEARNING ACTIVITIES

Class will involve a range of lecture based training, activities, written task, case study and
questioning.

STUDENT FEEDBACK

We welcome your feedback as one way to keep improving this unit. Later this semester, you will be
encouraged to give unit feedback through completing the Quality of Teaching and Learning Survey

LEARNING RESOURCES
Other Learning Resources available to students include:

 Candidate Resource & Assessment: BSBPMG511 Manage project scope.


 Presentation handout
 PPT Presentation

TEXTBOOKS

You do not have to purchase the following textbooks but you may like to refer to them:

Unit Code(s) Unit Title Reference Book/ Trainer & Learner Resource

BSBPMG511 Manage project scope  The Business Communication Handbook 7th


edition
 The Principles of Project Management
(Merri Williams)

110 | P a g e
 Project Management in Practice by Neil D.
Pearson
 Trainer and Learner Resources by LRES
Training Management

Additional Reference Texts

ASSESSMENT DETAILS

Assessment Summary
The assessment for this unit consists of the following items.

Knowledge Assessment

Task 1 : Project Scope Management

Formative Activities
In addition to the two assessment tasks, students will be required to complete activities as outlined
by their trainer/assessor – these will be taken from class resources, Enhance Your Future Learner
Guides.

Referencing Style
Students should use the referencing style outlined by the Trainer when preparing assignments. More
information can be sought from your Course Trainer.

Guidelines for Submission


1. An Assignment Cover Sheet (or cover page) must accompany all assignments at front to
confirm it is your own assessment/ work.

2. All assignments must be within the specified timeframe (please refer to Due Date).

Assignment Marking
Students should allow 14 days’ turnaround for written assignments.

Plagiarism Monitoring

111 | P a g e
Students should use the referencing style outlined by when preparing assignments. More
information can be sought from your Trainer.

Marking Guide
C Competent: for students who have achieved all of the learning outcomes specified for that
unit/module to the specified standard.

NYC Not Yet Competent: for students who are required to re-enrol in a unit/ module in their
endeavour to achieve competence

S Satisfactory: has achieved all the work requirements

NS Not Satisfactory: has not achieved all the work requirements

Every student at Danford College can expect to have “timely fair and constructive assessment of
work.” Assessment tasks must be marked in such a way that the result reflects how well a student
achieved the learning outcomes and in accordance with the assessment criteria. In addition to the
final result, returned assignments must be accompanied by feedback that clearly explains how the
marking result/s was derived (summative), as well as how the student can improve (formative).

Refer to observation checklist below and/or consult your trainer/assessor for marking criteria for
this unit.

STUDENTS’ RIGHTS AND RESPONSIBILITIES


It is the responsibility of every student to be aware of all relevant legislation, policies and procedures
relating to their rights and responsibilities as a student. These include:
 The Student Code of Conduct
 The College’s policy and statements on plagiarism
 Copyright principles and responsibilities
 The College’s policies on appropriate use of software and computer facilities
 Students’ responsibility to attend, update personal details and enrolment
 Course Progress Policy and Attendance
 Deadlines, appeals, and grievance resolution
 Student feedback
 Other policies and procedures.

112 | P a g e
 Electronic communication with students

International Students Please also refer to ESOS framework for further details
https://internationaleducation.gov.au/Regulatory-Information/Education-Services-for-Overseas-
Students-ESOS-Legislative-Framework/ESOS-Act

ADDITIONAL INFORMATION

Contacts:
If you have a query relating to administrative matters such as obtaining assessment results, please
contact your Course co-ordinator.

Deferrals/Suspensions/Cancellations
Danford College will only allow deferrals/student requested suspensions under exceptional
compassionate circumstances. Once a student has commenced studies, students are not allowed to
take leave unless there are compelling and compassionate reasons. Please refer to the College’s
Deferment, Suspension and Cancellation Policy available in the Student Handbook and at Student
Administration. This policy has been explained to you at Orientation.

Course Progress Policy


You are expected to attend all classes and complete your units of study satisfactorily, within your
term. Your Course Trainer will make a report to the Course co-ordinator if there are any concerns
about your progress. The Course Progress Policy is available to you in the Student Handbook and at
Student Administration or on college website www.danford.edu.au.
Assessment Conditions

Assessment must be conducted in a safe environment where evidence gathered demonstrates


consistent performance of typical activities experienced in the management and leadership – project
management field of work and include access to:
 workplace documentation used to document and manage project scope
 examples of feedback from project stakeholders regarding management of project scope
 case studies and, where possible, real situations
 Interaction with others.
Assessors must satisfy SRTO2015/AQF assessor requirements.

113 | P a g e
Lesson/Session Plan
For face-to-face classroom based delivery as per timetable.

Delivery Day Delivery Topics Activities to be undertaken


1 Introduction to BSBPMG511 Manage Work through corresponding sections
project scope and Assessment of Learner Materials and Assessment
Requirements overview (Page 3) Tasks
Develop and confirm procedures for Activity 1 (Page 8)
project authorisation with an Commence Written Questions
appropriate authority (Page 6) PowerPoint Presentation – Slides 1 –
45

2 The Project Scope Management Work through corresponding sections


Processes (Page 10) of Learner Materials and Assessment
Tasks
Activity 2 (Page 18)
Continue with Written Questions

3 Obtain authorisation to expend Work through corresponding sections


resources (Page 19) of Learner Materials and Assessment
Tasks
Commence Task 1 – Project Scope
Management
4 Confirm project delegations and Work through corresponding sections
authorities in project governance of Learner Materials and Assessment
arrangements (Page 30) Tasks
Activity 3 (Page 32)
Continue with Task 1 – Project Scope
Management
5 Project Governance (Page 34) Work through corresponding sections
of Learner Materials and Assessment
Tasks
Activity 4 (Page 43)
Continue with Task 1 – Project Scope
Management

6 Identify, negotiate and document Work through corresponding sections


project boundaries (Page 45) of Learner Materials and Assessment
Tasks
Activity 5 (Page 51)
PowerPoint Presentation – Slides 46 -
62
7 Project Requirements (Page 53) Work through corresponding sections
of Learner Materials and Assessment
Tasks

114 | P a g e
Delivery Day Delivery Topics Activities to be undertaken
8 Establish measurable project benefits, Work through corresponding sections
outcomes and outputs (Page 58) of Learner Materials and Assessment
Tasks
Activity 6 (Page 67)
Activity 7 (Page 71)
9 Establish a shared understanding of Work through corresponding sections
desired project outcomes with of Learner Materials and Assessment
relevant stakeholders (Page 73) Tasks
Activity 8 (Page 75)
10 Document scope management plan Work through corresponding sections
(Page 77) of Learner Materials and Assessment
Tasks
Activity 9 (Page 83)
11 Implement agreed scope management Work through corresponding sections
procedures and processes (Page 84) of Learner Materials and Assessment
Tasks
Activity 10 (Page 92)
12 Manage impact of scope changes Work through corresponding sections
within established time, cost and of Learner Materials and Assessment
quality constraints according to Tasks
change control procedures (Page 94) PowerPoint Presentation – Slides 63 -
81
13 Scope Management at Project Start Work through corresponding sections
(Page 96) of Learner Materials and Assessment
Tasks
14 Identify and document scope Work through corresponding sections
management issues and recommend of Learner Materials and Assessment
improvements for future projects Tasks
(Page 102) Activity 11 (Page 106)
Complete Written Questions
PowerPoint Presentation – Slides 82 -
98
15 ASSESSMENT Complete Task 1 – Project Scope
Management

115 | P a g e
Knowledge Assessment (Written Tasks)

1. Completion of a product scope is measured against:

(a) Product Management Plan


(b) Project Management Plan
(c) WBS & WBS Dictionary
(d) Product Requirements

2. All of the below are inputs to Define Scope process EXCEPT:

(a) Project Charter


(b) Requirements Document
(c) Organizational process assets
(d) Project Management Plan

3. Validated deliverables is an input to which of the following processes?

(a) Collect Requirements


(b) Define Scope
(c) Create WBS
(d) Validate Scope

4. Project Charter is an input to all of the following processes EXCEPT:

(a) Collect requirements


(b) Define Scope
(c) Create WBS
(d) Develop Project Management Plan

5. Work Performance Measurement is an output of which process:

(a) Define Scope


(b) Create WBS
(c) Validate Scope
(d) Control Scope

6. If the project is terminated early, the level and extent of completion should be documented.
This is done as a part of:

(a) Define Scope


(b) Create WBS
(c) Validate Scope
(d) Control Scope

116 | P a g e
7. Validate Scope can be BEST described as the process of

(a) Validating that the project quality requirements have been met
(b) Obtaining stakeholder's formal acceptance of the project deliverables
(c) Controlling changes to the scope of the project
(d) Validating that all of the project's objectives have been met

8. Which of the following can be BEST described as a characteristic of Work Package?

(a) May or may not be cost estimated


(b) Can be scheduled
(c) Can be further decomposed into work packages
(d) May be monitored subject to nature of the project

9. The process of determining, documenting and managing stakeholder needs and requirements to
meet project objectives is known as

(a) Plan Scope Management


(b) Collect Requirements
(c) Control Scope
(d) Validate Scope

10. The Scope Management Plan is included in which of the following documents?

(a) Project Management Plan


(b) The Work Breakdown Structure
(c) The Scope Statement
(d) Project Specifications

11. Project Scope:

(a) is of concern only at the start of the project


(b) is mainly a problem to be handled by the change control procedures during the project execution
phase.
(c) Should be managed and controlled from the project concept through closing
(d) is usually not a problem after the contract or other document authorizing the project has been
approved.

12. The Project charter is created by:

(a) The project manager


(b) The sponsor
(c) The Vice President over a functional management group
(d) The customer

117 | P a g e
13. The project scope statement furnishes the basis for:

(a) Clearly defined acceptance criteria


(b) Provides links to the clients functional management groups
(c) Allowing the project to move to the next phase
(d) A way to provide updated information to the accounting department

14. The Requirements that describe features, functions and characteristics of the product, service,
or result that will meet the business and stakeholders requirements is known as:

(a) Solution Requirements


(b) Project Requirements
(c) Transition Requirements
(d) Quality Requirements

15. What is the term used for the processes required to ensure that the project include all the
work required, and only the work required, to complete the work successfully.

(a) Project Scope Management


(b) Bill of Materials
(c) Work Breakdown Structure
(d) None of the above

118 | P a g e
16. Project Scope Management has following processes:
a. Collect Requirements
b. Plan Scope management
c. Define Scope
d. Create WBS
Arrange them in the correct sequence.

(a) a-b-c-d
(b) c-d-b-a
(c) b-a-c-d
(d) a-c-b-d

17. What is an Issue?

119 | P a g e
18. What is a Deliverable?

19. A project manager has just been assigned to a new project and has been given the completed
project scope statement. The FIRST thing the project manager must do is:

(a) Create a project plan using the WBS


(b) Confirm that all the stakeholders have had input to the scope of work
(c) Form a team to create the procurement plan
(d) Create a network diagram

120 | P a g e
20. How does scope creep happen?

121 | P a g e
Task 1 – Project Scope Management
Assuming your organization was awarded the following tender:

ATM ID: NAA RFT 20xx/1058


Agency: National Archives of Australia
Category: 81110000 - Computer services
Close Date & Time: 15-Aug-20xx 2:00 pm (ACT Local Time)

Publish Date: 15-Jul-20xx


Location: ACT Canberra
ATM Type: Request for Tender
APP Reference: NAA20XX-1
Multi Agency Access: No
Panel Arrangement: No
Description:

A service provider is being sought for the technical upgrade of the Archives’ website Destination:
Australia. In order to ensure the best value for money and optimal functionality (for the website and
related exhibition interactive) going forward, it is necessary for the website to be transferred from a
proprietary CMS to a commonly available CMS (including, but not limited to, an Open Source CMS).

The website will enable the National Archives of Australia to collect user contributed data about the
photographic collection featured on the site. The interface must be modern, engaging and user-
friendly, designed to meet the needs of people of all ages, and differing levels of computer and
English literacy. The website must interact successfully with an exhibition interactive via an existing
API. There is an option for hosting, maintenance and support services to be provided from contract
execution until 31 December 2019.

Timeframe for Delivery: November/December 20XX with a possible extension of up to 3 years for
hosting and maintenance.

The Requirement
The National Archives of Australia (Archives) (the Customer) is responsible under the Archives Act
1983 (Cth) for the preservation and storage of Commonwealth records, including the archival
resources of the Commonwealth.

This procurement request relates to the website redevelopment and hosting and maintenance
services for website Destination: Australia. The current website is located at
https://www.destinationaustralia.gov.au

The photographs showcased on this website are part of the Immigration Photographic Archive
(Series A12111). This collection comprises more than 22,000 black-and-white and colour
photographs taken by government photographers between 1946 and 1999 to record the arrival and
settlement of migrants in Australia after World War II.

122 | P a g e
The photographs were used in newspapers, magazines, posters, brochures and displays to promote
Australia as a prosperous welcoming nation to potential migrants and to reassure the Australian
public that new migrants would readily settle into the Australian way of life.

In 2014, Destination: Australia was upgraded to encourage users to upload their own photographs
and stories to share their migrant experience, further adding rich personal context to the Archives’
collection. These ‘Feature Stories’ are also available (via an API) in a ‘Globe’ interactive in the
Archives’ exhibition A Ticket to Paradise?, which is touring nationally from April 2016 to September
2019.

Required
 Redevelopment of existing website Destination: Australia
 Software to be either open source or common-use proprietary Content Management System
(CMS)
 One website prototype round, with testing and feedback
 Website testing including content review
 Final revisions
 Final testing and bug fixes
 Website handover
 Final documentation including website style guides, master templates, admin user
guidelines, technical specifications. This must be written in English with clear instructions for
non-technical experts to operate the CMS.

Optional
 External hosting and ongoing support with a service level agreement (3 years).
 Updates and post implementation changes in response to user feedback

Required deliverables
API compatibility
 The website must continue to work with the pre-existing API linking the content with an
exhibition interactive
 The administrator account to the Destination: Australia CMS must have a check box function
that allows the administrator to select which feature stories will be published through the
API to the exhibition interactive.
 The API must be able to draw all user-added content in the selected feature stories,
including photographs, through to the linked exhibition interactive.
 The website will support sourcing and storing its data from the Archives’ API, according to
API calls provided by the Archives, to ensure valid, up to date data is displayed on the
website.
 The website must successfully GET, POST and PUT and DELETE data using the API within
agreed timeframes.
 Data from the API contains a mix of official records and user generated content
 API compatibility and function must be maintained at all times until December 2019
 The successful supplier will be provided with further documentation on the API.

123 | P a g e
Accessibility/compatibility
 All elements of the solution must comply with the relevant Australian Government
mandatory criteria including meeting Web Content Accessibility Guidelines (WCAG) 2.0 – to
Level AA. Refer to the Australian Government Digital Transformation Office website for more
information – https://www.dto.gov.au/standard/design-guides/
 Any online forms should include identifying mandatory fields, error validation and error
suggestion on input fields (e.g. include @ for email addresses), as per the WCAG 2.0 Level
AA.
 All elements of the solution must display consistently across popular Windows, Macintosh
and Linux browsers including Internet Explorer (V9 up), Firefox, Chrome, Safari and Opera.
 Code to ensure ease of use and accessibility from desktop, tablet and smart phone / mobile
platforms using responsive interface design.

Privacy, security and intellectual property


 Data captured in online forms should reflect the Australian Privacy Principles (which unify
the National Privacy Principals and the Information Privacy Principles) and security
obligations of (ASD). Including any updates to how data should be stored according to the
Australian Privacy Principles or security obligations.
 Website security appropriate to support administration module, members’ pages, API
developer key hidden and enables encryption of stored data including indexes and
registered user’s personal details e.g. email address.

Hosting
 The website application must be built to be hosted externally to the Archives’ IT
infrastructure taking into account data sovereignty, data protection controls (see the
Australian Government Protective Security Policy Framework (PSPF) and Information
Security Manual) and compliance with the Privacy Act.
 Please see ‘Optional Deliverables’ for information on the optional hosting component of this
procurement process.

Aesthetic design
 The aesthetic design of the website must be maintained for the upgraded website.
 Style guides and other necessary components will be provided to the successful Supplier.

Content Management System


 The website must support formats to enable crowd sourced data and display of collection
data including images.
 The solution must provide an easy way for administrators to view and record user-generated
activity across the site from within the administration CMS.
 The website’s supporting CMS or web application must have both a design and source
interface enabling recognition of user contributed data and has the ability to manage full
user administration and content moderation in-house. This must include tasks such as
updating all content (including descriptions on collection photographs), monitoring and
moderating user-generated data and where necessary, blocking, removing, editing and/or
extracting user-generated data.
 Administration module must be secure
 Administration page displays name (as well as screen ID) of contributing users

124 | P a g e
 The solution must support Google Analytics for website visitor statistics and pre-scripted
database reports for listing and exporting all user generated content.
 The website must comply with records management requirements to enable the website to
be archived with user-generated data extracted (e.g. XML, CSV format and image formats)
with relevant references for future re-purposing.

Email notifications to administrator


 Email notification to be sent to destinationaustralia@naa.gov.au when a user adds a
comment, tag, person, location to a collection photograph, or adds a feature story.
Notifications should include a hyperlink to the new content in the CMS administrator
account.
 Email notification to be sent to destinationaustralia@naa.gov.au when a user reports
comments or other content. Notifications must include a direct hyperlink to the reported
content.

Public user login


 Website users have the option of browsing and searching the website without registration.
Anyone wishing to input data to the website must register and login with a unique email
address and passphrase.
 Existing usernames and passwords must carry over to the redeveloped site
 Profile must include an online form for users to contact Archives to remove or edit their
user-added content
 Optional: ability for the user to ‘link’ together multiple stories that they have contributed by
the user, or to allow sorting by tag with user name. The published feature story page would
display a link to take viewers to the related stories.

Navigation
 Website navigation must align with pre-existing information architecture for Destination:
Australia.
 Breadcrumbs must be added to the top of each page to enhance user navigation

Search function
 Ability to query search and return search results, this will be supported through the API calls,
and the interface will need to be configured to return merged search requirements and
apply search parameters (e.g. filters) for the Discovering Anzacs interface.
 Required: free text feature stories and comments contributed by users must be posted back
to the API to become searchable on Destination: Australia.
 User-added tags on stories must be posted back through the API to become searchable.
 User-added locations on stories must be searchable and clickable to sort stories by place
 Adding terms to the search parameters should refine the search (it currently expands the
result field)
 The website must include all images within the A12111 series/collection, and search results
must display all relevant images. Check that search picks up all photographs in collection (or
that Destination: Australia captures all images in A12111) – e.g. searching for “Petrus
Mouwmans” does not give a result, although it is listed in RecordSearch: A12111,
1/1963/14/9.
 Results distinguish between feature stories, collection items and user added photographs.

125 | P a g e
 Results able to be sorted by category (feature story, collection item) or by date range
(earliest to latest or vice versa)
 Image title to appear at the top of the results display (currently “view this photograph”).
 Hit highlighting - the search interface will support search term (eg. keyword, name) hit
highlighting using bold or similar

Updates/fixes to ‘add your story’ form (see Attachment B for images of changes)
 All free text fields must allow users to copy and paste text from other programs.
 The fields ‘Year’, ‘Country of origin’, ‘Theme’ and ‘Photos’ (at least one) must be compulsory

Adding images
 ‘Add photos’ must be moved to location above ‘Add Your Story’
 When adding an image from the website, the citation and image caption must also be
imported. The citation (e.g. NAA: A12111, 2/1969/4A/18) must be locked in, with the option
for the user to personalise the caption.
 When adding an image from the website, users must be able to search by collection control
symbols and non-consecutive key words.
 When adding an image from the website, user has the ability to refine the search using date
range.
 When adding an image from the website, clicking ‘enter’ after typing keyword must initiate
the search (currently takes user to blank error page).
 ‘Add image from website’ search must return all results available through Destination:
Australia.
 The website must perform checks to ensure the user is uploading an accepted size and
format (e.g. png, jpeg) and provide error messages where limits are exceeded.
 Optional: add a new function to allow users to select from their ‘Favourite’ images to add to
their story.
 Optional: users able to crop images before they upload.

Add your story


 ‘Add your story’ text field must allow simple formatting: paragraph breaks, italics.
 Must display Latin diacritics (accents e.g. acute é, grave è, circonflex ê, caron č; dots e.g.
diaeresis ë; cedilla ç, ogonek ą).

Feature story publishing process


 Selecting ‘Preview’ must save a copy that allows for the user to return and edit content. This
draft copy must not be publicly available at this stage.
 Selecting ‘Save your story’ (on contribution form page) or ‘Save and submit’ (on preview
page) submits the story to the CMS and publishes the feature story on the live website
 Stories are automatically published on submission.

Feature story display page (front end)


 On published feature stories, viewers must be able to click on categories (year, country, tags,
locations) to bring up a list of any other stories/images with the same user-added metadata
 Must display Latin diacritics (accents e.g. acute é, grave è, circonflex ê, caron č; dots e.g.
diaeresis ë; cedilla ç, ogonek ą)
 Must display simple formatting: line breaks, italics

126 | P a g e
 Images must be able to open for larger display in a lightbox, with accompanying caption
 Optional: where a user has added a photograph from the website, the image on the
published feature story page links back to the image display page for the particular record
(i.e. with metadata, comments, tags etc).
 Optional: if users add data to ‘location’, map with tagged locations should be shown on
published feature story page.

Record display page (front end)


 Required: create ‘order record’ button that takes the user through to PhotoSearch result for
that image and the associated ‘ordering images’ text box.

Home page
 Optional: preview of ‘Feature stories’ displays feature stories at random

Testing
 The Supplier must outline the project plan and team roles and the testing strategy and plan.
It should also include any handover files and documentation to be provided for
implementation.
 Extensive testing will be required prior to the website launch. This includes iterative testing
during development, implementation of changes and subsequent re-testing.
 On implementation and handover the Destination: Australia website should be fully
functional and populated with relevant content and data. As part of the website handover,
training sessions and support documentation for nominated administrators will also be
required.
 Testing must include success of API calls to/from the Destination: Australia website for
creation, deletion, updates and retrieval of data in conjunction A Ticket to Paradise? ‘Globe’
interactive.
 The National Archives will determine when the website is ready to be launched and the
date. However, the supplier must be able to meet the nominal launch date of 25 October
2016.

Acknowledgements
The banner (visible on all pages) must include:

 Destination: Australia web tile


 Multi-agency logo for the National Archives of Australia and the Department of Immigration
and Border Protection (to be provided by the Customer)
 The following tagline:
o ‘The National Archives acknowledges the support of the Department of Immigration
and Border Protection for the Destination: Australia website’, with the text
‘Department of Immigration and Border Protection’ hyperlinked to the website
https://www.border.gov.au/

Progress meetings and reports

The successful Supplier will be required to:


 Attend the project kick-off meeting (face-to-face / teleconference)
 Attend regular updates at an agreed time and day, at least fortnightly.

127 | P a g e
 Attend scheduled project meetings to report at key milestones or deliverables throughout
the project.
 Communicate any issues which may impact agreed project tolerances as they occur
 Attend project wrap-up meeting with final deliverables and website handover including
report/documentation.
 Work collaboratively with National Archives staff and Suppliers to meet expectations and
resolve issues.

Optional
 Should the option of host services be agreed to by the Customer, the Supplier must attend
ongoing support meetings or maintain regular communication as required, up until the end
of the contract?

Project Management Requirements


 The Archives will nominate a Project Manager who will be responsible for liaison with the
successful supplier in relation to management of the contract and overall service delivery.
 Potential Suppliers must specify all staff and subcontractors proposed to complete the work.
 The successful Supplier will be required to nominate a Project Manager as the primary point
of contact for the Archives. This person will be responsible for the management of the
contract as a whole and for liaison with the Archives’ Project Manager.

After delivery
The Supplier must commit to providing defect resolution in the post-launch period, up to 30 April
20xx, in response to Archives user testing and feedback. In this period the Supplier must complete
full internal testing and bug fixes before any solution release for publishing.

Optional deliverables

Hosting and maintenance


The Potential Supplier should provide a response for an optional service level agreement, to host the
website externally to the Archives’ infrastructure, provide ongoing maintenance and support until 31
December 2019.
 The website application must be hosted externally to the Archives’ IT infrastructure taking
into account data sovereignty, data protection controls (see the Australian Government
Protective Security Policy Framework (PSPF) and Information Security Manual) and
compliance with the Privacy Act.
 Quality of service requirement in order to maintain its effectiveness; available 99% of up
time annually and has appropriate back-up (with equal features to meet above-mentioned
data security and privacy requirements) scalability options and recovery processes.
 Response time for issues to be negotiated and confirmed with the successful Supplier.

Capability to function with future API’s


Potential to link with National Archives’ and external sources’ collections and data, via API’s that
may be developed in the future.

128 | P a g e
Complete the following:

Conduct project authorisation activities

Outline the project authorisation procedure for your project:

 What the governance arrangements are in regards to project delegation?


 What are the critical review points during the project?
 Who is the appropriate authorising authority/s?
 What will they expect to see at the review points?
<<<< INSERT ANSWER HERE >>>>

Define project scope

Using your Project Charter as the basis of the project, use the template below to define in detail the
Scope Statement and the Scope Management Plan for the project. This should be extensive
including both product and project scope and give a shared understanding of the desired project
outcomes and how the project will be delivered.

Project Scope Statement:

Background information about the Project


<Insert the name of the project, background information about the company and how the Project
was triggered and its intended outcome.>

<Insert the benefits to be achieved from the project and the title of the person responsible for
tracking and measuring the achievement of the benefits.>

Scope Definition
The scope of the plan covers the following aspects:

 <in scope>

The scope of the plan does not cover the following aspects:

 <out of scope>

Objectives and Success Criteria

From this plan the key objectives and success criteria are to:

129 | P a g e
 <insert objectives and success criteria – they must be SMART>

Deliverables

 <insert deliverables>

Acceptance Criteria

 <insert the conditions required to be met before the deliverables are accepted>

Constraints

List of all known constraints:

 <insert constraints>

Assumptions

The following assumptions have been made:

 <insert assumptions>

Dependencies

 <insert dependencies>

Outstanding Issues

 <insert outstanding issues for Project Manager resolution>

The proposed project methodology consists of <X> separate phases, as described below:

 <insert phase number and names>

Work Breakdown Structure

 < Insert diagram of the WBS>

Project Scope Management Plan:

130 | P a g e
Roles and responsibilities:

<Who has authority and responsibility for scope management?>

<List the stakeholders who are responsible for collecting or contributing to scope requirements and
confirming scope>

Major milestones

<What are the milestone dates for: collection of scope requirements, detailed definition of scope
and approval of the scope baseline? >

How is scope defined and documented?

<Describe how scope is defined and documented>

Scope Change Control Process


< Describe the process to change scope including the title of the person/s responsible for evaluating
and approving scope change. You may include a diagram for clarity>.

Scope Validation
<Describe how the scope will be validated including the title of the person responsible for scope
validation>.

Scope Acceptance
<Who is responsible for accepting the final project deliverable and approves acceptance of project
scope>

Scope Performance measurement


<Who is responsible for managing scope performance and measurement? When is scope
performance measurement to be done?>

-----------------------------------------------------------------------------------------------------------------------------------

Element 3: Manage project scope control processes

1. List the main factors that could trigger requests for scope change on your project.
<<<< INSERT ANSWER HERE >>>>>

131 | P a g e
2. A stakeholder has requested a change in scope to the project. Fill out the Change Request
Form below (or provide your own template), which shows the impacts to time, cost and
quality. Note: there must be impacts to time and cost as this change request will be referred
to in other following course units.

Change Control Form


Project Name
Requested By: Requested Date:
Change Request <Unique identifier>
Number:
Description of the <A detailed description of the change being requested>
change:

Reason for the change: <The trigger or reason the change is needed>

Alternative solutions: <Any other options>

Impact Assessment Description of impact

Cost <The $ impact of the change – either positive or negative>

Time <The time impact of the change – including number of hours/days and the
knock on impact to the other tasks in the project>

Resources <The resources required or no longer required and the impact to the
project e.g.: resource availability>

132 | P a g e
Quality <The impact to quality of the change>

Impact if scope change


request is not approved
Other

Risk assessment Risk description Impact Likelihood Strategy


<1, 2, ,3, <1, 2, ,3,
4 – see 4 – see
risk risk
register> register>

Immediate Action Required if approved


Authorisation Decision
Approved? Yes □ or No □
Decision by: Date Decision Made:

Authorised by: Date Authorised:

3. Describe step by step how you used the change control procedures provided in Assessment
Task 1 Scope Management Plan to make a decision on this change request.

133 | P a g e
<<<< INSERT ANSWER HERE >>>>>

4. Assume the change request was approved. Describe what you would do to update the
current baselines and communicate the new baselines.
<<<< INSERT ANSWER HERE >>>>>

5. Give an example where you encountered scope creep in your project/s including:
a. The method or tools used to identify that scope creep had occurred.
b. What was the impact of the scope creep?
c. How did you or would you handle this situation?
<<<< INSERT ANSWER HERE >>>>>

134 | P a g e
BSB51415 DIPLOMA OF PROJECT MANAGEMENT
College Copy

Unit Code and Title: BSBPMG511 Manage project scope

Assessment task Due Dates

Assessment 1 Due Date:

Assessment 2 Due Date:

I Student ID acknowledge receiving the

Student Assessment Information Pack, which contains:

o Assessment Due Date Sheet


o Time table /Training Plan
o Lesson Plan
o Student Assessment Information Guide
o Assessment Cover Sheets
o Feedback form
o Student Resource
o Internet Access for online Business Environment Simulation with Login Key or access to college
simulated business documents on internal intranet.

Student Signature:

Date :

135 | P a g e
BSB51415 DIPLOMA OF PROJECT MANAGEMENT
Student Copy

Unit Code and Title: BSBPMG511 Manage project scope

Assessment task Due Dates

Assessment 1 Due Date:

Assessment 2 Due Date:

I Student ID acknowledge receiving the

Student Assessment Information Pack, which contains:

o Assessment Due Date Sheet


o Time table / Training Plan
o Lesson Plan
o Student Assessment Information Guide
o Assessment Cover Sheets
o Feedback form
o Student Resource
o Internet Access for online Business Environment Simulation with Login Key or access to college
simulated business documents on internal intranet.

Student Signature:

Date :

136 | P a g e
ASSESSMENT SUMMARY / COVER SHEET
This form is to be completed by the assessor and used a final record of student competency.
All student submissions including any associated checklists (outlined below) are to be attached to
this cover sheet before placing on the students file. Student results are not to be entered onto the Student
Database unless all relevant paperwork is completed and attached to this form.
Student Name:

Student ID No:

Final Completion Date:

Unit Code: BSBPMG511

Unit Title: Manage project scope

Unit
Assessors Name:
Outcome
C NYC
Result: S = Satisfactory, NYS = Not Yet Satisfactory, NA = Not Assessed
 Knowledge Assessment - Questions and Answers
S | NYS | NA
 Task 1 S | NYS | NA

Is the Learner ready for assessment? Yes No


Has the assessment process been explained? Yes No
Does the Learner understand which evidence is to be collected and
Yes No
how?
Have the Learner’s rights and the appeal system been fully
Yes No
explained?
Have you discussed any special needs to be considered during
Yes No
assessment?
I agree to undertake assessment in the knowledge that information gathered will only be used for
professional development purposes and can only be accessed by my manager and the RTO:
Learner Signature:
Date:
I have received, discussed and accepted my result as mentioned above for
this unit assessment and I am aware about my rights to appeal.
Assessor Signature:
Date:
I declare that I have conducted a fair, valid, reliable and flexible
assessment with this student, and I have provided appropriate feedback.

137 | P a g e
ASSESSMENT COVER SHEET

Unit BSBPMG511 Manage project scope

Course BSB51415 DIPLOMA OF PROJECT MANAGEMENT

Student Name: Student ID:

Group: Date

Title of Assignment: Knowledge Assessment - Questions and Answers

Assessor Name:

This cover sheet must be attached to your assignment.

Declaration:
1. I am aware that penalties exist for plagiarism and unauthorized collusion with other
students.
2. I am aware of the requirements set by my educator with regards to the presentation of
documents and assignments.
3. I have retained a copy of my assignment.

Student Signature:___________________________

Date:________________________________________

138 | P a g e
QUESTION & ANSWER CHECKLIST

S NYS
Learner’s name:

Assessor’s name:

Question Correct ()

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
Feedback to Learner:

Assessor’s Signature:
Date:

139 | P a g e
ASSESSMENT COVER SHEET

Unit BSBPMG511 Manage project scope

Course BSB51415 DIPLOMA OF PROJECT MANAGEMENT

Student Name: Student ID:

Group: Date

Title of
Task 1
Assignment:

Assessor Name:

This cover sheet must be attached to your assignment.

Declaration:
1. I am aware that penalties exist for plagiarism and unauthorized collusion with other
students.
2. I am aware of the requirements set by my educator with regards to the presentation
of documents and assignments.
3. I have retained a copy of my assignment.

Student Signature:___________________________

Date:________________________________________

140 | P a g e
TASK 1 CHECKLIST

S NYS
Learner’s name:

Assessor’s name:

Observation Criteria S NS
Developed and confirmed procedures for project authorisation with an
appropriate authority
Obtained authorisation to expend resources
Confirmed project delegations and authorities in project governance
arrangements
Identified, negotiated and documented project boundaries
Established measurable project benefits, outcomes and outputs
Established a shared understanding of desired project outcomes with
relevant stakeholders
Documented scope management plan
Implemented agreed scope management procedures and processes
Managed impact of scope changes within established time, cost and
quality constraints according to change control procedures
Identified and document scope management issues and recommend
improvements for future projects
Feedback to Learner:

Assessor’s Signature:
Date:

141 | P a g e
Student Feedback Form
Unit BSBPMG511 - Manage project scope
Student Name: Date
Assessor Name:
Please provide us some feedback on your assessment process. Information provided on this form is
used for evaluation of our assessment systems and processes.
This information is confidential and is not released to any external parties without your written
consent. There is no need to sign your name as your feedback is confidential.
Strongly Strongly
Agree
Disagree Agree
I received information about the assessment
1 2 3 4 5
requirements prior to undertaking the tasks
The assessment instructions were clear and easy to
1 2 3 4 5
understand

I understood the purpose of the assessment 1 2 3 4 5

The assessment meet your expectation 1 2 3 4 5


My Assessor was organised and well prepared 1 2 3 4 5

The assessment was Fair, Valid, Flexible and Reliable 1 2 3 4 5

My Assessor's conduct was professional 1 2 3 4 5


The assessment was an accurate reflection of the unit
1 2 3 4 5
requirements
I was comfortable with the outcome of the assessment 1 2 3 4 5

I received feedback about assessments I completed 1 2 3 4 5

Great
The pace of this unit was: Too Slow Too Fast
Pace
Comments:

142 | P a g e

Вам также может понравиться