As Business Analysts, we’ve probably all had to map processes. But the question is ‘did we succeed in what we set out to do?’
Process analysis and its subsequent mapping are seemingly very rudimentary business analysis skills. It is something that a Business Analyst should be able to handle even at a fairly junior level. When we set out to perform process analysis do we really understand what we are trying to get out of it and are we properly prepared to deal with whatever the result?
Thinking back over my time as an analyst I can recall quite a few times where I would be doing process analysis in a fully prepared state, or so I thought, but in hindsight, I was doing little more than conducting meetings and doing even less with the results.
So why would we do process analysis in the first place? To understand the AS IS state is one obvious reason. Another common response would be that it needs to be done as part of a contractual deliverable. But even in the absence if these most basic reasons there are many other good reasons why we should be doing it.
Let’s Visualize our World
Doing process analysis and mapping out the results allows all stakeholders to see the bigger picture, and not just their part of it. Whether they like what they see or not is irrelevant. What is relevant is the fact that the bigger picture stirs up a lot of discussions which leads to the second reason why we do it.
Solve the Problem
All the talking and discussions that result from a process map gets the creative juices flowing and not only helps stakeholders to rethink those processes where they knew they were not doing too well but, more importantly, help them rethink those processes that they thought they were doing great.
Identify Functional Gaps
Potentially the most dangerous reason why we do process analysis. I say this because you have the very real danger of exposing functional gaps in your supporting systems during the analysis process. Hopefully, there is room to close these gaps but there is also the danger that they cannot be closed within the scope of an existing project. I mention that it is potentially dangerous but not exposing such gaps can be even worse.
Once you know why you want, or need, to do process analysis and you understand how to manage the possible outfall the rest is fairly simple.
Know Your Stakeholders
Getting to know your stakeholders means that you have an understanding of how they interact and where they fit into the bigger organization.
People, in general, tend to become set in their ways when they are not actively challenged. Business Analysts are no different so reevaluating your approach and techniques is always a good idea. Sure, the way you have done things in the past worked so don’t fix it if it ain’t broke right? Maybe. But every audience is different and the techniques that you will use needs relatable. Remember that the stakeholders will be (should be) active participants in your analysis process and for somebody to be active they need to be engaged. You cannot engage somebody in something they do not relate to. No matter what techniques you decide on you can improve the efficiency by
Research as an analysis technique is often neglected. Doing research to understand the background of what you are trying to achieve is vital and will give you an important head start. One of the key aspects of facilitating a process analysis workshop is the ability to question everything, but the line of questioning should be aligned with fact. Your research will provide you with these facts. Try to be as unobtrusive as possible when researching and stick to the basics. DO NOT be tempted to skim over something during the workshop sessions because you already KNOW it.
Select a technique that will allow you to be agile. Things can change quickly during a workshop session, and you do not want to be apologizing for spending lots of time fixing or changing something. While a whiteboard allows you to erase or redo anything, it becomes a bit messy when you are at gate 34, and you need to make a change at gate 2. Messy is a fact of life when it comes to process mapping workshops, but it must be a good messy i.e. controlled chaos. I prefer using post-it notes on flip chart pages. Depending on the process I would stick the flip chart page onto a wall and proceed to draw out the process using the post-it notes. The post-it notes allow me to be very agile while the flip chart pages allow me to expand in any direction. While I tend to stick to the more conservative side, the availability of post-it shapes and colours allows you to be very creative.
Stick to techniques that you are comfortable using. Hopefully, as a Business Analyst, you are comfortable in your position as a facilitator but that only gets you to the point where you need to use a technique or tool. Stakeholders can smell blood in the water, especially hostile ones. If you do decide on a technique or tool that you are not 100% comfortable using, then practice until you are. An analysis workshop is not the time to ‘wing’ it.
This is where the rubber meets the road, where all the preparation you have done pays off. You did prepare, right? Who goes into a meeting or workshop as a facilitator and do not prepare? Well, there is prepare, and then there is PREPARE. I’ve done both, and I can tell you that they are not equal. So some pointers when the time comes to show off your skills.
- Ensure everything works. If you are using a technique that requires that a large open space, make sure the technique is possible in the actual venue. Keep factors like lighting, ventilation, and accessibility in mind.
- Engage ALL stakeholders. Make sure that the seating positions are arranged to ensure that everybody has an equal opportunity to participate. Remember that they might not even need a table in front of them and even standing in a semi-circle around a chart could work with a small group. Standup meetings have been proven to be a great way to get people going, and keep them going. It can apply to a workshop too.
- Question everything, well almost. Not only is it a very effective way of engaging stakeholders, but asking questions also makes them think. You did your research so you have some facts that you could use to raise sensible questions.
- Focus on the AS IS. While it might be very tempting to show off you prowess as a Business Analyst by highlighting shortfalls in the existing processes, it is much more effective to focus on what they are currently doing. The time to fix it will come soon enough. But don’t squash ideas coming from stakeholders. Save these ideas for consideration during the TO BE process designs.
The workshop is done, and you have walked away with a heap of information. It is time to produce the output, probably in the form of an analysis report containing the AS IS and TO BE states for the processes you have mapped. The output is as, if not more important than the actual workshop. While only a select group attended the workshop, the report will find its way to many who were not part of this initial process.
- Use a format that all stakeholders can relate to and understand. Most people are familiar with the basic flow diagram and decision gateways, so that is a good starting point.
- Breakdown big processes into smaller sub-processes for easier reading.
- If your objective was process improvement, make sure that the proposed TO BE state is something that can be supported, either by the project scope or supporting systems.
- Make sure to spell out clearly what can be achieved and what cannot. You might want to map out TO BE states in a phased approach when the best possible solution cannot be implemented within the current scope constraint.
- Highlight changes that will have a significant impact on resources. These impacts could be training or hiring needs.
- Most importantly, produce the output as soon as possible. Do not be tempted to reprioritize activities just because you have taken careful notes of all the proceedings.
And you are done. There are few things as satisfying as delivering a good quality document to stakeholders that they can understand and agree on. The cherry on top is actually implementing the improved process changes. But all this success is only possible if you used the right techniques and tools, prepared properly and produced quality documentation.