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.