Work Flow vs Work Process

Okay, I admit it, I am dense as a uranium fuel rod in a nuclear reactor.

Steve has mentioned several times in the campfire series these two topics, 1) Work flow and 2) Work Process. I have gone back through the Hyper book and the latest Tameflow book and just can’t seem to find a definition of the two. There clearly is a difference in the way it is referenced, but I want to understand the subtle and true differences. I think my fundamental problem is all this “mental model” stuff. I think I need some improvement in the “mental” part before I can combine the two.

My current understanding as it relates to the Kanban board is that the Work Flow is the board itself; the steps through which our work items must progress until delivered to our customer as complete. So what then is the “work process”? My inquiring mind wants to know.

1 Like


Good catch. If you were to search for ‘constraint in the work flow’ or ‘constraint in the work process’ you would find some good piece of information…

Chapter 9 is where the action basically starts!

Thank you.

Nope. Think of it this way:

  • Work Flow: All the queues - especially virtual queues - that are in front of the [Kanban boards of] teams.

  • Work Process: The sequence of stages/steps that you depict on one Kanban board of a single team.

The Work Flow is like the Jungle that you intend to travel through. The Work Process is your Jeep, with all components working together to move it forward towards the Jungle. When the Jeep actually eats off miles going through Jungle, it is on it’s Journey: this is what I call the Work Execution. You can have a Constraint in all three locations.

Hope this helps

That helps.

It seems that the “project” I am managing then falls into the Work Flow definition. The project contains many deliverables, each of which has to be distributed out to various teams (services) within my organization to complete the project. One of those teams will be my constraint at the project level.

Expanding upon that thought, each project in our portfolio could require one particular team within each project. Most likely (but not necessarily) that team could be the constraint for the portfolio and the project on which they have the most work would be the constraint project for the entire portfolio. I realize this is just one example of a portfolio constraint. It would also be possible that some other team that is only used on one project could actually be the real constraint of the whole portfolio, but for my simple mind the shared team across project helps me form a mental model of what might be going on.

Assuming that is correct, I have to admit I don’t have a clue as to what would be the Work Execution constraint. If you could elaborate it would be helpful.

1 Like


Not really. That really breaks the idea that you first find the team that is the Constraint in the Work Flow, and then focus on the step/stage/phase/column of that team that is the Constraint in the Work Process (of that team).

The portfolio has one constraint, the Constraint in the Work Flow. It might change, yes, but due primarily to the Work Load. You need to look at the Virtual Queues that build up in front of the teams. In a simplified mode, you can count the Work Items and pick the one with the longest queue. A more refined way is to use probabilistic forecasting - for each team - and see which team would need the most time to process its virtual queue.

(Note: these queues are “virtual” because their items have not been released into the work flow yet; they have not been “committed” to.)

Great question, which often leads to the “Aha!” moment of learning about the TameFlow Approach.

Let’s use the 3J metaphor.

So you have these squadrons of Jeeps (Teams) that need to reach the base camp at the other side of the Jungle (the end of the Portfolio Backlog). They will take different paths or Journeys (the different Virtual Queues or backlogs in front of each Team) through the Jungle (Work Flow).

One of these Jeeps will face the most challenging Journey: it has to climb a very steep mountain. We can foresee that it will be the one that will need the most time (Constraint in the Work Flow), so we will make sure to focus on keep it going at the best of its capacity, keeping it moving at its maximum sustainable pace (by focusing on the Constraint in the Work Process). All other Jeeps can take it easier, because they are faster and have plenty of capacity to catch up.

Now in this swarm of Jeeps that are traversing the Jungle - and they all have to bring their cargo (Deliverable) to the same base camp before sunset (Deadline) - just as there is a Jeep that we can foretell will be the slowest one – under “common” / normal conditions – all other Jeeps will move faster than that one and get to base camp before the Herbie Jeep. Again, note well: under “common” / normal conditions (Common Cause Variation)

As we know, when we traverse a Jungle, well, “things happen.” So we might have the fastest Jeep on the least challenging Journey of all that will encounter Mr. Murphy. And that fast and favored Jeep will have to stop. The stoppage could be so sever that – under these “special” conditions (Special Cause Variation) - that it might end up becoming the last Jeep heading toward the base camp.

This unlucky Jeep is Constraint in the Work Execution. This Constraint came about not because of what we can foresee (the Work Load / Work Flow) or what we know (the Work Process) but because of the “stuff that happens” factor, courtesy by Mr. Murphy. Since this stuff happens during the Execution of the work/plan/portfolio, we call that Jeep - which is experiencing the bad luck - the Constraint in the Work Execution.

And if there are multiple Jeeps all encountering Mr. Murphy on their way, then the one that is delayed most will be considered as the Constraint in the Work Execution. The other ones can recover at their convenience… they are still ahead of Herbie notwithstanding their meeting Mr. Murphy.

We need to have prompt signals - during Work Execution - that some Jeep is encountering this stuff. That’s why we have Buffer Management and in particular the Bubble Fever Chart. For an animated example of this see at the end of the Visual Portfolio Management blog post. Do you literally see how the Herbie team is represented by that purple bubble? Give this kind of chart to the steering committees and portfolio managers and they will be very, very grateful. But, of course, in order to get there you need to implement all the things described in the book; and for a deeper explanation see Chapter 20 - Operational Governance in PEST Environments of Tame your Work Flow.

Hope that makes it clear!


This is one area I have found slightly confusing as well.

I liked the analogies when first introduced to them at the bottom of page 4, top of page 5.

The concepts of work process, work flow and work execution come up regularly enough that I had to write them down on piece of paper and keep it with me when reading the book, because it is not immediately obvious to me which one is the jeep, jungle or journey.

(For completeness the definitions are found on page 145, 147)

I will try and write it down as I understand it. (Steve please correct me if I am wrong.)

What I liked when I was first introduced to this metaphor is the expansion of possibilities for what may be causing a constraint.

Too often we think of a constraint as a physical limiting factor without proper consideration to the surroundings (or context) it operates within.

The metaphor makes it obvious that the jungle and the journey need to be accounted for as well.

What helps me keep things straight in my mind (and I may be completely wrong), is that the constraint will always manifest itself by noticing that one jeep (within a fleet) is progressing slower than all the others, but the crucial part is that the cause for it progressing slowly can be due to 3 different (distinct) reasons:

  1. The jeep itself has a limiting factor such as the size of the motor, the type of tires it has fitted, or the load (weight) it has to carry.
  2. The track or path it was asked to follow is slow to drive on. Some tracks may have a lot of overgrowth, others might be on rocks or pebbles others on sand or clay. Not to mention hills, valleys, rivers that may need to be crossed etc… (But all these facts are known ahead of time).
  3. Unforeseen events might occur that may slow the jeep down as it is taking the journey to its destination. Such as rain on that part of the clay track, a puncture or a tree falling over the track.

When looking at it from this point of view it also becomes clear that there may be other constraints around managements ability to plan correctly and match the right truck to the right track (or path). Such as, matching the heavy truck with thin tires to the “sandy path” … even if it has the most powerful motor… things won’t go well.

Or matching the truck with a spare tire on the cleanest path, and the truck without a spare tire on the path that goes through an old mine site that has many sharp objects that could puncture a tire (Simply because they never thought about it. i.e. failure by omission).

Another constraint could be not being able to read the map properly, such as noticing a river is running all along one of the most difficult soft soil tracks that is easy to get bogged down in. Instead of taking the track, they could put the truck on a barge and get it to the destination in 1/3 of the time. They just had to notice the river and inquire about the many barge operators in the region.

What makes more sense to me is to think of:

  • Work process: as the entity that is actually processing the work
  • Work Flow: as work load and the type of work that needs to be processed
  • Work Execution: as the potential for special cause variation to occur.
  • Jungle: as the track or path that is assigned to a jeep (and runs through the jungle)
  • Journey: The actual expedition. (My mind seems to associate the word “journey” with “track”, which confuses me.)

Could there be a fourth constraint around strategic planning and allocating the right jobs to the right teams (which may not be entirely obvious at first)?



Just as a twist, I like to mention that the Work Process and Work Flow constraints have a location, a place. (where)

The Work Execution constraint is something that happens with the passage of time. (when)


1 Like


I can see that we can pin point a constraint in Work Process by location and a constraint in Work Execution by time. However it would seem the constraint in Work Flow needs both location and time (the location will depend on the “work process” that is processing it and the time will be based on the composition and characteristics of the work flow itself. ?)

1 Like


Note: the Constraint is always ONE with respect to your system. That is: your Span of Control.

Here we are not listing Constraints as such. We are listing locations where the Constraint may appear, and suggesting ways to identify and handle it once we know it is there.

So there might be a fourth location for a Constraint. But the Constraint is always ONE.

The locations that TOC identifies are:

  1. Policy
  2. Supply (upstream)
  3. Physical (internal)
  4. Market (downstream)

So what I did with the Constraint in the Work Flow, Process and Execution, is just a refinement of that thinking. Trying to categorize where the Constraint might turn up.

But again, the key concept: the Constraint is only ONE!

1 Like