Increasing the Probability of Project Success with 24 Essential Views

The 24 Views of a Project's performance are the minimum set needed for the Program or Project Management processes to effectively oversee the successful delivery of the project's capabilities on time and within budget.

All projects operate in the presence of processes. Here's one framework for this condition...

What Do We Mean When We Say Project?

The term project has an official meaning in many domains. Work that has a finite duration is a good start. But then, what is finite? Work that makes a change to an external condition. But what does the change mean, and what is external? In most definitions, operations and maintenance are only sometimes budgeted as projects. There are accounting rules that describe projects as well. Once we land on an operational definition of the project, here's a notional picture of the range of projects.

When we hear a suggestion about any process for project management, we need first to establish a domain and a context in that domain to test the idea.?

One framework for making decisions in the presence of uncertainty is Organizational Governance. Without establishing a governance framework, ranging from one like that below to No governance, just?DO IT, it's difficult to have a meaningful conversation about the applicability of any project management process.

So when we hear a new and possibly counter-intuitive suggestion, start by asking?In What Governance Model Do You Think This Idea Might Be?Applicable?

The 24 Essential Views Needed to Manage Projects Provide ...

• Leading and lagging indicators of program success are needed, but leading indicators are preferred over lagging if we can have both.
• Data sources start with the Integrated Program Management Report. Still, they must include the Risk Register, Technical Performance Measures, Measures of Effectiveness (MOE), Measures of Performance (MoP), and Key Performance Parameters (KPP).
• Putting all these together in a set of views for use by the government is the primary beneficial outcome of our efforts.

An Essential View provides ...

• Actionable information allowing the Program Manager to take corrective actions
• Credible information on the program’s performance to provide leading indicators of performance
• Traceable information that leads to the source of the unfavorable outcome, so corrective actions can be taken on the process connected to that information

An Essential View provides project performance information that enables the Project Manager to:

1. Assess the status of technical, cost, and schedule progress health,
2. Determine which areas are problematic, and
3. Help develop mitigation or corrective actions before small problems become large.

5 Immutable Principles of Project Success

Before applying the 24 Essential Views, let's start with the principles of project management success.

The five immutable principles of project success are:

1. We know where you are going by defining “done” at some point in the future. This point may be far – months or years from now. Or closer in the future, days or weeks from now.
2. We have some kind of plan to get to where we 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. We understand the resources needed to execute the plan. How much time and money is needed to reach the destination? This can be fixed, or it can be variable.
4. We have identified the impediments to progress along the way to the destination. Have some means of removing, avoiding, or ignoring these impediments.
5. We have some way to measure your planned progress, not just your progress. Progress to Plan must be measured in units of physical percent complete.

With all 5 Principles in place and processes and practices (of your choice) applied, the probability of project success increased.

The key here is that requirements tell us something about where we are going. But requirements come in all shapes and sizes. Here’s a sample of two extremes.

A small project and a not-small project.

• A small project on the left is straightforward in terms of requirements. There is a list of them on the flip chart. They are likely well-understood. They can be estimated in terms of cost and schedule. And most importantly, the interactions between the requirements can be intuited with a little effort.
• The project on the right is a different class of effort. These are the top-level components (if we can call them that) of the Future Combat System. It’s a $35B, that’s billion with a B program to restructure the entire US Army Battle-Space Management System.

I help one of the teams on the right – the Class I product team – build their Performance Measurement Baseline (PMB) and get that information into a cost and schedule management system, so they can use Earned Value Management to “manage” their program.

The Future Combat System (FCS) is a software intensive system of systems (SISoS), where software is in everything from small handheld devices to major facilities housing the “battle space management command.”

If the software doesn’t work, the FCS doesn’t work. Soldiers can’t do their job. If soldiers can’t do their job – there’s a BIG PROBLEM

Now that we know where we want to go, the next question is how to get there.

How do we build the products or provide the services needed to reach the end of our project? There are numerous choices, depending on the domain and the context of the project in that domain.

For the software domain, there are many contexts. Let's look at two methods using the example on the previous page. These are the extreme ends of the spectrum of contexts and methods. They can focus the discussion on project management rather than product development methods by disconnecting project management from product development so we can look at them separately.

SCRUM is a popular approach in the first software development context – a list of features.

But there are many more software-based projects, possibly more complex than the example from the previous page to the “wickedly” complex program also shown in the previous chart.

The SCRUM method is shown in its common diagram. Below is the method used for product procurement in the US Department of Defense. The products are not developed by the DoD (except in rare cases). But are, instead, procured. So, acquisition management is guided by this process.

Both are iterative, both are incremental, both can deal with emerging requirements, both make use of “test-driven planning,” and both have clear and concise measures of physical percent complete.

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 skills 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 are 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.

• Uncertainty and their Risks never go away.
• They are always there.
• They are unavoidable.

If risk management is how adults manage projects, here are some principles of project risk management.

These five principles are simple and obvious but take more work 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 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. The connection to value can only be made by connecting the cost, schedule, and technical performance of the effort to produce the product or service.
4. Risk management is not an ad hoc process that we can make up as we go. A formal foundation for risk management is needed.
5. Identifying risks without communicating them is a waste of time

We must confirm our progress with the information from the previous 4 Irreducible Principles.

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.

For any closed-loop control system, we need feedback on our progress. 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 customer. Something compliant with the planned technical outcomes at this point in the plan.

Scrum does this by predefining the outcomes of the iteration.

This is also done with the Integrated Master Plan and Integrated Master Schedule.

So looking at two extremes of the spectrum – one agile software development and the other a mega- program procurement.

Both share the same principles and outcomes. Something that is tangible and measurable at incremental steps along the way to “done.”

24 Essential Views are the Basis of Project Success

To successfully apply the 5 Immutable Principles, we need Views of how the project is performing against the planned perform beyond to typical measures of progress:

1. Key Technical Performance (TPM) Plans - Provides evidence that the project possesses a logical plan to accomplish the required technical work. Provides the basis for tracking technical progress, which should be consistent with reported cost and schedule progress.
2. Deliverables Plan - Assures the Project Manager has a plan to deliver products when required and provides another metric consistent with cost and schedule progress.
3. Deterministic Integrated Master Schedule (IMS) - Evidence that the contractor has a resource-informed plan to accomplish the technical work and produce the required deliverables.
4. Labor Utilization Plan - Provides evidence that the contractor has (or plans to have) the correct skilled personnel at the time they are needed.
5. Schedule Health Checks - Allows the Project Manager to know if the plan is of good quality based on scheduling "best practices."
6. Risk Register and Risk Mitigation Actions - Provides evidence that risks have the plan to mitigate them. Provides evidence of a credible PMB.
7. Risk Burndown Plan - Let the Project Management know there is a plan of good quality based on scheduling "best practices."
8. Computation of Initial Management Reserve (MR) - Provides evidence that there are thoughts about risks and has a plan to mitigate them. Provides evidence that the contractor has a credible Performance Measurement Baseline (PMB).
9. Computation of Schedule Margin (SM) and Placement in the Integrated Master Schedule - Provides evidence that there is a cushion for the plan in order to meet the required "need date". The process formally recognizes the irreducible "natural variation" of development efforts using reference classes. Provides a statistical basis for the SM.
10. TPM Plan vs Estimated Values vs Cost and Schedule Performance Metrics - Communicates whether planned technical progress is being made and aligned with cost and schedule progress. Lack of technical progress leads to future cost and schedule performance problems.
11. Deliverables Plan versus Actuals - Communicates whether deliverables are being produced as planned. Used to help explain reported cost and schedule progress.
12. Labor Plan versus Actuals - The inability to acquire the correct skilled personnel at the time required is a key leading indicator of unfavorable cost and schedule variance. Further, a lack of key personnel may help explain variances.
13. Cumulative Cost and Schedule Performance - Communicates the current status of cost and schedule performance. Provides information to allow further investigation of potential problems to be managed.
14. Risk Burndown Plan - Let the Project Manager know if risks are being managed according to plan.
15. Cost and schedule performance informed by the Risk Burn Down Actuals for Selected Risks - Allows the Project Manager to examine the efficacy of a given risk mitigation strategy and ensure that cost and schedule progress are consistent.
16. Schedule Health and Performance Metrics on Past and Future IMS - Provides the Project Manager with past schedule-rated performance data and quality checks on the "to-go" Integrated Master Schedule (IMS).
17. Contribution of WBS Costs to Budget at Completion (BAC) Total - Communicates which elements are the costliest and may need closer oversight.
18. Management Reserve (MR) and Budget at Completion (BAC) Projections - MR and BAC Projections.
19. Contract Modification Percentage Change - Communicates how much the contract has changed. A high amount of contract changes signals instability of the contractor's plan and can jeopardize meeting cost and schedule targets. A High percentage of change should trigger a full review of the plan.
20. Baseline Revision Index - Communicates how much the baseline has changed. High revisions threaten the contractor's plan's stability and jeopardize meeting cost and schedule targets. High indices should trigger a full review of the plan.
21. Forecast of Estimate at Completion (EAC) and Estimated Completion Date (ECD) Using Performance Data - Uses past performance to forecast the final EAC and ECD. The Project Manager can use the results to ask probing questions about how the contractor plans to change performance to change the outcome vectors.
22. Updated Risk Register - Provides Project Management with status on the efficacy of earlier mitigation actions and the updated risks, risk attributes, and mitigation actions for the remainder of the contract.
23. Confidence Levels of Estimate at Completion (EAC) and Estimated Completion Date (ECD) - Provides the Project Manager with a statistical measure of the contractor's Best Case, Worst Case, and Most Likely EACs and ECDs. It also provides a summary-level leading indicator of potential issues and can be used to investigate remaining schedule logic and risk mitigation actions.
24. Confidence Levels of EACs, ECDs, and Cost Sensitivity Indices - Provides the Project Manager with a forward look at which activities and WBS are most likely to cause cost and schedule overruns and permits the Project Manager to take corrective and preventive action to control the project work.

Connecting the 5 Principles and Five Practices of Project Success with the 24 Essential Views