What level of details to include in a procedure
By ITIL from Experience ©
When writing a procedure1 it is sometimes difficult to determine the level of details to include. Some might be tempted to add step-by-step instructions with screen captures like a user guide (see What is another term for User).
The problem with adding too much detail is that it takes more time and effort to develop and test. It is also more expansive to maintain. Every time the technology, policies or business rules used to execute the process2 changes, more effort is required to validate or update that procedure. More importantly, too many details mean that experienced people will be tempted to skip it all together and run the risk of forgetting a critical step that was buried in the details. The opposite also has its drawback; without enough details the user might not know how to complete it.
Defining the target audience for the procedure ensures that it has just the right level of details, not too much, or too little. Ideally the procedure should specify what and who it is for. This can easily be done by mentioning in the introduction who the procedure is for. Thus, this assumes that the individual has a certain level of skills.
For example, a statement in the introduction that "This procedure is for the system administrators to create a user group" is all that suffice. Alternatively, adding a section to the procedure titled "Audience for this Procedure" also works well. Thus, one can assume that the system administrator has basic skills and knowledge of that system to create a user group. Therefore, the procedure may look like:
- Create a user group using the following naming convention:
o ...
- On the advanced tab, set the following parameters:
o ...
- Reassign the request to the Service Desk
As such, there is no need to specify:
- Press CTRL-ALT-DELETE
- Type the Administrator login name
- Press Tab or click in the Password field (see the Secured password manager for the password)
- Type the password and click OK
- etc.
However, when people who use the procedure have limited experience with the system, the system is new, or when they do not perform these actions often (like an upgrade every few years) the work instructions3
need more details.
The same goes if the procedure is part of a Business Continuity Plan. The level of details needs to be prescriptive since untrained users may be performing the procedure.
In conclusion, determine the purpose of the procedure and who will be using it. Also, ask someone from that audience to review and test it to ensure that they have the necessary details to execute it successfully.
Thus, unless details are required by your audience, less is better. Focus on the critical steps so that it can be used as a check list and guidance to ensure that nothing was forgotten. To paraphrase Einstein: “Everything should be made as simple as possible, but no simpler.”4
Last updated on: 2019-05-04
Published on: 2013-03-06
"Good process design does to diagram all work instructions in a flowchart. That's what work instructions are for." Denis Matte
Related:
- Why spend effort documenting processes
- Should a process change go to the CAB
- Should we use a method like BPMN to document our processes
- Should we wait for the reorg before improving our processes
- How to explain that following a process does not cause delays
Category:
Implementation > Process
Copyright 2013-2019 - ITIL® from Experience - D.Matte
<HR>