Journals by RSS
Journals by EmailStill somewhat surprised that Vanessa, the project manager, had labeled him a major player in solving the customer’s problems, Henry projected his improved diagram onto the screen. Everyone looked at Vanessa.
“Henry, will you explain the diagram, and then we can go through each situation and find out whether the right things are happening.”
Henry hadn’t expected to guide the discussion, but he talked through the diagram. Then he began going through each relationship and explaining the effects of the relationship on the reports that the users were generating using the software.
As they went, the customer identified where things were happening correctly and where something needed to change. Vanessa kept track of action items, and since they uncovered a couple of inaccuracies, Henry took note of where he needed to make changes. Vanessa then asked Henry to create a version of the diagram that represented what should be happening in the software as if it already was. The development team could take that version and begin creating and assigning tasks.
When the meeting was over, Henry couldn’t help but experience some relief. The spotlight had been moved elsewhere. His original documentation on the software had contained a couple of errors, and he would fix them, of course. It was possible that the number of questions and problems coming back to the customer stemmed from those errors. But this possible communication problem had exposed a programming problem. And Henry, being the professional communicator on the team, had taken the task of communicating to the customer how the software currently worked, and doing it clearly enough that the customer could make informed decisions. So communication had been the first step to solving the programming problem.
In my experience, a diagram—a method of communication—facilitated a discussion on what needed to be improved about a family of applications and their connected wiring. Most of the current functionality was right, fortunately, or we could have been somewhat embarrassed. The developers need to make just a few minor changes so that the users get the right information in their lists and reports.
Looking back at the process, I’m not sure how I became one of the main participants in the discussion; it may have been that diagramming the applications’ current workings was considered documentation, or similar enough thereto for the tech writer to do a decent job of it. It became a sign to me, though, that it’s possible for the technical communicator to climb the evolutionary ladder from the person who just documents the product to someone who facilitates the solution of problems.
Related posts (auto-generated):
1 Comment to 'Communication Problem or Programming Problem? (Part 3)'
February 16, 2010
By creating the diagram of how the related programs worked with each other, you became the defacto system analyst, which unofficially made you the “expert” in this scenario.