Essential Reading List for Managing Other People's Money

Education is not the learning of facts, but the training of the mind to think?- Albert?Einstein?

So if we're going to?learn how to think?about managing projects or programs while spending other people's money in the presence of uncertainty - both reducible (Epistemic) and irreducible (Aleatory) that creates cost, schedule, and technical performance risk, we need some basis of education.?

Uncertainty is a fundamental and unavoidable feature of daily life: personal life and the life of projects. To deal with this uncertainty intelligently, we represent and reason about these uncertainties. There are formal ways of reasoning (logical systems for reasoning found in the Formal Logic and Artificial Intelligence domain) and informal ways of reasoning (based on probability and statistics of cost, schedule, and technical performance in the Systems Engineering domain).

If Twitter, LinkedIn, and other forum conversations have taught me anything, many participants base their discussions on personal experience and opinion. Experience informs opinion. That experience may be based on?gut feeling?learned from the?school of hard knocks.?But there are other ways to learn as well. Here are ways to guide your experience and let you know your option. Ways based on education and frameworks for thinking about solutions to complex problems.

Samuel Johnson has served me well with his quote...

There are two ways to knowledge,?We know a subject ourselves, or we know where we can find information upon it.

Hopefully, the knowledge we know ourselves has some basis, theory, and practice, vetted by someone outside ourselves, someone beyond our personal anecdotal experience

Here's my list of essential readings that form the basis of my understanding, opinion, principles, practices, and processes applied in the domains I work with Enterprise I.T., defense and space, and their?software intensive systems .

Making Hard Decisions: An?Introduction?to Decision Analysis , Robert T. Clemen

• Making decisions in the presence of uncertainty is part of all business and technical endeavors.
• This book and several others should be the start when making decisions about how much, when, and what.

Apollo Root Cause Analysis: Effective Solutions to Everyday Problems, Every Time, Dean L. Gano.

• There is a powerful quote from Chapter 1 of this book
• STEP UP??TO FAIL
• Ignorance is a wonderful thing.
• It facilitates magic.
• It allows the masses to be led.
• It provides answers when there are none.
• It allows happenings in the presence of danger.
• All this, while pursuing knowledge, can only destroy the illusion. Is it any wonder mankind chooses ignorance?
• This book is the starting point for all that follows. I usually only come to an engagement when there is?trouble.
• You don't need to improve if there's no trouble.
• Without a Root Cause Analysis process and corrective actions, all problems are symptoms. And treating the symptoms does little to make improvements to any situation.?
• So this is the seminal book, but any RCA process is better than none.
• The Phoenix?Handbook,?William R. Cocoran, Ph.D., P.E., Nuclear Safety Review Concepts, 19 October 1997 version.
• This was a book and process used at Rocky Flats for Root Cause Analysis

Effective Complex Project Management: An?Adaptive?Agile Framework for Delivering Business Value , Robert K. Wysocki, J. Ross

• All project work is probabilistic.
• All project work is complex. Agile software development is different from project management.
• Project management is needed for agile software development beyond a handful of people in the same room as their customers.
• This book tells you where to start performing Project Management functions in the Enterprise domain.

The Art of System Architecting, 2nd Edition , Mark W. Maier and Eberhardt Recthin, CRC Press

• Systems have architecture. This architecture is purpose-built.
• The notion?that the best architectures, requirements, and designs emerge from self-organizing teams must be tested in a specific domain.
• Many domains have?reference architectures. DODAF ?and?TOGAF ?are two examples.
• Architectures developed by self-organizing teams may or may not be helpful over the system's life. It depends on the skills and experience of the?architects. Brian Foote has a term for self-created architectures -?a ball of mud. So, ensuring the self-organizing team can produce a good architecture is necessary.
• The Recthin book can be your guide for that test.

Systems Engineering: Coping With Complexity , Richard Stevens, Peter Brook, Ken Jackson, Stuart Arnold

• All non-trivial projects are systems.
• Systems are complex, and they contain complexity.
• Defining?complex complexity and complicated?needs to be done with care.
• More information is needed in the Agile community about these terms. Usually used to make so point about how hard it is to manage software development projects.
• There is a strong case that much of software development's?complexity?and?complex?aspects could be better?requirements management.

Forecasting and Simulating Software Development Projects: Effective Modeling of Kanban & Scrum Projects using Monte Carlo Simulation , Troy Magennis

• When we hear?that Control in a non-deterministic paradigm is an illusion at best and delusion at worst starts with Troy's book to see that conjecture is invalid.
• If the system you're working on is genuinely non-deterministic - that is chaotic - you've got a long road because you're on a Death March project. Run away as fast as you can.

Probability Methods for Cost Uncertainty Analysis: A Systems Engineering Perspective , Paul R. Garvey, CRC Press.

• All project variables are probabilistic. Managing in the presence of uncertainty created by the statistical processes, the result in probability is part of all project management.
• This book speaks to the uncertainty in cost.
• Uncertainty in schedule and technical performance are the other two variables.
• Assuming deterministic variables or thinking you can't manage in the presence of uncertainty is naive and ignore the basic mathematics of?making decisions in the face of uncertainty.

Estimating Software-Intensive Systems:?Projects, Products and Processes , Richard D. Stutzke, Addison Wesley.

• Software Intensive Systems?s any?system?where?software?contributes essential influences to the system's design, construction, deployment, and evolution. [IEEE 42101:2011]
• Such systems are by their nature complex, but estimating the attributes of such systems is a critical success factor in all modern business and technology functions.?
• This book is mandatory reading for anyone conjecturing estimates can't be made in a complex system.?
• Estimates are complex but can be done and done.?
• So when you hear that conjecture, ask?how you know those estimates can't be made. Where's your evidence that counters the work found in this book? Not?anecdotes,?optioning,??conjectures, but actual engineering?assessment with mathematics?

Effective Risk?Management:?Some?Keys to Success, 2nd?Edition , Edmund H. Conrow.

Project Risk Management: Processes, Techniques and Insight , Chris Chapman and Stephen Ward.

• These two books are the core of Tim Lister's quote
• Risk Management is How Adults Manage Projects
• Risk management involves estimating

The Economics of?Iterative?Software Development" Steering Toward Business?Results , Walker Royce, Kurt Bittner, and Mike Perrow.

• All software development is a?MicroEconomics ?paradigm.
• Where?the behavior of individuals and small impacting organizations in making decisions on allocating limited resources.
• When you hear about conjectures for improving software development processes that violate Microeconomics, ignore them.
• These limited resources are people, time, and money

Assessment?and Control of?Software?Risks , Capers Jones.

• Since all management is risk management, here's a book that clearly states how to manage in the presence of uncertainty.

Software Cost?Estimating?with COCOMO II , Barry Boehm et al.

• This is the original basis of estimating with parametric processes
• Numerous tools and techniques are based on COCOMO
• Parametric estimating uses Reference Classes, the same as Monte Carlo Simulation.
• With a parametric or Reference Class model, future outcomes can be estimated in every domain where we're not inventing new physics. This means there is no reason not to estimate for any software system in a normal business environment.
• This is different from saying everyone can estimate. Nor should they. The?excuse?that?we've never done this below?really means you should find someone who has.

Facts and Fallacies of Software Engineering , Robert L. Glass

• There are many fallacies in the development of software
• This book exposes most of them and provides corrective actions
• How to Measure Anything: Finding the Value of Intangibles in Business, Douglas Hubbard
• When we hear,?we can't measure?read this book.
• This book greatly describes Monte Carlo Simulation (used everywhere in our domains).?

Monte Carlo ?(MCS) started at Los Alamos during the bomb development process

• MCS samples a large number of values?under?in Probability Distribution Function that represents the statistical processes that are being modeled.?
• MCS has some relatives; Boot Strapping ?is one. But it operates differently, though, using past performance as a sample population.

Hard Fact, Dangerous Half-Truths & Total Nonsense , Jeffrey Pfeffer and Robert Sutton

• This book was handed out by Ken Schwaber's "The State of Agile ."
• The key here is that decisions are best made using facts. When facts aren't directly available, estimates of those facts are needed.
• Making those estimates are part of every business decision, based on the Microeconomics of writing software for money.

So, In The End

This list is the tip of the iceberg for access to the knowledge needed to manage in the presence of uncertainty while spending other people's money.

Compendium of Resources

Here is a compendium of materials used to increase the probability of project success in the presence of uncertainty, with Capabilities needed for a defined cost on a defined date.

• Briefings, Papers, and Presentations ?developed for clients, conferences, journals, and book chapters.

These Compendiums of resources are used in managing Complex Software-Intensive Systems of Systems developed in a wide range of business and technical domains, from commercial enterprise software to manned spaceflight.

• A Compendium of Managing Complex Systems
• Compendium of Resources for Agile Project Management and Earned Value Management
• A Compendium of Risk Management Resources
• Compendium of Resources for Digital Twins, Model-Based Systems Engineering, and Integrated Program Performance Management
• A Compendium of Resources for Applying Design Structure Matrix to Complex System of Systems
• Compendium of Resources for Integrated Master Plan / Integrated Master Schedule
• Compendium of Resources of Capabilities-Based Planning
• Compendium of Estimating Resources
• A Compendium of Resources for Managing Complex Systems
• Compendium of Resources of Mathematics for Project Management
• Cybersecurity Resources for Federal and Commercial Systems
• Compendium of Root Cause Analysis Resources