Posted by: S R Balasubramanian
business case, business-IT alignment, IT plan, IT planning
It was during my school days that I first learnt the importance of good writing as a means of communication. Our English teacher was once distributing answer-sheets of our periodic exams in the class. One of the questions in the paper was of essay-writing. The teacher singled out my paper to explain to the class how an essay needs to be written. I was overwhelmed as I always thought I was poor in English and often used to envy some of my classmates who had rich vocabulary to boast of. The teacher simply said that the key was not about using a flowery language but of simple expression conveying the story to the reader in a way he can understand. I could never forget that advise and that stayed with me ever since.
Experience of the professional world
After a few years of working with two companies I moved into a management consulting firm. I was on my first major assignment and had to submit a proposal to the client. I carried out the fact-finding with great enthusiasm and then compiled the data collected to write out my proposal. The proposal, painstakingly written, was full of expression and analysis and I forwarded to our Director for his approval. The Director later called me over and told me in a polite way that though the proposal was good, he had difficulty comprehending it since he looked from the client’s perspective. He said that the proposal did carry details of the task to be done, the process that I would adopt, and the deliverables, but did not speak of the need for such a work, the purpose to be served, and benefit that would accrue to the organization. It was a knuckle on my head — in short, he told me that the proposal didn’t make sense! Feeling hurt, I sat with my senior colleague to complete the task.
A similar experience with another organization a few years later brought more sense into me. New to the organization, I set out to prepare a comprehensive IT plan for submitting to the management. There was nothing wrong with the effort that I put in or about the technology solutions I envisaged. My final report carried details of system requirements for each function, software to be developed, hardware to be procured and a schedule for implementation. Most of my colleagues agreed with my assessment but our Managing Director did not. He said he could see no connect with the organization’s plans and said that the report did not indicate the purpose it is going to serve. Another knock and I nearly swooned.
I had to understand the art of good writing and went about reading, discussing, and applying what I learnt. I wrote the following guidelines for myself for writing out any report:
- Objective: Always state the objective or the main purpose of the report.
- Context: Explain the background or build up the context so that the reader is able to make out the situation that is being addressed.
- Explain approach: It is important to explain your choice of actions and various options considered for resolution. Your arriving at a conclusion otherwise would not convince the recipient of the report.
- Specify the solution: It is important to be specific and unambiguous on your decision or the final recommendation. What you may do is to suggest and leave the final decision to the person to whom it is forwarded.
- Enumerate advantages: It is good to mention about the likely gains, advantage that may accrue or savings possible and wherever possible quantify them.
- Conclusion: End up stating clearly the action that you expect. It could be seeking approval, wanting to inform, putting the matter for debate or justifying your stand but it is important not to leave the report open ended.
Did it work?
Yes, it did. In subsequent years, I was lucky to have most of recommendations accepted without too much of a debate or with very few objections. In fact, many of my other colleagues in other functions wondered what steps I had employed “to please my bosses”. I was happy to have learnt something which I could use.