Project Success: Starts with 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.”

Webster’s Dictionary defines a principle as 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 in a project. One common principle is “time is money.” In all project work, this is the case. If work is being done, time passes, 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 and actual measurements. In another example, cost and schedule are directly related through some multiplicative factor.

The more time the project takes, assuming constant labor productivity, the larger the cost will be for that labor. Quality, cost, and schedule performance can be described similarly, 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 most of the key criteria 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.

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

The Five Practices

The five practices 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

?10 Drivers That Enable the Practices

These 10 drivers are the foundation for the immutable principles and practices of 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 needed to be more technically compliant, we would have to spend more money and time to finish it. Therefore, we would need more budget and time on the planned day of completion of our deliverable.
9. Fulfilled requirements produce delivered capabilities. The capabilities can be deployed to the customer with the requirement fulfilled by products or services.
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” elements 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 (driver 2) and the creation of the PMB describing the time-phased work and its budget (drivers 3 and 4), to the execution of the baseline (drivers 6, 7, and 8) and project close-out (drivers 9 and 10).

The drivers of performance-based project management provide feedback loops to ensure 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 assessment periods provided for corrective actions are appropriately spaced to minimize risk and maximize the delivered value to the project.

The 10 drivers are the basis of the principles and practices of performance-based project management. 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, 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 Drivers to Work

Let’s examine the first driver to see how it can increase the probability of project success when paired with the five principles and practices.

Capabilities Drive System Requirements

The first driver 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 we don’t know how to address this supposed issue. It turns out someone needs all the capabilities in those products—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 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, supporting agility and tailorability with the least 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 on 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 will 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 what 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 will eat outside or stay in.
5. Take hedging actions to better prepare for the possibility that an assumption will fail by considering plausible scenarios to test the assumptions.?This what-if approach is at the core of good project risk management.

Capabilities-based planning uses 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 and 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—not 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 all stakeholders' active and timely participation in producing a capability. These include collaborative engineering and information sharing between the contributors of the system capability elements. Developing a solution is a collaborative effort guided by the shared understanding of what “done” looks like. The information must be exchanged between the provider and the consumer to ensure that each uses 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 interface sides.?

Reprinted with permission from Performance-Based Project Management(r), Performance-Based Project Management is a registered trademark of Niwot Ridge Consulting LLC: Increasing the Probability of Project Success by Glen B. Alleman. Copyright ? 2014 Glen B. Alleman. Published by AMACOM Books. All rights reserved. www.amacombooks.org

For more information

https://herdingcats.typepad.com/

https://twitter.com/galleman

www.dhirubhai.net/in/glenballeman

www.maxwideman.com

If we understand what capabilities are needed to produce business value or fulfill a mission, we can then identify what technical or operational requirements are needed to deliver those capabilities.