Kaizen and Project Management

Last week I got a chance to tour the Mead Johnson manufacturing facilities here in Evansville, and I was struck by how firmly kaizen is embedded in the culture of our supply chain.   The plants are clean and tidy, with performance and safety metrics prominently displayed.  Improvement ideas are posted, the author(s) credited, and the results are made available to all.

I’ve always thought that PMs could better leverage kaizen thinking, especially when they’re IT PMs in a business that values continuous improvement.  Many methodologies are out there for kaizen-inspired product or project management.  These concepts are at the heart of agile, Six Sigma, lean, etc.  In fact, I’m using some principles now, like using 5S to organize the project portfolio.  I’m also planning to get key performance reporting visible to all.

What other approaches have you seen to introduce “project management with kaizen characteristics”?  In particular, I’d like to see what has worked to promote better IT/business understanding and alignment.

Accountability for “soft stuff” deliverables

Per an earlier post (here), I have a bee in my bonnet about “supporting” deliverables and how to measure their success.  The excellent comments from Glen and Stephen (here) pointed to the answer.  From Glen:

We are looking for cost savings, efficiencies, and other process improvements. This is the typical work flow process improvement approach. Extend that to the human processes – monetized – and you can define MOP’s and MOE’s [measures of performance and effectiveness respectively].

In retrospect, it should be obvious that training deliverables — and their measures and incentives — should make such deliverables accountable for the relevant process/solution/project/program success measures.   In other words, CRM call center training should be judged by the how well the call center solution delivers the intended capabilities.

This approach is not so obvious to many training professionals, largely because many have never been held to the same standard as process owners.   My experience — from observing a particularly savvy SAP customer — is that a few pointed questions do concentrate the trainers’ minds:

  • Are you worried that the training does not support the actual execution of the processes?
  • What do we need to change in our training approach so that it delivers value to the project?
  • Why am I spending money on training if it can’t be held accountable for project/process succeess?
  • Do you still wonder why trainers aren’t better paid?
%d bloggers like this: