One of the questions that comes up frequently in “lean” discussions is the issue of non-repetitive work. This is especially an issue with complex information processes such as bid proposals, estimates, etc.
While it is true that breaking down and understanding truly repetitive work is easier, the same principles apply to more complex tasks.
But first, I’d like to challenge some thinking. If you were to tell me that “every time we do this it is totally custom,” my question would be “If it has never been done before, why can’t everyone do it just as well as you?” What makes up your expertise? Why do your customers come to you?
I’ll answer: Because you know how to do it. Obvious, right? But that’s the point. You have experience, because you have done it before. You have a process of some kind. And you carry out that process to produce your customized product.
Further, you have some kind of idea of what a “defect free product” is. You understand what you want to accomplish.
Complex operations are built up from simple ones. The tasks that are done over and over are these simple operations. These simple operations are great sources of waste because (typically) no one ever examines them.
The idea that “lean” only works for repetitive processes is largely the fault of the “lean industry.” It focuses so much on takt time and removing waste that it has not, so far, gotten to the actual heart of what makes continuous improvement work.
In an ideal repetitive process running to takt time, there are a number of key ingredients.
- There is a highly specified work sequence that calls out the content, timing, sequence and intended outcome of the work. EVERY time that work sequence is carried out, the actual content, sequence, timing and outcome is being compared to what was specified. ANY departure from the specified work (or result) is going to trigger some kind of immediate response to correct the immediate issue, and then start the process of problem solving to find the reason this happened. This is jidoka.
- Although I mentioned timing above, the importance of time is elevated. Taiichi Ohno is quoted as saying “Time is the shadow of motion.” Ohno was a great student. The idea that it is important to study motion itself rather than focusing on time comes from the pioneer Frank Gilbreth. In application, by specifying how long each normal operation should take, and checking the actual timing, it is possible to detect when unplanned motions creep into the work. This is the purpose of takt time and work balance. It is no more, and no less, than a tool for verifying planned vs. actual so that action can be taken immediately if there is a difference.
- There is a specified amount of work-in-process. Each piece has a reason to be there. There is some means of detecting any departure from that standard, and any departure triggers an immediate response to understand why.
As you scale up from a work cell to an entire factory, these mechanisms scale as well, but the principle is always the same:
- Tightly specify what you expect to do, when it should be done, who should do it, where it should happen, and how it should happen.
- Tightly specify (understand) the intended “defect free” result of each step.
- Have a way to verify, continuously, that what you are actually doing (and when, who, where and how) matches what you planned.
- If When you DETECT any departure from what you specified, STOP pretending you are still running to plan; FIX or CORRECT whatever got you off plan and get back on plan; then work to understand and SOLVE THE PROBLEM. This is how the organization learns and acquires what Deming calls “profound knowledge” of itself and its processes.
In a complex one-off situation, you might never carry out that plan again. But plan carefully, applying everything you know… all of your expertise. Understand the elemental tasks that you do all of the time. Understand how long each should take. Understand what result you should get at each step.
As you carry out the plan, if when there are unforeseen real world issues, STOP long enough to understand their impact and start asking questions. First, what must we do to get this back on track?
If someone had to improvise, why? What knocked him off the plan or process?
If someone had to finish up work he got from upstream, why? Was the specification for a “defect free” transfer vague? Does it need clarification?
This can go on, but the bottom line is that most organizations with complex processes expect their people to accommodate and cope with noise in the system. They say “every time is different, we can’t possibly plan that well.”
The ones who are getting better every day say “We should be able to plan this perfectly. Why couldn’t we this time?” In simply asking that question, they get better each time they do it.
So – in the context of the original question. When putting together a complex bid and proposal, there are (I presume) steps you routinely go through. This is so even if you are not aware of what they are. Study those steps. Study the intermediate products. Understand where one step ends and the next begins. Understand what must be present (information, resources, etc.) for that step to execute successfully. If, at any point, those things are not there then STOP and understand WHY. Don’t just ask the people who SHOULD have those things to go find them.
You wouldn’t have an assembler on the shop floor hunt down missing parts. Don’t have a professional engineer hunt down information he should have received.
Check, at each intermediate step, that it was done as you expect.
At the end of the process, check that the bid is what you want it to be. If it needs rework (meaning someone didn’t approve it), understand why, and work on what information the process didn’t have the first time through. Next time, get it right.
The proposal itself is packaging. It is also your first cut at the plan for execution.
If you get the bid, and execute your plan, any departure from what you originally proposed should be understood. Why? What happened? What didn’t you see coming? Some things are truly different, and you are only estimating. But compare your actual vs. your estimate so that next time you can do a better job estimating.
There will always be imperfections. The question is in whether the organization chooses to bury them in waste or learn from them.