An Example of Complete Misunderstanding of Project Work

This is one of those pictures tossed out at some conference that drives me crazy. It needs to be more informed, ignores the disciplines of developing software for money, and is meant to show how smart someone is without actually understanding the core processes needed for being knowledgeable of the topic - in this case, statistical methods of project work. Then, the picture gets circulated and re-posted and becomes the basis of all kinds of other misunderstandings, just like the Dilbert cartons that represent cartons of the problem but have no corrective actions associated with them.

In some agile development circles, it is popular to construct charts showing the?strawman of deterministic and waterfall approaches, then compare them to stochastic?approaches and point out how much better the latter is than the former. Here's an example.

These?strawman approaches are, of course, not only misinformed, but they're essentially nonsense in any domain where credible project management is established, and the basis of their response with

Don't do stupid things on Purpose.

Let's look at each?strawman?statement for the Deterministic View in light of actual project management processes, either simply?best practice or?mandated practice.

• Technologies are stable—no one believes this that has been around in the last 50 years. And if they do, they've been under a rock. Suggesting this is the case ignores even?the simplest observations of technology and its path of progress.
• Technologies are predictable—anyone who has any experience in any engineering discipline knows this is not the case. Beyond the simplest single?machine, unintended consequences and emergent behavior are obvious.
• Requirements are stable—no, they're not, not even in the bonehead's most straightforward project. This would require precognition and clairvoyance.
• Requirements are predictable—no, they're not. As a cub developer, you can learn this by reading requirements management guidance, observing requirements elicitation processes, or working on non-trivial projects.
• Helpful information is available at the start - this would require?clairvoyance.
• Decisions are front-loaded,?which ignores the principles of microeconomics of decision-making entirely in the presence of uncertainty. This is a good way to set fire to your money. For a good survey of when and how to make front-loaded decisions,s see?Making Essential Choices with Scant Information. Als,o buyWilliams's another boo,k?Modelling Complex Project,?along with another boo,k Project Governance: Getting Investments Right.?This statement is a prime example of not doing homework before deciding to post something publicly.
• Task durations are predictable—all task durations are driven by aleatory uncertainty. For this to be true, the laws of stochastic processes would have to be suspended. Another example is being asleep in the High School statistics class.
• Task arrival times are predictable—the same as above. It must have been a classics major in college, with full apologies to our daughter, who was a classics major.
• Our work path is linear and unidirectional. This would require the problem to be so simple that it can be modeled as a step-by-step assembly of Lego parts, which is unlikely in any actual non-trivial project. When a system of systems becomes the problem—any enterprise IT project, any complex product—the conditions of linear and unidirectional go out the window.
• Variability is always harmful—it violates the basis of all Variability systems, where DeminVariabilityty is built into the system. Didn't anyone who made this chart read Deming?
• The math we need is arithmetic - complete ignorance of the fundamental processes of all systems - they are statistical generating functions creating probabilistic outcomes.

The only explanation here is the intentional ignorance of basic science, math, engineering, and virtual computer science.?

In the stochastic View, there are equally egregious errors.

• Technologies are evolving—of course. Look at any technology to see rapid and often disruptive evolution. Project management is Risk Management. Risks are created by uncertainty—reducible and irreducible. Managing in the presence of uncertainty is how adults manage projects.
• Technologies are unpredictable—in some sense—but we're building systems from parts in the marketplace. If you're a researcher at Apple, this is likely the case. If you're integrating an ERP system, you'd better understand the process, technology, and outcomes, or you're going to fail. Don't let people who believe this spend your money.
• Requirements are evolving—of course, they are. But the needed capabilities had better be stable, or you've signed up for a Death March project with no definition of done. But requirements aren't the starting point; Capabilities are. Capabilities-based Planning is how enterprise and complex projects are managed.
• Requirements are degrees of freedom—I?have no idea what this means. Trade Space is part of all good engineering processes. I wonder if the author or those referencing this chart know that.
• Helpful information is continuously arriving - of course it is. This work is called engineering and development. Both are?verbs.
• Decisions are continuous - of course they are. This is the core principle of microeconomics for all business decision-making. But front-end decisions are mandatory. Please review "Issues on Front-end Decision Making?" for some background before considering this statement. And a summary of the concept of the Williams book above.?
• Task arrival times are unpredictable - this is intentional ignorance of stochastic processes. Prediction always includes confidence and a probability distribution. Predictions?are simply saying something about the future. For task arrival time to be unpredictable, it would have to be completely chaotic, with no underlying process to produce them. This would be unheard of in project work. And if so, the project would be disorganized and destination to fail to start on the day way—another example of being asleep in the stats class.
• Our work path is networked and recursive—of course it is. But this statement is counter to the INVEST condition of agile, which is present in only the simplest projects.?
• Variability is required - all processes are stochastiVariabilityty—a tautology. Natural variabVariabilityreducible. Event-baseVariabilityty disrupts productivity, quality, cost, schedule performance, and forecasting when, how much, and what will be delivered in teVariabilitybilities. Uncontrollable liability is counter to proper stewardship of your customers' money.
• The math we need is probability and statistics - yes, and you'd better have been paying attention in the High School statistics class and stop using terms you can't refer to in the books on your office shelf.?

In the End

For some reason, using charts like this one, re-posting Dilbert cartons, and making statements using buzzwords - we're using Real Options and Bayesian Statistics to manage our work - are my favorite ones - seems to be more common the closerViewget to the sole contributor?point of view. Look at my 22 samples of self-selected data with a ±70% variance in forecasting future performance.

It may be because sole contributors are becoming more prevalent. Sole contributors?have certainly changed the world of software development in ways never possible by larger organizations. But without the foundation of good math and sound systems engineering—and I don't mean "data center systems engineering," I mean?INCOSE?Systems Engineering View—those sole contributor points of view simply don't scale.

Always ask when you hear the advice:?In what domain have you successfully applied this advice??

The Best example of this question is the #NoEstimates fallacy, as discussed Here.