Principles, Practices, and Processes to Increase Probability of Project Success
To increase the probability of project success, many things have to happen at the same time. Here's are Five principles and practices that can increase that probability of success
I'm working an Implementation Review (IR) of a major space flight vehilce, that includes Software Intensive System of Systems.
Here are the guidelines for a credible cost estimate (GAO-16-620)
These guidelines are comprehensive and not likely to cover most projects or programs. But it's good to ask how many of these attributes can be found in your cost estimate?
20 Logical Fallacy Found in Agile and related topics
The suprising discovery of Newton's is just this, the clear seperation of laws of nature on one hand and initial conditions on the other - Eugene Wigner, in Newton's Principis for the Common Reader, S. Chandrasekhar
There are 5 immutable principles of project success. Without the initial conditions of these five principles, the project has little chance of success.
All project work is uncertain. Uncertainty comes in two types - Reducible (Epistemic) and Irreducible (Aleatory). These uncertainties create the risk to the success of all projects. Without managing in the presence of risk, the probability of project success is significantly reduced, most likely reduced to zero.
First a definition
A risk is an issue or event that could prevent a program or project from meeting its technical, schedule, cost, or safety objectives.
Management in the presence of risk has the following steps: 
For this process to work, each activity - in the presence of uncertainty - must be estimated.
So in the end, if we're going to be adults when managing projects, especially projects funded by other people's money, we need to act like adults and estimate. Without estimates of the uncertainties, the risks created by those uncertainties, the effectiveness of our risk handling processes - research, accept, watch, or mitigate in the NASA paradigm, the effectiveness of the controlling processes, and even the effectiveness of the communication processes - there will be little chance of success for our risk management process.
Let's change Tim Lister's quote and call it as it is
Estimating is how adults manage projects. No estimates No adult management
and the story in our neighborhood when our sons were in the Scouts...
what's the difference between our organization and the Boy Scouts? The Boy Scouts have adult supervision.
 NASA's approach to Continuous Risk Management, described in "NASA's Management of the Orion Multi-Purpose Crew Vehicle Program," September 2016
The Due Date doesn't mean the Do Date
If you have a Due date, you need the plan to show up on that date, with what is Due for the cost of that Due Item and have that Due Item be compliant with the attributes (effectiveness and performance) needed by those paying you.
I was asked to look at a corrective action plan this year, that had a list of deliverables that were supposed correct the root causes of the problems identified as the reason the project was not performing as planned. The right two columns were the person performing the work and the DONE date.
A big smile came to my face. I see the real root cause of your troubles here. You don't know what Done looks like. That's the first immutable principle of project success.
Without knowing what Done looks like in units of measure meaningful to the decision makers, the project has little hope of success.
Most people know nothing about learning; many despise it. Dummies reject as too hard whatever is not dumb - Thomas More, Utopia
The Fallacy - We can't know much of anything about the Future. But in fact, the future is always knowable to some degree of precision and accuracy unless it is truly Unknowable
Software developers and the IT managers they work for operating in the future. Many of this practitioners view the future as an esoteric, abstract, impractical realm, But the future is where the value of the software is earned. The future is where to cost to develop that software is paid back. The future is where the users of the system will be satisfied with the provided capabilities.
The primary job of management and those developing value for management is to find the future, not just the future in general, but the specific futures for the customers. - Al Ries, in Positioing the Battle for Your Mind.
This future is not in the resulting products and services but the cost, schedule, and technical attributes needed to produce these products and services. Knowing this future can be on large-grained boundaries - sometimes called waterfall. Or on fine grained boundaries - sometimes called spiral, incremental commit and agile.
All Project Work Operates in the Presence of Uncertainty
All work even production line work operates in the presence of uncertainty. Uncertainty comes in tow forms - Aleatory and Epistemic
Managing in the presence of these two uncertainties requires one or two approaches:
Now to the Logical Fallacy
In the presence of Aleatory and Epistemic uncertanty, risk is created to the cost, schedule, and technical performance of the project. To assess the impact of that risk, devise the protective actions needed to address the resulting risk - ESTIMATING is required. Without estimates the Aleatory and Epistemic uncertanty that exists on All project will go unaddressed and the probablity of project sucess will be significanlty reduced, perhaps to Zero.
Without estimating both the probability of occurance (for reducible uncertanties) and the statistical processes (for irreducible uncertanties) informed decsions cannot be made.
The falalcy is that decsions can be made in the presence of these uncertanties - that exist on all project work - willfully ignores these principles.
There are two type of errors made, of which this fallacy adheres:
 Software Cost Estimation with COCOM II, Barry Boehm, et al
 The Incremental Commitment Spiral Model, Barry Boehm, and Jo Ann Lane
 The Economics of Iterative Software Development, Walker Royce
 Facts and Fallacies of Software Engineering, Robert Glass
 Distinguishing Two Dimensions of Uncertainty, Craig Fox and Gülden Ülkumen, in Perspectives of Thinking, Judging, and Decision Making
 Decision Analysis for Professionals, Peter McNamee and John Celona
Those making the original assertion need to bring evidence. Without that evidence, those challenging the assertion have no need to bring evidence. For those making the assertation to ask for evidence as to why their conjecture is correct is the Burden of Proof fallacy, which is common when the original conjecture has no basis in principle, fact, or experience - it's just a conjecture. All attempts by the original assertion author to invert this fallacy should be strongly rejected, since it shows a lack of understanding of who ideas are put forth and tested in the larger marketplace of ideas.
The Standish Report is raising its head again in the Agile presentations I've seen recently at conferences. Forgetting for the moment all the past "criticisms" of Standish...
The numbers in the report are still being used by "agile thought leaders" to establish the basis for their proffered solutions. Forgetting even more that "agile" is a bottom-up software development solution. And that most of the issues with large IT programs are leadership at the senior executive level, externalities from the market place at large, and general inability to connect the dots between business strategy and business execution.
And of late by the #NoEstimates thought leader to further their unsubstantiated conjecture that decisions can be made while spending other people's money in the presence of uncertainty.
Further is the complete lack of transparency in the statistical numbers. But here an alternative on how to report IT project success.
The definitions of "needs attention" and "significant concerns" is provided in terms of mission suitability rather than simple - and simple-minded cost and schedule.
So it's time once more to move beyond the worn out red herrings and start to address how to Increase the Probability of Project Success with processes and tools beyond just applying Scrum to the development team.
Willian pointed out the bands for measuring success. http://it.usaspending.gov/faq-agencies
The speach I love is a simple, natural speach the same on paper as in the mouth; a speach succuleant and sinewy, brief and compressed not so much dainty and well-combed as vehement an brusque - Michel de Montaigne The Essays of Montaigne (1580).
Deming's approach to problem solving is based on The System of Profound Knowledge (SOPK). The anti-pattern to SOPK is The System of Profound Ignorance (SOPI).
To obtain a System of Profound Knowledge, we need to start with the four components - appreciation of the system, theory of knowledge, knowledge of variation, and the psychology of the people and process working within the system.
While knowledge of these understandings are standard for any credible management process of other people's money are needed, there is the inverse of this knowledge in play for the #Noestimates advocates.
The leadership of this notion that decisions can be made in the presence of uncertainty without estimating seem to have missed the core knowledge of the principles of decision making. The opposite of knowledge is ignorance, so the framework of #NoEstimates is an anti-SOPK.
When you hear...
#NoEstimates is a hashtag for the topic of exploring alternatives for making decisions in software development. That is, ways to make decisions with "No Estimates"
Think about the conjecture. How would you assess a decision in the presence of uncertainty without making an estimate of the outcome of that decision. Since there is not deterministic data available about the future, even though you may have deterministic data from the past. This would mean the future is like the past, there is no uncertainty about the future - either reducible (epistemic) or irreducible (aleatory). No conditions that were in place from the past will be changing in the future. Nothing is going to emerge that you have not accounted for. Nothing is going to change in any attribute, process, or people doing the work..
Such a process defies the principles of microeconomics of decision making. Defies the principles of managerial finance in the presence of uncertainty. Defies the principles of closed loop control systems in the presence of stochastic non-stationary systems.
It simply defies the principles of logic