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
 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
INFO 638 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?
 Examine legacy system documentation?
 Conduct interviews?
 Study similar systems?
 Describe use cases?

INFO 638 Lecture #2 43

OO WBS
 The top level WBS for an object
oriented (OO) project might follow
the Rational Unified Process life cycle
phases
 1.0 Conduct Inception Phase
 2.0 Conduct Elaboration Phase
 3.0 Conduct Construction Phase
 4.0 Conduct Transition Phase

INFO 638 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