Inoculating Ourselves from Misinformation

One of my favorite websites is Snopes, which is a fact-checking site and reference source for researching urban legends, folklore, myths, rumors, and misinformation. The same process they use can be applied in our Program and Project management domain, which abounds with legends, folklore, and misinformation.

They suggest five steps to inoculate against misinformation that can be applying to managing complex, evolving system of systems

• Don't mistake anecdotes for evidence ― we hear all the time personal anecdotes about what works and doesn't work when managing projects. Remember an anecdote is a sample of one from an unknown population. When you hear someone say something, even if that someone is a well-known voice in the PM world, ask that person, or ask yourself - what are the principles on which statement is basis. These principles start with risk-informed decisions making in the presence of uncertainty and the microeconomics of decision making in project management.
• Be aware of personal opinions based on emotion ― we all have personal experiences, with success and failure. When those experiences are based on established principles, and many times immutable principles, there is a high probability they can be transferred to other domains and contexts. So to test the validating of any experience used as a suggested action ask first -what domain is this applicable to? If it is generally applicable the principle on which it is based needs to also be generally applicable. For example, measuring progress to plan and using that progress as the basis to developing the Estimate to Complete and Estimate at Completion applies to every project. This means physical percent complete must be in units of measure meaningful to the decision-makers. The passage of time and consumption of money is not a meaningful measure of progress to plan. Tangible evidentiary materials in units of effectiveness and performance are.
• Reading the buzz-word compliant headline is not enough ― we need deep dives for almost everything we do as project managers. This is why handbooks, bodies of knowledge can be starting points, but putting that guidance to work requires further direction, tools, analysis, examples, and review.
• Trace all advice, suggestions back to references ― this is why all advice requires some form of reference and validation. Advice from experience is similar to anecdotes - a sample of one from an unknown population. When you hear some advice, a comment, a suggestion - ask for the basis of that advice, comment, or suggestion before putting it to work in your domain and context, unless what you are working on is de minimus - meaning if it's late, over budget, and doesn't work no one cares/
• Keep up to date ― The guidance from the past may or may not be applicable today. My favorite is the advice from the past on how to manage risk. In the current edition of The Standard for Risk Management in Portfolios, Programs, and Projects from PMI the words Aleatory and Epistemic are not found. The uncertainty appears 40 times, but only in the form of uncertainty is inherent in the nature of portfolios, programs, and projects, which is restating the obvious. Starting with Risk-Informed Decision Making current risk management guidance from NASA, National Nuclear Security Agency, and traditional nuclear systems guided by the Department of Energy, all the Insurance Underwriting guidelines, and other high risk, high reward domains mandates the separation of aleatory and epistemic uncertainties that create risk. The risk created by Aleartory uncertainty can only be handled with margin. Cost margin, schedule margin, technical margin. Aleatory is naturally occurring, like the weather or the productivity of a software developer. Unless you are a deity, you're not going to be able to improve that naturally occurring uncertainty and must have a margin to protect the project when it occurs, You do this for the weather by bringing an umbrella or adding rain delay margin to the schedule. For risk created by epistemic uncertainty, you can buy down this uncertainty with knowledge. Epistemology is the study of knowledge. This failure to separate aleatory from epistemic uncertainty is a serious flaw in the PMI approach to risk management. So keep up with the current principles, practices, and processes for all the elements of project management.

As a parting thought, ask and answer on a timely basis - What Corrective and Preventive Actions Must Be Taken To Increase the Probability of Project Success?