Speaking Process Improvement to Your Management


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).

About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.