1. Increasing the Maturity of Project Work
Chapter 0
Processes and Their Deliverables
1
Identify Indentify Establish Execute
Needed Baseline Performance Performance
Capabilities Requirements Measurement Measurement
Baseline Baseline
Perform Continuous Risk Management (CRM)
Define Capabilities Fact Finding Decompose Scope Perform Work
Define ConOps Gather And Classify Assign Accountability Accumulate
Assess Needs, Cost, and Evaluate And Arrange Work Performance Measures
Risk Impacts Rationalize Develop BCWS Analyze Performance
Define Balanced and Prioritize Requirements Assign Performance Take Corrective Action
Feasible Alternatives Integrate And Validate
Define the Measurable Assure All Requirements Define Measures of Ensure Cost, Schedule,
Capabilities of each Provided In Support of Performance and and Technical
Project Outcome Capabilities Effectiveness Performance Compliance
Performance Based Management(sm), Copyright ® Glen B. Alleman, 2012
2. 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 Partition system capabilities into 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.
1.2 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.
1.3
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.
1.4 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.
2 Performance Based Management(sm), Copyright ® Glen B. Alleman, 2012 Chapter 0
3. Chapter 0
What Does A Capability “Sound” Like?
3
Performance Based Management(sm), Copyright ® Glen B. Alleman, 2012
4. Chapter 0
Identifying Needed System Capabilities
4
What Should We Do?
Where Are We Now?
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
Performance Based Management(sm), Copyright ® Glen B. Alleman, 2012
5. 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 Produce an overall 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.
2.2
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.
2.3
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.
2.4
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.
2.5 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.
5 Performance Based Management(sm), Copyright ® Glen B. Alleman, 2012 Chapter 0
6. Chapter 0
What Is a Requirement?
6
Performance Based Management(sm), Copyright ® Glen B. Alleman, 2012
7. Chapter 0
Identifying Requirements†
7
†Systems Requirements Practices, Jeffery O. Grady, McGraw Hill, 1993
Performance Based Management(sm), Copyright ® Glen B. Alleman, 2012
Notas del editor
Here are some example of capabilities. They appear obvious. But in many instances this approach is missing. The requirements are the starting point for the solution. In the absence of the capabilities statement and the Concept of Operations the user community may have trouble envisioning how the system will benefit them when it becomes available.The tendency to start with the requirements should be avoided. Requirements need a home, a reason for being.These examples are from actual projects. They represent clear and concise statement about the need for the system, the use of the system for the business or mission purpose, and how the end user will benefit from the system.
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 Performance Based Management(sm)method concentrates instead on elicitation. This method addresses problems found with requirements engineering that are not adequately addressed by specification techniques.This Performance Based Management(sm) 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 first step is to separate “product” requirements from “process” requirements. The product could be a service as well, but the product (or service) is not the same as the process that delivers the service that may be enabled by the product.We can see there are several components of this separation. Later on in this session we’ll put this taxonomy to use with a process for requirements management. While this type of taxonomy looks unnecessary, later on we’ll see it can serve to reduce complexity, focus our efforts on important the parts of requirements management, and reduce the overall effort of managing these requirements.