Lecture note 7

Scope Planning

The scope of work defines exactly what will be done as a result of the project work. It's important to
know exactly what is to be done to avoid wasting both time and money on tasks and activities that
are not necessary to accomplish the project goals. That's why scope planning is so important. This
chapter will address how to define the scope of work based on the requirements of the end result
and the deliverables of the project.

Defining the Scope

You already have a head start on refining the project's objectives in quantifiable terms, but now you
need to plan further and write down all the intermediate and final deliverables that you and your
team will produce over the course of the project. Deliverables include everything that you and your
team produce for the project (i.e., anything that your project will deliver). The deliverables for your
project include all of the products or services that you and your team are performing for the client,
customer, or sponsor. They include every intermediate document, plan, schedule, budget, blueprint,
and anything else that will be made along the way, including all of the project management
documents you put together. Project deliverables are tangible outcomes, measurable results, or
specific items that must be produced to consider either the project or the project phase completed.
Intermediate deliverables, like the objectives, must be specific and verifiable.

All deliverables must be described in a sufficient level of detail so that they can be differentiated
from related deliverables. For example:

 A departmental solution versus an enterprise solution

 A red marker versus a green marker
 A twin-engine plane versus a single engine plane
 A daily report versus a weekly report

One of the project manager's primary functions is to accurately document the deliverables of the
project and then manage the project so that they are produced according to the agreed-on criteria.
Deliverables are the output of each development phase, described in a quantifiable way.

Project Requirements

After all the deliverables are identified, the project manager needs to document all the requirements
of the project. Requirements describe the characteristics of the final deliverable, whether it is a
product or a service. They describe the required functionality that the final deliverable must have or
specific conditions the final deliverable must meet in order to satisfy the objectives of the project.

A requirement is an objective that must be met. The project's requirements, defined in the scope
plan, describe what a project is supposed to accomplish and how the project is supposed to be
created and implemented. Requirements answer the following questions regarding the as-is and to-
be states of the business: who, what, where, when, how much, and how does a business process
work?

Requirements may include attributes like dimensions, ease of use, colour, specific ingredients, and so
on. If we go back to the example of the company producing holiday eggnog, one of the major

1
deliverables is the cartons that hold the eggnog. The requirements for that deliverable may include
carton design, photographs that will appear on the carton, colour choices, etc.

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

A. Functional Requirements

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

Examples:

1. Vehicles

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

2. Computer System Example

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

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

B. Non-Functional Requirements

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

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

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

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

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

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

2
  The length of time a record should be held for auditing purposes.

For the customer records example, the constraints might be:

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

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

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

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

Time: When a deliverable should be delivered

Resource: How much money is available to develop the deliverable

Quality: Any standards that are used to develop the deliverable, development methods, etc.

Technical Requirements

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

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

Business Requirements

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

User Requirements

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

Regulatory requirements

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

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

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

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

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

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

Software Requirements Fundamentals

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

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

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

4
Measuring Requirements

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

Property Measure

 Processed transactions/second

Speed  User/Event response time

 Screen refresh time

 K Bytes
Size
 Number of RAM chips

 Training time
Ease of use
 Number of help frames

 Mean time to failure

 Probability of unavailability
Reliability
 Rate of failure occurrence

 Availability

 Time to restart after failure

Robustness  Percentage of events causing failure

 Probability of data corruption on failure

 Percentage of target dependent statements

Portability
 Number of target systems

Table 9.1. Measuring Requirements

5
Scope Inputs

The project manager gathers initial project facts from the project charter. In addition, background
information on the stakeholder's workplace, existing business model and rules, etc. assist in creating
the vision of the final product/service, and consequently, the project scope

Techniques
Certainly, being a seasoned project manager broadens the repertoire of one's scope planning
techniques. An experienced project manager can draw on past experiences with similar projects to
determine the work that is realistically doable, given time and cost constraints, for a current project.
Communication and negotiation skills are a "must-have" as well. Project managers need to educate
stakeholders about the project impacts of some requirements. Adding complexity to a project may
require more staff, time, and/or money. It may also have an impact on project quality. Some aspects
of the project may be unfeasible – stakeholders need to know this so they can adjust their vision or
prepare for future challenges.

Gathering requirements is part of scope definition, and it can be done using one or more of following
techniques:

 Interviews
 Focus groups
 Facilitated groups such as JAD (joint application development)
 Group creativity techniques: brainstorming, nominal groups, delphi, mind map, affinity
diagnostics
 Prototyping
 Observation
 Questions and surveys
 Group decision-making techniques: unanimity, majority, plurality, dictatorship

6
Requirements Traceability Matrix
The requirements traceability matrix is a table that links requirements to their origin and
traces them throughout the project life cycle. The implementation of a requirements
traceability matrix helps ensure that each requirement adds business value by linking it to
the business and project objectives. It provides a means to track requirements throughout
the project life cycle, helping to ensure that requirements approved in the requirements
documentation are delivered at the end of the project. Finally, it provides a structure for
managing changes to the product scope. This process includes, but is not limited to, tracking:

 Requirements to business needs, opportunities, goals, and objectives

 Requirements to project objectives
 Requirements to project scope/work breakdown structure deliverables
 Requirements to product design
 Requirements to product development
 Requirements to test strategy and test scenarios
 High-level requirements to more detailed requirements

Attributes associated with each requirement can be recorded in the requirements

traceability matrix. These attributes help to define key information about the requirement.
Typical attributes used in the requirements traceability matrix may include a unique
identifier, a textual description of the requirement, the rationale for inclusion, owner, source,
priority, version, current status (such as active, cancelled, deferred, added, approved), and
date completed. Additional attributes to ensure that the requirement has met stakeholders'
satisfaction may include stability, complexity, and acceptance criteria.

Work Breakdown Structure

Now that we have the deliverables and requirements well defined, the process of breaking
down the work of the project via a work breakdown structure (WBS) begins. The WBS
defines the scope of the project and breaks the work down into components that can be
scheduled, estimated, and easily monitored and controlled. The idea behind the WBS is
simple: you subdivide a complicated task into smaller tasks, until you reach a level that
cannot be further subdivided. Anyone familiar with the arrangements of folders and files in a
computer memory or who has researched their ancestral family tree should be familiar with
this idea. You stop breaking down the work when you reach a low enough level to perform
an estimate of the desired accuracy. At that point, it is usually easier to estimate how long
the small task will take and how much it will cost to perform than it would have been to
estimate these factors at the higher levels. Each descending level of the WBS represents an
increased level of detailed definition of the project work.

WBS describes the products or services to be delivered by the project and how they are
decomposed and related. It is a deliverable-oriented decomposition of a project into smaller
components. It defines and groups a project's discrete work elements in a way that helps
organize and define the total work scope of the project.
A WBS also provides the necessary framework for detailed cost estimating and control, along
with providing guidance for schedule development and control.

Overview

7
WBS is a hierarchical decomposition of the project into phases, deliverables, and work
packages. It is a tree structure, which shows a subdivision of effort required to achieve an
objective (e.g., a program, project, and contract). In a project or contract, the WBS is
developed by starting with the end objective and successively subdividing it into manageable
components in terms of size, duration, and responsibility (e.g., systems, subsystems,
components, tasks, subtasks, and work packages), which include all steps necessary to
achieve the objective.

The WBS creation involves:

 Listing all the project outputs (deliverables and other direct results)
 Identifying all the activities required to deliver the outputs
 Subdividing these activities into sub activities and tasks
 Identifying the deliverable and milestone(s) of each task
 Identifying the time usage of all the resources (personnel and material) required to
complete each task
The purpose of developing a WBS is to:
 Allow easier management of each component
 Allow accurate estimation of time, cost, and resource requirements
 Allow easier assignment of human resources
 Allow easier assignment of responsibility for activities

100 Percent Rule

The 100 percent rule is the most important criterion in developing and evaluating the WBS.
The rule states that each decomposed level (child) must represent 100 percent of the work

8
applicable to the next higher (parent) element. In other words, if each level of the WBS
follows the 100 percent rule down to the activities, then we are confident that 100 percent
of the activities will have been identified when we develop the project schedule. When we
create the budget for our project, 100 percent of the costs or resources required will be
identified.

Scope Statement

Scope statements may take many forms depending on the type of project being
implemented and the nature of the organization. The scope statement details the project
deliverables and describes the major objectives. The objectives should include measurable
success criteria for the project.

A scope statement captures, in very broad terms, the product of the project: for example,
"development of a software-based system to capture and track orders for software". A scope
statement should also include the list of users using the product, as well as the features in
the resulting product.

As a baseline scope statement should contain:

 The project names
 The project charter
 The project owner, sponsors, and stakeholders
 The problem statement
 The project goals and objectives
 The project requirements
 The project deliverables
 The project non-goals (what is out of scope)
 Milestones
 Cost estimates
In more project-oriented organizations, the scope statement may also contain these and
other sections:
 Project scope management plan
 Approved change requests
 Project assumptions and risks
 Project acceptance criteria

Questions
1. You have joined a software development project as project manager when it was
in execution stage. You and your team is busy on it since last 4 months. So far the
project is on track. But there is one work package which is troubling you. Nobody
exactly knows who is responsible for it. Even the work associated with it is unknown.
Account department is unaware of its code of account. Which of the following would
best help you in this situation.

A. Scope Management Plan B. Work Breakdown Structure

C. Scope Management Plan D. WBS Dictionary

9
2. You are working on project scope statement of a software project. You are
analyzing the expected deliverables by generating different ways of executing and
performing the deleverable. You select the best menthod for creating that
deleverable. Which of the following describes what you are doing
A. Decomposition B. Alternative Identification
C. Scope definition D. Stakeholder Analysis

3. An input to define scope process is:

A. Decomposition B. Project Charter
C. Work Breakdown Structure (WBS) D. Contract

4. You are working with a Not-for-Profit organization. You have been assisgned the
working of hosting a 10 kilomer walk. You have worked on a similat project of hosing
a 5 kilometer walk two years back. Which of the oraganizational process assets will
help you.
A. Financial control procedure
B. Issue and defect management database
C. Historical information and Lessons learned from previous phases or projects
D. Risk Control procedure

5. The following is true about WBS

A. The WBS is another term foe Gantt (Bar) chart
B. The WBS shows only critical path activities
C. Work not in WBS is usually defined in the scope statement of the project
D. Each descending level represents an increasingly detailed description of the
project deliverables.

10