Archives

Next Archive Previous Archive

01 Feb - 28 Feb 2006
01 Dec - 31 Dec 2005
01 Nov - 30 Nov 2005
01 Oct - 31 Oct 2005
01 Sep - 30 Sep 2005
01 Aug - 31 Aug 2005
01 Jul - 31 Jul 2005
01 June - 30 June 2005
01 May - 31 May 2005

Calendar

« October 2008
S M T W T F S
      1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31  

Stuff

Powered byPivot - 1.24.1: 'Arcee'
XML Feed (RSS 1.0)
XML: Atom Feed


Creative Commons Licence
This work is licenced under a Creative Commons Licence.

About

These are the archive pages of SwimBlog.
You can also use the search function on the Main Page to look for entries with keywords or phrases

+ 1 - 1 | § More on Project Kaizen

The first question being tackled by the Project Kaizen co-bloggers is 'Why do kaizen on projects?'. I believe a more revealing question would be 'where can we apply kaizen thinking to projects?'

For me, project perfomance improvement and optimisation opportunities can come from 4 areas:

1. First pass project planning to optimise task sequences and information handoffs.
2. Ongoing re-thinking of task sequencing and possible re-planning in the light of new information obtained.
3. Individual work planning and execution.
4. Mindful reflection (thanks for the term Hal!) on the work that has just been carried out with the intent to do it better next time.

1 and 2 will normally be the responsibility of a project manager, and so should 'automatically' happen for each project.

3 and 4 are where the actual project work happens, and is where kaizen is traditionally effective - it empowers those closest to the actual work to make the improvements. The easier of the two is probably 3, because a person embarking on a task will surely give at least some thought to how it will be done. All we need to do is to encourage a broader mindset so the individual optimises his or her own workplan until it is good enough, working as appropriate with uptream or downstream work owners to determine the best methods for passing information along. This approach should not be too difficult to instill, as most people are willing to put in a little up-front thought if they believe they will save themselves, or dependent work owners, some effort in the short-term.

However, 4 is the real challenge. The payoff is potentially higher than 3 as benefits can be repeated over time, but for kaizen to take root here, we need to motivate work owners to stray beyond the boundaries of the work at hand, and consider improvement possibilities that may not bring them any personal benefits. Things are made even more difficult due to the fact that next time the task is carried out, the inputs and outputs may be different. It takes significant time and effort to think through the possible combinations, and in fact it may not be possible to do so. This is where process kaizen and project kaizen differ. In the former, conditions are the same or similar each time the work is carried out, and the worker has an intrinsic motivation to make his own life easier for next time. In the latter we are relying more on altruism, or may need to provide for external motivations such as improvement suggestion measures or targets as suggested by Hal.

In conclusion then, for projects a kaizen approach to improvement seems to be suited to individual work planning where there is an immediate benefit to an individual and/or the project team. However, making kaizen work as a method for identifying improvements that can carry forward to the next project would take a lot more effort. In this latter case, maybe the traditional end-of-project review is more appropriate

+ 1 - 1 | § Project Kaizen

How can you continuously improve your performance in new product development projects, when each project is different? The concept of kaizen, or structured continuous improvement has been around for some time now, but some of the techniques and analysis tools that go with kaizen (process mapping, control charts, pareto analysis etc.) lend themselves most readily to repeatable processes where conclusions can be drawn from observations of past perfomance. In projects, we typically get one attempt at an activity, and it either goes well or it doesn't. OK, so we may do many similar projects over a period of time, but by the time we have data or case study stories to analyse, the opportunity to improve may have disappeared. So, is a kaizen approach possible in a project driven organisation?

This is the question behind a co-blogging event being co-ordinated by Hal Macomber at Reforming Project Management. It will be interesting to follow the discussions.

+ 1 - 1 | § GM's Quality Cat!

If you are ever tempted to try any gimmicks to promote an improvement initiative, you need to read this article first (warning: article contains 'colourful' language). Apparently, some bright General Motors executives thought that a man dressed up in a furry suit, prowling the GM production lines would encourage workers to improve quality. The character, named 'Howie Makem' was popular for all of five minutes, until the workers began to cotton on to the unstated message that they had the intellects of children. I wonder what actually happened to quality during that period?

In the end, Howie's visits stopped. There were rumours he was made redundant.