Workgroup Kaizen for Project TeamsBy 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 Summary 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. Read about what the other 6 bloggers wrote today about Workgroup Kaizen for Project Teams Hal Macomber, Norman Bodek, Chuck Frey, Joe Ely, Bill Waddell and Mark Graban on their respective blogs. 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. Bob, I just received a request from a subscriber of "Lean Directions" to address lean in software development. I think your comment on Jon's post is a good example -- would you be willing to write it up and expand it as an article? Gang of Seven -- With Bob's permission, I will freely give you the rights to incorporate the resulting article in your book, thus attempting to justify this query to Bob using your blog. Hope it's OK. Poster: Karen Wilhelm | Post Date: December 14, 2005 5:44 AM |
I was once in charge of the test team (~12 people) on a software project that had a new development platform. As a result, they really did not have a fully developed testing process. I knew from past experience that we would have some problems with our testing process; we would need to make it better fast, and we should start on this effort immediately. Further I knew that we would have to get better even faster once testing started. Testing always gets squeezed for time at the end of the project.
There is a set of very simple measures for a process. First is cycle-time. For testing, cycle time is the period from announcement of a build until testing results can be delivered to the change board and developers. We wanted a one-week cycle. Both developers and testers set priorities for testing but the overriding concern is throughput: maximize the value of test cases completed and do it with an appropriate set of priorities. The word "value" is used instead of number because some test cases are more important and some take more time. Importance is concerned with overall risk reduction and customer satisfaction.
Next is unit-cost. Accountants would like to measure productivity, but productivity is always a derived measure calculated from historical data. I wanted to use the (current) tacit knowledge of the team. They should be able to tell me the cost (effort and other resources required) to execute a test case. I didn't care whether it was dollars, time, people or facility, but they had to decide how they would measure it. They created a scale from 1-to-5 for least costly to most costly. I suspect their scale was mostly based on effort, but that was not the only factor. Each test case was rated. They could use this unit cost measure to determine the unit cost and throughput for predicting to how much could be done in a week. Say for example, that a normal tester could perform 50 units a week so 8 testers could perform 400. Understand that "performing test cases” is not the entire job. The job includes documenting the failures which takes a good bit of time. Do you count recording the failure as part of the effort and cycle time or does it belong to a separate process? There is not a right answer, but everyone has to agree on the answer.
The third measure was rework. This was one I suggested myself. I asked the testers to count how many times they had to restart a test case before they could make a determination of the result. It did not matter whether the result was pass or fail. The measure was related to why determining pass or fail took so long. There are many possible reasons for this rework such as: unclear text, test data not available, wrong setup.
Finally, we had weekly “testing improvement meetings” where we would analyze this data. On a project where the test cycle was planned for 8 weeks, we
doubled the throughput (value of test cases completed in a week) in 3 weeks, and reduced rework by 60% as measured in restarts and "bad test cases"
and produced one of the best products the organization had seen.
Many activities on a project can be subjected to kaizen principles.