Is the Grass Greener on the Other Side of the Fence?

disincentive to change and assume a risk that cannot be quantified beforehand. He went on to say that many of these bright ideas, while good, did not fully appreciate the business environment and constraints placed on him. All too often the benefits were overly optimistic and the costs to implement the change were understated-a typical failing of the bright ideas from his smart technical people.

Some other lessons I've learned along the way:

Lesson Learned #1

• Do not underestimate cost, do not overestimate returns, and be sure to consider the business drivers that are limiting your boss's freedom of action.

The Problem Saturation Index (PSI)

A number of years after learning Lesson #1, I was introduced to the Problem Saturation Index. I was at lunch with a group of friends bemoaning the boss's unwillingness to embark on an inspection program in spite of a logical and conservative proposal. "After all," I thought, "everyone knows inspections are a winner in a high-tech, high-quality product development, such as satellite control systems."

One member of the group said, "Ed, you don't understand! You are solving a problem that will occur two years from now--management is saturated with today's problems." Realizing this was the case and that the organization's culture was to empower individuals to solve problems, I took the approach of finding a project manager willing to try inspections. I trained the team, and we inspected a complete set of requirements documented in use cases. Along the way we discovered the need for standards for the use cases. When we finished, we had a useable set of use case standards that could be used by the rest of the organization, a much higher-quality requirements document, and significant savings in time and money. This was because several of the problems would have escaped through design and implementation and been discovered in the integration test stage or later. The latter point was critical because the product was to be subcontracted from the requirements document and it was unlikely the subcontractor would have had the overall systems view to recognize these problems.

The development team later presented the results at a brown bag lunch, where the afore-mentioned boss was present. He declared that inspections would be a best practice, remarking "pay me now or pay me later."

Lessons Learned #2-#4

• Present solutions, not problems when faced with PSI.
• The solutions should be actual experiments or pilots with data.
• Have the development team members present the results. They did the work; let them explain it. The results will have greater credibility.

Which Way Is the Wind Blowing?

Occasionally you will run into a manager who seems to have lost his compass. He will do whatever he is told by his boss, ignoring past experience that would tell him to at least protest mildly at the direction given.

I was approached by several development team members who complained they were being told to remove code inspections from the project plan because there "wasn't enough time to inspect all the code." It was interesting that years before, this manager was an early adopter of inspections, albeit at the direction of his boss. She was one of the rare "initiates change" managers at the far right side of the curve. His current boss was unconvinced of the value of inspections in the development environment, and saw no reason to "waste" time and delay the start of testing. (One might ask, if you do not need to inspect, then you do not need to test either, but then the senior PHMs might accept that proposal!)

What we proposed was to inspect