As I mentioned yesterday, the questions get tougher as the week progresses. The topic for Tuesday is the 'Workgroup Kaizen', or what is the role of a sub-group of the overall project team in the effort to kaizen the project.
It strikes me that, for a workgroup or for the whole team, one unique aspect of project optimization is the need for a clear understanding of the value of the cycle time of the project. In a repetitive manufacturing environment, kaizen efforts aimed at reducing cycle time are always welcome. In a project, however, shorter cycle time may be more problematic than helpful. Consider the project I mentioned yesterday - the gathering of culinary professionals in the kitchen on Thanksgiving Day (note that, thoroughly chastised, I will never again refer to the female members of my family who I dearly love as a 'gaggle'). For them to continually improve their process throughout the effort to the point that they have the feast ready for the table at 3:00, rather than the original planned completion time of 4:00 would not be particularly beneficial to Uncle Henry who will still be traveling over the river and through the woods at 3:00. In a similar vein, a building construction project is not always to the good if completed early. The occupant may not be able to leave his old digs until a set date. Often with projects, JIT is the rule, with no bonus points awarded for being early.
The point is that the kaizen effort should be undertaken with a clear understanding of what aspect of the deliverable is best optimized. Cost reduction and assuring quality are always valuable, but cycle time reduction may be very valuable - or it might not be. So framing the context of the improvement is very important in a project setting, and cannot be taken for granted.
Long ago, before Six Sigma was Shanghaied by people wearing belts of all colors, a central element of Motorola's quality strategy was 'defect mapping'. At the workgroup level, in particular, this strikes me as an enormously valuable kaizen focus.
In Motorola's manufacturing setting, defect mapping was essentially laying out the entire flow of production in chart form, then identifying every defect opportunity along the way. Every time material was touched by either a person or a machine represented an opportunity for a defect to occur, and every critical specification on every part introduced from outside the company represented a defect opportunity. The objective of the mapping exercise is to proactively look at the quality control in place for each defect opportunity. What is the quality control mechanism in place to assure that each opportunity is prevented from becoming an actual defect in the product? Any holes or weak points in the quality control system could then be addressed beforehand.
In a project setting, this exercise will be particularly effective. While the glaring holes in a repetitive process have already been found (usually the hard way), there is a huge risk that some gaps may have been left in the process constructed for the project. Each workgroup should defect map their piece of the project and evaluate how effectively Mr. Murphy (of 'whatever can go wrong will go wrong' fame) will be kept off the premises.
I can envision a construction project, for instance, that is dependent upon the building supply folks to deliver on Monday all of the parts the electricians will need on Tuesday. What is the team's assurance that the right parts were called for by the architect? What is their assurance that the right parts were ordered from the supplier? What is their assurance that the supplier has the correct date and place for delivery? Each of these represents something that could easily go wrong, driving up the cost of the project and throwing it behind schedule. The workgroup is the ideal crew to spot the defect opportunities in the plan, and preclude them from becoming realities. If the workgroup consists of the electricians who will contribute to the project, they have all of the skills necessary to review the drawings and parts ordered for correctness, and it will be easy enough for one of them to take on the task of calling the supplier in advance and confirming the order and all of its details.
Is this kaizen? You bet it is. The existing quality control mechanism is to rely on the people who planned the project to have made no mistakes. We all know that a quality system that relies on human perfection is the worst sort of quality system. Moving quality toward goodness through minimization of defect opportunities is the essence of what kaizen is all about. In fact, kaizen that fixes defects before they ever happen is a whole lot better than kaizen that improves quality after the fact.
Through defect mapping logic, the project team can, and really should, assure that they embark on a project that Eiji Toyoda would be proud of. He once said that if he were "in the sorry position of having to worry about quality, he would just shut down the whole company". Kicking off the project with a defect mapping kaizen at the workgroup level is the best way to be sure the project does not get to the 'sorry state' at which Eiji would just shut it all down.