The Case For Kaizen on Projects

Hal Macomber, who some of you may know, is a guy who works quite a bit on applying lean principles in project areas, and he recently put together a gang of lean bloggers for the purpose of having us throw out our largely uniformed, but nevertheless none too humble opinions on the matter.  What will give this project juice is having all of the much better informed, but typically very humble, Superfactory readers jump in with their comments.  There is a different aspect of the subject to look at every day and the goal is to put all of the blogs, comments, etc... into a book at the end of it all that will represent a pretty fair collection of the body of knowledge.

The first topic is why apply kaizen to projects at all?  Check out the other thoughts on the question by reading what Hal has to say at Reforming Project Management, or Norm Bodek at Kaikaku, or Chuck Frey at Innovation Weblog, or Joe Ely at Learning About Lean, or Mark Graban at the Lean Manufacturing Blog, or Jon Miller at Gemba Panta Rei.  While you are there, you ought to check out what these guys have to say about other lean topics.  You'll see it is pretty heady company I have been thrown in with.

You can see they kept it pretty easy at first so we can get warmed up.  Just about all I know about lean manufacturing is the Toyota version, which seems to be getting further and further from how others are defining lean.  At Toyota, what gets kaizened is a process.  If any process needs kaizening, it would be a project.

Just so everyone understands, a 'project' is defined for the purpose of the blog as just about any ad hoc sort of group that comes together for the purpose of accomplishing a one time only, unique goal.  The project can be the various construction work specialists who build a house, the medical team in an operating room, the gang of nerds needed to design and write software; it can even be that gaggle of women that may have descended on your kitchen on Thanksgiving for the purpose of gossiping, bickering, one upping each other and somehow putting an incredible dinner on the table at the end of it all.

By definition, a project has no defined process, or, at best, a basic process that was cobbled together to justify getting the group together to launch the effort.  Even the least lean manufacturer has already taken all of the blatant waste out of its processes, and a kaizen effort to improve those processes has to start from wherever those improvement efforts have left off.  A project, on the other hand, is virgin territory.  Because it is brand new, there has never been an eye cast upon it for the purpose of improving it.

Step one in any project should be a kaizen effort, bringing all of the owners of the brand new process together to share their creative and intellectual best, in order to assure that the process is optimized prior to lifting the first finger.

Any project should begin with a basic flow chart - a sort of value stream map - that defines how the team is going to sequentially arrive at the intended deliverables.  The next order of business is to kaizen that process chart to death to optimize the project, and assure complete project team ownership.

As I said, the questions will get harder as the week progresses.  As I also said, the value comes from you.  On a final note, most of the bloggers in this project (including me) have agreed to contribute their share of the proceeds from the sale of the book at the end of this effort to Habitat For Humanity.  The quality of your comments on my posts, and that of the other bloggers will help a very good cause.

Comments

[Mark Williams at Swim]

Bill, you said:

"Any project should begin with a basic flow chart - a sort of value stream map - that defines how the team is going to sequentially arrive at the intended deliverables."

This has many similarities with the traditional task of producing a project plan. Do you see the mapping and optimisation exercise as a seperate activity?

[Bill Waddell]

No, Mark, I don't think there is much different about the chart, or the map, at the outset. The difference is what is done with it. As the week goes on I will talk about aome of the kaizen impacts, but essentially, the traditional approach has been to use the map as a static document that represents a firm schedule and a fixed budget. What I hope evolves as the week goes on is an approach that views the chart, or map, as a flexible document that is continually improved.

For the most part, the traditional chart outlining the project steps becomes a best case. Everyone tries to meet the milestones, with little incentive to beat the time line - the project only gets worse from the starting point, or at best, meets the schedule. With a kaizen approach, the initial map becomes the worst case scenarion - everyone focuses on improving from the starting point.

So the chart is about the same, but the application is radically different.

[Jinjer Markley]

that gaggle of women that may have descended on your kitchen on Thanksgiving

Hey, hey now! You're going to have to be more careful about statements implying your audience is male--Kathleen Fasanella is sending over a gaggle of fashion business owners interested in running a lean operation--and a lot of us are chicks.:P

[Bill Waddell]

Jinjer, I was referring to the gaggle of grandmothers, aunts, and others bent on establishing their reputation as world class pie bakers and stuffing afficienados. My assumption was that the female segment of the Superfactory audience generally operates to a different set of priorities; and that you were in the den with me and Kathleen, knockin' back a bottle of something, content to let the gaggle demonstrate their prowess unmolested by us.