Writing your report for readers

As observed, many of you had the difficulty submitting your 1st draft research proposal due to your inability to present and write a logical research questions. As I've mentioned, research is logic. And to be good in logic, you need to be a critical thinker to be good in research.

Anyway, I've presented two important issues for you to think. First, your inability to construct a logical research statements which I doubt if you can learn that in one minute. Development is a process and if you intend to learn logic, you better start it now. Second, you inability to write you thoughts and this is I think critical because your output is your written report.

I will have to cling and discuss more of writing your report technically for technical and non-technical readers. Often, you are misguided with the difference between feature and technical writing. What I asked you to write is the technical report and not a feature report. Most of you submitted the latter.

Good technical reports don't just happen. They are "designed". Their design may be learned and that knowledge can be applied in your everyday work in the same way as you apply your other technical skills. We cannot all be William Shakespeare or Ernest Hemingway, but it is possible to acquire enough writing skill to write simple, declarative sentences and readable reports. Subjects you know about, you can also learn to write about. That is the reason why you have to take major subjects prior to writing your thesis.

The first step that you need to take to be an effective technical writer is to know your audience. In our case, some of your would-be panelists are not directly related to HRM which means that they are not technically knowledgeable in your reseach topic. And so, you must artistically translate the technical terms and statements in simple and declarative sentences.

One of your tasks, as technical writer, is to provide whatever information may be missing so that your readers will understand your message. You have to do some guessing in this because you may not know all of the people who will read your report. If in doubt, it is best to include a little more information rather than a little less. This must be done carefully so that you don't insult your readers by implying that they are more ignorant than they are. In general though, the wider the range of knowledge among your audiences, the more basic information you will need to include.

Each of your readers will use your report in a somewhat different way. For example, the Finance Director needs budget figures so that he knows how your proposal may affect the rest of the organization. A City Councilor will look for the political effects of the plan you propose. A Regulatory Agency reviewer may be expected to look for compliance with existing rules.
For each main audience group, ask yourself how they may use your report. If the subject of the report is at all controversial, then you must also anticipate that some audience members who oppose your plan may attempt to use your report against you. Knowing that in advance is a great advantage and allows you to anticipate that criticism and include answers to those objections in the report.

Most of us have prejudices of some kind or another. If you've worked with your current boss for a long time you probably know some things he/she likes and some things he/she doesn't like. For example, you might know that the boss doesn't like complicated solutions but prefers simpler ideas. Knowing that tells you clearly how you must fashion your report to gain approval. If you have a choice, a simpler solution to the problem is more likely to win favor. If you don't have a choice; i.e., if you can't find a simple solution, then you will want to point that out in the report and explain why you can't present a simple answer to the technical question.

Apart from their personal preferences, each of your readers will have concerns that relate to their jobs. Some are obvious such as, Production Managers, Finance Directors, Regulatory Specialists, etc. Your report must address their concerns if those audience members are in the decision making loop. Ignoring any legitimate concern of this kind will ensure that your report will either not be approved or worse yet, if approved, will not be supported and implemented by some important members of the team.

Finally, it is human nature for each of us to look at any proposal from our own selfish point of view. Many people view change as threatening. Suggestions to change the way things have been done for a long time will almost always meet resistance, especially from those who may have a career interest in keeping things the way they are. Be alert to these feelings as you write your report. Be certain that when you do recommend change that it is really necessary or desirable. If you are convinced that it is, then ask yourself, who will resist it? Then be prepared to offer those who might be opposed some reasons to support the change so that it will be less threatening to them.

No matter how widely varied your audiences' interests are there are two things everyone of them may be expected to understand. These are time and money. Your report must answer these two basic questions for every reader. They should know what your idea will cost and how long will take to accomplish.

So you must analyze your reader. The idea above is simple if you start it now. The next blog I will be discussing is framing a good technical problem. You read it and compare the statements you have submitted.