Blog

By Cathy Dew

Happy New Year and welcome to Plus17, our monthly live webinar series. Thank you for taking the time to join us. We know that you are busy – as always, we intend to pack meaningful data into an efficient 30-minute window. Drop any questions into the chat as we go through the presentation, we’ll save time for Q&A at the end. We will be recording this session and sending you a link.
 

Watch the Video replay

Let’s get started. My name is Cathy Dew and I am CEO + Information Architect for 2Plus2 Partners. Today we’re going to walk through a 16-step checklist for Business Process Analysis approaches,techniques and tools.

Business Process Analysis Methodology

This is our 16-step checklist for successful BPA projects.

In today’s competitive environment, companies must continuously improve the way they do business to remain relevant and competitive. If you don’t, you risk higher costs, lower revenues, less engaged employees, and less satisfied customers.

Business Process Analysis, or BPA, is a research discipline that enables organizational change by identifying business needs and determining solutions to those needs that deliver value to stakeholders. Today we’re going to walk through a checklist that will help you define the appropriate steps for your project. We are keeping our presentation at an overview level so that you can see the full scope of possibilities. Many items in the checklist refer to specific analysis tools and templates that can help you ensure a good process and result. Over the next several weeks we will explore each of these tools and share the templates that we have fine-tuned over the years of our work with organizations large and small. For today, we are going to review the steps, introduce the tools and talk about how each one applies (or not) to four types of project. Those types are:

• Public website (feature)
• Enterprise intranet 
• Departmental application
• Enterprise-wide software

01. Identify the process to improve

Make sure you have a target for your business analysis.

It sounds obvious, but the very first step is to make sure you have a target for the analysis. Specifically, you need to have a defined process that needs analyzing. Often someone has already identified a problem that needs improvement and this is the inspiration for your project. Rather than going directly to brainstorming solutions, stop and take a look first. Make sure you understand the problem. BPA is a structured methodology to review and validate (the process) to determine where the problem is – and there might be more than one.

Website: You’re losing too many people somewhere in the purchase path, or it may be that not many people are signing up for your newsletter or downloading a case study. Business process analysis can help identify the problem area.

Intranet: The number one complaint that we hear over and over is that employees can’t find what they’re looking for. This is a vague problem that will benefit from a rigorous analysis process. You must understand what and why, how often and exactly who is looking for information to get to the right solution. Intranets offer organizations the platform to automate workflow, request forms, and track document routing – but these are just tools. Effectively integrating online capabilities requires understanding the entire process.

Departmental Applications: Within an organization there are lots of specific, focused business processes designed to get work done. These processes typically evolve over time and are largely defined by the actual people going through the steps. The effectiveness and efficiency of those processes are highly dependent on the skills of the participants. In many cases the processes cross departmental boundaries.

Communication across departments as well as an overall understanding of the impact of the process may be limited company wide. For example, the process to design and launch a new product or manage access to a company's international bank accounts or process permits which are required to do business with your entity are complicated and multi-faced processes. There are various steps, people and data involved in the associated lifecycle. This is where the heavy lifting of business process analysis comes into play.

Enterprise Software: Like departmental applications (only larger), enterprise software projects can only succeed if there is meaningful integration of the full suite of business process analysis tools. We have worked with UC Berkeley on several campus-wide projects as Business Analysts from initial interviews through RFP development, vendor selection and implementation, 2Plus2 was part of the project team for Work Order Management, Housing Assignments and Conference Services. We have seen directly what an important role these tools and practices can have on a project.

02. Find a meaningful metric

What does success look like for your project?

As you are digging into the problem it is easy to get distracted by the problem and the individual players. It is tempting to make assumptions and start generating solutions immediately. One trick to help you think about the problem in a different way is to look for ways to measure success. This forces you to think about the problem and what success will look like. Usually there is a meaningful metric buried in the problem definition. For Internets, it might be:

• Number of downloads
• Time to complete action
• Customer satisfaction

As mentioned before, there are lots of opportunities to make an intranet shine, some metrics include:

Here are some general metrics associated with pretty much any department application:

• Time spent on Intranet portal – more is more
• The number of calls/emails requesting information
• Employee satisfaction

Similarly, enterprise software solutions have very specific metrics that can be measured:

• Turnaround to complete a cycle
• Time spent on routine tasks
• Data accuracy or number of errors

There is almost always a measurable metric that keep the project focused on the solving the right problem.

03. Conduct a survey

Survey reach large groups to collect objective data.

One of the very first things you can do is ask stakeholders what’s going on. The beauty of a survey is that it is quick develop and administer to a broad group. There are lots of online tools that you can use at a very low cost. Like many, we’ve used SurveyMonkey and really like how easy it is and they provide excellent summary and detail reports of the results. Online surveys allow you to get input from a potentially very large group.

Here are a few tips on creating a good survey:

• You’ll want to limit your survey to no more than 10 questions. It needs to be brief, focused and easy to complete in a short amount of time, say 10-15 minutes, to ensure good response.
• Next, because surveys are geared to gather input from lots of respondents, make as many of the questions as possible objective with yes/no, multiple choice or simple numeric answers. This will make it easy to analyze the results.
• The corollary is to limit free text answers to one or two important questions as these must be manually reviewed.

How survey line up with our project types:

Internet Feature: This can be tricky, as you don’t want to irritate your public audience. Depending on your visitor volume, maybe ask every 10th (or 100th) person to participate. The value is in gathering feedback across a board and large enough group to identify patterns. The risk is that you irritate your audience. You can offer a reward to complete the survey – discount, a Starbucks gift card – it doesn’t have to be much.

Intranet: An online survey can be a great tool and can be easily distributed across the organization. In our experience, internal surveys where you ask employees how the Intranet can be better typically get very high response rates – you have an engaged audience that is invested in the project. Tar, star, star – this is an excellent tools for Intranets.

Departmental Applications: Unless there is a large group of users, you may not need a survey. You might go directly to interviews, which we will talk about in a minute.

Enterprise Software: There usually is a large group of users, some may even be external. Surveys can be a great way to capture input across the various constituents and stakeholders.

04. Identify process experts

Talk to the people directly involved in the process.

The next steps is to identify process experts. What we mean by a process expert is just what it sounds like, an expert in the process you are reviewing. The other term you’re probably familiar with is a subject-matter expert (SME), or domain expert who is an authority in an area or topic.

Now let’s talk about how process experts play into each of the project types. For websites, unless you have a large site, with a large group of partner users, you don’t really need process experts. Process experts may just be the different audiences you are trying to reach. You can use Personas (the next slide) to guide analysis.

For intranets, there are plenty of employees that are “experts” for general features. As a side note, don’t forget about staff that might not have internal system credentials. Many companies have a large swath of employs that don’t have internal system access. There might be a kiosk that is shared by a manufacturing. Don’t forget about these folks. For department applications, typically the people using the system are your process experts, which are usually not managers (unless they are also users). Talk to the right people. For enterprise software, you will want to identify as many types of users as possible. The different perspectives can really help define the challenges as you go through process analysis.

05. Generalize experts into personas

Alan Cooper introduced personas in 1998.

The next step is to develop personas. A persona represents a cluster of users who exhibit similar behavioral patterns in their decisions, in their use of technology, their preferences, lifestyle choices, and the like. Behaviors, attitudes, and motivations are common to a "type" regardless of age, gender, education, and other typical demographics. In fact, personas vastly span demographics.

Alan Cooper is famously known as the “Father of Visual Basic” and is the founder of Cooper, a leading interaction design consultancy. He created the Goal-Directed design methodology and pioneered the use of personas as practical interaction design tools to create high-tech products. He first introduced personas in his book The Inmates Are Running the Asylum (1998) in which Cooper play-acted fictitious characters to help solve design questions.

So why do we care about personas? Personas provide designers and developers with an anchor for justifying design choices. Rather than appeal to vague notions of a requirement, they let the team view the problem through the eyes of the persona – "what Amanda would do" or "whether Bob will understand" a given feature, interaction, or visual cue. Websites Personas are largely defined by audience type. Note that for estores, Personas can be significantly more diverse and aligned with purchase patterns.

For Intranets, Personas can represent different types of employees based on job function, role/title, or by frequency of accessing the Intranet. For Business Applications Personas probably aren't needed as these projects are usually limited set of actual users.

Personas can be very helpful for enterprise-wide systems which touch many populations, including external entities.

06. Prep participants with questions

Good questions prompt the good thinking.

We have some general survey information and we’ve identified experts – now it’s time to talk to them. Prepping your interviewees with a questionnaire is one of the most effective ways to make the interview successful. Reading and answering the questions starts the process of thinking about tasks, inputs, outputs and the various entities and people involved. We recommend sending the questionnaire in advance and if possible leave time for it to be returned so that the interviewer can review the responses to formulate even more meaningful questions during the interview.

Website Feature: Even if it's personas that will be interviewed, you need to understand the process and ask the right questions to get at the crux of the issue

Intranet: Some questions are generic and relate to all processes, then there may be specific questions about a particular interaction

Departmental App: Don't ask too many questions, it should take the participant 15-20 min max to complete the questionnaire

Enterprise Software: Be sure to ask the interviewee about their sequence of steps, pain points and inefficiencies as well as what might be working

The point is to trigger thinking – get started.

07. Conduct (great) interviews

Create an intimate setting; in-person and onsite is best.

The interview is your opportunity to gather critical information and really understand the process and there by the highlight any challenges, inefficiencies and what may not need changing. The questions sent in advance are to spur thinking and break the ice. It is not unusual for the interview discussion to go a completely different way.

Tips for a good interview:

• Prep the interviewee
• Conduct the interview in person if possible, if not then include video so that you can establish a more connected setting for the discussion
• Go to the interviewee’s workplace if possible
• Listen, listen, listen. The questions are just a cue to get the interviewee talking about their process. Don’t be so focused on answering your questions that you miss important points from the interviewee.
• Tape record the session so that you can be fully present – you can take notes later.

For websites, the interviewee may be the project team acting in the role of each Persona. Interviews for intranets you want to confirm broad findings (from the survey) and ask specific questions for each sub group (department, management, etc.)

For departmental apps, it’s even more important to observe the nuances of their work space. You can learn lots from the piles of paper, sticky notes and other support materials and actions that the process owner conducts.

For enterprise software projects, be sure to ask about all the resources required to do their job, where are sticking points, what works well.

08. Compile and organize results

Maintain transparency and encourage engagement.

Once you’ve conducted the interviews it’s important to document the results in a meaningful way. There is often a series of back and forth exchanges (emails, short phone calls) with the interviewee to ensure that you have accurately captured their process. This not only ensures that you got it right, but also builds trust with the process expert. You understand what they do, what they put up with, suffer from, etc.

Regardless of the project type, writing down and summarizing the interviews is critical to establish credibility, communicating the information and continuing to keep the team aligned with the goals of the project. Common problems will be highlighted by multiple groups. Specific needs will come up by department or persona. Often this step reveals hidden problems that you weren't looking for initially. Doing well in this step is a great way to maintain transparency and encourage engagement.

09. Create flow diagrams and iterate

A picture really is worth a thousand words, maybe more.

There are two techniques that we have found useful in documenting processes. The first is process flow diagrams, also known as swim lane diagrams or flow charts. The second documentation type is a more narrative description of the input, process and output known as IPO grids.

Process flow diagrams depict the lifecycle of processes in a visual format. Participating departments, people and systems are depicted as swim lanes (rows) in the process diagram. Inputs and outputs are documented. There is usually a visual distinction between manual steps and automated processes. One of
the most powerful aspects of the business process mapping tool is the magic that happens when all of the participants come together to review the diagram. We’ve found, the most effective way to conduct this type of review is to print out a large-scale image. Roll it out on the conference table and invite all stakeholders to attend. This technique allows everyone to access the entire process. The team can then review, update and ultimately approve the process flows.

Depending on the project, you often do both an “as is” flow diagram which describes the current process. This is followed by a “to be” which outlines the proposed, desired, future process.

• Even if the process is not complex, seeing it laid out on paper often communicates the interaction in a way that is hard to grasp from a narrative description.
• Flow diagrams can capture the many external systems that employees rely on every day.
• You want to be sure you have a swim lane for each significant user type (persona) as well as systems.
• Make sure that you document the entire process, manual and automated, capture inputs and output, think about each step from a data and process perspective (these might be different diagrams).

The number and complexity of process flow diagrams depends on the project. In our sample project types we’ve intentionally gone from simple to complex.

10. Checkpoint – data completeness

Can you adequately describe the process?

We’ve gathered a lot of data. It’s time for a checkpoint. It’s time to stop and assess. Do you have all the information you need to generate requirements that fully describe the solution to the problems being analyzed? This is a judgement call as much as anything else. You may want to schedule more interviews with the same or different people. You may even want to conduct a survey to validate something that you heard.  You can actually do this at any time, well as long as you don’t fall into the analysis paralysis trap...

11. Write up requirements

Pull together everything you learned into a clear list of needs.

Documenting business requirements is somewhat of an art and as is true with most things, the level and quality in requirements documentation varies greatly. Experience with generating, digesting, and organizing observations, flows and the compilation of data gathered into business requirements counts for a lot here. Version 1 of a requirements documents includes a way to group the requirement – categories might be functional, technical, user experience and integration. You may also want to organize requirements by function, department or phase on the process. As we think about requirements for each project type, here are some points to keep in mind:

• The process of writing it down provides a valuable buy-in and accountability tool.
• Don't pare down much (yet), it's okay of it's a big list.
• The initial focus is on functional requirements for the target process, but other requirements will come up -- integration, performance, usability, etc.
• Categories can help organize what will likely be a very long list

12. Comb for hidden requirements

Leave no stone unturned, there may be real gems.

There are often requirements hidden in existing sources. Be sure to mine these areas for things that might not have come up yet. Note that it’s totally okay to move this step earlier in the checklist. Just not too early as you want to remain open to letting the business users define the problem. Some common sources of hidden requirements include:

• Emails to the "webmaster"
• FAQ, support tickets
• Users of focused applications typically have a wish list, go ahead and add these in, try not to constrain the input
• Help desk logs, features slated for a future release and even competitor solutions can be sources for more requirements

13. Check for peripheral systems impact

No man (or system) is an island.

The are almost no isolated systems. The next step is to look up and down the system food chain.

• If you haven't yet, ask users of both upstream and downstream systems about their process as it relates to the process you are analyzing.
• Most Intranets have a lot of touch points with systems – it may be HR for payroll or benefits, it could be Finance or Sales – be sure to track integration requirements.
• For larger projects (departmental apps and enterprise software) interaction with peripheral systems may be both critical and complex to design and implement – don’t miss them

14. Compile, consolidate and prioritize

Categorize, prioritize and possibly quantify effort for each item.

Now you’re ready to finalize requirements. For each requirement, you will want to add a priority, a timeframe and perhaps a scope of effort. These columns can help organize the requirements. You want to compile, consolidate and prioritize all requirements.

• For website features, this can be as easy as High, Medium and Low for priority and effort.
• For intranets organizing and prioritizing is critical – start thinking in releases, especially with Intranets which are growing ecosystems and always evolving.
• For departmental apps and enterprise software, you will want to identify have-to-have vs. nice-to-have as well as relative effort in order to plan out versions of the application

15. Check point – buy versus build

Is there an off the shelf solution that would work?

I’m not going to spend much time here, but for departmental applications and possibly enterprise software, there may be a decision to make regarding the system implementation. There are likely off-the-shelf solutions that should be considered. For highly specialized problem areas, you may be looking at a development project. This decision drives the kind of documentation and process that comes next.

16. Develop RFP or spec

We’ve reached the end, which is also the beginning…

Departmental applications and enterprise software projects can only succeed if you understand and can articulate what you need. You must have fully vetted, categorized and prioritized requirements that fully describe the desired system. If that software will be purchased from a vendor, you will need to develop a Request For Proposal (RFP). The requirements section is a critical tool in evaluating the vendor’s ability to deliver a system that will work for your organization.

Here is how this step lines up across our project types:

• This is NA as in Not Applicable for website features.
• For an Intranet, you will want some sort of document to help drive the development process and in some cases to select the Intranet platform if that is also up for grabs.
• For a Departmental Application, the Specification must contain enough information for a developer (internal to the company or an external consultant) to provide an accurate design, development and implementation budget and timeline.
• The larger the system, e.g., enterprise software, the more likely it is that you will be looking for a vendor solution. Having a well written RFP can make a big difference in the quality of responses and ultimately the likelihood of finding a great vendor partner.

This is the end of our checklist for business process analysis, but it is also the beginning of implementing your solution. And as you might have guessed, that’s another whole checklist.

Congratulations – time to kick-off

• Build + implement
• Measure again
• Have a party
• Build process improvement into the lifecycle

Before we leave this topic though, it’s important to acknowledge the value of the work.

Thank you. Any questions?

Contact us for a free consultation: cathy@2plus2.com, 510 652-7700

Thank you for your time today. I hope that you have a better understanding into how business process analysis can impact your project in a meaningful way and into some of the tools and techniques that are used.

We hope you will join us next month Tuesday, February 7th at 10 am PT, 1 pm ET when we will look at SharePoint and Office365. Specifically we’ll be looking at the flavors of teamsites available and how to make decisions for your organization.