I am currently developing a security process reference model. This got me thinking about two important questions that often come up when it comes to process modelling and process documentation:
- Why should you document your processes? Basically, why bother?
- What are the common pitfalls? Basically, why do we fail?
In this post I provide some answers to the second question. See my previous post for the answers to the first question.
Avoiding the pitfalls of process documentation
Most organizations have seen a number of process documentation initiatives over the years. They come and go. Some are more successful than others. Process documentation takes time and resources, so it is a pity if that effort and investment goes to waste. Below are some of the pitfalls and how to avoid them:
- You don’t want to be stuck in detailing every little detail and variant out there. That is why a tiered or layered process model is important. For some processes you simply keep the process flow at a higher level. Only where needed for e.g. consistency, correctness, quality, etc. you document the details. Always take a cost-benefit approach: if there isn’t much benefit in documenting the details, then don’t bother in spending the effort.
- Rely on technical writers and process model experts to do it for you
- Technical writers and process modelling experts whether internal or external (e.g. via consultants) can definitely help you out, kick start a process modelling initiative and ensure quality. However, don’t rely on them do it all for you. First of all they are not your process experts. Your true process experts are sitting in the teams that perform the process activities day in day out. Leaving it all to externals will result in process descriptions that are theoretical and not in line with reality. Secondly, process documentation and modelling is not a one-off activity. Once created, process documentation needs to go into a life cycle where change requests are managed, documentation is periodically reviewed, etc. While externals can help you with the initial design and development, they typically will not be able to support you in your continued documentation lifecycle.
- Assuming everyone can describe their process
- A common response to the previous pitfall is to document all your processes yourself. After all your own people know their own processes the best. However, it is a mistake to think that everybody can document their own processes. While process modelling comes easy to some people, it is not a skill that is commonly available in all people. Indeed, I have seen people having trouble documenting even the simplest of activities they have been involved in themselves for many years. Training doesn’t help much in such cases because the skill is completely missing. The solution will be to find and only use those people that have the skills. You can start with a broad basis, but then gradually only keep those that that have the skill. Adding some internal or external process modelling experts to the mix will further help to speed up the learning process and increase the quality.
- Lack of active governance
- Process documentation has a life cycle; changes need to be managed, periodic reviews must occur, documentation of new processes needs to be initiated, old process documentation needs to be retired, etc. You could leave it up to the process owners to take care of all this. But let’s face it, more often than not, that will be the last thing on their to-do list. Hence, some form of active governance is needed by a dedicated Process Excellence role (or similar). Someone actively reviewing the processes on a daily basis. However, don’t just assign this role to just any process modelling expert. You need a person that combines process modelling skills with in depth knowledge and understanding of the processes in the domain at hand.
- Bureaucratic governance
- While some form of governance is needed, you don’t want to make that governance too complex. It should not take months and endless meetings to update a process to fit what it is probably already a long-time reality. In my personal experience, the trick has often been to assign and empower a dedicated Process Excellence role (or similar). A person who is sufficiently empowered to analyse the nature and impact of change requests and approve the bulk of the lower impact changes together with the process owner. Whereby higher management and potential process stakeholders – e.g. Privacy, Legal, Quality, Integrity & Compliance, Internal Control – only get involved if and where needed.
Feel free to comment on this post or contact me if you are interested to know more.