A few days back I needed to call the customer service for one of the utilities at home. The call went pleasantly. The representative listened to my issues, tried to resolve or provide me solutions and my problem was solved. I was happy. When I reached home and I opened my emails, I saw an email asking for feedback on the service provided by the representative. Along with the request for the brief survey, a transcript of our telephonic discussion was also provided as a documentary proof of our conversation.
A document is thus a summarization of the ideas that flew across two or more people in different communicating ways. The document lists important information that is mutually agreed upon and also the action items if any. The document is therefore the knowledge bits that may be required for a task. The document serves as a reference point for anyone using it for a task. The document also serves as a knowledge bank for anyone who reads it. This helps particularly in the customer service scenario where different people might be accessing your case. Thus all the knowledge of the people and the process is imbibed in the document.
At the heart of the documenting process, is the thought of “incomplete truth”. In certain scenarios this could be misconstrued as untruth. Hence the document serves as the proof of what happened or what was discussed upon. The delivery is measured upon the compliance to the document. What if the document was written incorrectly? What if the document is incomplete? What if the author or the content provider omitted something? How valid is this proof? The document is a capture of the oral or written communication. How about the clues visible to the eye, perception and intuitiveness? Where do they figure?
Looking from the IT sector perspective, where I belong, many IT professionals are good at what they do – development or support. But not equally good at documenting. This leads to the many issues faced in IT projects. The requirements document, design document, test document all may tell a different story from what was captured in the minds of the team themselves. At the end, the project and the team’s success is measured on the parameters provided in the documents. We know that the documents may not reflect the complete picture (an inherent problem), moreover the documents loose value over time when the requirements may have changed or alternate systems may have been assumed.
Documents are a powerful tool. At the same time, sticking by them is like living by the rules. Living by the set of instructions which define black and white and leave no place for different shade of grey. In the Indian context, this reminds me of Bhishma in Mahabharata who took an oath for a noble cause and stuck by it, even when the beneficiaries changed. Ultimately, his noble oath became a curse for the entire mankind.
Comments
Post a Comment