CREATING THE SOFTWARE SCOPE

 One wouldn’t start creating a new piece of software without

knowing what the software will actually do.
 Out here in the real world, stakeholders present project
managers with software wish lists.
 They expect the project manager and the project team to
create a stellar deliverable. You can’t create a stellar software
product unless you know what it is supposed to do.
 One must work with the stakeholders to create the product
scope in order to identify the key elements of the product so
that one can determine the best path to successfully
completing the project.
 We need to learn how to work with the project team and
stakeholders to gather requirements and how to understand
and manage potential conflicts.
 UNDERSTANDING PRODUCT SCOPE
AND PROJECT SCOPE
 The product scope is the summation of the attributes and features
that will comprise the product you’re creating for your customer.
 When the stakeholders are in agreement on the product scope,
then you can focus on creating the software project scope.
 The difference between the two is that the product scope describes
the end result of the project — the things the customer sees.
 The project scope describes the work that must be completed in
order to complete the project — the things the project manager
focuses on.
 The product scope and the project scope support one another. The
best way to determine the product scope is to analyze the concrete
needs and expectations of the stakeholders.
UNDERSTANDING PRODUCT SCOPE
AND PROJECT SCOPE
 STAKEHOLDER ANALYSIS
 Stakeholder analysis is the process of determining who
your stakeholders are and what their interests and
concerns for their project are. As the project manager,
you inherit their vision of the software solution.
 A stakeholder, technically, is anyone who has a vested
interest in your project’s success. The PM, project team,
project sponsor, customers, clients, or project champions.
 In a large organization, you may not immediately know
who all of the stakeholders are. The software you create
for the sales department, for example, may have ripples
into manufacturing, marketing, training, and even
distribution.
 STAKEHOLDER ANALYSIS
 One of your most important responsibilities is to
interview your stakeholders. This is a vital step because it
ensures that you are in tune with what the project
stakeholders really want.
 When gathering stakeholder requirements and other
information, be sure you have considered all
stakeholders, not just those that are the most visible.
 Stakeholder analysis isn’t just examining who the
stakeholders are — but also their demands and wishes
for the project deliverables.
 STAKEHOLDER ANALYSIS
You’ve got to ask lots of questions, for example:
 Can you describe the conditions this deliverable will operate in?
 What’s the opportunity this project will grasp?
 What’s the main problem this software will solve?
 How do you see the deliverable solving your problem?
 What other software will this deliverable interact with?
 What are the primary and secondary features of the software?
 How will this software make the end-users’ jobs better or easier?
 Are there other stakeholders that we should consider?
 How do you see this deliverable benefiting your customer?
 STAKEHOLDER ANALYSIS
 Questions should be open ended but focused.
 Make sure that the stakeholder has an opportunity to
talk in his or her own words about the expectations and
goals of the software
 But lead the discussion so that the answers you receive
are specific enough to help you plan the project
effectively.
 One of the most effective ways of completing stakeholder
analysis is to put yourself in the stakeholders’ shoes.
MANAGING STAKEHOLDER OBJECTIVES
 Don’t expect stakeholders to play nicely with each other.
 Stakeholders have individual personalities, and
competing stakeholder objectives can haunt a project
through its duration.
 Sometimes, stakeholders don’t know exactly what they
want and they’re counting on you to show them.
 Proceed with caution when you’re working with
stakeholders don’t know exactly what they want.
MANAGING STAKEHOLDER OBJECTIVES
 Stakeholders who don’t know exactly what they want will
expect you and your project team to create software that
they can try and then modify. And then the process starts
over
 Stress to the stakeholder that you both must have a clear
vision of what the project will create. Without a real
grasp on the deliverables, writing an effective project
scope — let alone creating an effective application — is
impossible.
MANAGING STAKEHOLDER EXPECTATIONS
 Knowing the sources of common conflicts. Project
Management Institute (PMI) rank the following conflicts
in order of frequency:
 Schedules
 Priorities
 Resources
 Technical beliefs
 Policies and procedures
 Costs
 Personalities
 RESOLVING COMMON CONFLICTS
To help resolve conflicts, we’ve got five approaches:
 Problem solving
 Forcing
 Compromising
 Smoothing
 Withdrawal
 BUILDING THE SOFTWARE SCOPE
 When you and the stakeholders have a clear vision of where the
project’s going, you need a clearly defined set of requirements.
 Early on in the project, you and the key stakeholders define what
must be in the project and what would be nice to have in
software.
 Document scope changes and allot time to research their true
impact; be sure you’re examining their impact on the project, as
well as on other projects; sometimes the code you change for one
project can affect other systems as well.
 Requirements are the things your software must create in order
for the customer to accept the project deliverable. Creating good,
clear requirements takes time, patience, and input from all the
stakeholders, including the project sponsor, the quality assurance
folks . . . and the application testers.
 Dealing with regulations and options
 The software project scope is created based on the product
scope.
 But not everything is really a requirement.
 Some facets of your software may be optional.
 It’s a great idea to identify, or at least prioritize, the things your
project will create.
 Getting everything straight enables you and the project team to
evaluate the core functions of the application versus the optional
features.
 ADHERING TO REGULATIONS
 A rule that has a punishment attached to it — like jail,
fines, or both — is typically a regulation.
 Regulations are not optional. You must obey them.
 The difference between a standard and a regulation is
significant.
 A standard is a particular set of guidelines to which you
agree to adhere. For example, a naming convention, the
method for documenting programming comments, and
file formats are examples of standards.
 A regulation, on the other hand, is a requirement
imposed by a government body.
 Choosing options
 At the beginning of a project, stakeholders may believe
that nothing is optional.
 They’ll want every feature, every button, and every
concept they’ve dreamed up.
 Then you and your experts must discuss the feasibility
of their wishes, the cost of the plans, and offer a
realistic timetable to deliver everything stakeholders
want.
 At that point, light bulbs will go off and the stakeholders
will quickly discover what’s optional and what’s not.
 WHY PRIORITIZE NEEDS AND WANTS
 Money: Software design takes time and time costs money.
• Time: If you’re crunched for time, picking which components can be
shoved to the side first and which components must be created if you’ve
prioritized is much easier when you know in advanced what’s desirable
and what’s absolutely essential.

• Stakeholder buy-in: Stakeholders know that you know which

features you should focus on first, and which components are optional
based on the project’s health.
• Project manager’s sanity: Leading, creating focus, and making
decisions based on assigned priorities is much easier than tacking on new
components and removing them.
• Negotiations: If you know there are elements the customer would
like in your deliverable, but they aren’t defined as requirements, you
have bargaining chips.
 GETTING TO THE SIGNATURE
 A requirements document that identifies everything the
project promises to create is needed after discussions.
 Requirements document may be an in-depth product
description, statement of work, contract, or a formal
documentation of all of the features and components
your project is responsible for creating.
 Product scope may also serve as your requirements
document with simple modifications. This document
sets expectations and is the groundwork for creating the
formal project scope.
 GETTING TO THE SIGNATURE
Signed requirements document on hand:
 Identifies what you and your project team will create for the
stakeholders
 Identifies that the stakeholders are in agreement as to what the
project requirements are for your project
 Identifies that you understand the software functionality the
stakeholders are expecting as a result of your work
 Allows you and the stakeholders to fully share in the project buy-
in by agreeing to the things your project will create
 Acts as a checklist to ensure that you meet all the requirements
 Serves as future historical information for other project managers
in your organization
CREATING THE PROJECT SCOPE
 PROJECT SCOPE STATEMENT
There are certain items that absolutely must be included
in the project scope statement:
 Deliverables
 Assumptions
 Exclusions
 Functions
 Technical structure
 Influences
 Other projects
 A PROJECT SCOPE DOESN’T INCLUDE
 While the project scope details what the project will do,
it must also implicitly define what’s not included.
 By definition, if something’s not included in the list, it’s
not in scope.
 Anything that’s added to the scope of a project that’s
already underway will affect the schedule and budget.
 There must be a consensus among the project
stakeholders as to what’s in scope and what’s out of
scope.
 A WORK BREAKDOWN STRUCTURE
 A work breakdown structure (WBS) is a visual
representation of everything the project will create.
 Typically, a WBS includes things (deliverables,
components, and so on), not activities.
 However, there’s no hard-and-fast rule on exempting
activities from your WBS.
 Its better to keep work out of the WBS and focus on the
things the work will create.
 Some actions, such as testing, ordering, and compiling,
etc. can be taken as WBS.
 Most of our WBSs are comprised of deliverables.
 A WORK BREAKDOWN STRUCTURE
 WBS is also scope baseline.
 The WBS is a direct input to scope verification, which is
a fancy way of saying customer acceptance.
 The traditional WBS is a flowchart of objects.
 Another style of WBS looks more like a shopping list.
 A PM should be open to whichever approach works best
for each project.
 A WORK BREAKDOWN STRUCTURE
The WBS to do any of the following, which are crucial:
 Cost estimating. The WBS allows you to create accurate cost estimates
to create the thing the project requires.

 Cost budgeting. The WBS allows you to track actual costs against the
estimates for the things your project will create.

 Resource planning. By creating the WBS, PM can accurately capture

everything (people and things) needed to complete the project.

 Risk management planning. The WBS illustrates the things to be

created and then provides a clearer picture of where risks may be hiding.

 Activity definition. The end result of the WBS is to create an activity

list. The activity list, or activity definition, lists all of the actions your
project team will need to do to build the stuff in the WBS.
 THE 8/80 RULE
 This is a general guideline that breaks down items into work
packages.
 A work package is a unit of time allotted to a task or deliverable.
 The 8/80 Rule says that a work package should equate to no
more than 80 hours of work and not less than 8 hours of work to
create the deliverable.
 The 8/80 Rule is really a heuristic — a broad rule and you don’t
have to live and die by the rule.
 There’ll be some deliverables you want to reflect, like licensing
agreements, that won’t actually take 8 hours of work to create.
 It’s perfectly fine to have exceptions to the 8/80 Rule if it helps
you complete your project.
 GETTING THE WBS
1. Break down the scope into major buckets of things the project
will create.
Some project managers like to envision the phases of the project to
serve as main components and some prefer to think in broad
categories of deliverables.
For example, you might decompose a project scope into
 Project management deliverables

 Database deliverables

 Server deliverables

 End-user deliverables

 Education and documentation deliverables

 GETTING THE WBS
2. Decompose these deliverables again into smaller units or
work packages.
 If you’ve decomposed deliverables down and the smallest
item you have still equates to 400 hours of labor, break down
the WBS some more.
 Making updates to the WBS
 The WBS creation is part of planning
 WBS gets updates and refinements many times.
 In fact, sometimes change requests will trickle in.
 You should revisit the WBS to reflect the approved
changes to the project.
 The danger of not consistently updating the WBS to
reflect changes will be evident when the final
deliverable doesn’t match what the WBS has promised.
 Not modifying the WBS when you ought to can cause
several problems.
 Making updates to the WBS
The WBS is your scope baseline, so any changes to the
scope must be documented. Else:
 Time and cost baselines may be skewed because they don’t
match what’s in the WBS.
 Your customer may be confused as to why the WBS doesn’t
match the deliverable you’ve provided.
 Project team members may be out of synch about what they’re
supposed to be creating and what the WBS calls for.
 If someone in management reviews the WBS and the project
deliverables don’t match up, you have to have that conversation.
Nobody wants to have that conversation. Especially you.
 Future projects based on your current project will have faulty
information.