performance-based project management in a nut shell

Performance-Based Project Management provides 5 practice areas that measurably increase the probability of success for projects and programs in every technical and business domain.

Performance-Based Project Management provides step–by–step guidance to the management team and project stakeholders through 5 process areas needed for success.

These process areas appear obvious, but the processes are many times skipped over during the “heat of the battle” to get the project out the door.

By applying Performance-Based Project Management the project team focuses their efforts on increasing the probability of success, not just measuring cost and schedule numbers.

This notion of “increasing the probability of success” is significantly different than simply applying a method and thinking that positive results will be the outcome.

If we do not have a calculated probability of a successful outcome, we can not determine if we will actually reach the end goal of the project – we can not determine what DONE looks like.

1

Performance -Based Project Management in a Nutshell

Copyright ©, Glen B. Alleman, Niwotridge Consulting, 2011

The Customer Bought Outcomes

No matter the customer is, a commercial firm deploying and enterprise IT solution, to a government agency, it is the outcome of the project that was paid for.

The work needed to produce this outcome, the materials that support the development of this outcome, all collateral activities from the project are not what the customer paid for.

They paid for the beneficial outcome from their investment in the project.

Performance-Based Project Management starts with defining what that outcome is in terms of the capabilities provided by the project.

These capabilities are the starting point for the project’s success. They are defined in Measures of Effectiveness.

These 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 a MoE that defines a capability is: “95% of all work will be completed within 15 business days or the negotiated deadline.”

This MoE is a description of what DONE looks like for the project. The project provided this capability.

2

Performance-Based Project Management in a Nutshell


The five immutable principles of project success are the mechanisms for increasing the probability of success.

1. Know where you are going by defining “done” at some point in the future. This may be far in the future – months or years from now. Or closer in the future days or weeks from now.

2. Have some kind of plan to get to where you are going. This plan can be simple or it can be complex. The fidelity of the plan depends on the tolerance for risk by the users of the plan. The plan answers the question how long are we willing to wait before we find out we are late?

3. Understand the resources needed to execute the plan. How much time and money is needed to reach the destination. This can be fixed or it can be variable.

4. Identify the impediments to progress along the way to the destination. Have some means of removing, avoiding, or ignoring these impediments.

5. Have some way to measure your planned progress, not just your progress. Progress to Plan must be measured in units of physical percent complete.


Copyright ©, Glen B. Alleman, Niwotridge Consulting, 2011 3

There are 11 practices needed to generate the data necessary to provide actionable information to the decision makers in Performance-Based Project Management

This information is connected to the 5 Immutable Principles of project management and the artifacts from the practices of the these principles.

These 11 criteria are a subset of the 32 criteria of ANSI–748B Earned Value Management.

While Earned Value is certainty not necessary for project success, some form of measuring physical progress to plan is.

Without this ability, only measures of the passage of time and consumption of resources remains.

Using these 11 practices, based on measures of physical percent complete, real progress to plan can be measured. This provides visibility into the final cost, schedule, and technical performance of the project needed to answer the question how long are we willing to wait before we fins out we are late? And provide sufficient time to take corrective actions to avoid being late, over budget, and non–compliant with the technical performance measures.

4



The connection between principles of Performance-Based Project Management and the 11 Practices is shown to the left.

The 5 Immutable Principles of Success must be connected with artifacts and outcomes of the 11 Practices that implement those principles.

If any of the 11 Practices or the 5 Principles are missing the probability of success is measurably reduced.

Each Principle and each Practice must be in place for the Probability of Project Success to increase.

That is the goal of Performance-Based Project Management – Increase the Probability of Project Success.

5



Projects exist in a Domain and a Context in that Domain. This can be a business of technical Domain and a Business or Technical Context in that domain

No matter the Domain and the Context in that Domain, projects consist of a collection of problems to be solved and needs of the stakeholders each seeking to solution.

Performance-Based Project Management provides a framework for addressing each of these elements in a cohesive and consistent manner, while providing visibility to the project’s Performance in units of measure meaningful to the decision maker.

6



When we say outcome what do we mean? We certainly don’t mean the work effort or the cost absorbed during that work effort.

We mean something tangible that benefits the customer. This tangible outcome must be assessed by the Measures of Effectiveness (MoE) that are quantitative measures that provide insight into how effectively a product or service is performing.

This product or service must provide the customer with a capability to do something tangible, something measureable, something that benefits the business or mission.

The outcome must be capable of being measured in some way as it moves from left to right in the schedule. As it increases in its maturity. The outcomes must be testable in some form. Testable Requirements are the starting point.

The outcomes are produced through Work Packages – “units of work.” These Work Packages are resource loaded, have specific periods of performance, and produce a tangible, measureable outcome that can be traced to the requirements and further traced to the needed capabilities.

7



1. Identify Needed Capabilities that achieve the program objectives or the particular end state. Define these capabilities through scenarios from the customer point of view in units of Measures 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. Define these requirements in terms that are isolated from any implementation technical products. Only then bind the requirements with technology.

3. Build The Performance Measurement Baseline – describing the work to be performed, the budgeted cost for this work, the organizational elements that produce the outcomes from this work effort, and the Measures of Performance (MoP) showing this work is proceeding according to cost, schedule, and technical Performance plan.

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 every requirement is traceable to work and all work is traceable to requirements.

5. Apply Continuous Risk Management for each Performance-Based Project Management process area to Identify, Analyze, Plan, Track, Control, and Communicate programmatic and technical risk.

8 Copyright ©, Glen B. Alleman, Niwotridge Consulting, 2011

9

With these five process areas, the next level of detail is show to the left. These are a repeat of the Performance-Based Project Management processes.

A statement of intent is the starting point for the successful application of each process area.

This statement is provided in the form of a question.

1. What are the needed capabilities?

2. What are the technical and operational requirements?

3. What is the cost and schedule?

4. What are the periodic measures of performance?

5. What are the impediments to progress?

By asking and answering these questions at every juncture of the program, the participants gain visibility into the Performance of the program in ways not found in other approaches to program management.



10

Transforming the System Capabilities into System Requirements begins with the a narrative description of the needed Capabilities in some form meaningful to the customer.

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:

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.

The four steps here result in a Concept of

Operations (ConOps) for the resulting system.

The ConOps describes the systems application

to the problem domain and how the system will

produce measurable value to the user in that

domain.

The ConOps is the story of how the system will

work when it is delivered to the customer.



Here are some examples of capabilities. They appear obvious.

But in many instances this approach is missing. The requirements are many time 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.

11



Requirements are the 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.

Requirements elicitation acts as the transformation between the customer’s system needs and the design concept implemented by the organization’s engineering resources.

The basic 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.

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.



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 Project Management method concentrates instead on elicitation.

This method addresses problems found with requirements engineering that are not adequately addressed by specification techniques.

This Performance-Based Project Management 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.

13



14

The Performance Measurement Baseline (PMB) is the primary assessment document for assuring the credibility of a project plan. The PMB is the baseline of the cost, schedule and outcomes 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 outcomes 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 project controls staff. Without this discipline, the development of a credible baseline is simply not possible.

The concept of a producing measureable outcomes is at the core of the Performance Measurement Baseline (PMB).

Outcomes are the units of measure of progress to plan.

Outcomes are what the customer has paid money for.

Outcomes contain the business capabilities, the associated value that fulfill the requirements of the business plan



The critical success factor in building the Performance Measurement Baseline (PMB) is the decomposition of the system requirements into technical capabilities, then into outcomes that enable those technical capabilities, and finally into the Work Packages (WP)that produce those outcomes.

Performance-Based Project Management using WPs includes:

Defining the decomposed outcomes 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 estimate 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.

15



16

With the Performance Measurement Baseline established, its execution becomes critically important.

The execution process is called the “project 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 allows actions to be taken.

These tangible, physical outcomes must be defined in the work packaged created during the Planning process of Performance-Based Project Management.

The measures of physical percent complete can be applied on weekly boundaries in a variety of ways:

1. Have weekly outcomes.

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 focus of Performance Measurement Baseline execution steps is to physically assess the progress of the program in units reflecting the progress using the three independent variables: C,S,P

Cost Schedule Performance both technical and

programmatic

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 Work Package Manager. 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.

17



18

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



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 project’s objectives and consciously looks for things that may effect quality throughout the project 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.



Traditional project management methods are usually focused on the activities of the project management method. Process Groups and Knowledge Areas of PMBOK®.

These Groups and Knowledge Areas are necessary for project success.

But they may not be sufficient.

Using these baseline processes, project management activities are guided by field proven examples.

20



Using traditional project management process groups and knowledge areas, Performance-Based Project Management adds the concept of Capabilities.

As well the integration of Cost, Schedule, and Technical Performance Measures (TPM) in the Performance Measurement Baseline (PMB).

The Work Packages (WP) of the PMB contain the measures of Physical Percent Complete for the individual outcomes of each Work Package.

21



Performance-Based Project Management 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 outcomes 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 outcomes they produce. Performance-Based Project Management 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).

Conventional approaches use the cost and schedule baseline and the variances generate the values for Earned Value.

Performance-Based Project Management, measures of Physical Percent Complete derived from pre–defined targets of Technical Performance.

The Earned Value variables are augmented with adjustments from the Technical Performance compliance for each outcome 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.


Performance-Based Project Management provides tools, processes, and training needed to increase the probability of success of a projects.

This approach is unique in its integration of the critical success factors for projects, no matter the domain.

Our approach answers the following 5 immutable principles:

1. Where are we going?

Do we have a definitive description of the needed capabilities and the requirements needed to deliver those capabilities?

2. How do we get there?

What is the sequence of the work efforts to achieve the plan?

3. Do we have enough time, resources, and money to get there?

Are the resources properly allocated to the sequence of work activities?

4. What impediments will we encounter along the way?

Have we captured the risks and their handling plans for all the critical work activities?

5. How do we know we are making progress?

Can we measure progress to plan in units meaningful to the decision makers?

24



Here’s my contact information.

If you have questions that weren’t answered here, would like a soft copy of this briefing or any others from today or last night’s PMI Chapter meeting, please drop me a note.

The 5 Immutable Principles of Project Management 25/58

Copyright ® 2012, Glen B. Alleman, All Rights Reserved

performance-based project management in a nut shell

Technology

project success

bythe project

getthe project

project arenot

probabilityof success

probability of success

kind of plan

projects success