Five Immutable Principles of Project Success

Principles are the Basis of Practices and Processes of Project Success

Successfully managing Capital projects, Software Intensive System of Systems projects, or simply planting the spring garden ? starts with the Five Immutable Principles shown to the right.

These five principles of project success are stated as questions with answers meaningful to the decision?makers:

1. Do we know what Done looks like with Measures of Effectiveness and Measures of Performance?
2. Do we have of Plan to reach Done on time, on budget, with a technical solution that delivers capabilities to satisfy the customer’s needs?
3. Do we have the Resources needed to execute this Plan? The Time, money, staff, facilities, and capacity for work needed to reach the destination?
4. Have we identified Impediments to our progress along the path to Done? Have we defined how these impediments are removed, avoided, or handled at the proper time?
5. Do we have a way to measure the Physical Percent Complete of Progress to Plan, reaching the needed Effectiveness (MOE), Performance (MOP), Technical Performance Measures (TPM), and Key Performance Parameters (KPP) for the planned cost at the planned time?

Each Principle is supported by Practices, Processes, and the Data they produce, shown below, that provide actionable information to the decision-makers.

? Identify Needed Capabilities

Identifying System Capabilities is the starting point for any successful project. The System Capabilities are not direct requirements but statements of what abilities the system must provide when it is complete. [1] Here is what some Actual Capabilities sound like:

• We need the capability to remove 1? hours from our supply chain ordering process once the merger of our two firms is complete.
• We need the capability to change the Wide Field Camera and the internal nickel hydride batteries while doing no harm to the Hubble Space Telescope.
• We need the capability to dock four oil tankers at the pier and unload their cargo in 18 hours while concurrently operating the ground transportation system.
• We need the capability to process provider applications to our new health insurance enrollment system for $0.07 a transaction rather than the current $0.22 a transaction.

How are these capabilities delivered? What are the technical and operational requirements needed to implement each capability? We may still need to find out, but a Capabilities-Based Plan (CBP) identifies program needs, allocated resources, and how work activities and outcomes will be planned and tracked. The critical reason for starting with capabilities is to establish a home for all the requirements. The CBP answers the questions of why this requirement is present. Why is this requirement needed? What business or mission value does fulfilling this requirement provide?

Capabilities statements define units for measures of project progress to plan with physical percent complete at each project level. Measuring how the Capabilities are being fulfilled is most meaningful to the customer with Measures of Effectiveness (MOE) and Measures of Performance (MOP) meaningful to the customer. Without these MOEs and MOPs, the project may be a cost, schedule, and technical success but fail to accomplish the mission or fulfill the business strategy.

By defining the needed capabilities, it is clear the mission will be a success because there needs to be a clear and concise description of what Done looks like. Success means providing the needed capabilities, on or before the needed schedule, at or below the needed budget.

?Capabilities Based Planning recognizes interdependencies of systems, strategy, organization, and support processes in the delivery of capabilities by examining options and trade-offs of performance, cost, and risk to identify development investments to produce the Capability from project Use Cases or Scenarios described in the Concept of Operations to provide the increasing measures of maturity for each delivered capability as the project progresses.

? Establish A Technical and Operational Requirements Baseline

Poorly formed requirements contribute as much as 25% to the failure modes of programs and projects. [2]

Requirements are technical and operational attributes for an item prior to the start of development for that item. Requirements analysis is a structured, organized methodology for identifying an appropriate set of technical, operational, and human resources satisfying a system's need (the needed capabilities). Requirements are the transformation between the customer’s needed capabilities and the design concept implemented by the engineering resources. [3]

The requirements engineering process decomposes a statement of a customer’s need by systematically exposing what that system must do to satisfy that need. This need is the ultimate system requirement from which all other requirements and designs flow.

There are two fundamental classes of all requirements.

• Process Performance Requirements ? define the work processes used to produce a beneficial outcome to the customer.
• Product Performance Requirements ? define the technical and operational specifications and how they relate to process requirements. [4]

Requirements methods focus on technical and operational specifications through requirements elicitation, fact-finding, classification, evaluation, rationalization, prioritization, integration, and validation of requirements. These baseline requirements define Work Packages and Planning Packages and work their efforts needed to produce deliverables from the project. These deliverables provide needed technical and operational capabilities to accomplish a mission or fulfill a business strategy.

? Establish Performance Measurement Baseline

The Performance Measurement Baseline (PMB) is a primary assessment document assuring the credibility of the project plan and its schedule. The PMB is a baseline of the cost, schedule, and technical and operational deliverables for each Work Package in the PMB.

Constructing a PMB requires knowledge of business, operational, and technical requirements, skill in developing Work Packages producing the deliverables for these requirements, and discipline in assembling cost, schedule, and relationships between the Work Packages. This discipline requires focusing on technical, planning, risk, contracting, and project controls staff. With this discipline, the development of a credible PMB is easier.

The PMB is where Measures of Effectiveness (MOE) and Measures of Performance (MOP) are defined and used to assess the physical percent complete of progress to plan in units of measure meaningful to the decision makers. Each deliverable defines as:

• The Value they produce is what customers paid money for.
• The business, technical, or operational capabilities, with the associated value fulfilling the requirements to accomplish a mission of fulfilling a business strategy.

The critical success factor in building the PMB is the decomposition of the system requirements into technical capabilities, then into deliverables that enable those technical capabilities, and finally into Work Packages that produce those deliverables. Defining decomposed deliverables 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 since there are better approaches than the first decomposition.

A credible Plan and Schedule for delivery of the needed capabilities on time and on budget have three Performance Measurement Baselines ? Technical, Schedule, and Cost:

? Execute the Performance Measurement Baseline

With an established Performance Measurement Baseline from step ?, proper execution is the next critical success factor.

The execution process is the project rhythm. These are the processes performed repeatedly – from daily to monthly. This business rhythm creates actionable information for the project manager on a time scale, allowing needed corrective actions to be taken to stay on schedule and on budget and assure compliance with the technical and operational requirements to fulfill the project’s capabilities to accomplish the mission or fulfill a business strategy.

These tangible, physical deliverables are defined in the Work Packages created during the Planning process. No matter the duration of the assessment of performance, a measure of physical percent complete is mandatory if the project manager is to be provided actionable information from the Performance Measurement Baseline. The measures of Physical Percent Complete (P%C) can be applied on periodic boundaries in a variety of ways:

• Have short-duration tangible deliverables.
• Have apportioned milestones to measure progress to plan from the deliverables.
• Have tasks short deliverable cycle and record 0%/100% complete at the end of each reporting period.

This approach provides the answer to the question:

How Long Are We Willing To Wait Before We Find Out We Are Late?

The answer must be short enough to take corrective action to stay on plan. In all cases, a measure of physical percent complete is mandatory if the project manager is to receive actionable information to stay on plan. The important process here is to have an agreed-upon measure of performance defined before the work starts.

? Perform Continuous Risk Management

Continuous Risk Management is the foundation for increasing the probability of project success by:

• Preventing problems before they occur by identifying and dealing with them early.
• Improving cost, schedule, and technical performance by focusing on project objectives and consciously looking for activities affecting these measures throughout the project lifecycle.
• Enabling better use of resources for early identification of potential problems

References

[1] Capabilities Based Planning, https://www.rand.org/topics/capabilities-based-planning.html

[2] The Requirements Engineering Handbook, Ralph R. Young, Artech House.

[3] “Issues with Requirements Elicitation,” Michael G. Christel and Kyo C. Kang, Technical Report, CMU/SEI–92–TR–12, Software Engineering Institute, Carnegie Mellon University Pittsburgh, Pennsylvania 15213.

[4] System Requirements Practices, Jeffery O. Grady, McGraw Hill, 1993.

[5] A Compendium of Risk Management Resources.

[6] The 5 Immutable \(?)i(m)-?myü-t?-b?l Principles of Project Management, Need to Increase the P robability o f P roject S uccess (PoPS) , PMI Symposium, Forth Worth, TX July 16th, 2010

\