Make Your Point ... Without Pointing a Finger

development did. Our request for buying our own server had been denied by the CFO and our plea for a partition on development's server had been denied by the R&D VP. We literally could not have tested it even if we had tried. So, we had a veritable shooting gallery of villains, and behind closed doors I made sure that the Sales VP knew it.

But in public, at the cross-functional meeting, we mentioned none of this. What we said was that we understood the importance of testing configurations and truly regretted the problem. However, we were also aware of the need to stay within schedule and budget, and testing each configuration took about three days. So we proposed to publish the configurations we planned to test and those that we did not, and elicit input from the team to be sure we were focusing on the right ones.

The beauty of this approach was that it drew attention to the fact that we could not possibly test all the configurations. When we distributed the matrix of every potential combination of database, server, and operating system version (there were hundreds), it blew everyone away. Suddenly they were more sympathetic. Furthermore, it imposed reality: if someone insisted that we add a new configuration, we agreed to, but it meant we would either have to take another off, or add three days to the schedule, or add more resources. Their choice.

Example 2
More recently, a colleague related a similar strategy. A problem related to interfaces had caused serious problems in another department, and so his manager was especially irritated at being called on the carpet by a peer. He humbly took responsibility and told his boss that he would work with the other department to be sure it never happened again.

So he printed out his test case inventory of more than 3,000 different scenarios, then scheduled a meeting with the manager of the other department. At the meeting he produced his test cases (several heavy binders), flipped through them to the section dealing with the relevant interfaces, explained carefully what was being tested, and asked for input on how to improve the process.

The other manager was impressed and somewhat intimidated, and eventually confessed that the problem was really on his end for not testing the incoming files. My friend now had a new fan and supporter because he did not run back to his boss claiming exoneration. He let the other manager tell his boss that he was doing a great job and that they had worked through the issue. Everyone saved face.

The lesson here is to remember that people are more important than problems. You can make your point without pointing a finger. And remember that the real challenge is not explaining the last issue, it is preventing the next one.