Scope Management- A Key Player in Understanding the True

Business Requirements

Amlan Chakrabarti
A.K.Choudhuri School of Information Technology, University of Calcutta
92 A.P.C. Road Kolkata-700009, India. email:achakra12@yahoo.com

Abstract: The achievement of true “success” in information technology projects is still an elusive goal for
many organizations. The issues mainly focuses on the review of the project cost, delivery schedule,
implementation and scope fulfillment as delivered, compared to the initial plan in a relative reference
scale. A project that is being envied certainly goes for a bulls-eye attainment of these items. The key factors
for achievements are, a well-engineered starting scope definition and a proper Work Breakdown Structure
(WBS). A good project planning effort serves as a good baseline plan for understanding the business
requirements and helps the project managers to visualize the potential problems and mitigate them and
their impact to the project. This additional effort plays a key role in understanding and satisfying the true
needs of a quality project. This paper tries to establish the impact of scope management in context to the
challenging and emerging information technology application scenarios.

1. Introduction
Scope refers to all the work involved in creating the products of a project and the processes used to create
them. Determining scope is an exercise, which leads to the development of a common understanding as to
what is included in, or excluded from, a project. The project scope defines the boundaries of the project -
what is included in the project and what is to be achieved: who the client is, the objectives and the
deliverables. By default, the project scope also indicates what is not included in the project (if it is not in
the scene, it is not in the project). Scope is defined at a high level by describing the boundaries and
deliverables of the project, it adds more detail to that definition through the gathering of the true business
requirements. Once the sponsorer agrees to these items, the overall scope change can be managed through a
simple scope change process. It is to be remembered that having the scope and business requirements
approved doesn't mean nothing can change from that point on. It means instead that it is required to manage
the overall change process from that point forward using a good scope change management process. A
successful project outcome depends on an effective project management plan, development and execution,
and adherence to a scope management process. It also begins with the proper integration of related project
elements across project process groups and knowledge areas. The integration processes comprises of the
following features:
• Developing the project charter
• Preliminary scope statement, and project management plan
• Directing and managing project execution
• Monitoring and controlling project work
• Change control
• Project closeout

2. Scope Management
Project scope management includes the processes involved in defining and controlling what is or is not
included in a project. Anyone who has ever done a project will have tales of how scope changes caused
grief. Scope is bound to change, and this is to be expected. As the detail becomes clearer, more
complications creep in. These are not foreseeable at the start and hopefully we build in a contingency for
what we cannot see. The scope changes that usually cause problems are those where the perception of what
was in and out of scope was different between various parties. For an example project the Project Manager
assumed there would only be four or five reports, and the business assumed ten to twenty, nobody felt it
was worth talking about because they assumed the other person thought the same way they did.
 The key issues in scope management are:
• Requirements
• Constraints
• Assumptions
• Risks
Requirements are the ultimate objectives of the project. Constraints are limitations such as: time,
resource dependency, business, legal, organizational, technology and management. Assumptions consider
facts for planning purposes, for example a new system will not require routine IT resources and
involvement. Risk is any business or technical factor that has reasonable potential to impact the project.
Risk characteristics: probability, impact, mitigating action, and contingent action. Project scope
management processes as demonstrated in Figure 1, majorly includes the following processes involved in
defining and controlling what is or is not included in a project:
• Scope planning: Deciding how the scope will be defined, verified, and controlled.
• Scope definition: Reviewing the project charter and preliminary scope statement and adding more
information as requirements are developed and change requests are approved.
• Creating the WBS: Subdividing the major project deliverables into smaller, more manageable
components.
• Scope verification: Formalizing acceptance of the project scope.
• Scope control: Controlling changes to the project scope

Figure 1: Steps of Scope Management

2.1 Scope Plan
The scope plan is a document that includes descriptions of how the team will prepare the project scope
statement, create the WBS, verify completion of the project deliverables, and control requests for changes
to the project scope.

2.2 Scope Definition

The preliminary scope statement, project charter, organizational process assets, and approved change
requests provide a basis for creating the project scope definition statement. As time progresses, the scope
of a project should become clearer and more specific. There are numerous ways to define. Ideally several
ways should be used. Each looks at the situation from a different perspective and will elicit different
information. We look at three main ways in this paper. They are:
• Define Deliverables
• Define Functionality and Data
• Define Technical Structure

2.3 Work Breakdown Structure

WBS is a deliverable-oriented grouping of the work involved in a project that defines the total scope of
the project. It is a foundation document that provides the basis for planning and managing project
schedules, costs, resources, and changes. A sample WBS for intranet application is being demonstrated in
Figure 1.
 Figure 2: A sample WBS for Intranet Application

The key approaches followed for the development of the WBS are:

Guidelines: Some organizations provide guidelines for preparing WBSs.

Analogy approach: Review WBSs of similar projects and tailor to your project.
Top-down approach: Start with the largest items of the project and break them down.
Bottom-up approach: Start with the specific tasks and roll them up.
Mind-mapping approach: Write tasks in a non-linear, branching format and then create the WBS
structure.

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

2.4 Scope Verification

It is very difficult to create a good scope statement and WBS for a project and even more difficult to verify
project scope and minimize scope changes. Many IT projects suffer from poor scope verification.

2.5 Scope Control

Scope control involves controlling changes to the project scope. Goals of scope control are to:
• Influence the factors that cause scope changes.
• Ensure changes are processed according to procedures developed as part of integrated change
control.
• Manage changes when they occur.

3. Managing Scope Changes

Controlling and managing scope change is critical to the success of any project, as scope changes can
significantly impact the cost, schedule, risks and quality of the entire effort. While scope is defined early in
the planning and estimation phases, there are many reasons for changing it later on — for instance, a
stakeholder may acquire additional insight into a problem during the course of the project. In addition to
internal factors, external market conditions and government regulations often drive requests that extend
beyond the initial project scope. The key to successful scope management is defining, communicating and
reconciling emerging requests throughout the project lifecycle. No one questions the relevance of change
management for project scope, which can involve project deliverables, services, and work content. In
particular, there are four strong reasons why scope management must be a top priority for the successful
project manager:
• Cost: Scope change can affect work that has been already performed. This means rework costs for
work that has already started or worse, been completed.
• Schedule: With each scope change, precious project resources are diverted to activities that were
not identified in the original project scope, leading to pressure on the project schedule. The project
manager must also consider impact on the project’s critical path.
• Quality: When not analyzed thoroughly, scope changes lead to quick fixes that can affect product
quality.
• Morale: Scope changes can cause a loss of control of the team’s planned work. Changing focus or
direction to meet the change requests adversely impacts team morale.

We look into the techniques utilized for keeping scope change on track:
• Proactive Change Identification: Scope changes are waiting to happen, so the project manager
should take an active role in identifying these changes with stakeholders. By being proactive, the
project manager can incorporate the vital few changes that account for 80% of the stakeholders’
issues and concerns.
• Sponsor Approval: Always get the sponsor’s approval and buy-in for the change request before
authorizing any related work. If it is difficult to have the sponsor review every change, ask him/her
to review a set of change requests. Alternatively, the change can be classified as routine or in need
of further analysis.
• Thorough Impact Analysis: It’s easy to conduct a superficial change impact analysis, however
the repercussions are not very pleasant. An impact analysis needs to consider all the configuration
items that will be affected by the change and associated costs.
• Communicate Changes: In a large project team, changes can be overlooked if they are not
communicated in a timely way. People like to know what they are working on and to be kept
informed of project decisions. Proper team communications are essential to understanding and
overcoming resistance to change.
• Avoid Scope Creep: Scope creep occurs when changes are allowed without proper impact
analysis, and without reviewing schedule and cost implications. This is common with repetitive
minor incremental adjustments, where the project budget and schedule are not kept in sync with
the effort involved for the changes. In this scenario, there is no way to avoid a runaway project
syndrome. Scope creep is a symptom of a process problem; the solution is to implement a process
to track each change and control its implementation

Here's a simple scope change process that can be used for a given project.
• Potential scope change requests from any project stakeholder need to be solicited, including the
project team, clients, sponsors, etc.
• Smaller projects can document the scope change in a short form or an e-mail. For larger projects,
the scope change request should be formally documented using a Scope Change Request Form.
The important thing is that you need to document the scope change in writing. Don't act on scope
change requests you receive verbally.
• The requests are to be entered into the Scope Change Log for tracking purposes.
• The person making the scope change request should define the business value to the project. The
sponsor will need this information to make a final decision.
• The project manager will assign the scope change request to a team member for further
investigation. (The project manager could assign it to himself.) The team member will first
determine how much time it will take to investigate the scope change request. If the time required
to perform the analysis will cause deliverable dates to slip, the request must first be taken to the
sponsor to determine whether the request should be investigated or not. If the sponsor gives the
initial approval to proceed, the workplan and budget may need to be updated to reflect this new
work. If the sponsor does not agree to investigate the change request, then the request should be
placed closed as "not approved" on the Scope Change Log.
 • The scope change request, alternatives, business value and project impact needs to be
communicated to the sponsor for a resolution (yes we do it or no, we don’t do it).
• The resolution or course of action needs to be documented
• The resolution is to be documented briefly on the Scope Change Log. If the Sponsor does not
agree to the change request, then the request should be closed as 'not approved' on the Scope
Change Log.
• If the scope change request is approved, the appropriate activities are added to the workplan to
ensure the change is implemented. The project budget should also be updated, if necessary.
• The current Project Definition (Charter) should be updated if an approved scope change results in
a substantial change to the project.
• Throughout the process, it is to be ensured that you communicate all scope change status and
resolution to project team members and other appropriate stakeholders. This is usually done by
attaching the current Scope Change Log to the Status Report. This helps manage expectations and
shows how approved scope change requests are impacting the project end date and budget.

4. Conclusion
In this work the major issues of scope management as well issues regarding controlling and managing
scope changes in context to information technology management have been discussed. It comes out
unanimously that in present scenario of highly competitive schedules of I.T. project development, scope
management plays a key role. It has also been briefed that a scope management endeavor leads to the
understanding of various sub-processes and proper measures are to be taken for the ensuring of the quality.
A detailed analysis is being done to get an insight of the scope change process and the roles of the key
actors are being identified.