The following is a guest blog by Tom Molyneux. Tom is a business process consultant at some of the largest enterprises in the world. His experiences in the strategic use of technology give him thoughtful insights into the rapidly changing world we live in. Tom is stepping in while Chris climbs in the Himalaya.
Recently, I’ve been evaluating an enormous number of presentations for a new company initiative. Some have been truly memorable – I’ve learned new things and they still stick with me. Others have been quickly forgotten. What accounts for this difference? There are bookshelves full of books offering to tell us how to create and deliver good presentations and speeches. One of my all time favorites is a short book called Presentation Zen by Garr Reynolds. If you really think about it, the same rules that apply to making a great presentation also apply to describing great process. Here is my shortlist.
Bad presentations lack focus. They try to jam too much information into not enough time. The end result is walking away feeling like you’ve just been forced to drink by a fire hose. Not only is this unpleasant, but, paradoxically, because they give you so much information, you retain almost none. The key to focus, according to Steve Jobs, was “about saying no”. The same holds true with process. How many have had to wade through 40 page process documents filled with background histories, rationales, “fluff”, vaguely related documents, and appendices only to reach the actual process at page 28? Focus is often about deciding what to remove.
Tell a story
I always look for stories in presentations. A good story is far more memorable than the most comprehensive bullet list. A process is really a kind of story – a story of the way something is done. There is a beginning (or trigger), a middle (where things happen), and an end (the outcome). If a process lacks any of these attributes, then it just doesn’t “work”.
Know your audience
The best presentations I listen to are those where the presenter asks me who I am and what I hope to get out of the talk – right at the start. They then tailor their presentation and their language to match these. In other words, the do not simply deliver the same pat presentation to all audiences. The same focus on the audience applies describing process. One of the first questions should be – who is the intended audience? Is it the enterprise architect or systems analyst? If so, something like BPMN, which they will have likely studied, may suit the purpose. If it’s business user – a process owner, a person on the shop floor that needs to perform the job, an auditor, or the division head who owns a number of processes, then something else all together is required. They are going to want process described in a “business-like” way – something that clearly answers what gets done, who is responsible, when do you start, how do you know you’re done.
What do you think are the keys to describing process?