5 Principles and Processes for Project Success

No matter the domain, the context, the method, the framework, there are Five Principles and Processes for project success.

Before you engage with any salesman about a solution looking for a problem to solve, have credible answers to each of these principles and practices to test the solution against. And never engage in a conversation about solutions until you know what the problem is.

And then for each problem, you are trying to solve with your selected solution, identify the Condition and Action that will be addressed with a corrective or preventive action to remove, isolate, and protect your project from the root cause of the problem.

There are five processes for the success of any project. Each of the steps will produce tangible outcomes showing the physical percent complete progress to plan of the project. These processes are enabled by five immutable principles shown in the next chart. With both the principles and the processes the probability of project success is greatly increased.

The five immutable principles of project success are:

1. Know where you are going by defining “done” at some point in the future. This point may be far in the future – months or years from now. Or closer in the future days or weeks from now.
2. Have some kind of plan to get to where you are going. This plan can be simple or it can be complex. The fidelity of the plan depends on the tolerance for risk by the users of the plan.
3. Understand the resources needed to execute the plan. How much time and money is needed to reach the destination. This can be fixed or variable.
4. Identify the impediments to progress along the way to the destination. Have some means of removing, avoiding, or ignoring these impediments.
5. Have some way to measure your planned progress, not just your progress. Progress to Plan must be measured in units of physical percent complete. In units meaningful to the decision-makers.

These two words should be tattooed on your wrist. If we don’t have a Plan, our schedule is not credible. Plans are not Schedules. And Schedules are not Plans. A Plan is a Strategy for the successful delivery of the project. Plans state “what” is to be done (programmatically what, not technically what). Schedules state “how” it is to be done – programmatically how it is to be done. While this may seem subtle or maybe not even useful, it is critically important for several reasons:

• The plan shows how the project produces increasing value and increasing maturity of the products.
• This value and maturity is meaningful to the business.
• It’s is the “road map” from the beginning to end, INDEPENDENT from the actual durations of the work.
• The Plan speaks to What we are doing.
• The schedule is the “driving instructions” for the vehicles on the roads, following the map.
• The execution of the schedule is the actual “driving” of the vehicle by the driver along with the passengers.

All three (Plan, Schedule, Execution) are needed, no one can be missing, all three interact with each other.

Now that we know about the existence of a Plan, what is the Schedule?

Why is a Schedule different from the Plan?

The Schedule shows the work needed to produce the “deliverables” in the Plan. This sounds like a tautology – a statement of the obvious. But there’s more to it than that. This work is ONLY the work needed to cause the “exit criteria” to appear of each individual definition of the criteria for named Accomplishment.

In a previous chart, the definition of the Accomplishments comes first.

With these definitions – and most importantly the order in which these Accomplishments must be accomplished. I know this is not as clear as you’d expect at this point. But we’ll need to use an example before we get back to the details. For now, think of the schedule as the description of how the individual Exit Criteria from the “lumps of work” are to be accomplished.?

Now that we know some things about what capabilities we need and how we might cause these capabilities to appear at the appointed time and place for the planned cost and schedule, do we know what we need to be successful? We need to constantly ask this question.

If we don’t ask and answer the question, we’ll find out what is missing when they arrive on our doorstep. At that point, it will be too late. It is not too late to acquire them, but too late to acquire them within our planned schedule and planned budget.

Now that we know where we’re going and how to get there – do we have all we need to reach the end? Staff, time, money, the necessary skill and experience, and the proper management support.

These are all obvious on any project – at least any well-managed project. But there are always underlying issues with answering these questions. The first is that management, as well as the development organization, is always optimistic about the outcome. This is the very nature of project management. Why be pessimistic?

Well maybe not pessimistic, but how about realistic? What do we mean when we say realistic? One good word is credible. Credible could be optimistically credible or pessimistically credible. But either way, we have a credible understanding of what it takes to reach the end.

One part of credible is knowing what the risks and uncertainties are and how we are going to deal with them. Managing in the Presence of these uncertainties is critical to reaching our goal. Risk is created by uncertainty and it never goes away. They are always there. They are unavoidable.

Project Managers constantly seek ways to eliminate or control risk, variance, and uncertainty.

This is a hopeless pursuit.

Managing “in the presence” of risk, variance, and uncertainty is the key to success. Some projects have few uncertainties –only the complexity of tasks and relationships is important – but most projects are characterized by several types of uncertainty. Although each uncertainty type is distinct, a single project may encounter some combination of four types:

1. Variation – comes from many small influences and yields a range of values on a particular activity. Attempting to control these variances outside their natural boundaries is a waste (Muda).
2. Foreseen Uncertainty – are uncertainties identifiable and understood influences that the team cannot be sure will occur. There needs to be a handling plan for these foreseen uncertainties.
3. Unforeseen Uncertainty – is uncertainty that can’t be identified during project planning. When these occur, a new plan is needed.
4. Chaos – appears in the presence of “unknown unknowns.”

“Managing Project Uncertainty: From Variation to Chaos,” Arnoud De Meyer, Christoph H. Loch, and Michael T. Pich, MIT Sloan Management Review, Winter 2000.

If risk management is how adults manage projects, here are some principles of project risk management. These five principles are simple, obvious, but difficult to implement. The reason they’re difficult is that most people shy away from risk. Managing in the presence of risk does not come naturally.

It is a learned behavior. And once learned it has to be practiced. But before it can be learned and then practiced, “managing in the presence of risk,” must become part of the business culture. Some cultures do this better than others. NASA is probably better than others. But even NASA has moved to a risk-averse culture in the past decades.

1. Hoping that something positive will result is not a very good strategy. Preparing for success is the basis of success.
2. Single point estimates are no better than 50/50 guesses in the absence of knowledge of the standard deviation of the underlying distribution.
3. Without connecting the cost, schedule, and technical performance of the effort to produce the product or service, the connection to value cannot be made.
4. Risk management is not an ad hoc process that you can make up as you go. A formal foundation for risk management is needed.
5. Identifying risks without communicating them is a waste of everyone’s time.

Tim’s advice to us is immutable for any project success in any domain or in any context. For all managers, no matter the domain and context, the management of risk is the starting point for any project's success.

The technical aspects of project management, the regulatory aspects of project management, or any other aspects of project management require the starting point to be risk management.

All risk comes from uncertainty. Uncertainty comes in only two forms on projects in the management of those projects. Aleatory uncertainty comes from natural variances. Aliyah is a single die used by the Greeks to gamble. Epistemic uncertainty comes from our lack of knowledge. Epistemology is the study of knowledge.

Aleatory uncertainty that creates risk can only be handled by margin. Epistemic uncertainty that creates risk can be handled by buying information. This information can come from prototypes tests or redundancies.

No matter the source of uncertainty that creates risk, the management of IT projects requires that we manage risk.

The naturally occurring variability, the Aleatory uncertainties are irreducible. These uncertainties come from randomly performing processes, weather delays, the productivity of individuals at their task, scheduling issues in the harbor, any random process that is naturally occurring.

Reducible uncertainties are handled by acquiring more knowledge. There is some advice from Tim Lister, who was a Program Manager at IBM for the first American Express credit card system. Risk management is how adults manage projects

They may be offensive to our millennial colleagues but has a ring of truth.

Identify – Before risks can be managed, they must be identified. Identification surfaces risks before they become problems and adversely affect a program.

Analyze – Analysis is the conversion of risk data into risk decision?making information. The analysis provides the basis for the program manager to work on the “right” risks.

Plan – Planning turns risk information into decisions and actions (both present and future). Planning involves developing actions to address individual risks, prioritizing risk actions, and creating an integrated risk management plan.

Track – Tracking consists of monitoring the status of risks and actions taken to ameliorate risks. Appropriate risk metrics are identified and monitored to enable the evaluation of the status of risks themselves and of risk mitigation plans. Tracking serves as the “watchdog” function of management.

Control – Risk control corrects for deviations from planned risk actions. Once risk metrics and triggering events have been chosen, there is nothing unique about risk control.

Communication & Documentation – Risk communication lies at the center of the model to emphasize both its pervasiveness and its criticality. Without effective communication, no risk management approach can be viable. While communication facilitates interaction among the elements of the model, there are higher-level communications to consider as well.?

An important aspect of the Decision Analysis Process is to consider and understand at what time it is appropriate or required for a decision to be made or not made. When considering a decision, it is important to ask questions such as:

• Why is a decision required at this time?
• For how long can a decision be delayed?
• What is the impact of delaying a decision?
• Is all of the necessary information available to make a decision?
• Are there other key drivers or dependent factors and criteria that must be in place before a decision can be made?

Here’s the Full Monty of Risk Management is about making decisions in the presence of uncertainty. These processes should be in place in the Risk Management of any project in any domain, managed and developed with any process, method, framework, or what if you wnat to call it.

It may not be your job, but it must be someone’s job. An important aspect of the Decision Analysis Process is to consider and understand at what time it is appropriate or required for a decision to be made or not made. When considering a decision, it is important to ask questions such as:

• Why is a decision required at this time?
• For how long can a decision be delayed?
• What is the impact of delaying a decision?
• Is all of the necessary information available to make a decision?
• Are there other key drivers or dependent factors and criteria that must be in place before a decision can be made?

Risk management is not a hard science. Risk Management requires that the risk manager combine the best?known technical information with good professional judgment. A key element of risk management is maintaining the set of program risks so that the most important risks are prioritized from the perspective of the program team or organization.

The Risk Register facilitates this process and makes risk management as simple and straightforward as possible. The most important part of risk management is to identify the highest?priority risks and to keep attention focused on them as a project evolves over time. Risk management is a dynamic and proactive process that requires continuous vigilance.

An important risk this month might not be important next month. It is impossible to predict all the risks a project might face in the future, and it is futile to try. The critical success factor for the risk register is the connection between the identified and active risks the risk handling processes embedded in the Integrated Master Schedule.

Only by making these connections can the program be assured that risks are being “handled” as part of the normal course of business of Program Management.

Measures of progress are one of the difficult topics in project management. Typically, we measure progress by the consumption of resources and the passage of time. We talk about “budget,” being “on budget,” being “over budget.” We talk about the passage of time. “We’re on schedule,” “we’re late,” “our schedule is slipping.” These are all necessary things to talk about. But they are not sufficient for our project’s success.

Performance measurement is the comparison of actual performance against an integrated baseline plan consisting of the integrated cost, schedule and technical goals. The baseline used for performance measurement should be a single, integrated plan, because the analysis of cost performance must include schedule considerations and the evaluation of schedule performance must include technical performance considerations.

Given a project where some tasks are on schedule, some are ahead of schedule and some are behind schedule, overall project status is virtually impossible to determine. It is no wonder that many project managers are literally “flying by the seat of their pants” without a good feel for where the project stands at any given point in time. A systematic, organized process for collecting performance information and presenting it in a clear manner on a regular basis is essential to the project management process.

And therefore, a critical success factor for the project itself.

For successful measurement of progress?to plan?in a project we need to have:

• Tangible evidentiary materials measure progress to plan.
• Pre–defined existence of this evidence in meaningful units of measure established before starting work.
• Progress is defined in these same units of measure.
• All units of measure must be meaningful to the decision-makers.
• The Technical Performance Measures must be traceable to the requirements, the capabilities, and back to the Measures of Effectiveness (MoE).
• MoE’s are how the stakeholder measures progress. The stakeholder didn’t buy the development environment, or even the code produced by the development environment. The stakeholder bought the capabilities that the software implements. Or any product, not just software.
• One example is the program of the Hubble Robotic Service Mission (HRSM). The Goddard Space Flight Center bought the capability to fly to Hubble, do no harm to the telescope, change the Wide Field Camera, and connect the umbilical cord of the external batteries latched to the towel bars on the ass end of the telescope.
• That’s what done looked like, that’s what Frank Cepollina?bought for his telescope.

With the information from the previous 4 irreducible principles, we now need to confirm we are making progress. The key principle here is “planned progress.” We must pre-define what progress we must make at any specific point in the project, otherwise, all we can determine is the passage of time and the consumption of the money.

Preplanning the progress is the basis of “performance-based” measurement for both project processes and technical products. There is only one kind of feedback for projects – measures of physical percent complete.

No soft touchy-feely measures of progress. No hand waving measures. Physical, tangible evidence of progress. Something that can be physically shown to the stakeholder. Something that is compliant with the planned technical outcomes at this point in the plan.

So looking at two extremes of the spectrum – one a software development method and the other a mega-program procurement method. Both share the same principles and outcomes. Something that is tangible and measurable at incremental steps along the way to “done.”

Let’s talk a bit about a common fallacy in the project acquisition management world. The notion of the “iron triangle” has fallen into disrepute lately. We all should know about the iron triangle. It connects cost, schedule, and quality – or some 3rd element in place of quality. Actually, the variable in place of quality is “Technical Performance Measures” (TPM).

When we say “project management” we have to say “management” in terms of measuring progress to plan. This is not always the first image of a Project Manager. Many times we think of a personnel coordinator, a facilitator, all those soft skills that are taught at the PM conferences.

But at the end of the day, the stakeholder has little concern about that. It is assumed that all that is handled. It is considered hygiene, part of the normal operations. The stakeholder wants to know:

• When will you be done?
• How much will it cost?
• Will it work the way the stakeholder wants it to work?

With a good plan, a schedule, a description of the needed capabilities and related requirements, the needed resources to deliver on the requirements, and all the impediments to progress identified and handling plans - The question is how to measure progress to plan?

How do we define what the planned progress “should” be, what actual progress we made to date, and how much work there is to go? With the remaining progress to go, what should our pace be to arrive at the end of the project at the planned time?

Without clear and concise answers to these questions, all the other aspects of project management are going to add little to the probability of success. This is the source of most project failures, the dreaded Death March of Ed Yourdon.

Performance measurement is the comparison of actual performance against the planned performance in an integrated baseline plan consisting of integrated cost, schedule and technical goals.

The baseline used for performance measurement should be a single, integrated plan because the analysis of cost performance must include schedule considerations and the evaluation of schedule performance must include technical performance considerations.

Given a project where some tasks are on schedule, some are ahead of schedule and some are behind schedule, overall project status is virtually impossible to determine.

It is no wonder that many project managers are literally “flying by the seat of their pants” without a good feel for where the project stands at any given point in time. A systematic, organized process for collecting performance information and presenting it in a clear manner on a regular basis is essential to the project management process.

Project management means being able to state with confidence these phrases?any time someone asks you “how are you managing the project?”

If you cannot say this with a straight face, then you need to take action to start to move in that direction.