Manage Project Scope:- Project

Management Assignment Help

 Previous
 Next

Manage project scope

BSBPMG511
What is a project?

Before we delve into project time management, maybe we should take a

moment to define what a project is.

 A project has a single objective that must be accomplished

through the completion of tasks that are unique and
interrelated
 Projects are completed through the deployment of
resources
 Projects have scopes, schedules, and costs and are
accomplished within specific deadlines, budgets, and
according to specification

And to summarise, a project is a sequence of unique, complex, and

connected activities having one goal or purpose and that must be
completed by a specific time, within budget, and according to
specifications.

Project Scope Management

According to the PMBOK Project Scope Management includes the

processes required to ensure that the project includes all the work
required, and only the work required, to complete the project
successfully. It is primarily concerned with defining and controlling what
is or is not included in the project.

Project Scope Management includes 5 processes:

1. Initiation – authorising the project or phase.

2. Scope Planning – developing a written scope statement
as the basis for future project decisions.
3. Scope Definition – subdividing the major project
deliverables into smaller, more manageable components.
4. Scope Verification – formalising acceptance of the
project scope.
5. Scope Change Control – controlling changes to project
scope.

A project generally results in a single product, but that product may

include subsidiary components, each with its own separate but
interdependent product scopes. For example, a new telephone system
would generally include four subsidiary components – Hardware,
Software, Training and implementation.

Completion of the project scope is measured against the project plan, but
completion of the product scope is measured against the product
requirements. Both types of scope management must be well integrated
to ensure that the work of the project will result in delivery of the
specified product.

Initiation - Conduct project authorisation activities

Before any project can advance a formal authorisation of its scope must
be achieved and documented. Such authorisation may be subject to
needs and risk assessment, analysis of needs vs. conditions and
feasibility and other equivalent efforts that are designed to secure the
formal approval of the scope or determining that the project is high risk,
not feasible or not viable. 
In some cases, a portion of the work will be carried out prior to obtaining
formal approval. This is done to support and secure the formal approval,
when the work done serves as a proof of feasibility or greater readiness
for the project.

Project scope isn’t developed and presented to the sponsor at one go, it’s
a process.

Develop and confirm procedures for project authorisation

with an appropriate authority

INPUTS - The first step in preparing to obtain project authorisation is

collating inputs to initiation, this includes:

1. Product/Service description

Documents describing the product or service, including behaviour,

characteristics and the business reason for its proposed creation.

2. Strategic plan

Strategic planning is how an organisation or an individual defines their

objectives, values, missions and the way to achieve these. Project
management is the discipline of planning, organizing, motivating, and
controlling resources to achieve specific goals. A project is a temporary
endeavour with a defined beginning and end under-taken to meet unique
goals and objectives.

A strategic plan by the organisation that undertakes the project should

be considered and may be included in the inputs to initiation, as the
project should coincide with the organisation’s goals, objectives and
values. If it isn’t, issues may arise in a later phase of the project.

3. Selection criteria and business reason

Innovative ideas are important for organisations, but projects are

typically associated with risk of losing the investment, losing time,
process, reputation, causing indirect damage to other products and
services etc. This is why selection criteria must be set in place to
determine which ideas make the cut and are “worthy” of a project.

The business reason for the project and the details explaining why the
idea is worthy of turning in to a full scale project are important input to
obtaining project authorisation.

4. Historical information

Although not always available, historical information can help the

authorising body or individual make a good decision. Similar previous
projects may shed light on the process, cost, issues and results involved
with the project you are about to commence.

Think of yourself as the financing body that provides authorisation to

projects. You would probably want to see as much information and
details about the reason for the project, why it will pay off and how it is
going to be managed smoothly and deliver the expected outcome.

Other tools and techniques for initiation include modelling techniques in

which models are made to support the reason and logic to start the
project (decision models, diagrams, mathematical models, researches,
analytical hierarchy etc.).

Another source of information is Expert Judgement. This may be

achieved within the organisation or externally and will reinforce other
documentation.

OUTPUT

Now that you have collated all the relevant information you possibly
could as inputs to initiation, it is time to create the documents that will
formally authorise the project:

1. PRODUCT DESCRIPTION

Product/service description incorporates product/service requirements

that reflects agreedupon customer needs and the product design. It
explains how the product/service operates/behaves/used in order to
address and agreed-upon customer need.

2. THE PROJECT CHARTER.

This document holds all the relevant information for a decision maker to
know about the project. It includes the business reason (needs
identified) and the product/service description.

It is better for project charters to be developed by a party external to the

project as that will allow:

 An objective interpretation of data

 The project manager to allocate and apply resources as
determined.

If the organisation is contracted to produce a product or a service to a

client, the contract may serve as the project charter.

To view an example of a Project Charter click HERE.

3. CONSTRAINTS – These are limitation to the project that are likely

to affect your ability to manage the project towards successful delivery.
These can be internal, like a dire financial straight for the performing
organisation or external like environmental constraints.

The more specific and detailed you are with the assessment and
description of project constraints, the better you will manage the project
around the constraints and find alternative ways of achieving your goals
and objectives.

4. ASSUMPTIONS

Every project operates under a set of basic assumptions. These are

factors that you consider to be certain and will affect project planning.
You must make assumptions and that involves an element of risk
because things may change. This is why assumptions must be validated
throughout the project and if proven wrong than project planning must
change accordingly.

Scope Planning

INPUTS

We discussed the documents and data included in the initial scope

planning;

 Product description
 Project charter
 Constraints
 Assumptions

All of these documents are inputs for the next step in scope planning.

Scope Planning doesn’t stop with the creation of the four documents
mentioned above. In fact, this is an ongoing process design to achieve
accurate scope definition and controlling the scope throughout the
project to deliver the defined deliverables.

Scope planning uses tools to help you better understand, evaluate and
document information about the project scope. These include:

Product analysis

A detailed analysis of the product/service in terms of: engineering, value,

functions and quality.

Benefit/cost analysis

Evaluation and estimation of cost vs returns of different scenarios (with

regard to the project and product/service produced) to assess relative
desirability of the alternatives.
Alternatives identification

Finding alternative approaches to manage the project.

Expert judgement

The analysis, evaluation, assessment and advice of an expert about the

processes involved with producing the product/service.

OUTPUTS

The outputs of this step in the process are 2 documents:

 Scope statement – describing project objectives and

deliverables.
 Scope management plan – How we will manage the scope,
identify scope creeps, document changes and obtain
approvals.

An additional document is “supporting detail” which may accompany

any of the two. Scope Statement

The scope statement includes:

 The business reason (justification) for the project (i.e.

customer need we set out to address)
 Description of the product/service including main
characteristics and functions
 The deliverables required to complete the project
 Quality criteria that when met the project is deemed
successful

This document may be modified throughout the project when changes

are needed and approved. This will be the basis for future project.

Supporting detail
Supplementary documentation, calculations, analysis etc. should be
documented to assist in:

 Supporting scope statement

 Other areas of managing the project
 Supporting Scope management Plan

Stakeholder’s approval of scope

A formal acceptance of the project scope by stakeholders is necessary in

order to kick off the project. The stakeholder can be a sponsor, customer,
employer or other. In order to approve the relevant stakeholder will
review the documentation mentioned above and if all is well – approve
the project to start. This could mean singing the project charter, a
contract or various other acceptable ways to give approval in the
business environment.

A good presentation of information through the documents mentioned

above is crucial to obtaining approval for project scope.

Obtain authorisation to expend or shrink resources

Change requests

Change requests happen in almost any project. It’s enough to think of a

young family building their home where they plan to raise children to
imagine how many changes may occur before and during construction.
Changes aren’t necessarily bad and should automatically stress or hinder
a project, but they most certainly be managed.

The actual request can be made orally or in writing and by more than one
stakeholder, including internally and externally. The changes may attract
an expansion or shrinkage of scope.

The following table shows internal and external causes for scope change
requests.

Internal External
Errors and omissions in calculations, Errors and omissions in calculations,
evaluations, estimations and assessments. evaluations, estimations and assessments.
Change of management. Change of Government.
Respond to risk – Implementation of Plan B. Respond to risk – Implementation of Plan B.
Financial issues.
Environmental issues.
Change of legislation.
Critical changes of labour.

Scope change control

Scope change control is the set of procedures to follow when a scope

change is needed.

The procedures will relate to the way in which the change will be
requested (i.e. paperwork or electronic system used), the integration of
the change and the documentation of the entire process.

Think about your own workplace, if you wanted something changed,

what is the procedure?

In a project, this process of changing the scope must be predetermined

and clear as changes to scope will directly or indirectly have an effect on:

 Time
 Cost
 Quality

The output of this process is the documented scope change, which is any
change to the approved Work Breakdown Structure (WBS).

Approved scope changes may attract modification to several other

documents in the project such as technical and planning documents.

Corrective action
Another tool to manage scope is the corrective action. This includes any
action done subsequently to changes or fluctuations to align the project
actual performance with the plan.

Lesson learned

Here lies the historical data of future projects. It simply means that what
you have learnt in the current project may be useful information for
future projects and that is why you should identify and record the
reasons for corrective actions, the corrective actions and its results.

Adjusted baseline

The project baseline is a document that shows the plan for the project
over the period of time it is designed to occur. Milestones for payments,
deliverables and significant events are marked on the timeline and helps
the project manager monitor and compare actual results with planned
results.

If the change affects the baseline then an updated/new baseline must be

created.

Confirm project delegations and authorities in project

governance arrangements

What is Project Governance?

Project governance is the management framework within which project

decisions are made. Project governance is a critical element of any
project since while the accountabilities and responsibilities associated
with an organization’s business as usual activities are laid down in their
organizational governance arrangements, seldom does an equivalent
framework exist to govern the development of its capital investments
(projects). 

For instance, the organization chart provides a good indication of who in

the organization is responsible for any particular operational activity the
organization conducts. But unless an organization has specifically
developed a project governance policy, no such chart is likely to exist for
project development activity.

Therefore, the role of project governance is to provide a decision making

framework that is logical, robust and repeatable to govern an
organization’s capital investments. In this way, an organization will have
a structured approach to conducting both its business as usual activities
and its business change, or project, activities.

Put simply, the project governance will tell you what activities are under
whose authority and which project delegations are related to the activity
you need to carry out.

Imagine that you need more time, equipment or machinery to complete a

task in the project. For example, during an excavation you realise that
you’ve hit pipes and must stop the work.

Typically you would approach your supervisor or project manager. 

But if you are the project manager you need to know who in the
performing organisation to contact about this. Who is delegated and
authorised to make a decision and approve your solution to the problem.

Not knowing who to talk to may cause delays. When the work is stopped
and workers are just waiting for further instructions money is wasted
and this may affect the overall project in terms of meeting deadline,
staying within budget, quality etc.

When you work on a project as part of a team you could work under a
project governance scheme or under the organisational umbrella (when
no project governance framework has been developed). It is essential for
project managers to clarify the delegations and authorities prior to work
commencement.

Define project scope

Identify, negotiate and document project boundaries

As described earlier, the INITIATION phase of Project Scope
Management includes the input of:

 Product/service description
 Strategic plan
 Project selection criteria
 Historical information While the output is:
 Project charter
 Project manager (identified or assigned)
 Constraints
 Assumptions

The project charter in itself may include the boundaries of the project,
the constraints and the assumptions under which the project will run. 

The project plan should include reference to OUT of SCOPE

components. This may also be included in the project charter which is a
supplementary document to the project plan.

Describing OUT of SCOPE components is about identifying the points of

controversy and demystifying them as early as possible.

For example, a landscaping company is working on a project to build a

Koi Fish Pond in a residential house backyard.

The only thing we know about the project at this point is it include a Koi
Pond although we don’t have specifications. 

Naturally, the size, shape and orientation of the Koi Pond will be
discussed and determined, but areas of controversy may be:

 Garden path
 Plants
 Trees
 Rockery
The boundaries should be defined and agreed upon at phase 1 of the
Project Scope Management and be part of the inputs to initiation, thus
included in the project Charter.

Continuing the example above, if the project scope was agreed to

include:

 A pond of around 2.5 m x 2 m and 1.2 m deep containing

approximately 5500 L.
 One gravel path – 8 metre long.

It may be useful for the project manager to add:

Not Included:

 Plants
 Trees
 Vegetation
 Lawn

This may seem unnecessary but many project managers run into this
trap later on in the project when the client is asking what happened to
that components and arguing that it should have been included.

The more detailed you are the easier it would be for you to utilise this
information down the track.

Establish measurable project benefits, outcomes and outputs

Scope Statement

To develop a scope statement you will need to have:

 Product/service description
 Project charter
 Constraints
 Assumptions
When developing the Project Scope Statement you will determine
measurable project benefits, outcomes and outputs.

The scope statement includes:

 Project justification – a problem or a need that the

project was undertaken to address.
 Project’s product/service – a summary of the
product/service description.
 Project deliverables – a list of deliverables whose full
and satisfactory delivery marks completion of the project.
 Project objectives – at the very minimum; cost, time and
quality criteria that must be met. They should have an
absolute or relative value to measure the project outcome.

Examples include:

o Project must end by 30 June 2022 o Project must be completed within

a $4 m budget o All structures, materials and facilities must meet
Australian standards. If project objectives aren’t quantifiable, it’s very
hard to assess the success of the project. For example, if your objective
was “customer satisfaction”, it would be harder to know where you stand.

Establish a shared understanding of desired project outcomes

with relevant stakeholders

Who are project stakeholders?

According to the Project Management Institute (PMI), the term project

stakeholder refers to,

‘an individual, group, or organization, who may affect, be affected by, or

perceive itself to be affected by a decision, activity, or outcome of a
project’ (Project Management Institute, 2013).

Project stakeholders are entities that have an interest in a given project.

These stakeholders may be inside or outside an organization which:
 1. sponsor a project, or
2. have an interest or a gain upon a successful completion of a
project; 3. May have a positive or negative influence in the
project completion.

The following are examples of project stakeholders:

 Project leader
 Project team members
 Senior management  Project customer
 Resource Managers
 Line Managers
 Product user group
 Project testers
 Any group impacted by the project as it progresses
 Any group impacted by the project when it is completed
 Subcontractors to the project
 Consultants to the project
 Sponsors
 Individual contributors

When establishing a shared understanding of desired project outcomes

with the relevant stakeholders it is important to be precise and clear and
not to use general terms and unmeasurable objectives.

This process of scope definition involves breaking down project

deliverables from the scope statement into smaller manageable
components.

By doing that you will achieve:

 Better estimation of cost, duration and required resources

 Establish a realistic baseline
 Assign responsibilities and resources more accurately.
Adequate scope definition helps you understand the project and manage
it better to complete it on time and within budget, and to better handle
the changes as they arise.

The inputs to scope definition are:

 Scope Statement
 Constraints
 Assumptions
 Supplementary information
 Historical information

The outputs of the scope definition process are:

 Work Breakdown Structure (WBS)

 Updated Scope Statement

Work Breakdown Structure (WBS)

A WBS is a breakdown of the project activities, grouping them according

to their contribution to specific deliverables. The WBS defines the total
scope of the project and activities or deliverables that are not in the WBS
are outside the scope of the project. The second tool for Scope definition
is Decomposition.

Decomposition is the breakdown of the deliverables (or major

activities) into smaller, more manageable components until a point
where the deliverables are defined in enough detail to support the
development of project activities.

An example of a work breakdown structured is shown in the next page.

The project is the building of a new shed where an old one stood.
These are the main deliverables of the project:

 Design – an architectural design

 Demolition – a clear area to build a new shed on
 Levelling – a levelled ground because the new shed will be a
lot bigger
 Construction – a ready new shed
 Landscaping – a garden with Koi Pond and trees.

You may use a template from a previous project to create your WBS, but
remember that each project is unique and you can’t just use previous
WBS as is or sections from it without verifying accuracy and relevancy.

Document scope management plan

Scope Management Plan

While the other documents we discussed dealt with the “what” of the
project scope, this document deals with the how. The scope management
plan depict HOW the project scope will be managed and changes
integrated into the project.

This document usually include a scope stability assessment, which

simply means how likely changes to occur in this project are.

Most large scale projects encounter changes. When this happens

stakeholders must know what the process is, meaning:

 Who is asking for the changing?

 In what way is the request for change being made?
 Who is authorising the change?
 What is the process for authorising changes?  How will
changes to scope be documented?
The scope management plan is a supplementary component of the
project plan and may vary in detail and content.

Manage project scope control process

The scope management plan describes how to manage changes to scope

and we discussed how to identify project delegation and authorities. But
how will you monitor and ensure that the project is advancing according
to the agreed-upon scope?

The project baseline is the answer. The baseline is developed in the

Scope Definition step for performance measurement and control.

Baseline is the value or condition against which all future measurements

will be compared. The baseline is a point of reference. In project
management there are three baselines – schedule baseline, cost baseline
and scope baseline, and in some cases quality baseline.

Implement agreed scope management procedures and

processes

We’ve discussed procedures to manage changes to scope and now we will

take a look at some tools that will serve us in the process of monitoring
our progress and comparing actual behaviour against planned.

The tools are project baselines; scope, cost and time.

Creating the Scope Baseline

Introduction > Creating Project Charter > Creating Scope Baseline >
Creating Schedule Baseline > Creating Cost baseline > Integrated
Change Control > Risk Management > Communication Management.

The baseline is:

 Set at the end of the planning phase

 The original approved plan (and any approved scope
changes)
  The basis against which all progress will be measured

The scope baseline includes all approved plan elements that define
scope.

Baseline type Documentation purpose

1. Scope statement

2. WBS The scope baseline outlines the

Scope baseline requirements for the scope of the project
3. Additional and how the work will be broken down.

documents (optional)
1. Resource estimates

2. Cost management
This is a version of the budget, used to
Cost performance plan Budget
compare actual expenditures with planned
baseline
expenditures, over time.
3. development,
including provisions for
risk
Schedule This is a specific version of the schedule,
performance 1. Project schedule used to compare actual delivery to planned
baseline delivery.

The process of monitoring our progress involve monitoring the

Performance Measurement Baseline.

What is the Performance Measurement Baseline (PMB)?

The Performance Measurement Baseline (PMB) is a time-based budget

plan that outlines how the project will be completed and against which
performance measures it will be evaluated. The PMB is a direct output of
the project planning process; planning typically involves all known
stakeholders that have an interest in a project’s outcome.

A PMB is not a single baseline schedule, but rather is made up of several

baselines that describe the approved scope, cost and time.  
These baselines are vital for evaluating performance during the project to
judge whether the project is on track, as well as enable project teams to
re-assess scheduling throughout a project development.

Performance Measurement Baseline

The chart shows the actual cost over time against the planned scope to
complete over time (value), and the actual earned value.

In the example below we can see that the project hasn’t achieved the
planned scope on time and the earned value is lower than the planned. 

Now that you’ve had a look at the tools we can talk about the process.
The process of monitoring the baselines against actual performance is
ongoing. As project manager you should determine intervals for
performing that check. These can be periodically, i.e. daily, weekly,
monthly etc. or at milestones. It is important to undertake this
comparison of the planned baselines against actual performance at
milestones even if you have a periodic checks in place.

Milestones are another tool that will help you manage scope. 

What are project milestones?

Milestones are tools used in project management to mark specific points

along a project timeline. Completion of a certain deliverables by a
specific date may be requested by the project sponsor, the project
customer, or other stakeholders. Once scheduled, these dates become
expected and often may be moved only with great difficulty. 

Milestone events need to be part of the activity sequencing to assure that

the requirements for meeting the milestone(s) are met.

Modern project management software enable you to add diamond shape

elements to your baselines to indicate milestones in your project.
The following is an example of using milestones in the software
SMARTSHEET which we’ll be using in this course assessment.

From the Smartsheet blog:

Life is full of milestones – and so are projects.  When planning a project,

aside from laying out the tasks that take you from beginning to end,
you’re inevitably going to want to mark key dates along the way.  One
easy way to do this is through the use of a diamond shaped symbol in
your Gantt chart, the milestone.  Milestones not only help your team stay
on track, they are also useful to you as a project manager to more
accurately determine whether or not your project is on schedule. 

Incorporating milestones in your project planning helps you and your

team keep sight of:

 Key Dates Launch parties, board meetings, product

rollouts and other key dates mark significant pieces of your
project. It’s also helpful to include other one-day events
unrelated to your project specifically that are still important
for your team to keep in mind – like a group offsite or team
holiday.
 Key Deadlines Key deadlines are important to surface on
large project plans so your team can easily see what’s
coming up and plan accordingly. For example, the date that
website development is completed or when customer
conference registrations need to be returned to qualify for
early bird pricing. Key deadlines are related directly to your
project but they aren’t project tasks.  Use a key deadline as a
milestone to reflect when a section of tasks or key task is
completed.
 External Dates and Deliveries For example, a due date
for a deliverable you are expecting from an agency, the date
when your hiring manager has received an offer letter, or
the day that pipes are scheduled to be delivered. These key
events can affect when other tasks in your project are
 allowed to start.  They may also be used as predecessors in
your plan.

Scope verification

Formal Acceptance

Scope verification is the process of obtaining formal acceptance of the

project scope by the stakeholders (sponsors, client, customer, etc.). It
requires reviewing deliverables and work results to ensure that all were
completed correctly and satisfactorily. 

For example, if the project was turning office space into a classroom, the
deliverables to review could be:

 Painted walls
 New flooring
 Pictures on the walls  Electricity: wiring and lighting  New
furniture set in place.

If the project is terminated early, the scope verification process should

establish and document the level and extent of completion. Scope
verification deals with acceptance of the work results (and not the
correctness that is done in quality control). 

The scope verification is done against a number of items. The inputs to

scope verification include the actual deliverables (representing the work
result), product documentation (specifications), WBS, scope statement
and project plan.

The process of scope verification can be easily described as inspection

that may vary in nature depending on the item inspected. The object of
this inspection is to determine whether the work results conform to
requirements.

The output of this inspection process is called Formal Acceptance. This

acceptance should preferably be signed off by the customer/sponsor and
documented. Skipping this process leaves you exposed to complaints,
demands and change of requirements throughout the project.

The formal Acceptance apply to deliverables, phases or products and

these will differ from project to project but must always exist, even in
small projects.

For example, in a website project you could ask the client/sponsor to

sign and approve the following:

 Homepage design
 Inner pages design
 Homepage HTML
 Inner pages HTML
 Content Management System (CMS)
 Content uploaded
 Functioning website ready for launch

Manage impact of scope changes within established time, cost

and quality constraints according to change control
procedures

Project Management Procedures

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. They may already exist at the
organisation level, or need to be created per project.
Although they take time to develop, this will pay off as you will have a
framework in which the project can progress confidently when workers,
management and stakeholders know how to behave and what to expect.
When you have a set of procedures that allow you to be successful, you
can reuse them in future projects.        

Scope management procedures (examples)

1. Change request: a written change request form must be

filled out for every requested change to scope that will
attract one of the following:
o Delay in schedule
o Increase in cost
o Increase resources requirements
o Introduce a new risk factor
2. The request must be documented along with the approval
or reason for denying in a Scope Change register.
3. Arrange for an internal perusal of the change request by a
competent skilled person to determine the impact on
project cost and schedule.
4. If the impact on project cost, resources, and schedule falls
below a 15 hours, and the project will still be completed on
time and within budget, the project manager and client
manager may approve the scope change request.
5. Present the scope change request, alternative ways of
achieving the goal, and the impact on the project to the
sponsor / customer for a resolution. Remember to
document the result.
6. Documenting resolution results is important even if
requests are rejected, and they should by saved on the
Scope Change register marked “not approved” for future
reference.
7. If the resolution is in favour of the proposed change some
documents will need to be updated. This include:
o Appropriate activities are added to the work plan to
ensure the change is implemented
 o The project budget should be updated (if relevant)
o If the approved scope change results in a major
change to the project, the original Project Definition
should be updated and communicated to relevant
stakeholders.
8. Communicate scope change status and resolution to project
team members and other appropriate stakeholders as soon
as practicable.

Procedures and processes may vary between projects. If you are a project
manager you need to contextualise these tools and frameworks to the
project you are working on, considering:

 The nature of the work

 The environment
 The location
 The type of workers
 The stakeholders
 The conditions
 The worksite
 The performing organisation culture and attributes
 The resources you have available  The project schedule and
budget  Constraints and assumptions.

Identify and document scope management issues and

recommend improvements for future projects

Project managers may encounter many diverse problems when

managing project scope. However, three issues seem to be a common for
most projects and good handling of them will help you keep the project
on track.

1. Scope Creep

Scope creep occurs when new requirements are added on to scope. These
newly introduced requirements were not part of the initial phase of a
project, and were not considered during the planning phase. But
nevertheless, these additions or extras creep through to the execution
phase of the project, impacting schedule, cost, and resources and at
times even quality and risk. 

Scope creep does not relate to changes derive from necessity, such as
technology changes, new regulations and basic adjustments in user
needs. Scope creep refers to the additions that are not necessary and are
driven (in many of the cases) by not being able to visualise the project at
the planning phase. 

For example, in house construction, if the customers during the

execution phase decided they must have a sky window in the bedroom,
although not mentioned previously in the planning they will affect:

 Cost – sky windows cost more.

 Resources – You may not be able to use the roof
components you ordered.
 Time – This may add a few hours.
 HR – You will need a worker who knows how to handle sky
windows as not all workers do.

This is just one example, but in a real construction of a house people

realise during the build the real dimensions of the structure and how
they feel while moving in it. This alone may attract changes and scope
creep. The problem lies in the lack of ability to visualise the product. This
is why architects use 3D simulations.

In IT projects the scope creep problem is even bigger. This is due to 2

main reasons:

1. It easier to forget a technical detail/feature than a tangible

(you will more likely remember to include a basin in your
bathroom than you are to include a search feature in your
website).
2. Technology is evolving so fast that not implementing new
technologies and features in the project could mean staying
behind and defeating the purpose or some of the objectives
 of the project. For example, you are developing a mobile
app for a pet accessories franchise when location based
technology breaks, allowing you to know where your
potential clients are and which branch is closest to them.
Not incorporating the new technology in your project
means that your client will probably have to start another
project if they wish to keep up with the competition.       

2. Poorly Defined Project Scope

Let’s try and define project scope and its documentation:

Project scope is the part of project planning that involves determining

and documenting a list of specific project goals, deliverables, tasks,
costs and deadlines.

The documentation of a project’s scope explains the boundaries of the

project, establishes responsibilities for each team member and sets up
procedures for how completed work will be verified and approved. The
documentation may be referred to as a scope statement, statement of
work (SOW) or terms of reference. During the project, this
documentation helps the project team remain focused and on task.

Now, imagine the consequences of poorly defined project scope.

Immediate implications are:

 Workers aren’t sure who is responsible for which activity

because no HR assignment have been made.
 Team isn’t sure when an activity has finished because the
requirements aren’t well defined.
 Failure to meet deadlines because milestones haven’t been
properly defined.  Extra unnecessary work is being done
ending up costing more than planned.
 Necessary work may be overlooked and when remembered
it’s too late and rework cost more than planned.

And the list goes on and on.

In summary, the project manager must invest sufficient time to review,
understand and modify if necessary the project charter and for the
development of an adequate scope statement that is acceptable by
stakeholders, realistic and taking into considerations the unique nature
of the project and the conditions and resources.

3. Lack of Communication with Stakeholders

The success of project is not determined by the project manager alone.

Each project has stakeholders and that includes sponsor/customer. You
can’t be successful if your sponsor/customer is unhappy with the project
and this often comes down to their experience rather than the quality of
the end result.

Agile project management boasts effective stakeholder’s management

processes and one of the principles of that project management
methodology is indeed working closely with customers. They are not
wrong. Projects in which key stakeholders are not involved enough in the
planning phase and aren’t shown scope definition documentation tend to
run into the following problems:

 Misinterpretation of requirements – could have been

avoided in a short meeting.
 Scope creep – The more you discuss things prior to
execution the less surprises later.
 Satisfaction level – we all like to be included and involved,
especially when it’s our money.

Imagine that you engaged a builder to build a house for your family. You
invest a significant amount of money and possibly even borrowing some.
Now consider the 2 following scenarios:

Good communication with the project manager

You meet the project manager/builder several times before the project
starts and sit with them during the planning phase. You share your
thoughts, ideas, concerns and they advise you until you agree on the
general layout, ballpark figure budget, materials and time frame. You
approach an architect and share the progress and issues in the design
process with your builder, so if he/she has any input it is brought up on
time and you are not surprised later. During the execution you have not
many new ideas because you have had a long time

to think, consult, discuss and choose the right specifications. You

maintain close communication with the project manager / builder
throughout the project and they feel comfortable approaching you with
issues, ideas and thoughts. The project is completed and you have been a
part of it.

Poor communication with the project manager

You hand the builder the architectural plan designed by the architect.
You sign a contract for the building of the house. You provide an
engineering plan and wait for the project manager to deliver. 

Because you haven’t brainstormed your options with the project

manager you now have all these questions, ideas, thoughts and concerns,
but the project is already in its execution, meaning changes will cost you
more. You either keep it to yourself or become bitter about the
construction, or you ask the builder to add the changes. They price it
higher than they would in the planning phase, the schedule stretches,
budget increased and quality may compromised.

 All this could have been neutralised if you had been part of the planning.

Summary

The three commonly encountered problems are a just a small

representation of the issues and problems project managers have to deal
with, but addressing them and considering them from the first day of the
project will dramatically increase your chances of a successful delivery.
Another thing worth mentioning about communication is that even “bad
news” should be communicated to stakeholders. It is always in the
project’s long-term interest that you maintain an open and consistent
relationship with stakeholders so that problems can be dealt with when
they are still manageable.

Reasons for Poor Scope Definition

There may be different reasons for poor scope definition. Here are a few
of the leading ones;

1. Pressure to get product to market faster. Not only

that compressing project phases and skipping adequate
planning won’t get you to the market on time but they are
likely to cause cost and schedule overruns.
2. Lack of in-house design or planning capability. With
some projects, full in-house planning is not possible. Using
the construction of a residential house again, it is not likely
that you will be able to do the architectural plan for the
house better than an architect (unless you are one). But
handing the requirements off and disengage will result in
the architect and engineer taking decisions for you, and
increase the chances of failing to meet customer
expectations.
3. Overly optimistic leadership. This is usually true when
the project is similar to one that the organisation has done
before. This could lead to complacency and a slack planning
as you rely on historical data.
4. Financial pressure to minimize planning costs. It
may be the case that one or more of the key stakeholders
will want to cut the planning phase shorter and get to
business. There must always be ample time to properly plan
and develop project scope. As mentioned before, the time
saved on planning will be doubled when the undefined
activities are to be carried out in the execution phase.
5. Using vague language and terms in the project
scope statement. The scope statement must be concise
and clear and has no room for abbreviations, acronyms,
slang and other forms of language that may be
 misinterpreted. You should also avoid language that is too
general or not measurable or clear.
6. Not including the types of deliverables that are “in
scope” and “out of scope”. Defining in and out of scope
will draw a clear line for the team and help them
understand where a task begins and end.
7. Not including procedures for how completed work
will be verified and approved. See the section below.
8. Omitting guidelines for handling project change
requests that alter the scope. See change request
(above).

You have now learned about the full cycle of project Scope Management:

When considering this process of developing the Scope Baseline (Scope

Statement + WBS) we need to remember that the information (data)
used in each stage is carried on to the next. This is why we must exercise
caution with our estimates and when using historical data (information
from previous projects.

Once you have the Scope Statement and a good WBS that has been
appropriately decomposed, have people assigned to tasks and each sub
task has a duration you have your baseline.

Combined with the Cost and Time baselines you have your project
baselines ready. These baselines form the basis for project management,
and performance and deviations are compared against them.

In the next pages we will demonstrate how a project management

software tackles all the mentioned above baselines and serves as a
project plan for project managers to plan, communicate information to
team and record progress, completion, issues and changes.
The use of such software is not a condition for successful delivery, but
the world is shifting towards it as it provides mobility, flexibility and
accessibility of information across multiple devices.

Many project managers do not adopt this new technology development

because they don’t feel comfortable around computers. It is advisable for
any project manager to at least try to use such software and give it a fair
chance.