During my time in IT Service Management I’ve read my fair share of process and policy documentation. In fact, I think I’ve had the misfortune to read more than my fair share.
Process documentation is important, don’t get me wrong. Without someone taking the time to write down the intention, expected steps, outcome and quality checks within a module of work you don’t really have a process at all.
I was having a conversation this week with someone that was sure they had a process for something. It transpired that what they had was an unwritten set of best practices that everyone understood and followed. The outcome was actually fairly good and repeatable but by no sensible definition was this a process.
In fact the moment of realisation came when I asked if the best practices had changed over time. Of course they had as the team had learned and improved itself. But without proper documentation outlining the new steps to take nothing was truly repeatable. There was no real process.
Lean Process Documentation?
So, I am an advocate of writing documentation to support a process. But does it have to be so verbose, heavy in language, formal… and lets be honest. Boring?
Lean principles teach us how to identify “waste”. Any more than the responsible minimum is waste. Do we actually need to include difficult to read text in our process documentation? If they don’t add value to the reader surely they are wasteful and can be removed?
There are some practices that I use in my role in product development that I think would be really useful to IT Service Management professionals that are willing to take a fresh look at their process documentation.
User Personas in Action
A user persona is a method of representing an individual that is involved in a process. For example in your Change Management process you will have a number of different people to think about:
- The person requesting the change
- The person that peer reviews
- The approver
- The person implementing the change
- The person who does a post implementation review
Each of these people have different requirements, concerns and objectives when working within the Change Management process. Does your process documentation accurately represent these people?
Each user persona should fit on a single side of A4 – An example, ‘Angie – Change Manager’ is below.
User personas represent real people within the process and I’d recommend using photos of your actual users. It’s a powerful thing in design meetings to have a set of personas pinned up on the wall and to actually see the faces of the people you are making decisions on behalf of.
Each persona has a short summary and then four sections.
- What she’s thinking
- What she’s hearing
- What she’s saying
- What she’s doing
The sections show the users concerns (“thinking”), the conversations that other people would start with her (“hearing”), the conversations she would start with others (“saying”) and her day-to- day actions within the process.
A persona should be a “caricature” of the different people that act the part within your process. You might seek out these people and interview them to discover what they are thinking, saying, hearing and doing. If you interview 4 different Change Managers and discover that they all have different concerns your “Angie the Change Persona” would be a representation of a person that has ALL of the concerns. You are aiming to discover the extreme points of view that these people exhibit and document them.
We try and use personas throughout our product development process – when we design a process defining these is a critical early step and we rely on them during Acceptance Testing to ensure we are getting feedback from all people.
A few months ago I mentioned personas in the Back2ITSM Facebook group and got a good response. As a community resource I’d love to see a set of User Personas that cover all the roles in common ITSM processes. Imagine knowing that you need to write a new process for Configuration Management. Heading over to Back2ITSM to download a set of user personas for each role in the process would be a huge head start.
I’d love to see process documentation move away from mimicking legal documents with reams of dense text and move towards a more user centric representation of users requirements and concerns.
After all – your process affects real people. Lets find out who they are at the design stage and make the process more suitable for their needs.