One of the recurring questions in the Message Board forums, and in other discussion groups, is the difficulty we have in getting management to listen to us when we propose some sort of improvement initiative. Whether it is a large-scale CMM-based improvement effort, or a small-scale, limited-scope improvement, we see our proposals ignored at best, or trashed with attendant risk to our careers. In more than fifteen years of working in various improvement initiatives, some sponsored top down, others bottom up, and as both a company employee and an external consultant, I have had a mixture of successes and failures that may help others who want to help their companies improve. 

The last phrase, "help their companies improve," really gets to the heart of the matter. Most of the time, we see a problem, know of a solution that will solve the problem, and often assume that the solution is so obvious or logical that we blast forward without sufficient thought to the culture, environment, or support structures within the company. These elements are critical to the success of our initiative. After being severely bludgeoned about the head and shoulders, we come to the conclusion that "management (or another convenient target) just doesn't get it," and we become discouraged and cease our efforts. When these stories are posted in newsgroup discussions, or discussed at conferences, the advice I see in many cases is to "switch companies and find a supportive culture or management." I will argue that this approach is doomed to failure, and the best way to succeed is to plan your strategy to acknowledge whatever roadblocks are in the way before you start, and work around them. Beating yourself against immovable objects will not succeed, but isolating these obstacles and showing progress elsewhere will lead to success in the long run.

The "Management Problem"
While management certainly can cause many of the problems we must overcome, often management is a scapegoat. There are some real problems, which I categorize below:

PHMs Pointy Haired Managers

ADD Attention Deficit Disorder

PSI Problem Saturation Index

DHC Don't Have a Clue

However, as Walt Kelly said in Pogo years ago, "We have met the enemy and it is us." All too often the fault is ours, in that we lack a business view, get mired in detail, and have difficulty getting our point across in a short time, if at all. A boss once told me that the biggest mistake I was making was assuming others had the same interest and some knowledge in the areas I was passionately working on. To succeed, we need to present our ideas in terms that grab the attention of the decision makers (not always management—don't forget the technical leaders), in terms they understand, and within the allotted time (attention span) that they can reasonably devote to you. What may be the  biggest problem the company faces in your eyes may be only one of many that are taking management's time.

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: Good.

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.

The Estimating Problem
A while ago I chaired a senior management panel on the value of Inspections and their role in establishing the process in their organization. It was a forty-five-minute panel, and each of the three panelists was to speak for ten minutes, with fifteen minutes at the end for questions and answers. The actual results were:

VP #1: two slides, spoke for thirteen minutes

VP #2: six slides, spoke for thirteen minutes

PM #1: ten slides, spoke for thirteen minutes

Thus the 30 percent rule: Management underestimates their tasks by 30 percent, so why not yours (or the projects they manage)? It is necessary to understand their background (software and project management experience, or lack thereof).

Lessons Learned 3:

• Know what makes your bosses tick (what's important to them)
• Do a "background check"

The Problem Saturation Index
By profession or inclination, if you are interested in process improvement you tend to look to the future, anticipate problems, and try to avoid them. We dislike firefighting and crisis management, even if we are good at it. In companies without a strong process focus, people tend to be consumed by today's problems and do not have time to drain the swamp. Their agenda is too full of alligators. I was in this situation on one job, and in a lunchtime conversation, a friend said something like this: "Ed, your problem is that management is so consumed with today's problems that when you propose solutions to next year's problems it doesn't even register."

If this is the case, how do you get anything done? What might work is finding the solution and implementing it-presenting a fixed problem to the boss rather than another problem. You might worry that you are not empowered to do this, but if the boss is really that saturated with today's problems, there is a chance you really have the opportunity to solve a future problem. Solutions that work are appreciated. If you take this approach, beware Lesson Learned 1 about turf. If your solution works, get the people who did the work to advertise it. Doing it yourself may be seen as self-serving, and if the development teams did the work, they will have more success in spreading the change in many organizations.

Lessons Learned 4:

• If management really is saturated with problems, don't bring them one more
• Identify the problem, pilot a solution, and gather the data that shows you have a winner
• Better to be a winner than a whiner

Attention Deficit Disorder
How many times have you been in the situation where something that worked on the last project is left out of the next one? When you investigate, you find that someone has changed the project to make it go faster ("We don't need to do inspections this time, since everyone will remember the mistakes they made the last time and they won't happen again"). This is frustrating, especially if you have done lessons learned, identified all the good things you want to do again, and have had numerous discussions about the good results obtained on the last project.

Fortunately, this is relatively easy to overcome. Go to the people with short memories, and remind them of the disasters they managed or participated in, and gently remind them of how much better things will be if they follow the proven methods for success. If gentle reminders don't work, more forceful reminders of the last disaster they were involved with may be in order. In some cases, you have to go over their heads and convince the next higher level of responsibility (either management or senior technical leaders).

Lessons Learned #5

• You can't take your eye off of the ball!

Data Interpretation
You have a lot of good data that tells you something, but no one else will believe the bad news—this situation is all to typical of organizations just starting to use data in decision making (or the first time a new set of data is used). The natural tendency for optimists, or projects that are boxed into a delivery date, is to (pick one)

• Ignore the data
• Reinterpret the data (rationalization)
• Use the data

I've seen people go through all three choices, in order. The first time the data is ignored, because if it were valid, the project would be in trouble, and we can't have that outcome, right? The next time, people know the data is probably good, but in order to meet the schedule, the data is interpreted in a favorable light (as in, "Yes, the defect rate is high, but I choose to interpret that as meaning the early defect removal activities were highly successful, so fewer are left in the remaining test stages"). Now, if the assumption is provably correct, this may be okay. However, if there is no basis for assuming greater success in the early stages, this can be a fatal assumption. When this happens, ask "what specific steps did we take to improve the early stage defect removal? What data indicates we can believe this?" I always add, to myself most of the time, "...other than wishful thinking."

Lessons Learned #6

• You needed training, why not those around you?

Can This Company Be Saved?
Then you run into the real PHMs. I was doing a three-day baseline process assessment. Everyone was cooperating, and we detected a level of enthusiasm among the participants, sort of a "Maybe we can really resolve some problems and improve the way we do business" attitude among the project managers and technical people we were interviewing. We had a final feedback session with the senior manager at 4 p.m. on the third day. He arrived at 4:05 and said, "I have to go to a meeting at 4:30. Can we get this done in ½ hour." (Note this was not a question). You could almost see the people in the room slump in their chairs. Needless to say, this organization never made any progress. (I tracked them on the stock exchange and they fell to ? of their value well before the March 2000 collapse.) Now there may have been a valid reason for the senior manager's early departure (an urgent and unplanned meeting with a key customer comes to mind), but why didn't he say so? Without the reason for leaving early, the rest of the people who had participated in the assessment felt let down.

Lessons Learned #7

• Know when to hold 'em, and know when to fold 'em!

Summary
There is a very important point to be made here. The "leave and find a better company or boss" approach to solving the problem just doesn't work very well. Yes, there are some managers in the Lesson 7 category, but the majority fall into the other categories (other than 1), and if you switch companies you are likely to fall into a similar situation. I think if we are to succeed as change agents or improvement agents, we need to recognize the limits of the situation we are in. As often as not, we need to do a better job of tying our ideas for improvement to the business needs of the organization. In most cases it will involve educating those we work with to understand the true value of efficient and effective processes, methods, and practices. Learning to manage with data is not easy, for both technical and culture reasons. Other than the cases where senior management poisons the well, it is up to us as professionals to find a way to sell our ideas, train the rest of the organization, and be sure that at all times we are in alignment with business needs.