5 immutable principles of project success (v2)(notes)

Thank you for inviting me here today.

The topic should be one we all are familiar with, since it is nearly impossible to not have experienced a project failure at least once in our career.

The principles I’m going to speak to you about are universal. Applicable to any project, of any size, in any domain.

The example project was one I was involved with as a Program Manager. One that was manifestly important, and nearly impossible. One that shaped how I see the principles, practices, and processes of managing projects in ways I had not considered before.

What you’re going to hear is not the solution to project failure. It is the framework for that solution. The actual mechanics of managing a project are based on these principles. The practices used in this management should be based on the se principles. And of course the process ad tools should implement the practices.

I’d like to present the 5 Immutable Principles of project success using examples from a program I was a participant in. Rocky Flats Environmental Technology Site, in Golden Colorado.

5 Immutable Principles of Project Success

Page 1 Glen B. Alleman, Niwot Ridge Consulting, LLC

Let’s start with positioning our interest in the project domain.

Nearly every business activity is based on a project in some way. Even the operational aspects of a business are projectized through processes, procedures, and business management.

Today I’d like to focus that types of projects Land speaks of. The really important ones that are nearly impossible.

I was a participant in one of those projects –Rocky Flats Environmental Technology Site. The name of the site was a nice marketing term for the cleanup of a nuclear bomb factory.

It was nearly impossible. The previous contractor had spent $4B and not done much.

When Kaiser-Hill (a joint venture between ICF Kaiser and CH2MHill) won the contract, they had a plan that was dramatically different from the past attempts to cleanup and close the site.



Rocky Flats was a U.S. Department of Energy National Nuclear Security Agency production site that operated from 1952 to 1992.

Rocky Flats was the most contaminated nuclear weapons plant in the country, was an environmental disaster and the site of rampant worker unrest.

Estimates projected that cleaning up and closing the facility would take 70 years and $36 Billion. The actual project was completed in 10 years for $6B.



For projects where success is mandatory, the outcome critical to the business, and risks are high, success comes about through principles, practices, and processes.

I’m going to try and convince you today that the 5 Immutable Principles are the foundation of any projects success.

These Principles are “Immutable” because they must always be present. They are the foundation on which the Practices and Processes are built.

We won’t look at the Practices and Processes, but they are critical to the success of any project as well.



After the Rocky Flats project had completed, the book Making the Impossible Possible was written about the lessons learned from the cleanup. This book examines the cleanup and closure of 800 buildings with 3 million square feet under roof, on a 6,000 acre site with many tons of hazardous materials just 10 miles from Denver’s suburban population.

Success is explained in the book through the model of Positive Deviance or Heliotropic Abundance. The theoretical framework of Competing Values (shown here) is the basis of the book.

The 5 Immutable Principles of Project Success are derived from my experiences as a Program Manager at this site.

Two elements of the competing valuesframework are the basis of this talk. Control and Create. Both are needed for success. Control alone limits creativity. Creativity alone results in out of control work activities.

Control provides stability measurement, clarity of objectives, discipline, and detailed planning.

Creativity enables agility in the presence of constant change.



Of the four quadrants of positive Deviancewe are interested in Control and Create as the basis of the 5 Immutable Principles of project success.

The focus is on clear and concise descriptions of Done, while innovative solutions to technical, programmatic, and operational problems are needed at every step along the way to Done.

We need both, but Control is the basis of Create. Control is often criticized as inhibiting or sabotaging performance.

Control emphasizes efficiency, smooth functioning, predictability and standardized procedures. It focuses on tight control of internal activities. The result is consistency and dependability in contrast to innovation and dynamism.

The success of any project is still grounded in extending beyond doing well to doing spectacularly well, and developing the mechanism that produces extraordinary results.

This requires creativity, a clear and shared vision of the future, symbolic leadership (leaders doing the work as well), innovative ideas about work, and creating a sense of meaning and importance attached to the tasks being pursued.



With this background, let’s look at the 5 Immutable Principles of Project Success.

I would suggest these are applicable to any technical domain. Any project management method. Any business domain. They are universal and Immutable – meaning they don’t change over time. They are permanent principles that must be applied for the success of any project.

The Principles are in the form of questions in this example. There are more formal statements about the Principles, but starting by asking 5 questions shows how the principles can be applied in any situation.

When there is not a credible answer to the question, this is an indication there is likely trouble on the project and the probability of success has been lowered.

In the next charts there will be the questions – numbered 1 through 5. Then there are 3 answers. Starting with the simplest answer –Number 1 – through the best answer –Number 3.

It is the Number 3 answer that we are after.

Being able to produce the answer in that style may be difficult and require Practices and Processes. But we have to start with the Principles.

So let’s start.



The first Principle is to ask if we know what Done looks like. This sounds like a simple question. But turns out to be the root cause of most project failure.

Done must be described in meaningful units of measure for the decision makers.

1. Our first response is usually to make a list of features and functions for the product of service produced by the project. This is necessary but far from sufficient to describe Done. We don’t know how these features and functions interact, how they provide value to the customer.

2. The interdependencies are next. We need to show how each feature or function is dependent – if it is – on other features and functions. This usually starts with the Work Breakdown Structure (WBS) showing all the deliverables from the project. The WBS needs a WBS Dictionary to show how we are going to measure the performance, quality, compliance of these outcomes with each other and the customer.

3. But the WBS and its Dictionary are not enough to know what Done looks like. We need to know what Capabilities are being provided by the project. What is the customer going to DO with these outcomes? How are they going to satisfy the business needs or mission?

The Capability to do something is what the customer bought.



These Capability statements are clear and concise. Long before we ever arrived in the moon, Robert Goddard knew what capabilities were needed to get there.

On October 19, 1899, Goddard climbed a dead tree to trim some branches. He was 17. He is quoted as saying … “I imagined,” he later recalled, “how wonderful it would be to make some device which had even the possibility of ascending to Mars, and how it would look on a small scale, if sent up from the meadow at my feet. . . I was a different boy when I descended the tree from when I ascended, for existence at last seemed very purposive.”

He had in his mind what capabilities were needed to fly outside the Earths atmosphere. He knew some of the units of measure that had to be fulfilled to do this.

If we don’t have some vision of the project at the Capabilities level, we really can’t say what Done looks like. We can describe the technical aspects, but we can’t say what we are going to do with those technical aspects.

This definition of Capabilities is a Systems Engineering role. There are formal processes to elicit these Capabilities through the Concept of Operations, Scenarios, and Use Cases, making tradeoffs between cost, risk, schedule, and technical performance, and balancing all the feasible alternatives.

The result is the Measures of Effectivenesswhich tell the customer the project will meet the needed capabilities.



With the needed Capabilities we can now develop a plan and schedule for the work.

Knowing how to get Done on–budget and on–schedule means knowing what requirements will have to be fulfilled.

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

This starts with Fact Finding, Gathering and Classifying the Requirements, Evaluating and Rationalizing the Requirements, Prioritizing them, and Integrating and Validating the Requirements.

With this in hand we can start building the packages of work that implement the requirements.

The result is a Plan and a Schedule. The Plan is the Strategy for the proper delivery of the Capabilities produced by the project. The Schedule is the sequence of work needed to implement the Strategy. Both are needed.

The Plan is emergent, since it is a strategy. The Schedule tests this strategy on short term boundaries, with measures of physical percent complete.

Both the Plan and the Schedule must be capable of responding to change as new information about requirements, program performance, and risk emerge.

But the needed capabilities should remain stable if we are to have a baseline on which to execute our project.



The Plan can be very simple or it can be complex.

Here’s a plan that took us to the moon and back. This picture shows a simple concept. Build the launch vehicle, develop the fuel to power it, the space craft on the top, train the astronauts, do the testing, and fly.

The Plan shows the 6 major systems , their approximate duration in years, and the dependencies between them are all that is needed to confirm the feasibility of the project.

Notice the longest activity is the training of the crew. No one had ever flown in space before all the way to the moon and back. So training was high risk and critical to success.



One view of the Plan is the vertical integration of the deliverables.

This is the deliverables traceability view. At the bottom is our deliverable.

The deliverable is produced by workcontained in a work package. A Work Package says its name. it produces a single outcome.

The technical capabilities needed for the project’s success are produced by the Work Packages.

Finally these Technical Capabilities produce business or mission capabilities needed by the customer for business success.

This traceability is necessary for a credible Plan and Schedule. It is also necessary for a credible project delivery process.

This traceability tells everyone what Donelooks like and how we are going to get there.



With the Plan in place and the “packages of work” identified in the Schedule, we can construct a picture of how we are going to reach Done.

This picture is not like the typical horizontal scheduling activities we see in all the scheduling tools.

This picture starts with the vertical integration of the deliverables as they progress through their maturity life cycle.

This is called the Integrated Master Plan. This Plan shows the Measures of Effectiveness and Measures of Performancewe need to achieve to reach a specific level of maturity.

This notion of levels of maturity can be seen is we use some words Preliminary is a work description. We all know what preliminary means. It means we’re not done yet. We have a preliminary design we have a preliminary cost estimate or a preliminary list of subcontractors. We know enough about the project to make some decisions, but we need more details before we can say for sure the cost, the design, and the subcontractors are all in place.

This incremental approach allows us to move foreword without all the details, while still having visibility into what Done looks like.

Since RFETS was many times discovery driven, planning had to be increasing maturity driven without the planning horizon reaching the final date. This incremental and iterative approach is a critical success factor for all projects.



Projects are executed by people.

People consume time, money, and materials.

How can we know if we have enough of everything we need for success?

We need a Plan of course, in this case a Resource Management Plan, showing people, funding, and materials, and when and where we need it.

1. We can start with a simple list. This gets us to write it down.

2. Next we need to assign people and money to the needed resources. How many of each special skill type will we need for this project.

3. In the end though, we need to lay out these needs against the schedule of work. We need to resource load the schedule. This sounds like a lot of work and it is. But without this in place we really have no idea if the project is feasible.



Matching people to needs is at the heart of resource management.

Without understanding what skills are needed we can’t do this matching. This information comes from the subject matter experts that have defined the “packages of work” and their deliverables.



We usually start by identifying risks. But risk is the result of uncertainty. There are two types of uncertainty – reducible uncertainty and irreducible uncertainty.

We can do something about reducible uncertainty. We can buy more knowledge about this uncertainty – it is epistemic. We can run tests, build prototypes, look at what others have done. The risk that results is reducible.

The irreducible uncertainty is part of the world around us. This uncertainty cannot be reduced – it is aleatory uncertainty. The only way to deal with this uncertainty is through margin. Cost margin, schedule margin, technical margin.

1. We have to start by identifying these uncertainties and associating them with the risks.

2. Then the impacts of the risk are identified along with their dependencies.

3. The probability of occurrence and the probability of their impact can be assessed and once the reducible risks are handled the residual uncertainty and its resulting risk.

With these impediments in hand we can take actions to either protect our project with margin or spend money to retire or handle the resulting risk.



The resulting Risk Management Planbecomes part of the Integrated Master Plan.

Risk management is how adults manage projects – Tim Lister.

We can manage the risk with either margin or with specific risk reducing actions. Either way, we must manage the risk.

The discovery of uncertainty and the resulting risk is a continuous work process. It is repeated weekly, monthly, quarterly, annually. It is never ending.

Risk drives variance and variance must be managed actively as part of the project management process.

The retirement of risk must be defined in the planning documents. The reduction from RED to YELLOW to GREEN must take place as planned. If we miss the buy down target we will have created more risk, since the retired risk was not removed as planned.

If we spend more money than planned to retire the risk, we are over budget as well. Retiring risk is a project work activity funded on the baseline.

Management Reserve maybe used to those “reducible” risks we have not yet decided to retire.



With our Plan, Schedule, Resources, and Risk Management Plan, we can now determine how we are going to measure progress to these plans.

1. The customer bought outcomes, deliverables, capabilities. We need to describe these in a way the customer understands. Units of measure that are meaningful for making decisions.

2. These are best described as Technical Performance Measures. These are attributes that determine how well a system or system element is satisfying or expected to satisfy a technical requirement or goal.

3. But these alone are not sufficient for the success of the project. We need Measures of Effectiveness (MoE), Measures of Performance (MoP), and Key Performance Parameters (KPP).

MoEs are operational measures of success that are closely related to the achievements of the mission or operational objectives evaluated in the operational environment, under a specific set of conditions. These are “customer satisfaction” measures.

MoPs characterize physical or functional attributes relating to the system operation, measured or estimated under specific conditions.

KPPs represent the capabilities and characteristics so significant that failure to meet them can be cause for reevaluation, reassessing, or termination of the program.



Measuring progress to plan means measuring physical percent complete at a fine grained level, where a 0% / 100% assessments can be made.

You’re either done or your not done. No in between. No vague assessment of done.

This means the planning of the work must identify tangible deliverables at that level.

This may appear more difficult, but it provides unassailable measures of progress. No opinions. No almost done. No “we’ll be done real soon.” Either you’re done or not done.

This approach provides the foundation of Earned Value at the Work Package level. It makes measuring progress easy.

More importantly it provides the basis to answer the question – How long are you willing to wait before you find out you are late?

With these fine grained measures of progress to plan, the answer can be the tangible evidence of progress.

Typically this evidence is produced every two weeks. No longer than monthly.

But it has to be tangible.

In this picture the tangible evidence is barrels of waste packaged, sealed, and ready to leave the site.



If we don’t have a plan. If we don’t have the proper resources available at the needed time. Of we don’t handle risks if we don’t have measures of physical; percent complete.

We can’t have confidence the project will be successful.

Without these elements, the probability of project success is reduced. Possibly to the point of project failure.

Without these elements, we have created risk to our success with no handling plans.

It is this unmitigated risk that creates the unanticipated growth in our Estimate At Completion.



Over a large number of complex, high risk programs there have been a small number of root causes discovered for project failure.

There are shown here.

Reading them they seem obvious.

Dealing with them is more difficult .

But we must deal with them and we must have information needed to deal with them.

This information comes from the practices, processes, and tools used to manage the project.

Scheduling, cost, risk, performance measurement, and forecasting tools and the processes used to apply them.

Only when all this information in integrated though a single “lens” can we have the needed visibility to take corrective action to keep the project GREEN.

Stay on schedule, stay on budget, comply with the technical requirements. Or if not, know about the variances soon enough to take corrective action.



Let’s quickly review the 5 principles of project success in the time remaining.

1. What does done look like? The customer needs to know what capabilities will be possessed when the project is done. The capabilities produce the business value or fulfill a mission objective.

2. How do we get there? We need a plan and a schedule. We need to arrange the work properly in the sequence to produce continuous value.

3. Are there enough resources? People, material, facilities? Are they the right people, does the material arrive at the needed time, are the facilities adequate to produce the needed outcomes?

4. What are the impediments to progress? Risk management is how adults manage projects. Do we have a risk register? Do the risks have handling plans? Is the cost and schedule baseline adjusted for these risks?

5. How do we measure progress? The only way is tangible evidence of physical percent complete. This means “show me” the outcomes and show me they meet the specifications, on the planned day for the planned cost. If not we’re late, over budget, and out outcomes probably don’t work right.




At the end of the Rocky Flats program, this is what done looked like.

All cleaned up, lock the gate and throw the keys over the fence.

On-time, on-budget, met technical requirements.

Project of the Year, 2006 PMI.

http://goo.gl/oCL0WJ


Thank you for your time.

I hope you got some new ideas about how to increase the probability of success for your projects.

The advice shown here should be applied to everything you do in managing your projects.

Evidence to the answers from the questions that represent the five immutable principles.

Evidence of what done looks like.

Evidence that you have a credible plan and schedule.

Evidence that you have the right resources, people, facilities, capacity for work.

Evidence you have identified the risks, assessed them, have handling plans.

And most of all evidence that your are making progress to plan through tangible measures of physical percent complete.




Glen B. Alleman, Niwot Ridge Consulting, LLCPage 25


Glen B. Alleman, Niwot Ridge Consulting, LLCPage 26

5 immutable principles of project success (v2)(notes)

Technology

actual project

project failure

project domain

projects success

example project

rocky flats project

principles im

se principles