This is the part I like the most about writing procedures. It involves walking around and getting to know those who work with the actual procedure and know how it works ‘warts and all’.
The Tale of the Information Gathering Phase
One of the mistakes many writers make is to work at their PC and assume that the knowledge they need will come to them. All they have to do is send out some emails, right?
Not really. You need to get out and make connections with people. Once they can put a ‘name to the face’, it gets easier to arrange meetings. You’re not a stranger anymore. They know who you are and why this project means so much to you.
Also, by going to their desk, you’re showing that you’re making the effort to reach out to them. It’s also harder to say No to a person when they are in front of you. Deleting emails is a lot easier.
What Information Are You Gathering?
Let’s think about this for a second. The end goal is to be able to:
- Document how the process works
- Understand where and how it interacts with other processes
- Examine where it can be improved
- Share this information with everyone on the team
To get to that point you have to do a Sherlock Holmes.
Do a Sherlock Holmes?
What I mean is you need to look at this procedure as neutrally as possible. Think of yourself looking for clues, trying to find information that will explain exactly how the process works.
Many business analysts, maybe new to this field, think they know how a process works after a quick assessment. When they get into how it works – and when eagle-eyed team members review the first draft – it becomes clear that the process needs to be re-examined.
To recap: the information gathering phase is where you go out and collect all the information you need to prepare the procedures.
Shouldn’t it be obvious what you need to capture?
Not really. If you ask ten people how to get from your house to the city centre, they’ll all give you different routes. Everyone knows different shortcuts, different schedules, and better ways to get from A to B.
It’s the same with writing procedures and work instructions.
You don’t write Procedures in a vacuum. Meet up with other people and ask them how the procedure works. Let’s say, as an example, that you’re writing procedures for a bank. You want to know how mortgages applications are processed.
This process will typically involve numerous activities, all handled by different people, many of which are performed by different functions and disparate IT systems.
To capture each step in the process means sitting down with those who understand each task.
There are two parts involved in capturing how a process works.
- Capture the As Is Process – The first is to ‘photograph’ how the actual process works. This is often called the ‘as-is’ process. In other words, you’re aim is to capture exactly how the process works, warts and all. You’re not concerned with finding faults, looking for improvements, or exploring alternative options. The as-is process shows how the process works, just as a photograph would.
- Define the To Be Process – The second is the ‘to-be’ process. This involves looking at alternative ways of performing the process and different contingencies you can take if/when a specific action occurred. Exploring the to-be process is often called process redesign or process reengineering.
However, to get to this point, you need to understand the ‘as-is’ process very clearly.
If you start the second step without going through the first, you’re likely to make assumptions or overlook factors that will undermine the accuracy of the process.
How to get started?
You can speed things along by arranging workshops with the necessary subject matter experts. It’s unlikely that all will be able to attend; don’t worry. Get as many into the workshop as possible and go through the processes.
Make sure you have:
- Overhead projectors and
- Writing materials
If necessary, arrange for lunch to be delivered as this will give you more time with the attendees, instead of them splitting up for lunch. I’ve seen people go for lunch and not return for the afternoon session; do your best to keep them in the room. You mightn’t get a second chance.
If possible, get another team member to make notes as you’re running the workshop. You can compile these notes the next day and then circulate them to the attendees for their review.
Tip: Try to capture things while they are still fresh in your memory. If you leave it until tomorrow, you’re likely to forget large chunks of what you’ve heard. Give yourself an extra hour after the session to write up your notes.
What other suggestions do you have for this phase? What’s the best way to get information from those who are reluctant to share information? Why do you think they hold the information back?