Author: Anton Oosthuizen

The Business of Process Analysis

Written by Anton Oosthuizen on December 15, 2015. Posted in Articles.

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.

Select Techniques

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

Conducting Research

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.

Being Agile

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.

Being Comfortable

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.

The Workshop

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.

How to Promote Stakeholder Ownership

Written by Anton Oosthuizen on July 24, 2012. Posted in Articles.

One of the first things a project manager does on project initiation is compile a project plan that contains, among other things, an RACI, which is a matrix showing the roles and responsibilities of the different project stakeholders. But there is one responsibility that is never spelled out in any document. This is the responsibility of a stakeholder to take ownership of their own decisions. Everywhere you look there are certain responsibilities that stakeholders must take ownership of, which are mostly social and moral, but for some reason it is deemed acceptable for a stakeholder on a project to neglect their responsibilities toward the success of the outcome.

Now some people will argue that these checks and balances are present during different phases of the project to enforce some sort of ownership — i.e., the approval of a specification, acceptance of a test result, etc. — but all of these are usually at the end of a phase, and as any business analyst can tell you, a lot of water passes under the bridge before this is reached.
So besides the normal approval of requirements, specifications or test plans, what should the stakeholder be taking ownership of? I believe we have all been in a situation where we are responsible for conducting an elicitation workshop and as we know one of the elicitation tasks is preparation. When the facilitator of a meeting or workshop neglects to prepare properly, the outcome is doomed from the start, but this is true for the participants as well. Participants should come to a meeting or workshop fully prepared, but unfortunately not a lot is done to enforce this.

If you have facilitated more than one session, you have most probably heard somebody say “since you are the experts you should be telling us what to do,” and this normally comes from the participant who arrives with only his mobile phone. Although there is some truth in this statement, it is too often used as an easy way out of doing anything or for taking responsibility. The ‘tell us what we don’t know’ is used as plan B whenever the stakeholder has neglected to deliver on plan A, which is to prepare.

Just like making a child eat their vegetables, there are ways to make the stakeholder take responsibility, but as with the former it is never easy and could lead to tears. This is part facilitation skill, part stakeholder management and part psychology. This is the how-to guide to getting your stakeholders to take responsibility.

Start driving home the message well ahead of time. Don’t wait for the last minute but remind participants of their responsibility to come prepared two or more weeks in advance. It is always a good idea to include anything that they should be bringing to the table in the agenda, which by the way should also be distributed early.

Ensure that any presentation material is distributed with instructions on what needs to be done, i.e., homework.

Always try to get as much input from stakeholders before the session. This will allow time to understand what stakeholders are thinking and hopefully provide valuable information on how to steer the session.

Get commitment for stakeholders about attendance and participation.

Make sure the agenda has a clear set of objectives, something that stakeholders can think about but also that is of particular value to them. You want to ensure there is a sense of anticipation, i.e., ‘they are going to be discussing this and I’m not being left out.’

Get to know your stakeholders, that way you can talk to them, ensuring they have a sense of ownership. Throwing a general statement out there has its place, but nothing says ‘you own this’ more than looking somebody in the eyes when addressing an issue.

Actively engage the stakeholders to make some verbal commitments. One of the outcomes of any meeting or workshop is an action list, but getting verbal agreement from a stakeholder in front of his peers always provides an ‘Oh #$#@# now I am responsible’ moment.

Make it about them. We all know that is why we do it, but in many cases stakeholders attend sessions because they were told to, and there is nothing worse than dealing with a stakeholder who did not buy into the idea. If they feel you are there to try to add value to the function (and not just because it is a contract deliverable), you might be surprised how they open up.

But the old adage ‘you cannot satisfy everybody all the time’ remains true. There are times that stakeholders will arrive with the gusto of a sloth on his way to his afternoon sleep and remain like this throughout, but there are always opportunities where you can awaken the beast and as a facilitator this is part of what you should be looking for.

The most important and powerful tool you have to mitigate this type of behaviour is…YOU! When stakeholders say that we [BAs] are the experts and should be guiding them, they are 100% correct. If we cannot do this then we have no place standing in front of the customer. To manage your stakeholder effectively, you need to do so from a position of authority. Contrary to popular belief, availability is NOT a skill and nothing annoys and breaks down trust quicker than a placeholder, so if you see this coming your way, run!

Don’t forget to leave your comments below.