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”.

1. 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

2. 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

3. 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

4. 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

5. 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

6. 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

7. 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

8. 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

9. 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

10. 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

11. 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

12. 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

13. 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

14. 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’s
experimentation 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

15. 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

16. 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

17. 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

18. 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. 19

20. 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

21. 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

22. 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.
APRIORITY
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

23. 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

24. 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

25. 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

26. 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

27. 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

28. 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

29. 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

30. 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

31. 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

32. 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

33. 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

34. 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

35. 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

36. 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

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

38. 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

39. 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

40. 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

41. 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