Process writing guidelines

Take the Improve your process mapping course in Nintex University.

• Best Practice Technique 1- System Guides.pdf
• Best Practice Technique 2 - Chunking.pdf
• Best Practice Technique 3 - Poorly Written.pdf
• Best Practice Technique 4 - Overly Complex Diagram.pdf
• Best Practice Technique 5 - Replacing a decision flow chart with a Conditional Matrix.pdf

• Document the steps that "normally" occur when running a process. For example, the steps that are typically performed 80% of the time. We recommend against including every variation/exception as a process step because it results in an overly complex process that becomes difficult to comprehend.

• Ask yourself "Is this step normally performed?". If not it is a variation or exception.

• Use notes to describe how to handle variations or exceptions in your processes.

• Make the note title a question. This allows the person viewing the process to ignore the note content if they know the answer to the question.

• Read this Nintex Community blog: Managing process exceptions in Nintex Process Manager.

• Create separate processes to reduce complexity and ensure process information is more relevant for your Nintex Process Manager users.
• Recognise when you have multiple ways of performing the same process and document as separate processes. For example, split the Recruit Staff process into three processes:
  • Hire Temps
  • Hire Contractors
  • Hire Full Time Staff

• Group tasks to identify the major activities A numbered step in the process consisting of a sequence of tasks. An activity is a major step in the process. of your process.
• Limit the number of activities to 10 for each process.
• Identify tasks that are performed at the same time or by the same role as a mechanism to group.

• Break long processes into smaller, more manageable sub-processes. For example, the Recruit New Staff Member process can be broken into three sub-processes:
  • Obtain Approval to Recruit
  • Advertise Position
  • Select Candidate
• Use Process Links and Process Overviews to link your sub-processes together to provide a view of the mega or end to end process.

• Start all process names, activity and task descriptions with a verb. Verbs are "action" words and processes are all about providing instructions on "how to do an activity".
• Ask yourself "What is the person expected to do?" when reviewing your processes to test if you have applied the verb first rule.

• Use 'if required', 'if needed', 'if appropriate' to identify activities or tasks that are not always performed.
• Supplement any 'if statement' with a note to explain under what circumstances the activity or task would be carried out.
• Ensure the note title is always a question. This allows the person viewing the process to ignore the note content if they know the answer to the question.

• Use documents or guides to reduce the complexity or detail shown in the Process Map. Detailed instructions on how to use a software application is useful when learning the job but will not often be referred to once the job is learnt.

• Attach documents/guides to the relevant activity step. For example, if you have an activity Create Sales Order, you can attach a system guide called Enter Sales Order - instead of including step by step details in the process.

• If something is not being done correctly then make sure that item is given the right prominence in your process so that it is done correctly.

• Promote a task to an activity if it's important and not currently being done or not being done correctly.

• Promote a business rule within a guide to a note or task if it's important and not currently being done or not being done correctly.

• We coach on decisions as part of implementation training. You can insert a decision diamond into a process but we recommend reserving this for critical decision points that impact your overall flow. The decision can either lead to another process, or a single alternate activity that terminates the process.
• For low level decisions that do not impact the core process flow (for example, What if it’s a weekend? What if it’s an Executive Manager we are hiring?), we recommend capturing these as notes within a process, or using other mechanisms such as inserting a matrix for a decision chart.
• To be useful to your business team, your ideal is to capture a process flow of how you’d like it to go 90% of the time (a flow of activities to deliver an output).
• What we find is that process writers can fall into the trap of adding decisions for the sake of it. For example, if your legal team needs to approve every step of the process, decision diamonds reflecting those approvals do not aid the reader of the process. In a situation like this, our recommendation is to build lawyer approval into the core process, making it an activity step, not a decision.

Consider who you are writing the process for (audience), why you are writing it (purpose), and don’t document everything. Only document the details which will add value. Also make an assumption that a person reading the process has a level of competency applicable to anyone employed in that role.

Yes. We recommend a maximum of 10 activities on a single process map and around 10 tasks or notes per activity.

• The level of detail or complexity and whether the steps are shared by a number of different processes.
• Do not create a process for something that only has a couple of steps.
• If activities are shared across processes then creating a sub-process for these steps allows the same content to be linked to multiple processes.

• Use notes to document exceptions or variations to your process. For example, conditions that occur less than 20% of the time.
• Use parallel activities to document either/or conditions. For example, 50:50 scenarios or conditions that happen simultaneously.
• Ask yourself, "how often does this occur to determine if the scenario is an exception", either/or, or simultaneous scenario.

Do one of the following:

1. Use ‘if statements’ within a single activity.
Example: 

a) Contact Support to resolve issue, if appropriate:

• Contact on 09 9812345 quoting customer number 123806.
• Provide details and priority of issue.

b) Assign to next available technician, if appropriate. Assign issue in Help Desk system to next available technician.

• Note: When should Support be contacted?

• Note details: If initial diagnosis has revealed that the Help Desk Technician cannot resolve issue.

2. Use parallel activities

The volume of steps required to carry out each of the steps: Contact Support or Assign to next available technician determines if approach (i) or (ii) should be used.

The level of detail or complexity and whether the steps are shared by a number of different processes determines whether you should use processes vs. activities. There is no point creating a process for something that only has a couple of steps, but equally if activities are shared across processes then creating a sub-process for these steps allows the same content to be linked to multiple processes.

If it is important that the process related to the exception is carried out correctly, then use a conditional process link to make it prominent on your process map. If the exception is a minor exception then embed the process link within a note.