A couple of days ago I started writing a post whinging about processes that, at least from a user's perspective, appear to be constantly changing. These are often pretty, bureaucratic changes but are exceedingly frustrating for those on the receiving end of the changes.At the same time I was documenting an existing process as part of the day job, and I started thinking about the quality attributes for a process. What makes an effective process?
I know that many folk would argue that there is no such thing as a good process. but for the rest of us here's my list - written from the perspective of a process user (not purely as a process author)...
- Stable - whilst the whole point of continuous improvement is to ensure that processes are kept up to date, there must be a period of bedding down a process before you start changing it. Constantly fiddling with a process, even in the minutiae, irritates and confuses users, and will inevitably lead to some kind of failure before too long as people simply don't know what's right and wrong anymore. Unless a process is shown to be fundamentally wrong (in which case it there should be big questions about how or why it was published in the first place), let a reasonable amount of time pass before updating it. And where processes are cyclical, e.g. monthly, don't make changes every month, especially at the point of execution!
- Complete - there are plenty of great examples of how to document a process, but all too often these are ignored, and valuable or even critical information is missing from the process definition. For example, entry and exit criteria are often missed out, sometimes inputs and outputs are only partially listed. Attention to details gives users confidence in the process
- Understandable - if you document all your processes as essays, don't be surprised if people struggle to follow them. It's also important to get the level of detail right - don't mix up process definitions with work instructions. Few users actually need to read a process end to end if they are already familiar with it. They are more likely to want to find elements within the process like process inputs or specific roles and responsibilities. If using web based descriptions, draw on good user interface guidelines to hide or show levels of information that people can focus on. If your using more traditional document based descriptions, a tabular approach is often a good way to present information.
- Current - people expect to be able to access processes that are up date and relevant for the work they are currently doing. Old, irrelevant processes should be withdrawn and archived if necessary. And publishing process changes is simply not enough - there needs to be communication that processes have changed, and how they have changed
- Usable - in the age of corporate intranets, wikis and even SharePoint, there is no excuse in not making processes easy to find, navigate and access. Libraries of documents are no longer relevant nor desirable as vehicles for users to access information. The best process libraries are those that users can interact with, even to the extent of having processes describes from different user perspectives according to their role or function. More importantly, thing about how the process flows from a user's perspective - something obvious to an author may not be so obvious to a user, especially in the heat of the moment when they are battling against a deadline
- Simple - many working environments are already unnecessarily complex so your processes need to be documented to help remove the complexity as much as possible, They need to be clear and precise, and focused on the people who do the work - they should not attempt to showcase the author's writing talents!
I'm sure there are other attributes that you may want to add to my list - drop me a note or leave a comment and I'll include them in a future post
Posts
