How detailed should a map be?
How useful would google maps be if it only showed countries?
Not very, I would suggest!
We have been spoiled in recent years by tools such as Satnav, GPS and now standard apps on your phone that can show multiple levels of detail down to when to change lanes on the motorway and right up to how long until you reach your destination. You get an annoying person interrupting your thought telling you to turn left in 80m if you forget to turn the sound off.
A drive from town A to town B starts with the first turn out of your driveway. You need to know if you should go left, right or straight ahead (if that option doesn’t result in an insurance claim and angry neighbours). So, a map of the country, region or even a city is not going to be very helpful except for answering generic questions such as how far?
Yet, when we create maps of our organisational processes, we have the big picture but often the detail is what many of us are guilty of missing!
Similarly, much effort is spent in process analysis determining whole tasks, who does them and who should be given the output for the next task to begin. This is the level that managers typically like to be given to understand the process, as it’s in summary form that can answer questions like ‘who’s involved?’ or more likely which of my resources are involved.
Very little attention gets paid to the detail level. This is what I call procedure. There are many different definitions of what this means so to be clear, I define a procedure as the series of steps that one individual conducts on their own without significant pause until it is completed.
It must be pointed out that it is not universally true that the procedure level isn’t covered by organisations. It's hard to imagine medical procedures where sterilisation is done on the fly and left to the best endeavours of those in the operating theatres! However, my experience has been that it is far more the exception in complex service industries and public service organisations. Further, where it is done it is not ‘joined-up’ and certainly doesn’t link back to other factors like policy or risk management.
Why do I say that procedure is so critical I hear you ask? The focus on many organisations when considering process is that it is done for managers to understand what is going on. The procedure is likely to be a whole lot of detail that they don’t know much about and don’t really need to know much about! But for the people executing the task, this is the level they work at and often without the guidance necessary to do it well and usually without the insight into the downstream implications of any carelessness.
Why document procedures then?
1. Common practice — if you do not have an agreed way of doing things at the procedure level you are giving the impression that you do not care how it is done, just telling staff to get the result. Staff need to know that you do care and you don’t want the inevitable inconsistent outcomes and the unintended consequences that arise from it.
2. Decision making* — There is decision making that happens inside a procedure that is otherwise not exposed. For example, there are rules applied to determine a discount or to determine what sales taxes might be due. If you wish to have traceability between policy and where the rules apply you are going to need the detail. For example, imagine a change in the rate of sales tax in a complex organisation with multiple systems it would be difficult to be sure you have identified all of the affected tasks.
3. Customer contacts — In a service design practice where you may wish to investigate contact points with customers (customer journey mapping in particular), you are going to need to know more than what you can get from a customer lane on a diagram. Examples of what else you may need would be the channel (email, face to face, app, phone etc), the standard message content, who delivers the message etc.
4. Policy compliance — Your organisation’s policies are embedded in the rules that govern the decision-making of your staff and systems. If you don’t have this documented and agreed in a procedure then how do you guide your staff to be compliant?
Typically policies are finalised and published on the corporate intranet. These might include information management, privacy, health and safety policies, customer care etc. It is rare in day to operations for only one of these policies to apply at one time and it is also true that only part of a policy will apply for the task at hand. You need something to pull the relevant bits together for staff to not be trapped in a web of irrelevant detail that results in analysis paralysis!
5. Operational risks — Similarly your operational risks are embedded in the manner that your procedures are executed. If you do not have the important steps clearly stated then how can you be sure that the risk is being mitigated? Further, when you are asked by auditors how can you demonstrate that you have taken real steps to deal with the risk? Better to have it documented than to rely on a staff member to talk them through what they do warts and all.
6. IT requirements — If you do not have procedure level documentation then your business analysts will discover a lack of clarity and consistency in how the task is executed. You are effectively playing roulette, gambling that the subject matter expert has the same view as the majority or at least a workable view. The ground is fertile for inaccurate requirements for IT projects and therefore increased costs and failed projects.
7. Training alignment — Without procedure level detail, task training quickly falls to be solely the responsibility of a colleague, who may or may not be an advocate for doing things the correct way.
8. Capability management — the swimlanes on a diagram can give you the broad capabilities required but the necessary detail often rests in the procedure.
So how do we go about it?
The key concern now is who documents this information and who owns it? For me, this should be something worked through between analysts and the process operators.
The analyst’s role is to provide the templates and methodology and critically evaluate the material. They should also be managing the links with policy, risks etc. A good practice is to include a flowchart as it helps clarify understanding and identifies logic gaps very well.
The operator provides knowledge. They need to be empowered to keep this fit for purpose and update as practices change. It is the role of their manager to ensure that this is being done.
The starting point is the process that identifies a task. For every task that a staff member completes there should be a procedure written.
Change issues
There are some common issues that cause resistance in some staff when undertaking the documentation of procedure, such as…
1. The temptation to document every possible exception — This should be avoided as much as possible, as by documenting an exception you legitimise its existence. Better to have the conversation about how to prevent the exception from occurring than complicate everyone’s life by managing multiple variants. N.B. This is also true at the process level. The 80/20 rule is useful to apply here.
2. It constrains us too much — This can be true particularly in the creative industries. Usually, staff are railing against the rules more than the steps. How you can manage this is by focussing on the inputs and outputs, they will vary much less than the steps it takes to transform them from one to the other. Be prepared for the steps in the middle to simply stay unspecified.
You can also consider rules not so much as absolutes but more as normative guidelines. E.g. ‘90% of top ten hits have less than 3 lead guitar tracks’ rather than ‘the song must have less than 3 lead guitar tracks’ (assuming the motivation is to generate hits!).
3. Information is power — Unfortunately, the procedure level is where much of this unfortunate behaviour rears its ugly head. This is where someone does not want to share their knowledge as they believe it to be the thing that makes them indispensable. This needs careful management. One way could be by having someone trusted to shadow the person and document as they go. Other ways that have worked is by putting the person in charge of a special project to document the procedures with colleagues. However, it may take some time and probably needs its own strategy.
What I am not condoning here is over-prescription! If you chain staff down to simply being button pushers then they are discouraged from making sensible decisions and you will end up with a workforce of robots who can only do what they’re programmed for!
But consider the alternative, in the absence of clear direction, staff will infer what should be done with varying levels of success. Who could blame them for getting lost between the 2 cities when they only have a 1992 hard copy map?
*There is a whole practice around decision management. It will be far too soon for an organisation at the beginning of the process management journey. Better to be pragmatic and get the processes structures in order first and then work on the decisions and rules soon after. This should not stop the linking of decisions to policy though.
