|
Darn Good RecommendationsJuly 2005 For a few months now we have been talking about findings. The whole reason we write findings is to elicit change—we want the client to implement our recommendation. So your recommendation better be darn good! If you write some soft, unintelligible recommendation, you are blowing your chance to make a difference. You also might be making your life hard down the road. You may have to follow up on your own recommendation and you might find that:
So before you publish your finding, verify that your recommendation is auditable, feasible, and satisfactory. AuditableAsk yourself if your recommendation is something that you can easily follow up on next year. Your goal is to write something up once, have the client implement it, and then never have to write the thing up again. If you have been auditing for a while and have followed up on other people’s recommendations, you have probably experienced a few findings that are hard to work with. Maybe the writer was vague. Maybe the writer never quite got to the point. Maybe the writing was poor and the recommendation paragraph didn’t make any sense. As you may be the unlucky soul who follows up on your own recommendation, do yourself a favor and ask yourself what you would do to verify that the client has actually implemented your recommendation BEFORE you publish your finding. If you can’t easily think of some way to verify the recommendation, rewrite it. FeasibleHere the question is “Will the client ever actually do this?” If the answer is “no”, you aren’t much of a change agent! How do you know if the client will take your recommendation? You let them write it! Your job is to identify the risk. You present the risk to the client and ask them whether they are willing to tolerate the risk. If they are not—or if you are not—then ask them what they can do to mitigate the risk. Your job is not to tell them what to do—only to point out risk and help them mitigate risk. If the client comes up with their own recommendation, they are much more likely to do it. They have bought in to it and it is something they can actually do. I remember my audit office recommending a software upgrade to one of our largest clients year after year after year. The upgrade would have cost hundreds of thousands of dollars and the client didn’t have the money to do it. So every year, we recommended the upgrade and they responded by telling us they couldn’t afford the upgrade. A boring, tedious dance. Finally, we got a new audit manager who didn’t think technology was the answer to everything. Along with the client we found a low-tech, low-cost way to make sure they were doing the right thing. We wrote one finding, they implemented the recommendation in the finding, and we were done with that nagging issue forever! Yeah! SatisfactoryIf the client implements this recommendation, will you be satisfied? Will you be able to leave them alone for the rest of their life about this issue? If not, rethink your approach. Maybe you are just dealing with a symptom of the problem. Maybe you are just taking on a piece of the issue, not the whole thing. Maybe you are being too vague or passive. In developing your findings, start with the recommendation as your first element and then match the other elements up to it. Ask yourself, “What do I want the client to do here?” That becomes your recommendation. The recommendation is the most important element and all the other elements are designed to support it. The recommendation resolves the condition and the cause. For example, if you knew that you would only be happy if the client prepared cash reconciliations every month and these reconciliations were reviewed, your recommendation becomes:
The condition becomes:
The cause becomes:
The finding is almost complete. Now all you have to do is develop an effect and criteria. Easy. ![]() |
|||||||||
|
||||||||||