For projects at scale, meaning the success or failure of the outcome impacts the firm in ways that cannot be corrected if it fails - loss of business, non-recoverable sunk cost, or other unfavorable impacts, there is usually a formal governance process for managing the project, the funding, and the outcomes in a manner that provide visibility to the project progress to plan to the highest levels of the organization.
Many of these Enterprise IT projects apply agile methods. Just as many of the Agile projects in this domain misuse the Definition of Done. Used as an excuse for not having a plan. Or as an excuse for not defining tangible evidence to needs to be produced in exchange for the investment. Here's a collection of PP&C processes that impact the probability of program success.
Here's the framework for applying Program Planning and Control to Enterprise IT projects, as well as the other projects and programs where it is currently used.
Let's start with a basic idea. All work on projects is uncertain. Reducible uncertainty and irreducible uncertainty. This uncertainty is applicable to all work elements, no matter the development method, the system architecture, or any other attributes of the project. Uncertainty is universally applicable to everything we do.
Some would suggest that having no dependencies would remove the impact of uncertainties. But that is no true on any non-trivial project. For example, in an enterprise system, like the one below, the needed capabilities to provide value to the business have a logical order. This is a health insurance provider enrollment system. We can have the shared group matrix reports and interfaces until we have a demonstration of the conversion process and member reconciliation. Order, predecessor, and successor relationships are part of all development work.
Let's start with some simple statistics. These uncertainties come from the underlying probability and statistics of the work processes. It's important to separate probability from statistics. Both are needed, but they are not the same. And more importantly, they have different impacts on the project. We must learn about the behaviors of both. Reducible uncertainties come from probabilities. Irreducible uncertainties come from statistical processes. One we can do something about and other we must have margin because they are irreducible.
If you hear about some probabilistic or statistical process, there are some terms that are useful. Here's one - a Probability Distribution Function. This tells us the probability that some value will appear. In this example, those values range from 0.0 to 5.0. As managers, we may only be interested in 80% of the possible value. This 10/90 phrase says that numbers from the 10th percentile to the 90th percentile are the ones we're interested. If there is possibility that a value in the less than 10th percentile or greater than the 90th percent was to appear, we'd need to consider that an outlier or a value that must be prevented from appeared by some means
As PP&C people we now need to put these concepts to work. The first question to answer is what are the behaviors of the schedule of work. We start with the schedule, rather than cost, because most every non-trivial projects have some deadline to start earning back the invested cost. It's not that we're not interested in cost, but we can usually go beg for more money. We get to beg for more time in any serious project. Why is this true, simple time cost of money. Those investing in the project have a need to start making money from their investment. Or, in many cases, those investing in the project have some external dependency – a launch date for a product. Or a physical launch date - a literal launch date. You can only go to Mars in a small window (weeks) every 3 years. Miss that date, you have to wait - usually at your own cost.
So here's a simple project example. This is from a larger briefing where we use the Wright Brothers contract to deliver a flying machine on a specific date for a specific amount of money. The contract for this machine is 3 pages and calls out dates, cost, measures of effectiveness, measures of performance, and key performance parameters. They had already flown many many times, this was a procurement contract for a production machine. That date was
That date was August 14, 1908. Orville and Wilbur were probably not professional Program Planning and Cost analyst, but they knew they to have a credible schedule complete with risk management and risk buy down, margins for that cost and schedule as well as margins for the technical performance of the product. Just like any credible plan for any non-trivial development effort. The Wright Brothers is a good place to learn how it was actually done, and learn that many of things we learning in grade school are not factually correct. The contract Signal Corps Specification No. 486 calls out the details. Wilburn and Orville had he needed margins - developed from reference classes of past flights, experiments, models, prototypes, and intuition.
In our current domain, the primary tool used to develop the needed margins, assess the impacts of risk reduction activities, find blocking steps and a variety of other reducible and irreducible uncertainties is Monet Carlo Simulation. These simulations are applied to the three core attributes of all project work - time, cost, and technical performance and their interactions.
Here's what that looks like for the planned completion of Work Package #3 on March 12th, 2012. The chart shows there is a 60% probability of completing on or before the need date. If this is acceptable, then fine. If not we need a better plan.
One of the roles of PP&C is the develop models for the cost and schedule of the project. Then interact with the engineers to assess the plan for increasing the maturity of the deliverables and how hat maturing assessment will impact the cost and schedule when that maturity is not being delivered to plan. This is the basis of a Closed Loop Control system.
Without a plan for delivering the needed capabilities at the needed maturity on the needed date for the needed cost, there is no way to have a control system that will provide actionable information to the decision makers.
While these charts are notional in nature, here's a real one for dependencies of a large software-intensive system of systems for a flight vehicle. This chart is blurry enough to not be recognizable, but it is real and it represent several billion dollars of work over 5 years
So In the End
- Without a plan, you don't know what done looks like – don’t believe for a moment the things will emerge, and the customer will be happy about what you come up with – unless it's a research project. It's their money, and they want to know when they will start earning back that investment.
- Closed Loop Control requires you have units of measure for what done looks like, when that Done will appear, how much it will cost to get to done, what impediments you'll encounter along the way and most importantly what units of measure meaningful to the decision makers will inform the physical percent of the work on the way to done.
This is what Program Planning and Controls does. It does it on large space flight programs. road building, power plant building, and most of all on Agile Software Development projects. Not you're 5 guys at the same table with their customer and an open check book, projects. But large software development project (ours are typically $20M or greater up to Billions) with a deadline for working software – all the individual Sprints, Release up to Full Working systems with the needed capabilities to accomplish the mission.
If you have no deadline, no not to exceed budgets, no mandatory capabilities to meet the mission need, no defined benfist from the project, then none of this is useful
