Updated: May 25
Start with why. While this seems obvious, this is not necessarily where we start. Establish why you need to review or implement a new process. Simon Sinek's book has inspired many people to start with why. The same principles are valid to process design. Check out this article.
Be very clear about the problem. Although very similar to "start with why", knowing the problem is slightly different. You need to be sure that the process design is going to be fit for purpose - that is, solve the problem. Talk to everyone. Different stakeholders will see a problem differently. Do not make any assumptions. Be wary of symptoms distracting you from the underlying problem. Defining the problem is extremely important to process design.
Ensure you know who the decision makers are - governance is important in any process design. In some cases, the process needs to meet compliance obligations. For example, the trades. As the process designer, know who will be responsible for final sign-off. They need to trust the process. Ultimately, they will be responsible for the success (or otherwise) of the process. They need to ensure it is consistent with the business's practices and goals, and that it is fit for purpose - including any compliance obligations.
Define the situation. Consider why now? What has lead to this process design requirement? Like defining the problem, this information will fill some gaps to avoid you making assumptions. Ask lots of questions to ensure you fully understand the situation.
Who will use the process? Too often it is not the users who are designing the process. Be sure to talk to the end-users of the process. When reviewing a process, this is easy. There are always users who will tell you what is wrong with the process - remember though that this information might be the symptoms. When introducing a new process, the users need to be involved in the journey. Good communication ensures users understand why the gold-plated version is not possible ...yet!
Other stakeholders. Think about the end to end use of the process. Although the process might be for internal use, are the external customers going to be affected? Maybe a shorter lead time or a better value product is worth bragging about. Therefore, maybe, the customers should be included in the communication plan. Practically anyone in a business, or the user of the business's services or products, is a stakeholder. Although impractical to speak to them all, all stakeholders should be considered in any process design.
Consider implementation. Any change to processes is disruptive and people are generally resistant to change. Therefore, implementation needs to be planned for. Although not naturally part of the process design, successful implementation will have a huge impact on the final success of the new process.
Apply the KISS principle - an oldie but a goody. Pare everything down. Keep the process, the documentation, the plan ... everything, simple. When processes become over-complicated, they will not be followed and they will fail.
Record it - test it - refine it. Do the documentation, test the documentation to ensure it reflects the process, then fix the issues found. Do again! Processes should be dynamic; so this will continue post-implementation. Therefore, have systems in place to enable simple process review and documentation for continual improvement.
Continue to ask why. Throughout the design, and for each of the previous tips, ask why. This tests assumptions. Yours and the process owner's.