Defining a Process? Use the Six Honest Serving Men
In Process – How to develop one that is not stupid, we looked at how we can develop a process that empowers people to do to their thing and not stand in their way. But how do we actually develop one that can assist us in achieving the above goal? Using the concept of Six Honest serving men, we can define a system for activities that involve more than one person. Some of the following content may overlap with other posts, but that’s because they are all related (or maybe I am too dense to write one that explains all).
Why: As I mentioned in a previous post, without stating clearly why we are doing something, it is pretty difficult to convince people to even read something, forget about following it. The Why is often stated in grand terms, and since people are not stupid, they understand it is just for the sake of having it! Have a simple description of the outcome and why following it will help them (in their daily life and not something like, “It will make the organization compliant with the GRAND THEORY OF NOTHING”. Who cares?)
What: What defines the activities that need to be completed to achieve a certain goal. The inputs for this can be based on existing team practices or from best practices in other teams or (God forbid!) from frameworks.
When: When here does not relate to time, but the sequence in which the above activities should be performed.
Who: Code does not get written just because we have defined “Write code”. Someone needs to write it and someone else needs to test it. Mr. Who helps us identify the people to perform the activities in the desired sequence.
Where: This is the easy one. You ask me to enter the bug – fine. Where? You get the idea (please don’t create forms for every small bit of information! Funny one here – http://www.bureauofcommunication.com/compose/romanticintent)
How: This is the most difficult one. If you list out how to do an activity in great detail, your process will be cumbersome and if you don’t give any details, it will not be useful. Err on the less side, since you can always add detail. This is easy to say, but difficult to implement and unfortunately, the answer for how much is, “It depends, at least for me. By the way, do you have any good principles for this? Share with me.
One of the easiest ways to spell out a process is the System flow chart or activity diagram coupled with annotations for inputs/outputs of the process. This makes the process simple, visual and clear.
If you are wondering if this can be used in Agile methods (not using Agile process, in case you are offended. Ha.), the answer is yes. A process is just a structured method of representing what needs to be done and does not mean it needs to be “heavy”; it can be as light as you need. If you come from a process mature organization and want to find out if you can use Agile methods or not, read this interview and then buy the book (disclaimer: I am not affiliated in any way with the author and have not yet read the book completely).
Go on, become a process specialist. May the Force be with you.
Related posts:
[...] previous posts, we have seen how to use the Six Honest Serving Men to define the elements of a process, while keeping it from becoming stupid. In the latter, one of [...]
GovernIT » Blog Archive » Practitioner-led Process Improvement:For “sticky” processes
16 Dec 10 at 2:38 pm
[...] the necessary steps to see that you are not defining a stupid process and provided guidance on how to define processes. It still failed, sob. Once you have gotten over it, read [...]
Common Mistakes in Process Improvement Initiatives
22 Dec 10 at 12:38 pm