Jerry, just remember, it's not a lie if you believe it - George Costanza
Principles, Practices, and Processes to Increase Probability of Project Success
In a time of universal deceit - telling the truth is a revolutionary act.
War is peace. Freedom is slavery. Ignorance is strength.
Political language... is designed to make lies sound truthful and murder respectable, and to give an appearance of solidity to pure wind.
If liberty means anything at all, it means the right to tell people what they do not want to hear.
It is the first responsibility of every citizen to question authority ― Benjamin Franklin
Think of this when you hear someone say protesting is a waste of time, and tell you to just be quiet and accept the situation you are in.
Overheard on Twitter
The Start of a Project Is the Worst Time to Estimate Its Duration or Cost
This is only the case if those you've hired know nothing about what capabilities are needed to produce value the project, what Features are needed to produce that Value, when those Value-producing Features are needed to meet the time cost of value payback process, what risks there are for meeting those value producing outcomes, and how the work effort to produce that value are to be measured (physical percent complete) to increase the probability of success for your project. As the project progresses this understanding will, of course, improve with feedback, working product, and learning.
If those you've hired don't have some sense of these needs, to some level of confidence, you've hired the wrong people.
From Estimatiing and Reporting Agile Projects with the SRDR
Risk is everywhere on projects. This risk comes from two types of uncertainty. Aleatory uncertainty, which is the naturally occurring yields variances in the underlying processes. This uncertainty is handled with cost, schedule, and technical performance margins. Epistemic uncertainty comes from probabilistic processes that can be addressed with handling responses.
The idea of risk and its management and handling is a critical success factor for all software development.
One of the most rigorous theorems of economics  proves that the existing means of production yields greater economic performance only through greater uncertainty that is, through greater risk. While it is futile to try and eliminate risk, and questionable to try and minimize it, it is essential that risk be taken be the right risks...
We must be about to choosing rationally among risk-taking courses of action, rather than plunge into uncertainty on the basis of hunch, hearsay, or incomplete experience, no matter how meticulously quantified.
- Peter Drucker (1975) Management (From The Principles of Software Engineering, Chapter 6, Tom Glib, 1988).
Managing in the presence of risk - and the uncertainty that creates the risk - requires we make risk-informed decisions. These decisions are informed by the probabilistic and statistical outcomes of those decisions in the future. In order to make risk-informed decisions, we must estimate the outcomes and the impacts of those outcomes on future activities (cost, schedule, and technical performance of products and services). Without these estimates, there is no risk management. And as Tim Lister reminds us
Without these estimates, there can be no risk management. And as Tim Lister reminds us
Risk Management is how Adults Manage Projects. Be an adult, make estimates of the future outcomes of your risk informed decisions.
 Control or Economic Law Paperback, Eugen von Boehm-Bawerk, 2010.
 "How Much Risk is Too Much Risk," Tim Lister, Boston SPIN
 "Risk Management is How Adults Manage Projects," Susanne Madsen
 "Risk Management and Agile Software Development," Glen B Alleman
Risk Management is How Adults Manage Projects - Tim Lister
Risk Management requires making estimates of many things. The uncertainties that create the risk - reducible (Epistemic) and irreducible (Aleatory), the impacts from the risks, the efficacy of the corrective actions, the residual reducible uncertainty, and any changes in the irreducible uncertainties.
Just like risk management, estimating is how adults manage projects. No risk management no adult managemnt. No estimates, no adult management. Since as that.
Making decisions in the presence of uncertainty with limited resources is the domain of Macro and Micro Economics
Making decisions in resource-limited situations at the national or global scale is macroeconomics. Macroeconomics is the study of how people make decisions influenced by tax rates, interest rates foreign policy, and trade policy. Microeconomics is the study of how people make decisions on a personal scale and treats decisions that individual and organizations make. For example, about which software to buy, which Features in the development backlog should be implemented next, what prices to charge for products and services.
Software development is an exercise in microeconomics, since it deals with limited resources - time, cost, and what value is produced in exchange for the time and money.
Because of the limitations of resources, projects need to operate withing a world of limited resources, the uncertainties - both reducible and irreducible - that create risk, and the emerging attributes of all project work. This is the foundation for estimates. Estimates with accuracy and precision values needed to make credible decisions. These estimates are critical to both developers and customers. Underestimating software engineering costs could result in management approving proposed systems that potentially exceed budget allocations, or underdeveloped functions with poor quality, or a failure to complete a project on time. Overestimating costs may result in too many resources committed to a project, or, during contract bidding, result in losing a contract and loss of jobs.
These estimates are used for generating requests for proposals, contract negotiations, scheduling, monitoring, and control.
Managing in the presence of uncertainty requires a Closed Loop Control process. Where targets are set, work is performed, feedback received, corrective actions taken it steer toward the target. Without that target and the error bands on the target and the processes used to steer, Close Loop Control will be ineffective - constantly chasing a moving target, with understanding of what could result, versus what should result.
Accurate and precise estimates - with predefined values for the accuracy and precision needed to satisfy the attributes of the Closed Loop Control system - are needed because:
Since uncertainty creates risk, managing in the presence of uncertainty is Risk Management. Since risk management is how adults manage projects, † making estimates in the presecnce of uncertanty is adult management.
No Estimates? No Adult Management.
Here are three starting resources for Software Economics:
† Tim Lister, Risk Management is Project Management for Grownups
Increasing the Probability of Project Success
Simple in Theory, Complex in Practice
When we hear any suggestion about improving the probability of success of a project, there are some simple tests to confirm there actually is such a thing. This means having a set of Principles, Process, and Practices to test the suggestion against. Let's start with the Principles
Let's start with the Principles
These Five Immutable principles are time phased into Processes that provide answers to the Five Principles.
and the connections between each Process are made to form a Closed Loop control systems needed to manage any project.
With some details for each process area
To support these Principles and Processes, a set of Practices are needed
These charts are an extract from the book Performance-Based Project Management: Increasing the Probability of Project Success and the abstracted training materials Handbook.
I received a book over the Holidays - Managing Project Risk and Uncertainty: A Constructively Simple Approach to Decision Making, Chris Chapman and Stephen Ward. This is a seminal work on risk management in the presence of uncertainty. The introduction has this...
Uncertainty in the plan English sense is lack of certainty has important implication for what can be acheived by organizations. All Management decision should take uncertainty into account. Sometime the implcations of uncertainties are risk in the sense of significant potential unwlecome effects on orgainzation performance.
Success in the presence of uncertainty requires a process be followed. Here's a recommend one:
|Stage in the Decision Process||Uncertainty About|
|Monitor the environment and current operations within the orgainzaiton||Completness, veracity, and accuracy of information received, meaning of information, interpretation of implications|
|Recognize the Issue||Significance of issue, need for action|
|Scope of decisions||Appropriate frame of reference, scope of relevant organization activities who is involved, who should be involved, extent of separation from other decision issues|
|Determine the performance criteria||relevant performance criteria, whose criteria, appropriate metrics, appropriate priorities, and trade-offs between different criteria.|
|Identify alternative course of action||Nature of alternatives available (scope, timing, and logistics), what is possible, level of detail required, time available to identify alternatives.|
|Predict the outcomes of courses of action||Consequence, nature of influencing factors, size of influencing factors, effects and interactions between influencing factors (variability and timing), nature and significance of assumptions made|
|Chose the course of action||How to weight and compare predicted outcomes|
|Implement the chosen alternatives||How alternatives will work in practices|
|Monitor and review performance||What to monitor, how of term to monitor, when to take further actions|
In order to make decisions in presence of uncertainty, we need to estimate all the partially elements of the decision process. Withoitn these estimates thetre is no Risk Management. Without Risk Management, there is no SAdult management of the project.
Risk Management is How Adults Manage Projects - Tim Lister
One of the principles of agile development is self-organizing teams. Self-Organizing is a powerful process. But Self-Directed is not the same as Self-Organizing. On all but de-minimis projects, there is some external organization that is defining what Done looks like at the business capabilities level. In Scrum, this is the Product Owner, who is a member of the team. The PO is defined as:
The keeper of the requirements. The Product Owner provides the “single source of truth” for the Team regarding requirements and their planned order of implementation. In practice, the Product Owner is the interface between the business, the customers, and their product related needs on one side, and the Team on the other. The Product Owner buffers the Team from feature requests that come from many sources, and is the single point of contact for all questions about product. The PO maintains the Product Backlog, sets the schedule for releasing completed work to customers, and makes the final call as to whether implementations have the features and quality required for release.
But First a Statement of Principles
Without a set of principles, it's difficult to have a conversation about seeking a shared understanding of the problem and possible solutions for almosty any topic. So for projects that spend other people's money in the presence of uncertainty - Governance is a means to establish those shared principles.
Governance is about Decision Rights. Specifying the decision rights and accoutability framework to encourage desirable behaviours in the developemnt and use of information technology and its supporting services. - IT Governance: How Top Performers Manage IT Decision Risght for Superier Results, Weill and Ross, Harvard Business School Proess.
In this Role (like all members of Agile teams, the PO is a role, not a position) the business value stream is conveyed from the business to the development team through the Product Roadmap and Release Plan. With the Team's full contribution to these artifacts, the Product Owner is Accountable to the business for delivering that value from the Scrum Team's outcomes. This is paradigm is usually found at the Enterprise level of software development. If you're working on a self-contained team, where the customer, PO, development team, and all supporting roles are all sitting at the same table, with a low ceremony around cost, schedule, or deliverable - you can stop reading now. You don't need governance, a Product Roadmap, and Release Plan. Just code and the person paying you will tell you what to do next.
But if you're on a team that gets its funding outside the team, then there is likely a governance process in place for how to spend that money. In this case, there are others who are Accountable for delivery working software. Not designing and developing the software. But those that have a business role for the use of that software to make money or provide a mandated service.This is the Team itself as a collective, but there is a separation of concerns on any non-trivial project as well. The UX/UI designers are Accountable for developing human factors and compliance -
In this governance paradigm, the Team itself is still a collective, but there is a separation of concerns on any non-trivial project as well. The UX/UI designers are Accountable for developing human factors and compliance - 508 Compiance for example - as well as compliance with the current or future UX/UI processes. The Database performance lead on the team is accountable for assuring the code and web service maintain the needed database performance. The Cyber Security lead is Accountable for assure the work of the developers adheres with NIST Cyber Security Framework when the system is public facing with controlled content. The Architect is accountable for assuring the code developed by the Team is compliant with the established Architecture. For example TOGAF or in the DOD, DODAF, or in some other domains industry architectures. IEEE 1553 for real-time embedded system.
In these examples, there is usually some overarching governance process. If yu have no governance process, then none of this accountability discussion is applicable - do what you want not one cares. But if someone does care, usually the customer and those paying, then the notion of Accountability is the basis of project success.
The Responsibility Assignment Matrix
First, there are many alternatives to RACI, so this post is about a Principle and in this case a Practice and Process. On projects where governance is in place, a Responsibility Assignment Matrix (RAM) is a means of defining who is participating in what Role on the project. The RAM defines the single points of accountability for project Leadership Team. These assignments start by identifying who is accountable for which project roles before the project starts. As the project matures, a delegation of these responsibilities down to the project team members using the RACI tool.
In an enterprise project here's an example of the locations for Accountability at the enterprise.
For agile programs, replace the PM with the PO and the diagram above remains the same. From this business governance process, we can build a RAM.
The RACI paradigm should actually start with Accountability - but ARCI which isn't as snappy. RACI provides the means to flow down responsibility from the Accountability. There cannot be multiple people Accountable, but there can be multiple people Responsible. Without a single point of integrative responsibility, it's not clear who gets to say what about the spending of other people's money. Again if you have no governance process, spend as you wish, do as you wish, no one care. But if there is governance, one place for developers to looks as to WHY governance is needed (rather than saying it's a waste) is Essentials of Managerial Finance, Besley and Brigham. This book explains why and how to manage other people's money when producing products or services in exchange for that money.
In The End
If it's your money or maybe your parents money, no one carees how you spend it. But if it's not your money - investors, relatives, the firms money, the stockholders money, the owners money - then some form of governance is likely needed. With this governance paradigm in place, some structure around who gets to decide how to spend that money is likely needed. With that need in place RACI (or its relatives) is a way to have a conversation about who, what, when, and why descioons can be made.
The governance process is based on 3 pillars:
This is the basis of Governance - It's About Decision Rights.
No need for decision rights? Spend away
 COBIT 5 ISACA's new Framework for IT Governance, Risk, and Security Auditing: An Overview
 The Role of ITIL in IT Governance: Leveraging IT Governance around IT Service Management
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 Enterprose IT projects as well as the other projects and programs where it is currently used.
Let's 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 haveing 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
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