Chapter 0 of Performance Based Project Management (sm)

Performance-Based Project Management(sm) integrates Principles, Practices, and Processes to assure actionable information is provided to the decision makers that can increase the probability of program success.

1

0 Performance-Based Project Management(sm)

in a Nutshell

Chapter

Chapter 0 Performance-Based Project Management(sm), Copyright © Glen B. Alleman, 2012, 2013

Chapter 0 2

Performance-Based Project Management Management(sm)

In A Nutshell 5 Principles, 5 Practices, and 5 Processes to Increase The Probability of Project Success

Performance-Based Project Management(sm), Copyright © Glen B. Alleman, 2012, 2013


Why Performance-Based Project Management(sm)?

§  For projects to be successful they must deliver capabilities: §  Not the work efforts, §  Not the cost expenditures, §  Not the documentation, test

results, or the processes.

§  Projects must deliver tangible beneficial outcomes, measured in units meaningful to the decision makers.

3/230

Performance-Based Project Management(sm)

Principles, Practices, and Processes for Increasing the Probability of Project

Success†

† Program Success Probability, John Higbee, Defense Acquisition University, 9 May 2005


1.  What Does DONE Look Like?

2.  How Do We Get to DONE?

3.  Is There Enough Time, Resources, And Money To Get to DONE?

4.  What Impediments Will Be Encountered Along The Way to DONE?

5.  What Are The Units Of Measures For Progress To Plan for each Deliverable?

Five Immutable Principles of Project Success in the form of questions …

4 Performance-Based Project Management(sm), Copyright © Glen B. Alleman, 2012, 2013

5 Critical Process Areas that Answer the 5 Principle Questions of Project Success

5

¨  Define the Work Breakdown Structure(WBS).

¨  Indentify the Organizational Breakdown Structure (OBS).

¨  Integrate the WBS and OBS.

¨  1. Organization

¨  Schedule the work. ¨  Identify the Products and

Milestones. ¨  Set the time phased budget.

2. Planning and Budgeting

¨  Record direct costs. 3. Accounting

¨  Determine variances. ¨  Sum Data and variances.

¨  Manage action plans.

4. Performance Analysis

¨  Incorporate Changes.

5. Revision Management


Cha

pter

0

Credible Data Is Need 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)

6

Cha

pter

0


Systems Management Guides the Conversion of this Data to Produce 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.

¨  PBPM connects the data to provide actionable information to the decision makers.

7


Cha

pter

0

16 Program Management Processes 8

Program Enablers

Program Process Capabilities

Business Enablers

Cha

pter

0


Origins of Performance-Based Project Management(sm)

9

¨  This is 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

Cha

pter

0


Performance-Based Project Management(sm) 4+1 questions every project must answer

Performance-Based Project Management(sm) integrates five critical program management process areas with – Cost, Schedule, and Technical Performance Measures.

The inclusion of Technical Performance Measures (TPM) separates is 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 Performance-Based Project Management(sm), 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.

10


Cha

pter

0

The 4+1 Questions Every 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 0 11 Performance-Based Project Management(sm), Copyright © Glen B. Alleman, 2012, 2013

Performance-Based Project Management(sm) Addresses …

Project Management Case Study, Pierre Bonnal, CNAM IIM MBA Program, June 2004

12

Cha

pter

0

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

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 0 13 Performance-Based Project Management(sm), Copyright © Glen B. Alleman, 2012, 2013

Increasing the Maturity of Project Processes and Deliverables with Meaningful Measures

1.  Identify Needed Capabilities to achieve program objectives or a 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 and planned cost. Define these requirements in terms that are isolated from any implementation technical products or processes. Only then bind the requirements with technology.

3.  Establish a 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 assessments are 0%/100% complete before proceeding. No rework, no transfer of activities to the future. Assure all requirement are traceable to work and all work is traceable to requirements.

5.  Perform Continuous Risk Management for each Performance-Based Project Management(sm) 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 Performance-Based Project Management(sm).

Each process area stands alone and at the same time is coupled with the other process areas. Each process area contains specific 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 ways not know until the project is too far along to be recovered.

Each process provides information needed to make decisions about the maturity flow of the project. This actionable information is the feedback mechanism needed to keep a project under control. These control processes are not impediments to progress, but are the tools needed to increase the probability of success.

Cha

pter

0

14


Identify Needed

Capabilities

Indentify Baseline

Requirements

Establish Performance Measurement

Baseline

Execute Performance Measurement

Baseline

§ Define Capabilities § Define ConOps § Assess Needs, Cost, and

Risk Impacts § Define Balanced and

Feasible Alternatives

§ Fact Finding § Gather And Classify § Evaluate And

Rationalize § Prioritize Requirements § Integrate And Validate

§ Decompose Scope § Assign Accountability § Arrange Work § Develop BCWS § Assign Performance

§ Perform Work § Accumulate

Performance Measures § Analyze Performance § Take Corrective Action

Perform Continuous Risk Management (CRM)

Define the Measurable Capabilities of each

Project Outcome

Assure All Requirements Provided In Support of

Capabilities

Define Measures of Performance and

Effectiveness

Ensure Cost, Schedule, and Technical

Performance Compliance

Cha

pter

0

15

Increasing the Maturity of Project Work Processes and Their Deliverables


What is a Deliverable?

Project Management Case Study, Pierre Bonnal, CNAM IIM MBA Program, June 2004.

Cha

pter

0

16

Define the set of 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 Performance-Based Project Management(sm) process area to: Identify, Analyze, Plan, Track, Control, and Communicate programmatic and technical risk.

�


§ 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.

§ 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

�


What Does A Capability “Sound” Like?

Cha

pter

0

19


Identifying Needed System Capabilities

Identifying System Capabilities is the starting point for any successful program. System Capabilities are not direct requirements, but statements of what the system should provide in terms of “abilities.” For example there are three capabilities needed for the Hubble Robotic Service 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 known 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 statements 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 are fulfilled by the program.

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. Success means providing the needed capabilities, on or near schedule and cost.

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 Use Cases and scenarios to provide the context to measure the level of capability.

20

Cha

pter

0


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


21

Cha

pter

0


§ 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.

§ 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

�


What Is a Requirement? 23

Cha

pter

0


Identifying Requirements

Requirements are defined attributes for an item prior to the efforts to develop a design for that 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.

Requirements act as the transformation between the customer’s capabilities 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

Process Performance Requirements define how the work processes are used to produce a beneficial outcome to the customer.

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 product 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 (WBS). 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 are “foot and tied” to the Performance Measurement Baseline (PMB) to provide the traceability of the increasing maturity of the deliverables (vertical) and the physical percent complete of the work efforts (horizontal).

24

Cha

pter

0


Identifying Requirements†

†Systems Requirements Practices, Jeffery O. Grady, McGraw Hill, 1993

25

Cha

pter

0


Build a time–phased network 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

�


What Does a Credible Plan and Schedule Look Like?

27

Cha

pter

0


Establishing the Three Elements 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 Performance-Based Project Management(sm) is.

§  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.

There are three elements to the Performance Measurement Baseline:

The Technical Performance Baseline represents 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 DI-MGMT-81861.

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.

28

Cha

pter

0


Establishing the Three Elements of the Performance Measurement Baseline

Cost Baseline

Schedule Baseline

Technical Baseline

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

Requirement

Prepare Cost

Estimate

Resource Load

Schedule

Finalize Apportioned

Milestones

Determine Funding

Constraints

Approve PMB

29

Cha

pter

0

Perform Functional Analysis


Execute the planned work, 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

�


How Do We Know We Are Making Progress to Plan?

31

Cha

pter

0


Executing the Performance Measurement Baseline (PMB)

With the Performance Measurement Baseline established, its execution is now the next critical activity.

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 Performance-Based Project Management(sm) 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 Performance-Based Project Management(sm).

The measures of physical percent complete can be applied on weekly boundaries in a variety of 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.

32

Cha

pter

0


Executing the Performance Measurement Baseline (PMB)

33

Cha

pter

0


§ Identify and classify 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

�


Ana lyze

P lan

Trac k

Con t ro l

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 35

Cha

pter

0


Integrating all the Parts Into a Whole

For project success to have a chance, we need all the parts of the project’s architecture to be in place.

This starts with the Statement of Work (SOW), the Concept of Operations (ConOps), Statement of Objectives (SOO)and similar narrative documents and supporting graphics showing what the system will do, who is involved, and the artifacts and outcomes of the results from the project.

With these in hand, we can build the Work Breakdown Structure (WBS) for the deliverables. The WBS is product centric, along with the services that produce the products. The WBS does not describe the organizations producing the products. That is done in the Organizational Breakdown Structure (OBS). At the terminal nodes of he WBS are the Work Packages that produce the deliverables.

From the WBS, the technical and operational requirements can be derived. These define the behaviors of the deliverables through Key Performance Parameters. The customer’s KPPs come first, followed by the project’s KPPs in the CWBS.

The Integrated Master Plan (IMP) describes the Program Events, Significant Accomplishments, and Accomplishment Criteria needed to increase the maturity of each deliverable through the project’s lifecycle. The IMP is the single most important document for properly executing the project. Without the IMP, we cannot tell what Done looks like.

From the IMP, the Integrated Master Schedule (IMS) is developed. The IMS sequences the Work Packages that perform the work to produce the deliverables. This sequence defines the critical path, the resources needed to perform the work, the order of the work, and the dependencies between the work efforts.

Using the IMS, the Earned Value Management techniques for each Work Package is defined. Measures of Physical Percent Complete are the best choice.

For each Work Package, Technical Performance Measures (TPM) are used to assure the resulting outcomes meet the requirements of the SOW, SOO, and ConOps.

With all these components, the Performance Measurement Baseline can be established, showing the time phased budget, work effort, deliverables, and assessment of increasing maturity of the outcomes.

36

Cha

pter

0


Integrating all the Parts into a Whole 37

Risk Management

SOO ConOps SOW Techncial and Opera9onal

Requirements

CWBS & CWBS Dic9onary

Integrated Master Plan (IMP)

Integrated Master Schedule (IMS)

Measures of Effec9veness

(MoE)

Measures of Performance

(MoP)

Measures of Progress

Customer Key Performance Parameters

(JROC KPP)

Program Specific Key Performance Parameters

(KPP)

Technical Performance Measures (TPM)

Earned Value Management System

Performance Measurement Baseline

Objec9ve Status and Essen9al Views to support the proac9ve management processes needed to keep the program GREEN

Cha

pter

0

WBS

From Mission Capabilities to Done

Measures of Effectiveness (MoE) – 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.

These measures are stated in units ,meaningful to the buyer. They focus on the capabilities independent of any technical implementation.

Measures of Performance (MoP) – characterize physical or functional attributes relating to the system operation, measured or estimated under specific conditions.

These measures are attributes that assure the system has the capability and capacity to perform. They are an assessment of the system to assure it meets the design requirements to satisfy the Measures of Effectiveness.

Key Performance Parameters (KPP) – Represent the capabilities and characteristics so significant that failure to meet them can be cause for reevaluation, reassessing, or termination of the program. KPPs have a threshold or objective value that characterize the major drivers of performance that are considered Critical to Customer (CTC).

Technical Performance Measures (TPM) – are attributes that determine how well a system or system element is satisfying or expected to satisfy a technical requirement or goal.

TPMs assess design progress, define compliance to performance requirements, identify technical risk, are limited to critical thresholds, and include projected performance goals.

Connecting the Mission Need – capabilities produced by the project – with the MoEs, MoPs, KPPs, and TPMs must be done for the project to have a chance of success.

38

Cha

pter

0


From Mission Capabilities to Done 39

Cha

pter

0

“Coming to Grips with Measures of Effec9veness,” N. Sproles, Systems Engineering, Volume 3, Number 1, pp. 50–58

MoE

KPP

MoP TPM Mission Need

Acquirer Defines the Needs and Capabili9es in terms of Opera9onal Scenarios

Supplier Defines Physical Solu9ons that meet the needs of the Stakeholders

Opera&onal measures of success related to the achievement of the mission or opera&onal objec&ve being evaluated.

Measures that characterize physical or func&onal a<ributes rela&ng to the system opera&on.

Measures used to assess design progress, compliance to performance requirements, and technical risks.



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

Cha

pter

0

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

Cha

pter

0

Tangible Benefits of Performance-Based Project Management(sm)

P-B PM Capabilities 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

Cha

pter

0

Performance-Based Project Management(sm) 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 0 45 Performance-Based Project Management(sm), Copyright © Glen B. Alleman, 2012, 2013


Date post:	10-May-2015
Category:	Business
Upload:	glen-alleman
View:	659 times
Download:	1 times