Workshop Presentation Overview:

Kaizen, Nemawashi and a Project Management Work Cell

As Project Managers we are well trained in conducting and implementing traditional “Lessons Learned” as part of the project life cycle. However, for longer projects typically lasting over 6 months, the potential lag in the discovery and incorporation of improvements to the ongoing project management may miss important opportunities to achieve the project goals at lesser costs in time and energy. This workshop applies a few pages from the Lean Manufacturing and Toyota Production System playbooks to explore opportunities to contemporaneously improve what happens in a “Project Management Work Cell”.

© Jeffrey S. Marsh, December 9, 2009

1

This copy of the workshop presentation has been provided as a PDF of the original PowerPoint “Notes Pages”. This was done in order to make it convenient to view the written transcript of the spoken part of the presentation.

This presentation prepared by Jeff Marsh, PMP. It was originally presented to the PMI Mile Hi Chapter in Denver, CO on December 9, 2009 as a workshop preceding the regular monthly chapter meeting.

Questions asked by audience members - - and some answers - - have been appended to the end of the set of presentation slides.

Thank you for your time and interest in this presentation.

2

Welcome.

The title of this workshop presentation is “Kaizen, Nemawashi and a Project Management Work Cell”. To which your first observation may be ‘Wait a minute, I don’t know Japanese.’ Not to worry - - we are going to talking about some exposure to Lean Manufacturing and the Toyota Production System - - and we will get to that -and more.

And your second observation is likely; ‘What in the world is a Project Management Work Cell? Are they finally going to install bars across my office window and door?’ No, instead we’ll be talking about raising the bar - - of our projects’ performance.

This presentation is my opportunity to share with you some interesting insights and tools that I discovered while exploring how to make my projects more successful. I hope these insights and tools will be useful to each of you - - I think they can be.

My exploration started with classic questions – How can I make my projects more successful? What should I and could I do to run my projects professionally?

In particular I was looking for time-effective solutions. There is so much to do - -and do right - - to keep a project on track that any new tools or practices that I add must not pull my attention away from the “big picture”.

3

For answers many of us start at a top level with the PMBOK which provides a wealth of structure and information.

Beyond that are lots and lots of books. I did a search on the Barnes & Noble website for books about “project management” and got back 2293 titles! Based on a sort by relevance, I estimated at least 1000 titles were specifically directed at our profession.

And there are training courses. Our local area PMI chapter website alone lists three or four great classes every other week. That incredible amount of available learning collateral can be overwhelming. And we are finite beings with limited time and retention capabilities. So I, like you, find myself being very selective in where and what I seek for new learning and self-improvement.

If we have a mentor or coach perhaps they help point us in a direction. Fortunately, we have another constant teacher always available - - our experience. We learn by doing.

4

Somewhere along the road to our matriculation from the college of hard knocks we have driven into our skulls the basic lesson that “Insanity is defined as doing the same thing over and over again and expecting different results.” And that is basically why we conduct “Lessons Learned” exercises as part of our project life cycles.

Some questions to ask of yourself are:

• Do you conduct Lessons Learned exercises as part of your projects?

• Do you routinely conduct Lessons Learned at the conclusion of your projects?

• Instead of waiting for the completion of the project, do you routinely conduct Lessons Learned after some interim key milestones?

• Do you ever consider conducting Lessons Learned even more frequently?

• Does the overall duration of your project is impact your decision of when and how to conduct the Lessons Learned?

My personal challenge to depending on Lessons Learned exercises arose from my niche in project management. I lead technical and multidisciplinary teams in developing and launching new products. Often these products are medical devices or instrumentation systems that require project durations on the order of 12 to 24 months or longer due to new innovations or substantial qualification testing. I found that if I waited until the end of these long projects to conduct the Lessons Learned exercise, this potential lag in the discovery and incorporation of improvements to the ongoing project management often missed important opportunities to achieve the project goals at lesser costs in time and energy. My need was clear - - I had to find opportunities to make Lessons Learned more contemporaneous.

5

My first step was to look at the basic items we typically want to harvest from a Lessons Learned exercise.

At the highest level I think these are all well covered by :

• We want to avoid undesirable outcomes.

• We want to repeat desirable outcomes.

• We want to repeat those desirable outcomes faster, cheaper and more predictably.

I mentioned the disadvantage of timeliness and missed opportunities.

But we should also note that it would be important if the Lessons Learned were done in a way that the results - - the recommendations - - were actually meaningful and useful and could be applied to our future activities. It is disappointing if the Lessons Learned just gets filed away and forgotten - - a project milestone completed and checked off - - but of no value to anyone.

And I believed there was a link between the timeliness and the value.

6

When we ask ourselves what are some of the important areas for the Lessons Learned exercise, we each bring our own favorite topics for review and improvement. This is not a completely comprehensive list but I hope it covers most of the items you usually find of interest.

This long list looked a bit overwhelming - - and it is probably why we often reserve conducting Lessons Learned until the end of the project or at the completion of significant phases or milestones.

It was clear to me that I should not be looking for a solution that tried to boil this ocean continuously - - but maybe I could keep one small pot boiling . Just focus on one area or a few topics - - not all of them.

I was willing to look for solutions both inside and outside the traditional domains of project management for ideas. And amongst the books, the magazines, the classes, the symposiums and some web-research - - I did find some important clues in the realm of Production, Process and Service.

7

What I found, as many of you already knew, is that the commitment to creating a better product, work environment and business - - every day - - is not a new concept. As a principle of continuous improvement, one of Deming’s 14 points states, “Improve constantly and forever" the system of production and service.

And this is where “Kaizen” is often quoted as beginning.

8

Kaizen is a Japanese word constructed from two ideographs, the first of which represents change and the second goodness or virtue.

The term Kaizen is used in two ways. The first use refers to the phrase “continuous improvement”. The second use is as the label for a group of methods that improve work processes.

In its first use, Kaizen means the pursuit of perfection in all one does. In this sense, Kaizen represents the element of continuous improvement that is a fundamental part of the “Quality Model”. In a business context, it includes all activities, as individuals and as teams, that leverage learning to make processes better at satisfying customer requirements.

In its second use, Kaizen identifies a group of methods for making work process improvements. The methods that have been placed under the Kaizen label range from suggestion systems to planned events conducted in the workplace that systematically uncover waste in a work process and eliminate it.

9

Kaizen eliminates waste by allowing workers to uncover improvement opportunities and either suggest or make changes. In Japan, some use the term to refer to a process that gathers suggestions for improvements from employees. Others use the term to refer to periodic meetings of employees who brainstorm improvement ideas and immediately select and make an improvement (remember “Quality Circles”?). Still others use the term to refer to special events during which a team of workers systematically detect and eliminate the presence of waste in a targeted work process.

In the production environment, when you Kaizen a specific process step, improvements are measured by such things as:

• Reduction in duration

• Decrease in the space required

• Fewer use of resources ( people, money, energy, information, machines, materials)

• Better outcomes ( higher quality , greater customer satisfaction, increased business cash flow, etc)

So - - Kaizen – I thought this was good discovery - - it was one piece of the contemporaneous Lessons Learned I was looking for - - but again the mystery was how to apply it to project management?

10

I found my next clue in a Harvard Business Review article from May 2004; “Learning to Lead at Toyota” by Steven J. Spear.

The article describes how Toyota leadership trainees directly observe people and machines in action—watching for and addressing problems as they emerge. Through frequent, simple experiments— relocating a switch, adjusting computer coding—they tested their hypotheses about which changes will create which consequences.

Toyota’s production system uses these simple real-time experiments, this application of Kaizen, to continually improve their operations.

But one additional and very important point, the Toyota Production System , which many of you know as Lean Manufacturing, presumes the introduction of material flow systems that embrace the goal of moving a manufactured item quickly from activity to activity without interruption for any of the types of waste. It considers how materials, people and information flow through a given manufacturing process. The intent is to studiously avoid work flows using batches and queues for a number of great reasons. The dual emphasis on efficient flow and avoidance of waste leads to the “lean work cell” that can accommodate a batch size of quantity one.

11

So this lean work cell is typically an arrangement of people, machines, materials and methods such that processing steps are adjacent and in sequential order so that parts can be processed typically - - one at a time. The lean work cell design is designed to achieve and maintain efficient continuous flow.

Key attributes of the lean work cell include the frequently repeatable nature of process activity that occurs there and the standardization of that activity. These attributes enable Kaizen’s cycle of observe, experiment, improve, sustain, observe, experiment, improve, sustain, …., and on and on.

12

A ‘lean manufacturing work cell’ was another step in the right direction.

The mystery was beginning to unravel. All I needed to do in order to apply the concept of Kaizen to Project Management was figure out where to find the equivalent of a lean manufacturing work cell in our project management processes. But how would we go about doing that?

PMBOK and other sources give us our classic definition of a project: "A project is a temporary endeavor undertaken to create a unique product, service or result." This ‘temporary endeavor’ language coupled with ‘unique’ seems to run afoul of finding something frequently repeatable and standardized.

In projects I typically run, the team travels from the Requirements Phase into the Research Phase into the Feasibility Phase into the Design Phase into the Testing Phase into the Transfer to Manufacturing Phase into the Production Ramp Up Phase and finally into the Product Release Phase.

Doesn’t look like much gets frequently repeated - - or does it?

13

With reflection and discussion I was able to identify some activities that occur within a project that are frequently repeated and may be subject to some standardization of activity. And I winnowed the list a bit to those activities that may have opportunities for improvements to the project.

Here is the list I came up with. Again it is not comprehensive but it was extensive enough to support my exploration.

“Task Assignment and Deployment” was my first choice for exploring a Project Management Work Cell. I suspected it had the easiest to access territory for Kaizen’sexperimentation and improvement.

Before I go much further, let’s agree that trying to apply every aspect of Lean Manufacturing onto what we do as Project Managers may not be the most useful application of our time and energy. We don’t want to stretch a good thing too far here. Again some selectivity in our choices of what may work for us is definitely in order. Having stipulated that caveat, let me paint a picture of “Task Assignment and Deployment” as a proposed Project Management work cell.

14

I started with something many of you are familiar with, the SIPOC analysis, where SIPOC is an acronym for SUPPLIER, INPUTS, PROCESS, OUTPUTS, CUSTOMERS. It is a methodology for process improvement employing analysis based on diagrammatic representation of these key elements - - not too removed from basic process mapping.

15

Using that format, we have the supplier (you the project manager) taking the inputs (the next task element from your WBS Dictionary and the dates from your project schedule) then executing the process of attaching that WBS Task to its performing resource identified from your Responsibility Assignment Matrix and sending it (well, sending the person) on its way to get the assigned task done. The output of this Project Management Work Cell is this ‘transformed task performer’ who is now also the customer of the process step because they are the one to go do the work. You, the project manager, are a ‘meta-customer’ because the results of the task completion are very much an ongoing concern for achieving overall project results. This did not yet quite achieve the clarity I was looking for in defining the process.

So lets see how this would typically work … …. All we need to do is fit the schedule against the resource availability and pull in this other skill set, and jam that one required input that will probably arrive late around the real expected work duration and squeeze out all three task deliverables even though the equipment needed is not yet reserved for the work,…

So as usual, the devil is in the details. There is a bit of granularity of information to explore for this lower level of this process.

16

Again with reflection and discussion I was able to identify what information is SHARED that transforms the resource into a more predictable performer of the WBS Task.

On review of this list we find there is an underlying theme; Miscommunication or under-communication of these task attributes and expectations increases the likelihood of unpredictable performance of the task.

I put this gather of attributes into a list but just as easily could have presented them, perhaps not so legibly, in a cause and effect diagram or a fishbone diagram.

I suspect that there are even more items for inclusion - - but this felt like a good step forward.

But even this list is still a bit unwieldy to use as-is to define and design a process.

17

So remembering that I was looking for a process to standardize on - - and this process is an information exchange - - a dialogue - - and I needed it to be convenient for us to use - - I sequenced these - - with a bit of an affinity exercise - - to these nine conversation points between the project manager and the task performer (see slide).

And of course I made it easy for myself by finding the acronym “APRIORITY” to make it easy to remember.

Let’s again emphasize that this process step is a conversation – a dialogue – not a Project Manager monologue, decree, declaration or diatribe. We are seeking an accord with the task performer - - that is the YES of concurrence – the agreement at the end of the process step - - that occurs only after there is a sharing of information and discovery on both sides.

As project managers, we are very motivated to find out about problems, issues and roadblocks before their consequences damage the project schedule, budget and quality. Spending 10 to 20 minutes in the conversation with the task performer prior to their launch of a 2 week task seems like a wise time investment. Because - - in the absence of such information sharing - - we leave ourselves vulnerable to the belated potential silent scream:

18

19

So how do we approach acquiring this accord?

Allow me to introduce another Japanese term; “NEMAWASHI”

NEMAWASHI is literally translated as “going around the roots”; from 根 (ne, root) and 回す (mawasu, to go around [something]).

It originally referred to gently digging around the roots of a bonsai tree in preparation for transplantation to a new container.

20

Within the Japanese business culture, Nemawashi refers to the groundwork or “touching base” with others that the Japanese view as necessary to secure informal consent and enlist support prior to formal decision-making. This is an informal activity of quietly laying the foundation by talking to those concerned to gather support and feedback. This helps to avoid discrepancies and allows people of differing views the time to adjust. The avowed benefit is that by gaining agreement from everyone in advance of a decision or formal meeting, relationships can be maintained as harmonious.

NEMAWASHI should have great resonance with each of us as Project Managers for its ability to strengthen the efficiency of our high-performance project teams and to sustain the support and commitment of our project stakeholders.

Of course here in America we tend to jump to the end of the matter and just talk about getting BUY-IN. And that is okay because it helps us understand that the process activity within this conceptual Project Management Work Cell is also NEMAWASHI and the output is not just a ‘transformed task performer’ who is going to go do the work – but – someone who has BUY-IN for the task and all the attributes and expectations that have been agreed to in the discussions with the Project Manager.

21

Reviewing my goals here – I wanted to define one of the Project Management Work Cells –and I chose Task Assignment and Deployment – with an expectation that it was a process that can be standardized and be repeated fairly frequently so we can analyze what improvements could be made and then experiment to try changes to achieve continuous improvement – Kaizen.

The one person that is ALWAYS in this Project Management Work Cell is us, the project manager. It is our activities and process that are the subject of scrutiny and improvement here. The other person in the conversation, the task performer, is going to change often. Although in most cases I would hope to see the same core team members with some regularity.

The primary activity within this Work Cell is information exchange - - a conversation.

And that conversation has an outline to it - - an order - - something we can standardize on.

A P R I O R I T Y

So we start with the inputs from the plan

• The project WBS task element

• The project schedule for that task

• The person identified as the task performer from the Responsibility Assignment Matrix.

And we bring to the table some tools;

• Sets of open-ended questions we’ll ask

• A willingness to participate in active listening as part of the dialog

• A notebook to record what was asked and what was said

( how else can you go back and assess and analyze?)

22

Another caveat before we proceed any further. Some of our wonderful coworkers on our project teams may not be - - - eager - - to sit down with us and go through this process.

An example would be the Generation X’ers who resent inflexibility in scheduling, being micromanaged, feeling pressure to conform or being viewed as lazy or un-ambitious.

Or you may have a foreign-born senior team member with a cultural aversion to answering any questions about the details of his work - - he’ll only tell you what he will provide and when it will be ready. He feels discussing anything else with you would be considered a challenge of his competency and professionalism.

As we know, good communication is sometimes difficult and a bit tricky. I found I needed to find the right level and the right questions for each situation. But the consequence of not going through the process is simply that I may miss important opportunities to achieve the project goals at lesser costs in time and energy.

So what does this conversation feel like? Let me present some sample questions I would use for maybe a junior team member with a good attitude and a reasonably strong commitment to the team and the project.

We start with the “A” of Achieve and Accomplish. What we want to discuss is:

What is the goal / What is it that we are going to get done?

What is going to be accomplished or achieved?

23

We move on to the “P” of Process and People.

Here our interests are:

How is the work going to get done?

What is the process to be used?

Who does this work?

Are they the right performers?

And these people are available when?

The questions about goodness of fit and motivation are to assess where the Task Performer is in general terms of being on the project team at this point. For more information on dealing with responses to these type questions, I recommend “A Manager’s Guide to Coaching” by Brian Emerson and Anne Loehr.

24

Then the first “R” – Resources and Requirements.

The focus here is:

What other resources will be needed?

What is the task budget?

What other requirements and constraints impact this task?

25

And the first “I” – the Inputs;

These basic process interests are:

What inputs do we need to start this task ?

And what inputs do we need to complete this task?

When will these inputs be available and from whom will they be provided?

26

The “O” of Outputs gains us shared clarity on the task deliverables:

What outputs are expected?

What are these output’s quality measures?

When are the outputs needed and who needs them?

27

The second “R” is Risks, Reasonableness and Rationality.

This is the point in the conversation where we want to deliberately do some temperature taking. In the prior discussion, quite a lot of the task has been explored and expanded upon. With that framework in place, now the discussion can address concerns:

• Are there any risks unique to this task to be managed?

• Is the plan for this task reasonable and rational?

Both the Project Manager and Task Performer can conduct their ‘reality check’. If it reveals issues that should have been surfaced earlier - - go back and work them until you can find ways to manage through the risks and uncertainties revealed.

If you have time and can find a copy, “AntiPatterns in Project Management” by WJ Brown, HW McCormick III and SW Thomas is great background reading for recognizing the irrational and unreasonable in some project approaches.

If you are not doing this conversation face-to-face then you may be at a disadvantage. Reading the body language and facial expressions during this part of the discussion is important to finding out just how comfortable or uncomfortable the Task Performer is with the work about to be undertaken. You may have to listen carefully to their choice of vocabulary to assess where there confidence is and isn’t.

28

The second “I” of Interim Information can be thought of as a ‘second look’. Remember, this is the conversation point where we explore what progress and status reporting is needed.

If it is a two week task, you may want to request an email update from the task perfromer at the 1 week mark to see if task progress is at the 50% mark or not.

It is all about timely warnings on expected or unexpected challenges to the task execution. If you know early - - you can react and respond. Finding out late just means recovering - - - if possible.

29

The “T” of Time - - I guess I could have said Schedule instead - - but then the acronym would have been APRIORISY instead of APRIORITY which would not make much sense.

This conversation point holds a position near the end of the discussion to ensure good understanding of all that will go into the task. Estimating - - or re-estimating the effort required to accomplish the task should now be done with much less uncertainty.

30

The “Y” of “YES” is more than one final question. This is a second temperature taking. You may chose to repeat or summarize all that has been gone over through the conversation to make sure you and the Task Performer heard the same things.

So it is the answer to this last question,

“Based on what we have discussed and agreed about this task, can you now commit to doing the work within our mutual expectations?”

- - if you get a “YES” - - declare the conclusion of the conversation and the process.

If you get a “NO”, go back and work the open issues until you find the “YES”.

One caution: Avoid prematurely asking for, getting or accepting the YES prior to going through the full conversation. Shortcutting may leave both you and the task performer with some uncomfortable ambiguity.

I use a simple form for organizing this APRIORITY conversation. The form makes it convenient to prepare for the conversation and it is useful for organizing my notes during the conversation.

31

After the conversation, I found it important to consolidate my written notes into a clear record. If it makes sense, I provide the task performer with a copy of that written record. A comfortable email transmittal may be “I thought you may want a copy of my notes from our meeting today on your task. Thank you for your time. The discussion helped me appreciate what all is going into the work you will be doing for this part of the project.”

There may be additional notes though that you don’t transmit. Throughout the conversation you should have been attentive to the body language and choice of vocabulary as additional clues to just how much buy-in and understanding were actually achieved.

32

AND FINALLY - - We are ready to Kaizen this Project Management Work Cell !!

Now monitor the performance and the results of the task - - pretty much standard fare for a project manager. Assess the gaps between the expectations and the results. These gaps may be in the dimensions of schedule, budget, quality, or other important dimensions of the project.

Next, honestly evaluate what you could have done differently during the conversation that may have more successfully influenced the task results. (This is where that written record comes in very handy!)

Then determine what you will change in your next APRIORITY conversation –make that change and observe the results of the experiment with the ensuing task. See if the improvement was realized.

If it did – then we learned something we can apply. If it did not, then back to analysis and experimentation.

--------------------------------------------------------------------------------------------------------

So we have found a spot for Kaizen in our project management; this never-ending process of continual improvement.

33

My goal in this workshop presentation was to share with you some things I have learned and used and I hope they will be useful to you.

This last slide shows the Japanese ideograph for COURAGE.

I wish each of you the courage to find and make your own improvements to your projects and your project management skills.

Thank you.

34

Jeff holds a BS in Engineering Physics and a MS in Engineering Science, both from UC Berkeley. While he started his career as a Nuclear Engineer with General Electric in California (and earned his Professional Engineering license while there), Jeff soon shifted over to (Nuclear) Magnetic Resonance Imaging. He got his early exposure to project management with both facility projects and MRI product upgrade projects while at Toshiba America Medical Systems. Jeff’s first formal posting as a Project Manager was at Fairchild Imaging in Sunnyvale working with digital dental x-ray sensor systems and other CCD-based instruments.

After relocating to Colorado, Jeff worked at RELA in Boulder where he managed multiple project teams to develop and deliver a variety of medical devices and biotechnology machines for client companies. Subsequent project management assignments at Ionics Instruments in Boulder and Sartorius in Arvada produced process instrumentation and laboratory instruments.

Jeff’s most recent assignments as both Project Manager and Program Manager have been in startups; At SysTest Labs in Denver he crafted a process for that company to extend their value-added software testing services into the medical device industry, and, at Ascend Geo in Golden, he led internal and external technical teams in the development and product launch of innovative instrumentation systems used for field seismic data acquisition for the oil and gas industry.

December 9, 2009

35

At this time Jeff is available for consulting, contracting or permanent assignments in Project Management, Program Management and New Product Development.

You can reach Jeff at:

Email js_marsh @ att.net

Cell 303 664-9985

LinkedIn http://www.linkedin.com/pub/jeff-marsh/0/747/567

36

In the following slides, the selected questions and their answers are paraphrased.

37

I don’t think we need to add the third R but the goal of going back over what was discussed is important. I would recommend doing that as we enter the ‘YES’ conversation point.

38

I have used this for both software and firmware development tasks - - - but probably more for firmware development due to the nature of most of the hardware and instrumentation products I work on.

I found that this tool helped particularly well in getting clarity of Task Performer estimates and priorities. I also diligently attended to never letting a software task be set for longer than 2 weeks without breaking it down into sub-milestones and sub-tasks. I usually ended up checking the status of such 2 week tasks at least weekly.

This tool was also used in a project environment where we maintained a fairly good detailed look-ahead at the prioritized backlog of software tasks. This allowed the team to anticipate what comes next and provided me a basic burndown list to check against.

I don’t have experience as a Scrum Master so I would recommend that someone more familiar with AGILE methodologies would be in a better position to explore what would be their analog to this APRIORITY conversation process design for their SCRUM process.

39

I have found that in a majority of cases where we are unable to arrive at agreement there are a couple of underlying drivers:

1) The Task Performer has looked at the goals and constraints and does not believe they can successfully deliver in the dimensions of schedule or quality due to either their ability of availability.

2) The Task Performer has fundamental differences with some key assumptions of the project or task.

3) The Task Performer has personally assigned a much lower value to the project and/or the task at hand than the Project Manager and therefore does not believe the effort is warranted to do the work.

4) The Project Manager has failed to buffer the team from impossible constraints or deadlines that are imposed from on-high.

While each instance requires a different approach, some of the choices of resolution available to us are:

a) Tell the Task Performer you understand their point of view but would ask that they, for just this task, just go along with the plan so the team and project can progress.

b) If you’ve had to use that line more than twice with a given Task Performer, consider replacing that team member.

c) Agree to disagree but identify what are the specific impacts of the specific issues of disagreement and take steps to compensate elsewhere in the project for the difference in task plan versus anticipated task performance.

d) [Theory X school of management] Explain to the Task Performer that you are in charge of the project and their failure to agree and perform will have consequences for them.

40

I took on this exploration with the initial assumption that I was looking for tools that the Project Manager could apply, not necessarily tools for the team. Yet the original questions I posed myself were:

“How can I make my projects more successful? What should I and could I do to run my projects professionally?”

Incorporating the project team’s insights into the Kaizen process on this Project Management Work Cell is directly in line with “Kaizen eliminates waste by allowing workers to uncover improvement opportunities and either suggest or make changes.”

Thomas Isgar, in his book “The Ten Minute Team; 10 Steps to Building High Performing Teams” offers as part of his Step#8 ‘Problem Solving/Conflict Resolution’ that time should be set aside in the weekly team meetings to address and work a given problem the team is seeing. It is easy for us to believe that once we start applying the APRIORITY conversations to the project, the team members will be very aware of it and its usage - - - and won’t be averse to working to make its influence on their lives a bit more tolerable.

However - - I would suggest using something like the Vroom/Tetton/Jago model to sort out and carefully select which specific task performance gaps or kaizen issues to bring forward to the team. But I would also look for trends that seem to loom larger than what is being impacted by APRIORITY and consider those first for the team Kaizen exercise.

41