An Example of the Complete Misunderstanding of Project Work

This is one of those pictures tossed out at some conference that drives me crazy. It's uninformed, 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 circles of agile development, it is popular to construct charts showing the?strawman of deterministic and waterfall approaches, then compare them to the stochastic?approaches and point out how much better the latter is than the former. Here's an example.

Of course, these?strawman approaches are not only misinformed but essentially nonsense in any domain where credible project management is established. This is the basis of their response: 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 most superficial observations of technology and its path of progress.
• Technologies are predictable—anyone with any engineering discipline experience knows this is not the case. Beyond the most straightforward single?machine, unintended consequences and emergent behavior are apparent.
• 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 the requirements elicitation process, or working on a non-trivial project.
• Helpful information is available at the start - this would require?clairvoyance.
• Decisions are front-loaded, which completely ignores the principles of microeconomics of decision-making in the presence of uncertainty. It's an excellent way to set fire to your money. See Making Essential Choices with Scant Information for a good survey of when and how to make front-loaded decisions. Also, could you buy Williams's other book,?Modelling Complex Projects , along with Project Governance: Getting Investments Right ??This statement is a prime example of not doing homework before publicly posting something.
• 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 non-trivial project. When a system of systems becomes the problem—any enterprise IT project, any complex product—the linear and unidirectional conditions go out the window.
• Variability is always harmful—it violates the baVariability engineering systems, where variability 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 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'll 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 the degree of freedom - I have yet to learn what this means. Trade Space is part of all sound 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. Before considering this statement, please review "Issues on Front-end Decision Making ?" for some background. 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. However, this statement contradicts the INVEST condition of agile, which is present only in the most straightforward projects.?
• Variability is required—all processes are variable processes. This is a tautology. Variability is irreducible. It disrupts productivity, quality, cost, schedule performance, and forecasting when, how much, and what capabilities will be delivered. Variability counters proper stewardship of your customer's 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, making statements using buzz words - we're using Real Options and Bayesian Statistics to manage our work - are our favorite ones - seems to be more common closer we get to the sole contribView?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 that were 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 SysView Engineering—those sole contributions of view simply don't scale.

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