Downloaded 37 times
![The 10 Organizing Principles of
Deliverables Based Planning®
Principles are the source of guidance for the Deliverables
Based Planning®
Practices.
A principle is a “general truth, a law on which other are
founded or from which others are derived.” [Webster]
For the principles of program and project management to be
effective they must :
§ Express a basic concept
§ Be universally applicable
§ Be capable of straightforward expression
§ Be self evident
The 10 Principles of Deliverables Based Planning®
guide the
application of the four process areas. These principles
encompass the entire life cycle of a project or program, from
inception and the discovery of the business or system
capabilities, through requirements elicitation, to the creation
of the Performance Measurement Baseline (PMB), to the
execution of this baseline.
The principles of Deliverables Based Planning®
provide
several feedback loops to assure that subsequent activities
provide measurable information to correct gaps that exist in
the previous activities. This iterative and incremental
approach to program management assures the periods of
assessment for corrective actions are appropriately spaced
to minimize risk while maximizing the delivered value to the
program.
Deliverables Based Planning® can be the basis of
conventional as well as Lean program management methods.
The illustration the next page are the 10 Principles of
Deliverables Based Planning®. Each principle is developed in
detail later in this handbook. For now understanding the
dependencies between the principles is important.
Information produced by the practices derived from the
principles must be done in a sequential manner. This is not a
“waterfall” approach, but rather an incremental elicitation of
the information needed to successfully manage the program.
Skipping forward in the sequence of principle, creates
systemic risk for both the programmatic and technical
elements of the program.
48
ChapterI](https://image.slidesharecdn.com/deliverablesbasedplanninghandbookv8-201224023045/85/Deliverables-based-planning-handbook-48-320.jpg)
![Deliverables Based Planning® Processes
Deliverables Based Planning® is a comprehensive approach
to managing cost, schedule, and technical performance of
programs and projects by assessing the interaction between
programmatic and technical processes. The method starts by
capturing the technical and operational needs of the
proposed system. These are stated in a Concept of
Operations describing how the system operates, how it fulfills
the stated mission, what major components comprise the
system, and how they interact with each other.
From the capabilities description of the Concept of
Operation, technical and operational requirements are
elicited. These requirements define the development progress
of the deliverables captured in the Performance
Measurement Baseline (PMB). This PMB is constructed from a
collection of Work Packages, arranged in a logical network
describing the increasing maturity of the products or services
needed to deliver the stated capabilities. Measures of
physical percent complete are used for each Work Package
and the deliverables they produce. Deliverables Based
Planning® is a Systems Engineering approach to program
and project management [INCOSE], [Stevens].
This method incorporates all three aspects of a program
performance measurement process – Cost, Schedule, and
Technical Performance Measures (TPM).
The inclusion of the TPMs distinguishes the Lewis & Fowler
Deliverables Based Planning® from more conventional
approaches to Program, Planning, and Controls.
In conventional approaches, the cost and schedule baseline
and the variances generate the values for Earned Value.
In the Deliverables Based Planning®
method, measures of
Physical Percent Complete are derived from pre–defined
targets of Technical Performance. The Earned Value
variables are augmented with adjustments from the Technical
Performance compliance for each deliverable to produce a
true assessment of progress.
Technical Performance Measures integrate technical
achievement with earned value using risk assessments that
provides a robust program management tool to identify
early technical and programmatic disruptions to a program.
[Pisano] TPMs:
Provide an integrated view across all programmatic and
technical elements.
Support distributed empowerment implicit in the IPT
approach, through interface definitions.
Logically organizes data resulting from systems engineering,
risk management, and earned value processes.
Provide a "real time" indication of contract performance and
future cost and schedule risk.
Support the development of systems thinking within an
integrated program model focused on the interface
definitions.
ChapterI
52
Deliverables Based Planning ® is a registered trademark of Lewis & Fowler. Copyright ® Lewis & Fowler, 2011](https://image.slidesharecdn.com/deliverablesbasedplanninghandbookv8-201224023045/85/Deliverables-based-planning-handbook-52-320.jpg)
![Capabilities Drive System Requirements
The principles for defining a capability address the
flexibility needed to ensure system responsiveness and
sustainability in a context of constant change, while
delivering tangible benefits to the buyer
These include: Agility, Tailorability, and measures of System
Element coupling and cohesion.
Governance principles provide guidance to institutionalize a
process, including its continued assessment and evolution over
time in support of the tangible system benefits.
These include: Enforced Rules & Responsibilities, Workflow
Guidance, Continuous Improvement, Transformation enablers.
The core concept in Capabilities Based development is the
focus on the delivery of value. The concept of “Value
Focused Thinking” starts with two methods of decision
making: the 1st
focuses on competitive analysis between the
various alternatives, and the 2nd focuses on attaining
organization values as the fundamental objective of any
decision making process. [Pagatto07]
During the development of the Concept of Operations for
each capability, assumptions must be made in the absence of
specific technical and operational information. To avoid
unwelcome surprises, some form of assumptions based
planning is needed. 1) Make operational plans, 2) Describe
plausible events, 3) Identify the “signposts” for potential
problems, 4) Discover shaping actions that shore up uncertain
assumptions, and 5) take hedging actions to better prepare
for the possibility that an assumption will fail [Dewer02]
Capabilities planning consists of several core processes to
describe the system capabilities in the absence of the
specific technical or operational requirements.
Discover what is not known by reaching a sufficient basic
knowledge level setting the problem space.
Identify problems by understanding the current process,
along with people and technology involved.
Establish boundaries and solution elements. These are
grouped into five categories:
1. Orientation principles align the process on a sound
theoretical basis issued from generally accepted practices
in the areas of engineering, modeling, and acquisition.
These principles include: Capability Thinking, Architecture
Models, Evolutionary Development, and Deliverables
Centric planning.
2. Communication principles enforce the standardization of
vocabulary and structure of information to be exchanged
within or outside the process.
These include: Standardized Formats and Common
Terminology to describes the system capabilities.
3. Collaboration principles enable active and timely
participation of all stakeholders involved in the
engineering of a capability.
These include: Collaborative Engineering and Information
Sharing between the contributors of the system capability
elements.
ChapterII
60](https://image.slidesharecdn.com/deliverablesbasedplanninghandbookv8-201224023045/85/Deliverables-based-planning-handbook-60-320.jpg)
![Requirements Identify Technical And
Process Deliverables
Inadequate requirements engineering is a common problem
in the development of any complex system.
There are many issues associated with requirements
engineering, including failure to define the system scope,
failure to foster understanding among the different
communities affected by the development of a given system,
and failure to deal with the volatile nature of requirements.
These problems lead to poor requirements and the
cancellation of development, or else the development of a
system that is later judged unsatisfactory or unacceptable,
has high maintenance costs, or undergoes frequent changes.
[Young04], [Grady06]
By improving requirements elicitation, the requirements
engineering process can be improved, resulting in enhanced
system requirements and potentially a much better system.
Requirements engineering is decomposed into the activities
of requirements elicitation, specification, and validation. Most
of the requirements techniques and tools today focus on
specification, i.e., the representation of the requirements.
The Deliverables Based Planning approach concentrates on
elicitation concerns, those problems with requirements
engineering that are not adequately addressed by
specification techniques.
The elicitation methodology to handle these concerns. Is
provided by [Cristel92].
Whatever the actual process used, the following activities
are fundamental to all Requirement Engineering
processes:[Sommerville05]
§ Elicitation – Identify sources of information about the
system and discover the requirements from these.
§ Analysis – Understand the requirements, their overlaps,
and their conflicts.
§ Validation – Go back to the system stakeholders and
check if the requirements are what they really need.
§ Negotiation – Inevitably, stakeholders’ views will differ,
and proposed requirements might conflict. Try to reconcile
conflicting views and generate a consistent set of
requirements.
§ Documentation – Write down the requirements in a way
that stakeholders and software developers can understand.
§ Management – Control the requirements changes that will
inevitably arise.
ChapterII
62](https://image.slidesharecdn.com/deliverablesbasedplanninghandbookv8-201224023045/85/Deliverables-based-planning-handbook-62-320.jpg)
![Requirements Identify Technical And
Process Deliverables
¨ Derive the system requirements for each system capability.
¨ Assure a requirement exists for each system capability needed to fulfill the
mission of the system.
¨ Develop the traceability from capabilities to requirements to produce a
“minimalist” system, with each requirement being present only because of a
needed system or mission capability.
¨ Test requirements by answering the question “why do we need this feature,
function, service, or capability?”
¨ Create Technical Performance Measures: [IEEE 1220]
¤ High priority requirements that have an impact on: mission accomplishment,
customer satisfaction, cost, system usefulness.
¤ High risk requirements or those where the desired performance is not currently
being met: the system uses new technology, new constraints have been added,
the performance goal has been increased, but the performance is expected to
improve with time.
¤ Requirements where performance can be controlled.
¤ Requirements where the program manager is able to rebalance cost, schedule
and performance.
ChapterII
63](https://image.slidesharecdn.com/deliverablesbasedplanninghandbookv8-201224023045/85/Deliverables-based-planning-handbook-63-320.jpg)
![Earned Value Describes Current
Performance
¨ Recognize Earned Value is cost based. Cost Variance and Schedule
Variance have the same units of measure – Dollars.
¨ Use the To Complete Performance Index (TCPI) and the Independent
Estimate At Completion (IEAC) as measures of progress derived from
Earned Value. But they are also measured in dollars.
¨ Using the TCPI and IEAC, the program manager has visibility into the
work performance needed to stay on schedule and the forecast cost
of this effort.
¨ Recognize the credibility of these indices depends on the credibility
of the underlying earned value numbers. This is the primary
motivation for maintaining good data on the program. Otherwise
the Earned Value numbers are not only wrong, they provide no real
value for guiding management in decisions that impact the future
performance of the program.
¨ Consider using Earned Schedule [ES] to complement Earned Value
[PMI EV]. Earned Schedule is a method of deriving schedule
performance from Earned Value data [Lipke], [Henderson04],
[Vanhoucke]
ChapterII
73](https://image.slidesharecdn.com/deliverablesbasedplanninghandbookv8-201224023045/85/Deliverables-based-planning-handbook-73-320.jpg)
![Performance Feedback Used To Adjust WP
Sequence and Resource Allocation
Earned Value Management (EVM) is a program management
tool integrates Cost and Schedule parameters as an early
warning system for future performance of the program.
But the EVMS standard states that EV is a measurement of
quantity (BCWP), not quality, of the work accomplished.
As far back as 1997, the discussion was integrating Cost,
Schedule, and Technical Performance. Robust systems
engineering and software engineering processes should
provide technical performance measures (TPM) and exit
criteria for assessing technical maturity that are
quantitatively linked to Earned Value.
Adjusting the To Complete Performance Index (TCPI) and the
Independent Estimate At Complete (IEAC) for less than
planned technical performance measurements – quality,
missing scope, delayed scope, or combinations of these and
other less than planned outcomes.
These TPMs are defined and evaluated to assess how well a
system is achieving its performance requirements. Technical
performance measurement uses actual or predicted values
from engineering measurements, tests, experiments or
prototypes.
The introduction the Earned Value Management Intent Guide
speaks to this but better guidance is needed [Solomon].
To provide the needed feedback for adjusting the TCPI and
IEAC values , the following activities need to be performed:
§ Include systems engineering activities in the schedule and
the Performance Measurement Baseline (PMB).
§ Establish thresholds or parameters for TPM in the program
plan.
§ Specify objective measures of progress as base measures
for EVM for: Development maturity to date, product’s
ability to satisfy requirements, Product metrics, including
TPM achievement‒to‒date.
§ Review program’s plans, activities, work products and
performance measurement baseline for consistency with
the requirements and the changes made to the
requirements baseline.
§ Incorporate risk mitigation plans in the program plan,
including changes to the PMB.
§ Include quantified risk assessments in the EAC depending
on the probability of risk occurrence and the impact on
cost objectives.
With this information, TCPI and IEAC can be adjusted to
reflect the Physical Percent Complete of the Work Packages,
not just the Cost and Schedule performance measures.
ChapterII
76](https://image.slidesharecdn.com/deliverablesbasedplanninghandbookv8-201224023045/85/Deliverables-based-planning-handbook-76-320.jpg)
![Forecast Of Future Performance Based On
TCPI, IEAC, and Work Sequence
¨ Develop a new forecast of cost and schedule with the new
sequence of Work Packages.
¨ Base this forecast on the To Complete Performance Index (TCPI)
and the Independent Estimate At Complete (IEAC)
[Henderson08].
¨ There are five IEAC indices.
¤ IEAC1 = BAC / CPI
¤ IEAC2 = ACWP + (BAC – BCWP) / SPI
¤ IEAC3 = ACWP + (BAC – BCWP) / (SPI x CPI)
¤ IEAC4 = ACWP + (BAC – BCWP) / ((wt1 x SPI) + (wt2 x CPI))
¤ IEAC5 = ACWP + (BAC – BCWP) / CPIx
ChapterII
79](https://image.slidesharecdn.com/deliverablesbasedplanninghandbookv8-201224023045/85/Deliverables-based-planning-handbook-79-320.jpg)
![Define the set of capabilities needed to achieve the program objectives or the particular end
state for a specific scenario. Using the ConOps, define the details of who, where, and how it
is to be accomplished, employed and executed.
Process Activities Outcomes or Deliverables Benefits
Using the supplied Statement of Work (SOW),
Statement of Objectives (SOO) extract a
description of the operational behavior of the
system in a Concept of Operations (ConOps)
and an associated process flow diagram.
A Process Flow Diagram of the system with
verbs in the boxes and nouns on the lines.
This can be done in Visio using the IDEFÆ
notation, or some other systems engineering
process and element diagramming method
[IDEFÆ].
A single diagram showing the system
components, the data or actions it produces,
and how these components interact.
This diagram shows the increasing maturity of
the system as is proceeds from left to right in
the Integrated Master Plan (IMP), through each
Program Event.
With the Process Flow Diagram, identify the
Accomplishments for each Milestone or Event.
Identify the dependencies between each
Accomplishment within and between the
Integrated Product Team (IPT) stream.
For each Event or Milestone, build a single
page chart for each Accomplishment for each
Integrated Product Team (IPT) members work
stream.
These diagrams show how each Event or
Milestone will be met from the completion of
the Accomplishment s.
With the dependencies identified, a top level
precedence diagram is now available for the
development of the Integrated Master
Schedule (IMS).
With each Accomplishment defined and
arranged in a sequence of increasing maturity
within the Event or Milestone, capture the
Criteria for the assessment of the
Accomplishment.
These Criteria are the “Exit Criteria” for the
Work Packages containing the Work Tasks.
The exit criteria for the work effort will be
defined in terms meaningful to the assessment
of Physical Percent Complete and the
completion of the Accomplishment.
Connections from Milestone or Event, to
Accomplishments and to the Criteria describe
the increasing maturity of the program.
This is more than just the traditional list of items
in the Integrated Master Plan. But a description
of the program’s process flow and its
increasing value.
1
Chapter III83](https://image.slidesharecdn.com/deliverablesbasedplanninghandbookv8-201224023045/85/Deliverables-based-planning-handbook-83-320.jpg)
![1.0 – Identify Needed System Capabilities
Discovering needed system requirements begins with the a
narrative description of the needed Capabilities. Defining
capabilities provides a rational basis for making decisions
about requirements and allows planning to be responsive to
uncertainty. [TTCP]
This sounds like a tautology – a Chicken or the Egg problem.
But discovering the system requirements is difficult in the
absence of some higher level description of the needed
“Capabilities” of the desired system.
The concept of a “Capability” is a capacity or potential
[Davis]:
§ Provided by a set of resources and abilities
§ To achieve a measureable result
§ In performing a particular task
§ Under specific conditions
§ To specific performance standards
One approach to capturing the system capabilities is:
§ Start with the customers understanding the current and
future operational needs of their system.
§ Aligning those needs with industry standards and trends.
Translating the needs into system capabilities in the form of
system requirements specification or a Concept of
Operations. The Systems Requirements Specification is not
the same as a Technical Requirements Specification.
Establish a high–level system concept to identify system
components and their interfaces.
Guide the Integrated Product and Process Development
(IPPD) Teams, mentoring, and working with providers of
system components (both custom built and COTS) to ensure
they adhere to the overall system view.
Work with the customer to identify and mitigate technical
risks through a structured Risk Management process at the
Systems Requirements level.
Verify each system capability through a System Integration
and Qualification Test Plan.
Work with the customer to develop a Fielding and Product
Support Plan of the delivered system.
ChapterIV
90](https://image.slidesharecdn.com/deliverablesbasedplanninghandbookv8-201224023045/85/Deliverables-based-planning-handbook-90-320.jpg)
![§ Partition system capabilities into classes of service within operational scenarios
§ Connect capabilities to system requirements using sysML
§ Define Measures of Effectiveness (MOE) and Measures of Performance (MOP)
§ Define in the delivery schedule the achievement of each Technical Performance Measure
Process Activities Outcomes or Deliverables Benefits
1
Decompose the SOW, SOO,
and other RFP and system
documents, into a Concept of
Operations (ConOps).
§ A Top–to–bottom System Traceability Structure as the starting
point for the Requirements Management Baseline.
§ This structure is a “map” of the needed capabilities, their
interrelationships. This forms the basis of the requirements
flow down process.
Starting at the beginning of the program
capture capabilities in a form that can be
used to trace requirements, deliverables and
performance measures back to these
capabilities.
2
Build a map between the
System Capabilities in the
using the Design Structure
Matrix. [Browning99]
§ Design Structure Matrix showing dependencies between
operational capabilities.
§ Optimized structural alternatives suggesting re–architecting
of these dependencies.
Place all information in a common database
for analysis, publishing, and change control.
3
Define Measures of
Effectiveness (MOE) for each
capability.
How would the presence of
the capability be
recognized?
§ The Measures of Effectiveness (MOEs) are quantitative
measures that provide some insight into how effectively a
product or service is performing.
§ MoE’s are derived from stakeholder expectation statements.
§ MoE’s are deemed critical to the mission or operational
success of the system
§ For example: “95% of all work will be completed within 15
business days or the negotiated deadline.”
The basis of physical percent complete can
be defined with measures of effectiveness.
4
Define Measures of
Performance (MOP) for each
capability.
How would the presence of
the capability be
recognized?
§ MoPs serve as criteria to hierarchically organize these MoEs.
§ MoPs are qualitative or quantitative measures of system
capabilities or characteristics as seen from the providers
point of view.
§ MoPs are broad physical and performance parameters.
§ MoPs are components, or subsets, of MoEs; i.e., the "degree–
to–which" a system performs is one of a number of possible
measures of "how well" a system's task is accomplished.
The basis of physical percent complete can
be defined with measures of performance.
1.1
Chapter IVChapter IV92](https://image.slidesharecdn.com/deliverablesbasedplanninghandbookv8-201224023045/85/Deliverables-based-planning-handbook-92-320.jpg)
![§ Define scenarios for each system capability
§ Connect these scenarios to a Value Stream Map
§ Assess value flow through the map for each needed capability
§ Identify capabilities mismatches and make corrections to improve overall value flow
Process Activities Outcomes or Deliverables Benefits
1
List individual capabilities in scenario forms:
Use Case, process flows, or an operational
description
Scenario Based Descriptions using some
notation amenable to systems analysis –
IDEFÆ or SysML.
A single integrated representation of the
needed capabilities in a form assessable with
formal tools.
2
Assess dependencies between capabilities
using Design Structure Matrix (DSM) tool
Identify implicit dependencies as well as
explicit dependencies in a DSM.
Remove or minimize the implicit dependencies.
Address interface management issues with the
explicit dependencies.
3
Perform a Functional Area Analysis (FAA)
[INCOSE]
Characterize a specific area of the system in
terms of the operations that are required to
be performed to support the mission in a FAA.
Produces a focus on provides capabilities
based on functional scenarios rather than
specific technologies.
4
Performance a Functional Needs Assessment
(FNA) [INCOSE]
Assess the ability of the current and planned
systems to deliver the capabilities
identified in the FAA.
Produces a focus on identifying gaps in both
the scenarios and the functional behaviors
needed to fulfill those scenarios.
5
Perform a Functional Solutions Analysis (FSA)
[INCOSE]
An operationally–based assessment of all
potential organizational, training,
technological, material, leadership, personnel
and facilities and the supporting policy
approaches to solving (or mitigating) one or
more of the capability gaps identified in the
FNA.
Produces a focus of identifying all
participating elements of the system beyond
the technological deliverables.
1.2
Chapter IVChapter IV93](https://image.slidesharecdn.com/deliverablesbasedplanninghandbookv8-201224023045/85/Deliverables-based-planning-handbook-93-320.jpg)
![§ Assign costs to a system element using a value model process model
§ Assure risk, probabilistic cost and benefit performance attributes are defined
§ Use cost, schedule and technical performance probabilistic models to forecast
potential risks to program performance
Process Activities Outcomes or Deliverables Benefits
1
For each implicit and explicit dependency
asses the nouns and verbs that cross the
interface boundary.
A weighted Trade Space Matrix for each
capability used to assess the cost and benefit
for each requirement that has alternative
choices of implementation.
ü Establish a common vocabulary for
making tradeoffs between desired or
needed capabilities in a form beyond just
personal assessment.
2
Assign cost, risk, and operational needs for
each capability and its impact on the
adjacent interface element.
A monetized assessment of each “trade
space” element used to build a credible
business model for the trade space decisions.
ü Document these trade offs in a formal
manner (sysML) that can be used by
analysis tools [Sharman].
3
Make assessments between cost, risk, and
operational needs in some form of
mathematical model.
Quantitative data showing the relationship
between these elements.
ü A tangible assessment of the “trade
space” between the programmatic
elements of the system.
4
From the data above, perform CAIV (Cost As
an Independent Variable) assessment. Set
aggressive, but realistic cost objectives when
defining operational requirements and
acquiring defense systems and managing
achievement.
Adjusted program cost objectives through the
use of cost‒performance analyses and
trade‒offs.
ü Execution of the program in a way to
meet or reduce stated cost objectives.
ü Realization that risks are present and
must be understood and managed in
order to achieve performance, schedule
and cost objectives.
5
For the CAIV process define the maximum
and minimum affordable price and the
maximum and minimum performance
thresholds.
Trade studies that address meeting user
performance needs and cost / resource
constraints, while performing on schedule with
minimal acceptable risk.
ü Visibility in the probability of success for
the program based on the trade space of
cost, schedule, and technical
performance.
1.3
Chapter IVChapter IV94](https://image.slidesharecdn.com/deliverablesbasedplanninghandbookv8-201224023045/85/Deliverables-based-planning-handbook-94-320.jpg)
![Action Outcome
Implement Strategy
Ensure Capabilities
Prioritize Problems And Solutions
Identify Redundancies
Deliver Solutions
Chapter IVChapter IV97 † [Kossakowski]](https://image.slidesharecdn.com/deliverablesbasedplanninghandbookv8-201224023045/85/Deliverables-based-planning-handbook-97-320.jpg)
![2.0 – Establish the Requirements Baseline
Poorly formed requirements have been shown to contribute
as much as 25% to the failure modes of programs and
projects.
Requirements engineering can be decomposed into the
activities of requirements elicitation, specification, and
validation. Most of the requirements techniques and tools
today focus on specification, i.e., the representation of the
requirements. The Deliverables Based Planning® method
concentrates instead on elicitation. This method addresses
problems found with requirements engineering that are not
adequately addressed by specification techniques. [Christel]
This Deliverables Based Planning®
method incorporates
advantages of existing elicitation techniques while
addressing the activities performed during requirements
elicitation. These activities include fact–finding, requirements
gathering, evaluation and rationalization, prioritization, and
integration.
The requirements baseline is established starting with a Fact
Finding activity. This does not search for requirements, but
instead defines the boundaries of the requirements space.
With these boundaries established, the actual requirements
can be gathered and classified. The classification process is
an important state for assessing the need, evaluation, and
tradeoff processes.
Evaluating the requirements is done against the background
of the system boundaries and system capabilities.
With these evaluation, prioritization can start. These
prioritizations assess the order in which the requirements will
be deployed against the funding and resource limitations.
With the requirements prioritized, they can then be
integrated and validated. The integration process defines
the interdependencies between requirements that guide the
development of the Work Packages that produce the
deliverables that fulfill the requirements.
ChapterV
100](https://image.slidesharecdn.com/deliverablesbasedplanninghandbookv8-201224023045/85/Deliverables-based-planning-handbook-100-320.jpg)
![§ Decompose the Project Scope into a product based Work Breakdown Structure (WBS)
§ Decompose WBS into Work Packages describing the production of all deliverables
traceable to the requirements
Process Activities Outcomes or Deliverables Benefits
1
Map the desired system capabilities into
categories of system elements.
A Requirements Flow Down Tree from the
requirements to Work Packages that produce
deliverables.
Continue with full traceability from capability
to deliverables.
2
Build a Work Breakdown Structure derived
from the requirements categories. Focus on
products that are delivered from the work
effort.
Construct a product centric WBS. Not a
functional WBS. This WBS should follow the
100% rule [MIL 881] and the Mutually
Exclusive rule (no overlap between WBS
elements).
Assign resources and functional to each
deliverables in the WBS (product breakdown
tree). The WBS describes “planned outcomes”
not “planned activities.”
3
Decompose the requirements into collections
of deliverables at the terminal nodes of the
WBS.
Assembly collections of requirements into
logical “lumps of work” for assignment to
subject matter experts for estimating
Discovering how the “lumps of work” are
related is an iterative process. making them
visible is the start.
4
Produce a requirements traceability matrix in
some form of automated tool. Quality
Function Deployment (QFD) or Design
Structure Matrix (DSM). [Danilovic]
Using the WBS, the requirements tree and
other relationship models, use DSM to
construct a dependency model.
Making visible explicit and implicit
relationships is critical to verify requirements
and avoiding conflicts.
5
Examine the decomposition to determine if all
the components are clear and complete.
Using the model verify interdependencies are
needed.
Reduce coupling and increase cohesion of the
requirements.
6
Determine if each component listed is
absolutely necessary to fulfill the
requirements of the deliverable and verify
that the decomposition is sufficient enough to
describe the work.
Assessment of the necessity for each
requirement.
Complete the traceability from requirements
up to capabilities and from capabilities down
to requirements.
3.1
Chapter VIChapter VI112](https://image.slidesharecdn.com/deliverablesbasedplanninghandbookv8-201224023045/85/Deliverables-based-planning-handbook-112-320.jpg)
![IDEFÆ Diagrams
The IDEFÆ Functional Modeling method is designed to model
the decisions, actions, and activities of an organization or
system.[2] It was derived from the established graphic
modeling language Structured Analysis and Design
Technique (SADT) developed by Douglas T. Ross and SofTech,
Inc.. In its original form, IDEFÆ includes both a definition of a
graphical modeling language (syntax and semantics) and a
description of a comprehensive methodology for developing
models.[3] The US Air Force commissioned the SADT
developers "to develop a function model method for
analyzing and communicating the functional perspective of a
system. IDEFÆ should assist in organizing system analysis and
promote effective communication between the analyst and
the customer through simplified graphical devices".[2]
Where the Functional flow block diagram is used to show the
functional flow of a product, IDEFÆ is used to show data
flow, system control, and the functional flow of life cycle
processes. IDEFÆ is capable of graphically representing a
wide variety of business, manufacturing and other types of
enterprise operations to any level of detail. It provides
rigorous and precise description, and promotes consistency
of usage and interpretation. It is well-tested and proven
through many years of use by government and private
industry. It can be generated by a variety of computer
graphics tools. Numerous commercial products specifically
support development and analysis of IDEFÆ diagrams and
models.
An associated technique, Integration Definition for
Information Modeling (IDEF1x), is used to supplement IDEFÆ
for data intensive systems. The IDEFÆ standard, Federal
Information Processing Standards Publication 183 (FIPS 183),
and the IDEF1x standard (FIPS 184) are maintained by the
National Institute of Standards and Technology (NIST).
IDEFÆ may be used to model a wide variety of automated
and non-automated systems. For new systems, it may be used
first to define the requirements and specify the functions, and
then to design an implementation that meets the requirements
and performs the functions. For existing systems, IDEFÆ can
be used to analyze the functions the system performs and to
record the mechanisms (means) by which these are done. The
result of applying IDEFÆ to a system is a model that consists
of a hierarchical series of diagrams, text, and glossary cross-
referenced to each other. The two primary modeling
components are functions (represented on a diagram by
boxes) and the data and objects that inter-relate those
functions (represented by arrows).
180
ChapterX](https://image.slidesharecdn.com/deliverablesbasedplanninghandbookv8-201224023045/85/Deliverables-based-planning-handbook-180-320.jpg)
![Requirements Framework
Business requirements are statements of the business
rationale for the project. These requirements grow out of the
vision for the product which, in turn, is driven by mission (or
business) goals and objectives. The product’s vision statement
articulates a long-term view of what the product will
accomplish for its users. It should include a statement of scope
to clarify which capabilities are and are not to be provided
by the product. [Gottesdiener]
Putting all this information into a framework is next. We’ll do
this in preparation for our exercise that’s coming up.
User requirements define the software requirements from the
user’s point of view, describing the tasks users need to
accomplish with the product and the quality requirements of
the software from the user’s point of view. Users can be
broadly defined to include not only the people who access
the system but also inanimate users such as hardware
devices, databases, and other systems. In the systems
produced by most government organizations, user
requirements are articulated in their concept of operations
document.
This framework is one of many, but it’s simple, and even
useful for our current needs and the future needs as well. This
framework does several things:
1. It uses the separation of product and process that was
shown earlier.
2. It asks 5 of the 6 question in Rudyard Kipling “Six Honest
Serving Men” from “The Elephants Child.” “Where” is
missing, but we know where – we are at the location
where we are gathering requirements for our systems.
3. It demonstrates the layering of the requirements and
their evolutionary nature.
4. It shows some of the techniques for managing these
requirements.
Each requirements model represents information at a
different level of abstraction. A model such as a state
diagram represents information at a high level of
abstraction, whereas detailed textual requirements represent
a low level of abstraction. By stepping back from the trees
(textual requirements) to look at the forest (a state diagram),
the team can discover requirements defects not evident when
reviewing textual requirements alone.
Because the requirements models are related, developing
one model often leads to deriving another. Examples of one
model driving another model are the following:
§ Actors initiate use cases.
§ Scenarios exemplify instances of use cases.
§ A use case acts upon data depicted in the data model.
§ A use case is governed by business rules.
§ Events trigger use cases.
184
ChapterX](https://image.slidesharecdn.com/deliverablesbasedplanninghandbookv8-201224023045/85/Deliverables-based-planning-handbook-184-320.jpg)
![Chapter I References
Principles and Practices of DBP®
[INCOSE] Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities, INCOSE–TP–2003–002–03.1,
August 2007, www.incose.org
[Stevens] Systems Engineering: Coping with Complexity, Richard Stevens, Peter Brook, Ken Jackson, and Stuart Arnold, Prentice
Hall, 1998.
[Wood] Henri Fayol: Critical Evaluations in Business and Management, John C. Wood and Michael C. Wood, Routedge, 2002.
[Pisano] “Technical Performance Measurement, Earned Value, and Risk Management: An Integrated Diagnostic Tool for
Program Management,” Commander N. D. Pisano, SC, USN, Program Executive Office for Air ASW, Assault, and
Special Mission Programs (PEO(A))
AppendixA
213](https://image.slidesharecdn.com/deliverablesbasedplanninghandbookv8-201224023045/85/Deliverables-based-planning-handbook-213-320.jpg)
![Chapter II References
The 10 Principles of DBP®
[Pruitt03] Modeling Homeland Security: A Value Focused Thinking Approach, Kristopher Pruitt, Air Force Institute of Technology,
March 2003
[Solomon] Performance Based Earned Value, Paul Solomon.
[PMBOK] Guide to the Project Management Body of Knowledge, Project Management Institute.
[Brooks87] “No Silver Bullet: Essence and Accidents of Software Engineering, Fred Brooks, IEEE Computer, 10‒19, April 1987.
[Grady06] Systems Requirements Analysis, Jeffry O. Grady, Academic Press, 2006.
[Henderson08] “Further Development in Earned Schedule,” Kym Henderson, The Measureable News, Spring 2004.
[Lipke] “Schedule is Different,” Walter Lipke, The Measureable News, Summer 2003.
[Vanhoucke] “A Simulation and Evaluation of Earned Value Metrics to Forecast Project Duration,” M. S. Vanhoucke, Journal of
Operations Research Society, October 2007.
[IEEE1220] Standard for Application and Management of the Systems Engineering Process, Institute of Electrical and Electronics
Engineers, 09–Sep–2005
[Stevens98] Systems Engineering: Coping with Complexity, Richard Stevens, Peter Brook, Ken Jackson, and Stuart Arnold, Prentice
Hall, 1998.
[Young04] The Requirements Engineering Handbook, Ralph R. Young, Artech House, 2004
[Pisano] “Technical Performance Measurement, Earned Value, and Risk Management: An Integrated Diagnostic Tool for
Program Management,” Commander N. D. Pisano, SC, USN, Program Executive Office for Air ASW, Assault, and
Special Mission Programs (PEO(A))
[Christel92] “Issues with Requirements Elicitation,” Michael G. Christel and Kyo C. Kang, Technical Report, CMU/SEI–92–TR–12,
Software Engineering Institute, Carnegie Mellon University Pittsburgh, Pennsylvania 15213.
[Danilovic] “Managing complex product development projects with design structure matrices and domain mapping matrices,”
Mike Danilovic and Tyson Browning, International Journal of Project Management, 25 (2007), pp. 300–314.
AppendixA
214](https://image.slidesharecdn.com/deliverablesbasedplanninghandbookv8-201224023045/85/Deliverables-based-planning-handbook-214-320.jpg)
![Chapter II References
The 10 Principles of DBP®
[Sharman] “Architectural optimization using real options theory and Dependency structure matrices,” David M. Sharman, Ali A.
Yassine+, Paul Carlile, Proceedings of DETC ’02 ASME 2002 International Design Engineering Technical Conferences
28th Design Automation Conference Montreal, Canada, September 29–October 2, 2002.
[Browning] “Modeling and Analyzing Cost, Schedule, and Performance in Complex System Product Development,” Tyson
Browning, Massachusetts Institute of Technology, February 1999.
[TIPMH] The Integrated Project Management Handbook, Dayton Aerospace, 8 Feb 2002, Dayton Ohio.
[Davis] “Analytic Architecture for Capabilities–Based Planning, Mission–System Analysis, and Transformation,” Paul K. Davis,
RAND Corporation.
[INCOSE] Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities, INCOSE–TP–2003–002–
03.1, August 2007, www.incose.org
AppendixA
215](https://image.slidesharecdn.com/deliverablesbasedplanninghandbookv8-201224023045/85/Deliverables-based-planning-handbook-215-320.jpg)
![Chapter III References
Deploying Deliverables Based Planning®
[IDEFÆ] http://www.idef.com/idef0.html
AppendixA
216
Deliverables Based Planning ® is a registered trademark of Lewis & Fowler. Copyright ® Lewis & Fowler, 2011](https://image.slidesharecdn.com/deliverablesbasedplanninghandbookv8-201224023045/85/Deliverables-based-planning-handbook-216-320.jpg)
![Chapter IV References
Identify Needed Systems Capabilities
[Davis] “Analytic Architecture for Capabilities–Based Planning, Mission–System Analysis, and Transformation,” Paul K. Davis,
RAND Corporation.
[Davis] Portfolio-Analysis Methods for Assessing Capability Options, Paul K. Davis, Russell D. Shaver, and Justin Beck, Rand
Corporation, 2008
[Sharman] “Architectural optimization using real options theory and Dependency structure matrices,” David M. Sharman, Ali A.
Yassine+, Paul Carlile, Proceedings of DETC ’02 ASME 2002 International Design Engineering Technical Conferences
28th
Design Automation Conference Montreal, Canada, September 29–October 2, 2002.
[Browning99] “Modeling and Analyzing Cost, Schedule, and Performance in Complex System Product Development,” Tyson
Browning, Massachusetts Institute of Technology, February 1999.
[Maier] The Art of Systems Architecting, Mark W. Maier and Eberhardt Rechtin, CRC Press, 2000.
[Stevens] Systems Engineering: Coping With Complexity, Richard Stevens, Peter Brook, Ken Jackson, and Stuart Arnold, Prentice
Hall, 1998.
[Dewer] Assumption Based Planning: A Tool for Reducing Avoidable Surprises, James A. Dewar, Cambridge University Press,
2002.
[Kossakowski] Capabilities-Based Planning: A Methodology for Deciphering Commander’s Intent, Peter Kossakowski, Evidence Based
Research, Inc. 1595 Spring Hill Road, Suite 250 Vienna, VA 22182.
[Stalk] Competing on Capabilities: The New Rules for Corporate Strategy, George Stalk, Philip Evans, and Lawrence Shulman,
Harvard Business Review, No. 92209, March-April 1992.
[Jeffery] Effects-Driven, Capabilities-Based, Planning for Operations, Maj Kira Jeffery, USAF and Mr Robert Herslow.
[Saunders] Effects-based Operations: Building Analytical Tools, Desmon Saunder-Newton and Aaron B. Frank, Defense Horizons,
October 2002, pp 1-8.
[TTCP] Guide to Capability-Based Planning, Joint Systems and Analysis Group, MORS Workshop, October 2004,
Alexandria, VA. http://www.mors.org/
AppendixA
217](https://image.slidesharecdn.com/deliverablesbasedplanninghandbookv8-201224023045/85/Deliverables-based-planning-handbook-217-320.jpg)
![Chapter V References
Establish the Requirements Baseline
[Christel] “Issues with Requirements Elicitation,” Michael G. Christel and Kyo C. Kang, Technical Report, CMU/SEI–92–TR–12,
Software Engineering Institute, Carnegie Mellon University Pittsburgh, Pennsylvania 15213.
[Young] The Requirements Engineering Handbook, Ralph R. Young, ArcTech House, 2004
[Boehm] Software Risk Management, Barry W. Boehm, IEEE Computer Society Press, 1989.
[David] Software Requirements Analysis & Specifications, Alan M. Davis, Prentice Hall, 1990.
[Sommerville] Requirements Engineering: A Good Practice Guide, Ian Sommerville and Pete Sawyer, John Wiley & Sons, 1997.
[Grady] Systems Requirements Practices, Jeffery O. Grady, McGraw Hill, 1993
[Ebert] Four Key Requirements Engineering Techniques, Christof Ebert, IEEE Software, May / June 2006.
[Leveson] Intent Specifications: An Approach to Building Human-Centered Specifications, Aeronautics and Astronautics, MIT.
[Leveson] Sample TCAS Intent Specification, Nancy Leveson and Jon Damon Reese, Software Engineering Corporation .
AppendixA
218](https://image.slidesharecdn.com/deliverablesbasedplanninghandbookv8-201224023045/85/Deliverables-based-planning-handbook-218-320.jpg)
![Chapter VI References
Establish the Performance Measurement Baseline
[Danilovic] “Managing complex product development projects with design structure matrices and domain mapping matrices,”
Mike Danilovic and Tyson Browning, International Journal of Project Management, 25 (2007), pp. 300–314.
[MIL 881] MIL–STD–881A, Work Breakdown Structures.
[Morris] The Management of Projects, Peter W. G. Morris, Thomas Telford, 1994
[Williams] Modelling Complex Projects, Terry Williams, John Wiley & Sons. 2002.
[Brown] The Handbook of Program Management, James T. Brown, McGraw Hill, 2007.
[Brown] AntiPatterns in Project Management, William J. Brown, Hays W. McCormick III, and Scott W. Thomas, John Wiley &
Sons, 2000
AppendixA
219](https://image.slidesharecdn.com/deliverablesbasedplanninghandbookv8-201224023045/85/Deliverables-based-planning-handbook-219-320.jpg)
![Chapter VII Reference
Execute the Performance Measurement Baseline
[Fleming] Earned Value Management, 3rd
Edition, Quentin W. Fleming and Joel M. Koppelman, Project Management Institute, 2005.
AppendixA
220](https://image.slidesharecdn.com/deliverablesbasedplanninghandbookv8-201224023045/85/Deliverables-based-planning-handbook-220-320.jpg)
![Chapter VIII References
Continuous Risk Management
[Bolles] “Understanding Risk Management in the DoD,” Mike Bolles, Acquisition Research Journal, Volume 10, pp. 141–145,
2003.
[Conrow] Effective Risk Management: Some Keys to Success, 2nd
Edition, Edmund H. Conrow, AIAA Press, 2003.
[Hall] Managing Risk: methods for Software Systems Development, Elaine M. Hall, Addison Wesley, 1998
[NDIA] Integrating Risk Management with Earned Value Management, National Defense Industry Association.
[Risk] Three point estimates and quantitative risk analysis a process guide for risk practitioners, Acquisitioning Operating
Framework, UK Ministry of Defense, http://www.aof.mod.uk/index.htm
[Hillson] Effective Opportunity Management for Project: Exploring Positive Risk, David Hillson, Taylor & Francis, 2004.
[Bennatan] Catastrophe Disentanglement: Getting Software Projects Back on Track, E. M. Bennatan, Addison Wesley, 2006.
[Karolak] Software Engineering Risk Management, Dale Walter Karolak, IEEE Computer Society Press, 1998.
[Jones] Assessment and Control of Software Risks, Capers Jones, Prentice Hall, 1994
[AOF] Three Point Estimates and Quantitative Risk Analysis - A Process Guide For Risk Practitioners - version 1.2 May 2007 -
Risk Management – AOF, http://www.aof.mod.uk/aofcontent/tactical/risk/downloads/3pepracgude.pdf
[Lister] How much risk is too much risk?, Tim Lister, Boston SPIN, January 20th
, 2004.
[INCOSE] Risk Management Maturity Level Development, INCOSE Risk Management Working Group, April 2002.
[Arízaga] “A Methodology for Project Risk Analysis using Bayesian Belief Networks within a Monte Carlo Simulation Environment,”
Javier F. Ordóñez Arízaga, University of Maryland, College Park, 2007.
[USAF] AFMC PAMPHLET 63-101, 9 July 1997.
[Valerdi] An Approach to Technology Risk Management, Ricardo Valerdi and Ron J. Kohl, Engineering Systems Division
Symposium, MIT, Cambridge, MA 29-31 March 2004.
AppendixA
221](https://image.slidesharecdn.com/deliverablesbasedplanninghandbookv8-201224023045/85/Deliverables-based-planning-handbook-221-320.jpg)
![Chapter VIII References
Continuous Risk Management
[Bahill] “An Industry Standard Risk Analysis Technique,” A Terry Bahill and Eric D. Smith, Engineering Management Journal,
Vol. 21 No 4., December 2009.
[ASE] Risk Management Process and Implementation, American Systems Corporation, 2003.
[Kandaswamy] The Basics of Monte Carlo Simulation: A Tutorial, S. Kandaswamy, Proceedings of the Project Management Institute
Seminars & Symposium, 1-10 November 2001.
[NASA] Bayesian Inference for NASA Probabilistic Risk and Reliability Analysis, NASA/SP-2009-569, June 2009.
[Alberts] Common Elements of Risk, Christopher J. Alberts, CMU/SEI-2006-TN-014, April 2006.
[Conrow] “Development of Risk Management Defense Extensions to the PMI Project Management Body of Knowledge,”
Edmund H. Conrow, Acquisition Review Quarterly, Spring 2003.
[Dorofee] Continuous Risk Management Guidebook, Audrey J. Dorofee, Julie A. Walker, Christopher J. Alberts, Ronald P.
Higuera, Richard L. Murphy, and Ray C. Williams, Software Engineering Institute, 1996.
[DoD] Risk Management Guide for DoD Acquisition, Fifth Edition, June 2002.
[Drucker] Emerging Practice: Joint Cost & Schedule Risk Analysis, Eric Drucker, 2009 St. Louis SCEA Chapter Fall Symposium,
St’ Louis, MO.
[Coleman] Making Risk Management Tools More Credible: Calibrating the Risk Cube, Richard L. Coleman, Jessica R.
Summerville, and Megan E. Dameron, SCEA 2006, Washington, D.C., 12 June 2006.
[Book] A Theory of Modeling Correlations for Use in Cost-Risk Analysis, Stephen A. Book, Third Annual Project
Management Conference, NASA, Galveston, TX, 21-22 March 2006.
[Butts] The Joint Confidence Level Paradox: A History of Denial, 2009 NASA Cost Symposium, 28 April 2009.
AppendixA
222](https://image.slidesharecdn.com/deliverablesbasedplanninghandbookv8-201224023045/85/Deliverables-based-planning-handbook-222-320.jpg)
![Chapter X References
Tools and Artifacts
[Yassine] An Introduction to Modeling and Analyzing Complex Product Development Processes Using the Design Structure
Matrix (DSM) Method, Ali A. Yassine
[Browning] Browning, T. & Eppinger, S., “Modeling Impacts of Process Architecture on Cost and Schedule Risk in Product
Development,” IEEE Transactions on Engineering. Management, 49(4): 428–442, 2002.
[Danilovic] Managing complex product development projects with design structure matrices and domain mapping matrices,
Mike Danilovic and Tyson R. Browning, International Journal of Project Management.
[DoD] Risk Management Guide for DOD Acquisition, US Department of Defense.
[FIPS 184] Federal Information Processing Standard Publication 184: Integrated Definition for Information Modeling, 21
December 1993.
[Gottesdiener] Good Practices for Developing User Requirements, Crosstalk, May 2008, pp. 13-17.
AppendixA
223](https://image.slidesharecdn.com/deliverablesbasedplanninghandbookv8-201224023045/85/Deliverables-based-planning-handbook-223-320.jpg)
Uploaded byGlen Alleman
Deliverables based planning handbook
Deliverables Based Planning® integrates five critical program management principles with cost, schedule, and technical performance measures to increase the probability of program success. The document outlines these principles and practices through 10 chapters. It defines deliverables based planning, discusses its origins and benefits over conventional cost and schedule-only approaches. It describes identifying needed system capabilities, establishing requirements and performance baselines, executing work, and applying continuous risk management. The goal is to answer key questions around objectives, requirements, plans, execution and risks to deliver the needed capabilities on time and budget.
More Related Content
Similar to Deliverables based planning handbook
![Getting Started with Apache Spark: Big Data Made Simple [Free Meetup]](https://cdn.slidesharecdn.com/ss_thumbnails/apachesparkgettingstarted-260203175547-8361bcc3-thumbnail.jpg?width=640&height=640&fit=bounds)
Deliverables based planning handbook
- 1. Niwot Ridge, LLC DELIVERABLESBASED PLANNING® Principles and Practices that increase the Probability of Program Success (PoPS). V8.3.a 12/23/20
- 2.
- 3. Chapter Title Page Chapter0 Deliverables Based Planning in a Nutshell 5 Chapter I Principles and Practices of Deliverables Based Planning® 45 Chapter II The 10 Principles of Deliverables Based Planning® 55 Chapter III Deploying Deliverables Based Planning® 79 Chapter IV Process 1.0 – Identify Needed Systems Capabilities 87 Chapter V Process 2.0 – Establish the Requirements Baseline 97 Chapter VI Process 3.0 – Establish the Performance Measurement Baseline 107 Chapter VII Process 4.0 – Execute the Performance Measurement Baseline 117 Chapter VIII Process 5.0 – Continuous Risk Management 127 Chapter IX Graded Application of Deliverables Based Planning® 147 Chapter X Tools and Artifacts used in Deliverables Based Planning® 159 Append A References for each Chapter 207 Table of Contents 3 Deliverables Based Planning ® is a registered trademark of Niwot Ridge LLC,
- 4.
- 5. Deliverables Based Planning® integratesfive critical program management principles with: § Cost, § Schedule, and § Technical Performance Measures, … assuring actionable information is provided to the decision makers to increase the probability of program success. 5 0Deliverables Based Planning® in a Nutshell Chapter
- 6. Deliverables Based Planning® InA Nutshell Increasing Your Probability of Success(sm) Chapter 06
- 7. Why Deliverables BasedPlanning®? ¨ The customer bought capabilities to fulfill the mission:† ¤ Not the work effort, ¤ Not the cost expenditures, and, ¤ Not, the documentation, test results, or the work processes. ¨ All successful programs deliver tangible beneficial outcomes, defined in units of measure meaningful to the decision makers. Deliverables Based Planning® † Mission defines the fundamental purpose of an organization or an enterprise, and states why it exists and what it does to achieve its Vision. 7 Chapter0
- 8. 1. What DoesDONE Look Like? 2. How Do We Get There? 3. Is There Enough Time, Resources, And Money To Get There? 4. What Impediments Will Be Encountered Along The Way? 5. What Are The Units Of Measures For Progress To Plan? All Successful Projects Must Know The Answer To 5 Questions 8Lewis & Fowler, Copyright © 2011
- 9. 11 Critical PracticesNeeded to Answer the 5 Questions of Project Success 9 ¨ Define the Work Breakdown Structure(WBS). ¨ Indentify the Organizational Breakdown Structure (OBS). ¨ Integrate the WBS and OBS. ¨Organization ¨ Schedule the work. ¨ Identify the Products and Milestones. ¨ Set the time phased budget. Planning and Budgeting ¨ Record direct costs. Accounting ¨ Determine variances. ¨ Sum Data and variances. ¨ Manage action plans. Performance Analysis ¨ Incorporate Changes. Revision Management Deliverables Based Planning ® is a registered trademark of Lewis & Fowler. Copyright ® Lewis & Fowler, 2011 Chapter0
- 10. Credible Data IsNeed to Increase The Probability Of Program Success ¨ Concept of Operations (ConOps) ¨ Operational Scenarios and Use Cases ¨ Integrated Master Plan (IMP) ¨ Value Stream Maps (VSM) ¨ Key Performance Parameters (KPP) ¨ Measures of Effectiveness (MoE) ¨ Program Planning and Controls (PP&C) ¨ Integrated Master Schedule (IMS) ¨ Work Packages (WP) and Planning Packages (PP) ¨ Earned Value Management (EVM) ¨ Technical and Programmatic Risk Management (RM) ¨ Measures of Performance (MoP) ¨ Estimate At Completion (EAC) ¨ Estimate To Complete (ETC) ¨ To Complete Performance Index (TCPI) ¨ Independent Estimate At Completion (IEAC) ¨ Technical Performance Measures (TPM) 10 Chapter0
- 11. Systems Management Guidesthe Conversion of this Data to Actionable Information ¨ Systems Management is the set of organizational structures and processes that rapidly deliver dependable technological outcomes within a predictable time and budget. ¨ Complexity in large scale systems is not driven by the scale, but rather by the heterogeneity of the components and their individual underlying complexity. ¨ Managing the complex individual components, their interactions, their cost, schedule, and technical performance elements is the role of Systems Management. ¨ DBP® connects the data to provide actionable information to the decision makers. 11 Deliverables Based Planning ® is a registered trademark of Lewis & Fowler. Copyright ® Lewis & Fowler, 2011 Chapter0
- 12. 16 Program ManagementProcesses 12 Program Enablers Program Process Capabilities Business Enablers Chapter0
- 13. Origins of DeliverablesBased Planning® 13 ¨ This planning in the large. ¨ This is planning in the presence of change. ¨ The focus is on transformational outcomes. ¨ Capabilities start with a mission level analysis. www.rand.org Chapter0
- 14. Deliverables Based Planning® Answers 4+1Questions Needed for Success Lewis & Fowler’s Deliverables Based Planning® integrates five critical program management process areas with – Cost, Schedule, and Technical Performance Measures. The inclusion of Technical Performance Measures (TPM) separates our approach from conventional methods based solely on managing cost and schedule. In conventional approaches, the cost and schedule baseline and their variances generate the data for Earned Value variables that are used to make programmatic decisions. In Deliverables Based Planning®, Earned Value measures are integrated with measures of Physical Percent Complete (PPC) derived from Technical Performance Measures (TPM) at planned assessment points in the Integrated Master Schedule (IMS). The Events and Milestones define in the Integrated Master Plan (IMP) describe the planned technical or operational maturity of the products or services measured against their actual technical performance. The Earned Value measurements are used with Technical Performance measures for each deliverable to produce a credible measure of progress and a credible forecast of future performance using the To Complete Performance Index (TCPI). The result is increased visibility and credibility of the Independent Estimate at Completion (IEAC). As the program progresses, technical and programmatic risks are identified, their mitigation or retirement planned and executed, and adjustments to the program made to assure planned progress is maintained. Successfully executing a program requires a Program Planning and Controls discipline that identifies what “Done” looks like, measures progress toward “Done,” identifies the risks and impediments to reaching “Done,” and assures timely corrective action to maintain progress toward “Done.” “Done” is always defined in units of measure meaningful to the customer. The best tangible evidence are the Deliverables needed to meet the requirements that fulfill the system’s requested capabilities that are recognized as success for the program. Using this approach, Deliverables fulfill the requirements that meet the system or business performance criteria, produced at the planned time, using the planned budget. This performance is measured as Physical Percent Complete and is the only Credible measurement of progress. With the planned requirements fulfilled, the system or operational capabilities become available to the customer at the planned time. 14 Deliverables Based Planning ® is a registered trademark of Lewis & Fowler. Copyright ® Lewis & Fowler, 2011 Chapter0
- 15. The 4+1 QuestionsEvery Project Must Answer to be Successful Capabilities Requirements Plans Execution 2. What technical and operational requirements are needed to deliver these capabilities? 1. What capabilities are needed to fulfill the Concept of Operations†, the Mission and Vision, or the Business System Requirements? 3. What schedule delivers the product or services on time to meet the requirements? 4. What periodic measures of physical percent complete assure progress to plan? What impediments to success, their mitigations, retirement plans, or “buy downs are in place to increase the probability of success?” + Continuous Risk Management † A Concept of Operations (ConOps) describes the characteristics of a system from the point of view of an individual who will use that system. It is used to communicate the quantitative and qualitative system characteristics to all stakeholders. Œ Ž Chapter 015
- 16. Deliverables Based Planning® Addresses… Project Management Case Study, Pierre Bonnal, CNAM IIM MBA Program, June 2004 16 Chapter0
- 17. Identify Needed Capabilities Establish a Performance Measurement Baseline Executethe Performance Measurement Baseline Capabilities Based Plan Operational Needs Earned Value Performance 0% /100% Technical Performance Measures System Value Stream Technical Requirements Identify Requirements Baseline Technical Performance Measures PMB Changes to Needed Capabilities Changes to Requirements Baseline Changes to Performance Baseline Œ Ž Chapter 017 Deliverables Based Planning ® is a registered trademark of Lewis & Fowler. Copyright ® Lewis & Fowler, 2011
- 18. Increasing the Maturityof Project Deliverables 1. Identify Needed Capabilities to achieve program objectives or the particular end state. Define these capabilities through scenarios from the customer point of view in units of Measure of Effectiveness (MoE) meaningful to the customer. 2. Define The Technical And Operational Requirements that must be fulfilled for the system capabilities to be available to the customer at the planned time. Define these requirements in terms that are isolated from any implementation technical products or processes. Only then bind the requirements with technology. 3. Establish The Performance Measurement Baseline describing the work to be performed, the budgeted cost for this work, the organizational elements that produce the deliverables from this work, and the Measures of Performance (MoP) showing this work is proceeding according to cost, schedule, and technical performance. 4. Execute the PMB’s Work Packages in the planned order, assuring all performance assessment are 0%/100% complete before proceeding. No rework, no forward transfer of activities to the future. Assure every requirement is traceable to work and all work is traceable to requirements. 5. Perform Continuous Risk Management for each Deliverables Based Planning® process area to Identify, Analyze, Plan, Track, Control, and Communicate programmatic and technical risk. The integration of these five process areas is the foundation of Deliverables Based Planning® . Each process area stands alone and at the same time is coupled with the other process areas. Each process area contains specific process steps for producing beneficial outcomes to the project, while establishing the basis for overall project success. Each process can be developed to the level needed for specific projects. All five process areas are critical to the success of any project. If a process area is missing or poorly developed, the capability to manage the project will be jeopardized, possibly in way not know until the project is too far along to be recovered. Each process provides information needed to make decisions about the flow of the project. This actionable information is the feedback mechanism needed to keep a project under control. These control processes are not impediments of progress of the tools needed to increase the probability of success. Chapter0 18 Deliverables Based Planning ® is a registered trademark of Lewis & Fowler. Copyright ® Lewis & Fowler, 2011
- 19. Increasing the Maturityof Project Deliverables Identify Needed Capabilities Indentify Baseline Requirements Establish Performance Measurement Baseline Execute Performance Measurement Baseline §Define Capabilities §Define ConOps §Assess Needs, Cost, and Risk §Defined Balanced and Feasible Alternatives §Fact Finding §Gather And Classify §Evaluate And Rationalize §Prioritize §Integrate And Validate §Decompose Scope §Assign Accountability §Arrange Work §Develop BCWS §Assign Performance §Perform Work §Accumulate Performance §Analyze Performance §Take Corrective Action Continuous Risk Management (CRM) Define the Measurable Capability Outcomes Assure All Requirements Are Met In Support of Capabilities Define Measures of Performance and Effectiveness Ensure Cost, Schedule, and Technical Performance Chapter0 19
- 20. What is aDeliverable? Project Management Case Study, Pierre Bonnal, CNAM IIM MBA Program, June 2004. Chapter0 20
- 21. Define the setof capabilities needed to achieve the project objectives or the particular end state for a specific scenario. Using the Concept of Operations (ConOps), define the details of who, where, and how this capability is to be accomplished, employed, and executed. Œ Define the technical and operational requirements for the system capabilities to be fulfilled. First, define these requirements in terms isolated from any implementation details. Only then bind the requirements with technology. Build a time–phased network of work activities describing the work to be performed, the budgeted cost for this work, the organizational elements that produce the deliverables, and the performance measures showing this work is proceeding according to plan. Ž Execute work activities, while assuring all performance assessment represent 100% completion before proceeding. This means – No rework, no forward transfer of activities to the future. Assure all requirements are traceable to work & all work is traceable to requirements. Apply the processes of Continuous Risk Management for each Deliverables Based Planning® process area to: Identify, Analyze, Plan, Track, Control, and Communicate programmatic and technical risk. Chapter 021 Deliverables Based Planning ® is a registered trademark of Lewis & Fowler. Copyright ® Lewis & Fowler, 2011
- 22. §Partition system capabilitiesinto classes of service within operational scenarios. §Connect the capabilities to system requirements using some visual modeling notation. §Define Measures of Effectiveness (MoE) and Measures of Performance (MoP). §Define the delivery schedule for each measure of performance and effectiveness. §Define scenarios for each system capability. §Connect these scenarios to a Value Stream Map of the increasing maturity of the program. §Assess value flow through the map for each needed capability. §Identify capability mismatches and make corrections to improve overall value flow. §Assign costs to each system element using a value flow model. §Assure risk, probabilistic cost and benefit performance attributes are defined. §Use cost, schedule and technical performance probabilistic models to forecast potential risks to program performance. §Make tradeoffs that connect cost, schedule, and technical performance in a single location that compares the tradeoffs and their impacts. §Use Measures of Effectiveness (MoE) and Measures of Performance (MoP) for these alternative tradeoffs. Define the capabilities needed to achieve the desired objectives or a particular end state for a specific scenario. Define the details of who, where, and how these capabilities are to be accomplished, employed, and executed. 1.1 1.2 1.3 1.4 Œ Chapter 022
- 23. What Does ACapability “Sound” Like? Chapter0 23
- 24. Identifying Needed SystemCapabilities Identifying System Capabilities is the starting point for any successful program. Systems Capabilities are not direct requirements, but a statements of what the system should provide in terms of “abilities.” For example there are three capabilities needed for the Hubble Robotic Servicing Mission: 1. Do no harm to the telescope. 2. Change the Wide Field Camera. 3. Connect the battery umbilical cable. How is this to be done and what are the technical, operational, safety and mission assurance requirements? Don’t really know yet, but the Capabilities guide their development. The critical reason for starting with capabilities is to establish a home for all the requirements. To answer the question “why is this requirement present?” “Why is this requirement needed?” “What business or mission value does fulfilling this requirement provide?” Capabilities statement can then be used to define the units of measure for program progress. Measuring progress with physical percent complete at each level is mandatory. But measuring how the Capabilities are being fulfilled is most meaningful to the customer. The “meaningful to the customer” unit of measures are critical to the success of any program. Without these measures the program may be cost, schedule, and technically successful but fail to fulfill the mission. The process flow to the right is the starting point for Identifying the Needed Capabilities and determining their priorities. Starting with the Capabilities prevents the “Bottom Up” requirements gathering process from producing a “list” of requirements – all needed – that is missing a well formed topology. This Requirements Architecture is no different than the Technical or Programmatic architecture of the system. Capabilities Based Planning (CBP) focuses on “outputs” rather than “inputs.” These “outputs” are the mission capabilities that fulfilled by the program. In order to fulfill these capabilities, requirements need to be met. But we need the capabilities first. Without the capabilities, it is never clear the mission will be a success, because there is no clear and concise description of what success means. The concept of CBP recognizes the interdependence of systems, strategy organization, and support in delivering the capability, and the need to examine options and trade‒offs in terms of performance, cost and risk to identify optimum development investments. CBP relies on scenarios to provide the context to measure the level of capability. 24 Chapter0
- 25. What Should WeDo? Where Are We Now? Identifying Needed System Capabilities Abstracted from: “Capabilities‒Based Planning – How It Is Intended To Work And Challenges To Its Successful Implementation,” Col. Stephen K. Walker, United States Army, U. S. Army War College, March 2005 Identifying Needed System Capabilities 25 Chapter0
- 26. §Produce an overallstatement of the problem in the operational context. §Develop the overall operational and technical objectives of the target system. §Defined the boundaries and interfaces of the target system. §Gather required system capabilities, functional, nonfunctional and environmental requirements, and design constraints. §Build the Top Down capabilities and functional decomposition of the requirements in a Requirements Management System. §Answer the question “why do I need this?” in terms of operational capabilities. §Build a cost / benefit model using probabilistic assessment of all variables, their dependencies, and impacts. §For all requirements, perform a risk assessment to cost and schedule. §Determine criticality for the functions of the system. §Determine trade off relationships for all requirements to be used when option decisions must be made. §For all technical items, prioritize their cost and dependency. §Address the completeness of requirements by removing all “TBD” items. §Validate that the requirements are traceable to system capabilities, goals, and mission. §Resolve any requirements inconsistencies and conflicts. Define the technical and operational requirements that must be present for the system capabilities to be delivered. Define these requirements in terms isolated from any technology or implementation. Assure each requirement is connected to a need system capability. 2.1 2.2 2.3 2.4 2.5 Chapter 026
- 27. What Is aRequirement? 27 Chapter0
- 28. Identifying Requirements Requirements arethe necessary attributes defined for an item prior to the efforts to develop a design for the item. System requirements analysis is a structured, or organized, methodology for identifying an appropriate set of resources to satisfy a system need (the needed capabilities) and the requirements for those resources that provide a sound basis for the design or selection of those resources. It acts as the transformation between the customer’s system needs and the design concept implemented by the organization’s engineering resources. The requirements process decomposes a statement of the customer need through a systematic exposition of what that system must do to satisfy that need. This need is the ultimate system requirement which all other requirements and designs flow. There are two fundamental classes of requirements. § Process Performance Requirements § Product Performance Requirements The Process Performance Requirements define how the work processes are used to produce a beneficial outcome to the customer. The Product Performance Requirements define the product specifications and how they are related to the process requirements. As well as the product and process requirements, there are functional and non‒functional requirements. These non‒functional requirements play a significant role in the development of the system. Non‒functional requirements are spread across the entire system or within individual services and cannot be allocated to one specific software artifact (e.g., class, package, component). This makes them more difficult to handle than functional requirements. The specifics of the system’s architecture, such as highly distributed services bring up additional difficulties. The distinction between process and product requirements lays the foundation for the Work Breakdown Structure. The WBS, the Related Integrated Master Plan (IMP) and Integrated Master Schedule (IMS), also focus on this separation. The success of the project or program depends on defining both the product and the processes that support or implement the product. When properly connected, the Requirements Taxonomy, the Work Breakdown Structure, the IMP and the IMS “foot and tied” to the Performance Measurement Baseline (PMB) provides the traceability of the increasing maturity of the deliverables (vertical) and the physical percent complete of the work efforts (horizontal). 28 Chapter0
- 29. Identifying Requirements† †Systems RequirementsPractices, Jeffery O. Grady, McGraw Hill, 1993 29 Chapter0
- 30. Build a time–phasednetwork of activities describing the work to be performed, the budgeted cost for this work, the organizational elements that produce the deliverables from this work, and the performance measures showing this work is proceeding according to plan. Decompose the program Scope into a product based Work Breakdown Structure (WBS), then further into Work Packages describing the production of the deliverables traceable to the requirements, and to the needed capabilities. 3.1 Assign responsibility to Work Packages (the groupings of deliverables) to a named owner accountable for the management of the resource allocations, cost and schedule baseline, and technical delivery. 3.2 Arrange the Work Packages in a logical network with defined deliverables, milestones, internal and external dependencies, with credible schedule, cost, and technical performance margins. 3.3 Develop the Time–Phased Budgeted Cost for Work Scheduled (BCWS) for the labor and material costs in each Work Package and the Project as a whole. Assure proper resource allocations can be met and budget profiles match expectations of the program sponsor 3.4 Assign objective Measures of Performance (MoP) and Measures of Effectiveness (MoE) for each Work Package and summarize these for the Project as a whole. 3.5 Establish a Performance Measurement Baseline (PMB) used to forecast the Work Package and Project ongoing and completion cost and schedule performance metrics. 3.6 Ž Chapter 030
- 31. What Does aCredible Plan and Schedule Look Like? 31 Chapter0
- 32. Establishing the ThreeElements of the Performance Measurement Baseline The Performance Measurement Baseline (PMB) is the primary assessment document for assuring the credibility of a program plan. The PMB is the baseline of the cost, schedule and deliverables for each Work Package in the plan. Constructing the PMB requires knowledge of the business requirements, skill in developing the Work Packages that produce the deliverables for these requirements, and discipline in assembling the cost, schedule and relationships between the Work Packages. It is the discipline that requires the most focus for the planners and program controls staff. Without this discipline, the development of a credible baseline is simply not possible. In the end the planners and program controls staff must “know” in intimate detail each Work Package, its deliverables and resource requirements, the performance measurement criteria and the dependencies that form the critical path through the program schedule. The concept of a Deliverables Based Plan (DBP) is at the core of the Performance Measurement Baseline (PMB). § Deliverables are the units of measure of progress to plan. § Deliverables are what the customer has paid money for. § Deliverables contain the business capabilities, the associated value that fulfill the requirements of the business plan. The Technical Performance Baseline is the requirements flow down and traceability map for each deliverables in the program. § A critical performance measure of the Technical Performance Baseline is the stability of requirements. The expected technical achievement for the actual progress is compared using periodic measurements or tests starts with the Technical Performance Baseline. § An important aspect of the Technical Performance Baseline is to define the units of measures for each deliverable that defines what “done” looks like at each incremental assessment of maturity. The Schedule Performance Baseline is the sequence of Work Packages and Planning Packages that produce the products or services from the program. This baseline contains the schedule margin derived from the Monte Carlo simulation described in DID 81650. The Cost Performance Baseline is the “authorized time‒phased budget‒at‒completion (BAC) used to measure, monitor, and control overall cost performance on the program.” This budget (BCWS) is held in the Control Accounts, the Work Packages and Planning Packages owned by the Control Account Manager. 32 Chapter0
- 33. Establishing the ThreeElements of the Performance Measurement Baseline Cost Baseline Schedule Baseline Technical Baseline Perform Functional Analysis Determine Scope and Approach Develop Technical Logic Develop Technical Baseline Develop WBS Define Activities Estimate Time Durations Sequence Activities Finalize Schedule Identify Apportioned Milestones Determine Resource Requirements Prepare Cost Estimate Resource Load Schedule Finalize Apportioned Milestones Determine Funding Constraints Approve PMB 33 Chapter0
- 34. Execute the plannedwork, assuring all work is 100% complete before proceeding to the next planned work package. No rework, no forward transfer of activities or features. Assure every requirement is traceable to work and all work is traceable to requirements. § Using the Work Package sequencing, release work to be performed as planned. § With the responsibility assignments, identify the accountable delivery manager to guide the development of the products or services for each Work Package. 4.1 § Using Physical Percent Complete or Apportioned Milestones, capture measures of progress to plan for each Work Package. § Report this Physical Percent Complete in a centralized database for each Work Package and the program as a whole. 4.2 § Compare the Physical Percent Complete against the Planned Percent Complete for each period of performance. § Construct cost and schedule performance indices from this information and the Physical Percent complete measures. 4.3 § With Cost and Schedule performance indices, construct a forecast of future performance of cost, schedule, and technical performance compliance. § Take management actions for any Work Packages not performing as planned. 4.4 § Record past performance based on Work Package completion criteria. § Record past future forecast performance estimates in a historical database. § Forecast next future performance estimate against the Performance Measurement Baseline. § Report this next future performance estimate to the program stakeholders. 4.5 Chapter 034
- 35. How Do WeKnow We Are Making Progress to Plan? 35 Chapter0
- 36. Executing the PerformanceMeasurement Baseline With the Performance Measurement Baseline established, its execution becomes critically important. The execution process is called the “program rhythm.” this means the processes are performed in a repeated manner – at least on a monthly basis and many times on a weekly basis. This business rhythm must create actionable information for the program manager on a time scale that actually allows actions to be taken. For Government programs this time scale is at a minimum once a month – the Contract Performance Report – in the form of DI‒MGMT‒81466A. A larger question must be answered though. How long is the Program Manager willing to wait before she discovers she is late? Waiting one month seems risky. Many programs have weekly status reviews which answer the question “where are we in terms of progress to plan?” In the Deliverables Based Planning method, the measure of this “progress to plan” is provided by the tangible physical deliverables from the work efforts. These tangible, physical deliverables must be defined in the work packaged created during the Planning process of Deliverables Based Planning. The measures of physical percent complete can be applied on weekly boundaries in a variety if ways: 1. To actually have weekly deliverables. 2. Have apportioned milestones for each week. 3. Have tasks that are one week long and record 0%/100% complete at the end of each week. In all cases, a measure of physical percent complete is mandatory if the program manager is to receive actionable information. The important process here is to have an agreed on measure of performance that is defined before the work starts. Keep these measures and the work efforts that produce to “fine grained” durations. Focus on answering the question How long are we willing to wait before we find out we’re late? The answer to this question must be short enough to take corrective action so you are in fact not late. 36 Chapter0
- 37. Executing the PerformanceMeasurement Baseline (PMB) 37 Chapter0
- 38. § Identify andclassify risks in a Risk Register. § Manage this Risk Register through a Risk Management Board. § Connect these risks and their handling in the Master Schedule. § Convert risk data into risk decision‒making information. § Use this analysis information as the decision basis for the program manager to work on the “right” risks. § Turn risk information into decisions and actions (both present and future). § Develop actions to address individual risks, prioritize risk actions, and create an integrated risk management plan. § Monitor the status of risks and actions taken to ameliorate risks. § Identify and monitor risks to enable the evaluation of the status of risks themselves and of risk mitigation plans. § Risk communication lies at the center of the model to emphasize both its pervasiveness and its criticality. § Without effective communication, no risk management approach can be viable. Continuous Risk Management starts the underlying principles, concepts, and functions of risk management and provides guidance on how to implement risk management as a continuous practice in programs and the organizations that management programs. 5.1 5.2 5.3 5.4 5.5 Chapter 038
- 39. Analyze Plan Track Control Identify Risks, Issues,and Concerns Evaluate, classify, and prioritize risks Decide what should be done about each risk Monitor risk metrics and verify/validate mitigations Make risk decisions Subproject and partner data/constraints, hazard analysis, FMEA, FTA, etc. Risk data: test data, expert opinion, hazard analysis, FMEA, FTA, lessons learned, technical analysis Resources Replan Mitigation Program/project data (metrics information) Statement of Risk Risk classification, Likelihood Consequence, Timeframe Risk prioritization Research, Watch (tracking requirements) Acceptance Rationale, Mitigation Plans Risk status reports on: Risks Risk Mitigation Plans Close or Accept Risks Invoke contingency plans Continue to track Perform Continuous Risk Management 39 Chapter0
- 40. Chapter 040 DeliverablesBased Planning ® is a registered trademark of Lewis & Fowler. Copyright ® Lewis & Fowler, 2011
- 41. Chapter 041 DeliverablesBased Planning ® is a registered trademark of Lewis & Fowler. Copyright ® Lewis & Fowler, 2011
- 42. 4+1Critical Success Processes Capabilities, Requirements& Deliverables Program Architecture & Dependencies Work Planning and Sequencing Performance Measurement Baseline Programmatic & Technical Risk Management §Balanced Scorecard §Aligned Organization Strategy §Integrated Master Plan (IMP) §Gaps §Overlaps §Interfaces §Integrated Master Schedule (IMS) §Cost And Schedule Baseline §WBS, RAM, Resource Loaded IMS §Risk Registry §Risk Handling Plans §Contingency And Management Reserve §Requirements Traceability §Value Stream Mapping §Work Packages §Planning Packages §Technical Performance Measures (TPM) §Risk Integrated With IMS §Risk Trending §Measures Of Effectiveness (MoE) §Design Structure Matrix (DSM) §Earned Value Management §Measures Of Performance (MoP) §Monte Carlo Simulation 42 Chapter0
- 43. Program Support Services Business Process Reengineering Balanced Scorecard Organizational Change Management DCMA Compliance DCAA Compliance §Michael Hammer trained reengineering processes § Program governance scorecard § Integrated Project Team development § Earned Value Management System Deployment § Cost Accounting Standard (CAS) system deployment § Project Management process improvement § Program performance dashboards § Performance management training § EVM System Description development and application § Integration of the EV Engine with a CAS compliant accounting system § Value stream mapping § Strategic management connected with execution § Measurable Process improvement § EVMS Validation preparation § DCAA and DCMA compliance of EVMS 43 Chapter0
- 44. Benefits of DeliverablesBased Planning® DBP® Capability Benefits to the Customer Program, Planning, and Controls Rapid creation of the risk adjusted Performance Measurement Baseline. Earned Value Management ANSI‒748B compliant processes, tools, and training. Programmatic and Technical Risk Management Credible integrated risk management process guided by DoD, DOE, AACE, and PMI standards. Management Process Improvement Value focused organizational change management. Program Performance Assessment Unbiased External Independent Reviews (EIR). Proposal support – Management Volume IMP/IMS, Basis of Estimate (BoE), and Risk sections. 44 Chapter0
- 45. Deliverables Based Planning®Puts You On the Road to Success … Where are we going? How do we get there? Are there enough resources? What are impediments to progress? How do we measure progress? Chapter 045 Deliverables Based Planning ® is a registered trademark of Lewis & Fowler. Copyright ® Lewis & Fowler, 2011
- 46. Chapter 046 DeliverablesBased Planning ® is a registered trademark of Lewis & Fowler. Copyright ® Lewis & Fowler, 2011
- 47. The10 Organizing Principlesof Deliverables Based Planning® guide the application of the 5 Practice Areas in this handbook. These principles define the reasons for each practice, connect each practice to a beneficial outcome, and integrate the processes into a seamless delivery system. 47 IConnecting Principles With Practice Chapter
- 48. The 10 OrganizingPrinciples of Deliverables Based Planning® Principles are the source of guidance for the Deliverables Based Planning® Practices. A principle is a “general truth, a law on which other are founded or from which others are derived.” [Webster] For the principles of program and project management to be effective they must : § Express a basic concept § Be universally applicable § Be capable of straightforward expression § Be self evident The 10 Principles of Deliverables Based Planning® guide the application of the four process areas. These principles encompass the entire life cycle of a project or program, from inception and the discovery of the business or system capabilities, through requirements elicitation, to the creation of the Performance Measurement Baseline (PMB), to the execution of this baseline. The principles of Deliverables Based Planning® provide several feedback loops to assure that subsequent activities provide measurable information to correct gaps that exist in the previous activities. This iterative and incremental approach to program management assures the periods of assessment for corrective actions are appropriately spaced to minimize risk while maximizing the delivered value to the program. Deliverables Based Planning® can be the basis of conventional as well as Lean program management methods. The illustration the next page are the 10 Principles of Deliverables Based Planning®. Each principle is developed in detail later in this handbook. For now understanding the dependencies between the principles is important. Information produced by the practices derived from the principles must be done in a sequential manner. This is not a “waterfall” approach, but rather an incremental elicitation of the information needed to successfully manage the program. Skipping forward in the sequence of principle, creates systemic risk for both the programmatic and technical elements of the program. 48 ChapterI
- 49. The 10 OrganizingPrinciples of Deliverables Based Planning® Assess the capabilities being provided through the deliverables Fulfill the requirements through effort held in the Work Packages Produce deliverables from Work Packages Planned BCWS Physical % Complete WP’s contain deliverables that fulfill requirements Capabilities topology defines requirements flow down WP flow must describe the increasing maturity of the product or service Producing the deliverables in the planned sequence maintains the value stream to the customer ChapterI 49
- 50. The 5 ProcessAreas of Deliverables Based Planning® Five core process form the basis of Deliverables Based Planning® . These processes represent a sequence of activities that increase the maturity of the programmatic aspects of a project or program. The plans that result from these efforts describe the increasing maturity of the product or services that are the deliverables from the program. In order to develop and execute a Plan, a set of requirements is needed. Before these requirements can be developed, an understanding of the system capabilities should be developed. 1. Identify Needed System Capabilities ‒ Define the set of capabilities (business, operational, or technical) needed to achieve the program objectives or a particular end state for a specific scenario using the Concept of Operations (ConOps). CONOPs is a verbal or graphic statement, in broad outline, of an assumption or intent in regard to an operation or series of operations, mission, or system. 2. Establish Requirements Baseline – defines the technical, organizational, and operational requirements that must be in place for the system capabilities to be fulfilled. Define these requirements in terms isolated from the implementation details. Only then, bind these requirements with the technical alternatives. 3. Establish Performance Measurement Baseline – build a time‒phased network of scheduled activities describing the work to be performed, the budgeted cost for this work, and the organizational elements that produce the deliverables from this work. Define the technical performance measures showing how this work proceeds according to the technical and programmatic plan. 4. Execute the Performance Measurement Baseline – execute the Performance Measurement Baseline Work Packages, while assuring all performance assessments represent measures of Physical Percent Complete. 5. Continuous Risk Management – identify, plan, and budget risk mitigation or retirement activities at assure impediments to progress are handled. These five process areas must all be present in some form, for program success. To skip any process area, or performance the process area out of order Capabilities, Requirements, Baseline, and Execution, with Continuous Risk Management lays the foundation for a Troubled Project. Each process area builds on the previous area to increase the fidelity of the actionable information needed by the decision makers. This method is independent of any specific development of engineering process – iterative, incremental, and linear processes are all equally effective ChapterI 50 Deliverables Based Planning ® is a registered trademark of Lewis & Fowler. Copyright ® Lewis & Fowler, 2011
- 51. The 5 ProcessAreas of Deliverables Based Planning®10OrganizingPrinciplesofDeliverablesBasedPlanning® Chapter I 5 Identify Needed Capabilities Establish a Performance Measurement Baseline Execute the Performance Measurement Baseline Capabilities Based Plan Operational Needs Earned Value Performance 0% /100% Technical Performance Measures Business or Mission Value Stream Technical Requirements Identify Requirements Baseline Technical Performance Measures PMB Changes to Needed Capabilities Changes to Requirements Baseline Changes to Performance Baseline Œ Ž Chapter I51
- 52. Deliverables Based Planning®Processes Deliverables Based Planning® is a comprehensive approach to managing cost, schedule, and technical performance of programs and projects by assessing the interaction between programmatic and technical processes. The method starts by capturing the technical and operational needs of the proposed system. These are stated in a Concept of Operations describing how the system operates, how it fulfills the stated mission, what major components comprise the system, and how they interact with each other. From the capabilities description of the Concept of Operation, technical and operational requirements are elicited. These requirements define the development progress of the deliverables captured in the Performance Measurement Baseline (PMB). This PMB is constructed from a collection of Work Packages, arranged in a logical network describing the increasing maturity of the products or services needed to deliver the stated capabilities. Measures of physical percent complete are used for each Work Package and the deliverables they produce. Deliverables Based Planning® is a Systems Engineering approach to program and project management [INCOSE], [Stevens]. This method incorporates all three aspects of a program performance measurement process – Cost, Schedule, and Technical Performance Measures (TPM). The inclusion of the TPMs distinguishes the Lewis & Fowler Deliverables Based Planning® from more conventional approaches to Program, Planning, and Controls. In conventional approaches, the cost and schedule baseline and the variances generate the values for Earned Value. In the Deliverables Based Planning® method, measures of Physical Percent Complete are derived from pre–defined targets of Technical Performance. The Earned Value variables are augmented with adjustments from the Technical Performance compliance for each deliverable to produce a true assessment of progress. Technical Performance Measures integrate technical achievement with earned value using risk assessments that provides a robust program management tool to identify early technical and programmatic disruptions to a program. [Pisano] TPMs: Provide an integrated view across all programmatic and technical elements. Support distributed empowerment implicit in the IPT approach, through interface definitions. Logically organizes data resulting from systems engineering, risk management, and earned value processes. Provide a "real time" indication of contract performance and future cost and schedule risk. Support the development of systems thinking within an integrated program model focused on the interface definitions. ChapterI 52 Deliverables Based Planning ® is a registered trademark of Lewis & Fowler. Copyright ® Lewis & Fowler, 2011
- 53. Deliverables Based Planning®Processes ChapterI 53 Deliverables Based Planning ® is a registered trademark of Lewis & Fowler. Copyright ® Lewis & Fowler, 2011
- 54. 1. Identify NeededSystems Capabilities – Define the Measures of Effectiveness (MoE) Deliverables Based Planning® DEFINE OPERATIONAL CONCEPTS THROUGH SCENARIOS OR USE CASES Partition system capabilities into classes of service within operational scenarios Connect capabilities to system requirements using sysML Define Measures of Effectiveness (MoE) for these capabilities in units meaningful to the customer Define in the master schedule the achievement of measure of Technical Performance DEFINE CAPABILITIES NEEDED TO IMPLEMENT THE OPERATIONAL CONCEPTS Define scenarios for each system capability Connect these scenarios to the Value Stream map Assess value flow through the map for each needed capability Identify capability mismatches and make corrections to improve overall value flow ASSESS NEEDS, COST, AND RISK SIMULTANEOUSLY Assign costs to each system element using a value process model Assure risk, probabilistic cost and benefit performance attributes are defined Use cost, schedule, and technical performance probabilistic models to forecast potential risks to program performance DEFINE EXPLICIT, BALANCED, AND FEASIBLE ALTERNATIVES Make tradeoffs that connect cost, schedule, and technical performance in a single “trade space” model Measures of Effectiveness and Measures of Performance are the raw materials for these tradeoffs 2. Establish Requirements Baseline – DEFINE MEASURES OF PERFORMANCE (MOP) PERFORM FACT FINDING Produce an overall statement of the problem in the operational context Develop the overall operational and technical; objectives of the target system through Measures of Performance (MoP) for the requirements Define the boundaries and interfaces of the target system GATHER AND CLASSIFY THE REQUIREMENTS Gather required operational capabilities, functional, nonfunctional, and environment requirements and design constraints Build a Top Down Capabilities and Functional decomposition of the requirements in a flow down tree using a requirements tool EVALUATE AND RATIONALIZE THE REQUIREMENTS Answer the question “why do we need this?” in terms of operational benefits Build a cost / benefit model using probabilistic assessments of all variables and dependencies For technical requirements, perform a risk assessment to the cost and schedule PRIORITIZE THE REQUIREMENTS Determine the criticality for the functions for the system’s mission Determine tradeoff relations for all requirements to be used when option decision are made For technical items, prioritize the cost and dependencies INTEGRATE AND VALIDATE THE REQUIREMENTS Address completeness of requirements by removing all TBD items Validate the requirements agree and are traceable to capabilities, goals, and the mission Resolve any requirement inconsistencies and conflicts Chapter IChapter I54
- 55. 3. ESTABLISH PERFORMANCEMEASUREMENT BASELINE – DEFINE TECHNICAL PERFORMANCE MEASURES (TPM) DELIVERABLES BASED PLANNING® DECOMPOSE REQUIREMENTS INTO WORK PACKAGES AND PLANNING PACKAGES Decompose the program scope into a product based Work Breakdown Structure (WBS) Decompose the WBS into Work Packages describing the production of all deliverables and processes traceable to the requirements ASSIGN ACCOUNTABILITY FOR THE DELIVERABLES FROM EACH WORK PACKAGE Assign accountability for Work Packages to a named owner for the management of resource allocation, cost baseline, and technical delivery ARRANGE WORK PACKAGES IN A LOGICAL ORDER Arrange Work Packages in a network with defined deliverables, milestones, internal and external dependencies, appropriate schedule and cost margin DEVELOP THE BUDGETED COST FOR WORK SCHEDULED (BCWS) FOR EACH WORK PACKAGE AND PLANNING PACKAGE Develop a time‒phased Budgeted Cost for Work Scheduled (BCWS) for labor and material costs in each Work Package Develop a time‒phased Budgeted Cost for Work Scheduled (BCWS) for the program as a whole Assure proper resource allocations can be met and budget profiles match expectations of the program sponsor ASSIGN WORK PACKAGE MEASURES OF PERFORMANCE (MOP), KEY PERFORMANCE PARAMETERS (KPP), AND TECHNICAL PERFORMANCE MEASURES (TPM) Assign an objective Measure of Performance (MoP) for each critical Work Package deliverable Trace critical deliverables to the Measure of Effectiveness (MoE) defined in the Capabilities baseline Summarize these Measures of Performance (MoP) and Measures of Effectiveness (MoE) for the program as a whole Assign measures of Physical Percent Complete for each Work Package Assign measures of Physical Percent Complete for the program as a whole SET THE PERFORMANCE MEASUREMENT BASELINE (PMB) Establish a Performance Measurement Baseline (PMB) used to forecast Work Package and Project ongoing and completion cost and schedule metrics 4. Execute the Performance Measurement Baseline (PMB) – Maintain Cost, Schedule, and Technical Performance PERFORM AUTHORIZED WORK IN THE PLANNED SEQUENCE Using the Work Package sequencing, release work to be performed as planned With the RACI based RAM, the Accountable delivery manager guides the development of the products or service for each Work Package ACCUMULATE AND REPORT WORK PACKAGE PHYSICAL PERFORMANCE Using Physical Percent complete or Apportioned Milestones, capture the measures of “progress to plan” for each Work Package Report the Physical Percent Complete in a centralized system for each Work Package and he program as a whole ANALYZE WORK PACKAGE PERFORMANCE Compare the Actual Percent Complete against the Planned Percent Complete for each period of performance Construct cost and schedule performance indices from this information and the Physical Percent Complete measures TAKE CORRECTIVE MANAGEMENT ACTION FOR ANY VARIANCE IN WORK PACKAGE PERFORMANCE With the cost and schedule performance indices, construct a forecast of future performance of cost, schedule, and technical performance compliance Take management actions for any Work Packages not performing as planned MAINTAIN PERFORMANCE MEASUREMENT BASELINE’S INTEGRITY Record past performance based on Work Package completion criteria Record previous future performance estimates in a historical database Forecast future performance against the Performance Measurement Baseline Report the future performance estimate to the program stakeholders Chapter IChapter I55
- 56. Program Events Define theavailability of a Capability at a point in time. Accomplishments Represent requirements that enable Capabilities. Criteria Represent Work Packages that deliver the Requirements. Work Package Work Package Work Package Work Package Work Package Work Package Work Package Work package § Deliverables Based Planning® describes of the increasing maturing of a product or service through Events or Milestones, Accomplishments, Criteria, and Work Packages. § Each Event or Milestone represents the availability of one or more capabilities. § The presence of these capabilities is measured by the Accomplishments and their Criteria. § Accomplishments are the pre–conditions for the maturity assessment of the product or service at each Event or Milestone. § This hierarchy decomposes the System Capabilities into Requirements, Work Packages, and the activities the produce the deliverables. This hierarchy also describes increasing program maturity resulting from the activities contained in the Work Packages. § Performance of the work activities, Work Packages, Criteria, Accomplishments, and Events or Milestones is measured in units of “physical percent complete” by connecting Earned Value with Technical Performance Measures. The structure of a Deliverables Based Plan Chapter IChapter I56
- 57. 10 organizing principlesguide the deployment of Deliverables Based Planning® and the application of the 5 Process Areas. These 10 principles form the basis of the “theory” of Deliverables Based Planning®, while the Process Areas are the practice of the principles. 57 II10 Organizing Principles Chapter
- 58. The 10 OrganizingPrinciples of Deliverables Based Planning® Assess the capabilities being provided through the deliverables Fulfill the requirements through effort held in the Work Packages Produce deliverables from Work Packages Planned BCWS Physical % Complete WP’s produce deliverables that fulfill requirements Capabilities topology defines requirements flow down WP flow must describe the increasing maturity of the product or service Producing the deliverables in the planned sequence maintains the value stream to the customer ChapterII 58 Deliverables Based Planning ® is a registered trademark of Lewis & Fowler. Copyright ® Lewis & Fowler, 2011
- 59. The 10 OrganizingPrinciples of Deliverables Based Planning® Organizing Principles in Order of Increasing Maturity 1 Capabilities drive system requirements. All requirements must be traceable to a capability. Requirements identify technical and process deliverables. All deliverables must be traceable to a requirement. Work Packages describe the production of deliverables. Integrated Master Schedule (IMS) arrange the Deliverables, Accomplishments, Criteria, and Work Packages into a logical – risk adjusted – activity network. Work Package progress is measured as Physical Percent Complete against the planned progress at time of the performance assessment. Work Authorization assures the sequence of Work Packages produce progress at the planned rate for the planned cost, with the planned product maturity at each assessment point in the IMS. Earned Value describes the current performance and provides information about future performance. Conformance with Technical Performance Measures adjusts Earned Value for rework, quality, or delayed features, using Units of Measure meaningful to the decision makers. Performance feedback from each WP and program level Earned Value adjusts the WP sequence and resource allocation to reestablish an on–time, on–budget schedule. Future performance is based on the To Complete Performance Index (TCPI), Independent Estimate At Complete (IEAC), and the adjusted work sequence. ChapterII 59
- 60. Capabilities Drive SystemRequirements The principles for defining a capability address the flexibility needed to ensure system responsiveness and sustainability in a context of constant change, while delivering tangible benefits to the buyer These include: Agility, Tailorability, and measures of System Element coupling and cohesion. Governance principles provide guidance to institutionalize a process, including its continued assessment and evolution over time in support of the tangible system benefits. These include: Enforced Rules & Responsibilities, Workflow Guidance, Continuous Improvement, Transformation enablers. The core concept in Capabilities Based development is the focus on the delivery of value. The concept of “Value Focused Thinking” starts with two methods of decision making: the 1st focuses on competitive analysis between the various alternatives, and the 2nd focuses on attaining organization values as the fundamental objective of any decision making process. [Pagatto07] During the development of the Concept of Operations for each capability, assumptions must be made in the absence of specific technical and operational information. To avoid unwelcome surprises, some form of assumptions based planning is needed. 1) Make operational plans, 2) Describe plausible events, 3) Identify the “signposts” for potential problems, 4) Discover shaping actions that shore up uncertain assumptions, and 5) take hedging actions to better prepare for the possibility that an assumption will fail [Dewer02] Capabilities planning consists of several core processes to describe the system capabilities in the absence of the specific technical or operational requirements. Discover what is not known by reaching a sufficient basic knowledge level setting the problem space. Identify problems by understanding the current process, along with people and technology involved. Establish boundaries and solution elements. These are grouped into five categories: 1. Orientation principles align the process on a sound theoretical basis issued from generally accepted practices in the areas of engineering, modeling, and acquisition. These principles include: Capability Thinking, Architecture Models, Evolutionary Development, and Deliverables Centric planning. 2. Communication principles enforce the standardization of vocabulary and structure of information to be exchanged within or outside the process. These include: Standardized Formats and Common Terminology to describes the system capabilities. 3. Collaboration principles enable active and timely participation of all stakeholders involved in the engineering of a capability. These include: Collaborative Engineering and Information Sharing between the contributors of the system capability elements. ChapterII 60
- 61. Capabilities Drive SystemRequirements ¨ Establish the system capabilities by describing the fundamental ideas about the system through the operational behavior. ¨ Do this before the technical and process requirements are elicited. ¨ Use these Operational Concepts (OC) to describe how the system achieves the beneficial outcomes before any commitments are made to the implementation. ¨ Use a Capabilities Based Assessment (CBA) to define gaps in the current system and the approaches to providing capabilities within a specified functional or operational concept. ¨ Construct three capability assessments: Functional Area Analysis, Functional Needs Analysis, and Functional Solutions Analysis. ¤ Functional Area Analysis (FAA) is a capabilities based task analysis that provides the framework for assessing required capabilities for the success of the system. ¤ Functional Needs Analysis (FNA)assesses the ability of the current system to accomplish the needed tasks identified in the FAA, in the manner prescribed by the concept under the operating conditions and to prescribed standards. ¤ Functional Solutions Analysis (FSA) is an operationally based assessment of the potential strategies, organizations, training, leadership and education, personnel, facilities, and materials (technologies) for solving open of more of the capability needs. ChapterII 61
- 62. Requirements Identify TechnicalAnd Process Deliverables Inadequate requirements engineering is a common problem in the development of any complex system. There are many issues associated with requirements engineering, including failure to define the system scope, failure to foster understanding among the different communities affected by the development of a given system, and failure to deal with the volatile nature of requirements. These problems lead to poor requirements and the cancellation of development, or else the development of a system that is later judged unsatisfactory or unacceptable, has high maintenance costs, or undergoes frequent changes. [Young04], [Grady06] By improving requirements elicitation, the requirements engineering process can be improved, resulting in enhanced system requirements and potentially a much better system. Requirements engineering is decomposed into the activities of requirements elicitation, specification, and validation. Most of the requirements techniques and tools today focus on specification, i.e., the representation of the requirements. The Deliverables Based Planning approach concentrates on elicitation concerns, those problems with requirements engineering that are not adequately addressed by specification techniques. The elicitation methodology to handle these concerns. Is provided by [Cristel92]. Whatever the actual process used, the following activities are fundamental to all Requirement Engineering processes:[Sommerville05] § Elicitation – Identify sources of information about the system and discover the requirements from these. § Analysis – Understand the requirements, their overlaps, and their conflicts. § Validation – Go back to the system stakeholders and check if the requirements are what they really need. § Negotiation – Inevitably, stakeholders’ views will differ, and proposed requirements might conflict. Try to reconcile conflicting views and generate a consistent set of requirements. § Documentation – Write down the requirements in a way that stakeholders and software developers can understand. § Management – Control the requirements changes that will inevitably arise. ChapterII 62
- 63. Requirements Identify TechnicalAnd Process Deliverables ¨ Derive the system requirements for each system capability. ¨ Assure a requirement exists for each system capability needed to fulfill the mission of the system. ¨ Develop the traceability from capabilities to requirements to produce a “minimalist” system, with each requirement being present only because of a needed system or mission capability. ¨ Test requirements by answering the question “why do we need this feature, function, service, or capability?” ¨ Create Technical Performance Measures: [IEEE 1220] ¤ High priority requirements that have an impact on: mission accomplishment, customer satisfaction, cost, system usefulness. ¤ High risk requirements or those where the desired performance is not currently being met: the system uses new technology, new constraints have been added, the performance goal has been increased, but the performance is expected to improve with time. ¤ Requirements where performance can be controlled. ¤ Requirements where the program manager is able to rebalance cost, schedule and performance. ChapterII 63
- 64. Work Packages DescribeProduction Of Deliverables Staying focused on decomposing the system capabilities into clearly defined streams of functionality is a critical success factor. This effort decouples the technical functionality from the system capabilities – increasing cohesion and reducing coupling between each stream. This decomposition is almost never optimal the first time around. The false sense of urgency to decompose the system requirements into a Work Breakdown Structure will cause extra work later on. Investing in a carefully developed WBS will pay back later in the program by isolating the work processes into supporting value streams. There is no set of instructions on how to do this. But starting the WBS in a graphical form, putting that diagram on the wall and asking coupling and cohesion questions about the terminal nodes in the WBS is one way to “test” to goodness of the WBS. The construction of the Work Breakdown Structure (WBS) starts with the decomposition of the requirements into collections of deliverables. Focusing on the deliverables is critical. The Work Packages that result from this decomposition are the vehicles for producing the deliverables. When these deliverables exist they provide the capabilities requested by the system to perform it function. All resources – internal and external, their dependencies, and any other items needed to produce the deliverables – are defined in Work Packages. The Work Package Manager is accountable for managing all these resources. If resources are not under the control of the Work Package Manager, the risk to the success of the deliverables is greatly increased, because … Accountability is no longer traceable to a single person – violating the principles of the Responsibility Assignment Matrix. Performance reporting for Physical Percent Complete is no longer represented by tangible items within Wok Package. Each Work Package produces one deliverable. This deliverable may have a Technical Performance Measure attached – a Measure of Performance (MoP) or Measure of Effectiveness (MoE). These Technical Performance Measures connect the dots between Cost, Schedule, and Technical maturity of the deliverable. In the absence of Technical Performance Measures, the Performance Measurement Baseline lacks the ability to connect physical percent complete with the increasing maturity of the product or service. ChapterII 64
- 65. Work Packages DescribeProduction Of Deliverables ¨ Use the Work Packages (WP) executable tasks to produce deliverables at the conclusion of each WP duration. ¨ Avoid connections between WPs that are not Finish‒to‒Start at the WP boundaries, this “hides” dependencies. ¨ Work contained in the WP produces a single or small number of deliverables. ¨ Use performance measures at the Work Package level to assess the progress of the increasing maturity of the deliverables produced by each WP. ¨ Do not measure effort, the passage of time, or consumption of resources as assessments of progress. ¨ Use apportioned milestones, 0%/100%, 50%/50%, and other forms of incremental physical progress as a credible measures of percent complete at the WP level. ¨ When performance measures of actual delivered value are used, the physical progress of the program becomes a credible measure success. ¨ Measuring Earned Value for each task within the WP may be of little value for the program without a measure of Technical Performance (Measures of Effectiveness and Measures of Performance). ChapterII 65
- 66. Master Schedule SequencesDeliverables, and Work Packages in a Network Arranging the Work Packages in a logical network is an iterative process. It should be obvious which major deliverables come first, second and later. Building an initial network, plotting that network in the Big Visible Chart, hanging that chart on the wall and standing in front of it with all the Work Package Managers is part of developing a credible PLAN for the program. The PLAN is the strategy for delivering the business capabilities the customer asked for. With the Big Visible Chart, this strategy is made visible – or at least more visible than a list of Work Packages. The strategy for delivering the program should be mapped out in some wall walk manner to make the connections obvious. This hands on approach is much better than burying the relationships in a program plan or spread sheet. Making the first cut is a hands on process. The arrangement of Work Packages should start with some simple rules: 1. All relationships are Finish to Start. This initial arrangement provides visibility into the dependencies that will drive schedule compression. Non FS relationships create opportunities to use partially complete work in future efforts, resulting in “rework,” the predecessor efforts are complete. 2. There should be no “lead” or “lag” arrangements. These create hidden dependencies and hidden schedule compression. 3. The only constraints on the network should be a “Must Start On” (MSO) for the start date and “As Soon As Possible” (ASAP) for all other activities. Any other constraints create hidden dependencies. This appears harsh at first, but is the basis of an “ideal” schedule. Other constraints may be added later, but only for necessary reasons, that are described in the IMS Narrative. 4. The flow of Work Packages should create a description of the increasing maturity of the products or services of the project – not just the consumption of resources and production of deliverables. This Maturity description should be meaningful to the customer in terms of business capabilities. At this point in time we will be able to perform the following business capabilities. 5. Speaking in these terms, the customer gains insight into the actual progress of the program. Speaking in consumption of resources, production of code, passage of milestones is not that meaningful to the customer 6. Point estimates of cost and schedule are meaningless without the range of possibilities, the level of certainty in achieving each value, and how these estimates impact the credibility that the program will complete on time, on schedule, and with the planned technical performance. ChapterII 66
- 67. Master Schedule SequencesDeliverables, and Work Packages in a Network ¨ Arrange Work Packages in an un–constrained Activity Network. ¨ This network is a description of the flow of increasing maturity of the product or service resulting from the completion of each Work Package. ¨ This network answers the 6 critical questions needed for success: ¤ Who is responsible for performing this the work? ¤ What are the constituent components of the work and what is the evidence that they are complete? ¤ When is this the work required to be completed? ¤ Where will this work be performed? ¤ Why does this work need to be done? ¤ How does this support the acceptance of the product or service by the customer? ¨ Postpone the detailed scheduling until there is a credible WP process flow increases the visibility into dependencies as well as programmatic and technical risk and its mitigation. ¨ Define the Exit criteria for each WP the describes what “done” looks like and what technical maturity is needed to proceed to the next WP. ¨ The schedule of work within the WP can then be developed by the “owners” of the work effort – the Work Package Manager (Control Account Manager). ¨ Cost, Schedule, and Technical Performance values must be described in statistical terms, within a range of possible values and the probability of their occurrence. ChapterII 67
- 68. Work Package Progressis Measured as Physical % Complete Against Plan Measuring progress to plan can ONLY be done with Physical Percent Complete (PPC). Any other measure of progress can not be connected to the delivery of business value to the customer. This is the basis of Earned Value and it is also the basis of Agile Software Development methodologies. Deliver working code at all times. Using the 0% /100% assignment or the Apportioned Milestone assignment, the Physical Percent Complete is multiplied by the Budgeted Cost of Work Scheduled (Planned Value, PV) for the entire Work Package to produce the Budgeted Cost of Work Performed (Earned Value, EV). PMI has used BCWP(EV) = PPC X Budget at Completion, where BAC = Sum(all Work Packages BCWS) This is the ONLY way BCWP(EV) can be produced. Any other way creates an invalid baseline measure of progress to plan. With the Work Packages defined, the BCWS(PV) spreads for each Work Packages established and the Work Packages assembled into a credible network, a Performance Measurement Baseline can be established. Step by Step check list for setting the baseline: 1. All BCWS spreads have been balanced against available resources for that Work Package and the program as a whole. This is a long, difficult and very unpleasant process. But letting a scheduling tool do this work has several undesirable outcomes: § The longest date usually results, since the tool spreads the resources according to their availability. § The planners of the program will not actually understand the resource spreads assigned by the machine § The day to day decisions of assigning work will now be removed from those who can make the decisions § The visibility into the logical process of assigning work is lost and the planners are simple observers 2. All Work Packages have apportioned milestones, 0/100, 50/50, or 25/75 assignments of Earned Value (BCWP)(EV) 3. All data fields in the schedule have been assigned and checked ChapterII 68
- 69. Work Package Progressis Measured as Physical % Complete Against Plan ¨ Measure progress as Physical Percent Complete to provide a credible assessment of the increasing maturity of the delivered product or service. ¨ Use each work activity in the Work Package to provide some form of progress toward producing the deliverable. ¨ Use this progress as an incremental measure of the overall progress of the Work Package. ¨ Predefine how each work effort contributes to the overall progress of the Work Package. ¨ Have the Work Package owner describe the incremental Physical Percent Complete is terms of tangible evidence of progress to plan. ¨ Assure what “done” looks like is defined in terms of the Physical Percent Complete of the Work Package, Measures of Effectiveness, and Measures of Performance. ¨ Capture this definition in the Work Package documentation. ¨ Ask the question: ¤ How Long Are You Willing to Wait Before You Find Out You Are Late? ¨ Measure physical progress to plan soon enough before that period of performance arrives, so management corrections can be made to stay on cost, schedule and technical performance. ChapterII 69
- 70. Work Authorization AssuresWork Packages Produce Planned Progress The work authorization system is used by the program manager and his or her designees in order to approve all work throughout the course of the current program management venture. The work authorization system will typically be in the form of a list of formally adopted and well‒ documented procedures. Work authorization procedures specifically detail who may authorize work to be completed and how those authorizations may be obtained. These procedures will include which documents must be completed prior to work being initialized, and whether there are any other prerequisites to work being performed at any particular level during the program. To better assist the efficiency of program management in larger programs, work authorization systems sometimes detail the timeline of the program. For instance, the work authorization system might include at which points in time certain portions of the program should be completed, in which order those tasks are to be completed, and by whom. It is important for program management to be aware of how they convey the work authorization to their staff. To ensure that spoken words are not misinterpreted, written directions for the Work Packages provide explicit guidance. The Work Package can be anything which might need to be accomplished to produce a deliverable. By providing a written work authorization, those in program management can be assured that their wish to have the job done by the right people, at the correct time, and in the right order. The Project Manager needs to be cautious to write out the exact steps on the work authorization. This prevents misunderstandings and mistakes along the line. To have the work done correctly the first time, the manager must have good communication skills with his workers, both in the writing of the authorization and in answering any questions which might arise. Proper direction given to employees in the work permitting directive will ensure that the task is completed in the expected manner. ChapterII 70
- 71. Work Authorization AssuresWork Packages Produce Planned Progress ¨ Executing the Work Packages (WP) in the agreed sequence assures the program proceeds as planned. ¨ This approach starts with a Work Authorization and control processes and continually monitors, Late Starts, Late Finishes, Schedule Margin erosion, and Technical Performance Measure compliance. ¨ Work Authorization does not inhibit the performance of work, but assures that work is performed in the planned sequence with the planned programmatic risk reduction, to continuously increase the maturity of the product or service. ¨ “Out of sequence work” creates programmatic and technical risks: ¤ It disrupts the Earned Value calculations – work without a budget in the planned period is an overrun. Planned budget without actual work being performed is recorded as an under run. In both cases EV is reported improperly. ¤ The strategy developed for sequencing work to increase the maturity of the product or service is disrupted. ChapterII 71
- 72. Earned Value DescribesCurrent Performance From the ANSI‒748 Guideline: § The Earned Value Management System (EVMS) incorporates business best practices to provide strong benefits for program or enterprise planning and control. § The processes include integration of the program scope, schedule, and cost objectives, establishment of a baseline plan for accomplishment of program objectives and the use of earned value techniques for performance measurement during the execution of the program. § The EVMS provides a sound basis for problem identification, corrective actions, and management replanning as may be required. § Any Earned Value Management System must: § Plan all work scope for the program through completion. § Integrate program work scope, schedule, and cost objectives into a baseline plan against which accomplishments can be measured. § Objectively assess accomplishments at the work performance level. § Analyze significant variances from the plan and forecast impacts. § Provide data to higher levels for management decision making and implementation of management actions. For the benefits of Earned Value to be fully realized, thorough planning, combined with the establishment and maintenance of a baseline for performance measurement is needed. The combination of advanced planning, baseline maintenance, and earned value yields earlier and better visibility into program performance than is provided by non‒integrated methods of planning and control. The key to success is to establish the performance baseline at the Work Package level. The Work Package is the point at which work is planned, progress is measured, and earned value computed. ChapterII 72
- 73. Earned Value DescribesCurrent Performance ¨ Recognize Earned Value is cost based. Cost Variance and Schedule Variance have the same units of measure – Dollars. ¨ Use the To Complete Performance Index (TCPI) and the Independent Estimate At Completion (IEAC) as measures of progress derived from Earned Value. But they are also measured in dollars. ¨ Using the TCPI and IEAC, the program manager has visibility into the work performance needed to stay on schedule and the forecast cost of this effort. ¨ Recognize the credibility of these indices depends on the credibility of the underlying earned value numbers. This is the primary motivation for maintaining good data on the program. Otherwise the Earned Value numbers are not only wrong, they provide no real value for guiding management in decisions that impact the future performance of the program. ¨ Consider using Earned Schedule [ES] to complement Earned Value [PMI EV]. Earned Schedule is a method of deriving schedule performance from Earned Value data [Lipke], [Henderson04], [Vanhoucke] ChapterII 73
- 74. Conformance With TechnicalPerformance Measures Adjusts EV Performance Values Technical Performance Measures (TPMs) are traditionally defined and evaluated to assess how well a system is achieving its performance requirements. Typically, dozens of TPMs are defined for a system. Although they generate useful information and data about a system’s performance, little is available in the program management community on how to integrate these measures into a meaningful measure of the system’s overall performance risk. TPMs may be combined to measure and monitor the overall performance risk of a system. The approach consists of integrating individual technical performance measures in a way that produces an overall risk index. The Program Manager must be cognizant of three basic program elements (baselines): § Cost § Schedule § Technical Performance The first two are tracked through cost and schedule control systems (earned value). The last is tracked through the technical performance measurement (TPM) system. TPM is the program manager’s early warning system, when correlated to cost and schedule reports, to provide the complete status of the program. The TPM method includes selecting Technical Performance Parameters; assigning weights; linking to CWBS; planning progress over time; getting data; evaluating variances; and taking corrective action as needed. Variances indicate level of risk and detect new risks before their effects on cost/schedule are irrevocable. The TPM approach involves: § Assessing technical characteristics of the system and identify problems through tests/analyses. § Surfacing inadequacies in time and dollars. § Complements cost/schedule performance measurement § Providing a basis for cost/schedule revisions. § Facilitating the verification of results achieved against technical requirements and what remaining technical work can be accomplished within established budgets. ChapterII 74
- 75. Conformance With TechnicalPerformance Measures Adjusts EV Performance Values ¨ Adjust the “Earned Value” forecast of future performance by the compliance with Technical Performance Measures (TPM). ¨ Correlate Technical Performance Measures with cost and schedule to provide the complete status of the program. ¨ Use Technical Performance Measures to add “technical achievement” to Earned Value’s cost and schedule metrics. ¨ Assess the program’s progress in terms of technical compliance, potential rework, postponed functionality (to later Work Packages or rolling waves) and other dilutions of the physical progress of the program. ¨ Use Technical Performance Parameters (TPPs) to indicate key areas for risk reduction and program success. ¨ Technical Performance Measures (TPMs) are a time–phased progress plan for achievement of critical TPPs. ChapterII 75
- 76. Performance Feedback UsedTo Adjust WP Sequence and Resource Allocation Earned Value Management (EVM) is a program management tool integrates Cost and Schedule parameters as an early warning system for future performance of the program. But the EVMS standard states that EV is a measurement of quantity (BCWP), not quality, of the work accomplished. As far back as 1997, the discussion was integrating Cost, Schedule, and Technical Performance. Robust systems engineering and software engineering processes should provide technical performance measures (TPM) and exit criteria for assessing technical maturity that are quantitatively linked to Earned Value. Adjusting the To Complete Performance Index (TCPI) and the Independent Estimate At Complete (IEAC) for less than planned technical performance measurements – quality, missing scope, delayed scope, or combinations of these and other less than planned outcomes. These TPMs are defined and evaluated to assess how well a system is achieving its performance requirements. Technical performance measurement uses actual or predicted values from engineering measurements, tests, experiments or prototypes. The introduction the Earned Value Management Intent Guide speaks to this but better guidance is needed [Solomon]. To provide the needed feedback for adjusting the TCPI and IEAC values , the following activities need to be performed: § Include systems engineering activities in the schedule and the Performance Measurement Baseline (PMB). § Establish thresholds or parameters for TPM in the program plan. § Specify objective measures of progress as base measures for EVM for: Development maturity to date, product’s ability to satisfy requirements, Product metrics, including TPM achievement‒to‒date. § Review program’s plans, activities, work products and performance measurement baseline for consistency with the requirements and the changes made to the requirements baseline. § Incorporate risk mitigation plans in the program plan, including changes to the PMB. § Include quantified risk assessments in the EAC depending on the probability of risk occurrence and the impact on cost objectives. With this information, TCPI and IEAC can be adjusted to reflect the Physical Percent Complete of the Work Packages, not just the Cost and Schedule performance measures. ChapterII 76
- 77. Performance Feedback UsedTo Adjust WP Sequence and Resource Allocation ¨ Adjust the Work Package sequence using feedback from the performance measures to maintain compliance with the Measures of Effectiveness (MoE), Measures of Performance (MoP), and Technical Performance Measures (TPM). ¨ TPM methodology includes: ¤ Selecting TPPs; assigning weights; linking to CWBS; planning progress over time; getting data; evaluating variances; and taking corrective action as needed. ¤ Variances can indicate level of risk and detect new risks before their effects on cost/schedule are irrevocable. ¨ Assess of the technical performance characteristics of the system to identify problems by: ¤ Having assessments coincide with cost reporting and completion of significant design tasks. ¤ Surfacing inadequacies in time and dollars. ¤ Complementing the standard cost/schedule performance measurement. ¤ Providing the basis for cost/schedule revisions. ¤ Facilitating the verification of results achieved against technical requirements and that remaining technical work can be accomplished within established budgets. ChapterII 77
- 78. Forecast Of FuturePerformance Based On TCPI, IEAC, and Work Sequence Employing Earned Value Management can present a program with data not available with any other management tool. And while each metric can be useful, there are two metrics are particularly useful in the management of any project, or program, or a portfolio of projects. The Cost Performance Index (CPI) is a reflection of program cost efficiency. The CPI relates the physical work accomplished, expressed in its budgeted value, against the actual costs incurred to accomplish the performed work. Budgets can be set with various monetary values, hours, deliverables, or anything else that can be measured. The question: Is the program staying on target, under running, or perhaps overrunning costs? Perfect cost performance would be defined as achieving a CPI of 1.0: For every dollar spent, we would get an EV equal to one dollar. Sometimes we do better, sometimes worse. This is a particularly critical metric to track because performance at less than 1.0 is a reflection of excessive costs spent against budget. Initial overruns are typically non‒recoverable. Think about it: In order to recover an overrun, future work must be underrun. Rarely does this happen. The same conditions which may have caused the overrun in the first place are likely to occur again and again. The CPI is an indicator of past cost performance, the TCPI has its focus on future performance. The question: What will it take to meet the goals set by management? The TCPI works in conjunction with the CPI. TCPI = Work Remaining / Funds Remaining The CPI can be thought of as sunk‒costs; whatever the results, they cannot be altered. The TCPI is the efficiency needed to regain the lost performance from the past. ChapterII 78
- 79. Forecast Of FuturePerformance Based On TCPI, IEAC, and Work Sequence ¨ Develop a new forecast of cost and schedule with the new sequence of Work Packages. ¨ Base this forecast on the To Complete Performance Index (TCPI) and the Independent Estimate At Complete (IEAC) [Henderson08]. ¨ There are five IEAC indices. ¤ IEAC1 = BAC / CPI ¤ IEAC2 = ACWP + (BAC – BCWP) / SPI ¤ IEAC3 = ACWP + (BAC – BCWP) / (SPI x CPI) ¤ IEAC4 = ACWP + (BAC – BCWP) / ((wt1 x SPI) + (wt2 x CPI)) ¤ IEAC5 = ACWP + (BAC – BCWP) / CPIx ChapterII 79
- 80.
- 81. Deploying the fivecore processes of Deliverables Based Planning® is an incremental and iterative activity. Each incremental step increases the maturity of the project or program deliverables. 81 IIIDeploying Deliverables Based Planning® Chapter
- 82. 82 Putting The FiveCore Processes of Deliverables Based Planning® to Work Define the set of capabilities needed to achieve the program objectives or the particular end state for a specific scenario. Using the ConOps, define the details of who, where, and how it is to be accomplished, employed and executed. 1 Define the technical and operational requirements that must be in place for the system capabilities to be fulfilled. First, define these requirements in terms that are isolated from any implementation technical products. Only then bind the requirements with technology. 2 Build a time–phased network of schedule activities describing the work to be performed, the budgeted cost for this work, the organizational elements that produce the deliverables, and the performance measures showing this work is proceeding according to plan. 3 Execute work packages, while assuring all performance assessment are 0%/100% complete before proceeding. No rework, no forward transfer of activities to the future. Assure every requirement is traceable to work and all work is traceable to requirements. 4 Perform the 6 process areas of Continuous Risk Management for each Deliverables Based Planning® process area to Identify, Analyze, Plan, Track, Control, and Communicate programmatic and technical risk 5 Chapter III
- 83. Define the setof capabilities needed to achieve the program objectives or the particular end state for a specific scenario. Using the ConOps, define the details of who, where, and how it is to be accomplished, employed and executed. Process Activities Outcomes or Deliverables Benefits Using the supplied Statement of Work (SOW), Statement of Objectives (SOO) extract a description of the operational behavior of the system in a Concept of Operations (ConOps) and an associated process flow diagram. A Process Flow Diagram of the system with verbs in the boxes and nouns on the lines. This can be done in Visio using the IDEFÆ notation, or some other systems engineering process and element diagramming method [IDEFÆ]. A single diagram showing the system components, the data or actions it produces, and how these components interact. This diagram shows the increasing maturity of the system as is proceeds from left to right in the Integrated Master Plan (IMP), through each Program Event. With the Process Flow Diagram, identify the Accomplishments for each Milestone or Event. Identify the dependencies between each Accomplishment within and between the Integrated Product Team (IPT) stream. For each Event or Milestone, build a single page chart for each Accomplishment for each Integrated Product Team (IPT) members work stream. These diagrams show how each Event or Milestone will be met from the completion of the Accomplishment s. With the dependencies identified, a top level precedence diagram is now available for the development of the Integrated Master Schedule (IMS). With each Accomplishment defined and arranged in a sequence of increasing maturity within the Event or Milestone, capture the Criteria for the assessment of the Accomplishment. These Criteria are the “Exit Criteria” for the Work Packages containing the Work Tasks. The exit criteria for the work effort will be defined in terms meaningful to the assessment of Physical Percent Complete and the completion of the Accomplishment. Connections from Milestone or Event, to Accomplishments and to the Criteria describe the increasing maturity of the program. This is more than just the traditional list of items in the Integrated Master Plan. But a description of the program’s process flow and its increasing value. 1 Chapter III83
- 84. Define the technicaland operational requirements that must be in place for the system capabilities to be fulfilled. First, define these requirements in terms that are isolated from any implementation technical products. Only then bound the requirements with technology. Process Activities Outcomes or Deliverables Benefits Identify the end user and system functional requirements through a requirements flow down process in some type of database system. This doesn’t have to be a large scale tool, but it must provide some sort of change control and tracking of the requirements. In order to make requirements trade offs, the requirements must be organized in a logical manner. Starting organized, keeping organized, and tracing changes to the requirements is part of the requirements elicitation and management processes. Keeping requirements under control is a critical success factor for controlling the scope of the program. Not changes to the requirements baseline can be made without on impact assessment. Build a Requirements Traceability Matrix between the SOW, SOO, ConOps, CDRLs, DID’s and any other document containing requirements. Place these requirements in a database so “pivots” and “coverage” assurance can made between all the sources. There may be conflicting requirements on the program. This will never be known early if all the requirements are not in one place, under the control of the Change Board The requirements elicitation process has five (5) steps: § Fact finding § Gathering and Classifying § Evaluation and Rationalization § Prioritization § Verification and Validation These must be performed in an iterative, incremental, and logical sequence, capturing the resulting “emergence” of the requirements baseline through each cycle. A requirements system model that captures facts, classifications, evaluation, rationalizations, prioritizations, and verifications in a Requirements Management Database of some form. By organizing the requirements in the form of a database is a critical success factor for the program. With this database, traceability of the requirements from the system capabilities to the technical and operational deliverables. Only by building these traceability relationships, can trade offs be made in the presence of distributions in the program due to funding, requirements, and technical changes. 2 Chapter IIIChapter III84
- 85. Build a time–phasednetwork of schedule activities describing the work to be performed, the budgeted cost for this work, the organizational elements that produce the deliverables, and the performance measures showing this work is proceeding according to plan. Process Activities Outcomes or Deliverables Benefits Using the Events or Milestones, Significant Accomplishments, Accomplishment Criteria, the Work Packages and Planning Packages are constructed for each Accomplishment Criteria. These Work Packages are the starting point for the Integrated Master Schedule The Work Packages contain the resources and work activities needed to produce a deliverable represented by the Accomplishment Criteria – the outcome of the Work Package. An Integrated Master Schedule (IMS) for the work effort needed for each Accomplishment Criteria is the starting point for optimizing the program execution description. The IMS describes the work activities needed to increase the maturity of the delivered product or service. The Exit Criteria for these work activities are measured by the Accomplishment Criteria – the measureable outcome of each Work Package. The Accomplishment Criteria are the entry conditions for the Significant Accomplishments. The Significant Accomplishments describe the current maturity of the deliverables in units of measure defined during the development of the Integrated Master Plan (IMP). The increasing maturity of the program can be measured through assessments of Physical Percent Compete. These units of measure are derived from the Technical Performance Measures of the delivered article at the specific time point in the schedule. By connecting cost, schedule, and technical performance in a time–phased assessment process, the Program Manager will have insight into the progress of the program, not just as assessment of cost and schedule performance. With the sequenced Work Packages, the labor and other direct costs are applied to the Integrated Master Schedule (IMS). This Labor and Cost Spread reveal speaks and valleys in the labor assignments. These must be smoothed to match the actual labor availability before further analysis of the IMS can take place. An “all in” IMS contains all work, all resources, all dependencies , all risk mitigation and retirement plans, and all assessment processes of the increasing maturity of the program. With the IMS in place, budget spreads are “balanced “ across the collection of Work Packages to meet the objective measures of the organization and the technology BCWS balanced spreads across the current rolling wave and across planning packages. Visibility into the budget demands and labor utilization for ach rolling wave and planning packages. 3 Chapter IIIChapter III85
- 86. Execute work packages,while assuring all performance assessment are 0%/100% complete before proceeding. No rework, no forward transfer of activities to the future. Assure every requirement is traceable to work and all work is traceable to requirements. Process Activities Outcomes or Deliverables Benefits The duration between measurements of progress must be tuned to the business rhythms of the program. A simple question is how long are you willing to wait before you find out you are too late to take corrective action? Periodic Business Rhythm Meetings where a simple Status Report is reviewed and forecasts for the performance in the next period are committed to. Measuring progress in physical percent complete units provide visibility in ways not possible with simple measures of cost and schedule. Coupling cost, schedule, and technical performance is the basis of Performance Based Earned Value Define the Business Rhythm to provide timely insight into the progress of the program. This should be a minimum of a monthly performance report. A published Business Rhythm Process Flow with deliverables, data sources, work processes, accountabilities, and an archive for this information. Bi–weekly and monthly measures of performance are used to guide management decisions. Capturing the physical percent complete starts with defining the agree on units of measure of performance for each Work Package (WP) allocated to the Control Account. These measures must match the technical assessment of the products or services provided from the WP. Apportioned milestones, 0/100% complete descriptions and other measures of Physical Percent Complete are defined in the WBS Dictionary. Measurements of progress are done through evidentiary materials – artifacts from the program that can be “seen” by the program stakeholders, rather than just “reported” on. By connecting cost, schedule and technical performance in the assessment of progress can the program determine how is it progressing, how efficient the resources are working and what the risk adjust Estimate to Complete is. Project status report that measures the Physical Percent Complete for Apportioned Milestones, 0/394 deliverables or other evidentiary materials of progress. Defining these measures “before” the execution of the WPs provides a baseline for measurement of Physical Percent Complete. 4 Chapter IIIChapter III86
- 87. Perform the 6process areas of Continuous Risk Management for each Deliverables Based Planning® process area to Identify, Analyze, Plan, Track, Control, and Communicate programmatic and technical risk Process Activities Outcomes or Deliverables Benefits Identify A list of risks that impact the technical, operational, programmatic, and financial aspects of the program All risk identified before they become problems. All risk information incorporated in the program management process. Analyze A prioritization of these risks, their mitigations or retirements All risk data converted into decision making information. Plan The detailed cost and schedule of the mitigation or retirement of the identified risks Consequences and sources of risk are known. Effective plans for handling these risks are developed. Corrective actions from these plans minimize risk and impacts to the program while maximizing opportunity and value. Track Oversight and management of the work efforts to mitigate or retire the identified risks Accurate, timely, and relevant information is collected and presented in a clear and concise manner appropriate to the person or group receiving the information. Control Decisions regarding replanning, closing, invoking contingencies, and continued tracking of risks and their mitigations Informed, timely, and effective decisions are made regarding risks and their mitigation plans. Communicate A communication plan that fits the organization’s culture. This plan describes the risk communication processes needed to properly inform management and staff of the risks and mitigation plans The program’s risks and mitigation alternatives are understood and communicated. Informed choices can be made with this information within the constraints of the program. 5 Chapter III87
- 88.
- 89. DBP Process 1.0 “Planning,under uncertainty, to provide capabilities suitable for a wide range of modern- day challenges and circumstances while working within an economic framework that necessitates choice.” By Identifying system capabilities, the elicited technical and operational requirements can be traced from the Measures of Effectiveness to each deliverable in the Integrated Master Plan and Schedule. Capabilities state the “why” of the system. 89 IVIdentify Needed System Capabilities Chapter
- 90. 1.0 – IdentifyNeeded System Capabilities Discovering needed system requirements begins with the a narrative description of the needed Capabilities. Defining capabilities provides a rational basis for making decisions about requirements and allows planning to be responsive to uncertainty. [TTCP] This sounds like a tautology – a Chicken or the Egg problem. But discovering the system requirements is difficult in the absence of some higher level description of the needed “Capabilities” of the desired system. The concept of a “Capability” is a capacity or potential [Davis]: § Provided by a set of resources and abilities § To achieve a measureable result § In performing a particular task § Under specific conditions § To specific performance standards One approach to capturing the system capabilities is: § Start with the customers understanding the current and future operational needs of their system. § Aligning those needs with industry standards and trends. Translating the needs into system capabilities in the form of system requirements specification or a Concept of Operations. The Systems Requirements Specification is not the same as a Technical Requirements Specification. Establish a high–level system concept to identify system components and their interfaces. Guide the Integrated Product and Process Development (IPPD) Teams, mentoring, and working with providers of system components (both custom built and COTS) to ensure they adhere to the overall system view. Work with the customer to identify and mitigate technical risks through a structured Risk Management process at the Systems Requirements level. Verify each system capability through a System Integration and Qualification Test Plan. Work with the customer to develop a Fielding and Product Support Plan of the delivered system. ChapterIV 90
- 91. § Partition systemcapabilities into classes of service within operational scenarios § Connect capabilities to system requirements using sysML § Define Measures of Effectiveness (MoE) from the customer point of view § Define in the delivery schedule the achievement of each Technical Performance Measure § Define scenarios for each system capability § Connect these scenarios to a Value Stream Map of the increasing maturity of the program § Assess value flow through the map for each needed capability § Identify capabilities mismatches and make corrections to improve overall value flow § Assign costs to a system element using a value model process model § Assure risk, probabilistic cost and benefit performance attributes are defined § Use cost, schedule and technical performance probabilistic models to forecast potential risks to program performance § Make tradeoffs that connect cost, schedule, and technical performance in a single “trade space” model § Measures of Effectiveness and Measures of Performance are the raw materials for these tradeoffs Define the set of capabilities to be employed to achieve desired objectives or a particular end state for a specific scenario. Take the ConOps and define the details of who, where, and how it is to be accomplished, employed and executed. 1.0 1.1 1.2 1.3 1.4 Chapter IVChapter IV91
- 92. § Partition systemcapabilities into classes of service within operational scenarios § Connect capabilities to system requirements using sysML § Define Measures of Effectiveness (MOE) and Measures of Performance (MOP) § Define in the delivery schedule the achievement of each Technical Performance Measure Process Activities Outcomes or Deliverables Benefits 1 Decompose the SOW, SOO, and other RFP and system documents, into a Concept of Operations (ConOps). § A Top–to–bottom System Traceability Structure as the starting point for the Requirements Management Baseline. § This structure is a “map” of the needed capabilities, their interrelationships. This forms the basis of the requirements flow down process. Starting at the beginning of the program capture capabilities in a form that can be used to trace requirements, deliverables and performance measures back to these capabilities. 2 Build a map between the System Capabilities in the using the Design Structure Matrix. [Browning99] § Design Structure Matrix showing dependencies between operational capabilities. § Optimized structural alternatives suggesting re–architecting of these dependencies. Place all information in a common database for analysis, publishing, and change control. 3 Define Measures of Effectiveness (MOE) for each capability. How would the presence of the capability be recognized? § The Measures of Effectiveness (MOEs) are quantitative measures that provide some insight into how effectively a product or service is performing. § MoE’s are derived from stakeholder expectation statements. § MoE’s are deemed critical to the mission or operational success of the system § For example: “95% of all work will be completed within 15 business days or the negotiated deadline.” The basis of physical percent complete can be defined with measures of effectiveness. 4 Define Measures of Performance (MOP) for each capability. How would the presence of the capability be recognized? § MoPs serve as criteria to hierarchically organize these MoEs. § MoPs are qualitative or quantitative measures of system capabilities or characteristics as seen from the providers point of view. § MoPs are broad physical and performance parameters. § MoPs are components, or subsets, of MoEs; i.e., the "degree– to–which" a system performs is one of a number of possible measures of "how well" a system's task is accomplished. The basis of physical percent complete can be defined with measures of performance. 1.1 Chapter IVChapter IV92
- 93. § Define scenariosfor each system capability § Connect these scenarios to a Value Stream Map § Assess value flow through the map for each needed capability § Identify capabilities mismatches and make corrections to improve overall value flow Process Activities Outcomes or Deliverables Benefits 1 List individual capabilities in scenario forms: Use Case, process flows, or an operational description Scenario Based Descriptions using some notation amenable to systems analysis – IDEFÆ or SysML. A single integrated representation of the needed capabilities in a form assessable with formal tools. 2 Assess dependencies between capabilities using Design Structure Matrix (DSM) tool Identify implicit dependencies as well as explicit dependencies in a DSM. Remove or minimize the implicit dependencies. Address interface management issues with the explicit dependencies. 3 Perform a Functional Area Analysis (FAA) [INCOSE] Characterize a specific area of the system in terms of the operations that are required to be performed to support the mission in a FAA. Produces a focus on provides capabilities based on functional scenarios rather than specific technologies. 4 Performance a Functional Needs Assessment (FNA) [INCOSE] Assess the ability of the current and planned systems to deliver the capabilities identified in the FAA. Produces a focus on identifying gaps in both the scenarios and the functional behaviors needed to fulfill those scenarios. 5 Perform a Functional Solutions Analysis (FSA) [INCOSE] An operationally–based assessment of all potential organizational, training, technological, material, leadership, personnel and facilities and the supporting policy approaches to solving (or mitigating) one or more of the capability gaps identified in the FNA. Produces a focus of identifying all participating elements of the system beyond the technological deliverables. 1.2 Chapter IVChapter IV93
- 94. § Assign coststo a system element using a value model process model § Assure risk, probabilistic cost and benefit performance attributes are defined § Use cost, schedule and technical performance probabilistic models to forecast potential risks to program performance Process Activities Outcomes or Deliverables Benefits 1 For each implicit and explicit dependency asses the nouns and verbs that cross the interface boundary. A weighted Trade Space Matrix for each capability used to assess the cost and benefit for each requirement that has alternative choices of implementation. ü Establish a common vocabulary for making tradeoffs between desired or needed capabilities in a form beyond just personal assessment. 2 Assign cost, risk, and operational needs for each capability and its impact on the adjacent interface element. A monetized assessment of each “trade space” element used to build a credible business model for the trade space decisions. ü Document these trade offs in a formal manner (sysML) that can be used by analysis tools [Sharman]. 3 Make assessments between cost, risk, and operational needs in some form of mathematical model. Quantitative data showing the relationship between these elements. ü A tangible assessment of the “trade space” between the programmatic elements of the system. 4 From the data above, perform CAIV (Cost As an Independent Variable) assessment. Set aggressive, but realistic cost objectives when defining operational requirements and acquiring defense systems and managing achievement. Adjusted program cost objectives through the use of cost‒performance analyses and trade‒offs. ü Execution of the program in a way to meet or reduce stated cost objectives. ü Realization that risks are present and must be understood and managed in order to achieve performance, schedule and cost objectives. 5 For the CAIV process define the maximum and minimum affordable price and the maximum and minimum performance thresholds. Trade studies that address meeting user performance needs and cost / resource constraints, while performing on schedule with minimal acceptable risk. ü Visibility in the probability of success for the program based on the trade space of cost, schedule, and technical performance. 1.3 Chapter IVChapter IV94
- 95. § Make tradeoffsthat connect cost, schedule, and technical performance in a single “trade space” model § Measures of Effectiveness and Measures of Performance are the raw materials for these tradeoffs Process Activities Outcomes or Deliverables Benefits 1 Using the Design Structure Matrix elements for the operational capabilities assess the trade offs between feasibility, cost, and risk. An analytical model of the capabilities “trade space.” A continuation of the analytical assessment processes of the needed capabilities. 2 Monetize the tradeoffs in the Design Structure Matrix to assess the connections between risk, value, and compliance with Capabilities and Requirements. A “Trade Space” map showing the connectivity between the trade elements. Full traceability between all the trades. 3 Define the tradeoffs in terms of Measures of Effectiveness (MOE) and Measures of Performance (MOP), Risk Evaluation, Schedule Impacts in a probabilistic manner. A Risk Adjusted model of the trade offs. Adjusted measurements of the “trade space.” 4 Use Real Options (RO) to make tradeoffs when the necessary measurement variables are available. A Real Options model of the trade offs. Another view of the trade space, from the point of view of capital usage. 1.4 Chapter IVChapter IV95
- 96. Events / Milestones Definethe availability of a Capability Accomplishments Criteria Work Package Work Package Work Package Work Package Work Package Work Package Work Package Work package § Events and Milestones are assessment points for system Capabilities. § Technical and operational requirements are constructed from these Capabilities. § Capabilities elicited and organized in a hierarchy matching the functional decomposition of the system. § System Capabilities defined and structured to enable the requirements elicitation process to be started. § Order of the availability of the Capabilities defined by the mission or business process, to match the Concept of Operations or Strategy. § Feedback from requirements elicitation – in later stages – used to adjust the Capabilities assessment in the presence of conflicts. § Full traceability between systems capabilities of the top level system partitioning architecture. Chapter IVChapter IV96
- 97. Action Outcome Implement Strategy EnsureCapabilities Prioritize Problems And Solutions Identify Redundancies Deliver Solutions Chapter IVChapter IV97 † [Kossakowski]
- 98.
- 99. DBP Process 2.0 Baselinedrequirements are the basis of Work Packages and Planning Packages and the work efforts needed to produce the deliverables from these Packages. These deliverables fulfill the technical and operational requirements needed to deliver the system Capabilities. Tracing Capabilities to Requirements assures each requirement has a “home” in the system. 99 VEstablish Requirements Baseline Chapter
- 100. 2.0 – Establishthe Requirements Baseline Poorly formed requirements have been shown to contribute as much as 25% to the failure modes of programs and projects. Requirements engineering can be decomposed into the activities of requirements elicitation, specification, and validation. Most of the requirements techniques and tools today focus on specification, i.e., the representation of the requirements. The Deliverables Based Planning® method concentrates instead on elicitation. This method addresses problems found with requirements engineering that are not adequately addressed by specification techniques. [Christel] This Deliverables Based Planning® method incorporates advantages of existing elicitation techniques while addressing the activities performed during requirements elicitation. These activities include fact–finding, requirements gathering, evaluation and rationalization, prioritization, and integration. The requirements baseline is established starting with a Fact Finding activity. This does not search for requirements, but instead defines the boundaries of the requirements space. With these boundaries established, the actual requirements can be gathered and classified. The classification process is an important state for assessing the need, evaluation, and tradeoff processes. Evaluating the requirements is done against the background of the system boundaries and system capabilities. With these evaluation, prioritization can start. These prioritizations assess the order in which the requirements will be deployed against the funding and resource limitations. With the requirements prioritized, they can then be integrated and validated. The integration process defines the interdependencies between requirements that guide the development of the Work Packages that produce the deliverables that fulfill the requirements. ChapterV 100
- 101. Define the technicaland operational requirements that must be in place for the system capabilities to be fulfilled. Define these requirements in terms isolated from any implementation. 2.0 § Produce an overall statement of the problem in an operational context. § Develop the overall operational and technical objectives of the target system. § Defined the boundaries and interfaces of the target system. 2.1 § Gather required system capabilities, functional, nonfunctional and environmental requirements, and design constraints. § Build a Top Down Capabilities and Functional decomposition of the requirements in a flow down tree using a Requirements Management System. 2.2 § Answer the question “why do I need this?” in terms of operational benefits. § Build a cost benefit / model using probabilistic assessment of all variables and dependencies. § For technical requirements, perform a risk assessment to cost and schedule. 2.3 § Determine criticality for the functions for the system mission. § Determine trade off relationships for all requirements to be used when option decisions are made. § For technical items prioritize on cost and dependency. 2.4 § Address completeness of requirements by removing all “TBD” items. § Validate the requirements agree and are traceable to system capabilities, goals, and mission. § Resolve any requirements inconsistencies and conflicts. 2.5 Chapter VChapter V101
- 102. § Produce anoverall statement of the problem in the operational context § Develop the overall operational and technical objectives of the target system § Defined the boundaries and interfaces of the target system Process Activities Outcomes or Deliverables Benefits 1 Identify relevant parties across multiple levels of the Requirements breakdown. A list of program stakeholder, participants, and suppliers as one portion of a Program Traceability Matrix. Make visible all influences on the use, consumption, creation, and constraints of the requirements. 2 Determine operational and problem context, including definition of operational modes, goals, and mission scenarios as appropriate. From the Concept of Operations, create a cross reference between the program’s operational behaviors and the stakeholders. Make visible the interactions between the requirements elements and their influence on technical and programmatic risk. 3 Identify similar systems and systems elements within the requirements breakdown. The attributes of similar systems can be the starting point for Fact Finding. Preserving these requirements baselines preserves these attributes. Lessons learning and “past performance” are enablers of process and product improvement. 4 Perform context analysis between these similar elements to isolate redundancy and duplication. A description of the context of each requirement – why is it here? What value does to provide? Start the basis of the economic assessment of each requirements and how it supports the capabilities. 5 Identify domain experts (both application area and development experts). A Connectivity Matrix between the requirements and the subject matter expert. Through subject matter experts, facts about the requirements can be captured classified, and prioritized. 6 Identify domain and architectural models for each of the requirements elements. The domain and architectural models captured in sysML or IDEFÆ. An integrated model using a standard notation is the basis of analysis 7 Conduct technological surveys, for later feasibility studies and risk assessment. Associate technological options with each requirement. Requirement trade offs provide the basis of cost assessments. 8 Assess cost / implementation constraints imposed by the sponsor. Associate the cost trade offs with each requirement. Cost trade offs are based on understanding cost structure. 2.1 Chapter VChapter V102
- 103. § Gather requiredoperational capabilities, functional, nonfunctional and environmental requirements, and design constraints § Build a Top Down Capabilities and Functional decomposition of the requirements in a flow down tree using a Requirements Management System. Process Activities Outcomes or Deliverables Benefits 1 Capture the “list” of requirements derived from the Concept of Operations. A structured Requirements Flow Down Tree. Identify the connectivity between the requirements on day one. Although these connections may not be correct in the beginning, start structuring the relationships as early as possible. 2 Classify wish lists according to functional, nonfunctional, environment, and design constraints; and also according to partitions defined by domain models and the development paradigm (e.g., top–down functional decomposition or object–oriented). Partition the assignment of requirements items by multiple categories. Avoid the simple “wish list” approach with no means of separating value, risk, cost, feasibility and other “show stopper” attributes. 3 Turn the lists into a Requirements Tree and connect dependencies and parent child relationships Requirements Tree Clear and concise connectivity between requirements and the system capabilities needed to make “trade space” decisions. 2.2 Chapter VChapter V103
- 104. § Answer thequestion “why do I need this?” in terms of operational benefits § Build a cost benefit / model using probabilistic assessment of all variables and dependencies § For technical requirements, perform a risk assessment to cost and schedule. Process Activities Outcomes or Deliverables Benefits 1 Perform abstraction to answer questions of the form “Why do you need X?”; this in effect moves from statements of “how” to statements of “what”. Using sysML or some form of dependency modeling, connect the “need” with the requirements element. Traceability from need to requirement is made visible to all participants so they can understand the impact on the cost and schedule for each requirement. 2 Capture rationale to support future requirements evolution. A narrative about “why” this capability is needed, its impacts on the requirements. Requirements reuse is likely to be of value in large enterprise programs. Capturing the motivation for reuse is critical. 3 Perform risk assessment, addressing technical, cost, and schedule concerns. This includes cost/benefit filtering and feasibility analysis based on technology availability. Using the sysML model a risk map can be created. Mapping risk to individual requirements provides the source of managing risks, but also for making tradeoffs based on risk. 2.3 Chapter VChapter V104
- 105. § Determine criticalityfor the functions for the system’s mission § Determine trade off relationships for all requirements to be used when option decisions are made § For technical items prioritize on cost and dependency Process Activities Outcomes or Deliverables Benefits 1 Determine criticality, i.e., the critical functions for the mission. Ranked list of critical elements using a “paired comparison” analysis with geometric progress. No simple linear list can be useful. Geometric ranking (1,2,5) and a paired comparison between each requirement. 2 Prioritize requirements based on cost and dependency. Study how the system can be incremented, and identify appropriate architectural models which support incremental development. Using the sysML or IDEFÆ model assessments of cost and dependencies on the individual requirements. Using ”models” instead of lists provides the opportunity to assess impacts beyond simple linear relationships. 2.4 Chapter VChapter V105
- 106. § Address completenessof requirements by removing all “TBD” items § Validate the requirements agree and are traceable to capabilities, goals, and mission § Resolve any requirements inconsistencies and conflicts Process Activities Outcomes or Deliverables Benefits 1 Address completeness by filling in as many “to be determined” issues as possible. Using the “requirements” model assess any missing components and grade the maturity of the requirements model with this attribute. Make visible the “maturity” of the requirements in tangible measures. 2 Validate that requirements are in agreement with originally stated goals. Build a traceability matrix from the requirements back to the system capabilities. Assure each system capability has a fulfilling requirement that is explicitly defined in the requirements model. 3 Obtain authorization/verification to move to the next step of development, e.g., the demonstration and validation phase. Assess the completeness of the requirements model during a formal requirements review. Make visible any gaps in the review process. 4 Resolve conflicts (consistency checking). Using sysML or IDEFÆ map any gaps and define closure actions. Assess the maturity of the requirements model using tangible metrics. 2.5 Chapter VChapter V106
- 107. Events / Milestones Accomplishmentsdefine the entry conditions for each Event or Milestone Criteria Work Package Work Package Work Package Work Package Work Package Work Package Work Package Work package § Capabilities are defined in the Concept of Operations and decomposed into a requirements traceability process. § Accomplishments represent the “entry” criteria for the presence of a Capability. “What must be accomplished in order to provide a Capability to the user?” § Decomposition is represented in a “requirements flow down tree” that follows the structure of the produce or service. § For the terminal nodes of each requirements in the “requirements tree,” one or more Deliverables can be identified. These deliverables are produced from the work efforts contained in the Work Package. § Sequencing of the Work Packages is the next step in the Deliverables Based Planning process. Chapter VChapter V107
- 108.
- 109. DBP Process 3.0 ThePerformance Measurement Baseline (PMB) assesses progress to plan through measures of physical percent complete. Starting at the Work Package level, a pre–defined performance measure is established. During the performance period assessment of “progress to plan” produced measures of Physical Percent Complete 109 VIEstablish Performance Measurement Baseline Chapter
- 110. 3.0 – Establishthe Performance Measurement Baseline The Performance Measurement Baseline (PMB) is the primary assessment document for assuring the credibility of a program plan. The PMB is the baseline of the cost, schedule and deliverables for each Work Package (WP) in the plan. Constructing the PMB requires knowledge of the system requirements, skill in developing the WPs that produce the deliverables for these requirements, and discipline in assembling the cost, schedule and relationships between the WPs. It is the discipline that requires the most focus for the planners and program controls staff. Without this discipline, the development of a credible baseline is simply not possible. In the end the planners and program controls staff must “know” in intimate detail each WP, its deliverables and resource requirements, the performance measurement criteria and the dependencies that form the critical path through the program schedule. The concept of a Deliverables Based Plan (DBP) is at the core of the Performance Measurement Baseline (PMB). § Deliverables are the units of measure of progress to plan. § Deliverables are what the customer has paid money for. § Deliverables contain the system capabilities, the associated value that fulfill the requirements of the master plan The first critical success factor in building the Performance Measurement Baseline (PMB) is the decomposition of the system requirements into technical capabilities, then into deliverables that enable those technical capabilities, and finally into the WPs that produce those deliverables. This material provides a Practice Guide for constructing these WPs and assembling them into a network. The physical construction of the WPs can take many forms suitable for the needs of the program. The format for these WPs is not critical. The contents are. The format should be appropriate to the needs of the program. The Principle of Deliverables Based program management using WPs includes: § Defining the decomposed deliverables from the needed system capabilities in a Work Breakdown Structure. This decomposition process MUST be iterative and incremental. Assessment of the validity of this decomposition requires thought. The first decomposition is likely not the best approach. § Estimating the duration and work effort for each WP. Duration and effort estimating is iterative and incremental, it cannot be a one–time effort. The initial estimated MUST be assessed after the assembly of the WPs into the Activity Network with inter–work stream dependencies. Only then can they be considered credible. ChapterVI 110
- 111. Build a time–phasednetwork of schedule activities describing the work to be performed, the budgeted cost for this work, the organizational elements that produce the deliverables, and the performance measures showing this work is proceeding according to plan. 3.0 Decompose the Project Scope into a product based Work Breakdown Structure (WBS), then further into Work Packages describing the production of all deliverables traceable to the requirements 3.1 Assign Responsibility to Work Packages (the groupings of deliverables) for the named owner accountable for the management of resource allocation and cost baseline and technical delivery 3.2 Arrange the Work Packages in a well formed network with defined deliverables, milestones, internal and external dependencies, appropriate schedule and cost margin. 3.3 Develop a Time–Phased Budgeted Cost for Work Scheduled (BCWS) from labor and material costs in each Work Package and the Project as a whole. Assure proper resource allocations can be met and budget profiles match expectations of the program sponsor 3.4 Assign objective Measures of Performance (MOP) and Measures of Effectiveness (MOE) for each Work Package and summarize these for the Project as a whole 3.5 Establish a Performance Measurement Baseline (PMB) used to forecast Work Package and Project ongoing and completion cost and schedule metrics 3.6 Chapter VIChapter VI111
- 112. § Decompose theProject Scope into a product based Work Breakdown Structure (WBS) § Decompose WBS into Work Packages describing the production of all deliverables traceable to the requirements Process Activities Outcomes or Deliverables Benefits 1 Map the desired system capabilities into categories of system elements. A Requirements Flow Down Tree from the requirements to Work Packages that produce deliverables. Continue with full traceability from capability to deliverables. 2 Build a Work Breakdown Structure derived from the requirements categories. Focus on products that are delivered from the work effort. Construct a product centric WBS. Not a functional WBS. This WBS should follow the 100% rule [MIL 881] and the Mutually Exclusive rule (no overlap between WBS elements). Assign resources and functional to each deliverables in the WBS (product breakdown tree). The WBS describes “planned outcomes” not “planned activities.” 3 Decompose the requirements into collections of deliverables at the terminal nodes of the WBS. Assembly collections of requirements into logical “lumps of work” for assignment to subject matter experts for estimating Discovering how the “lumps of work” are related is an iterative process. making them visible is the start. 4 Produce a requirements traceability matrix in some form of automated tool. Quality Function Deployment (QFD) or Design Structure Matrix (DSM). [Danilovic] Using the WBS, the requirements tree and other relationship models, use DSM to construct a dependency model. Making visible explicit and implicit relationships is critical to verify requirements and avoiding conflicts. 5 Examine the decomposition to determine if all the components are clear and complete. Using the model verify interdependencies are needed. Reduce coupling and increase cohesion of the requirements. 6 Determine if each component listed is absolutely necessary to fulfill the requirements of the deliverable and verify that the decomposition is sufficient enough to describe the work. Assessment of the necessity for each requirement. Complete the traceability from requirements up to capabilities and from capabilities down to requirements. 3.1 Chapter VIChapter VI112
- 113. Assign Responsibility toWork Packages (the groupings of deliverables) for the named owner accountable for the management of resource allocation and cost baseline and technical delivery Process Activities Outcomes or Deliverables Benefits 1 Assign Responsibility for Work Packages to named owners who are accountable for the management of resource allocation and cost baseline, and technical performance. This manager is accountable for managing the activities of the Work Package and its deliverables. Fine grained work activities with tangible and measurable deliverables and their measures of progress provides visibility into the actual progress of the program. 2 Build a Responsibility Assignment Matrix (RAM) showing all deliverables and the accountable person for the successful completion of that deliverable. The RAM identifies the accountable person for each Work Package. Assigning Accountability is mandatory. The Accountable person can them assign Responsibility. The other two elements of RACI may be useful, but are not mandatory at the Work Package level. Single point of integrative responsibility removes the confusion over who has the information about the performance of the Work Package. 3.2 Chapter VIChapter VI113
- 114. Arrange the WorkPackages in a well formed network with defined deliverables, milestones, internal and external dependencies, appropriate schedule and cost margin. Process Activities Outcomes or Deliverables Benefits 1 Arrange the Work Packages in a well formed network with explicitly defined deliverables, milestones and internal and external dependencies. A Work Packages Road Map of each sequence in the delivery of the product or service, showing dependencies, deliverables, maturity increases, risks and their mitigation or retirement, and other attributes meaningful the senior management. An assessment of the increasing maturity of the pro duct or service produced by the work effort of the program. 3.3 Chapter VIChapter VI114
- 115. Develop a Time–PhasedBudgeted Cost for Work Scheduled (BCWS) from labor and material costs in each Work Package and the Project as a whole. Assure proper resource allocations can be met and budget profiles match expectations of the program sponsor Process Activities Outcomes or Deliverables Benefits 1 Develop Time–Phased Budget (BCWS) from labor spreads in each Work Package and balance these BCWS spreads across the Project. Labor Spread Report for all work packages. Make visible peaks and valleys in the labor spread to start balancing the work load, cost, and on–boarding processes. 2 Assign BCWS to each Work Package and roll up these Work Packages into Control Accounts. Budget Spread Report by Work Package, Control Account, and product deliverables. These spreads must have probabilistic assessments of their ranges in order to establish a credible Estimate At Completion. Visibility into not only the baseline cost models, but the variability of these costs by each class of risk. 3.4 Chapter VIChapter VI115
- 116. § Assign objectMeasure of Performance (MOP) and Measures of Effectiveness (MOE) for each Work Package and summarize these for the Project as a whole. § Assign measures of Physical Percent Complete Process Activities Outcomes or Deliverables Benefits 1 Assign Objective Performance Measures for each Work Package and summarize these for the Project as a whole. A Objective Measures Report attached to deliverables in units meaningful to the consumer of the deliverable. This measure of Physical Percent Complete is an unequivocal assessment of progress. 2 Use the 0%/100% measurement of complete whenever possible Using the 0% /100% assignment or the Apportioned Milestone assignment, the Physical Percent Complete is multiplied by the Budgeted Cost of Work Scheduled (Planned Value, PV) for the entire Work Package to produce the Budgeted Cost of Work Performed (Earned Value, EV). With 0/100, apportioned milestones, and physical percent complete define “done” in unassailable measures of progress. 3 Use other measures of physical percent complete for deliverables that cross multiple reporting periods. Apportioned milestones is a useful measure. Defining the value of each milestone as a proportion of the total Work Package value prior to starting the Work Package assures agreement of physical progress is made. 3.5 Chapter VIChapter VI116
- 117. Establish a PerformanceMeasurement Baseline (PMB) used to forecast Work Package and Project ongoing and completion cost and schedule metrics Process Activities Outcomes or Deliverables Benefits 1 Establish a Performance Measurement Baseline to be used forecasting Work Package and Project ongoing and completion metrics. § A Cost Spread Report showing BCWS spreads have been balanced against available resources for that Work Package and the program as a whole. § A Work Package Performance Measure Report showing apportioned milestones, 0/394, 50/50, or 25/75 assignments of Earned Value (BCWP)(EV). Explicitly describe the Physical Percent Complete of each Work Package and its deliverables. 2 Define a location where change control of the Performance Measurement Baseline can take place. This change control processes must be managed by a single individual or a ®all collection of individuals. Define a change control processes that assesses the cost, schedule and technical performance impacts of any change in a risk adjusted manner. Make visible the cost, schedule, and technical performance of any suggested change, along with the impact on the risk to cost, schedule, and technical performance. 3.6 Chapter VIChapter VI117
- 118. Events / Milestonesdefine the availability of a capability at this point in the schedule Accomplishments define the entry conditions for each Event or Milestone Criteria are the exit conditions for each Work Package Work Package Work Package Work Package Work Package Work Package Work Package Work Package Work package § Work Packages arranged in a logical sequence of increasing maturity of the Criteria, which define the entry criteria for the Accomplishments. § Performance Measurement Baseline (PMB) structured around the Work Package sequence below the line in this diagram. § Work performed in each Work Package results in Deliverables. § Deliverables represent the “exit criteria” for the Work Package and the “entry criteria” for describing the Accomplishments of the work effort. § The collection of Accomplishments represent the current maturity state of the program and can be reviewed and accepted by the customer against the planned maturity at this point in the program. Chapter VIChapter VI118
- 119. DBP Process 4.0 Usingthe Performance Measurement Baseline (PMB), each Work Package must start as planned, complete one or near the planned date, and produce the planned technical performance. This is the key to success for any credible deliverables based plan. In the absence of this, the program is behind schedule, over budget, and non– compliant with the technical goals 119 VIIExecute the PMB Chapter
- 120. 4.0 – Executethe Performance Measurement Baseline The focus of the Performance Measurement Baseline execution steps is to physically assess the progress of the program in units reflecting the progress using the three independent variables: § Cost § Schedule § Technical Performance The traditional Earned Value Management approach uses three data sources, the budget (or planned) expenditures (BCWS), the actual expenditures (ACWP), and the Earned Value (BCWP) captured from the Control Account or Work Package Manager’s. The comparison of budget versus actual expenditures indicates what was planned to be spent versus what was actually spent at any given time. The use of Earned Value (BCWP) indicates what was produced for that expenditure. With this approach the use of physical percent complete for the amount of work performed is a starting point. It does not indicate anything about the conformance to specification of the work produced for the amount of money spent. By adding Technical Performance Measures (TPM) to the analysis of Earned Value Management, the program manager can assess the actual progress of the program. Non–compliance with the planned Technical Performance Measures dilutes the Earned Value proportionally. This dilution is in the form of: § Rework of non–compliant deliverables. § Deferred work not completed during the planned period of performance. § With the period of performance complete, the unused funds – if any – are used to adjust the Earned Value (BCWP) to reflect the unfinished or deferred work. § If the work is deferred and there is remaining funds, a change order is issued to move the funding. § If the work is non–compliant and the funding is exhausted, a dilution of BCWP is needed to reflect the true Earned Value. ChapterVII 120
- 121. Execute work packages,while assuring all performance assessment are 0%/100% complete before proceeding. No rework, no forward transfer of activities or features. Assure every requirement is traceable to work and all work is traceable to requirements. 4.0 § Using the Work Package sequencing, release work to be performed as planned § With the RACI based RAM, the Accountable delivery manager guides the development of the products or services for each Work Package 4.1 § Using Physical Percent Complete or Apportioned Milestones capture measures of progress to plan for each Work Package § Report this Physical Percent Complete in a centralized database for each Work Package and the program as a whole 4.2 § Compare the Physical Percent Complete against the Planned Percent Complete for each period of performance § Construct cost and schedule performance indices from this information and the Physical Percent complete measures 4.3 § With the Cost and Schedule performance indices, construct a forecast of future performance of cost, schedule, and technical performance compliance efforts § Take management actions for any Work Packages not performing as planned 4.4 § Record past performance based on Work Package completion criteria § Record past future forecast performance estimates in a historical database § Forecast next future performance against the Performance Measurements Baseline § Report this next future performance estimate to the program stakeholders 4.5 Chapter VIIChapter VII121
- 122. § Using theWork Package sequencing, release work to be performed as planned § With the RACI based RAM, the Accountable delivery manager guides the development of the products or services for each Work Package Process Activities Outcomes or Deliverables Benefits 1 Utilize a Work Authorization process for starting Work Packages. Work Authorization Log shows the planned start, actual start, projected finish, actual finish. This log can be generated directly from Microsoft Project. Make visible all work to be authorized in the coming period of performance and confirm readiness to perform as well as allocated budget. 2 Open (start) Work Packages on using the Work Authorization as planned. If the Work Package does not start on time, record a delay in the Earned Value Management System and produce a “planned late start” estimate along with a “get to green” plan to recover from the late start. Since almost always “late start / late finish graph” and a “get to green plan” is needed for any work package that starts late. No delayed or deferred work can exist with a plan to get back on schedule and back on cost. The program’s performance forecast always includes the “get to Green” plan as an adjustment to the baseline. 4.1 Chapter VIIChapter VII122
- 123. § Using PhysicalPercent Complete or Apportioned Milestones captures measures of “progress to plan” for each Work Package § Report this Physical Percent Complete in a centralized database for each Work Package and the program as a whole Process Activities Outcomes or Deliverables Benefits 1 Capture actual cost of work performed (ACWP). Actual work costs in dollars and hours collected for each Work Package and possibly the tasks within the Work Package. Roll this ACWP to the Control Account. Actuals are important for forecast future costs and schedule impacts. 2 Capture measures of Physical Percent Complete. Measure physical percent complete with apportioned milestones, 0/100, or evidentiary materials. Only measure Physical Percent Complete in tangible units. 3 Record information in a cumulative database for each period of performance. Keep this information in some form of a central database. Past performance is a likely predictor of future performance. 4.2 Chapter VIIChapter VII123
- 124. § Compare thePhysical Percent Complete against the Planned Percent Complete for each period of performance § Construct cost and schedule performance indices from this information and the Physical Percent complete measures Process Activities Outcomes or Deliverables Benefits 1 Critical Path The longest path through the network, along with the near critical paths that appear when the schedule is being executed. Show this path at all times. This and the probabilistic path are the places to focus program management effort. 2 Duration Accuracy Realistic and feasible durations, not just success oriented guesses. Having measure of variance are critical to the credibility of management decisions. 3 Integration All the Work Packages connected horizontally as well as vertically. Horizontal connections are the sequence within a work stream, the intra–dependencies. Vertical integration describes the inter– dependencies between streams that produce increasing value to the program. Keeping all the data in a single location provides statistical analysis of variance. 4 Realism® An achievable schedule with risk adjusted measures. Credibility starts with understanding the underlying statistics. 5 Performance Teams performing at their planned rate. This Performance Factor is used in the denominator for all Earned Value. Measures of performance start with defining “done” in meaningful terms. 6 Variances Any significant differences from the baseline. Managing mans managing variances. 7 Forecasting The predicted cost and completion date. Past is a good predictor of future, but managing also means controlling variances in the future. 8 What–If’s Impacts when the identified risks become active. Alternatives must be built into the plan. 9 Risk The likelihood of overrunning cost or schedule. Managing risk is required for success 10 Resources All the needed resources in place and capable of performing at the planned levels. Cost and schedule integration means all cost accounted for. 4.3 Chapter VIIChapter VII124
- 125. § With theCost and Schedule performance indices, construct a forecast of future performance of cost, schedule, and technical performance compliance efforts § Take management actions for any Work Packages not performing as planned Process Activities Outcomes or Deliverables Benefits 1 Calculate performance measured derived from the Earned Value measurements. Earned Value metrics used to construct the To Complete Performance Index (TCPI) shows how performance must be increased to maintain schedule. Visibility into past performance as a forecast of future performance. 2 Calculate the Earned Schedule values using the Earned Value metrics. A forecast of how the program will proceed in terms of schedule performance, nit just cost performance derived from Earned Value. Another visibility metric into the future performance of the program. 3 Record changes to work package sequencing, other schedule and cost allocation elements in the change control board meeting. Agreed on changes to cost and schedule and the impacts on deliverables done in a formal manner. Visibility into impacts of any change in the cost or schedule of the program. 4 Make adjustments to Work Package Sequence, Resource Assignments, Requirements, or Capabilities Change Control Board processes for cost, schedule, and technical performance measure adjustments Visibility into the impact of any change on the other two independent variables of the program. 4.4 Chapter VIIChapter VII125
- 126. § Record pastperformance based on Work Package completion criteria § Record past future forecast performance estimates in a historical database § Forecast next future performance against the Performance Measurements Baseline § Report this next future performance estimate to the program stakeholders Process Activities Outcomes or Deliverables Benefits 1 Manage the master schedule, the labor and other cost spreads and the descriptions of the performance measures for the deliverables in a change controlled “baseline.” Data captured from each period of performance is added to the Performance Measurement Baseline (PMB) to record past performance used for future performance forecasts. A seamless data stream of past, present and future performance measures assures visibility into the program for management, technical experts and program, planning and controls staff. 2 Capture Work Package performance in a consistent manner. For discrete tasks: § 50/50 § 0/100 § Incremental Milestone § Equivalent Unit § Physical Percent Complete § Supervisors estimate Apportioned Effort § Factored effort directly related to direct tasks Level of Effort § Work that does not result in a final product An agreed on unit of measure for all work performed in the Integrated Master Schedule. 4.5 Chapter VIIChapter VII126
- 127. § Authorize eachWork Package to start work for the planned period of performance. § Using Work Packages sequences, measures of performance for each work package established – physical percent complete defined in units of measure meaningful to the customer § Deliverables from each Work Package completion assessed against the target Technical Performance Measure. § Measure other performance metrics – Late Starts, Late Finished, Margin Erosion, near critical path dependencies, and resource utilization. § Adjustments made to Earned Value from the TPM assessments. Events / Milestones define the availability of a capability at this point in the schedule Accomplishments define the entry conditions for each Event or Milestone Criteria are the exit conditions for each Work Package Work Package Work Package Work Package Work Package Work Package Work Package Work Package Work package Chapter VII127
- 128.
- 129. DBP Process 5.0 Thissection is extracted from the Software Engineering Institute’s Continuous Risk Management Guidebook. The CRM describes the underlying principles, concepts, and functions of risk management and provides guidance on how to implement it as a continuous practice in your projects and organization. 129 VIIIContinuous Risk Management Chapter
- 130. 5.0 – ContinuousRisk Management Continuous Risk Management is based on the underlying principles, concepts, and functions of risk management and provides guidance on how to implement it as a continuous practice in projects and organizations. Risk management is used to continuously assess what can go wrong in projects (i.e., what the risks are), determine which of these risks are most important, and implement strategies to deal with these risks. These principles are based on proven practices confirmed through research, field testing, and direct work with clients. Risk identification is an ongoing activity that takes place during the routine program workflow. Project activities such as programmatic and technical meetings, telecons, reviews, and other forms of communication often bring to light program risks. When this occurs, we record and analyze the risk on a Risk Information Sheet. The process outlined below helps the program team identify and cope with program risks throughout the life of the program. § Team identifies list of potential risk items. Not all items identified are accepted. Risks can be current problems or potential future problems. § Risk Mitigation plan with action items and due dates is developed for each accepted risk item. § Team meets regularly (every 2 weeks for us) to assess risks and add new risk items, if necessary. See Status section on Risk Information Sheet below. § Risks are closed when all the actions to close the risk have been taken. Some risk items are closed quickly; others are open for a long time. Some are considered watch items and the action plan doesn't kick in until certain negative events happen. § Action plans include second sources of some items, requirements redirection, different technologies, etc. § Closed risks remain in the base for future learning. Continuous Risk Management, when performed successfully, provides a number of benefits: § Prevents problems before they occur – indentifies potential problems and deals with them when it is easier and cheaper to do so – before they are problems § Improves product or service quality – focuses on the program’s objectives and consciously looks for things that many effect quality throughout the program lifecycle. § Enables better use of resources – allows the early identification of potential problems – proactive management – and provides input into management decisions regarding resource allocation. § Promotes teamwork – involves personnel at all levels of the program. ChapterVIII 130
- 131. http://www.sei.cmu.edu/risk/index.html Continuous Risk Managementhas Six Components ChapterVIII 131
- 132. 5.0 – ContinuousRisk Management Identify – Before risks can be managed, they must be identified. Identification surfaces risks before they become problems and adversely affect a program. The SEI has developed techniques for surfacing risks by the application of a disciplined and systematic process that encourages program personnel to raise concerns and issues for subsequent analysis. One such technique, the taxonomy‒based questionnaire, is described in subsequent chapters of this report. Analyze – Analysis is the conversion of risk data into risk decision‒making information. Analysis provides the basis for the program manager to work on the “right” risks. Plan – Planning turns risk information into decisions and actions (both present and future). Planning involves developing actions to address individual risks, prioritizing risk actions, and creating an integrated risk management plan. The plan for a specific risk could take many forms. For example: § Mitigate the impact of the risk by developing a contingency plan (along with an identified triggering event) should the risk occur. § Avoid a risk by changing the product design or the development process. § Accept the risk and take no further action, thus accepting the consequences if the risk occurs. § Study the risk further to acquire more information and better determine the characteristics of the risk to enable decision making. Track – Tracking consists of monitoring the status of risks and actions taken to ameliorate risks. Appropriate risk metrics are identified and monitored to enable the evaluation of the status of risks themselves and of risk mitigation plans. Tracking serves as the “watch dog” function of management. Control – Risk control corrects for deviations from planned risk actions. Once risk metrics and triggering events have been chosen, there is nothing unique about risk control. Rather, risk control melds into program management and relies on program management processes to control risk action plans, correct for variations from plans, respond to triggering events, and improve risk management processes. Communication & Documentation – Risk communication lies at the center of the model to emphasize both its pervasiveness and its criticality. Without effective communication, no risk management approach can be viable. While communication facilitates interaction among the elements of the model, there are higher level communications to consider as well. To be analyzed and managed correctly, risks must be communicated to and between the appropriate organizational levels and entities. This includes levels within the development project and organization, within the customer organization, and most especially, across that threshold between the developer, the customer, and, where different, the user. Because communication is pervasive, our approach is to address it as integral to every risk management activity and not as something performed outside of, and as a supplement to, other activities. ChapterVIII 132
- 133. Putting Continuous RiskManagement Work Identify Analyze Plan Track Control Identify Risk Issues and Concerns Evaluate, classify, and prioritize risks Decide what should be done about risks Monitor risk metrics and verify/validate mitigations Make risk decisions Subproject and partner data/constraints, hazard analysis, FMEA, FTA, etc. Risk data: test data, expert opinion, hazard analysis, FMEA, FTA, lessons learned, technical analysis Resources Replan Mitigation Program/project data (metrics information) Statement of risk Risk classification, Likelihood Consequence, Timeframe Risk prioritization Research, Watch (tracking requirements) Acceptance Rationale, Mitigation Plans Risk status reports on: Risks Risk Mitigation Plans Close or Accept Risks Invoke contingency plans Continue to track` ChapterVIII 133
- 134. Identify Risks Identification isa process of transforming uncertainties and issues about the program into distinct and tangible risks that can be described and measured. Identifying risk involves two activities: § Capturing a statement of risk § Capturing the context of the risk The objective of risk identification is to locate risks before they become problems or issues and to I incorporate this information into the program management process. Capturing a statement of risk involves considering and recording the conditions that are causing concern for a potential loss to the program, followed (optionally) by a brief description of the potential consequences of these conditions. The objective of capturing a statement of risk is to arrive at a concise description of risk, which can be understood and acted upon. The statement of risk provides a brief, concise description of the condition and consequence of the risk. Capturing the context of a risk involves recording the additional information regarding the circumstances, events, and interrelationships within the program that may affect the risk. This description has captured more detailed than can be captured in the basic statement of risk. The objective of capturing the context of a risk is to provide enough additional information about the risk to ensure that the original intent of the risk can be understood by other personnel, particularly after time has passed. § Identify Uncertainties – individuals have uncertainties and issues about the project and project progress which may or may not be risks. § Group and Team Uncertainties – in group activities, individuals may together identify uncertainties and issues about the program and program progress which may or may not be risks. § Project Data – the program data is supporting information that consists of items such as the schedule, budget, plans, work breakdown structure, etc. that may provide information helpful for identifying risks. For example, previously unknown dependencies between module development schedules in a software project. § Statement of Risk – for each risk identified, a statement of risk is captured along with the associated context for the risk. § List of Risks – contains all the statements of risk identified for the program. ChapterVIII 134
- 135. § Transform uncertaintiesand issues about the program into distinct and tangible risks that can be described and measured. § Two activities are involved: capture a statement of risk and capturing the context of the risk. Source Materials Processes Outputs Individual uncertainties Capture statement of Risk Statement of Risk Group and Team Uncertainties Capture Context of Risk List of Risks Project Data 5.1 Chapter VIIIChapter VIII135
- 136. Analyze Risks Analysis isthe process of examining the risks in detail to determine the extent of the risks, how they relate to each other, and which ones are the most important. Analyzing risks has three basic activities: 1. Evaluating attributes of risks 2. Classifying the risks 3. Prioritizing the risks The objective of the analysis phase is to convert risk data into decision making information The elements of the analysis process include: § List of Risks – the list contains all the statements of risk that need to be analyzed. § Statement of Risk – prior to analysis, the risk information for each risk contains the statement of risk and supporting context. After the analysis, values for impact, probability, timeframe, class, and rank are added to the risk information – statement of risk, supporting context – for each risk. § Classification – organizes risks into groups having some common basis. The organization may come from the predefined structure of form a self organized structure. This list is an organization of the risks according to its classification § Master List of Risks – contains all risks that have been identified and the priority ranking of the top N risks. If the impact and probability have been evaluated qualitatively using ordinal numbers, beware of performing multiplication on the ordinal scale values. The individual scale values provide information on the impact and probability of the risk. Multiplying these ordinal values to obtain risk exposure provides information that if not careful, can be misinterpreted. Classifying risks involves grouping risks based on shared characteristics. The groups or classes show relationships among the risks. Classification helps to identify duplicate risks and supports simplifying the list of risks. The objective of classifying risks is to look at a set of risks and how those risks relate to each other within a given structure. The classes or groups of risks provide a different perspective when planning risks. Prioritizing risks involves partitioning risks or groups of risks based on the Pareto "vital few" sense and ranking the risks or sets of risks based upon a criterion or set of criteria as appropriate. ChapterVIII 136
- 137. § Examine riskin detail to determine the extent of the risks and how they relate to each other § Determine which risks are important § Analyzing risks has three activities: evaluate attributes of the risk, classify the risk, and rank the risk Source Materials Processes Outputs 1 Statement of Risk Evaluate Statement of Risk 2 List of Risks Classify Classification of Risks Prioritize Master List of Risks 5.2 Chapter VIIIChapter VIII137
- 138. Risk Handling Plan Planningis the function of deciding what, if anything, should be done with a risk. Planning produces risk action plans for individual or sets of related risks. Risk are planned by those who have the knowledge, expertise, background, and resources to effectively deal with the risks. Planning answers the questions: § Is it my risk? Is it my responsibility? § What can I do? What is my approach? § How much and what should I do? What are the scope of my actions? The objectives of the planning function are to: § Make sure the consequences and sources of the risk are known. § Develop effective plans. § Plan efficiently. Only plan as much as needed or that will be beneficial. § Produce, over time, the correct set of actions that minimize risk and impacts while maximizing opportunity and value. § Plan important risks first. Project goals and constraints are the targets and limits set by the program, team, or manager. Resources available for mitigation. In order to develop effective actions plans, planners need to know the limits of the available resources for mitigating and watching risks. Master List of Risks state all the risks that have been identified and the priority ranking of the top N risks. The top N designation helps planners decide how much efforts to put into planning a particular risk or set of risks and the scope of resources that should be used for mitigation. Statement of Risk is the information associated with each risk. Before planning this includes the statement of risk, supporting context, and values for impact, probability, time frame, class, and rank. Classification is the organization of risks according to their classification. Classification shows the relationships among risks and identifies risks which could be mitigated as a set. Action Plans describe what action is to be taken to deal with the risk. ChapterVIII 138
- 139. § Make surethe consequences and sources of risk are known § Develop effective risk plans § Plan efficiently § Produce the correct set of actions that minimize risk and impacts Source Materials Processes Outputs Statement of Risk Assign responsibility Statement of risk Master List of Risks Classification of Risks Determine approach Resources Project Goals and Constraints Define scope and actions Action Plans 5.3 Chapter VIII139
- 140. Track Risk Tracking isa process in which risk data is acquired, compiled, and reported by those responsible for tracking watched and mitigated risks. The data requires in status reports are defined by program personnel during the Planning functions of the paradigm. During tracking, the data are collected and the results are complied and presented in the reports. The generated document or presentation is input to the Control function. § The objectives of the Track Functions is to collect accurate, timely, and relevant risk information and to present it in a clear and easily understood manner appropriate to the group who receives the status report. The status reports generated during the tracking function are used by program personnel during the Control function to make decisions about managing risks. § Statement of risk prior to tracking provides information for each risk, support context, impact, probability, timeframe, class, rank, and plan approach. § Action Plans describe what action will be taken to deal with the risk. Mitigation plans and tracking requirements for watched risks identify the measures, indicators, and triggers to track both the statues of the risk and the mitigation progress. § Risk and Mitigation Plan Measures consist of the current values for all watched‒risk and mitigation‒plan measures and indicators. These data can be used to determine the current status of the risk action plan and can be compiled and presented as part of a report. § Resources available for mitigation. § Project Data such as schedule and budget variances, critical path changes, and program performance indicators that can be used as triggers, thresholds, and risk or plan specific measures. § Status Reports are the output of tracking highlighting the current value of the risk indicators and the statuses of action plans. These reports can be verbal or written, covering the status of both individual risks and aggregated risk areas. ChapterVIII 140
- 141. § Collect accurate,timely, and relevant risk information § Present this information in a clear and easily understood manner appropriate to the groups receiving the status report Source Materials Processes Outputs Statement of Risk Acquire Statement of risk Action Plans Compile Status reports Risk and Mitigation Plan Measures Report Visible reporting and accountability for the management of all risks. Resources Project Data 5.4 Chapter VIII141
- 142. Risk Control Strategies Thecontrol function is a process that takes the tracking status reports for the watched and mitigates program risk and decides what to do with them based on the reported data. The general process of controlling risks includes: § Analyzing the status reports § Deciding how to proceed § Executing the decisions The objective of the Control function is to make informed, timely, and effective decision regarding risks and their mitigation plans. Status reports are used to highlight the current values of the risk indicators and the statues of action plans. Statement of Risk used prior to the Control function, defines information for each risk comprises the statement of risk, supporting context, impact, probability, timeframe, class, rank, plan approach, and status. After the Control function updates to the information associated with each risk includes the current control decisions for the risk. Project data such as schedule and budget variances, critical path changes, and program performance indicators can be used to support decision making. Decisions are the output from the Control function that determines the next action for the risk or set of risk under consideration. There are four possible decisions: § Replan § Close the risk § Invoke a contingency plan § Continue tracking and execution the current plan Statement of Risk is updated after the Control function with information associated with each risk to include current control decision for the risk. Risk control is related to standard program management monitoring techniques. These methods use program measures, such as schedule and cost metrics, for tracking, and decisions are based on the acquired data. Controlling risks is a process step that should be easily integrated and coordinated with the routine activities associated with management decision– making processes already established within the program. During risk identification and analysis, risks that are related should be grouped together for easier management. For such sets, risk and mitigation plan status data are reported as an aggregate. Project personnel use the reports generated in tracking to make informed, timely, and effective decisions regarding sets of risks and their mitigation plans. The reports are analyzed and evaluated, and decisions are made and executed. When a set of risks is being analyzed and its trigger is reached, a decision should be made whether to look at individual risks. Any specific problems should be identified and addressed as appropriate. ChapterVIII 142
- 143. § Correct fordeviations from the risk handling plans. Source Materials Processes Outputs Status reports Analyze Statement of Risk § Context § Impact § Probability § Timeframe § Classification § Rank Statement of Risk Decide Decisions § Replan § Close § Invoke contingency § Continue tracking Project Data Execute 5.4 Chapter VIII143
- 144. Communicate Risks Communication ofrisk information is often difficult because the concept of risk deals with two subjects that people don't normally communicate well: probability and negative consequences. Communication is present in all of the other functions of the SEI risk management paradigm and is essential for the management of risks within an organization. It must both fit within an organization's culture as well as expose the risks which are present in an organization's programs. The objectives of communication include: § Understand the program’s risk and mitigation alternatives § Understand the risk data and make informed choice with the constraints of the program § Eliminate the barriers to effective communication There are several ways in which risk information can be shared between personnel on a program, including both formal and informal methods of communication. The categories of risk communication include: general, management, team, and external. The core principle of the seven principles of Continuous Risk Management is open communication. Risk management communication requires § A free flow of information within and between all program levels § Formal, informal, and impromptu communication § Non–attribution and trusted use of data § Processes that value the individual voice § Consensus–based processes for teams The power of effective communication can most readily be seen when multiple viewpoints come together to form a common understanding. Successful risk communication raises the level of understanding of relevant issues or actions on a program. As a result, program personnel feel that they are adequately informed about program issues. When good communication is encouraged within an organization, it provides a solid foundation for the communication of risks within the organization's programs. For risk communication to be considered "good," it must: § Be balanced and honest § Focus on specific issues § Focus on what the audience (e.g., The customer, the program manager, etc.) Already knows § Be tailored to the specific needs of the audience § Place risks in their appropriate contexts § Contain enough specific information to describe and potentially resolve the problems facing the members of the audience § Be hierarchically organized so that people who only want a summary can find it quickly and people who want details can find them as well § Be respectful in tone and recognize that people have legitimate feelings and thoughts § Be forthright about any limitations (e.G., Data limitations) § Deal with issues of trust and reliability (e.g., data reliability) ChapterVIII 144
- 145. § Provide informationand feedback internal and external to the program on the risk activities, current risks, and emerging risks. § Communication happens throughout all the functions of risk management. Source Materials Processes Outputs Status Report Analyze Risk Understanding Task Plan § Responsibility § Goals § Tasks Decide Schedule Execute Work Breakdown Structure 5.6 Chapter VIII145
- 146. Connecting Continuous RiskManagement with Decision Making Processes An important aspect of the Decision Analysis Process is to consider and understand at what time it is appropriate or required for a decision to be made or not made. When considering a decision, it is important to ask questions such as: § Why is a decision required at this time? § For how long can a decision be delayed? § What is the impact of delaying a decision? § Is all of the necessary information available to make a decision? § Are there other key drivers or dependent factors and criteria that must be in place before a decision can be made? ChapterVIII 146
- 147. Top N RisksAssigned Responsibility Required Indicators Status / Forecast Status / Trends Risks Project Manager Connecting the Continuous Risk Management Processes 147 Technical Leads Team Members ChapterVIII
- 148. Connecting Continuous RiskManagement with Decision Making Processes ChapterVIII 148
- 149. Graded application of DeliverablesBased Planning® Each of the 5 process areas can be applied in a variety of ways depending on the complexity of the project. 149 IXApplication of Deliverables Based Planning ® Chapter
- 150.
- 151. 151 Applying Deliverables BasedPlanning® in a Graded Manner Depending on the Engagement Define the set of capabilities needed to achieve the program objectives or the particular end state for a specific scenario. Using the ConOps, define the details of who, where, and how it is to be accomplished, employed and executed. 1 Define the technical and operational requirements that must be in place for the system capabilities to be fulfilled. First, define these requirements in terms that are isolated from any implementation technical products. Only then bind the requirements with technology. 2 Build a time–phased network of schedule activities describing the work to be performed, the budgeted cost for this work, the organizational elements that produce the deliverables, and the performance measures showing this work is proceeding according to plan. 3 Execute work packages, while assuring all performance assessment are 0%/100% complete before proceeding. No rework, no forward transfer of activities to the future. Assure every requirement is traceable to work and all work is traceable to requirements. 4 Perform the 6 process areas of Continuous Risk Management for each Deliverables Based Planning® process area to Identify, Analyze, Plan, Track, Control, and Communicate programmatic and technical risk 5 Chapter IX
- 152. § Partition systemcapabilities into classes of service within operational scenarios § Connect capabilities to system requirements using sysML § Define Measures of Effectiveness (MoE) from the customer point of view § Define in the delivery schedule the achievement of each Technical Performance Measure § Define scenarios for each system capability § Connect these scenarios to a Value Stream Map of the increasing maturity of the program § Assess value flow through the map for each needed capability § Identify capabilities mismatches and make corrections to improve overall value flow § Assign costs to a system element using a value model process model § Assure risk, probabilistic cost and benefit performance attributes are defined § Use cost, schedule and technical performance probabilistic models to forecast potential risks to program performance § Make tradeoffs that connect cost, schedule, and technical performance in a single “trade space” model § Measures of Effectiveness and Measures of Performance are the raw materials for these tradeoffs Define the set of capabilities to be employed to achieve desired objectives or a particular end state for a specific scenario. Take the ConOps and define the details of who, where, and how it is to be accomplished, employed and executed. 1.0 1.1 1.2 1.3 1.4 Chapter IV152 Chapter IX
- 153. 153 Level 1 Minimal Implementation Level 2 MinorImplementation Level 3 Major Implementation Level 4 Full Implementation with Earned Value Management Define Operation Concepts and Capabilities Construct a short narrative of what the system is supposed to do – treat this as the elevator pitch for the project – short, to the point, with defined outcomes and benefits Define the needed capabilities in a form that matches the business case and the wording of the business sponsors. Provide traceability to need in some hierarchy. Develop the Concept of Operations with a UML or IDEF0 diagram. Using this to map capabilities to requirements to the implementation process in IDEF0 Provide a full WBS narrative, IMP narrative, and Work Package narratives. Ensure traceability between these three is maintained in change control. Define Capabilities through Scenarios or Use Cases Identify the nouns and verbs of the work processes. Define the details of each noun and verb so they can be recognized when the work process completes Develop Use Cases for the top level capabilities, identify the Actors and their relationships with the Use Cases Identify the tangible outcomes for each Use Case and the “stories” or operational concepts that have measureable results. Assess Needs, Costs, and Risks of the Capability Simultaneously Assign costs and values to each element. Total these to match the top level budget Use the WBS to capture costs for the work needed to produce each deliverable. Produce a resource loaded schedule, with resource categories, costs, availability, and performance measures for each work effort Develop a Control Account Plan for each collection of funding. Define the risk and monetize those risks. Define the labor spreads for all work. Define Explicit, Balanced, and Feasible Alternatives Determine redundancies and any missing elements. Have a plan to deal with the risk when they become issues. Define the “trade space” for all the elements that are needed to make decisions. Produce a tradeoff model for the risk based decisions with the forecast of impacts if the risk were to become and issue. Chapter IX
- 154. Define the technicaland operational requirements that must be in place for the system capabilities to be fulfilled. Define these requirements in terms isolated from any implementation. 2.0 § Produce an overall statement of the problem in an operational context. § Develop the overall operational and technical objectives of the target system. § Defined the boundaries and interfaces of the target system. 2.1 § Gather required system capabilities, functional, nonfunctional and environmental requirements, and design constraints. § Build a Top Down Capabilities and Functional decomposition of the requirements in a flow down tree using a Requirements Management System. 2.2 § Answer the question “why do I need this?” in terms of operational benefits. § Build a cost benefit / model using probabilistic assessment of all variables and dependencies. § For technical requirements, perform a risk assessment to cost and schedule. 2.3 § Determine criticality for the functions for the system mission. § Determine trade off relationships for all requirements to be used when option decisions are made. § For technical items prioritize on cost and dependency. 2.4 § Address completeness of requirements by removing all “TBD” items. § Validate the requirements agree and are traceable to system capabilities, goals, and mission. § Resolve any requirements inconsistencies and conflicts. 2.5 Chapter V154 Chapter IX
- 155. 155 Level 1 Minimal Implementation Level 2 MinorImplementation Level 3 Major Implementation Level 4 Full Implementation with Earned Value Management Perform Fact Finding Create a simple list of the requirements. Manage requirements in a way that cross references can be made between the requirements. Assess the coverage of the requirements between needed capabilities and the implementation processes. Use a requirements management tool to provide traceability from requirements to the IMS. Gather and Classify Requirements Partition the requirements into few major categories. Make further partitions to reveal coupling and cohesion of the requirements. Further partition the requirement to reveal conflicts and undesirable dependencies. Use a requirements management tool to control requirements and map them to the IMS and assure MECE. Evaluate and Rationalize Requirements Confirm with the stakeholders these requirements are needed. Assign requirements to some form of a system and program architecture. Apply a formal architectural assessment process for each requirement. Manage all requirements under formal change controls with the proper participants on the Change Board. Prioritize Requirements Prioritize requirements and gain agreement. Assign some form of business value to each requirement and assess its impact on project performance. Connect requirements with Capabilities and monetize these with the business case. Rank them with paired- comparison analysis or Borda ranking and manage this priority under change control. Integrate and Validate Requirements Re-confirm need with stakeholders. Connect the requirements confirmation with cost and schedule confirmation. Manage requirements using a resource loaded integrated master schedule and continual architectural assessment. Manage all requirements through a formal change control process to maintain baselined business value. Chapter IX
- 156. Build a time–phasednetwork of schedule activities describing the work to be performed, the budgeted cost for this work, the organizational elements that produce the deliverables, and the performance measures showing this work is proceeding according to plan. 3.0 Decompose the Project Scope into a product based Work Breakdown Structure (WBS), then further into Work Packages describing the production of all deliverables traceable to the requirements 3.1 Assign Responsibility to Work Packages (the groupings of deliverables) for the named owner accountable for the management of resource allocation and cost baseline and technical delivery 3.2 Arrange the Work Packages in a well formed network with defined deliverables, milestones, internal and external dependencies, appropriate schedule and cost margin. 3.3 Develop a Time–Phased Budgeted Cost for Work Scheduled (BCWS) from labor and material costs in each Work Package and the Project as a whole. Assure proper resource allocations can be met and budget profiles match expectations of the program sponsor 3.4 Assign objective Measures of Performance (MOP) and Measures of Effectiveness (MOE) for each Work Package and summarize these for the Project as a whole 3.5 Establish a Performance Measurement Baseline (PMB) used to forecast Work Package and Project ongoing and completion cost and schedule metrics 3.6 Chapter VI156 Chapter IX
- 157. 157 Level 1 Minimal Implementation Level 2 MinorImplementation Level 3 Major Implementation Level 4 Full Implementation with Earned Value Management Decompose Scope into Work Packages A list of outcomes for the project. Further decompose work into separate measureable deliverables with units of measure for performance. Create an IMS with multiple products based on the maturity of the incremental deliverables. Define the deliverables through the IMP/IMS with coding in the IMS for each deliverable. Assign Responsibility for Deliverables Assign names accountable for delivery. Build a formal Responsibility Assignment Matrix (RAM) for the major deliverables. Further decompose the RAM with management, budget, and resource assignment. Assign resources to each task in the Work Package Arrange Work Packages in Logical Order Layout a schedule for these deliverables. Further define the dependencies between the work packages and their products. Assure resource availability and utilization to provide a credible IMS. Develop a full IMP / IMS with resource loaded tasks in Work Packages. Develop BCWS for Work Packages Assign budget portion to each deliverable. Apply to budget to RAM. Assure the BCWS is credible for the planned. Flow budgets to the Work Packages and hours to the Tasks Assign WP Measures of Performance Determine how performance will be measured. Further decompose the major deliverables and assign the performance. Define Measures of Effectiveness (MoE) and Measures of Performance (MoP) for all deliverables. Using the System Description and Work Instructions assign performance measures. Set Performance Measurement Baseline Set the baseline in the scheduling tool at the project level. Set the baseline in the scheduling tool at the work package Time phase the baseline into actual work and planning packages in a time phased PMB. Set the baseline in the EV Engine and control it through defined processes. Chapter IX
- 158. Execute work packages,while assuring all performance assessment are 0%/100% complete before proceeding. No rework, no forward transfer of activities or features. Assure every requirement is traceable to work and all work is traceable to requirements. 4.0 § Using the Work Package sequencing, release work to be performed as planned § With the RACI based RAM, the Accountable delivery manager guides the development of the products or services for each Work Package 4.1 § Using Physical Percent Complete or Apportioned Milestones capture measures of progress to plan for each Work Package § Report this Physical Percent Complete in a centralized database for each Work Package and the program as a whole 4.2 § Compare the Physical Percent Complete against the Planned Percent Complete for each period of performance § Construct cost and schedule performance indices from this information and the Physical Percent complete measures 4.3 § With the Cost and Schedule performance indices, construct a forecast of future performance of cost, schedule, and technical performance compliance efforts § Take management actions for any Work Packages not performing as planned 4.4 § Record past performance based on Work Package completion criteria § Record past future forecast performance estimates in a historical database § Forecast next future performance against the Performance Measurements Baseline § Report this next future performance estimate to the program stakeholders 4.5 Chapter VII158 Chapter IX
- 159. 159 Level 1 Minimal Implementation Level 2 MinorImplementation Level 3 Major Implementation Level 4 Full Implementation with Earned Value Management Perform the Authorized Work Perform the work according to the schedule. Assess the impact of “out of order” work on the schedule and cost. Apply change control to maintain the order of planned work. Perform the work as planned at the Work Package level through a WAD. Accumulate and Report Work Package Performance Record the actual costs at the project level. Maintain budget performance at the cumulative work package level. Integrate cost and schedule in a time phased manner. Record actual costs at the Task and Work Package level. Analyze Work Package Performance Examine the cost and schedule performance at the project. Examine the cost and schedule performance at the work package. Make forecasts of future performance based on this analysis. For each Work Package and the Tasks inside the WP, using physical percent complete. Take Corrective Management Action Take managerial action at the project level. Take managerial action at the work package level. Take proactive management action based on past performance to “get back to GREEN.” Continual management actions to keep the project GREEN. Maintain the Performance Baseline Project Manager maintains overall cost and schedule baseline. Project Manager maintains overall cost and schedule at the work package level. Maintain the project using change control at a program level. Maintain the PMB with full Change Control (CCB). Chapter IX
- 160. Execute work packages,while assuring all performance assessment are 0%/100% complete before proceeding. No rework, no forward transfer of activities or features. Assure every requirement is traceable to work and all work is traceable to requirements. 5.0 § Identify risks through a risk elicitation process from subject matter experts 5.1 § Convert risk data in risk decision making information5.2 § Turn risk decision information into action plans § This plans can be: mitigations, avoidance, acceptance, or transfers 5.3 § Monitor status § Monitor actions 5.4 5.5 Chapter VII160 Chapter IX § Using risk handling processes, take corrective actions to eliminate, response, or reduce risk impacts to cost, schedule, and technical performance of the project’s deliverables.
- 161. 161 Level 1 Baseline Implementation Level 2 MinorImplementation Level 3 Major Implementation Level 4 Full Implementation with Earned Value Management Identify Risk Development is list of risks and review them during the normal project performance reviews. Development is list of risks at the work package and review them during the project performance reviews. Apply a risk management tool to risks starting at the work package assigned to the deliverable. Connect risks to the “risk retirement” or “risk handling” activities in the IMS. Analyze Risks Determine impact of each risk on the over all project outcome and provide some handling strategy. Determine impact of each risk at the work package level on the outcome and provide one of the 4 handling strategies. Analyze and prioritize risks and document them in the risk management tool. Define the “risk buy down” strategy connected to the baselined IMS. Plan Risk Handling Processes Establish an inform risk response process for each identified risk in the project. Project Management guides the risk handling process. Using the risk management tool, execute the defined risk handling process at the approved time. Using a formal risk management board participate in the formal change control process. Track Risk Handling Report risk activities periodically. Monitor risks to determine potential impact on the project. Using the risk tool perform continuous risk management. Track individual risks through the risk register to the cost and schedule impacts of the current risk handling strategy. Control Risks Deal with risks when they become issues. Perform minor handling processes to address emerging risks. Performance major handling processes to address emerging risks. “Buy down” each risk in the IMS with planned budget and schedule. Chapter IX
- 162.
- 163. The tools usedduring the application of Deliverables Based Planning® and the artifacts generated by those tools enhance the ability of the program team to have visibility into the performance of each of the five process areas. 163 XTools and Artifacts Chapter
- 164. Documents needed tomanage a project Project Management is a VERB. Project Managers "manage" projects. No matter what anyone tries to tell us, projects don't manage themselves. There are many styles of project management. Even some where the role of the project manager is distributed - self directed teams for example. But in the end projects are human activities that require some form of bound Along the way there are many questions that needed to be answered. Here a short listed guidance. Each answer can be a document (and is a document on any non-trivial project). The contents of the answer can vary depending on the complexity of the project. From some notes on the White Board to 100's of pages of detailed narrative and diagrams, to a multi-million dollar ERP system containing the data for the program. But in the end if you don't have some grip on the answer - in a way that can be produced when someone asks the question in the right column with some artifact in the left column, you're headed for the ditch and may not even know it. So when we hear about all the failures of projects, especially in IT, let's ask of those failed projects had answers to these questions before concluding that the project management approach was flawed and needs to be replaced with an even more flawed project management approach. 164 ChapterX
- 165. Documents needed tomanage a project 165 Fundamental PM Questions The answer is found in the ... What have we been asked to do? Statement of Work When are we supposed to do this work? Integrated Master Schedule How much money do we have to do this work? Contract Budget Base How do we know we’re making progress? Earned Value What can go wrong? Risk Management Plan What does the future look like? To Complete Performance Index Who is doing what during the project? Responsibility Assignment Matrix How is the money allocated to the work? Control Account Plan Who is accountable for the delivery of products? Control Account Manager How do we know how much it will cost? Estimate At Completion Are we delivering what we said we would? Technical Performance Index ChapterX
- 166. Deliverables Based Planning® Products DeliverablesBase Planning® produces tangible documents that are evidence of the methods application. These documents are in addition the contractual and program documents normally found in a large complex systems development effort. The documents and evidence to the right are some examples of the evidentiary materials produced during the program that show increasing maturity of the products or services. These alone are not measures of progress, but are the supporting materials for measures of progress. In the end working product or services are the evidence to the customer of progress to plan. Each of products are part of a larger set of deliverables needed to provide visibility to the performance of the project. These deliverables documents start with the Statement of Work (SOW). This SOW describes the deliverables from the project. It contains what is says the “statement of the work.” This work produces the elements of the Work Breakdown Structure (WBS). The WBS is a bit of a misnomer. It should be called the Product Breakdown Structure (PDS). The components of the deliverables are decomposed in the WBS. The terminal nodes of the WBS describe the individual deliverables produced by the Work Packages (WP). From the WBS, Work Packages are defined with their budget (BCWS). This BCWS represents both direct labor and the material cost for the work being performed by the Work Package. There is are more complexities than this simple approach. For example the “rating” of the labor hours to include the “rap rate.” With the Performance Measurement Baseline in place, the execution of the can start. Each Work Package has a performance measurement – the best is measures of physical percent complete. This is a measure of some tangible evidence of completion of the planned deliverable, at the planned time for that deliverable for the planned cost. There are supporting documents listed here, with details of the format and use in later pages of this handbook. Each of these documents supports the visibility into the project’s performance measurement, risk management, and forecasts of future performance. 166 ChapterX Deliverables Based Planning ® is a registered trademark of Lewis & Fowler. Copyright ® Lewis & Fowler, 2011
- 167. Identify Needed System Capabilities EstablishRequirements Baseline Establish Performance Measurement Baseline Execute Performance Measurement Baseline DefineOperationalConcepts DefineCapabilitiesto ImplementConcepts Assessneeds,costs,andrisk simultaneously Defineexplicit,balanced, andfeasiblealternatives PerformFactFinding GatherandClassify Requirements EvaluateandRationalize Requirements PrioritizeRequirements IntegrateandValidate Requirements DecomposeScope AssignResponsibilities ArrangeWorkPackages DevelopBCWS AssignPerformance Measures SetPerformance ManagementBaseline PerformAuthorizedWork AccumulateandReport WorkPackagePerformance AnalyzeWorkPackage Performance TakeCorrective ManagementActions MaintainPerformance MeasurementBaseline Statement of Work (SOW) Statement of Objectives (SOO) Concept of Operations (ConOps) Process Flow Diagram (PFD) Work Breakdown Structure (WBS) Performance Measurement Baseline Requirements Traceability Matrix CDRLs, DIDs EACT (IMP/IMS elements) Labor and Cost Spreads Business Rhythm Process Flow Design Structure Matrix (DSM) Measures of Performance (MoP) Measures of Effectiveness (MoE) Scenario Based Descriptions Responsibility Assignment Matrix (RAM) Work Package Roadmap Work Authorization Log Chapter VIChapter X167
- 168. Hierarchy of DeliverablesBased Planning® Deliverables Based Planning® is structured around a hierarchy that describes the deliverables that enable the system capabilities to be produced and assessed against their planned maturity. This hierarchy provides the framework for organizing the planning and execution of the program in a straight forward manner. By decomposing the program architecture in this way, traceability from the capabilities, to the requirements, to the work efforts that deliver those requirements is made visible and assessable. The result is the ability to measure Physical Percent Complete for all work activities along with the Technical Performance Measures that describe the current maturity of all deliverables. Building, deploying, and executing an IMP / IMS requires a change in the conventional paradigm of program planning and management. This change starts by measuring progress as the completion of Accomplishment Criteria and the fulfillment of Significant Accomplishments. This progress is described as physical percent complete rather than measuring progress through the passage of time and consumption of resources. The Events / Milestones must represent maturity assessment points in the program, not just a meeting scheduled in the future. These maturity assessments review the progress to date, through the completion of Accomplishments, their Criteria, and the work performed to produce them. The Accomplishments represent to completion of a deliverable to the planned level of maturity. This might be “preliminary,” or “initial,” or “initial operating capability,” or “final operating capability.” In all cases the measures of maturity as well as the technical performance for this maturity is predefined. The Criteria for confirming the work effort has achieved the needed level of maturity or the needed Technical Performance levels is also predefined. This change means planning Vertically for each Program Event, through Work Packages to their Accomplishment Criteria, to the Significant Accomplishments, to the Program Event. Only then, can planning take place Horizontally for the dependencies between Program Events. As well a change takes place in conventional approach to Program Events. These Program Events are more than milestones. They are maturity assessments, where pre–defined deliverables are assessed to assure Technical Performance is being met against the pre–defined metrics. As well that the pre– defined levels of risk are being retired or mitigated as planned. All these changes mean defining the technical and programmatic performance measures for the critical Accomplishment Criteria (AC) describes what “done” looks like prior to starting the work. ChapterX 168 Deliverables Based Planning ® is a registered trademark of Lewis & Fowler. Copyright ® Lewis & Fowler, 2011
- 169. Hierarchy of DeliverablesBased Planning® IMS IMP Describes how the capabilities will be delivered and how these capabilities will be recognized Supplemental Schedules Work Packages and Tasks Criteria Accomplishment Events Milestones ChapterX 169
- 170. DBP® Execution Framework The operationalprincipals of Deliverables Based Planning® live within an execution framework, starting with the Request for Proposal and continuing through Program Execution. This framework describes the interaction between the deliverables of the method and the execution of the program. Each of these activities is interrelated in some way. Starting with the Request for Proposal and Statement of Work, for each Event or Milestone, a set of deliverables and their maturity is defined. The units of measure for the maturity is defined in a meaningful way for the customer. This allows the customer to recognize and acknowledge the progress has been made. The Technical Performance Measures (TPM) describe the technical aspects of the deliverables at each point in the increasing maturity assessment process. Meeting or not meeting these Technical Performance Measures provides insight into the physical percent complete of the work effort performed to date. In addition to the TPM there are Measures of Effectiveness (MoE) and Measures of Performance (MoP). These are Systems Engineering measures that describe customer The development of the Basis of Estimate and any “Cost as an Independent Variable” analysis is attached to each deliverable and the supporting Accomplishments and Criteria. From the Earned Value measures and the associated Technical Performance Measures, a forecast of future performance can be derived. This Physical Percent Complete measure is used to produce the BCWP for the program. For both the cost and schedule, a probabilistic risk analysis must be performed to develop a confidence level for the Estimate At Completion and the Probability of Completing on or before the planned date. ChapterX 170 Deliverables Based Planning ® is a registered trademark of Lewis & Fowler. Copyright ® Lewis & Fowler, 2011
- 171. DBP® Execution Framework Program ExecutionPMBfor IBRProposal SubmittalDRFP & RFP Performance Measurement Baseline Tasks (T) BOE % Complete Statement of Work Program Deliverables IMP Accomplishments (A) Criteria (C) EVMS Events (E) Budget Spreads by CA & WPCAIV Capabilities Based Requirements X BCWS = Probabilistic Risk Analysis = Time keeping and ODC = Technical Performance Measure BCWP ACWP Cost & Schedule Risk Model BCWS Decreasing technical and programmatic risk using Risk Management Methods IMS Physical % Complete Continuity and consistency from DRFP through Program Execution ChapterX 171 Deliverables Based Planning ® is a registered trademark of Lewis & Fowler. Copyright ® Lewis & Fowler, 2011
- 172. Dependency (Design) StructureMatrix A design structure matrix lists all constituent subsystems / activities and the corresponding information exchange and dependency patterns. In other words, it details what pieces of information are needed to start a particular activity, and shows where the information generated by that activity leads. In this way, one can quickly recognize which other tasks are reliant upon information outputs generated by each activity. A Dependency (Design) Structure Matrix (DSM)* is a compact, matrix representation of a system (i.e. program, product architecture, organization structure, etc.). § System elements names are placed down the side of the matrix in row headings and also in across the top of matrix in column headings in the same order § Conceptual Level Interactions are identified by 1, 0, or X in intersecting cells § Detail description of interactions can be identified by their names of inputs and outputs § Diagonal elements do not have meaning The dependencies between the elements of the DSM are the key to success on any complex system management domain. These dependencies provide “information driven planning” through feedback loops that are inherent in any program. These Relationships (Feed Forward and Feedback) can be defined by the Information Flow Between Them. § Communications Regarding Product/Data Exchanges § Lessons‒Learned § Test Results Feedback to Design § Technical Review Updates to Design/Build The benefits of DSM include the ability to use information flow to derive predecessor / successor logic. This: § Improves ability to establish credible logic on complex programs § Improves ability to integrate tasks that constrain tasks of other teams (interface management) DSM creates a view that depicts the derived work sequence including loops. This allows better understanding of iterations and development cycles. This view that depicts the derived task sequence including tasks that are parallel and serial. This is useful for optimizing the logic flow (shortening the schedule). ChapterX 172
- 173. Dependency (Design) StructureMatrix Prepare Create Prepared Perform Create Prepare Develop Perform Perform Develop Establish Evaluate Preliminary Prepare Model Input for Unmanned Autonomous Vehicle 1 2 3 4 5 6 7 8 9 10 11 12 13 14 Prepare UAV Preliminary DR&O 1 Create UAV Preliminary Design Configuration 2 1 1 Prepared Surfaced Models and Drawings 3 1 Perform Aerodynamics Analysis 4 1 1 Create Internal Structural Geometry 5 1 1 1 1 2 1 Prepare Structural Geometry and Notes 6 1 2 Develop Structural Design Conditions 7 1 2 Perform Weights & Inertias Analysis 8 1 1 Perform S&C Analysis 9 1 1 1 Develop Free Body Diagrams 10 1 1 1 1 Establish Internal Load Distributions 11 1 1 1 2 Evaluate Structural Strength, Stiffness 12 1 1 1 2 2 Preliminary Manufacturing Planning 13 1 1 1 Prepare UAV Proposal 14 1 1 1 1 1 1 1 1 1 1 1 1 1 ChapterX 173
- 174. Assign The Responsibilitiesto make a Single Person Accountable Accountability is assigned to a single person for each Work Package – which can include one or more deliverables. The Work Package Manager has stated clearly and concisely who, what, when, where, why, and how the work will be performed by the members of the Work Package team. There are several formats for defining work packages. At a minimum the Work Package must contain the items shown in the next slide. It is important though to not confuse the Principle of Work Package development with the Practice of Work Package development. The principles include defining the contents – as described in the previous slides. But the practice must allow for the adoption of how this information is captured. It can be in a formal document, with tables, descriptions of the details, and a high ceremony sign–off process. Or it can be an Excel file with all the necessary information in rows of a table. Either way the contents are what is important. Do not confuse form over function – it is the function that adds value. The RACI approach is useful for the overall project, but for the purposes of building the PMB, only the Accountable person is needed. All other elements of the RACI flow from the accountability. When the baseline project schedule is complete a RACI can be derived from the MSFT Project file through field coding. § Responsible – These positions do the work necessary to accomplish the process. § Accountable – This is the ONE position responsible for accomplishing the process. There can only be one accountable position for each process. However, the Accountable position can serve multiple roles. § Consulted – These positions provide information as needed to complete the process. § Informed – These positions are provided information resulting from the execution of the process. 174 ChapterX
- 175. Assign The Responsibilitiesto make a Single Person Accountable 175 ChapterX
- 176. Project Maturity Flowis the Incremental Delivery of Business Capabilities on the Planned Date Integrating multiple work streams at the highest level makes visible the increasing maturity of the project. The picture shown to the right should be built as the first overview of the project. This is the road map for the program – the program architecture. This map should be developed “first” but in many cases it is not possible, since it is not well understood how all the pieces of the project come together. In either case there are benefits that are provided for this approach: The business value flow is made visible. When a business capability is available, it should be put to use in support of the business case. If the nodes of the flow graph – the nodes where business capabilities join – provide a capability, then that capability can be put into production is some way. The assessment of the business value producing processes can then show how the project can incrementally deliver this business value. If such a picture can not be constructed – until the entire project is complete – then the is serious risk to the business case and the completion of the project for several reasons: Any non‒compliance with the business case will not be discovered until the end Physical percent complete will not likely be measurable during the project – only the consumption of resources and the passage of time, resulting is an increasing risk that the actual completion date and cost are being hidden in the “level of effort” measurement process The concept of connecting incremental delivery of value with the business case and the measurement of Physical Percent Complete closes the loop that generates the answer to the question – where are we, how much will this cost, and when will we be done? This can be answered in a straight forward manner: Where are we on the plan? The Work Package performance is measured through Physical Percent Complete, either through a 0%/100% assessment or an apportioned milestone assessment. What value is each Work Package? Look at the Business Value Flow Map and assign the value of completed Work Packages to the associated Business Value from the Business Case that results for the useable capabilities. 176 ChapterX
- 177. Project Maturity Flowis the Incremental Delivery of Business Capabilities on the Planned Date Pilot Data Enrollment Integrators Quality Monitor Internal Router Data Store Lookup Data Warehouse Data Marts Data Marts Portals and others Billing Demo conversion process, member reconciliation Shared group matrix reports and interfaces Shared member crosswalk and members to ERP Integrators in ERP converted to inventory Status and trigger conversions Data in Marts for ERP Material Master Converted from legacy External Interfaces External Vendors converted to ERP Finance Loss TBD Resale's Vendors from legacy Emulations Material converted end– to–end 177 ChapterX
- 178. Program Accomplishment Flow EachAccomplishment provides the needed elements of a planned capability. The flow of these Accomplishments describes the increasing maturity of the Program through the deliverables. This example shows how the program moves from Contract Award through the review cycles into the production of products and services meaningful to the customer. The example to the right shows how these Accomplishments are sequenced to show increasing maturity. The dependencies, inputs, and outputs of these Accomplishments describe the top level flow of the programmatic activities. When speaking to the increasing maturity of the program, we need to use the right semantics. The wording in the next picture is an approach for this wording. For each Program Event, Significant Accomplishment, and Accomplishment Criteria a past tense verb is needed. This approach is unsettling at first. But once put into practice it changes how work is discussed and progress is measured. The content of the programmatic elements (Milestone/Event, Accomplishment, Criteria) makes use of a sentence ending in a past tense verb. There are a limited number of these verbs of most Master Plans. They defined the state of the product or service that results from the activities that compose the Accomplishment Criteria – the tasks of the Master Schedule. learning to speak in the past tense of the basis of the Master Plan. Describing what “done” looks like requires a past tense verb be connected with “done.” The “sentence” of the adjective, noun, verbs describe “done” in units of measure meaningful to the decision makers. ChapterX 178
- 179.
- 180. IDEFÆ Diagrams The IDEFÆFunctional Modeling method is designed to model the decisions, actions, and activities of an organization or system.[2] It was derived from the established graphic modeling language Structured Analysis and Design Technique (SADT) developed by Douglas T. Ross and SofTech, Inc.. In its original form, IDEFÆ includes both a definition of a graphical modeling language (syntax and semantics) and a description of a comprehensive methodology for developing models.[3] The US Air Force commissioned the SADT developers "to develop a function model method for analyzing and communicating the functional perspective of a system. IDEFÆ should assist in organizing system analysis and promote effective communication between the analyst and the customer through simplified graphical devices".[2] Where the Functional flow block diagram is used to show the functional flow of a product, IDEFÆ is used to show data flow, system control, and the functional flow of life cycle processes. IDEFÆ is capable of graphically representing a wide variety of business, manufacturing and other types of enterprise operations to any level of detail. It provides rigorous and precise description, and promotes consistency of usage and interpretation. It is well-tested and proven through many years of use by government and private industry. It can be generated by a variety of computer graphics tools. Numerous commercial products specifically support development and analysis of IDEFÆ diagrams and models. An associated technique, Integration Definition for Information Modeling (IDEF1x), is used to supplement IDEFÆ for data intensive systems. The IDEFÆ standard, Federal Information Processing Standards Publication 183 (FIPS 183), and the IDEF1x standard (FIPS 184) are maintained by the National Institute of Standards and Technology (NIST). IDEFÆ may be used to model a wide variety of automated and non-automated systems. For new systems, it may be used first to define the requirements and specify the functions, and then to design an implementation that meets the requirements and performs the functions. For existing systems, IDEFÆ can be used to analyze the functions the system performs and to record the mechanisms (means) by which these are done. The result of applying IDEFÆ to a system is a model that consists of a hierarchical series of diagrams, text, and glossary cross- referenced to each other. The two primary modeling components are functions (represented on a diagram by boxes) and the data and objects that inter-relate those functions (represented by arrows). 180 ChapterX
- 181. IDEFÆ Diagrams 181 NODE: TITLE:NUMBER: MANAGE TIME A3 A3.1 DEFINE PROJECT ACTIVITIES A3.2 SEQUENCE PROJECT ACTIVITIES A3.3 ESTIMATE PROJECT ACTIVITIES DURATIONS A3.4 DEVELOP PROJECT SCHEDULE A3.5 PERFORM PROJECT SCHEDULE CONTROL workbreakdown structure scope statement historical information assumptions constraints workbreakdown structure updates activity list supporting detail project network diagram activity list updates resourcecapabilities resourcerequirements basis of estimates calendars activity duration estimates leads & lags project schedule schedule management plan resourcerequirement updates schedule updates correctiveaction lessonslearned change requests performance reports resourcepool description mandatorydependencies discretionarydependencies constraints productdescription schedule change control system performance measurement additional planning project management software simulation expert judgement analogous estimating mathematical analysis duration compression resourceleveling heuristics arrow diagramming method (ADM) conditional diagramming methods network templates precedence diagramming method (PDM) decomposition templates external dependencies ChapterX
- 182. IMP / IMSOverview The connections between the Statement of Work, WBS/CWBS, the IMP, the IMS, and the Basis of Estimate flow in a specific manner. Maintaining this logical flow is critical to the success of the program starting with the proposal and continuing throughout its life cycle. Statement of Work (SOW) describes the mission requirements, technical requirements, and dependencies and constraints. Contract Work Breakdown Structure (CWBS) identifies the work effort needed to produce the deliverables that fulfill the SOW. Integrated Master Plan (IMP) is an Event Driven strategy for the entire program. The IMP has Product and Process sections. The IMP contains Program Events (PE), Significant Accomplishments (SA), and Accomplishment Criteria (AC). § Program Events are the initiation or conclusion of an interval of major program activity. Provide decision‒points relating system maturity with continued system development . Provide at least some of the program key events are usually specified in RFP § SA are specified results, substantiating an event, that indicate a level of design maturity (or progress) for each product/process. SA are generally a discrete step in the progress of the planned development. These accomplishments demonstrates that the design and production of products are successfully maturing. § ACs are definitive measure(s) substantiating the maturity level of the significant accomplishment. These criteria are the completion of specified work that ensures closure of a specified "Significant Accomplishment“ The Integrated Master Schedule (MS) is and integrated, networked, multi‒layer schedule of activities necessary to achieve contract objectives which contains: detailed tasks to be completed , a network schedule (dependent tasks are linked) , the critical path, and the analysis needed to assure work will be completed on time, on budget and on specification. The Basis of Estimate (BOE) is derived from a resource loaded Integrated Master Schedule, confirmed by past performance and verified by Subject Matter Experts (SME). ChapterX 182
- 183. IMP / IMSOverview ChapterX 183
- 184. Requirements Framework Business requirementsare statements of the business rationale for the project. These requirements grow out of the vision for the product which, in turn, is driven by mission (or business) goals and objectives. The product’s vision statement articulates a long-term view of what the product will accomplish for its users. It should include a statement of scope to clarify which capabilities are and are not to be provided by the product. [Gottesdiener] Putting all this information into a framework is next. We’ll do this in preparation for our exercise that’s coming up. User requirements define the software requirements from the user’s point of view, describing the tasks users need to accomplish with the product and the quality requirements of the software from the user’s point of view. Users can be broadly defined to include not only the people who access the system but also inanimate users such as hardware devices, databases, and other systems. In the systems produced by most government organizations, user requirements are articulated in their concept of operations document. This framework is one of many, but it’s simple, and even useful for our current needs and the future needs as well. This framework does several things: 1. It uses the separation of product and process that was shown earlier. 2. It asks 5 of the 6 question in Rudyard Kipling “Six Honest Serving Men” from “The Elephants Child.” “Where” is missing, but we know where – we are at the location where we are gathering requirements for our systems. 3. It demonstrates the layering of the requirements and their evolutionary nature. 4. It shows some of the techniques for managing these requirements. Each requirements model represents information at a different level of abstraction. A model such as a state diagram represents information at a high level of abstraction, whereas detailed textual requirements represent a low level of abstraction. By stepping back from the trees (textual requirements) to look at the forest (a state diagram), the team can discover requirements defects not evident when reviewing textual requirements alone. Because the requirements models are related, developing one model often leads to deriving another. Examples of one model driving another model are the following: § Actors initiate use cases. § Scenarios exemplify instances of use cases. § A use case acts upon data depicted in the data model. § A use case is governed by business rules. § Events trigger use cases. 184 ChapterX
- 185. Stakeholder Categories Actor Table Prototypes Dialog Hierarchies Personas Glossary Context Diagram DataModel Class Model Data Dictionary Data Tables Event Response Table State Diagrams State Data Matrix Business Policies Business Rules Decision Tables Decision Trees Process Map Use Cases Scenarios, Stories, Activity Diagrams, Data Flow Diagrams Scope High Level Detailed Alternatives “Good Practices for Developing User Requirements,” Ellen Gottesdiener, CrossTalk, 3/08, www.stsc.hill.af.mil185 Chapter X
- 186. DoD Risk ManagementFramework There are many Risk Management frameworks. The Department of Defense framework described in the Risk Management Guide for DOD Acquisition, is the standard for all complex programs. All other frameworks leave out process details and create more risk than they remove. Risk is a measure of future uncertainties in achieving program performance goals and objectives within defined cost, schedule and performance constraints. Risk can be associated with all aspects of a program (e.g., threat, technology maturity, supplier capability, design maturation, performance against plan,) as these aspects relate across the Work Breakdown Structure (WBS) and Integrated Master Schedule (IMS). Risk addresses the potential variation in the planned approach and its expected outcome. While such variation could include positive as well as negative effects, this guide will only address negative future effects since programs have typically experienced difficulty in this area during the acquisition process. Risk Management – is a continuous process that is accomplished throughout the life cycle of a system. It is an organized methodology for continuously identifying and measuring the unknowns; developing mitigation options; selecting, planning, and implementing appropriate risk mitigations; and tracking the implementation to ensure successful risk reduction. Effective risk management depends on risk management planning; early identification and analyses of risks; early implementation of corrective actions; continuous monitoring and reassessment; and communication, documentation, and coordination. Risk Planning – is the process of developing and documenting an organized, comprehensive, and interactive strategy and methods for identifying and tracking risk areas, developing risk handling plans, performing continuous risk assessments to determine how risks have changed, and assigning adequate resources. Risk Assessment – is the process of identifying and analyzing program areas and critical technical process risks to increase the probability / likelihood of meeting cost, schedule, and performance objectives. Risk Handling – is the process that identifies, evaluates, selects, and implements options in order to set risk at acceptable levels given program constraints and objectives. Risk Monitoring – is the process that systematically tracks and evaluates the performance of risk–handling actions against established metrics throughout the acquisition process and develops further risk–handling options, as appropriate. ChapterX 186
- 187. DoD Risk ManagementFramework ChapterX 187
- 188. From each WBSelement define a Work Package containing tasks for each deliverable From the terminal nodes of the WBS, Work Packages can be defined. Each Work Package contains a list of activities that produce the deliverables. These activities can be simple or complex depending on the deliverables. In all cases, these activities are NOT part of the resulting schedule for the Project Level plan. This is a critical concept for the success of a Deliverables Based Planning process. 1. Once the Work Package deliverables have been defined, the activities to produce those deliverables planned and the labor assigned with the resulting BCWS, the actual execution of the work is the responsibility of the Work Package Manager – the person accountable for successfully delivering the outcome of the Work Package. 2. Defining the detailed activities in the baselined plan adds little value and creates a change control burden. This doe not mean these activities are not carefully defined, managed and adapted to emerging needs. The Work Package Manager does this in a secondary plan. This plan can range from a simple list of work to a complex schedule. 3. The Apportioned Milestones defined in the Work Package become part of this planning process and are the anchor of any detailed scheduling by the Work Package Manager. 4. All deliverables are defined in the Work Package documentation. These deliverables can be exposed in the master schedule or held in the Work Package documentation. This needs to be determined by the project manager . Both approach are valid. Placing them in the Master Plan makes more visible. 188 Do Not construct a WBS of the Functional Activities like Design, Code, Test. These are not deliverables of the project. The business value they produce are the deliverables – place these in the WBS. Once the Product Focused WBS has been developed, Work Packages can be defined that contain the Deliverables described in the WBS. Each Work Package contains the activities, resources, efforts, earned value measurement, dependencies, and assumptions. ChapterX
- 189. From each WBSelement define a Work Package containing tasks for each deliverable Business Need Process Invoices for Top Tier Suppliers 1st Level Electronic Invoice Submittal 1st Level Routing to Payables Department 2nd Level Payables Account Verification 2nd Level Payment Scheduling 2nd Level Material receipt verification 2nd Level “On hand” balance Updates Deliverables defined in WP 189 ChapterX
- 190. Risk Management ProcessFlow Integrating risk management with program management requires more than a “list” of risks. It requires a set of activities, tools, and staff to assure that risk management becomes part of the Integrated Master Schedule in the same way any other work activity would. This notional process flow shows how risks move from discovery to the Performance Measurement Baseline. This process flow contains actors, data storage elements, and meetings and committees. Each element interacts with other elements is a well structured manner. Following this process flow is critical to the success of any Risk Management process. Skipping steps, bypassing meetings or committees not only disrupts the flow of information, but also jeopardizes the integrity of the risk management process. The key to success here is that once the risk has been approved and is “active” is to connect the “risk handling” activities with the Integrated Master Schedule (IMS) at the Work Package level. The three processes shown on the facing page, move the risk from identification, to analysis, to an approved risk. Risk management and project risk management are comprehensive processes aimed at risk identification, planning stages post risk identification, defining the essential activities to be undertaken, and therefore lessening of the recognized risks. While relating particularly to the project risk management perspective, activities begin by planning the risk aspect in relevance to the project under consideration – the Idea Stage. The plan is comprehensively defined to include even the most basic of tasks, essential for project completion. The idea is to plan risk management for the project. The next stage focuses on project risk identification – the Analysis Stage. This is followed by the Approval Stage, where risks are incorporated into the normal course of the project’s management processes. 1. The Idea Stage – captures “ideas” for risks on the project. This is a “brain storming” processes as well as a subject matter expert processes. 2. Analysis Stage – for each identified risk, analysis is needed for determine the attributes of each risk. This includes the simple probability of occurrence and impact on the project. There is much more analyzing risk - beyond this top level material. 3. Approval Stage – once the risk has been identified it is approved by the Risk Board and placed on baseline. Connections to the Integrated Master Schedule (IMS) are made, budget allocated for the handling of the risk, and the risk handling activities treated just like any other work activity in the IMS. ChapterX 190
- 191. Risk Management ProcessFlow ChapterX 191
- 192. The Risk Registry Riskmanagement is not a hard science. Risk Management requires that the risk manager combine the best‒known technical information with good professional judgment. A key element of risk management is maintaining the set of program risks so that the most important risks are prioritized from the perspective of the program team or organization. Risk Radar facilitates this process and makes risk management as simple and straightforward as possible. The Risk Management too is a risk database that helps program managers identify, prioritize, and communicate project risks in a flexible and easy‒to‒use form. This tool provides standard set of functions to add and delete risks, together with specialized functions for prioritizing and retiring project risks. Each risk can have a user‒defined risk management plan and a log of historical events. A set of standard detailed and summary reports can be easily generated to share project risk information with all members of the development team. The number of risks in each probability/impact category by time frame can be displayed graphically, which allows the user to visualize risk priorities and easily uncover increasing levels of detail on specific risks. The tool also provides flexibility in prioritizing risks through automatic sorting and risk‒specific movement functions for priority ranking. The most important part of risk management is to identify the highest‒priority risks and to keep attention focused on them as a project evolves over time. Risk management is a dynamic and proactive process that requires continuous vigilance. An important risk this month might not be important next month. It is impossible to predict all the risks a project might face in the future, and it is futile to try. However, future events or conditions that could be a major threat to a project’s success should be diligently watched. Risks will pop up, be mitigated, and then hopefully be relegated to a much lower level of concern, and eventually be retired. Other risks will likely step in to replace them. The critical success factor for the risk registry is the connection between the identified and active risks the risk handling processes embedded in the Integrated Master Schedule. This connection is bi-directional, between the Registry and the IMS. The Risk ID in embedded in all the work activities in the IMS, and the IMS WBS number, Control Account, and Work Package IDs embedded in the Risk Register. Only by making these connections can the program be assured that risks are being “handled” as part of the normal course of business of Program Management. 192 ChapterX
- 193.
- 194. Monte Carlo Simulationof Schedule Risk Monte Carlo simulations provide a useful approach to modeling schedule risk. But their value is more than that. Unlike PERT or other deterministic approaches – even though the three point estimates are billed as probabilistic – Monte Carlo examines the schedule network independent of a critical path, topological constraints or other “human induced” problems. It looks at the network as a collection of nodes and arcs, independent of the “meaning” of this information and produces a model of the behavior of these nodes and arcs The concept behind Monte Carlo is to sample the possible durations for a task from the population of all durations and apply them to the schedule. The population of possible samples is defined by the Cumulative Probability Density (CDF) function for each task. This in turn is defined by the 3–point estimate for the task, which selects the bounds in the CDF for sampling. Since there is no direct concept of a Critical Path in Monte Carlo, the near critical path tasks are considered in the analysis of the completion time. As well the PERT biases produced by the simple minded PERT formula are avoided as well. Since Monte Carlo does not need to know about the Critical Path, it is conceptually simpler to use. A well formed network is needed and the 3–point estimates need to represent the proper risk assessment. The result is a cumulative distribution and a probability distribution function. Interpreting this result is straight forward. The confidence of each date is shown in the table on the right. This is the probability of completing the task by the date. 194 ChapterX
- 195. Monte Carlo Simulationof Schedule Risk ¨ The height of each box indicates how often the project complete in a given interval during the run ¨ The S–Curve shows the cumulative probability of completing on or before a given date. ¨ The standard deviation of the completion date and the 95% confidence interval of the expected completion date are in the same units as the “most likely remaining duration” field in the schedule. 195 ChapterX Date: 9/26/2005 2:14:02 PM Samples: 500 Unique ID: 10 Name: Task 10 Completion Std Deviation: 4.83 days 95% Confidence Interval: 0.42 days Each bar represents 2 days Completion Date Frequency CumulativeProbability 3/1/062/10/06 3/17/06 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1.0 0.02 0.04 0.06 0.08 0.10 0.12 0.14 0.16 Completion Probability Table Prob ProbDate Date 0.05 2/17/06 0.10 2/21/06 0.15 2/22/06 0.20 2/22/06 0.25 2/23/06 0.30 2/24/06 0.35 2/27/06 0.40 2/27/06 0.45 2/28/06 0.50 3/1/06 0.55 3/1/06 0.60 3/2/06 0.65 3/3/06 0.70 3/3/06 0.75 3/6/06 0.80 3/7/06 0.85 3/8/06 0.90 3/9/06 0.95 3/13/06 1.00 3/17/06 Task to “watch” 80% confidence that task will complete by 3/7/06
- 196. Techncial Performance MeasuresTrends and Responses TPMs are a set of measures that provide the supplier and acquirer with insight into progress to plan of the technical solution, the associated risks, and emerging issues. Technical Performance Measures § Provide program management with information to make better decisions, § Increase the probability of delivering a solution that meets both the requirements and mission need. Measures of Effectiveness are the operational measures of success that are closely related to the achievements of the mission or operational objectives evaluated in the operational environment, under a specific set of conditions. Measures of Effectiveness § Are stated in units meaningful to the buyer, § Focus on capabilities independent of any technical implementation, § Are connected to the mission success. Measures of Performance characterize physical or functional attributes relating to the system operation, measured or estimated under specific conditions. Measures of Performance § Are attributes that assure the system has the capability to perform, § Is an assessment of the system to assure it meets design requirements to satisfy the MoE. Key Performance Parameters Represent the capabilities and characteristics so significant that failure to meet them can be cause for reevaluation, reassessing, or termination of the program. Key Performance Parameters § Have a threshold or objective value, § Characterize the major drivers of performance, § Are considered Critical to Customer (CTC). Technical Performance Measures are Attributes that determine how well a system or system element is satisfying or expected to satisfy a technical requirement or goal. Technical Performance Measures § Assess design progress, § Define compliance to performance requirements, § Identify technical risk, § Are limited to critical thresholds, § Include projected performance. 196 ChapterX
- 197. Technical Performance MeasuresTrends and Responses 197 25kg 23kg 28kg 26kg PDRSRRSFRCA TRRCDR ROM in Proposal Design Model Bench Scale Model Measurement Detailed Design Model Prototype Measurement Flight 1st Article TechnicalPerformanceMeasure VehicleWeight ChapterX
- 198. Connecting the Dotswith the Performance Measurement Baseline The elements of the Performance Measurement Baseline support the credibility of this baseline. Each contributes an important element to increasing the credibility of the PMB and that increases the probability of success for the project. § Technical and Programmatic Risks Connected to the WBS and IMS. This connection identifies when the risk will move from one color to another – Red to Yellow for example is defined in the IMS as a date. The work needed to move from Red to Yellow is also defined. § IMS contains all the Work Packages, BCWS, Risk mitigation plans, and rolls to the Integrated Master Plan to measure increasing maturity. These work packages are the “value flow” of the project. They define the incremental outcomes of the work effort to implement the requirements which fulfill the capabilities needed for the mission, vision, or business. § The Products and Processes that produce them in a “well structured” decomposition in the WBS. The WBS terminal nodes of the WBS are the product deliverables (components) that form the final deliverables. The cost collection is the primary role of the WBS beyond the product decomposition. § BCWS at the Work Package, rolled to the Control Account defines the cost for the projects as well as the cost per product component and the service to produce that product. § The Statement of Work (SOW) and the related Statement of Objectives (SOO) and CDRLs define the named deliverables defined in the WBS. § TPMs attached to each critical deliverables in the WBS and identified in each Work Package in the IMS, used to assess maturity in the IMP Each of these elements is related to the other to form what “done” looks like from each point of view. 198 ChapterX
- 199. Connecting the Dotswith the Performance Measurement Baseline 199 Risk SOW Cost WBS IMP/IMS TPM PMB Named Deliverables defined in the WBS BCWS at the Work Package, rolled to the Control Account TPMs attached to each critical deliverables in the WBS and identified in each Work Package in the IMS, used to assess maturity in the IMP The Products and Processes that produce them in a “well structured” decomposition in the WBS IMS contains all the Work Packages, BCWS, Risk mitigation plans, and rolls to the Integrated Master Plan to measure increasing maturity Technical and Programmatic Risks Connected to the WBS and IMS ChapterX
- 200. Measures of Effectiveness(MoE) and Measures of Performance (MoP) for a Capability If we are to make logical decisions and choices in product and systems development, we need to have criteria to measure the value or relative importance of aspects of alternative proposals. This is an essential pre‒requisite for part of trade studies. Both the client (customer, user) and the engineer have such measures, and these are related. § Measures of Effectiveness (MoE) represent the customer view, usually annotated and of qualitative nature. They describe the customers’ expectations of a product, project or system; the voice of the customer. § Measures of Performance (MoP) are the corresponding view of the engineer; a technical specification for a product. Typically Measures for Performance are quantitative and consist of a range of values about a desired point. These values are what an engineer targets when designing the product, by changing shape, materials and manufacturing process, so as to finally achieve the qualities desired by the customer. Many of the results from this method may appear to be logical and obvious requirements. However, as the product becomes more complex, the systematic approach of breaking down the customers’ requirements into their most basic components, aids to understand where requirements were derived. This method enables formation of a complete list of customer needs and wants, from which broad engineering specifications are developed. When developing the Measures of Performance, it is necessary to distinguish needs and wants in the design. These then enables engineering design to proceed with some basic known constraints and variables. Weightings can be attached to each design requirement, both for Measures of Effectiveness and Measures of Performance. Evaluation of alternate designs can be made through the use of a method such as “Weighted objective decision matrix” or similar methods. 200 ChapterX
- 201. Measures of Effectiveness(MoE) and Measures of Performance (MoP) for a Capability New Stylish Coffee Cup Basic Coffee Cup Requirements Large, budget Market 0.4 0.3 0.3 New look and style 0.4 0.16 Trendy new look Glossy appearance 0.3 0.12 Smooth surface 0.3 0.12 Mass produced 0.3 0.09 Low cost 0.7 0.21 Don’t burn lips 0.4 0.12 Lightweight 0.2 0.06 Dishwasher proof 0.3 0.09 Hold hot liquids 0.1 0.03 Need What Measure N Weight < 120g W Weight < 100g N Non Porous N Thermal Conductivity < 2.5W/m.K W Thermal Conductivity < 1.4W/m.K W Surface finish < ± 0.04mm N Produce 5000 / day W Produce > 8000 /day N Rigid solid @ ~ 110°C W Reflective coating 201 ChapterX
- 202. 11 Critical Criteriafor Earned Value Management The successful management of projects depends on managing the performance of the planned work. This starts with the Performance Measurement Baseline – Chapter VI. But this Handbook does not describe the details for apply Earned Value to managing he performance of the PMB. This diagram shows the 11 critical process areas (criteria) from the ANSI-748B Earned Value Management guide that must be in place for project success. These include: 1 Define the Work Breakdown Structure (WBS) 2 Identify the Organization (OBS) 5 Integrate the OBS and WBS 202 ChapterX 6 Schedule the work 7 Identify Products and Milestones 8 Set Time Phased Budget 16 Record Direct Costs 23 Determine Variance 25 Sum data and Variance 26 Manage Action Plans 28 Incorporate Changes
- 203. 11 Critical Criteriafor Earned Value Management ¨ The 32 EVM Criteria are all designed to deliver value. ¨ These 11 are the basis of “connecting the dots.” 203 ChapterX
- 204. Connecting Principles withProcesses through Artifacts and Outcomes Each of the 10 organizing principles supports one or more the 5 Deliverables Based Planning® Process Areas. The chart to the right shows to the top level connectivity between the Principles and Practices. The key to Deliverables Based Planning® is to continuously ask and answer: What is the evidence that we have actually completed the work effort? The answer must be a tangible physical artifact. An artifact that was defined before the work started. An artifact whose measure of performance and measure of effectiveness was defined before the work effort started. It is the “defined before the work effort is started,” that is the critical success factor. Without this information, knowing what “done” looks like is missing. In the chart to the right the units of measure for each of these deliverables are not defined in any meaningful way – since this is a notional example. In practice one example would be the ConOps (Concept of Operations). An Annotated Table of Contents would be used to define the units of measure of “done” before the work effort was started. There may be predecessor work effort to define this Table of Contents. For each work effort – a Work Package – the “exit criteria” must be defined before the Work Package can be placed on baseline. This is equivalent to the Work Breakdown Structure Dictionary mandated in MIL‒STD‒881A. This is a narrative description of what “done” looks like. For each artifact there must be a agreed on Table of Contents (TOC) with annotations describing the outcomes of each section in the document before the writing can start 204 ChapterX
- 205. Connecting Principles withProcesses through Artifacts and Outcomes 10 Organizing Principles of Deliverables Based Planning® Capabilities Based Planning Requirements Baseline Performance Measurement Baseline PMB Execution 1 Capabilities Drive Requirements ConOps 2 Requirements Identify Deliverables REQM BL 3 Work Packages Describe Production of Deliverables WP Flow 4 Master Schedule Sequences Deliverables through Work Packages IMS 5 Progress Must Be Measured As Physical Percent Complete TPM, MoP, MoE 6 Work Authorization Assures Proper Sequencing of Work Packages WA 7 Earned Value Identifies Current Deliverables Performance SPI / CPI 9 Technical Performance Measures Adjust Earned Value TPM 9 Performance Feedback Adjusts Work Package Sequencing Business Rhythm 10 Future Performance Based on TCPI, IEAC and Adjusted Work Sequence TCPI IEAC 205 ChapterX
- 206. Connecting Deliverables BasedPlanning® with the 9 Knowledge Areas of PMI PMBOK® The Project Management Institute’s Guide to the Project Management Body of Knowledge provides one starting point for practices in the project and program management arena. Each of the elements in the matrix describes how Deliverables Based Planning® fulfills the Knowledge Area of PMBOK® 1. Integration Management – processes and activities needed to identify, define, combine, unify, and coordinate the various processes and project management activities within the Project Management 2. Scope Management – processes required to ensure that the project includes all the work required, and only the work required, to complete the project successfully. 3. Time Management – processes required to manage timely completion of the project. 4. Cost Management – processes involved in estimating, budgeting, and controlling costs so that the project can be completed within the approved budget. 5. Quality Management – processes and activities of the performing organization that determine quality policies, objectives, and responsibilities so that the project will satisfy the needs for which it was undertaken. 6. Human Resource Management – processes that organize, manage, and lead the project team. 7. Communications Management – processes required to ensure timely and appropriate generation, collection, distribution, storage, retrieval, and ultimate disposition of project information. 8. Risk Management – processes of conducting risk management planning, identification, analysis, response planning, and monitoring and control on a project. 9. Procurement Management – processes necessary to purchase or acquire products, services, or results needed from outside the project team. 206 ChapterX
- 207. Connecting Deliverables BasedPlanning® with the 9 Knowledge Areas of PMI PMBOK® The 9 Knowledge Areas of PMBOK® Capabilities Based Planning Requirements Baseline Performance Measurement Baseline PMB Execution Continuous Risk Management 1 Integration Management Concept of Operations IPT dependencies SE interface management Interface Management 2 Scope Management Capability flow down Requirements Flowdown Tree WBS/TPM Integration REQ Management Growth Control 3 Time Management Capability need date SA/AC Delivery Dates Integrated Master Schedule Schedule Variance EAC Control 4 Cost Management Traceability Matrix Integrated Master Schedule Cost Variance EAC Control 5 Quality Management Quality Mgmt Impact Matrix Integrated Master Schedule TPM Variance Variance Management 6 Human Resource Management Responsibility Assignment Matrix Resource Loaded Schedule Resource Management Plan FTE Management 7 Communications Management Requirements Traceability Performance Risk Messaging 9 Risk Management Risk Management Plan Risk Register IMS / Risk Risk Buy Down RM Processes 9 Procurement Management Supply Chain Management SCM Channels SCM Activities SCM Performance SK Management ChapterX 207
- 208. Connecting Deliverables BasedPlanning® with the 5 Process Groups of PMI PMBOK® The 5 Process Groups of PMBOK® are mapped to the Deliverables Based Planning® Process Areas. These Process Groups are: 1. Initiating – processes performed to define a new project or a new phase of an existing project by obtaining authorization to start the project or phase. 2. Planning – processes performed to establish the total scope of the effort, define and refine the objectives, and develop the course of action required to attain those objectives. 3. Executing – processes performed to complete the work defined in the project management plan to satisfy the project specifications. 4. Monitoring and control – processes required to track, review, and regulate the progress and performance of the project; identify any areas in which changes to the plan are required; and initiate the corresponding changes. 5. Closing – processes performed to finalize all activities across all Project Management Process Groups to formally complete the project, phase, or contractual obligations. The process groups and knowledge areas from PMBOK® have one to one connections with the details of the Deliverables Based Planning® processes. This mapping provide several benefits to the users of Deliverables Based Planning® : 1. The guidance in PMBOK® provides a starting point for any good project management method and the processes that go with it. 2. For each Process Group in Deliverables Based Planning® has directives for executing work in the process groups. These have their basis in PMBOK® as well as other project management frameworks. 3. The artifacts from the Deliverables Based Planning® processes are contained in PMBOK® since it is an overview document. The mapping connects the principles to the practices. ChapterX 208
- 209. Connecting Deliverables BasedPlanning® with the 5 Process Groups of PMI PMBOK® Deliverables Based Planning® Process Areas The 5 Process Groups of PMBOK® Capabilities Baseline Requirements Baseline Performance Measurement Baseline PMB Execution Continuous Risk Management 1 Initiating Concept of Operations 2 Planning Integrated Master Plan Integrated Master Schedule Plan Risks 3 Executing Work Package Sequencing Work Authorization Measure Risks 4 Monitoring and Control Integrated Master Schedule Performance Based Earned Value Monitor Risks 5 Closing Integrated Master Schedule Integrated Master Schedule Retire Risks ChapterX 209 Deliverables Based Planning ® is a registered trademark of Lewis & Fowler. Copyright ® Lewis & Fowler, 2011
- 210.
- 211. 211 ABibliography and References Appendix "Knowledge isof two kinds. We know a subject ourselves, or we know where we can find information upon it. When we enquire into any subject, the first thing we have to do is to know what books have treated of it. This leads us to look at catalogues, and at the backs of books in libraries.“ — Samuel Johnson (Boswell's Life of Johnson)
- 212.
- 213. Chapter I References Principlesand Practices of DBP® [INCOSE] Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities, INCOSE–TP–2003–002–03.1, August 2007, www.incose.org [Stevens] Systems Engineering: Coping with Complexity, Richard Stevens, Peter Brook, Ken Jackson, and Stuart Arnold, Prentice Hall, 1998. [Wood] Henri Fayol: Critical Evaluations in Business and Management, John C. Wood and Michael C. Wood, Routedge, 2002. [Pisano] “Technical Performance Measurement, Earned Value, and Risk Management: An Integrated Diagnostic Tool for Program Management,” Commander N. D. Pisano, SC, USN, Program Executive Office for Air ASW, Assault, and Special Mission Programs (PEO(A)) AppendixA 213
- 214. Chapter II References The10 Principles of DBP® [Pruitt03] Modeling Homeland Security: A Value Focused Thinking Approach, Kristopher Pruitt, Air Force Institute of Technology, March 2003 [Solomon] Performance Based Earned Value, Paul Solomon. [PMBOK] Guide to the Project Management Body of Knowledge, Project Management Institute. [Brooks87] “No Silver Bullet: Essence and Accidents of Software Engineering, Fred Brooks, IEEE Computer, 10‒19, April 1987. [Grady06] Systems Requirements Analysis, Jeffry O. Grady, Academic Press, 2006. [Henderson08] “Further Development in Earned Schedule,” Kym Henderson, The Measureable News, Spring 2004. [Lipke] “Schedule is Different,” Walter Lipke, The Measureable News, Summer 2003. [Vanhoucke] “A Simulation and Evaluation of Earned Value Metrics to Forecast Project Duration,” M. S. Vanhoucke, Journal of Operations Research Society, October 2007. [IEEE1220] Standard for Application and Management of the Systems Engineering Process, Institute of Electrical and Electronics Engineers, 09–Sep–2005 [Stevens98] Systems Engineering: Coping with Complexity, Richard Stevens, Peter Brook, Ken Jackson, and Stuart Arnold, Prentice Hall, 1998. [Young04] The Requirements Engineering Handbook, Ralph R. Young, Artech House, 2004 [Pisano] “Technical Performance Measurement, Earned Value, and Risk Management: An Integrated Diagnostic Tool for Program Management,” Commander N. D. Pisano, SC, USN, Program Executive Office for Air ASW, Assault, and Special Mission Programs (PEO(A)) [Christel92] “Issues with Requirements Elicitation,” Michael G. Christel and Kyo C. Kang, Technical Report, CMU/SEI–92–TR–12, Software Engineering Institute, Carnegie Mellon University Pittsburgh, Pennsylvania 15213. [Danilovic] “Managing complex product development projects with design structure matrices and domain mapping matrices,” Mike Danilovic and Tyson Browning, International Journal of Project Management, 25 (2007), pp. 300–314. AppendixA 214
- 215. Chapter II References The10 Principles of DBP® [Sharman] “Architectural optimization using real options theory and Dependency structure matrices,” David M. Sharman, Ali A. Yassine+, Paul Carlile, Proceedings of DETC ’02 ASME 2002 International Design Engineering Technical Conferences 28th Design Automation Conference Montreal, Canada, September 29–October 2, 2002. [Browning] “Modeling and Analyzing Cost, Schedule, and Performance in Complex System Product Development,” Tyson Browning, Massachusetts Institute of Technology, February 1999. [TIPMH] The Integrated Project Management Handbook, Dayton Aerospace, 8 Feb 2002, Dayton Ohio. [Davis] “Analytic Architecture for Capabilities–Based Planning, Mission–System Analysis, and Transformation,” Paul K. Davis, RAND Corporation. [INCOSE] Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities, INCOSE–TP–2003–002– 03.1, August 2007, www.incose.org AppendixA 215
- 216. Chapter III References DeployingDeliverables Based Planning® [IDEFÆ] http://www.idef.com/idef0.html AppendixA 216 Deliverables Based Planning ® is a registered trademark of Lewis & Fowler. Copyright ® Lewis & Fowler, 2011
- 217. Chapter IV References IdentifyNeeded Systems Capabilities [Davis] “Analytic Architecture for Capabilities–Based Planning, Mission–System Analysis, and Transformation,” Paul K. Davis, RAND Corporation. [Davis] Portfolio-Analysis Methods for Assessing Capability Options, Paul K. Davis, Russell D. Shaver, and Justin Beck, Rand Corporation, 2008 [Sharman] “Architectural optimization using real options theory and Dependency structure matrices,” David M. Sharman, Ali A. Yassine+, Paul Carlile, Proceedings of DETC ’02 ASME 2002 International Design Engineering Technical Conferences 28th Design Automation Conference Montreal, Canada, September 29–October 2, 2002. [Browning99] “Modeling and Analyzing Cost, Schedule, and Performance in Complex System Product Development,” Tyson Browning, Massachusetts Institute of Technology, February 1999. [Maier] The Art of Systems Architecting, Mark W. Maier and Eberhardt Rechtin, CRC Press, 2000. [Stevens] Systems Engineering: Coping With Complexity, Richard Stevens, Peter Brook, Ken Jackson, and Stuart Arnold, Prentice Hall, 1998. [Dewer] Assumption Based Planning: A Tool for Reducing Avoidable Surprises, James A. Dewar, Cambridge University Press, 2002. [Kossakowski] Capabilities-Based Planning: A Methodology for Deciphering Commander’s Intent, Peter Kossakowski, Evidence Based Research, Inc. 1595 Spring Hill Road, Suite 250 Vienna, VA 22182. [Stalk] Competing on Capabilities: The New Rules for Corporate Strategy, George Stalk, Philip Evans, and Lawrence Shulman, Harvard Business Review, No. 92209, March-April 1992. [Jeffery] Effects-Driven, Capabilities-Based, Planning for Operations, Maj Kira Jeffery, USAF and Mr Robert Herslow. [Saunders] Effects-based Operations: Building Analytical Tools, Desmon Saunder-Newton and Aaron B. Frank, Defense Horizons, October 2002, pp 1-8. [TTCP] Guide to Capability-Based Planning, Joint Systems and Analysis Group, MORS Workshop, October 2004, Alexandria, VA. http://www.mors.org/ AppendixA 217
- 218. Chapter V References Establishthe Requirements Baseline [Christel] “Issues with Requirements Elicitation,” Michael G. Christel and Kyo C. Kang, Technical Report, CMU/SEI–92–TR–12, Software Engineering Institute, Carnegie Mellon University Pittsburgh, Pennsylvania 15213. [Young] The Requirements Engineering Handbook, Ralph R. Young, ArcTech House, 2004 [Boehm] Software Risk Management, Barry W. Boehm, IEEE Computer Society Press, 1989. [David] Software Requirements Analysis & Specifications, Alan M. Davis, Prentice Hall, 1990. [Sommerville] Requirements Engineering: A Good Practice Guide, Ian Sommerville and Pete Sawyer, John Wiley & Sons, 1997. [Grady] Systems Requirements Practices, Jeffery O. Grady, McGraw Hill, 1993 [Ebert] Four Key Requirements Engineering Techniques, Christof Ebert, IEEE Software, May / June 2006. [Leveson] Intent Specifications: An Approach to Building Human-Centered Specifications, Aeronautics and Astronautics, MIT. [Leveson] Sample TCAS Intent Specification, Nancy Leveson and Jon Damon Reese, Software Engineering Corporation . AppendixA 218
- 219. Chapter VI References Establishthe Performance Measurement Baseline [Danilovic] “Managing complex product development projects with design structure matrices and domain mapping matrices,” Mike Danilovic and Tyson Browning, International Journal of Project Management, 25 (2007), pp. 300–314. [MIL 881] MIL–STD–881A, Work Breakdown Structures. [Morris] The Management of Projects, Peter W. G. Morris, Thomas Telford, 1994 [Williams] Modelling Complex Projects, Terry Williams, John Wiley & Sons. 2002. [Brown] The Handbook of Program Management, James T. Brown, McGraw Hill, 2007. [Brown] AntiPatterns in Project Management, William J. Brown, Hays W. McCormick III, and Scott W. Thomas, John Wiley & Sons, 2000 AppendixA 219
- 220. Chapter VII Reference Executethe Performance Measurement Baseline [Fleming] Earned Value Management, 3rd Edition, Quentin W. Fleming and Joel M. Koppelman, Project Management Institute, 2005. AppendixA 220
- 221. Chapter VIII References ContinuousRisk Management [Bolles] “Understanding Risk Management in the DoD,” Mike Bolles, Acquisition Research Journal, Volume 10, pp. 141–145, 2003. [Conrow] Effective Risk Management: Some Keys to Success, 2nd Edition, Edmund H. Conrow, AIAA Press, 2003. [Hall] Managing Risk: methods for Software Systems Development, Elaine M. Hall, Addison Wesley, 1998 [NDIA] Integrating Risk Management with Earned Value Management, National Defense Industry Association. [Risk] Three point estimates and quantitative risk analysis a process guide for risk practitioners, Acquisitioning Operating Framework, UK Ministry of Defense, http://www.aof.mod.uk/index.htm [Hillson] Effective Opportunity Management for Project: Exploring Positive Risk, David Hillson, Taylor & Francis, 2004. [Bennatan] Catastrophe Disentanglement: Getting Software Projects Back on Track, E. M. Bennatan, Addison Wesley, 2006. [Karolak] Software Engineering Risk Management, Dale Walter Karolak, IEEE Computer Society Press, 1998. [Jones] Assessment and Control of Software Risks, Capers Jones, Prentice Hall, 1994 [AOF] Three Point Estimates and Quantitative Risk Analysis - A Process Guide For Risk Practitioners - version 1.2 May 2007 - Risk Management – AOF, http://www.aof.mod.uk/aofcontent/tactical/risk/downloads/3pepracgude.pdf [Lister] How much risk is too much risk?, Tim Lister, Boston SPIN, January 20th , 2004. [INCOSE] Risk Management Maturity Level Development, INCOSE Risk Management Working Group, April 2002. [Arízaga] “A Methodology for Project Risk Analysis using Bayesian Belief Networks within a Monte Carlo Simulation Environment,” Javier F. Ordóñez Arízaga, University of Maryland, College Park, 2007. [USAF] AFMC PAMPHLET 63-101, 9 July 1997. [Valerdi] An Approach to Technology Risk Management, Ricardo Valerdi and Ron J. Kohl, Engineering Systems Division Symposium, MIT, Cambridge, MA 29-31 March 2004. AppendixA 221
- 222. Chapter VIII References ContinuousRisk Management [Bahill] “An Industry Standard Risk Analysis Technique,” A Terry Bahill and Eric D. Smith, Engineering Management Journal, Vol. 21 No 4., December 2009. [ASE] Risk Management Process and Implementation, American Systems Corporation, 2003. [Kandaswamy] The Basics of Monte Carlo Simulation: A Tutorial, S. Kandaswamy, Proceedings of the Project Management Institute Seminars & Symposium, 1-10 November 2001. [NASA] Bayesian Inference for NASA Probabilistic Risk and Reliability Analysis, NASA/SP-2009-569, June 2009. [Alberts] Common Elements of Risk, Christopher J. Alberts, CMU/SEI-2006-TN-014, April 2006. [Conrow] “Development of Risk Management Defense Extensions to the PMI Project Management Body of Knowledge,” Edmund H. Conrow, Acquisition Review Quarterly, Spring 2003. [Dorofee] Continuous Risk Management Guidebook, Audrey J. Dorofee, Julie A. Walker, Christopher J. Alberts, Ronald P. Higuera, Richard L. Murphy, and Ray C. Williams, Software Engineering Institute, 1996. [DoD] Risk Management Guide for DoD Acquisition, Fifth Edition, June 2002. [Drucker] Emerging Practice: Joint Cost & Schedule Risk Analysis, Eric Drucker, 2009 St. Louis SCEA Chapter Fall Symposium, St’ Louis, MO. [Coleman] Making Risk Management Tools More Credible: Calibrating the Risk Cube, Richard L. Coleman, Jessica R. Summerville, and Megan E. Dameron, SCEA 2006, Washington, D.C., 12 June 2006. [Book] A Theory of Modeling Correlations for Use in Cost-Risk Analysis, Stephen A. Book, Third Annual Project Management Conference, NASA, Galveston, TX, 21-22 March 2006. [Butts] The Joint Confidence Level Paradox: A History of Denial, 2009 NASA Cost Symposium, 28 April 2009. AppendixA 222
- 223. Chapter X References Toolsand Artifacts [Yassine] An Introduction to Modeling and Analyzing Complex Product Development Processes Using the Design Structure Matrix (DSM) Method, Ali A. Yassine [Browning] Browning, T. & Eppinger, S., “Modeling Impacts of Process Architecture on Cost and Schedule Risk in Product Development,” IEEE Transactions on Engineering. Management, 49(4): 428–442, 2002. [Danilovic] Managing complex product development projects with design structure matrices and domain mapping matrices, Mike Danilovic and Tyson R. Browning, International Journal of Project Management. [DoD] Risk Management Guide for DOD Acquisition, US Department of Defense. [FIPS 184] Federal Information Processing Standard Publication 184: Integrated Definition for Information Modeling, 21 December 1993. [Gottesdiener] Good Practices for Developing User Requirements, Crosstalk, May 2008, pp. 13-17. AppendixA 223
- 224.