By Jon Miller | Post Date: December 6, 2005 10:49 PM | Comments: 2
Today I'm blogging about Workgroup Kaizen for Project Teams. I'm going to take you behind the scenes for a moment and see what we can learn from a project that a workgroup called the Gang of Seven bloggers is involved in. By reading this, you're involved in it too. I'm all about holding people accountable, especially if they claim to be kaizen professionals, so I am taking us to task.
In a very real sense, the Gang of Seven bloggers are a workgroup of this project team of co-blogging on the topic of Kaizen for Project Teams. I was curious to see whether we would practice what we preach and apply project management and kaizen tools to our project. Now that we have proven that even a group of seven experts on Lean and innovation are fallible human beings, I have material for this blog.
I differentiate the core workgroup (the 7 bloggers) on this project from the "workstream" project team members, or those people who helped send out the press release, people who will help with the publishing and distribution of the handbook in 2006, the "plus one" blogger contributors, readers who post comments, etc. I only knew one member of my workgroup personally prior to this project and the others only through their writing. This may be atypical of a workgroup, but probably not of project teams in general.
Project teams are temporary. Some workgroups may persist and work on other projects within the same organization, while some workgroups, like ours, will disband at least for a time as the Gang of Seven bloggers after this week. In any case we have a short period of time within which to get to know each other and "storm, form and norm" as an effective team. In this day and age much of this happens with the help of something called the internet.
Technology is a wonderful thing to enable workgroup kaizen, as Mark Graban points out in his post today. E-mail allows us to rapidly form a team and work together. The internet let's us write collaboratively from different points on the globe and include hundreds of readers in the process, if they choose to post comments. Yet e-mail is a nefarious way to run a team meeting. More than 80% of communication is a combination of body language and tone of voice, according to psychologists. To the best of my knowledge, none of the work of this Gang of Seven workgroup so far was done face to face. This has a price.
Hindsight is 20-20 so let's see what we can learn from our mistakes. I'm going to gloss over all of the good things our workgroup has done this week, since I think mistakes can be more instructive. There are three rules I try to follow when leading major projects as well as smaller scale kaizen activities, so I will categorize my observations in context of these three rules:
1) Clarify the Goals
This was well done. The goal, as I understood it was for all of us to post one article each day on the same topic, for five days on the week of December 5 - 9, 2005. As a secondary goal, this workgroup would publish a book of the resulting work sometime in 2006. These are smart goals.
But each of us as workgroup members and owners of this project most likely also had goals. One lesson I've learned during kaizen activity is to clarify the goals of the kaizen event, but make sure that other intangible goals or individual goals are surfaced early so that they are not in conflict and can ideally be achieved as well.
Sometimes these minor, individual goals can cause trouble, if they are not made clear first. I was nearly guilty of this.
We were asked for our input on topics for each day, on the theme of Kaizen for Project Teams. The project leader asked for our improvement suggestions, as any good leader would do on the project plan. I gave my ideas. Being mine, these ideas were important to me and in my opinion important for the success of the project. To make a long story short, the project leader basically said “Thank you for your input” and proceeded with something like the original plan. My kaizen idea had effectively met the shredder.
I was surprised by this, and waited for some explanation of the process of how the decision was made to go with the final topics. I received none, but we were on a tight schedule and it was not worth slowing the whole process down to satisfy my curiosity. I think the reason was that my goal was to do justice to the topic of kaizen while the team leader's goal was to do justice to the topic of Kaizen for Project Teams.
I now know what it feels like to have the project leader or consultant ask for suggestions and ideas, and then have them go ahead in a different and possibly pre-set direction, without explanation. I can remember railroading kaizen team members as well as my staff with the solution that is “right” in my mind rather than take and develop their ideas that I may not think are the best ones to achieve the goal. This time the tables were turned, and it provided a good lesson for doing workgroup kaizen for project teams.
2) Define the Boundaries
It's another minor point, but I've noticed a discrepancy in the timing of the posts. Due to my travel schedule this week, and the fact that I tend to write until the minute I publish instead of in advance, I have been the last blogger to post each day so far. Bill on the other hand, appears to be a day ahead of the rest of us. The others are between early and on-time. It will all even out over the week, and it certainly will matter less when reading in a book form, but to a reader who wants all seven perspectives on the same topic of Kaizen for Project Teams at one time, this must to be inconvenient. My apologies.
When the guidelines for length of the blogs were given "one long, one short, others between x and y words" I responded that most of my blogs were on the long end of those guidelines. There was no big objection. This entry finds me out of bounds at over 1,700 words. What's my excuse? Like anyone who knowing violates a standard, it's because it's inconvenient for me and I don't understand the reason the boundary was set.
Thanks Hal, for adding the word pithy to my vocabulary.
Brainstorming and making changes to your work can’t be quite as open-ended during workgroup kaizen for project teams. Since a project by definition has a limited scope and duration, the scope of kaizen acitivity within a workgroup needs to be well-defined and "bounded". By contrast a widget in continuous production for several years can be improved over time in many ways, even through quite dramatic innovation and redesign of the product and process. When doing workgroup kaizen for project teams its especially important to clarify "What's in and what's out of bounds" and the reasons why.
3) Clarify the Decision Making Process
During a kaizen event or in Lean manufacturing implementation this is often a simple case of asking “Does taking this decision move us closer to flow?” or “Does this reduce waste?” or ultimately “Does this move us closer to profitability, without violating Lean principles, harming our people or our customers?” While you can adopt this almost as-is when doing workgroup kaizen for project teams, the definitions of customers may need to be expanded to include more internal customers and stakeholders, and the question of “Does this move us closer to flow?” may be too simplistic depending on what the project is trying to accomplish.
One example of a decision that didn't get made was the adoption by our workgroup of an idea by Joe Ely. One of the topics that didn't make the cut was "Getting in the Habit". Joe made a great suggestion that we should have a section at the end of each day on "Getting in the Habit". Read Joe's daily blogs this week and you'll see that he has done this. I'm ashamed that I'm one of the people that thought "Hey, great idea" and never thought to put it into action, or to ask the others for their thoughts on this. I'm guilty of PDCA without the DCA.
But to point the finger of blame at others, what the originator of the idea didn't do was say "Here is my kaizen idea. Here is how I think it will help meet team or individual goals. What do you think?" What the team leader didn't say was "Let's not do this." or "Let's do this. Team, show me that you understand how to follow this new standard." Again, as Hal Macomber reminded us in his post these mindful behaviors are particularly important for project teams.
As Joe pointed out in his post Project Kaizen: Single Piece Flow in the Workgroup, work needs to flow one at a time in a project. One piece flow is needed by the same token for communication and decision making during a project, rather than in batch and queue mode that delayed e-mail processing requires. None of our meetings were face to face, stand up meetings like Norman explained in his post Running Effective Meetings. We did none of the mapping of our project plan or visualization of potential defects before they occur, like Bill described in Project Kaizen - The Workgroup.
In this day and age when internet based collaboration of workgroups is becoming more common, it’s increasingly important to follow kaizen principles of genchi gembutsu and be on-site and fact-based as much as possible. Visualize the process by clearly outlining decision making processes and priorities. Build in quality by asking everyone “In your words, what did we just agree to do?” Empowerment is just a silly word when it is not supported by the behaviors and rules that make kaizen possible within workgroups and project teams.
On behalf of all seven of us bloggers I'd like to than the many comments and suggestions for improvement received by our workgroup to the format and content of the blogs so far this week.
The Kaizen for Project Teams blog entries on Panta Rei are Making the Case for Kaizen for Project Teams, Workgroup Kaizen for Project Teams, Workstream Kaizen for Project Teams, Quick and Easy Kaizen for Project Teams, and Kaizen Blitz for Project Teams.Comments are moderated to filter spam and inappropriate content. There may be a delay before your comment is published.