Capabilities Based Planning

Before any project or program can be successful, we must know what capabilities do we need to possess to accomplish the mission or fulfill a business strategy?

The units of measure for these capabilities start with Measures of Effectiveness (MOE) and Measures of Performance (MOP). These measures are delivered by the solution, but they are independent of the requirements and implementation of the solution.

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 prerequisite for trade studies. Both the client (customer, user) and the engineer have such measures, and these are related.

• Measures of Effectiveness (MoE) are Operational measures of success that are closely related to the achievements of the mission of business strategy evaluated in the operational; environment, under a specific set of conditions. MOEs 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. MOEs are stated in units meaningful to the buyer, focus on Capabilities independent of any technical implementation, and are connected to the mission or business success
• Measures of Performance (MoP) are measures that characterize physical or functional attributes relating to the system operation, measured or estimated under specific conditions. MOPs describe 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 the desired point. These values are what engineer targets when designing the product, by changing shape, materials, and manufacturing process, so as to finally achieve the qualities desired by the customer. MOPs are attributes that assure the system has the capability and capacity to perform, and are an assessment of the system that meets design requirements to satisfy the MOEs.

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 in understanding where requirements were derived.

This method enables the 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 enable 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.

Capabilities-Based Planning Process

Before defining ANY requirements for the project determine what Capabilities are needed to solve a problem. Only then find the technical and operational requirements for the deliverables from the project work that will enable those Capabilities.

"Capabilities-Based Planning - How It is Intended To Work and Challenged To Its Successful Implementation."

A simple example is we need the capability to capture the market on Coffee cups at our Coffee company. Here are the MOE's and MOP's of such a cup.

The same process of identifying the MOE's and MOP's takes place on ANY project in ANY domain and context, using ANY development method.

With the Identifies Capabilities, We Can Start With Planning

Designing, building, testing, and deploying complex systems is fraught with risk. And as always risk comes from uncertainty. And uncertainty comes in two forms -?reducible?(Epistemic) and?irreducible?(Aleatory). Much has been written about the sources of risk and how to?Manage in the Presence of Uncertainty?(This briefing describes how risk is managed for each?element of the Integrated Master Plan).?

What About the Plan to Manage in the Presence of Uncertainty?

Plans are Strategies.?A Strategy is a Hypothesis.?The Hypothesis requires?tests?(experiments) to confirm that we're moving in the right direction along the path defined in the Plan. This is the role of a?roadmap, a literal roadmap, folded and placed on the lap of the passenger?in the car for our road trip. I miss those days, where you could trace the route of where you came from and the route of where you are going with your finger.

The role of the Integrated Master Plan is to provide the Strategy for the successful completion of the program.

So how do we build the Integrated Master Plan and the Integrated Master Schedule to supports the plan? First, let's look at what we're talking about

The Integrated Master Plan (IMP) and Integrated Master Schedule (IMS) are important tools that provide significant assistance in planning and scheduling work efforts. This document outlines an approach to support program and project teams in developing effective integrated execution plans for weapons systems and subsystems and component acquisition, modification, and sustainment.

The IMP is an Event-based plan consisting of a hierarchy of program Events, with each event being supported by specific Accomplishments, and each Accomplishment associated with specific Criteria to be satisfied for its completion. The IMP should provide sufficient definition to track the step-by-step completion of the required Accomplishments for each event and to demonstrate satisfaction with the completion Criteria for each Accomplishment. IMP the Events are not tied to calendar dates; each event is completed only when its supporting Accomplishments are completed as evidenced by satisfying the Criteria supporting each of those Accomplishments. This plan, the IMP, is placed on contract and becomes the baseline execution plan for the program/project. Although fairly detailed, the IMP is a top-level, foundational document compared to the IMS.

This methodology document uses a 5x5 solutions approach including the following:

• Five conditions that must be satisfied by the IMP
• Five steps in developing an IMP
• Five questions regarding IMP development
• Five most common mistakes in IMP development
• Five templates/samples of the key IMP sections
• The chart below shows the 5x5 Methodology

Five Conditions That Must Be Satisfied in an IMP

There are Five major conditions the IMP must meet:

• Complete – Reflects the entire contract scope of work
• Traceable – Aligns with other program management artifacts
• Transparent – Comprehensible display of what needs to be done and how completion is measured
• Usable – Useful for developing other program management artifacts and for tracking the status of program achievements
• Controlled – Configuration-controlled, approved, and kept aligned to contract modifications

Complete

The IMP is a top-down view of the contractual work scope. It is the foundation for the IMS that is developed from the bottom-up; detailed task planning that supports specific IMP Criteria. It is essential that the IMP represent the work that must be performed. Several documents may be used to ensure that the IMP is complete.

If the IMP is being prepared as part of a proposal, then the Request for Proposal (RFP) and RFP attachments will be the primary documents to define the work to be performed. The RFP normally includes a Statement of Work (SOW) and Contract Data Requirements List (CDRL) that are invaluable in determining the scope of the IMP. Often the customer includes a program roadmap or top-level schedule that also helps define the scope of the IMP.

If the IMP is being prepared or updated after contract award, a Work Breakdown Structure (WBS) may be available. The WBS and its accompanying WBS Dictionary helps ensure that the scope of work in the IMP is complete. The WBS should be completely addressed in the IMP.

Traceable

The IMP should trace to other program artifacts. As a minimum, the IMP should trace to the WBS, SOW, and the Organizational Breakdown Structure (OBS). The SOW is essential for vertical integration from the detailed tasks to contracted work scope. The OBS is essential to identify responsibility for Accomplishments. The WBS is essential to ensure that all elements of work are represented in the IMP.

To demonstrate traceability most IMPs include cross-reference fields for WBS, OBS, and SOW. Cross-references may be at the Accomplishment Criteria level. The granularity of the IMP must be sufficient that only one OBS is listed for each Accomplishment Criteria.

Usable

An IMP is not just prepared and delivered. There are benefits from the use of the IMP. Most IMPs in development programs include Events for major design reviews such as PDR or CDR. The IMP shows the Accomplishments and the measures of Accomplishments that are essential to get through a design review. The IMP is a good top-level checklist to see what needs to be done to reach each major milestone. The cross-references in the IMP such as OBS, SOW, and WBS elements tell the managers which groups are responsible for which efforts. Through continued use, the IMP paints a picture of the program in the Program Manager’s and program team’s minds and facilitates stakeholder understanding, relating work efforts and progress to program goals and objectives.

Controlled

The IMP reflects the contracted work. The IMP is normally an approval deliverable. For these reasons, the IMP should be a configuration controlled document. When the contract is modified with additional scope, the IMP should be updated and aligned with the IMS accordingly. In a controlled environment, anytime the contract is changed or a Baseline Change Request is approved that changes scope, the IMP should be reviewed and revised—if required. If the organization is restructured or the WBS is changed, review the IMP and update it accordingly.

Five Steps in IMP Development

Developing an IMP takes these five key steps:

• Collect input information
• Identify Events
• Populate Events, Accomplishments, and Criteria
• Populate supporting sections of document
• Validate information with cross-references

Each of these steps is further described below:

IMP Development Environments

Sometimes an IMP has to be provided with the contract proposal. In this environment, the IMP is developed with less input material than one developed after the contract has been awarded and the project teams formed. Primary inputs are contained in the RFP and will include the Statement of Work (SOW), a top-level schedule or roadmap of the program, and a deliverables list. The personnel available for providing inputs to the IMP may be limited to the proposal team and selected functional managers. Rarely are Control Account Managers (CAM) or work package managers available for input in this environment.

When the initial IMP is prepared after contract award, it is common to have the performance team in place. CAMs are available to generate the bottom-up detail planning that fits with the top-down planning of the IMP development process. Supporting artifacts such as the WBS, WBS Dictionary, Basis of Estimates (BOE), and the Systems Engineering Management Plan (SEMP) are available to help define the scope of the work to be performed and especially the entrance and exit criteria for key program Events.

Collect Input Information

One of the most challenging tasks in IMP development is taking different artifacts that each have a distinct view of the project and combine them to show the program by Events and Significant Accomplishments. The chart on the next page shows the key inputs for the development of the IMP.