Now that we’ve gone over the scope, the owners and the stakeholders. It’s time to get down to the main event. The process itself. This article will list a few of the things to take into consideration in the process write-up itself.

If you’ve missed our previous posts find a small recap of the different elements below.

• The importance of processes
• The Scope;
• Who owns the process;
• Who does the process affect;
• The process itself;
• A visual representation including it’s expected inputs and outputs;
• Roles and responsibilities at each step of the process;
• Any risks the process introduces or mitigates;
• How will the process be enforced.

The Commandments

And the god of processes lay down the following 10 commandments…..

1. Thou shalt involve all main stakeholders
2. Thou shalt carry out multiple iterations
3. Thou shalt have the wisdom to know that not all input is valid input.
4. The person least affected by the process will want to be the most involved.
5. Most stakeholders will disappear once the difficult questions start being asked.
6. Thou shalt battle the fine line between a process and a how-to.
7. Thou shalt ensure that wherever possible the process steps are supported by tools to track, validate and check.
8. Thou shalt be aware the process improvements may trigger changes in the way operations are carried out.
9. Thou shalt remain calm when after a process has been reviewed ad nauseum and is published, someone suggests a major change.
10. Thou shalt not give up.

I admit, some of these are there for comic relief, but are reflective of what happens in real life.

The 1st and 2nd Commandments

• Thou shalt involve all main stakeholders
• Thou shalt carry out multiple iterations

A chat is required with all stakeholders to understand the salient points of the process from their perspective. .  It is recommended that stakeholders are interviewed separatelyat this point, to avoid bias or louder stakeholders taking over.

For more information on how to identify your stakeholders, please read our post on 4 steps to identifying your Stakeholders.

This method though more effective in terms of information gathering will trigger multiple iterations as the input from one stakeholder will raise questions and clarifications about the input of another stakeholder.

Commandments 3, 4 and 5

• Thou shalt have the wisdom to know that not all input is valid input.
• The person least affected by the process will want to be the most involved.
• Most stakeholders will disappear once the difficult questions start being asked.

A lot may be said about the process and surrounding processes when interviewing stakeholders but that doesn’t mean that all of it is relevant. Always keep the defined Process Scope in mind. The process analyst needs to sift through the information to determine what is relevant and what is not, without missing any important details.

Commandment 4 is mostly there for comic relief but it is quite often that the person most passionate about the process and with the strongest opinions is the one that knows least and is least affected. In such cases cycle back to commandment 3.

At some point the process discussions and clarifications will circle round to the salient questions as to who is responsible and accountable for certain steps. This is were most stakeholders will go AWOL while they contemplate if all those extra steps they requested to be added are really necessary now that they realise that they will have to do them.

Commandment 6

• Thou shalt battle the fine line between a process and a how-to.

This is a hard one. At which point too much detail is too much for the process? It is quite simple as a definition. Anything that describes the flow is the process, whilst anything that describes how to achieve that flow is a user manual.

However reality tends to be a bit less clear cut, especially when you’re introducing new process controls through the use of IT systems and  which button is clicked becomes a crucial step. 

For example, a particular process requires that a request is raised and sent to the manager for approval. So far so good, but I would like that approval to be tracked, so the request is raised through system X, that has a work-flow configured to track it and also to track the approval.

Hence my process would be a lot clearer if I state –‘a request is to be raised within system X is to be sent to the manager by changing the work-flow step to: ‘Awaiting approval’. A little screen shot of the work-flow step in question would also help especially if the process participants are not very familiar with system X.

Whilst we’re at it, should we also include a few lines describing how to raise the request? This is the fine line I’m talking about.

My rule of thumb is: If any clarification or instruction adds more than 2 additional sentences to the process, it needs to go into an instruction manual /how-to and linked to the process instead.

‘a request is to be raised within system X is to be sent to the manager by changing the work-flow step to: ‘Awaiting approval’.

Note: For instructions on how requests are to be raised and managed please refer to the user manual.’

Commandment 7 and 8

• Thou shalt ensure that wherever possible the process steps are supported by tools to track, validate and check.
• Thou shalt be aware that process improvements may trigger changes in the way operations are carried out.

Commandment 7 goes very nicely with the example in commandment 6. If a request is to be raised and approved, there are multiple ways this could be done.

A request can be made verbally, via email, on a printed and signed sheet of paper, or through a ticketing system configured specifically for the purpose.

The process analyst should always consider;  

• How important is this step?
• How much control do we want to have over it?
• Can it be automated?

In an ideal world we’d go for maximum control all the time, however a balance must be reached and the process must be practical,and not so bureaucratic as to slow down the business, whilst on the other hand providing the necessary checks and balances.

If the team in question has always carried this step out by using email and the new process will now dictate that System X is used for better tracking and auditing, this means that there is an operational change, bringing us to Commandment 8.

Having an operational change means additional steps to launching the new process. Such as configuration of system X. Perhaps even procurement of System X. Training of the stakeholders, writing up user instruction manuals etc…

Commandments 9 and 10

• Thou shalt remain calm when after a process has been reviewed ad nauseum and is published, someone suggests a major change.
• Thou shalt not give up.

This is a bit like Murphy’s law – what can go wrong will go wrong. Whilst we are aware that process changes are constant and part of the process improvement cycle, having a change proposed after weeks of discussions and reviews, when the end is in sight, is not exactly my idea of fun.

At the end of the day though, everyone can recognise the importance of a clear and well documented process and even if it takes a bit longer, things will eventually fall into place.

Up next, the inputs and outputs of each process and why it is important to represent them visually,