Drag – what resists and slows you down is what you need to eliminate in the pursuit of performance. But you can’t control what you can’t grasp, be it the air flowing around a race car or the thoughts going on inside the heads of knowledge workers. On making the ungraspable visible.
Ask people what it takes to build a better race car, and they’ll likely think of a more powerful engine. Fair enough. But what’s equally important but less intuitive is, for example, brakes. The fastest cars need the strongest brakes – how else would they rapidly change direction? And the real secret to going fast is eliminating what slows you down.
Air resistance increases with velocity squared. If you’ve ever stuck your hand outside of a moving car, imagine what syrupy resistance you’d encounter at more than three times the speed. Managing airflow is the main headache for Formula 1 performance engineers. But trouble is, you can’t see the stuff. Not at rest, let alone when it’s moving or being moved. Engineers being problem solvers, they’ve worked out a toolbox for themselves over the years. In design, a lot of the heavy lifting is done by Computational Fluid Dynamics computer models. For prototypes and component testing, they use the simulation environment of a wind tunnel. But there’s nothing like validating real world performance of the actual thing under unsimulated conditions. And for that, they use a decidedly low tech trick: they throw some paint on the car.
The so called “Flow-viz” is a mixture of paraffine wax and paint power, usually fluorescent or otherwise high contrast. On goes the brew, out goes the car, and when it comes back in the paraffine has evaporated off to leave a visual trail of the airflows on the daubed surfaces. This frozen motion allows the engineers confirm the results coming out of their models, or gives them indications of where to dig deeper.
When we talk about knowledge work, we’re of course referring to a vast range of fields and professional specialties. Without attempting a rigid definition, what they all share is some level of intellectual activity in an economic context. For this discussion we’re also assuming there is an aspect of repeatability to it, and that multiple people or teams need to work together on value creation. That is not to say that knowledge work can’t be a solo undertaking or the result completely unique every time. Both are certainly possible, but those cases are not terribly interesting for our current analytical purposes.
Knowledge work of that kind, with a bunch of teams collaborating on a workflow to produce units of value, poses the same problem faced by Formula 1 engineers. it is usually beneficial to have things move along as quickly as possible. But the things are slowed down by external forces, which are ill understood and invisible. F1 engineers address this by capturing an imprint of those forces as they act upon the car in motion.
What we want is something similar for knowledge work: flow-viz, tracing the units of value as they travel through their workflow, captured in the form a trace we can use to figure out where the resistance is.
So here’s where you begin to make knowledge work visible. For every “unit of work” the team has to process, record the start time when the team begins work on it, and record the end time when work is done.
For now, that’s it.
We’ll expand and elaborate on this, but want to begin with a simple metric that will already give us a lot of useful information. There’s no need to make it complicated, but there’s a couple of questions you might ask yourself.
> “Do I only count office hours, work days… do I need to differentiate between cases where the team puts in overtime?” It’s best to stay as close as possible to the real start and stop times. If one unit of work takes order of magnitude hours, record the number of hours and leave out downtime. If it’s days, leave out weekend time. But if it’s several weeks or months, don’t bother backing out weekend time. The important thing is that your average measured work time is representative and meaningful.
> “My team does many other things.” That’s true, with the other things including meetings, training, productive work on other value streams. But it is fine, as the time spent away from processing the “unit of work” will be incorporated in its total elapsed time. The idea is not (or not yet, anyway) to precisely measure only the time actively spent on the work unit, just the total elapsed time regardless of how much or how little of that time is actual “touch time” on the unit.
Once you have this, you can plot the units ordered (demand) and the units completed (delivery) on a plot like this. Plot the start and end times on the horizontal axis, and the count of successive work units on the vertical axis. Your plot will look something like this. (This is called a “Cumulative Flow Diagram” or CFD, not to be confused with the F1 engineers’ Computational Fluid Dynamics. 🙂
The CFD is your flow-viz. What can it tell us?
> It shows us the arrival rate of new work, and the departure rate of new work. In 10 time units, about 80 work items showed up for processing but only a little over 40 left. It seems that the running capacity of this process or team isn’t fast enough.
> The horizontal difference between the curves shows how long it takes to process a certain unit. This is essentially where our recording of start- and stop-time go. Not surprisingly this “residence time” for newer work units gets longer and longer.
> Likewise the vertical difference between the curves shows us how many work units require processing, or are being processed. This number too is growing as more and more remaining work piles up.
> While the increasing “residence time” and “units to be processed” numbers both tell us this process isn’t running well, it’s “units to be processed” that is a more useful indicator of trouble. Residence time only gets measured when a work unit is done: it is a lagging indicator, while units to be processed grows upon arrival of new work items before they are processed – making it a leading indicator.
Donald Reinertsen has a wonderful example in “Principles of product development flow” (a book I highly recommend). He gives the example of the Immigration waiting queue at an airport. There could be only 10 minutes waiting time before the arrival of a big new plan
Donald is s speed freak. His field is product development. The unit of value is information, and feedback is more powerful and less costly if it is generated as quickly as possible.
Imagine you had a CFD for every stage in a workflow… It would help spot where the longest processing times or biggest “To Do” queues are. But even just for your own team or process step it’s useful. There’s some other data-based learnings you can study a little. Are processing times relatively uniform, or all over the places? Is queue buildup seasonal, peaky at certain moments in the month or quarter. It won’t necessarily tell you exactly what the issues are – let alone how to resolve them – but it begins to give clues you don’t have if you have no data at all. And this is pretty lightweight to do. Some people simply start in Excel.
What and how to improve will depend on the nature of the knowledge work. Don Reinertsen’s work extensively discusses approaches to shorten processing times, because that is beneficial in his field. In product development a lot of the value produced is informational, and longer processing times drive up the waiting time for the all important feedback, the cost of obtaining that information, and the risk of moving in the wrong direction. In other lines of knowledge work, speed is not necessarily the most important performance driver to chase – but for Don, it is. No doubt he would have been a great F1 engineer!
”
Always understand what is the biggest limitation of the car that you have. That is what you have to fix first.
”
― Max Verstappen (four time F1 world champion, at minute 16:50 in this Youtube docu with Chris Harris)
Flow-Viz
Credits
Words
> Stefan Verstraeten
Ideas
> Lots of insight regarding Cumulative Flow Diagrams, the importance of queues, their relation to cycle times, and much more in Don Reinertsen “The principles of product development flow. Second generation lean product development.”
> There are a lot of benefits of making your team’s work visible to the broader organization, for which an illuminating case is made by Domenica DeGrandis in “Making work visible: Exposing time theft to optimize work and flow”
Photos
> Red Bull Formula 1 team
Video
> Chris Harris in docu / interview with Max Verstappen. https://www.youtube.com/watch?v=eY8pQMt8eB4&t=102s
