Is bowling a process?
Several correspondents questioned my assertion in last week’s column that if you throw a bowling ball exactly the same way every time on the same alley, you’ll knock down the same number of pins every time.
Experienced bowlers explained that the oil on a bowling lane changes over the course of an evening, changing the lane’s characteristics and the results of identically rolled bowling balls.
They are, of course, right. And being right they fell into my evil trap: A genuine false trichotomy.
I hope you’re impressed.
You can organize work three ways: As process, as practice, or through invention. They aren’t mutually exclusive. They are extremes that define a continuum of possibilities.
Pure processes abstract all knowledge and intelligence from those involved in their design and execution, moving it into the formal instructions of how to perform each step. Follow the instructions exactly and quality automatically happens.
Pure practices identify the basic steps, and achieve the rest through extensive knowledge, experience, and in many cases professional certifications on the part of practitioners, recognizing that there is no practical way to reduce the requirements for success to a set of defined instructions.
Pure invention imagines that a situation is so new and untried that the old solutions won’t work — the best outcomes will result from figuring things out from scratch.
Any real-world situation is best solved through a combination of the three. Some are more process-like than anything else, some are more practice-like. Pure invention is rare, but most processes and practices require some of it as an antidote to progressive obsolescence.
So bowling, while not a pure process, is more process-like than batting, which is more practice-like.
Where do IT “processes” and methodologies fit in? Hold that thought.
Professional process designers recognize a fact the amateurs ignore to their peril: Serious, industrial-strength processes don’t consist of a series of steps at all. They consist of a series of queues. The distinction is far from trivial. As evidence:
A very bright manager of my acquaintance developed a new way to manage development projects. He organized three teams — one for the user interface, one for back-end software engineering, and one to perform business analysis, overall design, and project management.
Project managers developed specs and farmed them out as requests to be fulfilled by the user interface and software engineering teams, which fulfilled the requests. The PMs also issued requests for support from external groups, such as the sysadmins, for such tasks as installing software on servers.
If this “process” was in fact a collection of steps it might have worked. Because it was a collection of queues instead, it failed miserably.
In traditional projects the PM defines tasks, dependencies and assignments. Everyone on the team knows when their tasks should start and finish. If all tasks start and finish on schedule, the project completes when expected.
In the queue version, project managers pushed tasks into a set of FIFO queues. They had no influence over task schedules. Tasks started when they reached the front of the queue. Tasks that depended on those tasks couldn’t start until they reached the front of their own queue and their predecessor tasks were complete.
No matter how hard everyone worked, the organization as a whole was paralyzed.
Serious processes are organized into queues for important reasons. First, each queue acts as a buffer. It accepts inputs even if everyone assigned to the step is fully occupied with other work. Conversely, queues ensure expensive employees and equipment stay busy instead of running out of work to do.
Queues help serious processes do what processes do best, which is to maximize throughput. They do so at the expense of cycle time — instead of it being the sum of the length of the steps, cycle time is the sum of the length of the steps, plus the sum of the delays caused by work waiting in queues.
It’s a design trade-off: Eliminate queues and cycle time improves, but capital and labor utilization nose-dive. Make queues too long and cycle times extend. If the process incorporates feedback loops, cycle time delays can be disastrous — among the equations describing mathematical chaos are those that describe delayed feedback (see “The mathematics of project chaos,” Keep the Joint Running, 5/6/2002).
Sound complicated? That’s because serious process design is complicated. Which is one reason designing IT methodologies as queue-less (as opposed to “clue-less”) practices, and not as queue-driven processes almost always leads to better results.
It’s also why, when selecting a process consultant to help your organization through a process improvement or re-engineering effort, you should include these four words in your evaluation criteria:
“Show me your engineer.”
Bob:
Haven’t written for a while as you nave not struck a nerve recently. But have an anecdote. First of all, you have to be in complete charge of a significant element of the system.
When I interviewed for the top engineering job at a midwest transit agency, I told the GM that I seldom made decisions. I just did what worked the last time. He bought that, as I had had similar jobs at much larger agencies, and had been demonstrably successful. Several years later, when he was less than successful in achieving his own goals, he threw that back in my face, saying, “How do you know it’s the same.
But that’s the trick. You have to be smart enough to recognize when it’s not the same. And never let your ego get in the way! Kind of like the bowling analogy.
Don’t really like your take on queues. They take more management than I believe you allude to. I don’t believe that they should be managed as “hands off” as you seem to feel. Would like to hear a lot more about that particular tactic.
Keep the good stuff coming.
Charley
Bob — this is fabulous. We are getting ready to leap into the process pond…your article will help me monitor and correct for the ripples by keeping me aware of the practice and invention pieces. We don’t want to re-invent the wheel, but if we really need a cog instead of a wheel we must not be blind to that.
Man, can I mix a metaphor or what!
Interesting column that starts a discussion but stops when it starts to get interestng. Why do you think an engineer is the solution?
Wow. I’ve never seen such a good explanation of this morass.. Good Job, Bob!
j.
Bob:
This column greatly clarified what you are calling a process, both in your columns and in your book. I teach a course in process management so a process has a much different definition in my mind. I completely agree that queues cause problems but as you note, the trade-off is idle time. In my course I cover the fundamental law of processes:
Inventory (Queues) = Throughput X Cycle Time
This is really just Little’s law in queuing theory but it has very practical implications for managing processes. There are fundamental trade-offs involved and if you want to speed up work (reduce cycle time) while maintaining throughput you must reduce inventory (queues). This column will help my understanding of your book a great deal.
Will Terpening, PhD
School of Business Administration
AD Box 9
Gonzaga University
Spokane, WA 99258
(509) 323-3423
[email protected]
Given that SCRUM is a popular methodology in software development, and that it works primarily off of a backlog queue, are you saying that SCRUM is “clueless” and should not be used?
Hi Bob,
I feel like you didn’t fully explore the idea of queuing fully in this article — would love to see you talk more about it later!
First of all, why must a queue be FIFO? Surely the goal of a good queue is to allow timely scheduling, with things like prioritization and interrupts baked in to the queuing process?
Secondly, isn’t it almost impossible to eliminate queues in most IT processes? Help Desks have to have queues, so do change request approvals (although I suppose you could argue these are batch-processed rather than queued) and the implementation of the changes themselves. Can you explain how a typical IT shop could become “queue-less”?
Goldratt’s theory of constraints, aka buffer management. One of the many schools of thought for PMs.
Perhaps one of the best examples showing what a disaster “queues” can be is sitting on many people desks. You may even have an example on your desk. It’s call the “Pentium 4” processor.
Sure, it is physically fast. But throughput, ah … that is a different matter. It took competition from AMD to show Intel how it was done before the P4 was buried.
The P4 is still a hot chip consuming extra electricity and it will continue to do so for the foreseeable near future. This is on top of the people and money resources wasted by Intel forcing the P4 to work at all.
Queues have their place. The trick is to correctly balance how much queue you need.
I believe Bob’s point is that there should be a balance between Practice, Process and Invention. Excessive queues destroy that balance. Excessive emphasis in any area destroys balance.
So the point becomes ‘Slavish attention to one facet at the expense of other facets is doomed to failure’.
In reply to Stephen – the problem in some businesses is the cost of reordering the queue. The problem we have in our business – once someone discovered interrupts due to priority – is that so much has become a priority that the queue is constantly in churn over which priority is higher and since more things are priority than the process can deal with, the queue is mostly back to a FIFO anyway. If everything is a priority, then nothing is a priority – you’ve just raised the stress level of the managers and workers dealing with the queue with no difference in outcome.
As I understood the story about the breakdown, the queues were not FIFO or prioritized, but “you pick” – so folks doing the coding were happy since they could pick the stuff they thought was easy and leave the hard stuff to some other poor shmoe – which might work – if you had folks with skills in different languages and any language could be used.
Even prioritized queues could be problematic – depending on the skill of the person doing the ordering – building reports before the database is put together is an obvious example, but much more subtle ones exist in the software world.
Bob,
I agree with the point you’re making about IT practices, but this statement deserves a response: “Eliminate queues and cycle time improves, but capital and labor utilization nose-dive.”
That’s true only if the *only* change you make is to eliminate queues. If you also redesign the process’ work balance, capital utilization at least remains constant (with the exception of when you were over-producing to begin with) and labor utilization (measured in productivity units) dramatically increases.
Seen it done. Did it myself.
But I heartily agree that you have to be working on a true process, not a practice.
Pingback: Twitted by bartb1067