Five Principles and Practices to Increase the Probability of Project Success

Project failure starts when we can't tell what done looks like in the absence of meaningful units of measure of progress to plan. Without some agreement on our vision of Done, we'll never recognize it when it arrives, except when we've run out of time, money, or both.

Recognizing what Done looks like, no matter the domain or context, starts with describing the Technical and Operational Capabilities needed to accomplish a mission or fulfill a business strategy.

Five Immutable Principles of Project Success

The Five Immutable Principles are simple and easily recognized, based on Systems Engineering and Program Management principles with conscious and intentional actions.

1. What does "Done" look like in units of measure meaningful to the Decision Makers? ? We need to know where we are going by defining "done" at some point in the future. This may be far in the future—months or years—or closer—days or weeks from now.
2. What is the Plan to Reach "Done" at the needed time, for the needed budget, with needed outcomes? ? We need the plan to reach done for the needed cost, at the needed time, with the needed Capabilities. This plan can be simple or complex. The fidelity of the plan depends on our tolerance for Risk. The complexity of the plan has to match the complexity of the Program.
3. Are there enough of the needed resources to successfully complete the Program? ? We must understand what resources are needed at the right time to execute the plan successfully. We need to know how much time and money is required to reach the destination as needed. This can be fixed, or it can be variable. If money is limited, Program success may be possible if more time is available and vice versa. What technologies are needed? What must information be discovered that we don't know now? How is this discovery process funded? What is Margin and Management Reserve needed to protect the plan from cost, schedule, and technical Risk?
4. What impediments to progress will be encountered along the way to Done, and what are the needed handling strategies? ? this provides means to correct, prevent, remove, avoid, or ignore the impediments. Importantly, we need to ask and answer the question, "How long are we willing to wait before we find out we are late?"
5. How is progress in planning be assessed in meaningful units of measure? ? We need to measure planned progress, not just progress. Progress to plan is best measured as Physical Percent Complete (P%C), providing tangible evidence, not just opinion. This evidence must be in "usable" outcomes the acquirer recognizes as requested from the Program to enable the Capabilities to accomplish the mission or fulfill a strategy.

These Five Immutable Principles are applicable in any domain where Programs are the means of producing solutions. These principles are based on Five Practices known to work across all Program domains in which they are being applied.

Five Practices to Implement the Five Principles

With Five Principles in place, enabling their success starts with Five Practices. Each of the Five Practices, like the Five Principles, is needed for Program success. There are noshort-cutss to success, no skipping any Principles, Processes, or Practice.

The Five Practices may seem obvious, but the obvious is only sometimes found in the Program domain. If it were, more Programs would be successful. Figure 1 shows the Five Practices, their relationships to one another, and the top-level outcomes needed to increase the probability of any Program's success. Each Practice creates outcomes used by executing the Practice.

Each Practice produces outcomes used as feedback to the other Practices. The first four Practices are supported by the Fifth Practice ? Continuous Risk Management. Every action done in the first four must be assessed for explicit and latent risks to the success of the Program.

This flow shows increasing visibility of what Done looks like starting with identifying the needed capabilities. Only then do the technical and operational requirements have a home – a reason for being there. Capabilities begin with a Concept of Operations, with scenarios, use cases, or narratives from the stakeholder's point of view. These connect data and Practices, a sequenced process flow, and the Measures of Effectiveness and Performance for the Capability in the ConOps.

The Five Practices are the foundation of the implementation of the Five Principles:

1.????Identify Needed Capabilities ? The first and most crucial Process is the discovery of what capabilities are needed for the success of the Program. To achieve Program objectives or particular end states, we need to define these capabilities through scenarios from the customer's point of view, using the customer's Measure of Effectiveness (MoE) in units meaningful to the decision maker. These Effectiveness measures state how well the results from the Program enable a business process, fulfill a strategy, or accomplish a mission of the business.

2.????Identify Baseline Requirements ? Define technical and operational requirements that will fulfill the needed capabilities; stipulate the resulting product or service's planned time, cost, and technical performance. Every requirement is traceable to work, all work is traceable to at least one condition, and each condition is traceable to each capability. The baseline requirements must be defined in terms isolated from any implementation, technical products, or Practices.

Only then can requirements be bound with a technology. This means the managers of the Program should wait as long as possible to determine the technical solution to the requirements. Only when the conditions have been defined and traced back to the needed capabilities should candidates for the technical solution be considered. If this decision is made too soon, the commitment to a specific technology may constrain alternative solutions.

Requirements are then assessed using their Measures of Performance (MoP) in fulfilling the Measures of Effectiveness to provide value to the customers' business or mission; in other words, we must determine whether the requirements we've established will meet the customers' needs.

3.????Develop a Performance Measurement Baseline (PMB) ? Once we have established the capabilities and requirements, we can determine the sequence of the work, the budget for this work, the outcomes from the work effort, the Measures of Performance, and the risk-reduction activities for each outcome that ensures progress is being made as planned. The PMB is our guide for managing the Program. It is not cast in stone but a map to "done." And like all maps, it needs to be reevaluated along the way to confirm we are on the right path to "done."

4.????Execute the Performance Measurement Baseline ? Take each element of work and perform it in the planned order, ensuring all work is completed successfully before proceeding to the next element. During execution, we measure Program performance through adherence to cost, schedule, and Technical Performance Measurements (TPM), and their supporting Key Performance Parameters (KPP).

5.????Perform Continuous Risk Management ? During each of the four preceding Practices, we'll need to manage Risk by (i) identifying, (ii) analyzing, (iii) planning, (iv) tracking, controlling, and (v) communicating each technical and Programmatic Risk, and taking corrective actions to reduce Risk and increase the probability of the Program's success.

Systems Engineering is the Anchor of All Project Success

The International Council on Systems Engineering (INCOSE) describes Systems Engineering as "an interdisciplinary approach and means to enable the realization of successful systems, focused on defining customer needs and required functionality early.?

Systems Engineering is as an iterative process of top-down synthesis, development, and operation of a real-world system that satisfies, in a near-optimal manner, the full range of requirements for the system."

Using the First Principle of Program Success – What Does Done Look Like in Units of Measure Meaningful to the Decision Makers requires specific measures based on Systems Engineering Principles ? these Measures are:

Measures of Effectiveness (MOE)

Measures of Effectiveness (MOE) correspond to mission accomplishment and achievement of desired program capabilities. MOEs assess changes in system behaviors, capabilities, or operational environments and measure of the attainment of an end state, achievement of an objective, or creation of an effect. A MOE is a criterion to assess changes in system behavior, capability, or operational environment, tied to measuring the attainment of an end state, an objective, or the creation of an effect produced by the system, measuring the relevance of performed actions.

Measures of Effectiveness are …

• They are stated in units meaningful to the stakeholder of the needed Capability to accomplish the mission or fulfill a strategy.
• They are focused on capabilities independent of any technical implementation.
• Traceable to the technical and operational attributes of mission success.

Measures of Effeciveness Belong to the End User

Measures of Performance (MOP)

Measures of Performance (MOP) are the performance characteristics that the system must exhibit when fielded and operated in its intended environment and necessary to achieve the MOEs. MOPs are necessary for correlation to specific MOEs to determine optimal levels of effort for objective achievement.

The MOP measures attributes considered essential to ensure the system has the capability to achieve its objectives and implement the Measures of Effectiveness.

Measures of Performance are …

• Attributes assuring the system has the capability and capacity to perform as needed,
• Assessments of the system to ensure it meets design requirements to satisfy the MOEs.
• Developed by the Systems Engineer, Measured By Technical Managers, and Analyzed by Performance Managers.

Measures of Performance Belong to the Project Management Process

Technical Performance Measures (TPM)

Technical Performance Measures (TPM) are physical or functional characteristics of the system associated with or established from the MOPs deemed critical to mission success.

TPMs are monitored during implementation by comparing the actual achievements of the best estimate of a parameter with the values anticipated at current and projected dates.

Technical Performance Measures …

• Assess design progress against needed technical and operational capabilities,
• Define compliance with technical and operational performance requirements,
• Identify technical, cost, and performance risks,
• Are limited to critical thresholds,
• Include projected planned performance and are the basis of assessing the current performance.

Technical Performance Measures are …

• Assessments of the system's increasing technical or operational performance are chosen as indicators of the increasing maturity of the produced Capabilities to accomplish a mission or fulfill a strategy. They are based on technical or operational requirements of high Risk or significance ? e.g., mass, power, data rate, or "…ilities." (maintainability, serviceability, reliability)
• Analogous to the Programmatic measures of expected total cost or estimated time?to?completion with required performance, current best estimate, and trend line.
• Indicators that when reserve allocations or trends do not meet the final performance trigger corrective actions and are tracked so Systems Engineers or Program Managers can assess progress to plan and the Risk associated with each TPM.

Technical Performance Measures enable …

• The delivered system value is to be estimated by extending the TPM trend line and using recommended contingency values for each Program phase.
• The Program life trend?to?date, current value, and forecast of all TPMs to be periodically reviewed (typically monthly) and at all major milestone reviews for performance.
• The tracking of technical performance and comparing it to resource growth provide an early warning system to detect deficiencies or excesses.
• Reserve allocations are to be narrowed as the design proceeds.

Figure 2 shows how Technical Performance Measures are connected to Measures of Effectiveness, Measures of Performance, and Key Performance Parameters, all Risk-Informed, to assess the Physical Percent Complete of the Program's current progress to plan compared to the planned progress to plan.

When this progress in planning does not meet the actual progress to plan, corrective and preventive actions must be taken to get the Program cost, schedule, and technical performance Back to Green and define the actions needed to Keep the Program Green.

Key Performance Parameters (KPP)

Key Performance Parameters (KPP) are a critical subset of the performance parameters representing the most critical capabilities and characteristics so significant that failure to meet their threshold values of the performance can be cause for system reevaluation or reassessment for termination.

For R&D, Safety, and Mission Assurance (S&MA) or similar high-risk programs, KPPs are defined in measurable engineering units relevant and meaningful to future system development as a basis of a reference design.

A threshold value is established for the minimum acceptable performance from a system developer's standpoint. A goal value is specified as the intended value to be achieved from the technology development or research investigation.

Key Performance Parameters …

• Have threshold or objective values,
• Characterize the significant drivers of technical and operational performance and
• Are Critical to Customer (CTC).

KPPs are identified in a Capability-Based Plan specifying operational requirements and a Capability Production Document capturing information necessary to support the production, testing, and deployment of affordable and supportable increments within the acquisition strategy.

Example Project Connecting MOEs, MOPs, and TPMs

Starting with needed Capabilities to accomplish a mission or fulfill a business strategy, Program success is enabled by defining Measures of Effectiveness (MOE) and their Key Performance Parameters (KPP). With these, the Measures of Effectiveness (MOE) are implemented by Measures of Performance (MOP). Technical Performance Measures (TPM) are defined for each technical and operational capability. With these measures, a Risk-Adjusted Plan to deliver the Capabilities is created. The example below is for a precision approach autonomous landing system of a military aircraft.

Starting with Measures of Effectiveness for a Precision Approach Landing System mission to get a US Navy F?18 on the deck of an aircraft carrier hands-off. Then moving to the attributes of the Key Performance Parameters inside an acquisition framework. Then moving to the system performance measures of the end product and the Technical Performance Measures of the components making up the system and its operational architecture.

For each Program deliverable, these measures are defined in units of measure meaningful to the decision-makers.

Managing in the Presence of Uncertainty Creating Technical and Programmatic Risk

Risk-Informed Decision Making starts with recognizing All Risk comes from uncertainty, and uncertainty comes in three forms, two of which are applicable to Program Management.

Aleatory uncertainty is a naturally occurring variance in cost, schedule, and technical performance created by underlying and stochastic Practices, modeled with Monte Carlo Simulation (MCS). A stochastic process is any process describing the evolution in time of a random phenomenon, and the weather is an example of a stochastic process.

Epistemic uncertainties are event base uncertainties from a probabilistic process requiring capturing, modeling of impacts, defining handling strategies, modeling the effectiveness of these handling efforts, their residual risks, and impacts of both the original Risk and any residual risk after handling on the Program.

Risk Management starts with estimating the probability of Epistemic Event Based Risks and the Statistical Variance of the Aleatory uncertainty of the normal work.

• Aleatory Uncertainty is the dominant source of the Program’s risk to cost, schedule, and technical performance from the natural variability of Program Practices. Aleatory uncertainty and its Risk can only be handled with Margin ? Cost, Schedule, and Technical margin. This margin is usually not funded but provided under Management Reserve or Contingency since there is no specific probability of occurrence of the uncertainty, just a stochastic process generating uncertainty.
• Epistemic uncertainty and resulting Risk are discovered through a knowledge elicitation process, placed in the risk register, assigned a risk handling strategy, and funded in the Performance Measurement Baseline.