table of contents · 2018. 6. 12. · 3.2 manage scope changes ... just as vital that there is a...

BSBPMG511 Manage project scope © Australis College Pty Ltd V151215

2

Table of Contents

Unit Overview .............................................................................................................................. 3

1.0 Project authorisation activities ...................................................................................... 4

1.1 Project Authorisation Procedures .......................................................................................... 4

1.2 Authorisation to Expend Resources .................................................................................... 10

1.3 Delegations and Authorities ................................................................................................. 14

2.0 Define project scope ....................................................................................................... 17

2.1 Project Boundaries ................................................................................................................. 18

2.2 Measurable Benefits, Outcomes and Outputs .................................................................. 23

2.3 Establish Understanding of Project Outcomes .................................................................. 27

2.4 Scope-Management Plan ...................................................................................................... 31

3.0 Manage project scope-control process ........................................................................ 43

3.1 Scope-Management Procedures .......................................................................................... 43

3.2 Manage Scope Changes ........................................................................................................ 49

3.3 Identify Scope-management Issues .................................................................................... 52

References .................................................................................................................................. 56


3

Unit Overview

This unit describes the performance outcomes, 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.

This unit applies to those responsible for managing and leading a project in an organisation,

business or as a consultant.

Unit Objectives

On successful completion of this unit, you will be able to:

- Conduct project authorisation activities.

- Define project scope.

- Manage project scope-control process.

Before you get started!

https://www.youtube.com/embed/qxjuo4Vnp6U

This chart gives you an ‘at-a-glance’ view of what happens when scoping a project. You can

download this as a pdf from the resources section.


4

1.0 Project authorisation activities

Module Overview

Formal authorisation should be obtained from key stakeholders prior to starting a new

project. You may be required to complete several actions, e.g. developing a business case to

determine the feasibility of the project, and provide a clear description of the project

objectives and deliverables.

At the end of this module, you will be able to:

- Develop and confirm procedures for project authorisation with an appropriate

authority.

- Obtain authorisation to expend resources.

- Confirm project delegations and authorities in project governance arrangements.

1.1 Project Authorisation Procedures

The Project Charter, created in the initiating phase of the project, is the document issued by

the project sponsor. This document formally authorises a project to start and delegates the

authority to the project manager to enact the project within defined limits of time, cost, risk,

quality and scope. This gives the project a well-defined ‘Start Point’ and clear project

boundaries. Other stakeholders will have their requirements collected, agreed and

incorporated into the project during the planning process.

The sponsor acts as the appropriate authority as they have the legal ability to commit

resources and can delegate the authority to act to the project manager.

The sponsor can be a senior executive, a group of managers, company board, a client or

owner as long as they have the legal authority to commit funds, resources and priorities to

the project.

If you want to build a new kitchen in your house, you sponsor the project and commit the

resources to build it.


5

The Project Charter may have already been completed before the appointment of the project

manager and is used at a number of points throughout the project. It also contains other

information including, the purpose or justification of the project, the initial scope, the

expected benefits, any assumptions or constraints that affect the project, the stakeholder list,

any high level risks or requirements and any project approval requirements.

The Project Charter may be as simple or detailed as needed by the project. A project to run a

conference for 30 attendees for one day will be much smaller and simpler than the one

required to build and run the next Olympic Games. So the project charter can be scaled and

tailored to meet the needs of the project.

The charter may also be called a project brief, scope of work statement, or project overview.

What is required is that the needs (scope) of the project are clearly defined and that it is

sponsored by a person or group that can commit the resources required for the project.

Over the life time of the project the charter will be modified due to changing project

requirements so it is said to be a “living document”.

As changes are introduced to the project, the charter or scope is said to creep or move away

from the original specification. This is normal as situations change or the project’s outcomes

may need to be changed or modified.

It is important that projects remain flexible to accommodate changing circumstances but it is

just as vital that there is a procedure in place to control changes to the scope or charter.

Scope creep is an issue when new requirements are added to a project without assessing the

impacts they will have on other parts of the project, e.g. a change in scope may affect the cost

or the schedule of the project, so the project may fail due to unexpected side effects of the

original change.

Governance

Should describe the accountabilities of each party.

Should detail the name and title of the stakeholders and

those to whom you would report.

Reporting

Requirements

Format of reports, reporting frequency, to whom are they

sent.

Guidelines/Standards

Guidelines, standards or methodologies that will be applied

to manage the project.


6

Project Plan

No matter which Project methodology (PMBOK, Prince2, Agile…) is used, at some stage within

the planning phase, the project needs to formalise what it needs to deliver, at what time, at

what cost, who will do the work, how it will be delivered and how it is approved and the

stakeholders needs to be considered and agreed upon.

This Project Plan can be referred to as the what, who, how and when document and is the

central plan that consolidates all the information about the project and also forms the basis

for monitoring and controlling the project once it commences. PMBoK calls this the ‘project

management plan’.

It is vital to the success of the project that this document is agreed to and signed off by the

Project Sponsor and any key stakeholders. The level of detail required for this process would

be determined in consultation with the Project Sponsor and the relevant stakeholders, it

should also reflect the complexity of the project.

There are many ways organisations choose to plan, prioritise and schedule activities

pertaining to a project and for that matter, the terminology used may also differ among

organisations and project methodologies.

The Project Plan’ is also often referred to as the ‘project schedule’, or ‘schedule of work’.


7

Whatever method or terminology is chosen, the foundation of project planning is to create a

‘work breakdown structure’ (WBS), which makes a project manageable.

This is achieved by breaking down large complicated tasks into smaller more manageable

individual components using a hierarchical structure that allows the project to proceed in a

logical and achievable manner.

This hierarchical structure shows tasks that can be completed independent of other tasks and

which tasks are sequential and need to be done in a specific order. This facilitates planning for

resource allocation, timelines, assignment of responsibilities, and measurement and control

of the project.

Example: If your project is to redecorate a bathroom. The new bath and basin can be put in

at the same time while the painting of the room can only start once the new fixtures, e.g.

shower, bathtub and basin have been installed.

Designing a project summary report

Project plans can be quiet complex and detailed therefore a project summary report should

also be developed.

The purpose of the project summary report is to assist anyone who needs a view of the

breakdown of the project to assist them to issue approvals or authorisations at the

appropriate time within the project. The summary report is distributed to the Project Sponsor

and other appropriate stakeholders and can contain information on the following:

- Report Category.

- Overview / Description.

- Summary of the number of tasks, project costs, or list the critical tasks.

- Current activities for those who may be more directly involved with the tasks in the

project.

- Costs, budgets, and other effective financial reports used in tracking the budget cost of

a project.

- Assignments, the to-do lists for human resources and their assigned tasks.

- Current task progress and information to determine who, if anyone, may have too

many assignments in the available time.

- Workload, the amount of work assigned to a task or per resource, on a weekly basis.


8

Process

To confirm and authorise the Project Plan, schedule a meeting with Project Sponsor and other

relevant stakeholders and review all the project plan deliverables.

Ensure that any changes from the last formal review are documented and agreed on to

finalise the project plan deliverables. The Project Sponsor will formally acknowledge that the

project will proceed and then with other designated stakeholders sign off on the project plan

so that work on the deliverables may begin.

It is important that these formal points of review (milestones) are scheduled into the overall

project because they provide a clear point in time to check that the project objectives still

represent value before committing further resources to the project.

For successful project management, it is critical to confirm these procedures with the

appropriate authority and identify any issues using a structured process. However, it is of

paramount importance to balance the process requirements so as to not outweigh and bog

down the desired outcome. This can be an issue in some organisations, e.g. government

bodies or heavily regulated industries.

The Project teams must keep the project’s desired outcome in mind when applying their time

and efforts to process requirements, e.g. confirming procedures and seeking authorisation,

planning and documentation.

Example: If the project was to open a gold mine, and between the time of the project

initiation and the work required to open the mine started, the price of gold falls dramatically.

Then it may no longer be economical or profitable to commence work on building the mine.

Resources should not then be committed to the project and the project should be shut down.

This type of review provides a go/ no-go decision point after checking the projects current

viability.

The following ‘Confirm Procedures for Project Authorisation’ template can be used as a

Project Summary. This document lists the Project Objective, a summary of the project

proposal, how it is implemented and approvals for what the project has produced.


9

Example Only

Confirm Procedures for Project Authorisation

Project Authorisation Document

Project Number __________

Project Information

Project Name

Sponsor

Project Manager

Submission Date

Submitted By

Client

Project objective

PROPOSAL SUMMARY:

- Background.

- What is proposed?

- Why should the proposal be implemented?

- Update since last approval (if applicable).

How the Project will be Implemented:

- Consultation groups (if any).

- Plan for development phase.

- Plan for delivery phase.

- Risks and Uncertainties.

Approvals

1.

2.

3.


10

1.2 Authorisation to Expend Resources

As previously stated, the Project Charter is the document that is issued by the project sponsor

that formally authorises a project to start and delegates to the project manager with the

authority to enact the project within defined limits. The Charter contains a summary budget

for the expenditure of resources on the project. These resources can include money, use of

equipment and facilities, and human resources.

Monitoring budgets

The establishment, control of and monitoring of the resources necessary to deliver the project

is one of the most crucial elements for the success of the project.

The process for this is first established in the project initiation stage, then it is revisited,

reviewed and if necessary updated in the scoping phase of the planning stage.

When determining budgets for different aspects of the project it is critical to allow for

contingencies during the life time of the project. Each deliverable is usually assigned a

tolerance as defined by a plus or minus (+/-) range for items including time, quality, work

hours or cost.

Example: If the project was to create a new MP3 player, the first prototype may need to be

produced in 30 weeks +/- 4 weeks and at a cost of $250,000 +/- $25,000.

Tolerance allows the project management team to continue with the project without having to

go back to the sponsor for every issue.

Similar to the outlines for seeking authorisation, financial matters, e.g. expending resources

would be taken from the project charter, reviewed and updated if required and then included

as part of your project plan.


11

So when meeting with the Project Sponsor(s) and other relevant stakeholders for budgetary

matters, which may involve different stakeholders compared to the meeting for authorisation

of the project, the following need to be considered for the Project Financial Management:

- Planning.

- Budgeting.

- Accounting.

- Financial reporting.

- Internal control.

- Auditing.

- Procurement of goods and services.

- Disbursement of payments.

- Achieving the project’s financial objectives.

Business Case

The Business Case document, developed in the Initiating Phase, contains all the information

from a business stand point about why the project is or is not worth the required resource

investment. It defines the business justification for the project.

The Business Case also contains any cost-benefit analysis for the project. This analysis should

provide sufficient financial detail to seek approval to proceed.


12

Implement Steps Monitor Actions

Communicate what needs to be

done and by what deadline.

Assign the work by breaking down the tasks into

smaller and more manageable pieces.

Consider a variety of expense

alternatives.

Develop and agree on the project budget plan.

Choose suppliers and contracts

for goods or services.

Base decisions on either company policy or what is

best to deliver to meet project timelines as well as

considering price.

Prepare timeline and sequence

of activities.

Use a prepared schedule to manage the overall

project to ensure its timely completion.

Outline clear expectations for

the project team and other

human resources.

Project teams are only temporary so select team

members based on their technical skills.

Their individual and collective performance will

impact on the financial resources and outcome.

Identify as many potential

financial risks as applies.

Manage or minimise each risk, be it large or small.

Routinely monitor and re-evaluate significant risks as

the project continues.

Keep all project stakeholders

informed and up-to-date.

Issue performance reports, status changes, and other

project documents.

Forecasting costs. Delivering on time and on budget is the expectation.

Include extra funds in the budget as required.

Financial Risk Management

The financial risk to the sponsor and for the project needs to be identified, understood,

documented and deemed not to be too excessive to prevent the start of a project.


13

Before any approvals can be made, the following financial aspects of the project need to be

addressed:

- Risk assessment.

- Is there risk mitigation (Contingency?).

- The real cost of risk.

- Cost analysis.

- Any comparisons to meet your particular requirements.

- Capital costs.

- Funding source (internal or external).

Financial Risk is only one aspect of risk that can affect a project.

Other financial details for the project that would likely need clarification prior to any approvals

include:

- Cost benefit analysis - is the project worth the costs?

- Political economic analysis - is it possible for the project to succeed?

- Cash flow - can we afford to start and run the project?

Approvals

Typically, the project sponsor approves and endorses the business case after all the due

diligence has been completed. The business case needs to explain why the project is needed,

and should clearly define what will be delivered, at what cost and timeframe and how it is to

be financed.

The Business Case is best supported by information that gives confidence in the ability of the

project to be delivered as proposed.

The Authorisation to expend resources may also require an independent review of the full

business case against the proposal presented to see if the proposed project solution matches

the business need(s) of the sponsor and is value for money.

This independent review is typical for a Government Tender project above a certain dollar

value and provides an assurance that the Project Plan meets the requirements as set out in

the Business Case.


14

Overall the questions that must be asked and answered before any approvals are given

include:

- Do any relevant stakeholder have any documented reservations about the financial

aspects of the project?

- Is the project appropriate for the uses of the requested resource, taking into account

the outcomes, costs, risks and alternatives?

1.3 Delegations and Authorities

Part of Project governance is help to determine ‘who is responsible for what and to what

degree’ and it is often defined in a roles and responsibility matrix. This matrix will include the

Position, who is filling it, the area of the project it is associated with and the level of authority.

Example: a construction manager, Jillian Jones, has a discretionary budget of $5,000 per

month for extra wages if needed, due to the use of overtime to ensure that the time scale of

construction remains on schedule.

The project manager creates this matrix in conjunction with the project sponsor and if the

company has one, guidance from the Project Management Office (PMO).

The PMO is usually a department within a business which defines the corporate project

management standards, methodologies used and governance. It also managers the

portfolios and programmes of all projects within the corporation.

Every project needs clear lines of authority and delegation of responsibility so that the efforts

within the project can remain focussed on creating, testing and delivering the project outputs.

Authority to act is assigned on a project by project basis and is removed at the end of the

project. Project delegations and authorities may include:

- Degree of line authority with the project team, it defines who you manage and who

manages you.

- Finance expenditure limits, how much of the project money you can spend.

- Procurement delegations, who you can buy from, what you can buy and how much

you can spend, including required quality levels of purchased items.

- Required organisational procedures, e.g. what reports you need to write, where the

information for the report comes from and who you send the reports to.


15

The delegating authority may be the project sponsor, the customer or client, the funding

body, the company board or from a management representative.

Once a project has been approved and started, the project manager may have been given

authority to assign work, budgets, time scales and so on for that specific project only.

Example: Steve has been assigned as the project manager for the development of a new

electronic medical instrument. His boss Rebecca has the most expertise in testing and

certifying new instruments.

For the duration of the project, Steve has the authority to schedule Rebecca’s time and

provide instructions for when she should be available for certification purposes. When the

project is completed this authority is removed.

Project delegations may be relevant to a ‘position’ rather than an individual. It is good

business practice to establish a delegation of authority policy or similar guideline and as

previously stated, it is often expressed in a roles and responsibility matrix.

Objective of Project Governance

As stated earlier, one of the objectives of project governance is to assist in defining the roles

and responsibilities of the people involved in a project. Other objectives of include:

- Accountability - To identify and define the level of accountability those individuals or

stakeholders who are ultimately responsible for the completion of a specific task or

tasks within the project. Projects are more likely to succeed when people know what

part of the project they are responsible for and have clear understanding of how they

are to achieve it. Ideally, there should only be one person responsible for each specific

task within a project.

- Communication and Consultation - Clear channels of communication between

relevant stakeholders to allow for suitable information flow should be defined during

project initiation and updated as required during the project life cycle. The information

on what form of communication, e.g. email, reports, meetings and phone calls,

frequency (how often) and what information is communicated will be contained within

the Communications Management Plan.


16

- Milestones - Are planned points in the scheduled of the Project Plan used for the

review and control of the project. They normally relate to the completion of a phase or

product, they can also be scheduled before the start of any significant activity or

expenditure. The milestones allow for in-depth review of project progress compared

to the schedule, so that any significant variations to cost, timeframes or deliverables

can be documented and plans to remedy this situation can be made. The milestones

act as a decision gate or point of control where the question “Is this project worth

continuing?” is asked and answered.

- Confirm Project Delegations and Authorities - Establish a clear and effective

governance structure based on the Project Sponsor’s & PMO’s standards. Ensure the

correct management structure, roles and responsibilities are established and

sustained throughout the project. Monitor the lines of communication, especially for

those who have direct access to individuals with particular challenges or areas of

authority.


17

2.0 Define project scope

Module Overview

Determining Scope is of fundamental importance to project success. It involves using the

Project Initiation Documentation, (Project Charter, Stakeholder Register and the Project

Management Plan) and getting the required information to specify the features the product(s)

need have in order to meet the stakeholder’s requirements.


- Identify, negotiate and document project boundaries.

- Establish measurable project benefits, outcomes and outputs.

- Establish a shared understanding of the desired project outcomes with relevant

stakeholders.

- Document the scope-management plan.

What is Scope?

Scope is the detailed description of all the products, services and results to be delivered by a

project. It can also define what is not to be produced by the project. Scope defines the

boundaries of the project.

Example: A company starts a project to deliver a new website to promote their products. A

second project is already under way within the company to produce a new company logo. The

new website needs to use the new logo but does not have to create it, so for the website

project, the logo would be considered ‘out of scope’ even though it has to use the new logo.

For the logo project, the logo needs to be developed and delivered, therefore the logo is

considered to be ‘in scope’ for that project.

Within project management, scope has two distinct meanings:

Project Scope - The work that needs to be successfully completed to deliver the desired

outcomes of the project. These outcomes can be products, services or results.

Product Scope - The attributes of a product, service or result. Attributes make up what the

product actually is, e.g. its size, shape, colour, function, or quality.

It is essential to properly scope the project so that all stakeholders have the same clear vision

of what is required to be produced. Considerable effort should take place to thoroughly scope

the project and as soon as possible. This will increase the likelihood of project success.


18

In practice, a lack of proper scope definition is one of the main reasons for project failure.

That is why it is so important to spend the time and effort to get it right as soon as possible.

An example of the significant impacts of poor scope definition is the Queensland Heath

payroll system project.

Queensland’s Auditor-General has published a landmark report into the disastrous payroll

systems overhaul at Queensland Health, broadly lambasting the project’s governance

structures and pointing out that all concerned — including the prime contractor— significantly

underestimated the necessary scope of the project.

The project aimed to replace Queensland Health’s ageing LATTICE payroll system, and was

been dubbed the Continuity Project —cost the state $101.96 million in total since its

inception, according to a report published by Queensland Auditor-General Glenn Poole.

The contractor had initially prepared a statement of scope for the replacement of the project,

providing an estimate of $6.13 million to replace the previous LATTICE system. The

assumption at the time was that the company would be able to provide a ‘like for like’

replacement system, using the Queensland Department of Housing’s existing SAP

implementation with very little customisation.

In August 2013, the Chesterman report stated that, “The $6.19m contract blew out and will

ultimately cost Queensland taxpayers an estimated $1.2 billion.”

https://www.youtube.com/embed/DuthRT6j6i4

2.1 Project Boundaries

The limit of the project boundary is from the point in time where the project is formally

authorised by its sponsor through to its completion.

Within the project boundaries is what the project needs to achieve to be successful and allows

the various stakeholders to see how their expectations and requirements can be achieved.


19

The boundaries set limits on what is ‘in’ and ‘out’ of scope for the project.

These boundaries are usually set in the Project Scope Statement which describes the entire

scope of the project including project and product scope.

It describes, in detail, the project’s deliverables and the work required to create those

deliverables to the product specification. It will also contain any assumptions or constraints

on the project and any specific inclusions and exclusions that can help manage stakeholder

expectations about what is or is not possible within the project.


20

The following table describes the various project boundaries and how to manage them.

Boundaries Identify Negotiate Document

Assumptions

Factors that we

believe to be true.

Assumptions add

risk to a project

since it is possible

that they will turn

out to be false.

It is important to

document and

analyse them.

Constraints

Constraints can

limit the solution

based upon the

current

organisational

status.

They usually focus

on the available

time, money and

resources for a

project.

Any assumptions

about a specific

project constraint

should be

documented.

Exclusions

Identify what is

excluded from the

project by explicitly

stating what is out

of scope.

Project exclusions

are those things

that exist outside

of the project

boundaries.

Ensure that all

items that are not

within the project

boundaries are

described here.

Inclusions

What is deemed to

be included in the

scope of the

project.

Essentially those

items appearing in

the scope and are

clear and

unambiguous.

Documenting

specific inclusions

provides the

‘boundaries’ for the

project scope.

Principal work

activities

Convert the work

breakdown

structure (WBS)

into a project

activity list.

This involves

working out the

relationships

between activities

and scheduling,

starting dates and

durations for each

activity.

This shows exactly

what you have to

do to create each

deliverable of your

WBS.


21

Project Boundary Limits

When determining the limit of the boundaries of a project, various project parameters are

considered including:

- How much money, time, human and technical resources are available?

- What risks there are, including legislative considerations?

- What are the procurement and reporting requirements?

Working through these parameters will provide a clear direction and a definite scope of work

that will enable better stakeholder engagement. This allows for a definitive Work Breakdown

Structure (WBS) to be created. This scope document, joined with a clear change management

process, will increase the likelihood of project success.

The process described above is the Scope Management Plan. The Scope Management Plan

takes in all the processes used to ensure that the project includes all the work required, and

only the work required, to successfully complete the project.

This process defines the boundaries of the project scope and also defines how the scope will

be defined, verified, controlled and how the work breakdown structure will be created.

A scope management plan details those items used to manage the project scope only, and no

other aspect of the project.

As previously stated, it is important that the Project Scope is clearly defined, one of the major

causes of project failure is Scope Creep.

Scope creep is the process when new requirements are added to the scope of the project

(and therefore increases what the project has to deliver) without any assessment of the

impact of those additions on the other parts of the project, e.g. the budget, delivery schedule,

quality or risk.

Scope creep can be caused by having to change product outcomes due to poor definition of

requirements during early development, or by adding new products or features that were not

included in the initial planning.

It is vital that a project is scoped correctly and a procedure is in place for controlled change

management of the scope during the project lifetime.


22

Example: You run a landscaping business and you have successfully won the contract for a

new Shopping Centre. The original contract asks for the construction of 7 flower beds, 2 water

fountains with plumbing, purchase and placement of 17 palm trees and the laying of turf to

cover all remaining bare ground.

1 week before the scheduled end of the project, the Shopping Centre construction manager

agrees that all work is on track except for the lack of flowers in the newly constructed flower

beds. There was no requirement for flowers in the original contract but there was an

undefined (in the scope) expectation from the Shopping Centre construction manager that

the flowers were part of the project. If the landscaper agrees to buy and plant the flowers at

no extra cost, scope creep has occurred. It was not in the scope, it has not been paid for but it

has been included.

Scope creep usually occurs due to trying to satisfy the customer request for a change, poor

project scoping, inadequate change control procedures or poor communication between

parties.

Effective Scope Management is a key factor in a projects success. Scope is one of the triple

constraints of a project along with Time and Cost. These three (3) constants directly impact

each other and Quality within a project.


23

The above diagram represents the relation Scope has with Time, Cost and Quality. It is known

as the Iron Triangle of project management as it forms an equilateral (all 3 sides the same

length) triangle – if you increase the quality of a project’s Scope, Cost and Time may also

increase. If you Decrease the Cost of a project, then the quality will probably be reduced

which will reduce the time and also the overall project scope.

So no matter which constraint is changed, the other two also change, so the shape of the

triangle does not change only its size.

2.2 Measurable Benefits, Outcomes and Outputs

A benefit is the quantifiable and desirable business outcome of a project. A project needs to

control, verify and report on when expected benefits can be realised.

Example: A project produces a new car. The car is not the business benefit, the sale of the car

to increase company profits by 8.5% is the benefit.

Projects are only temporary endeavours created to produce a specific product, service or

result and are normally closed, even if successful, before all benefits are realised.

It is important that the expected benefits are base lined in the initiating phase so that they

can be monitored during and after the project lifetime.

This allows the project manager to assess the current expected benefits verses the planned

benefits and take corrective action as required. This benefit baseline is also used to see if the

project still represents value for money to the sponsor – if the expected benefits no longer

represent value, the project should be shut down.

Example: A Bookshop wants to install an online ordering system to increase the number of

books sold (increase profit), provide service to customer requests (increased service and

customer satisfaction) and to reduce the number of phone orders so that the staff can be

either reassigned or reduced in number (reduction in cost).

None of these four (4) benefits are realised until after the project has delivered all of its

products and has had the worked signed off and has therefore been closed.


24

Benefits management

Once the benefits have been identified and quantified there is a need to develop a system or

a process that ensures as much as possible that your project delivers the desired benefits.

This process allows for the base lining of benefits to provide a comparison point between

where the project is, compared to where it needs to be.

This is why all benefits need to be real and quantifiable and are said to be a tangible benefit.

All benefits need to be quantified and not just the dollar value benefits (7% increase in profit)

but also benefits like customer satisfaction (increase 15%) and community good will (9%

decrease in complaints).

The expected benefit is the driving force behind all projects and forms part of the business

case and justification for the project. Even if the project is a requirement for compliance to

government legislation and earns no new revenue or reduction in costs, the benefit is that the

government does not impose fines or close your business.

To put it another way, benefits are the measurable results of the outputs and outcomes of a

project.

Example: A company decides to make a new can opener (the output), it is believed to be

superior to all other products on the market (the outcome) and so a prediction of an increase

of 12% of market share (benefit) which will lead to an increase in profit by 17% (benefit). The

project can then be assessed for success or failure based on the two measurable benefits

(market share and profit).

The objective of a project is what it is aiming to achieve. The output is what is actually

delivered, the outcome is what the organisation gains from the output and the benefit is the

measurable gain for the sponsor.


25

To use the benefits management process, you can set up a table of questions and

answers, such as:

Benefit management Your comments

Why are you or the organisation doing

this?

What objective/s will this project achieve

in meeting the “value for the

organisation?”

Have you defined all of the benefits?

Have you justified the time and resource

expense in achieving the benefits within

the project?

How do you measure the benefits

through the planned deliverables and

the project objectives?

Are the benefits in fact still relevant or in

need of further review?

Following the answers to these questions, you would then need to go a step further:

Extra Step Your Actions

Benefit cost analysis.

Scoping the benefit.

Quality management.

Stakeholder engagement.

Risk management assessment.


26

It is important to keep in mind that there is a difference between outputs, outcomes and a

benefit.

The objective of a project is what it is aiming to achieve. The output is what is actually

delivered, the outcome is what the organisation gains from the output and the benefit is the

measurable gain from the outcome.

Benefit management is a process to ensure that the project delivers the benefits as stated in

the Business Case. From a business point of view, it is much more important to deliver the

project benefits as opposed to just ensuring your project is completed within a specific

timeframe or cost, however for a project to be successful it must deliver the benefits within

the constraints of time, cost and quality.

This process can help to secure project deliverables that provide value Remember, not all

benefits can be measured in a dollar amount but they still need to be identified and

quantified, e.g. the good will generated by participating with charities or been involved in

community works.

Projects do not always achieve the outcomes and therefore do not achieve the benefits

planned in the business case or proposal. Many projects make the mistake of jumping from

the project proposal to trying to produce the outcomes and benefits, without considering the

intermediate steps, e.g. stringent scoping with stakeholders and adequately defining the work

required to achieve the desired outcomes (Work Breakdown Structure).

Never assume that outcomes and benefits will automatically occur when the project is

complete. All work within the project should lead to a desired outcome, if it does not, then it is

important to understand why it’s being done.

It is the project manager’s responsibility, on behalf of the sponsor, to ensure that the project

stays focussed on achieving the specified outcomes within set time, quality and cost

constraints.


27

Consider

When considering a project, it is beneficial to identify all outputs, outcomes and benefits to:

- Highlight all the project initiatives.

- Detail any contribution they make toward identified outcomes.

- Identify, document and specify all the intermediate steps that are required to produce

the final outcomes.

- Identify and document all expected benefits to ensure that the benefits justify the

continuation of the project.

Reminder, as stated above not all benefits can have a dollar value assigned to them, however

all benefits still need to be quantifiable.

2.3 Establish Understanding of Project Outcomes

A stakeholder is any person, group or entity, e.g. a company or association that is affected by

the project. The effect of the project on the stakeholder can be either positive or negative.

Different stakeholders can have differing levels of impact on the project so they need to be

identified and categorised so it is known which part of the project they are relevant to and

how important they are to it.

For large projects with a lot of stakeholders this can be a large, complicated task with an

enormous amount of detail collected. This is why a repeatable, systematic approach needs to

be applied to this process to ensure the best decisions can made and that all stakeholders in

the project have the same clear vision of what is required.

For each project there is a need to identify the stakeholders, plan how they are managed, how

they are engaged and how to control that engagement. Not all stakeholders are equally

important to a project or important to all aspects of it therefore the same amount of time and

resources cannot be equally spent on each stakeholder, nor can they be dealt with all at the

same time.

A way with dealing with all the various stakeholders needs to be devised and this process is

called Stakeholder Management. This where the stakeholders are identified, have their

importance to the project recorded and identify what part of the project they will have an

interest with.


28

The purpose of identifying all relevant stakeholders is to create a Stakeholder Register.

Making this register can be an extensive process and will require inputs from the project plan

and the use of various tools and techniques (public notices, advertisement in local media, mail

outs etc.) to find as many stakeholders that is economically possible.

Typically, stakeholders for a project may include clients, decision makers, internal and

external parties, sponsors, team members and interest groups.

It is vital for the stakeholders to develop a common understanding of the project's goals and

outcomes to avoid the risk of not obtaining a clear consensus, ownership, or in the end,

responsibility for project outcomes. Consensus does not mean that all stakeholders have an

equal say in how the project proceeds but their input is sort and included.

This is why project managers require negotiation skills to work with the stakeholders and as

every project is unique, this requires a negotiation process which cannot be a tick and flick

sheet or a manual.

Example: A property developer wishes to convert 8 acres of forested land into a new housing

estate. Obvious stakeholders include the architect for the buildings, town planning, water,

sewage, gas and power utilities, main roads, suppliers of the all the materials required,

environmental impact, noise issues for neighbours and so on.

However, the land may be currently used by a pony club and bird watching association, the

lost use of the forest will have a negative impact on them therefore they are considered to be

stakeholders. All the relevant stakeholders need be identified and engaged so that they all

have the same clear vision of what the project is to deliver and how it involves or affects them.


29

The process for the creation of the Stakeholder Register.

Inputs

The Project Charter can provide information about internal and external parties related to the

project and those stakeholders affected by the running or outputs of the project, e.g.

sponsors, customers (current and projected), team members and other people or

organisations affected by the project.

The Procurement Documents will detail any third party contractors, consultants or suppliers

required for the project therefore should be considered stakeholders.

Enterprise environmental factors will include internal decision makers (finance, corporate

compliance), team members, if there are any governmental or industry standards that need

to be adhered to or take advice from.

Organisational Process Assets provide documentation on stakeholder register templates, any

lessons learned from previous projects and stakeholder registers from previous projects for

this type.

Tools and Techniques

The analysis is designed to provide the project with an insight into the interactions between

the project and the stakeholders, and their importance, influence and impact.


30

Expert judgement is used to ensure a comprehensive as possible identification of

stakeholders using previous experience from similar projects, input from subject matter

experts, governmental bodies and any other available source of expert guidance.

Meetings can be used to develop an understanding of major project stakeholders and what

their roles, influence, interest are and how they view the project.

Output

The Stakeholder Register documents who the project has to engage with. It will contain the

stakeholder’s name, contact information, their link to the project, their main expectations /

requirements, their influence, whether they are internal or external and their support or lack

thereof for the project.

This process can be a very large undertaking so the stakeholder engagement needs to be

scaled relative to the size and possible risk of the project. It is best to engage the stakeholders

sooner than later as this gives more time to come to an understanding as early as possible of

their requirements and therefore the overall scope of the project. This may prevent having to

make expensive changes if the project has already started.

Stakeholder Management

Like any other business function, stakeholder engagement needs to be managed. It should be

driven by a well-defined strategy and have a clear set of objectives, timetable, budget, how

they are to be engaged, desired outcomes and allocation of responsibilities.

Considerations when engaging with your stakeholders:

- Don’t allow your time and that of the stakeholder’s to be wasted with unnecessary

meetings.

- Do manage the stakeholder process efficiently, mainly through sharing the specific

knowledge and understanding from each group or individual.

- Do not neglect or take for granted any stakeholder.

- Don’t make assumptions about the relationship of stakeholders to your project.

- Do communicate with all members of your project team about the stakeholder

engagement process.


31

The table below provides an example:

Desired Outcome from Stakeholders

PURPOSE

SCOPE

ROLE

SELECTION

Governance. Comply with noise

abatement Act.

Advise on

legislation.

High impact on site

starting time.

ENGAGEMENT PROCESS – Email

The desired outcomes of each stakeholder engagement.

Comply with legislation to enable the longest possible working day.

2.4 Scope-Management Plan

A project team spends a lot of time and effort to create plans and documents, e.g. the Project

Charter, Business Case, Stakeholder Register and Original Scope, so the information

contained within them can be useful in determining what the project specifically has to do to

achieve the desired project outcomes.

The Scope management plan brings in and uses the information and processes from these

other documents to describe how the scope will be developed, monitored, verified and

controlled. This process produces the Scope management plan and the Requirements

management plan. This an involved process where multiple plans and documents are created

and used so that the project can define its scope and have a clear vision on what needs to be

achieved.


32

The Scope management plan details those processes used to manage the project scope only,

and may include how to:

- Determine that a scope change has occurred or is about to occur.

- Seek authorisation for changes to project scope.

- Implement agreed scope changes.

- Monitor and report the effect of scope changes on other areas of the project.

- Identify and report scope creep.

- Identify factors influencing changes to scope.

- Refine the scope progressively throughout the project lifecycle.

The Requirements Management Plan describes how the project requirements (one of the

project objectives) will be managed, analysed, prioritised and documented.

The next step is to collect the specific project requirements from all the information gathered

so far.

Requirements can be categorised as business requirements, stakeholder requirements,

solution requirements and quality requirements.


33

From the required inputs for this process you can see why the Scope Management Plan,

Requirements Management Plan, Stakeholder Management Plan and Stakeholder Register

needed to be created – for large projects there is just too much information to do off the top

of your head or off the back of an envelope.

A systematic, structured approach is needed or important information may be lost or poorly

used. A point to keep in mind is that these activities need to be scaled appropriately to

accommodate the size and importance of the project.

Not all the Tools and Techniques need to be used to collect the requirements from

stakeholders for each project. Select the ones that best fit the needs of the stakeholders and

the project.

The two (2) outputs from the Collect Requirements process are:

- The requirements documentation which will define how the requirements will meet

the business needs of the project and will specify how each requirement will be

testable, measured, completed, traced and how it will be acceptable to key

stakeholders.

- The Requirements Traceability Matrix is a grid that links specific requirements from

their origin to the project deliverables that satisfy them.

Now that all these plans and documents have been created in the planning stage the initial

Scope document created in the initiation phase can be updated into the full project scope

statement that outlines all the work and only the work that the project needs to undertake.

From the requirements documentation it is now possible to construct the Work Breakdown

Structure.


34

Now that more is known about the project, the scope can be updated by the following

process:

The new Project scope statement will detail the product scope description and acceptance. It

will also describe the project deliverables, assumptions, exclusions and constraints.

Example Document - Final Scope Statement

Templates for the Scope Statement will come from the Organisational Process Assets and will

normally come in the form of blank electronic form that needs to be filled in, updated when

needed, and controlled.


35

Project Title: Project Number:

Project Leader/Manager: Anticipated Project Start Date:

Contact: Date Prepared:

Project Cost Estimate: Estimated Completion Date:

Document version number: Last Document Update:

Team Members

- As appropriate.

- Can be any combination of individuals, groups, teams, or organisations.

- Include the core team members directly responsible for project deliverables.

Purpose of Project

- As appropriate.

- Include a concise goal statement.

- What is being accomplished?

- What are the major benefits expected from this project?

Background

- As appropriate.

- Provide a brief project history.

- Justification of why this project should be done.

- What may be the expected consequences of this project?

- Why this project?

- Is it unique or special?

Deliverables

- As appropriate.

- What are the major outputs of the project, including quantities?

- What are measures of project success?

- What is promised to the “customer”?

Stakeholders

- List all internal and external stakeholders.

- List any steering committee members.

Resource Requirements


36

- As appropriate.

- Benefit/Cost Analysis.

- Any special labour, consulting or training needs and costs.

- IT Project resources and staffing plan.

- IT Project budget and timelines including project start, finish, and major

milestones.

- List those items you consider resource sensitive or may place limits on the

project team, e.g. empowerment, budget, resources etc…

Operations and support

- As appropriate.

- Product ownership and who is responsible.

Roles and responsibilities - SCOPE

You can describe who is responsible for establishing and managing project scope, who

will have input into the scope definition, who can approve the scope, who can request

changes to scope:

- Identify team members responsible for key roles.

- Identify any training needs.

- Identify communications and marketing scope.

Approvals

Creating the Work Breakdown Structure

There is now enough information gathered to begin creating the Work Breakdown Structure.

Remember: the WBS, is a hierarchical “break-down” of the major project deliverables and

project work into smaller more manageable components, so it easier to know and plan for

what exactly needs to be achieved within the boundaries of the project.

Some deliverables can be produced at the same time and others can only be started after

another has been completed. The critical path is the sequence of activities that produce all of

the project’s products in the least amount of time with no leads or lags.


37

Decomposition is the process used for the dividing and then subdividing again the project

scope and project deliverables into smaller and smaller more manageable parts.

A Work Package is the lowest (or smallest) amount of work that can be defined for which cost

and duration can be estimated.

Visit Sample Work Breakdown Structure in the resources section.

The outputs of this process are:

- Scope baseline is a combination of the Project Scope Statement (described above), the

WBS and the WBS Dictionary. The WBS Dictionary gives detailed information about

account identifier, description of work, scheduled milestones, resources required,

estimated cost, quality and acceptance criteria for each component in the WBS.

- Project Document updates refer to the project documents that may need updating

after the creation of the WBS. These may include the requirements documents which

may need to be updated to reflect any approved changes to the WBS.

The last two (2) Scope related processes are Validate Scope and Control Scope.

Validate scope is the process of formally accepting the completed project deliverables. It uses

an objective method for acceptance involving the sponsor when reviewing each finished

deliverable.


38

The inputs include:

- Verified deliverables which are deliverables that have been completed and checked

against the Control Quality.

- Work performance data can include information on how close the deliverable is to

compliance with requirement, the number and severity of nonconformities.

The outputs are:

- Accepted Deliverables, those deliverables that have meet the acceptance criteria of the

sponsor and have been formally accepted and signed off by the sponsor.

- Change requests are generated when formal acceptance has not taken place. The

reasons for non-acceptance will be documented and a change request for defect

repair issued.

- Work Performance information includes information about which deliverables have

started, their current progress and which deliverables are finished waiting acceptance

or accepted.

- Project Documents Updates, update project documents as needed.

The last Scope related process is Control Scope. This process monitors the project and

product scope and manages changes to the scope baseline.


39

The new technique used in this process is Variance analysis. This is where the actual

performance is compared to the baseline performance. The cause and degree of difference is

recorded as is any corrective or preventive action as required.

The outputs of this process are:

- Work Performance Information collects information on how well the project scope is

performing compared to the scope baseline. This information provides insights for

making scope decisions.

- Change requests can include preventive or corrective actions, defect repairs, or

enhancements.

- Update any plan, documents and process as required.

When any deliverable has been formally accepted by the sponsor it is forwarded to the Close

Project process. When all the deliverables have been accepted the project is then ready for

the formal closing phase.

To arrive at the point where the project team, sponsor and other stakeholders clearly

understand what has to be achieved within the constraints of time, cost and quality may have

taken months of planning for large projects.

The reason why such effort is made to determine the scope is that in the long run it will cost

less and more benefits will be achieved so the project is more likely to succeed. As a project

manager, all your efforts relate to ensuring the best and most successful outcomes for your

project.

Three (3) of the main reasons why projects fail are unclear requirements, poor scheduling and

making plans on insufficient data or missing items. All 3 of these are reviewed and used when


40

scoping a project, it is essential to spend the time and effort needed to correctly scope any

project.

Example Only – Questions to ask when scoping the project

Items Yes No

Does your scope definition include……………

Are there items that need to be resolved by the project

manager……..….?

Are there new system(s) to be implemented by this

project………………?

Any additional data requirements………..?

Who is the preferred person or body to seek agreement

from………..?


41

Template Example Only for a Project Plan

Suggested Headings Comments

Title

Background/Context

A brief explanation of the background and/or context of the

project.

Objective

Why are you doing the project? What is the aim of this

project?

Target Outcomes

Maybe things that are to be improved, increased, enhanced or

reduced and showing the benefits that the project intends to

achieve.

Project Activities,

Output and

Milestones

What things will be delivered by the project? Outputs are used

by the project’s customers to achieve the outcomes. Detail

milestones and chart the success or failure.

Measured

How will the success of the project be measured?

Measurements are linked to one or more target outcomes

which can then answer such questions as 'what have we

achieved' and 'how do we know?'

Governance

Briefly describe the accountabilities of each party. Detail the

name and title of the Project Manager and Project Sponsor.

Reporting

Requirements

Reporting frequency, format and to whom?

Resources

Human resources, internal, external, consultants and/or

working groups will be required for the project? Budget,

funding and details of the proposed expenditures.

Stakeholders &

Communication

Strategy

List the key stakeholders or stakeholder groups who will

impact on the project. How will they be engaged?

Assumptions and

Constraints

List any underlying assumptions and/or constraints.

Risks & Minimisation

Strategies

Identify barriers to achieving the project success. For each of

these risks, what steps will be undertaken to minimise them?


42

Risk Management

The process used to manage risks throughout the project.

Identification, review and reporting.

Issues Management

The process used to manage issues throughout the project.

Identification, review and reporting.

Related Projects

Projects which are dependent on this project, or projects that

are interdependent on this project. Describe the relationship.

Guidelines/Standards

Guidelines, standards or methodologies that will be applied

manage the project.

Quality Control

Levels of review that will be undertaken. The development of

the project outputs. How the reviews will be conducted and

who will be involved.

Capturing the

Lessons Learnt

Review the entire internal or external process to capture the

lessons learnt throughout the project.


43

3.0 Manage project scope-control process

Module Overview

Applying a project scope-control process will assist in ensuring that only ‘in scope’

requirements are worked on and will assist in avoiding scope-creep.


- Implement agreed scope-management procedures and processes.

- Manage the impact of scope changes within established time, cost and quality

constraints according to change-control procedures.

- Identify and document scope-management issues and recommend improvements for

future projects.

3.1 Scope-Management Procedures

As stated earlier, Scope management may include:

- Determining that a scope change has occurred or is about to occur.

- Identifying and reporting scope creep.

- Identifying factors influencing changes to scope.

- Implementing agreed scope changes.

- Monitoring and reporting the effect of scope changes on other areas and on

achievement of project objectives.

- Refining scope progressively throughout the project life cycle.

- Seeking authorisation for changes to project scope.

Implement management items

The project scope and the scope management plan were previously defined along with their

input, outputs, tools and techniques. Procedures contained within these documents

described how the various aspects of scope will be managed and by whom.


44

For smaller companies these scope procedures need to only be created once and can be re-

used as templates for subsequent projects, however these procedures should be customised

according to the current project scope. If the company has a Project Management Office

(PMO) then they will store and control the use of these templates.

It is important that these documents and procedures reflect the nature and risk of the project.

Scope still needs to be properly controlled and monitored but a project to build a spa bath

house that involves 1 company, 1 contract and 5 different stakeholders will have much

simpler management needs compared to a project that builds a new 22 story office block that

uses a prime contractor , 17 sub-contractors and has over 50 stakeholders.

No matter what the size or complexity of the project, someone from the project management

team needs to monitor, review and update as necessary the project’s activities within specific

time frames.

Example: the scope management plan may state that the project manager will review any

request for change to the scope in the Change Log on a weekly basis and that any request for

change that needs to be considered by the sponsor is forwarded to them before 5PM each

Wednesday.

If a request in the Change Log is approved by the sponsor then the scope documentation has

to be updated to reflect this change. Other stakeholders that the change affects also need to

be informed and the WBS updated.

Scope Management

One of the functions of scope management is to determine if a scope change has occurred or

is about to occur. If the scope has changed or a request has been submitted, the project

manager needs to consider how this change will impact the overall project and make any

changes needed that are within their authority to act.

If the change to the scope is outside their authority, the project manager with the sponsor

and other key stakeholders will consider the implications to the project.

Key questions that should be asked regarding all scope changes include:

- Will the project still be completed on time and on budget?

- Will the project deliverables still be completed within acceptable quality levels?

- Are scope change requests being managed successfully?


45

During these stakeholder reviews other questions that need to be considered include:

- Are project issues and risks being addressed successfully and mitigated?

- Are all customer concerns being addressed successfully?

- Managing risks might lead to a change request for the scope.

Example: During the expansion of a computer network to accommodate new users, it has

become apparent that there is risk that there is currently not enough storage space for the

new users’ files. It has been decided that extra storage be added to the expansion project. The

scope of the project now needs to be updated to reflect this change. Not all risk management

will lead to scope changes.

An example of a template for recording risks.

Identify Scope Creep

Remember: Scope creep is the process when new requirements are added to the scope of

the project without any changes to the budget or time scale of the project. It often occurs

when stakeholders attempt to add extra activities/tasks or outcomes, to the project.

If scope creep occurs, ensure it is documented and reported. Any project activity on work ‘out

of scope’ should cease or at least be immediately reviewed to prevent the expenditure of

resources on activities that do not help produce project outcomes.

Issue and

Description

Project

Impact

Target

Due

Date Issue Status Issue Resolution

[Description of

Risk]

- [Item]

- [Item]

[High/Med/Low] date [Open/Closed] [Description]

[Description of

Risk]

- [Item]

- [Item]

[High/Med/Low] date [Open/Closed] [Description]


46

If this ‘out of scope’ work is then authorised by those in your organisation with appropriate

delegations, then it needs to be added to the scope via the normal scope change process. Any

impact these 'extras' will have on the resources, including time frames, cost and quality of the

project need to be understood and documented.

Projects need to remain flexible so that stakeholder expectations and changing requirements

can be met and implemented. Having and using a specified change management procedure

for all changes to scope helps reduce the risk of scope creep but allows the authorised

changes.

A request for change will pass through several stakeholders during its implementation cycle.

The request will typically be:

- Evaluated, e.g. an impact analysis of the scope change request.

- Cancelled, someone with authority decided to cancel an agreed scope change.

- Re-submitted as someone has decided to re-implement the requested change.

- Verification that the change was made correctly.

- Change made to the request then approved and implemented.

- Approved and implemented.

Identifying factors influencing changes to scope

Scope change is natural and expected. It is useful for all the various project team members

and stakeholders to have input into possible scope changes. These possible changes should

have a central collection point to allow for ease of collation and review.

When submitted, these potential scope changes should include information on their:

- Likelihood, which represents the chance that the scope will need to be changed. This

can be represented qualitatively as a word, quantitatively as a probability or frequency,

or as both.

- Consequence, which represents the impact that a change to scope may have and is

measured in degrees of severity, should it occur. Consequences may be financial loss

or gain, legal problems or opportunities, delays in a project, personal injury or damage.


47

Examples of factors influencing changes to scope include:

- Changing roles and responsibilities within a project team.

- Negotiating an extension of a deadline.

- Seeking further resources to meet a deadline.

- Redefining completion criteria of the quantities or quality of outcomes.

- Outsourcing some aspects of the project.

When Implementing agreed scope changes, every attempt should be made to obtain the full

support of the project’s leadership in implementing any recommendations to the organisation

as a result of scope changes. Also it is important to have the support of key stakeholders and

as a minimum they need to understand why the changes are to be made.

Effect of Scope Changes

When monitoring the effect of scope change the following questions need to be asked and

answered:

- Did the project scope changes have the desired outcome as detailed in the revised

work plan and were there any outstanding issues that would need future refinement?

- What worked well and why and how do we know this?

- What did not work well and why not?

- Are the changes leading to successful outputs?

- Do the changes impact on the budget expenditure? If so, how?

- Do the changes impact on stakeholder participation? If so, how do we address this

issue?

- Are there further areas to be adjusted to ensure that tasks and activities are producing

the project deliverables?


48

Refining Scope Progressively

The scope needs to be reviewed at predefined points within the project life cycle though

important changes can be made at any time. Important areas of the scope can be reviewed

more often than other less important areas. Some of the reasons for predetermined scope

review include:

- Benefits – Some may not have been fully developed or identified and will need their

current status compared against targets.

- Requirement – Some may have been set too high or have been left too open to

interpretation or have changed.

- Stakeholders – May be in regular need of communication when confronted with

scope changes influenced by costs associated with revised solutions. Also the list of

stakeholders may change over the course of the project.

- Solutions – Can have many refinement needs when there are several options

available. Some critical decisions will not be completed until due diligence of the

suggested scope change options have been completed or further defined.

- Funding – From sponsors or financial backers may not be obtained until any scope

change impact on the business case is developed or further refined. Further

refinement may require understanding of the benefits, requirements, and solution

options before the funding is released.

The authorisation procedure for changes to project scope is defined in the Project Scope

Management plan. It will also include how to submit change requests and how they will be

dealt with.

Scope Change requests include the details you would logically provide for the scope changes,

include future impact and commitment of resources. The authority protocols for submission

would have been decided at the project plan stage. The format and submission structure

should also be in place and provided by the PMO if there is one.


49

3.2 Manage Scope Changes

Scope directly impacts project Time, Costs and Quality and so changes to the scope can

therefore instigate changes to other Change-control procedures. These may include:

- Formal agreements, e.g. contracts, subcontracts and memoranda of understanding.

- Major elements of the project likely to change, e.g. design, engineering and finance.

- Project documentation, including plans, schedules, statements, directives, guidelines

and instructions.

Changing the scope may require you to adjust the number or duration of the tasks, how much

they cost, what they produce, modify the WBS, and adjust the task constraints to meet your

schedule.

Impact of scope change on Time

Scope changes may cause a change to how much time is needed to complete the new

deliverables. It may increase or decrease the time required depending on the nature of the

scope change and therefore affect the overall project schedule.

The impact of scope changes within established time constraints can be managed by

determining what the new tasks are, how long they will take, what resources they require, and

in what order they should be done.

When managing the impact of scope changes involving time, revisit the part of the WBS that is

affected by the scope change. Build the new project schedule by listing, in order, all the tasks

that need to be completed. When this is completed the revised project schedule and new

critical path should be circulated to relevant stakeholders.

A common difficulty experienced in managing the impact of scope changes involving time is

that there is not enough time to complete all the new tasks. If it important that no extra time

be taken to deliver the new products, increased funding could be allocated for extra staff or

resources to ensure its completion on time. If no extra funding is available, the project

schedule may have to be extended.

Q: Does this remind you of anything?

A: The Iron Triangle of the triple constraints of Time, Cost and Scope and how they relate to

Quality.


50

In brief, managing the impact of scope changes is to manage changes to the critical path of

product production.

Note: Items can be added to, or removed from the critical path as circumstances change.

Impact of scope change on Quality

Quality in project management can be defined as delivering the desired outcomes according

to the plan, and meeting the expectations of all stakeholders.

Quality can also mean compliance with quality standards either regulated by state laws, local

government laws or imposed by industry or professional standards. It can also mean the

standard of quality products need to achieve to meet approval by the relevant stakeholders.

Example: the quality of the flint in a cigarette lighter may be defined as been able to

successfully strike and ignite the lighter fluid 10,000 times (+/- 10%) before it fails.

Quality itself is not necessarily a constraint but could be the result of achieving or not

achieving compliance of the three (3) main areas of:

- Scope.

- Time.

- Cost.

If all these are achieved according to the project plan then it is likely the overall project has

met the requirements of quality.

Constraints

Quality constraints and the successful management of them (as they appear) will depend on

the skills and knowledge of the project manager and team.

The project manager needs to take into account all constraints that occur and to establish a

set of rules and processes to keep the project in balance.


51

The iron triangle of constraints revisited. When managing conflicting constraints project

managers will usually have to make compromises. There may not be enough time or money

to make the best product, however sufficient money and time may be available to make a

product that will meet expectations and requirements.

Example: You may have enough time and money to build a computer that allows you to do

everything you want from a computer but you may not have the need, time or the millions of

dollars required to build several ‘super’ computers whose functions and capacity you will

never use or need.

Other examples of constraint compromise:

- A project schedule alters, there may be a need to increase the budget to cover the

extra work.

- Budget constraints may require the use of more resources in less time.

- Project scope might need to be altered because the resources available will not be

sufficient.

- Project scope will be altered because of fewer staff, resulting in not being able to meet.


52

Basic Change Control Function

- The process is usually undertaken in accordance with a set procedure for handling

proposed alterations to the project scope, which have previously been assumed as

working.

- Change control usually becomes a reality only if the item/s requiring change have

already been set in place or approved.

- The aim of a change control function is to then ensure such changes are re-approved,

accepted and are in line with the project objectives.

- There should be a set procedure to adhere to so that the changes can be controlled,

monitored and controlled.

Examples of elements in a set Change Control procedure

- Stakeholders should have an opportunity to participate in the change control

sequence of any change, or as a minimum those stakeholders primarily involved.

- Full disclosure of any changes that occur.

- Provide an audit trail which connects a change to the reason or strategy employed to

cause or make the changes.

- Record the new approvals and names of those authorised to make those changes.

3.3 Identify Scope-management Issues

It is essential in project scope management to sufficiently train the project managers and

team. Do not make the mistake of assuming that a technical expert in a specific area can

easily become an expert in another field, e.g. scope definition.

Scope management involves a high level and a detailed understanding of business

requirements and other processes within project management.


53

Possible ‘holistic’ Examples What Improvements?

Technical experts versus scope experts Don’t assume a technical expert, e.g.

architect, engineer, designer will

automatically qualify to collect, build, and

analyse the project scope.

Skills assessments not conducted before

a role is appointed

Training! Provide project managers with the

skills to build scope definitions etc.

Insufficient interaction between the

client and certain project team members

Communicate more efficiently and

frequently with key clients throughout the

planning and execution phases of your

project.

Lack of stakeholder education on project

management and possibly technical

solutions

Training and education provided by the

project team, where feasible! Address

current technological usage and skill levels.

There may be limitations to this.

Poor project decisions made by project

managers

Better communication, set procedures,

reviews and training.

Product, service or results issues

Remember: The outputs of a project are products, services or results!

Issues may only come to light when a project product or service is completed and delivered to

the client and they claim dissatisfaction or reject the product.

The ‘issue’ likely occurred due to insufficient interaction and communication between the

client and the project team members which led to poor scope definition. This is why

stakeholder engagement and the collection their requirements are important as it leads to

better outcomes for the project.

What can be done for future projects?

Lessons learned in your current project need to be recorded and made available for future

similar projects. You do not have to reinvent everything for every project.


54

Every project manager should build up a store of useful materials called at PM Kit or Tool Box.

This will save you time and effort on future projects.

To reduce issues, ensure the involvement of clients and customers at all stages of a project as

they are stakeholders. Remember to involve them in both the initiation and planning phases.

Also involve them in scope validation and the detailed design documentation to make sure

everyone has the same clear vision of the project deliverables.

Another cause that can create issues for the project is when the work begins before the

project scope has been completed. This can come from external pressures, e.g. when it is

perceived that waiting any longer for the detailed project scope is a waste of valuable project

resources. This can also come from internal pressure when project team members are

excited by the project and just want to get on with the job.

This is not the way to run a project as invariably there will be omissions that will appear later

in the project, and it may cost a lot more to fix a problem than if the issue had been

addressed at the scope definition stage.

For future projects, when considering scope issues ensure the project team has:

- The correct training for project scope communication techniques.

- Follow the set procedures and use any available templates.

- Ensure that all required governance documents are available. Ask for them if they are

not. Having no formal scope document is a recipe for disaster particularly if the project

encounters problems in the acceptance of deliverables.

- A poorly defined, but documented, scope can be as dangerous as not having one at all.

Spend the time to ensure that a clearly defined scope is understood by all the

stakeholders. Poor quality scope documentation can also lead to the need to repeat

the scope definition process wasting time and resources.

- Monitor all the documents relating to scope and follow the approved change

management guidance.

- All of the scope items must be prioritised and assigned. One system for this is the

MOSCOW Principle: where the scope items are designated as “Must have”, “Should

have”, “Could have”, and “Wont have” so there is no confusion about what is in and out

of scope and what is their priority.

These are the issues and what action should be taken during the life of your project.


55

Unit Completion

You have now completed the unit ‘Manage Project Scope’.

You are now able to:

- Conduct project authorisation activities.

- Define project scope.

- Manage project scope-control processes.


56

References

These suggested references are for further reading and do not necessarily represent the

contents of this learners guide.

- Barker, S. & Cole, R. 2009. Brilliant Project Management: (Revised Edition). Pearson

Business.

- Berkun, S. 2005. The Art of Project Management (Theory in Practice (O'Reilly)). O’Reilly

Media.

- Cleland, D. L. & Ireland, L. R. 2006. Project Management: Strategic decision and

implementation. 5th ed. McGraw Hill Professional.

- Harold R. K. 1995. Project Management: A Systems Approach to Planning, Scheduling,

and Controlling [Hardcover]. Van Nostrand Reinhold.

- Project Management Institute 2013. A Guide to the Project Management Body of

Knowledge (PMBoK® Guide). 5th ed. Project Management Institute, Newton Square,

PA.

- Thomsett, R. 2002. Radical Project Management. Prentice Hall.

- https://www.projectsmart.co.uk/improve-project-success-with-better-scope-

management.php

- http://www.projects.uts.edu.au/stepbystep/planning1.html

https://www.projectsmart.co.uk/improve-project-success-with-better-scope-management.php

https://www.projectsmart.co.uk/improve-project-success-with-better-scope-management.php

http://www.projects.uts.edu.au/stepbystep/planning1.html