Chapter 4: How to Write a Process – ISO19770-1:2012 SAM Process Guidance: A kick-start to your SAM programme

CHAPTER 4: HOW TO WRITE A PROCESS

For those starting out in the world of SAM, who might have been foxed by the thought of writing their own processes, I thought it would be a useful exercise to offer some tips and tricks I have picked up.

  • Start with a really simple title: The simpler the title, the easier it will be to convey why the process exists.
  • List the objectives of the process: Consider what you want the process to achieve.
  • Identify the stakeholders: At some point you will need other people’s buy-in for this process to become BAU, so know who you need to go to, to achieve this.
  • Identify the systems: Understand which systems are used within the process.
  • Identify any supporting documentation: Imagine someone was coming to the process for the first time, would it be reasonable to expect them to achieve a step within that process without a key piece of knowledge?
  • Identify data requirements: What data are required to complete a function step within that process?
  • Consider quality controls: What checks and balances are in place to ensure that the process meets the objectives and thereby supports the business?
  • Exception handling: What happens if things go wrong? Modelling a recovery route within the process demonstrates that you have thought about the process being applied in the real world.
  • Understand the context: Will the process modelled be a project activity, BAU, or both? Stipulate the scenario and consider modelling separate processes for every instance to avoid confusion.
  • Gain buy-in: The earlier in the cycle this can be achieved, the better. This reduces culture shock when the new process is introduced, and it will also allow for suggestions around possible improvements to the original draft.
  • Model: If you can use a framework or methodology that offers a pictorial representation of the process, then many people will gain an easier grasp of the objectives, than if they were asked to read through many pages of text. Equally, some processes are quite involved, and so you may not be able to escape writing supporting text.
  • Test: You should be able to walk through the process (in the manner of the clipboard monitors of days of old) to ensure that upper and lower limits of acceptable behaviour (i.e. metrics) are not exceeded.
  • Periodically review: Change is the one constant in life; people, systems and the business the process was written for all change over time – don’t be afraid to review a process on an annual basis to ensure that:
    • what’s expected by the business is still being delivered
    • the process is being adhered to
    • the staff required to run the process are suitably trained to complete the process.

Finally, I would add that processes do not exist in isolation, so, as a final exercise, try to understand where and how all the processes jigsaw together to form part of a larger system. An overall process map aids with scope definition, and should also help to prevent project overrun.