The Right Question and Turf Wars
My first organized attempt at process improvement occurred when a group of us across a large corporation was asked to "pick a design tool for new designs." Of course, the team knew that the tool selection was secondary to having a well-defined design process, so we went off and developed a software design process, with a development methodology suited to the design work being done in the organization. Our final report was well thought out, had many good ideas, and when I reviewed it many years later with the benefit of hindsight, was a darn good piece of work. Of course, it was trashed, for obvious, but hidden, reasons. First, we did not answer the question we were asked to solve. Second, as it turned out, there was a VP in the company responsible for "Quality," and our project, even though commissioned by the VPs of the development centers, invaded his turf.
Lessons Learned 1:
- Answer the question you are asked, or negotiate the right question
- Understand the political power structure; don't invade someone else's turf (especially if they have the power to "kill" your work)
The Ideal Situation
My second attempt was much more successful. It went something like this:
Senior Manager (SM): I have this problem.
Process Person (PP): I can help you.
SM: I will worry about today's problem; you prevent it in the future.
PP (sometime later): We need to do A and B to prevent the problem.
SM to direct reports: You WILL do what PP says.
If this has ever happened to you, you have no doubt recognized the good fortune you have had. There isn't much to say about this situation, other than don't squander the opportunity.
Lessons Learned 2:
- A boss like this is worth their weight in gold!
- If Process Improvement is your career path, do everything possible to stay with this person!
Unfortunately, this isn't terribly representative of the real world. In this case, I was lucky to have a boss who understood the value of good process. We had already worked together for several years, and she was willing to support me. If your boss does not have this appreciation, the language you are using to discuss your proposal may be a bit arcane, they may never have designed or written code (or worse, maybe they have), or maybe you do not have a background in this "real world" work. Remember how much training and studying you went through to reach your current understanding of the problem you are trying to solve. Take this into consideration when dealing with those who have a different set of problems and knowledge.