Seeing Igor’s work got me thinking about how I do operational review presentations and the purpose of them. The way I see it, the purpose of the operational review is to analyze the inner workings and activities of a department or functional area with the purpose of identifying problems and potential improvements.
This is all well and good but the problem here is that at executive and board level only few people have (and should imho have) complete domain knowledge. This means the presenter will be presenting a specific view port into the problem domain and is forced to translate the specifics into commonly understandable terms.
So the tradeoff becomes presenting a too high level view that everybody understands but does not facilitate the identification of improvements or presenting a too detailed view that isn’t understood and causes unnecessary concern and pushes focus towards the KPI’s instead of their meaning.
In addition to the overall purpose of the review I find that the good ones also serve the following purposes:
- Provide executives with an overview of the past and planned operations of the department so that they can plan for upcoming cross departmental activities
- Provide knowledge and ensure that planned operations of the reviewed department is in line with the overall company strategic themes
- Identify areas of possible cross departmental synergy (given the above bullet there should be plenty)
- Instill confidence that you know what you’re doing (if that is the case) and that they don’t need to worry about the things you don’t draw their attention to
In summary I tend to stick to these basic rules
- Provide reasonably few metrics that highlight problem areas (I provide 5-10)
- Have the underlying KPI’s for each top level metric ready but don’t show them unless necessary (I try to have additional KPI’s ready in a separate presentation or dive right into the reporting systems)
- Prefer meaningful graphs over tables
- Weird domain specific acronyms that I don’t know, makes me feel like a jerk. I assume this is a general thing so I try to avoid them
- Highlight risks
- Listen! – This is your chance to pick the brains of the most expensive coworkers in your company. Don’t waste the opportunity
- Be exceptionally honest (this is your chance to tell them that the multiple-inheritance multi-apartment threaded COM object based architecture that your architect came up with wont be supported in the next version of windows (btw: the version for which the next release is targeted at))