Software Project Management

Project scope and activities

 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)
 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 isnt static
It is negotiated with the customer
 Role of the POS
The POS is a communications tool among
the project manager, their development
team, the customer, and the project
managers boss (upper or senior
management)
The POS is a concise statement of
the project, and a summary of its justification
to continue
 Other Views
The POS and COS are often known by other
terms, like the Vision or Mission of the
project
POS and COS are Wysockis terminology
 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
 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
 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
 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
 Goal
The goal gives direction and purpose to the
project, summarizing how the organization
will address the problems, or act on the
opportunities
Dont commit to specific time or cost goals
the scope of the project is too vague for that
 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
 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.
 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)
 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.)
 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
 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
 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
 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
 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 Wysockis terminology, tasks make up the
smallest level of activity
 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 (well discuss
later) are graphic forms of
the WBS
 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
 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
 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)
 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
 Special Case WBSs
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
 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?
 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
 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
 WBS Approaches
There are three major approaches
to structuring a WBS
Noun-type approaches
Verb-type approaches
Organizational approaches
 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 servers
development could each be top level WBS
activities
In assembling a car, each major subsystem could
be a WBS activity (drivetrain, body, cabin,
suspension, ...)
 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
 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
 Showing the WBS
The WBS can be shown as an organization
chart-like structure
(p. 93)
This gives an overview of all the activities
 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
 WBS Numbering
[This section isnt 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
 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
 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)
 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
 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)
 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