Building work packages from requirements (from mm)(larger version)

Copyright 2007, All Rights Reserved
1
Building Work Packages from
Requirements
Using well formed requirements, Work Packages can be constructed
directly from the Work Breakdown Structure

Copyright 2007, All Rights ReservedCopyright 2007, All Rights Reserved
Agenda
 Building a well structured set of
requirements
 Deriving the Work Break Down
Structure
 Identifying Work Packages
 Constructing the Work Packages
2

Outcomes of today’s presentation
 Assessing the structure of the
current requirements
– Gaps in the topology
– Closure activities
 Getting ready to build the Work
Breakdown Structure (WBS)
– Decomposition tree of the WBS
– Defining business capabilities
– Defining deliverables that enable
those capabilities
3

4
Assessing the Current Requirements
Structure
The current requirements process is likely consider well on its way to
completion. But let’s assess the structure of the requirements, rather than the
requirements themselves. The better the structure the better the WBS and the
better the cohesion of the Work Packages

Requirements structuring starts with an
assessment of their cohesion
 Cohesion is defined as…
– a measure of the degree to which the
elements of a module belong
together
 It really means the measure to
which the tasks performed by a
module are functionally related
5
Let’s borrow
from the Object
Oriented world a
bit and assess
how well the
current
requirements
exhibit
cohesion.
Are they well
formed in that
each
requirement is
properly
isolated from
other
requirements

A simple Requirements Flowdown
Tree
6
Flowing down
requirements
from the top
level is a simple
approach.
Unfortunately
this is almost
never the real
world of
software
business
requirements
elicitation

A nice clean partitioning of
Capabilities into Functions
7
For each
business
capability we
can identify the
functions that
deliver that
capability.
Each function
performs a
service that is
nicely isolated
from the other
functions.
This creates a
high level of
cohesion and a
lower level of
coupling

A partitioning of Capabilities into
Functions more like Reality
8
Now this picture
probably
represents
reality.
The functions of
the underlying
system are used
to deliver
different
capabilities.
Coupling is
increasing.
Cohesion is
decreasing.
The rats nest is
starting to form
Trouble Happens Here

Let’s look at a simple approach to
managing the problem
 Make the connection
between what the
customer wants and
what capabilities
exist
 Do this BEFORE
flowing down
requirements into
functions
 Do this at the
Capabilities level of
the requirements
9
This simple
approach may
or may not be
possible on
Meridian 2/3.
It’s really out of
our hands at
this point. But
worth a visit all
the same

Let’s Pretend we could solve what ever problems
we have with the requirements flowdown process
10
There are a set
of processes
that can be
performed
before we get to
this stage.
These process
lay the
groundwork for
developing a
well formed
Work
Breakdown
Structure

Continuing to play Let’s Pretend
 What does the coupling and
cohesion of the current
requirements look like?
 Are the current requirements
capable of identifying a clear and
concise partitioning of the work?
11
Let’s take a
break for a
moment and
look through the
current
requirements
Structure to see
where we are
regarding
coupling and
cohesion

Let’s look at the requirements
 Are they structured in
some logical
manner?
 Can we trace a
business requirement
to a system capability
and them to a system
function?
 What is the sense of
coupling and
cohesion of these
requirements?
12

13
Building our 1st Work Breakdown
Structure
Building the WBS is an iterative and incremental process, so let’s take a
cut at the first iteration

Getting to a Work Breakdown Structure
(WBS) starts with well formed requirements
 Mapping requirements to a WBS
starts with an assessment of the
requirements topology
 Coupling minimized
 Cohesion maximized
 Parent child relationships defined
14
The assumption
that there is a
set of well
formed
requirements
needs to be
tested before
proceeding.
This can be
done with a
simple test

What does a good WBS look like?
 It’s not a laundry list of work to be
done
 It’s not a functional decomposition
 It’s not a direct map of the
requirements
 It’s not a reflection of the
underlying software partitioning
 It’s not the first structure you might
thinks of…
15
Let’s start with
what a good
WBS should not
look like.
This is the easy
part

Some attributes of a good WBS
 All terminal nodes describe some
end item in the project
 This physical deliverable is
testable in some manner
 The WBS is an increasing fidelity
description of the deliverables
produced by the project
 The WBS articulates what the
customer wants in terms of
deliverables
16
This are all
simple minded
attributes of
course. But they
should stimulate
some
conversation
about what does
good look like?

A Deliverables Focused WBS
 From the requirements Tree
construct a list of Capabilities needed
to satisfy the customer needs
 From this list of Capabilities construct
a list of Deliverables that will fulfill the
customer needs
 Arrange these deliverables into major
systems
 This has likely already been
done…so let’s have a hands on
exercise to draw this out
17
Building the first
cut at the Work
Breakdown
Structure is a
hands on,
iterative and
incremental
process.
Let’s not skip
the hard part
and assume we
have a WBS we
want to move
forward with

18
The Physical Act of Building the
Work Breakdown Structure
Let’s build a WBS using what we current know about the requirements

Step by Step to the 1st Instance of
the Work Breakdown Structure
1. What major partitions do we have?
 This should be easy
2. What sub–capabilities do we have
 Name 3 to 5 capabilities that can be
represented as deliverables
3. Some thoughts before we start
 Can we test for 100% completion?
 Can we trace this deliverable to a
business requirement?
 Can the deliverable be provided in
some independent sequence?
19
The Mind Jet
tool will be used
to capture the
first instance of
the WBS.

Let’s Get Started
20

21
Using the First Instance of the WBS
to Construct some Work Packages

Contents of a Work Package
 Description
 Assumptions
 Earned Value
Method
 Basis of Estimate
 Predecessors
and successors
 Strategy for
delivery
 Contents of the
deliverables
 Responsibilities
22
The Work
Package
Template used
on Meridian 1A
and 1B will be
our guide

Description
 A clear and concise description of
what the Work Package produces
in terms of deliverables
 This is your elevator pitch when
some asks “what does the Work
Package you’re working on do
when its all done?”
 Deliverables are meaning to the
customer – speak in deliverables
terms
23

Assumptions
 Make it clear (and concise) what
you expect to be in place before
the Work Package starts
 State these in terms of
deliverables themselves
– What they are
– Who you’re getting them from
– A little bit of why you need them
24

Earned Value Method
 Think about how you would message
100% done.
– Done, done
– Not almost done
– Not “I’ll be done soon”
 If the Work Package is contained and
100% done occurs at the end of the
WP then use that
 If the Work Package has more than
one deliverable or the deliverable has
incremental functionality then
Apportioned Milestones can be used
25
The concept of
Earned Value is
a separate topic
– coming soon.
But thinking in
Deliverables,
means thinking
about
measuring
physical
progress.
Physical
progress is not
the same of
effort.
Physical
progress is
deliverables

Basis of Estimate
 A short description of how you got
to the estimate of effort
– “I’ve done this before”
– “I asked someone who has done this
before”
– “I ran an experiment to determine
how long it would take”
– “I took a guess and multiplied it by 2”
26

Predecessors and Successors
 Give some thought about the
sequence of the Work Packages
– What comes first
– What comes next
 The reason for this is the obvious
dependencies
 But as well Work Authorization
processes will be used in Meridian
2/3
27

Strategy for Delivery
 What is the “story” you’re going to
tell the Work Package team about
how you’re going to get this work
done on time, on schedule and on
budget
 This is your strategy
– It’s a PLAN
– It’s not the Schedule
28

Contents of the Deliverables
 What to the deliverables “do” when
they are “doing what they do?”
– This is the basis of the Work
Breakdown Dictionary
 The WBS Dictionary sounds
redundant, but it is not
– The WBS is a deliverables structure
– The dictionary describes each
element in simple terms
29
WBS Element 1.5.4.5. - Systems Integration Test Equipment Planning - This element includes
the effort to identify requirements and specify types and quantities of test equipment needed to
support the System Integration and Test process. It does not include the design or
procurement of such equipment, which is covered in Element 1.5.4.6.

Responsibilities
 Each Work Package has one and
only one person Accountable for
the successful delivery of the Work
Package
– Put that persons name on the Work
Package
 We’ll build a Responsibility
Assignment Matrix (RAM) from the
Clarity files
– For now naming the person is a start
30

Building work packages from requirements (from mm)(larger version)

More Related Content

What's hot

Similar to Building work packages from requirements (from mm)(larger version)

More from Glen Alleman

Recently uploaded

Building work packages from requirements (from mm)(larger version)