Business Process Analysis

Goals

The main goal of a Business Process Analysis engagement is to get an accurate and holistic understanding of the business processes related to a project to help ensure that the completed project

• improves the business processes in the intended way,
• does not unexpectedly degrade other processes that are affected by the project,
• and the completed project provides greater benefits than costs to the university. 

Without this understanding it is all too easy to design and complete a project that is built according to specifications but ends up not benefiting the end users in the intended way, has an unexpected negative impact on other users that are downstream of the business process, or costs too much in time, effort, and money to make the project beneficial for the university.

Questions To Ask

To that end, we want to learn all that we can about the who, what, when, where, how, and why related to the project.

Who: Who all will be impacted by this project? Who will be executing the project? Who will benefit from the project? Who uses the output of this process later on? Who contributes to the input? Who is involved from other departments that should be speaking into how this process is done? Who is the executive sponsor(s)? Who decides on the budget allocated for the project?

What: What is the proposed solution? This is the part that is usually communicated in the initial request for help. There are additional questions to ask to help flesh out the 'what' aspect. What is the current workflow that is being done because this project has not been completed? What are the most cumbersome, expensive, or frustrating parts of the current process? This question is often helpful in gathering details because people generally easily remember the pain points in their current process and are eager to discuss them.

When: When is the current processed used? How frequently? Are there particular times during the year when it is used more, or less? What is the time table for completing this project? What time constraints are involved? When do you want to start using the new solution? Are there slow periods for your department that are particularly good opportunities for working on this project? Are there times that are especially busy in your departments that would conflict with working on this project, or where you want to make sure this solution can be used? What happens if the solution is not ready to use by the proposed date? What would we do as a workaround until it can be completed?

Where: Where will the data for this process reside? Will the software be hosted on premise or in the cloud? Where will the processes be done (on campus, off campus, etc.)? Does the location vary? If the location for the process changes, or if people perform this outside of their office, do they need to be able to complete this process on a phone or tablet?

How: Here is where you dig into the specific steps in the current workflow, as well as the steps in the proposed solution.

Why: This is the key set of questions. This is where we dig in to find the reasons behind the request. Why is the current process done? Who is impacted by the output, and what do they do with the output? Why is this project being proposed?

Once these questions have been asked we summarize the goals and requirements of the project. When writing this summary, use language that the end users and stakeholders can understand to make sure that they can acknowledge and affirm the summary. If you find any technical language that is not understood by all parties, find a way to rewrite it with language that is understood by everyone.

Additional Principles

Here are some additional principles to keep in mind during this process:

Be an assumption goalie. Projects that turn out poorly are often torpedoed by assumptions that turn out to be untrue. It was assumed that the stakeholders had secured the budget for the project, but they hadn't, and now we don't have the resources to complete it. Or, it was assumed that the vendor's claims to be able to integrate with our system had been verified, but now we are partway into the implementation and the integration requires significantly more work on our end to implement than we expected.

To that end, think of yourself as a goalie and assumptions as the ball, and don't let any past you without being investigated. As you talk with end users and stakeholders, be on the lookout for places where people are making assumptions and find a way to ask and see if the assumption is true or not. If you can't find a way to investigate the assumption, make sure to note the assumption in your write up of the project and detail what could happen if the assumption is not true. 

Zoom Out Before You Zoom In. As you begin to learn about the business processes, it can be easy to start getting very deep into the details of one particular part of the project. If you start getting deep in the weeds too early, it can pull time and attention away from learning the big picture goals and needs, and focusing on one aspect can distort your understanding of the goals and priorities of the project. As you begin the analysis process, focus your attention first on understanding the overarching goals of the project before you delve into the nitty-gritty details of its individual aspects.