Project Success: Applying the Five Immutable Principles ?

Some people in the field talk about the “basic tenets” of project management. Where do these come from? Some say they come from hands-on experience, anecdotal “best practices,” and the good old “school of hard knocks.”

According to Webster’s Dictionary, a principle is a “general truth, a law on which other laws are founded or from which others are derived.” According to A Project Management Dictionary of Terms, a principle can be further defined as:

• A rule or law of action based on desirable ends or objectives based on a fundamental set of actions. Principles are the basis of policies or procedures that govern the behavior of the people, processes, and tools used on a project. One common principle is, “time is money.” In all project work, this is the case. If work is being done, time is passing, and people must be paid for their time.
• A fundamental truth that can explain the relationship between project variables—usually cost, time, or technical attributes.

These can be independent and dependent variables in this relationship. This fundamental truth can be descriptive, explaining what will happen; or it can be prescriptive, indicating what a person, a process, or a tool should do based on some known standard.

The principle also can reflect a scale of values, such as efficiency, reliability, availability, or other “…ilities.” In this case, …ilities imply value judgments as well as actual measurements. In another example, cost and schedule are directly related through some multiplicative factor.

The more time the project takes, assuming constant productivity of the labor, the larger the cost will be for that labor. Quality, cost, and schedule performance can be described in the same way, with the same productivity factors. The technical performance of the planned deliverables is also related to cost and schedule in the same way.

For the principles of project management to be effective, Max Wideman suggests they must do the following:

• Express a general or fundamental truth [or] a basic concept
• Make for a high probability of project success. The corollary is that the absence of the condition will render project success on a majority of the key criteria as being highly improbable.
• Provide the basis for establishing logical processes and supporting practices that can be proven through research, analysis, and practical testing
• Be universal to all areas of project management application
• Be capable of straightforward expression in one or two sentences
• Be self-evident to experienced project management personnel
• Carry a concise label reflecting its content

Five Immutable Principles

The five immutable principles of performance-based project management are designed to meet both the definitions of a principle and Wideman’s requirement that they be effective. Here, they are stated as questions that need to be answered by the project manager:

1.????Where are we going?

2.????How are we going to get there?

3.????Do we have everything we need?

4.????What impediments will we encounter, and how will we remove them?

5.????How are we going to measure our progress?

These questions can be applied to projects just as they can be applied to any endeavor, from flying to Mars to taking a family vacation. If we use the dictionary definition of immutable, “not subject or susceptible to change or variation in form or quality or nature,” we can apply these principles to any project in any business or technical domain.

Five Practices

The five practices, which are derived from the five immutable principles, are used to keep the project on track.

1.????Identify needed capabilities

2.????Define a requirements baseline

3.????Develop a performance measurement baseline

4.????Execute the performance measurement baseline

5.????Apply continuous risk management

Ten Processes Used to Implement the Five Practices

These 10 processes are the foundation for the immutable principles and practices for project success.

1. Capabilities drive system requirements. Capabilities provide the customer with the means to generate business or mission value. With these capabilities in hand, the mission or business need can be carried out and the desired beneficial outcome produced from the project. If we understand what capabilities are needed to produce business value or satisfy a mission, we can then identify what technical or operational requirements are needed to deliver those capabilities.
2. Requirements are defined in work packages. Requirements are derived from the needed capabilities by asking and answering the question, “How can this capability be delivered using the technical or operational solutions at hand?” The mechanisms for implementing a capability are described in a requirement. Requirements state the “shalls” of the solution in support of a capability. The requirements are implemented in work packages, which produce deliverables that are assembled into the capability that produces the products or services needed by the customer.
3. Work packages produce the deliverables. This is where labor and materials come together; it is where the work needed to produce the components of products or services is done.
4. The performance measurement baseline (PMB) describes the work sequence. The PMB is the time-phased arrangement of the work packages that produce usable results in a planned order to produce the desired product or service.
5. Measures of physical percent complete define “done” for each work package. Working software, usable products, or services, all measured in predefined units of “physical percent complete,” provide the evidence needed to demonstrate that work is progressing according to plan.
6. Work authorization assures proper delivery of value. Keeping the work flowing to maximize the delivered product or service requires a well-structured schedule.
7. Produced and measurable value defines progress. Measurement in units of effectiveness and performance for the user is the definition of value that all projects require.
8. All measures are adjusted for technical performance compliance. Performance to plan is adjusted for the technical and operational aspects of the project, not just the passage of time and consumption of resources. These adjustments are necessary to correct our measures of the effectiveness of our cost and schedule. If we planned to complete a deliverable in a specific amount of time for a specific amount of money and that deliverable was not technically compliant, we would have to spend more money and time to finish it. Therefore, we would be over budget and late on the planned day of completion of our deliverable.
9. Fulfilled requirements produce delivered capabilities. With the requirement fulfilled by products or services, the capabilities can be deployed to the customer.
10. Past performance is a forecast of future performance. For all measurements of future performance, what happened before is a good starting point.

These 10 “driving” processes illustrate the various activities applied across the life cycle of a project or program. They start at the inception of the project (driver 1) and the initial assessment of the business’s or system’s capabilities and continue through requirements elicitation (process 2) and the creation of the PMB describing the time-phased work and its budget (processes 3 and 4), to the execution of the baseline (processes 6, 7, and 8) and project close-out (processes 9 and 10).

The processes of performance-based project management provide feedback loops to assure that subsequent activities provide measurable information about the corrective actions needed to increase the probability of success. This repeated step-by-step approach to project management assures that the periods of assessment provided for corrective actions are appropriately spaced to minimize risk and maximize the delivered value to the project.

The 10 processes are the basis of the principles and practices of performance-based project management, and each is present in every project domain, every business paradigm, and every project management method. If the driver is not recognized and dealt with, it will still “drive” the project outcome, whether the project manager looks after its performance or not. For example, if the work is performed out of sequence, the project is missing driver 6. Work authorization and the work products may need rework. If we install the wallboard in the house before the electrical wiring, we will have to cut the wallboard to pull the wiring.

Putting the Ten Processes to Work

The first process of project success is the principle that all technical and operational requirements must be derived from the needed capabilities.

We hear all the time about bloated software products, with features no one uses. But what we don’t hear about is how to address this supposed issue. It turns out all the capabilities in those products are needed by someone—maybe not us, but someone. They are there for a purpose. Maybe not the right purpose, but they didn’t get there by accident. Knowing up front what capabilities are needed for a product is not an accident, either. This is the role of capabilities-based planning. What capabilities do we need for the project to be successful?

Defining a capability creates the flexibility needed to ensure system responsiveness and sustainability in the presence of constant change.

At the same time, we need to deliver tangible benefits to the user. These capabilities may include:

Agility. Adapting to emerging situations that had not been planned for or even foreseen.

Tailorability. Changing the behavior of the product or service to meet emerging needs.

Architecture. Measuring the coupling and cohesion (interrelationships) between the business processes that support agility and tailorability with the least amount of disruption to previously developed project outcomes. Project governance provides the guidance needed to institutionalize a capabilities-based approach. Project governance requires continued assessment and evolution in support of the tangible benefits:

• Enforcement of rules and responsibilities of the organization and its members
• Guidance of the flow of work to sustain the needed performance of the business or mission
• Continuous improvement of the people, processes, and tools
• Facilitation of transformation from the current state to some desired future state.

The core concept of capabilities-based planning is its focus on the delivery of business or mission value, or “value-focused thinking,” which, in turn, is based on two methods for making decisions: the first focuses on competitive analysis of the various alternatives, and the second on attaining organizational values as the fundamental objective of any decision-making process.

To describe each capability, assumptions must be made without any specific technical and operational information. To avoid unwelcome surprises, some form of assumptions-based planning is needed. This requires taking five actions:

1. Make operational plans about how we are going to use the capabilities that result from the project (“What would we do with the products or services if they showed up tomorrow and were free?”).
2. Describe plausible events—that is, the things we know have a chance of happening.
3. Identify the signposts for potential problems that can then be used to monitor the things that can go wrong with our project.
4. Discover shaping actions that shore up uncertain assumptions about the future. We can’t control the weather, but we can control whether we are going to eat outside or stay in.
5. Take hedging actions to better prepare for the possibility that an assumption will fail by thinking through plausible scenarios to test the assumptions.?This what-if approach is at the core of good project risk management.

Capabilities-based planning makes use of these assumption-development processes to describe system capabilities when there are no specific technical or operational requirements. These development processes allow project managers to

• Discover what is not known by reaching a sufficient basic level of knowledge of the parameters of the problem
• Identify problems by understanding the current process, along with the people and technology involved.

The next step establishes boundaries and the elements of the solution. These are grouped into three types of principles:

1. Orientation?principles align the development process on a sound theoretical basis using generally accepted practices in the areas of engineering, modeling, and acquisition. These principles include capability thinking, architecture models, evolutionary development, and deliverables-centric planning. When we think of capabilities, we can ask, “What do I need to get the job done?” “I need to process transactions for $0.07 each, rather than the current $0.11.” When thinking about architecture, an external framework is the starting point. “We must be SOA-compliant for this project to be successful.” Evolutionary development establishes the sequence of capabilities to be delivered over time. “Enroll all members using the new system and process them using the legacy system. With them all enrolled, we can then migrate to the second phase of using a third–party processing system.” Deliverables-centric orientation is the basis of all project success. The customer bought the deliverable, not the work efforts—actually, not even the technology. The customer bought the ability to “do something.”
2. Communication?principles enforce the standardization of vocabulary and structure of information to be exchanged within or outside the system. These include standardized formats and common terminology to describe the system's capabilities. The semantics used to describe what “done” looks like need to be shared between the provider and the consumer. Without this commonality, it will be difficult to determine if the needed capabilities have actually been provided at the end of the project.
3. Collaboration?principles enable the active and timely participation of all stakeholders involved in the production of a capability. These include collaborative engineering and information sharing between the contributors of the system capability elements. The development of a solution is a collaborative effort guided by the shared understanding of what “done” looks like. There must be information exchanged between the provider and the consumer to ensure that each is using the same units of measure. An interface control document is an example of this shared understanding. It states the protocols and format of data, processes, and outcomes on both sides of the interface.

? "Project Success: The Basis of the Five Immutable Principles," Glen B. Alleman, Public Manager, Alexandria VA, Volume 43, Issue 3, Fall 2014, pp. 35-38.

Performance-Based Project Management - Increasing the Probability of Projects Success, Glen B. Alleman, American Management Association 2014.