Once again, Henry met with the project leadership; only this time, he was the star of the show. In the last meeting, he had taken the assignment to diagram the relationships that were currently possible to set between two types of objects in the software, as well as the downstream effects of those settings. He had to represent four criteria in a two-dimensional diagram but had a hard time thinking in four dimensions at first.

After some thought and experimenting, he accounted for all four types of variables by combining two of the criteria into one axis, putting the third across the other axis, and explaining the effects at the intersection of row and column. It didn’t look amazing, but it would do the job.

A little timid, Henry projected his laptop screen onto the conference room wall. He glanced around and saw a couple of confused looks.

“Henry, will you talk us through your diagram here?” asked Vanessa.

So he explained the meaning of the diagram and how, using it, someone could predict what the effects would be of setting up a given relationship between the two main types of objects in the system that were causing problems for the customer. The team identified some places where Henry needed to add information, but it was accurate for the most part.

“Let me make sure I’ve got this,” Nick said. “I want to walk through an example.” He talked through his example, and with some help from the rest of the team, he correctly matched it to the intersection of one of the rows and columns.

“Very good,” said George, nodding. “I think this diagram will do the trick. Once you work those changes in, we can show it to the customer.”

“And have him tell us where things should happen differently,” added Vanessa. “I think we have it mostly right, but there are going to be some enhancement requests coming out of our conversation with the customer.” She looked around the room. “I don’t think everyone here needs to meet with the customer. Who are our major players?”

“Well, you should be there,” replied George with a smile.

“Yes, I plan to be there,” Vanessa said. “George, you ought to be there as well. You know more about the data model than anyone. Henry needs to be there too.” She looked around. “I think that will do it. I’ll set up that meeting. In the meantime, Henry, please update the diagram and send it back out to us.”

Henry nodded and disconnected his laptop from the projector as the meeting broke up. He was a little surprised to be considered a “major player” in this process. But it was probably as much a communication problem as a programming problem. Communicating the current wiring of the system accurately was essential so that the customer would have the information he needed to be able to tell them how they could relieve the problems that were occuring.

Admittedly, I was a bit nervous to show a diagram that I thought was a bit ugly to a leadership team, including a couple of business analysts, who are generally adept at creating diagrams. But after we ran through some examples as a group and the diagram held up (with some gaps needing to be filled in), the team agreed that we could move forward and talk to the customer. I asked one of the business analysts for some advice afterward for improving the appearance of the diagram, and the document turned out looking a lot cleaner.

Just as Henry was in this story, I was a bit surprised to be included in the group of key players (or whatever term the manager used) who would be talking to the customer in the next meeting. I actually was about to open my mouth and say I think I didn’t need to be there, when the program manager said I needed to be there. So I wasn’t going to argue. It was an illustration of the concept that when communication is important in a situation, a professional communicator becomes a key player.

Keep an eye out for Part 3, where we’ll see the results of the communicator being involved in a communication and programming problem.

Related entries (auto-generated):

Communication Problem or Programming Problem? (Part 3)

Communication Problem or Programming Problem? (Part 1)

Technical Communication: The QA of Product Design

Minson’s Theorem of Perceived Value

Four More Reasons Your Company Needs Technical Communicators