Full-Kitting and customer involvement

Finished reading chapter 18 about Full-Kitting (FK).

My assessment of FK has matured throughout reading the book and have come to the conclusion that it is perhaps the single most important activity in determining the success of a project… and therein lies my dilemma…

Let me add some context:

  • We are talking about FK for a MOVE
  • FK done right will allow a MOVE to flow smoothly. If it isn’t done right or not done at all, it has the potential to raise many false positives when it comes to identifying the constraint. This is crucial on so many different levels. Not knowing precisely where the constraint is located and chasing down multiple false positives is the fastest recipe to descend into chaos. The importance of a good FK could not be stressed enough (IMHO).

What I would like to explore:

  • The role and activity of a customer in FK when working on a MOVE within the context of a custom (bespoke), completely green field, software development project.

Taking into account the various techniques for getting good requirements from customers (event storming, user stories etc…), I feel FK is a lot more than that, and probably requires a lot more customer involvement. (If you agree, how would you do this effectively? If you don’t agree, I would be interested to know why.)

My gut feel, is that if FK is done properly throughout the course of a project it should take up a third, perhaps even half the time to complete the whole project (! yes… just a gut feel).

Without good FKs, I can easily see a project taking twice as long to complete, and if the concept of a “MOVE” is not properly understood, I would dare say, the project could (will!) take 5 to 10 times longer…

But my dilemma is …

  1. Explaining to a customer the importance of FK :thinking:
  2. That a large chunk of the project costs will be due to FK
  3. That they will need to be actively involved :slight_smile:

Especially if they are stuck in a “Cost Accounting” world :wink: (Maybe we don’t even discuss point 2 :stuck_out_tongue: )


1 Like

Just adding my two (misguided) cents here.

The way I interpreted this from the book was that a MOVE is not necessarily a deliverable. Especially in the early stages of a project when there is high uncertainty.
A MOVE could well be requirements gathering activities (such as doing an Impact Map, coming up with hypotheses, prototyping and doing user tests). As part of Full-Kitting we would then make sure that we have the necessary tools and resources to complete those activities.

As the solution begins to emerge, we can break it down in further MOVEs always ensuring that we have some sort of goal (be it actually deliver something, or learn about something).

In short, I see Full-Kitting as an activity we do to ensure that we have put in place whatever is needed in order to complete the different product development activities so that a smooth flow can be facilitated.


Yes it may not be a deliverable but (my understanding is) it should always be an outcome that delivers value to the customer. The best outcome is not delivering a deliverable :slight_smile: (The best code is no code at all.). That does blur the lines between software development and consulting, but I would rather they find a good solution that does not require any development, than waste both our time working on something that is not really necessary.

In some ways that is exactly what I am trying to get at. Doing things properly at the start of a project could dramatically make it shorter, precisely because it will require a lot less deliverables.

My interpretation is very similar to yours. I look forward to reading any corrections if we are misguided.


Upon reading the first draft of the book, a few reviewers said : ‘This section is the book’ …

This is where Planning and Execution collide …

Pretty cool stuff.

1 Like


Looking forward to hearing from other people who can provide more opinions on this.

1 Like

For us the MOVEs that make sense are less likely to be a chunk of work that delivers value to the customer, and more likely to be a coherent chunk of work that can be done in a by a team in a limited period of time without stopping. For us we have lots of stops and starts while there is interaction with stakeholders (not always the client), and I feel that a MOVE cannot easily span such steps. Just thinking out loud here since I’m new to this way of thinking.

On the customer involvement question I can definitely imagine where that would help with full kitting if it is necessary to define the value to be delivered - the ‘client side full kitting’ described in the book… But if this is extensive work (you said up to 1/3 or even a half of the work) wouldn’t it be better to structure a MOVE whose purpose is to answer the customer value questions, and then use the result of that for the full kitting of the next MOVE. As I understand it full kitting as described in the book is more a tool to facilitate flow, and uncovering client value needs flow just as much as the development work.


I like that framing, and it is quite correct.



No! It will not raise false positives about the Constraint. The Constraint is what it is. If you do a bad FK, then you will just add more work than necessary to the WIP that needs to go through the Constraint, but it does not change the Constraint.

However, if that bad Full Kitting changes the Work Load, then it could potentially move the location of the Constraint in the Work Flow. That’s not a “false positive” - it is a reflection of the way you are working. So, maybe, by focusing on why the Constraint is where it is, you might figure out that you can exploit-subordinate-elevate by means of a more functional Full Kitting.

Agree, but it is unrelated to doing / not doing / doing badly the Full Kitting activity. The Constraint is the Constraint; and it is so because of the decisions you have made. Saying that the Constraint is not where it appears to be because you are making the wrong decisions, is missing the point by quite a mile!

As @dhdez already pointed out: if you have to do a lot of exploratory work together with the engineering team, then that exploratory work is a MOVE in its own right. The outcome is to discover / create new information / knowledge. If the activity takes requires real Touch Time by the engineering team, then it should be covered by a MOVE.

Yes, that’s part of the educational process that needs to happen.

Now you make me fume! :angry:

In the TameFlow Approach WE DO NOT CARE ABOUT COSTS. Any decision must be an economic decision, with a DOLLAR sign attached to it. But that is a DOLLAR sign of Financial Throughput - never of Cost!

Phew! Glad you recovered there! :roll_eyes:

And yes, they have to be involved. Remember the metaphor of the Patient in the Hospital. The entire organization (including stakeholders / customers) need to get the patient out of the hospital, ASAP, and in the best conditions!


I have been corrected by Steve many times about the focus on reducing costs … Reducing the amount of effort required is more palatable …

1 Like

Yes. The whole purpose of this post is really to get into the specifics of how this can be done.

I have been involved in too many projects where the customer want something done, is happy to pay for it but in reality the value to them is negligible because they are focusing on symptoms and not on the root cause.

A lot of people truly believe software has super powers. In their minds a new software solution will magically solve all their problems and remove all their headaches.

Do you have some page references in particular? (I may have missed them, or haven’t got to that stage yet).

Can we have a MOVE without doing FK first?

From page 284:

Given how we have been building our Mental Model on how to operate in a PEST environment, the
scope of action of the Full-Kitting activity covers a single MOVE at a time. One might wonder, what
essential elements must be part of a Full-Kit before actually committing to a MOVE? … Well, we
must clearly establish what must be known about any MOVE before it can be accepted in the Committed column of the Portfolio Kanban Board.

The way I interpreted this passage is that FK always precedes a MOVE.

When I wrote my initial post I was associating FK with “requirement gathering” and “scoping”, at the early stages of a project. ( I understand FK is a lot more than that, and what is involved in FK will change as the project progresses. The emphasis is really in doing whatever is necessary to ensure the MOVE never has to stop once it enters the flow.)

Customers typically come to us with a lot of requirements (we even have a name for it… the “laundry list” of requirements. :wink: )

There are two ways we potentially could deal with this:

  1. Accept all their requirements on face value, give them a price and get to work.
  2. Question the need for their requirements and cut the list to what is really required.

We already do point 2. In fact we love trimming these lists to the bare minimum.

However, the more I read about ToC as well as TameFlow and Throughput Accounting the more I realise we can do even better.

  1. Is the project the customer wants to work on addressing their constraint? If not they are wasting their time and money (with some caveats)

I started this post because I was curious to find out how others approach this, and how they deal with FK on the client side.

In my mind a MOVE is all about delivering value to the customer.

If we spend a couple days doing some scoping with them and realise that:

  1. They are not focusing on their constraint
  2. They are focusing on the constraint but there are faster, better and simpler ways for them to achieve the same outcome or more, without the need to develop any new software and therefore don’t require our services

Then the sum total of the time we spent on the project will be 100% requirement gathering with 0% development. (i.e. we effectively reduced the time of delivering a project from several months if not years, to just a few days, by simply finding a better solution for them which they hadn’t realised.)

This is an extreme scenario but is the principle behind how I came up with 1/3 or 1/2 of the project time.

Invariably, the deeper we dig the more we find out a customer does not really need as much as what they first thought. If we didn’t dig then we would end up with much longer projects.

Fully agree. It is all about flow, but the best flow is achieved by only working on things that really matter. (Figuring out what really matters is hard without ToC, but incredibly easy with it. The problem is, customers that don’t understand ToC will have a hard time getting their heads around this. And we haven’t even addressed TA yet…)

(I really want to say “The best flow is no flow” :wink: but feel that will get misconstrued.)

1 Like

In Throughput Accounting we have only three variables to consider. And effort is entirely captured by Operation Expenses.

And, Yes!, I confirm: It does indeed take a lot of… effort… to retrain a CPA [@DanielDoiron] to drop the Cost Accounting mindset!


1 Like

Correct. And you can find yourself in the situation that when doing the Full Kitting of MOVE-X, you uncover the need to do some “real work” in order to be able to perform the Full Kitting.

You put that “real work” into a new move, MOVE-Y.

And you establish a precedence dependency: MOVE-X is dependent on MOVE-Y.

All of this is handled very much as it has been taught in the Incremental Funding Method.

That is a limiting view of a MOVE. In general, Yes!, you are correct. But it is not only about requirements and scoping. It is more about: do we know everything we can / need to be able to start operating on this patient without interrupting the operation in due course. And in particular: “Are we in a position to make a good, informed and economic decision about this MOVE before we feed it to the lions?”

Excellent! You’re groking it!


Remember: every decision must have a DOLLAR sign attached to it. If you want to help the customers / clients to make the right decision, help them to see the decision with a DOLLAR sign attached to it for them as well.

1 Like

Steve, you are too quick. I went back and edited my post to clarify my thoughts. When I finished I noticed your replies! I think we are in agreement here. (Please see my edit. Actually I will add it below:)

Yes. This is a big takeaway from your book.

But I think there is some confusion over whether making an informed decision is a MOVE or is part of FK. In other words, is making informed decisions “real work”? (It is not as clear cut as I would like and I can see this going both ways depending on the situation.)

Yes this is probably the answer I was seeking all along. Be really explicit about the value for them.
Not only does it build trust it also achieves a win-win. (And if they don’t get it, we probably shouldn’t do a project together in the first place.)

Well… I’m all about Hyper-Performance!

Remember the definition of a MOVE: the “O” stands for Outcome.

When you are in a position of not being able to make a decision without performing some kind of “real work” (Popcorn Flow sessions to explore the solution space, an eXtreme Programming Spike, running interviews with customers, etc., etc.), then that becomes a MOVE that produces an Outcome.

The Outcome is always detected by metrics or observation, and in particular observation of changed behavior. What behavior in this case? That the folks were not able to make a decision about a MOVE without performing some other “real work” - i.e. the “extra” MOVE the Outcome of which enables the decision making. Now they can make that decision.

Take this rule of thumb: a Full Kitting meeting should be (relatively) short and focused. If you find yourself not being able to proceed because “we don’t know” – then you need to perform some “real work” that uncovers the unknown, or creates the knowledge that is missing. That’s a MOVE in its own right, and it must be treated as a precedent. And as any MOVE, it goes through the prioritization, ranking and in flow stages of the Portfolio Board.

It will incur in real Operational Expense, and the Financial Throughput of all the “other” MOVEs which we decide to postpone because of this exploratory MOVE, is likewise postponed by the same amount of time.

So draw the DOLLAR-TIME diagrams and see if the “Cost of Delay” (actually postponed Financial Throughput recognition) is worth the Outcome that you are seeking. If it is not worth it, don’t do it. It is a business judgement call.

Always go back to the fundamental: every decision must be made with a DOLLAR sign attached to it. And never accept to do any work that is invisible. If it is not on the Portfolio board, it is forbidden to touch it. Everything must be visible and transparent. Otherwise the very rationale of making economic decisions falls a part. The “Dark Matter” will eat your profits without you knowing what it was.


Your response puzzled me. So I went back and re-read what I wrote. I can see how these statements can be confusing. I should have provided better context and spelled out some assumptions. I will try and clarify them now.

I agree the constraint is what it is.

It does not mean we have no control over where and what we would like it to be.

When I wrote:

I made a context switch. I moved away from the context of TameFlow to a context where organisations are happy to take on any work that crosses their path without any consideration of whether it is a good fit with their skill set.

What I was trying to convey is that for such organisations the concept of a constraint is not even understood. It simply manifests itself as constantly “putting out fires” or playing “whack-a-mole” with bottlenecks. They don’t know any better.

They don’t realise these negative effects are aggravated by the lack of proper due diligence during the scoping phase (before the project even starts). Not to mention the fact that the use of any feedback mechanisms or leading indicators, while the project is being done, are completely missing. They only respond (or react) to customer complaints about late delivery dates or poor quality of work.

It is not only about the work load but about the work type, and being sure the project team has the necessary skills to do the work.

I have seen too many ERP implementations fail because of this. (ERP teams that think they have the right skills…)

If a company takes on work they are not skilled at they will have no idea where the constraint is going to be. (I know it seems crazy that people would put themselves in such a situation, but they do, all the time, because they need the work.)

There may be an assumption that, this is precisely the environment “knoweldge work” companies operate within, and that is the reason TameFlow exists. OK. I agree it is really good at identifying the constraint. I am only suggesting more could be done.

TameFlow requires some engineering to ensure the “arrival” and “delivery” rates are the same in order for Little’s law to apply. It strikes me as a system and methodology that has been extremely well thought through and refined through fire. It is well “engineered”…why not take it a step further and be more deliberate about the type of work it accepts to work on?

Knowing what delivers the most value to our customers and making it the constraint can be extremely beneficial. (See https://www.intelligentmanagement.ws/constraints-bottlenecks-need-know-the-difference/. It is foundational to what I am discussing in this post.)

Some may argue that if the constraint is known ahead of time then TameFlow is unnecessary. That would be missing the point. The correct argument is that despite our best efforts to keep the constraint in one location, when dealing with knowledge work environments, it will invariably move. We need to be prepared and TameFlow offers the best framework to handle these situations.

I think I have gone full circle. I hope this clarifies my original statements.

Your answers have provided me with the necessary clarity to bring this all together.

As I understand it FK can be divided into 2 aspects:

  1. Determining the value of a MOVE and whether it makes sense to proceed with it. (Both to the customer and to ourselves, without requiring any “real work” to be carried out.)
  2. (If it does makes sense to proceed with it.) Doing everything necessary to ensure the MOVE will never have to stop once it enters the flow.

Determining the value of a MOVE for the customer in collaboration with them (and ensuring it makes sense for them AND us) resolved all my dilemmas. (Including the ones I didn’t write about :wink: )


Not sure I follow you here.

Types of work are already handled. They are all captured in the flow time distributions. If you “tag” the incoming work according to their type, then you can “slice and dice” the flow time data and have type-specific flow time distributions. This is not described in the book [OK! So you couldn’t have known… :slight_smile: ], but it is a common “advanced” practice. It allows you to become more refined during the Full Kitting activity, and tune the forecasts and the Througput Rates according to the type of work.


Yes, I guess we have gone full circle!


I am referring to being more deliberate about the type of projects a company accepts to work on.

My assumption is, these projects are external and need to be completed for a third party (as opposed to internal projects.)

When assessing a project we can be a lot more careful that it is a good fit for our particular skill set, and that we have the required resources to complete the work.

Different projects, by their nature, may place varying amounts of work on different departments (or teams) within an organisation.

We should ensure the work profile of a project adequately engages our constraint.

(I am also keeping in mind “The extra step 6” paragraph you wrote on page 22).

If we strategically accept to work on a project that properly engages our constraint, and the constraint is what provides the most perceived value to the customer, we are exercising our expertise, and providing great value to the customer as well as healthy profits for ourselves.

If a company does not understand ToC, and willingly accept any projects that comes their way. The shape and form of these projects and the work load they place on the various departments (or teams) will be vastly different from project to project.

Let’s assume the company understood a little bit of ToC and started working on a project that required a particular type of work. As the project concludes they may rightly come to the conclusion that the constraint was “team A”. Now that the project is complete they start working on a new project that requires a completely different skill set and has a completely different shape and form to the first project. They may be shocked to find out, as the project concludes that the constraint was “team Z”. (Not to mention the fact that they hired extra staff at the start of the project to increase the capacity of “team A” in anticipation, when in actual fact, “team A” were hardly needed at all.)

I understand this is exaggerated but being deliberate about which projects we accept to work on (and rejecting those that don’t “fit”), is important if we want to try and keep the constraint in one location.

Talking about exaggeration… how do companies that use typical Kanban boards ever figure out what their constraint really is?

Being able to be “pick and choose” projects depending on how they engage our constraint is valuable, especially if customers want to do business with us because of the expertise we have at our constraint.

Making sure a project not only activates our constraint but also improves their constraint in delivering value to their customer (and therefore makes it valuable to them) is important.

This is where it all gets really interesting…

If you can get multiple companies working together, each of which are exercising their constraint and providing great value to their respective customer you achieve a state of flow across multiple boundaries. If the last company is providing a product to a large enough market you can achieve harmony. i.e. the throughput rate (or natural frequency) at each company are tuned to each other by their respective constraints, which will produce a harmonic response … the result of which will be greatly enjoyed by all involved. (It is all about the compounding “flow of value” across the whole supply chain.)

This requires some serious “engineering” :slight_smile:


Not really… the “shape and form” does not refer to what is inside a single project. It refers to the the collection of projects that have not started yet. It is the Jungle, in the 3J metaphor. It is in front of your Jeep, but you are not in it yet.

And even if a single project will have Team Z as the “new” Constraint, in the big picture it does not change the shape and form of the Jungle.

If it is the Jungle that is changing into a Tundra, then when Team Z is starting to experience the first difficulties of the new terrain, you will first get signals from the Work Execution. And that will be your early warning, your weak signal that you might be alert to figure out why Team Z is slowing down. You are at the beginning of the Tundra, and receiving signals about it. You need to decide if that is just a short distance to go through, or if it stretches ahead for the entire journey.

So only after going through enough “Red Zones” you might conclude that Team Z should be considered as the Herbie in deciding what route to take through the new terrain - because it is now confirmed it is a Tundra.

So it is not at all so “surprising” as you are describing it.

Always remember to look at the whole effect of all tools we have in TameFlow. Otherwise your analysis will be distorted by some local phenomena.

Correct, and we call that kind of decision making process the Demand Shaping.

No! You don’t pick projects based on the desire to keep Herbie nailed down in a location. The only criteria is an economic criteria, with a $$$ sign.

There are, however, other strategies you can employ to keep the system as stable as possible, but they have more to do with how you do the 5FS; not with demand shaping.

If you customer is at the other side of the Tundra, there is no point heading out for a Jungle…

Yes, keeping in mind the customer’s constraint is an excellent thing to always consider. But then: do you know what is the customer’s Constraint? First focus on figuring out what your Constraint is; only then can you be more magnanimous.

And yes, then taking that to the extreme, you wold consider the entire value chain (or value network) of which you are part, and reason in terms of overall Constraint. But remember: unless there is a shared common goal for all parties, it will not work out so easily.



There is something to be said about negative covariance. You are right that if you hit projects that are ‘design’ intensive, you can add to the overall variance (risk) of the undertaking.

Spreading projects that would cover equally ‘design’,‘architecture’,‘testing’ and various other processes would indeed reduce overall variance.

It is the only case where ‘variances’ actually cancel one another.

Donald Reinertsen discussed the topic at length in his book on Second Generation Lean Product development.

Coming into contact with ToC brings an entire new perspective.