Traditional project management starts with the identification of the tasks needed to deliver the solution. Deliverables Based Planning starts by defining what “done” looks like, how we would recognize “done” when we encounter it, and what effort is needed to deliver “done”. By defining accomplishments and criteria first, the effort needed to deliver can be easily identified

1. 1
A Gentle Introduction to
Deliverables Based Planning
Traditional project management starts
with the identification of the tasks
needed to deliver the solution.
Deliverables Based Planning starts by
defining what “done” looks like, how
we would recognize “done” when we
encounter it, and what effort is
needed to deliver “done”.
By defining accomplishments and
criteria first, the effort needed to
deliver can be easily identified

2. 2/62
Primary Goal of Project Management
must focus on the business aspects of a
project not the technical content
 No surprises for either the customer or the supplier
 Trust built on free and frank discussions about
– Risk, resources, planned effort, capabilities, commitment
– Performance – financial, technical, personnel
 Full engagement with customer strategies
– Communication of needs to solution providers
– Requirements traceable to business benefits
 Risk management is how adults manage projects
– Identify, analyze, plan, and mitigate
– Risk informed management processes
Overview

3. 3/62
Managing large complex projects is a
“full contact” sport, full of surprises,
disappointments, and sometimes success
 Project management
is not about
forecasting the future
 Its about
understanding the
risks that impact the
future
 Its about making
visible what “done”
looks like
 Its about staying
ahead of risk the
curve
Overview

4. 4/62
Fours Keys to Project Success
1. Attention to Context
– Be sensitive of personal
preferences and capabilities
– Distinguish the nature of the
project (repetition of the
past or discovery design)
– Distinguish the nature of the
sponsoring organization
2. Create a shared Vision
– Develop an emerging
shared metaphor
– Make this distinct from
requirements
– Define the Business
Capabilities
3. Focus on Community
– Ignore artificial limits
imposed by teams
– Consider the community
surrounding the project as
the guiding force
4. Planning versus Plans
– Assure a coherent
engagement with and within
the community about the
definition of “done”
– Measure maturity growth of
the Business Capability
rather than just progress as
the passage of time
Overview

5. 5/62
Learning to talk about the meaning of
“done” starts with a new vocabulary
 Insist everyone speaks in “capabilities” as the
standard unit of measure for commitment – a
measure meaningful to the business
 Have something to touch One (1) month after
project starts and every two weeks after that
 Insist on a list of “testable” deliverables –
something that can be demonstrated, shown or
assessed – no slides and reports of progress on
paper:
– We’ll be told this is an unnecessary overhead
– Accept no substitutes for testable milestones
Overview

6. 6/62
Some definitions needed to talk about the
meaning of “Done”
 A Business Capability is a Program Event describing …
– Major release point in the project providing a business capability
– The 100% delivery of a production ready business capability into
the hands of the customer
 A Significant Accomplishment is a Milestone for the …
– Interim, critical or discrete activity that must be completed before
the Business Capability can be called “Done”
 An Accomplishment Criteria is the Deliverable with …
– The measurable indicators of the evidence that demonstrates the
achievement of maturity or progress in an activity
 Tasks are the work efforts contained in a Work Package
– That perform deliver the Accomplishment Criteria in support of
the Significant Accomplishments

7. 7/62
Execution Schedule
Business
Capability
Milestones
Work Packages
The integration of the Deliverables Based
Plan with the Task execution schedule
Program Event
Significant
Accomplishment
Accomplishment
Criteria 3
Accomplishment
Criteria 2
Task
Task
Task
Task
Task
Task
Task
Task
The tasks required to complete each Accomplishment Criteria are
defined and linked to create the Deliverables Based Schedule
Significant
Accomplishment
Accomplishment
Criteria 1

8. 8/62
Core concept of horizontal and vertical
integration of the Deliverables Based
Plan
 Horizontal integration
– The rollout of products or services based on functional
activities (development, test, integration)
 Vertical integration
– The rollout of product or services based on business
capability (order processing, product shipment,
accounts payable)
Both Horizontal and Vertical integration are necessary for a
successful project. With horizontal only, the business must wait
until the end to receive the value of the project. With vertical only,
the functional streams are never clear about what “done” looks
like except the consumption of resources

9. 9
Deliverables Based
Task Scheduling
Deliverables Based Plan (Plan)
and Task Based Schedule
(Schedule) is one approach to
dealing with #4 in the 4 Keys to
Project Success just presented
The three other success factors
are important, but they’ll have
to wait for another session.

10. 10/62
Let’s walk through a gentle introduction to
Deliverables Based Plan starting with some
motivation and background
 Introduction
 Deliverables Based Planning Background
 What does a well formed Plan look like?
 Capabilities Versus Functional
 Attributes Of a Deliverables Based Plan
 Preparing The Deliverables Based Plan
 Planning The Program

11. 11/62
The fundamental “mission” of Deliverables Based
Planning is to assess the evolving maturity of a
project, not just the passage of time
 Traditional (horizontal planning) processes assess
progress to plan by measuring the percentage complete
for tasks connected to milestones
– Milestones are collection points for tasks
– “We made it to milestone #6, so we’re 47% along the path to
completion of this project”
 Deliverables Based Planning (vertical planning) makes
these maturity assessment points explicit
– Significant Accomplishments explicitly define the desired maturity
of the project at a point in time
– Accomplishment Criteria define the “exit criteria” for assessing
maturity for each Significant Accomplishment
– Tasks are the work elements for the Accomplishment Criteria
Introduction

12. 12/62
There are two points of view when
discussing “what does done look like?”
The Horizontal View
 The Lead says – “Here’s all the
things we’re going do and
when we’re done with them,
we’re done with the project”
 The Planner asks – “Tell me
about all the effort needed to
get your tasks done before you
have to ship?”
 The Outcome Is – effort is
equated with progress up to
the point where a milestone
occurs and the “real” progress
becomes visible
The Vertical View
 The Lead says – “What level of
maturity do we need to be at
when a specific event occurs?”
 The Planner asks – “Tell me
what needs to be
accomplished and how you
would measure those
accomplishments before you
move to the next level of
maturity?”
 The Outcome Is – frequent
tests and verifications of
increasing maturity define the
state of the project
Introduction

13. 13/62
A quick overview of Deliverables Planning
and why its an important concept for
complex integration projects
 Deliverables Based Planning is the basis of integrating
development effort using teams of solution providers
 Deliverables Based Planning is a simple and logical way
to consistently provide vertical schedule traceability
across the entire portfolio of projects
 The Deliverables Based Plan
– Identifies the timing of key events that function as commitment
and management check points in the project
– The Program Events (PE), Significant Accomplishments (SA),
and Accomplishment Criteria (AC) provide a logical framework to
develop a detailed Integrated Master Schedule (Schedule)
– Work Breakdown Structures define the scope of work needed to
fulfill the AC’s and SA’s
Introduction

14. 14/62
Nine principles of project management
applicable to complex integration
projects (there are more of course)
1. Systematic and integrative planning – maximum influence comes
early in the project
2. Timely decisions adjusted to uncertainty – objectives first, then the
means to fulfilling the objective
3. Isolation and absorption of risk – organize project elements to
maintain stability and isolate undesired results
4. Leadership is both Inward and Outward– leadership copes with
uncertainty, management copes with complexity
5. Teamwork – emphasize cooperation rather than risk allocation
6. Overlapping phases – pay great attention to pre–existing activities
7. Simple procedures – prevent re–invention, contribute to cooperation,
and establish internal stability
8. Intensive communication – fit the intensity and mode of
communication to the situation
9. Systematic monitoring – identifying and correcting small problems is
easy, identifying large problems is easy, correcting them is hard
Introduction

15. 15/62
Deliverables Based Planning is a mature
project management process used in
many industries
 The work elements for the portfolio are defined. A Work
Breakdown Structure (WBS), tailored for effective
management control, is used in this process.
 The portfolio organizational structure, including the major
providers responsible for accomplishing the work, is
identified. The organizational elements needed to plan
and control the work are defined. An Organizational
Breakdown Structure (OBS) is used in this process.
 The planning, scheduling, project WBS, and portfolio
OBS are integrated.
 The WBS organizational structure are integrated to
providing cost and schedule performance measurement
by work element across the portfolio.
Introduction

16. 16/62
Deliverables Planning is found in
organizations that understand “done”
means
 Is Deliverables Planning simply old wine in a new bottle?
 Is Deliverables Planning a “belt and suspenders”
approach to project controls?
 Why all this formality when the traditional approach to
planning appears to work just fine?
– The Plan is event focused rather than effort focused.
– The Plan communicates the portfolios approach to meeting top
level requirements (strategic requirements) of the organization
– The Plan provides the basis for subsequent detailed planning and
schedules
– The Plan measures maturity by marking the initiation or
conclusion of major intervals of activity with defined outcomes
Introduction

17. 17/62
The Deliverables Based Plan is …
 An event focused, time–driven plan for the delivery of
business value
 A schedule of tasks that deliver Significant
Accomplishments and their Accomplishment Criteria
 A tracking and status tool used during project execution
using Earned Value metrics for each Work Package
 A detailed tool to show progress, inter–relationships and
dependencies among all the project deliverables
 A critical path representation used to direct management
focus through the Earned Value performance
measurement of each Work Package
Introduction

18. 18/62
Why is Deliverables Based Planning
different from the traditional approach to
planning and scheduling?
 Vertical traceability is the significant difference
– The lowest activities are traced through all levels to the Program
Events – the delivered business capability
– All measurable effort directly supports these Program Events
 Deliverables Based Planning is a “simple concept”
– The definition of “done” is contained in the Significant
Accomplishments (SA) and their supporting Accomplishment
Criteria (AC)
– Tasks are the work effort that complete the Accomplishment
Criteria
– But the completion of a task is not an indicator of maturity, only
the completion of the Accomplishment Criteria and the related
Significant Accomplishments
– The 100% completion of Significant Accomplishments and their
Accomplishment Criteria are the ONLY measure of progress
Introduction

19. 19/62
The vertical and horizontal nature needs
to be kept in mind at all times until it
becomes second nature
The passage of time
Increasingmaturity
 Vertical linking – Increasing maturity is found by
completing Significant Accomplishments (SA)
through their Accomplishment Criteria (AC)
 Horizontal linking – SA, AC and Task linking
defines the critical path and work sequences
 Both are needed, but Vertical linking creates the
critical success factor for a complex project
portfolio – it defines “done” in customer terms
Think Vertically – Act Horizontally
Introduction

20. 20/62
Let’s look at a simple example of vertical
and horizontal linking — provisioning a
new employee
Human ResourcesNew Employee Ready to Work
Insurance
Orientation
Laptop Account Setup
Charge account setup
Information Technology
Finance
Buying authority
Supply Chain Management
Both horizontal and vertical processes are needed to provision the new
employee in a timing manner. No waiting for other departments, process
flows seamlessly between departments. The employee sees a “systems”
rather than a collection of processes.
Introduction

21. 21/62
Let’s have a process check before we
move on
 Both vertical and horizontal
connections are needed to
integrate functional
development and business
capabilities
– Silos of function are necessary
– But connections between the
silos make them sufficient to
deliver on the business
processes
 Thinking vertically is the place
to start when asking “what
does done look like?”
– Horizontal progress is
measured in the passage of
time
– Vertical progress is measured
in maturity improvement
“By George, for a minute there it
suddenly made sense”
Introduction

22. 22/62
A well formed Deliverables Based Plan
has a distinctive, look, feel, and
structure
 Introduction
 Deliverables Planning Background
 What does a well formed Plan look like?
 Capability Versus Functional
 Attributes Of Deliverables Based Planning
 Preparing The Deliverables Based Plan
 Planning The Program

23. 23/62
What does a Plan look like?
Value judgments mixed with fundamental
concepts
 It’s focused on Business Capability rather than on functional activities
 The topology is built around “vertical” connections between the
functional activities and the events
– All Significant Accomplishments (SA) and Accomplishment Criteria (AC)
“land” on the Program Event PDR Conducted
– All task activities “land” on the project’s SA’s and AC’s
Well Formed

24. 24/62
The fundamental concept of “schedule
drives cost” starts with a clear and
concise definition of “done”
 Event based planning defines the path to maturity
 Resource loaded tasks define the activities that drive
maturity
 Cost or cost estimates are derived from planning tasks
– Labor cost is a derivative of resource loaded schedules
– Non–labor costs can be added to the schedule or carried in the
pricing system
– Burdening the labor and non–labor is done in the cost system
 Adjustments to the cost profile start with adjustments to
the schedule
– All adjustments flow from schedule to cost
– The need for a cost adjustment implies a schedule or labor
adjustment
– Make labor or schedule adjustments first and cost will flow from
there
Well Formed

25. 25/62
Knowing when we have a well formed
Plan is not always obvious, but here’s
some questions to ask…
 Can we see the connections between the project
elements?
 Does it convey the logic and strategy of project?
 Are the delivery goals met through measurable
outcomes?
 Are all phase entry and exit criteria defined?
 Do the planned activities meet the funding and business
requirements profile?
 Are all interdependencies evident?
 Are accomplishments appropriate to events?
 Do criteria show completion of accomplishments?
 Are accomplishments and criteria linked from level to
level (system to subsystem; ,management to teams)?
Well Formed

26. 26/62
Knowing when we have a good
Deliverables Based Schedule has a
similar set of questions…
 Are key dates recognized and integrated?
 Does the Plan correlate one–to–one with
Schedule?
 Do the scheduled tasks address all required
activities and technical (functional + technical
solution) descriptions
 Do tasks cover all process and capability related
effort to
– Achieving the strategic goals and objectives
– Completing coverage of the business processes
– Reflecting all deliverables agreed on
– Explicitly managing the identified risks
Well Formed

27. 27/62
And some questions that need to be
continually asked for determining the
“goodness” of the Deliverables Plan
 Relationships among tasks are clear – how do the
accomplishments flow to the event?
 Dependencies among functions are clear – what
accomplishments are needed to arrive at an event or a
deliverable capability or service?
 Durations are clearly defined, estimated and committed
to by the technical owners – tasks are where the “action”
takes place
 Critical path is defined and understood – fully linked
tasks, no widows or orphans, built–in margin erosion
management is explicit in the Schedule
 Schedule risk assessment is provided to enable
milestone completion on time – schedule margin and risk
mitigation tasks “explicitly” in the Schedule.
Well Formed

28. 28/62
Functional approaches are horizontal,
Capability approaches are vertical
 Introduction
 Deliverables Based Planning background
 What does a well formed Plan look like?
 Capability versus Functional
 Attributes of Deliverables Based Plan
 Preparing the Deliverables Plan
 Planning the Program

29. 29/62
Process versus Functional planning is at
the heart of the Deliverables discussion
 A first impulse to “planning” is to define the functional
(Silo) work to be performed over a period of time
– Assemble the tasks in the order performed
– Assign durations to these tasks
– Assign resources and other costs
– Assure that a proper network is constructed that can be analyzed
through the Critical Path Method
 In most cases this results in a horizontal (functional)
architecture of the effort, with tasks arranged in a logical
sequence
– “Done” is defined by the implicit completion of tasks
 Plan (vertical) architecture approaches the schedule from
the “event” point of view
– How does the capability mature over time?
– What is the evidence that maturity is taking place as time
passes?
Capability v. Function

30. 30/62
Think about Deliverables as a
functionally structured WBS turned on its
side
Large Integrated Program
Supply Chain
Management
IT
Infrastructure
Finance
Planning &
Development
Human
Resources
WBS 3.1
WBS 3.2
Wbs 3.3
WBS 3.4
WBS 3.5
WBS 7.1
WBS 7.2
WBS 7.3
WBS 7.4
WBS 8.2
WBS 8.3
WBS 8.1
WBS 8.4
WBS 8.5
WBS 6.1
WBS 6.2
WBS 6.3
WBS 6.4
WBS 10.1
WBS 10.2
WBS 10.3
WBS 10.4
LargeIntegrtaedProgram
SupplyChain
Management
IT
Infrastructure
Finance
Planning&
Development
Human
Resources
WBS3.1
WBS3.2
WBS3.4
WBS3.5
WBS3.6
WBS7.1
WBS7.2
WBS7.3
WBS7.4
WBS8.2
WBS8.3
WBS8.1
WBS8.4
WBS8.5
WBS6.1
WBS6.2
WBS6.3
WBS6.4
WBS10.1
WBS10.2
WBS10.3
WBS10.4
Provision New Employee
Enroll New Qualified Supplier
Capability v. Function

31. 31/62
The differences between Capabilities
versus Functional speaks to the core of
defining “what does done look like?”
 The “hard part” of Deliverables Based Planning is
changing our habits of defining the horizontal (silo) –
instead of defining “done”
 Defining the events representing Business Capability, the
accomplishments that result in the event, and the criteria
for assessing the maturity of these accomplishment is the
role of the Plan
 Gathering the raw materials for a Deliverables Based
Plan is straight forward if approached in an iterative /
incremental manner aimed at “capabilities” deployment
 Continually asking “what does done look like” reinforces
the Deliverables Based Planning approach
– If you’re not asking questions and getting answers for “what does
done look like” on event boundaries then you’re not doing
Deliverables Based Planning
Capability v. Function

32. 32/62
A Gentle Introduction to Deliverables
Based Planning
 Introduction
 Deliverables Based Planning background
 What does a well formed Plan look like?
 Capability versus Functional
 Attributes of Deliverables Based Plan
 Preparing the Deliverables Based Plan
 Planning the Program

33. 33/62
Attributes of a Deliverables Plan starts
with the notion of “done,” how to get to
“done,” and how the assess “done”
 Starting with the PE/SA/AC sequence, the
Deliverables Based Plan has several major
attributes
– Tasks are collected by the Event rather than by a
WBS hierarchy
– There is a WBS but it is not the first organizational
structure of the schedule
– Rather, the first organizational structure is the logical
decomposition from the Business Capabilities (a
Program Event), to the Significant Accomplishments,
to the Accomplishment Criteria
Attributes

34. 35/62
Attributes of a Deliverables Based Plan
emphasizes the term “integrated” as the
foundation of all planning efforts
 Integrated, networked, multi–layered schedule of efforts
required to deliver each Business Capability
– Detailed tasks and work to be completed
– Calendar schedule shows work completion dates
– Network schedule shows interrelationships and critical path
– Expanded granularity, frequency, and depth of risk areas
 Resource loaded critical risk areas
 Correlates Scheduled work with Plan Events
– A single numbering system is the starting point
– A logical decomposition of the work is more important
– Demonstrating project maturity as a function of time is the critical
success factor for Deliverables Based Plan
Attributes

35. 36/62
The objectives of all this formality is not
to create paper work, but to reveal
critical success planning elements
Objective  Implementation
Event Driven Plan versus a
Schedule Driven Plan is based on delivery
of capabilities not just passage of time
 Separate the Plan from the Schedule
but link elements with numbering
system
Condensed, easy to read “plan” showing
“events” rather than effort
 Indentured, outline format (not text)
Pre–defined entry and exit conditions for
major Business Capability as defined by
the business customer
 Significant accomplishments (SA) for
each key event (submitted in proposal)
Objective measure of progress/
completion for each significant
accomplishment
 Pre–defined accomplishment criteria for
each significant accomplishment
Capture essence of functional processes
without mandating a particular process
 Split Plan into Capability and Process
sections
Attributes

36. 37/62
Definitions used in Deliverables Planning
are clear and concise and should not be
altered for the convenience of the novice
 Business Capability – Event
A major transition point in the
project
 Significant Accomplishment
Interim, critical or discrete
activity required to complete
prior to an event
 Accomplishment Criteria
Measurable indicators of
evidence that demonstrates the
achievement of maturity or
progress in an activity
 Tasks
Work performed in support of
accomplishments and their
criteria
 E/A/C
A combination of events,
accomplishments, and criteria
 Integrated Master Plan
A contractual commitment that
lays out the entire project in a
single plan
 Integrated Master Schedule
Provides an integrated and
networked time phased
schedule of all project and
deployment tasks
Attributes

37. 38/62
Deliverables Action Verb Dictionary is the
starting point for controlling the
definition of “done”
 Available
 Complete(d)
 Conducted
 Defined
 Delivered
 Documented
 Delivered
 Demonstrated
 Established
 Finalized
 Implemented
 Obtained
 Ordered
 Met
 Prepared
 Provided
 Published
 Received
 Refined
 Reviewed
 Submitted
 Trained
 Installed
 Integrated
 Loaded
 Operational
 Reduced
 Released
 Tested
 Updated
 Validated
 Verified
 In–Place
 Written
 Acquired
 Analyzed
 Approved
 Awarded
 Corrected
 Drafted
 Established
 Generated
 Identified
 Initiated
Attributes

38. 39/62
All the elements of a Deliverables Based
Plan work together providing visibility to
the increasing maturity of the project
Business Strategy
Plan Process Step
WBS Element or
Subsystem
Events
Tasks
Accomplishments
Criteria
Significant
Accomplishments
(SA)
Accomplishment
Criteria (AC)
Subsystem
Business
Capability
State of this
Capability
State of the
Process
Demonstrates
Maturity
Identifies
End Item
How
Defines
Customer/Program
Direction
Program/Team
Direction
Team Direction
Performance
Team Status
Team Status
Something
Completed
Effort
Expended
Deliverables
Attributes

39. 40/62
A common set of concise terms that are
capability specific provides a “stand
alone” description of “done”
Perform
Work
Maturity
Adjective
Action
Verb
ClosePreliminary
Capability
Noun
General Ledger
Demonstrates
Maturity End Item
“A01B02a: Preliminary Month End Close of the General Ledger Successful”
Step in the Process
State
Verb
Successful
Closure
State
Attributes

40. 41/62
Preparing the Deliverables Based Plan
starts with defining the Events that
represent a business capability
 Introduction
 Deliverables Based Planning background
 Capability versus Functional
 Attributes of Deliverables Based Planning
 Preparing the Deliverables Based Plan
 Planning the Program
 Program Architecture

41. 42/62
Preparing the Deliverables Based Plan
starts with gathering the customer’s
definition of “done”
 Charter the working group
– Program Leadership Team (PLT)
– Project Delivery Team
– Vendor Team
 And add the functional managers if they are organized along
functional disciplines
– But, and this is a big but, start the information gathering with the
functional managers at the “event” level
– Ask them to build a collection of “accomplishments” for each event
– Use these accomplishments to start the discussion of what “done” looks
like for the events
– Avoid the “passage of time” as progress discussion until the detailed
tasks are identified for the completion of the Schedule
Preparing

42. 43/62
Preparing the Plan surveys all the logical
sources, gathering events and their
accomplishments
 Inputs for the Deliverables Based Plan
– Statements of Work (SOW)
– Functional Requirements Specification
– Business Process Improvement Specification
– Traceable business benefits from the Business Case
– Work Breakdown Structure (WBS)
– WBS Dictionary (What do we mean when we say “x”?)
– Regulatory requirements
– Organizational Breakdown Structure (OBS)
Preparing

43. 44/62
A Deliverables Based Plan example from
a large systems integration and operation
project
Contract Start (1, 11)
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48
Year 1 Year 2 Year 3 Year 4
BN CPs (5) BDE HQs
(6)
ABCPs & OCs: L M, N, J, L, A (9)
SGATs: L, N, A, J & SAT (10)
Mission
Applications IPT
(1.5)
Develop Build1.2 Mission Apps SW– SBs, MOs
Develop Advanced TrainingSW Develop Build2 Mission Apps SW– SAPs,Process Assistants
Automated Data
Processing IPT
(1.7)
Define, Buy,Integrate ADP& Peri-
pherals HWand Operating Systems
Develop Common MobileHWDesigns
Modify AMCWSand RMPWS
Communications
IPT (1.8)
Comms
Site
Surveys
Define, Buy,Integrate, Test Comms Management HW &SW
Radars IPT
(1.9)
SRR Site Surveys
Manufacture, Install,SAT, FLT SRRGroup 1
#1 #2 #3 #4
Group 1 SYS (12)
#5 #6 #7 #8
Group 2 SYS(13)
Manufacture, Install,SAT, FLT SRRGroup 2
Civil Works IPT
(1.3)
Support
Site
Surveys
Plan, Design,Install Fibre OpticCable
Plan, Design,Prepare KC4ISSites
Plan, Design,Construct, Prepare SRR Sites
SEIT IPT
(1.2)
DefineCommon Processes Update Analyses,ConductConfiguration Mgmt &QualityAssurance Programmes, Monitor Common Processes
Plan& DryRun System Tests: Bld 1 FAT BNNATs BDENATs OC NATs Build 2 FAT SGATs SAT
KC4ISSite Surveys
System Desig n
Review (SDR) (2)
Node Design
Review
(NDR) (3)
Service Group
Design
Review (SGDR) (7)
Build 1
FAT (4)
Build 2
FAT (8)
Activate SIL, SDEs
Integr &Test
SW Build 1
Integrate& Test SWBuild 1.1
Integrate& Test SWBuild 1.2
Integrate& Test SWBuild 2
Procure, Install, Checkout, Test 9 Battalion Command Posts (BN CPs)
Procure, Install, Checkout, Test 6 Brigade Headquarters (BDEHQs)
2 Air BaseCPs(ABCPs) & 5Operations Centres(OCs) ConductService Group
&System Acceptance
Tests(SGATs &SAT)
Activate Install SuptFacility
Analyse System Requirements
&Define System Design
Finalise System Design and Analyses
Common
Services IPT
(1.6) Buy&Integrate Build 1.1 CS SW
Buy&Integrate Build 1.2 CS SW
Develop Build2 Common Services SW
Buy&Integrate Build 1
Common Services(CS) SW
Support System
IPT (1.4)
KC4ISProvisioning
Conference
SRR
Develop KC4IS Build 2 Manuals& TrainingMatls
Customise SRR Manuals& Training Matls
KC4ISWarrantyMaintenance
SRR Warranty Maintenance
ILSTransition
Activate KC4ISDepot
ConductKC4IS Build 1 BasicTraining ConductKC4IS Build 2 Advanced Training
ConductProficiency Testing &Training
ConductSRRTraining
Develop KC4IS Basic TMs &Trng Matls
ILSSite
Survey
PlanKC4IS&SRRSupportSystems
Update Spares Lists
ConductSystem Admin / Maintenance Training
ConductCommunications, Elec-Mech, Other Training
Preparing

44. 45/62
Preparing the Deliverables Based Plan
involves iterative and incremental
development starting with the Program Events
 “What needs to be accomplished for this event?”
– List these accomplishments – focus on operational aspects
– Use a past tense verb from the dictionary
– Code the Events, SAs, and ACs in the schedule
 “What tests can be performed to assure these accomplishments
meet the project requirements?”
– List the evidence showing completion
– Use past tense verbs
 “What work must be done to complete the criteria?”
– Assign resources
– Assign work package and control accounts
– Link tasks in the proper sequence
– Define the duration of the effort
– Use only allowed constraints
Preparing
Remember, the Program
Events are Business
Capabilities that can be put
to work fulfilling the business
case in an incremental and
iterative manner

45. 46/62
Define / Derive deliverables from the
strategy and leadership documents and
our mini-Kaizen event
 List of customer deliverables that make up a Capability
– These can be collected in a “Milestone” of completed
Deliverables
 Items needed to support the Deliverables
– These are usually Deliverables themselves
 Assign every Business Capability to a team with full
authority to deliver this capability
– The capability lead can provide more details of the
Accomplishments and Criteria
 Summarize each Business Capability life cycle in the
Deliverables Based Plan
– As the project matures the events are satisfied by delivering on
the accomplishments, assessing the criteria and finally
performing the actual work
Preparing

46. 47/62
Using a Mini–Kaizen to capture the
Deliverables provides a “hands on”
experience for all the participants
Preparing

47. 48/62
Criteria for defining Events starts with the
Requirements, adds Risk Mitigation, “give/get”
milestones and integration points
 Customer provided Events – Needed Capabilities by
Date
– These are usually stated by senior management or the business
stream owner
 Key decisions in the project
– Obvious project delivery points
– Risk assessment points
 Risk mitigation activities
– Intermediate points where project maturity and risk mitigation is
assessed
 Mandatory corporate events
– Internal guidelines, work processes, or independent reviews
 Capability demonstrations
 Verification and validation efforts and results
Preparing

48. 49/62
The Significant Accomplishments (SA)
describe the “done” aspect of the
Program Event (PE)
 SAs are event related not just time coincidental
– The passage of time has little to do with real progress when
Capability Maturity is the “unit of measure”
– These events should not be anchored at a specific date, unless
imposed by the customer
– The date of the event should be driven by the supporting work
that must be accomplished
 Characteristics of a Significant Accomplishment
– A discrete step in the process of planned development
– A desired result at a specific event
– Interrelationships, interdependencies, or handoffs points
Preparing

49. 50/62
Sample accomplishments should be
replicated throughout the project, but
with specific content changes
 Significant Accomplishments are stated as a past tense
verb
– Statements of accomplishments, things that have happened
already to move the maturity of the project forward
– Past tense focuses on the outcome rather than the effort toward a
goal. “Tell me what you’ve done to increase maturity”
 Significant Accomplishments are activities that have been
performed with measurable outcomes
– Process improvements Demonstrated
– System Requirements Allocations Completed
– Functional Interface Requirements Established
– Software Release Cycle 1 Complete
– Critical Design Review Complete and Accepted
Preparing

50. 51/62
Accomplishment Criteria are the
activities that “verify” outcomes, test
results or confirm compliance
 Accomplishment Criteria (AC) are definitive measures
supporting successful completion of a Significant
Accomplishment (SA)
 An AC must show objective evidence of work progress
– The accomplishment must be seen, read, demonstrated, or
quantified
– The accomplishment must be measured in an independent
means, not just a statement we’re done
– It is critical to define the accomplishment criteria before
proceeding with the work
 Accomplishment Criteria are the Exit Criteria for the work
being performed by the Work Package
Preparing

51. 52/62
The Master Schedule flows directly from
the Deliverables Based Plan
 The Schedule is a calendar oriented
representation of the project that integrates all
criteria, accomplishments, and events described
in the Plan.
– Represents relationships between tasks
– Duration and timing
– Scope of work
 But and this is a critical “But,” the Schedule is not
the starting point of the Deliverable Based
Planning, it is the ending point
– The calendar oriented elements are identical to “tasks”
in the traditional planning process
– They are explicitly connected to Program Events
Preparing

52. 53/62
Integrated Master Schedule
 Depicts both planned (baselined) and forecast dates for
all activities on the project
 Measures impact and performance for each activity
through earned value metrics
 Communicates project content, workflow, and approach
through the flow down of accomplishments and criteria
from the project events
 Identifies problem areas through critical path analysis
and risk paths
 Enables management to prioritize activities against
project events
 Is the basis for evaluating and communicating change
throughout the project
Preparing

53. 54/62
Three Levels of the Scheduling form the
project architecture
 Master Schedule – usually published with the proposal,
but also is the supporting basis for the execution Plan
 Intermediate Schedule – resource loaded derivative of
the Master Schedule
 Detailed Schedule – 60 to 90 day rolling wave details at
the execution level
– Sufficient detail to control the work
– Deliverables at the end of the wave support the accomplishments
Preparing

54. 55/62
The three levels of the Schedule define
the granularity of the planning as well as
the reporting
Monthly statusing:
– Validate schedule status
(start/complete/slip)
– Validate work package
% complete
– Claims earned value
– Identify/process cost ETCs
Weekly statusing:
– Roll up of lower level
schedule
status
– Roll up of lower level %
complete
or
– Milestone start/complete
– Milestone slip (early/late,
start/complete)
– % complete of tasks
Weekly statusing:
– Milestone start/complete
– Milestone slip (early/late,
start/complete)
– % complete of tasks
Near term RW period
Future RW periods
Control account span
Schedule tasks
(at Work Package level)
20 to 40
Workday tasks
Or even
weekly tasks
Schedule tasks
(one/two levels
below WP level)
Plan
WBS
Levels
1, 2, 3
WBS
Levels
4, 5
WBS’s
Below
Work
Package
Planning Package
Preparing

55. 56/62
A Gentle Introduction to Deliverables
Based Planning
 Introduction
 Deliverables Based Planning background
 Capabilities versus Functional
 Attributes of Deliverables Based Planning
 Preparing the Deliverables Based Plan
 Planning the Program

56. 57/62
Hard Constraints should be used
sparingly
 Start No Earlier Than (SNE)
– Tasks not controlled by the execution team, for which the team
has been given projects dates
– “Locked down” deliverables (launch date for the service)
– Tasks which may have to be scheduled in conjunction with other
project elements
 Finish No Earlier Than (FNE)
– “Just in Time” tasks
 Rationale needs to be provided for constraints other than
“As Soon as Possible”
– This information should be placed in the notes field
Planning

57. 58/62
Task Relationships in Microsoft Project
can create confusion and illogical
networks if not used carefully
 For an integrated master schedule
to reflect the project status, all
interdependencies must be
identified
 Finish to Start – one task finished
before another starts
 Start to Start – one cannot start until
another starts
 Finish to Finish – completion is
driven by another task
 Start to Finish – administrative tasks
driven by a review date
Write Test Procedure Conduct Test
Conduct Test
Gather Results
Conduct System Test
Design Production Item
Conduct Review
Prepare Agenda
SS+5d
SF –10d
FF+22d
Planning

58. 59/62
Milestones are one way to anchor hard
constraints, but the offsets must be made
explicit
 Deadline constraint is a powerful tool for controlling
– Complete prior
– Complete after
Milestone Date Complete 10 days afterComplete 10 days prior
FF–10d FF+10d
Planning

59. 60/62
Resource Materials
Although these resources come from large government
contracting environments their application to the commercial
world is straightforward
 Air Force Materiel Command: Integrated Master Plan / Integrated
Master Schedule (IMP/IMS) Guide, Version 1, November 2003.
 Air Force Guide to the Development and Management of Project
Schedules, SAF/AQ Schedule Incentives and Tools Reinvention
Team
 The Integrated Project Management Handbook, 8 February 2002
Dayton Aerospace, www.daytonaero.com
 Scheduling Guide for Program Managers, October 2001, Defense
Systems Management College, Fort Belvoir, VA
 Department of the Army Cost Analysis Manual, US Army Cost and
Economics Analysis Center, May 2001.
 NASA Systems Engineering Handbook, SP–610S, June 1995

60. 61/62
Resource Materials
 “Ninety Nine Rules for Managing ‘Faster, Better, Cheaper’ Projects,”
Alexander Laufer University of Maryland and Edward Hoffamn,
NASA Headquarters, October 1998.
 www.aim–pmcs.com has many articles on Deliverables Based
Planning
 PMI conferences for Program Performance Management
 “Integrated Master Plans and Integrated Master Schedules
(IMP/IMS) Workshop,” Center for Acquisition Development, The
Aerospace Corporation 11.June.1999
 The Defense Acquisition Guidebook, http://akss.dau.mil/dag/

61. 62/62
Thank You for Investing Your Time and
Effort. Now onto the next step
 The next step is to put
Deliverables Based
Planning to work
 Individual functional areas
build a initial Deliverables
Plan through a mini-Kaizen
process
 We’ll break up into groups to
start building our “wall of
truth”
 Our goal is to add value to
process