Software Project
Management
Project scope and activities
INFO 638
Glenn Booker
INFO 638
Lecture #2
1
Project Scope
 In Traditional Project Management
(TPM), it is assumed that you can
determine the goal of the project
from the onset
 The adaptive or extreme management
methods examined later will allow this
not to be true
 Capture key project objectives in the
Project Overview Statement (POS)
INFO 638
Lecture #2
2
Disclaimer
 I didn’t make up the POS acronym –
it’s not my fault
INFO 638
Lecture #2
3
Role of the POS
 The POS captures key objectives of
the project, such as the Conditions of
Satisfaction (COS)
 It should be a short document (1-2 pp)
 The COS should convey what the project
is expected to deliver and accomplish
 It should be reviewed and updated
throughout the project – it isn’t static
 It is negotiated with the customer
INFO 638
Lecture #2
4
Role of the POS
 The POS is a communications tool
among the project manager, their
development team, the customer, and
the project manager’s boss (upper or
senior management)
 The POS is a concise statement of
the project, and a summary of its
justification to continue
INFO 638
Lecture #2
5
Other Views
 The POS and COS are often known by
other terms, like the Vision or Mission
of the project
 POS and COS are Wysocki’s terminology
INFO 638
Lecture #2
6
Generating the POS
 Often the POS is developed through an
iterative process
 The customer makes a request for some major
aspect of the product (key set of features, for
example)
 The developer asks to clarify the request
 The customer provides a response
 Customer and developer agree on the response
 Repeat the previous four steps until done
INFO 638
Lecture #2
7
Non-traditional POS Uses
 The POS can help understand a
project even if not starting from
scratch
 Inheriting a project from someone else
 Using a POS as a suggestion to start an
unsolicited project
 Use a POS as a reference to guide your
team during development
INFO 638
Lecture #2
8
Parts of a POS
 The POS has five major sections





Problem/opportunity
Goal
Objectives
Success criteria
Assumptions, risks, obstacles
 Each is typically a few paragraphs
long
INFO 638
Lecture #2
9
Problem/opportunity
 This section summarizes major
problems the project will fix, and
identify significant new opportunities
of which it will take advantage
 Like the INFO 503 analysis method of
the same name, this helps prove there
is significant motivation for the project
to occur
INFO 638
Lecture #2
10
Goal
 The goal gives direction and purpose
to the project, summarizing how the
organization will address the
problems, or act on the opportunities
 Don’t commit to specific time or cost
goals – the scope of the project is too
vague for that
INFO 638
Lecture #2
11
Objectives
 The objective statements elaborate
on the goal, and clarify its scope or
boundaries
 If you meet all the objectives, then
the goal must also be met
 Each objective should define an expected
outcome, the rough time frame it will be
done, a measure, and the action needed
to meet the objective
INFO 638
Lecture #2
12
Success criteria
 Imagine the project is done, and you
want to prove how much the
organization benefited from it
 What specific measures could you make
to prove the project was worthwhile?
 These are your success criteria
 Typical criteria are increased revenue,
reduced costs, improved service, etc.
INFO 638
Lecture #2
13
Assumptions, risks, obstacles
 This is an executive summary of
major assumptions the project is
based upon, key risks to manage, and
foreseeable obstacles that will need
to be overcome
 Particularly focus on areas you might
need help managing
 More details will appear in the Project
Definition Statement (PDS)
INFO 638
Lecture #2
14
POS Attachments
 The POS can have attachments for
more information on the project
 Most common are
 A risk analysis (to show more detail than
given earlier), and/or
 A financial analysis (such as cost-benefit
analysis, feasibility studies, ROI, etc.)
INFO 638
Lecture #2
15
POS Approval
 The POS is submitted to middle or
upper management for approval
 The expected outcome is to continue
more detailed planning and analysis
for the project
INFO 638
Lecture #2
16
Expand POS into PDS
 The Project Definition Statement
(PDS) expands on the POS in two
key areas
 Objectives can be more specific, and use
more technical language to convey their
exact intent
 Assumptions, risks, obstacles can cover
more details of interest to the
development team
INFO 638
Lecture #2
17
Summary of Project Scope
 The POS and PDS capture the key
concepts needed to
 Understand the basis for the project
(why does it need to exist?)
 Demonstrate understanding of the
project risks, context, and concerns
 Provide an outline of objectives the
project will (hopefully) achieve
 And therefore justify approval for the
project to continue
INFO 638
Lecture #2
18
Work Breakdown Structure (WBS)
 The WBS gives structure to the set of
activities in a project
 It expands on the POS by describing
activities in more and more detail,
until you get down to the smallest
level of task you need to define for
your project
 The WBS is a really big ‘to-do’ list
INFO 638
Lecture #2
19
Smallest Level of Task?
 How big is the smallest level of task?
 Depends on the size of the project, and
how mature the staff are
 In general, from a couple hours to a
week might be the range
 Near term tasks are typically defined in
more detail than distant ones
 In Wysocki’s terminology, ‘tasks’ make
up the smallest level of ‘activity’
INFO 638
Lecture #2
20
WBS
 The goal of the project should be
accomplished when all tasks in the
WBS are completed
 When major activities are sequential,
they typically appear in that order in
the WBS
 The Gantt chart and PERT chart (we’ll
discuss later) are graphic forms of
the WBS
INFO 638
Lecture #2
21
Activity Decomposition
 The key to writing a good WBS is to
decompose the project goal into
major activities
 Then keep breaking those activities down
until you get to the smallest level of
tasks mentioned earlier
 A WBS with too much detail is time
consuming to generate and follow
 …not enough detail, and you miss
important tasks
INFO 638
Lecture #2
22
Why Create a WBS?
 The WBS helps plan out the process
needed to accomplish the project
 It also helps design the architecture
of the project
 It forms the basis for estimating the
time and effort needed for the project
 It establishes a baseline for reporting
project status
INFO 638
Lecture #2
23
Generating a WBS
 There are two basic approaches to
generating a WBS
 Top-down
 Start at the project goal, and keep breaking
down activities until you get to the smallest
task needed
 Can use the Team approach (have everyone
work on the schedule together) or
 The Subteam approach (agree on level 1
activities, then have subteams tackle each
activity in detail; then check for duplication and
missed tasks)
INFO 638
Lecture #2
24
Generating a WBS
 Bottom-up
 Agree on the top level activities using the
top-down approach
 Then break into teams and brainstorm all
the activities you think are within that
overall activity
 Organize the activities, and check for
missed tasks and redundancies
 Often the top-down approach results
in a more complete draft WBS
INFO 638
Lecture #2
25
Special Case WBS’s
 Small projects may want to consider
tools to help generate a good WBS,
such as mindmapping
 Large projects may need to alter the
approach to develop the top two WBS
levels as a group, then establish
subteams or teams to fill out the
details below that
INFO 638
Lecture #2
26
Are we Done Yet?
 Six criteria can help determine if a
WBS is complete
 Measurable Status – Is each task defined
in a way to help monitor its status
toward completion?
 Typically requires some kind of
measurement to assess percent completion
 Bounded – Is each task clearly bounded
by start and stop events?
 What event marks the start and stop of
each task?
INFO 638
Lecture #2
27
Are we Done Yet?
 Deliverable – Does each activity have a
clearly defined deliverable?
 What output should the activity produce?
 Cost and Time Estimate – Is each
activity defined in a way that allows a
meaningful estimate of its calendar time
and cost to completion?
 Often software cost is largely driven by the
labor cost, and hence the amount of effort
needed to develop it
INFO 638
Lecture #2
28
Are we Done Yet?
 Acceptable Duration Limits – Most
activities should be broken down into
tasks which are reasonably small
 Under two weeks is the upper limit
 There can be exceptions to this rule
 Activity Independence – Are the
activities defined to be independent of
each other as much as practical?
 Avoid activities that are too complex,
or the other extreme, micromanaging
INFO 638
Lecture #2
29
WBS Approaches
 There are three major approaches
to structuring a WBS
 Noun-type approaches
 Verb-type approaches
 Organizational approaches
INFO 638
Lecture #2
30
Noun-type approaches
 The noun-type approach means the
WBS is structured by the physical or
functional components of the project
 In a client-server system, the client and
server’s development could each be top
level WBS activities
 In assembling a car, each major
subsystem could be a WBS activity
(drivetrain, body, cabin, suspension, ...)
INFO 638
Lecture #2
31
Verb-type approaches
 Verb-type approaches focus on the
processes in the project
 Most common for software development,
this includes using each phase of the life
cycle as a top level WBS activity –
Requirements Analysis, High Level
Design, Low Level Design, Coding,
various kinds of Testing, etc.
 Could define WBS by project objectives
 Shows how close project is to completion
INFO 638
Lecture #2
32
Organizational approaches
 The organizational approach groups
activities by who does them
 Could be based on geographic location,
department, etc.
 Might be good for a distributed
development team, to help make it clear
what each group is supposed to do
INFO 638
Lecture #2
33
Showing the WBS
 The WBS can be shown as an
organization chart-like structure
(p. 93)
 This gives an overview of all the
activities
INFO 638
Lecture #2
34
Naming WBS Tasks
 The tasks in a WBS (and ideally, the
activities too) should start with a verb
 Include tasks to plan the project,
conduct the actual work of the
project, make decisions, etc.
 Task names might include ‘Prepare test
plan,’ ‘Conduct system test,’ ‘Write test
report,’ ‘Approve system release’
INFO 638
Lecture #2
35
WBS Numbering
 [This section isn’t part of Wysocki]
 Tasks and activities are often given
unique identification numbers to help
do cost accounting and generate
status summaries
 In Microsoft Project, you can add a
column called WBS which will
automatically follow this numbering
INFO 638
Lecture #2
36
WBS Numbering
 The goal of a WBS is to structure
activities to allow for unique
identification and tracking of existing
activities, while being expandable to
allow for new ones
 The WBS numbers are a series of
numbers separated by periods, used
to identify tasks on a project
INFO 638
Lecture #2
37
WBS Number Format
 The highest level of each major task
is a “whole” number (1.0, 2.0, …)
 The duration of major tasks (1.0) is
the span of all tasks under it (e.g. 1.1
to 1.3)
 Lower level tasks are components of
their higher level task (2.1 is part of
2.0), hence a short WBS number
(2.1) is a higher level task than a
long WBS number (2.1.2)
INFO 638
Lecture #2
38
WBS Number Example
 For example
 1.0 Risk Management Activities
 1.1 Develop Risk Management Plan
 1.2 Approve Risk Management Plan
 1.3 Conduct Ongoing Risk Management
 Task 1.0 is the highest level task
shown; composed of tasks 1.1 to 1.3
 Note that lower levels are indented
INFO 638
Lecture #2
39
WBS Numbering
 Numbers above nine under one task just
keep counting (e.g. 1.8, 1.9, 1.10, 1.11, …)
 The WBS numbers allow new tasks to be
inserted where needed, such as tasks
1.1.1, 1.1.2 and 1.4 in the RM example,
and yet uniquely identifies each task.
 A WBS can use as many digits as needed
(e.g. 1.2.3.14.7.6.5)
INFO 638
Lecture #2
40
Typical Software WBS
 A typical waterfall life cycle project
might use a WBS that follows the life
cycle phases





INFO 638
1.0 Do Requirements Analysis
2.0 Conduct High Level Design
3.0 Conduct Low Level Design
4.0 Conduct Coding and Unit Testing
5.0 Conduct Integration and System
Testing
Lecture #2
41
Typical Software WBS
 While that handles the development
life cycle activities, often support
activities will be broken out into
separate WBS elements
 6.0 Perform Quality Assurance
 7.0 Conduct Configuration Management
 8.0 Conduct Project Management
 This is a hybrid of the verb and
organizational WBS approaches
INFO 638
Lecture #2
42
Typical Software WBS
 Then, within each of the top level
WBS activities, you decide what
activities and tasks are needed
 Within requirements analysis, what will
you do to accomplish that?




INFO 638
Examine legacy system documentation?
Conduct interviews?
Study similar systems?
Describe use cases?
Lecture #2
43
OO WBS
 The top level WBS for an object
oriented (OO) project might follow
the Rational Unified Process life cycle
phases




INFO 638
1.0
2.0
3.0
4.0
Conduct
Conduct
Conduct
Conduct
Inception Phase
Elaboration Phase
Construction Phase
Transition Phase
Lecture #2
44
OO WBS
 For an OO project, you may not need
separate top level WBS entries for
support tasks, if they are integrated
into each phase
 Then each phase has iterations, and
you need to determine how long they
are (eventually) and what tasks
happen inside each iteration
INFO 638
Lecture #2
45
OO WBS
 1.0 Conduct Inception Phase
 1.1 Conduct iteration I-1
 1.1.1 insert tasks for this iteration
 1.1.2 insert tasks for this iteration
 1.2 Conduct iteration I-2
 1.2.1 insert tasks for this iteration
 2.0 Conduct Elaboration Phase
 2.1 Conduct iteration E-1
 2.1.1 you get the idea
INFO 638
Lecture #2
46
WBS Summary
 There is no one perfect correct way to
generate a WBS for a given project
 Many solutions could work well
 It is common to blend the noun, verb,
and organizational structures
 Such as use the verb approach for the top
level WBS, then noun or organizational for
lower level elements
INFO 638
Lecture #2
47