“In everyday life, the Flaw of Averages ensures that plans based on average customer demand, average completion time, average interest rate, and other uncertainties are below projection, behind schedule, and beyond budget.” – Sam L. Savage, 2009 – The Flaw of Averages
“Variation is the hard reality, not a set of imperfect measures for a central tendency. Means and medians are the abstractions.” – Stephen Jay Gould, 1985 – “The Median Isn’t the Message”
“Essentially, all models are wrong, but some are useful” – George E. P. Box, “Empirical Model Building and Response Surfaces”, (1919 – 2013)
“Remember that a model is not the truth. It is a lie to help you get your point across.” – Sam L. Savage, “The Flaw of Averages”, 2009
“You are allowed to lie a little, but you must never mislead.” – Paul Halmos, mathematician, (1916 – 2006)
Last week I read an article about yet another tool showing the ability to produce CFDs (cumulative flow diagrams). Maybe you’re already a user of one of these tools that help you visualize your workflow, and generate them for you automatically (or “auto-magically”) as part of reports they provide. Or, perhaps like me, you still generate them mostly using MS-Excel. Either way, have you wondered just a little about how a CFD works?
As most do, this article displayed a line extending vertically between “stages” on the CFD (or workflow processes, as I often call them) and identified this distance as the WIP (work-in-progress) on a specific date for the respective stage (or stages) of interest. There was also a description of another distance, a line extending horizontally between stages of interest on the CFD and identifying it as the “average lead time” for the requests (workitems) arriving on a specific date. That is, the average time for a request (workitem) to “flow” through (arrive into and depart out of) one or more stages of interest. Lastly, there was a description of a sloped line, as a mean delivery rate of requests (workitems) flowing into or out of a stage (workflow process) depending on viewing the workflow upstream or downstream. Note: for more on the basics on reading a CFD, see this earlier post here.
A Difference Is Not An Average, Right?
It is easy to understand that WIP is simply a “difference” between two counts on the CFD and represents the number of requests (workitems) at a point in time. Similarly, seeing the slope as a simple rise over run calculation of a number of requests per unit of time (a rate over a period of time of interest) is not a complex concept to accept. But, what about the notion of the “average lead time” derived from the CFD? How is it a “difference” between two points in time read from the CFD (ex. calendar dates) can represent an “average” unit of time for a request (workitem) to flow through a stage (workflow process)? A “difference” that represents N numbers summed up and divided by N. Yes, really! But how can this be?
“Don’t manage the unknown and unpredictable the same way you manage the known and predictable.”
– Doug DeCarlo, Oct 2004 – eXtreme Project Management
“Managers must be flexible enough to adopt the right approaches at the right time…to find the balance between planning and learning.”
– Arnoud De Meyer, Christopher H. Loch, and Michael T. Pich – Managing Project Uncertainty: From Variation to Chaos
Reflecting on the last ten years of my own experience working on projects, early on, I saw mostly “traditional project management.” That is, project management that places greater emphasis on planning upfront, and as a whole, a greater proportion of the total project planning is done very early in the project, and seeks to provide predictability of activities over longer planning horizons. Other terms I’ve heard for this project management style are “predictive” or “sequential (gateway) delivery.” In more recent years, however, my experience has been to see “iterative and incremental” approaches. Again, that is, project management that places less emphasis on planning upfront, and as a whole, a greater proportion of the total project planning is done in small amounts iteratively across the project, and seeks to provide predictability of activities only over shorter planning horizons. Other terms I’ve heard for this project management style are “emergent” and “incremental delivery.”
While this is a minimal level of distinction, for our purposes it will be sufficient. This won’t be a post on “good vs. evil” styles of project management. In fact, I’m advising, that might be a “limiting” perspective. Rather, the “focus” is to view projects from a perspective of uncertainty (as a model) to gain insights into these two project management styles that may help us more effectively manage our projects.
Are All Projects the Same?
In your experience, how often have you seen projects managed differently from one another? Is there “evidence” to suggest, based on how you manage or see projects managed, that all projects are the same? (more…)
Note: In his book “Actionable Agile Metrics for Predictability”, my colleague Dan Vacanti expands on my FedEx example while discussing further the notion and benefits of “slack” in the software development context. You’ll find this discussion in Ch. 13 Pull Policies.
“The beauty of using a flow system and a visual control is that we can measure cycle time and we can observe context…
The trappings of false certainty we gave ourselves in previous methodologies are being replaced with the comfort of graspable variation in kanban…
We now see knowledge work for what it is – a chaotic system that is fully manageable and understandable by its outputs and contexts, but very much unknowable by its actions and specifics.”
– Jim Benson, Sep 2011
The title of this post contains an answer and a question. However, it’s a “question” that prompted the answer part of this title, and my recollection of how both came to me originally, that I’m interested in sharing in this post and hope you find interesting if not amusing. As for providing an “answer” to the question part of this post’s title, that I’ll leave entirely to you.
Who Mentioned Variability?
This summer I had an opportunity to help out with a training class introducing the kanban method to a few members from several teams that all worked in a software development and operations support context. On the second day of this training we came to a section titled “Understanding Variability.” As the class began discussing why this might be important, I couldn’t help but flashback to a time when I heard my wife shout “It’s Slack! Who can’t see that?”, as she was watching a TV program in our family room. I’m sure at the moment of my flashback, more than a few in the training classroom wondered how I could be enjoying the discussion so much, while I sat there listening with a big smile on my face, chuckling a bit, as if I was somewhere else hearing a comic telling his latest and greatest jokes. The truth was, I was somewhere else for the moment.
The year 2009 was coming to an end, and it was a few days before New Year’s Eve. I was at home in the loft sitting at my computer reading or writing something, when I heard my wife shout from below “It’s slack! Who can’t see that?” as she walked out of the family room. The tone in her voice hinted it was the “Who can’t see that?” part that she was most excited and proud to share right at that instant. However, I was much more interested in knowing the yet unknown question that prompted her to excitedly shout “It’s slack!” It was obvious too, she had more to share with me right then, something I’ll now share a bit about with you. (more…)