Strategy that Works

Process Analysis:

The Foundation of Business Analysis

By: Brian Betkowski

Does this scenario sound familiar?

1. A requirements analyst periodically visits with business SMEs to document their needs. They talk until the SMEs feel they’ve finished providing information or until they run out of time.
2. The analyst then works offline to interpret the interview notes, format them into a document, and deliver it when it seems complete.
3. The accuracy and integrity of the document are measured by its thickness, the complexity of the content, a general sense of intuition by the analyst, and the amount of time, money, and effort it took to create.

If you’ve been there, you know this approach leaves too many questions unanswered. How do you know the requirements document is actually complete? Are there too many requirements? Too few? Are there pieces missing? Is the real business intent clear, traceable, and measurable? How does the project relate to other projects? And most important: How does this project fit into your overall business case?

Is this really business analysis at all? Or is it just requirements writing?

True business analysis answers all those questions and starts you down a solid path toward return on investment. To do that, it takes a focused analysis of business processes from the very start. Let’s examine process analysis in terms of foundation, framework, and methodology.

Process Foundation

People, process, and technology – the three fundamental components of business. Not to play favorites, but if you think of people and technology as performing critical support roles, the core of any business is its processes: the functions that occur as your organization serves its customers.

So, how does process analysis form the foundation for business analysis? By definition, business analysis means identifying business needs or problems and determining solutions to them. If we agree that processes are at the heart of a business, then all business needs (and solutions) can be traced back to a set of foundational business processes. It follows, then, that business analysis should be built upon a thorough understanding of business processes.

The first step, therefore, is critical: defining all of the key business processes performed by the organization. Only after laying this foundation can other impacts (to employees, customers, products, services, technology, operations, shareholders, partners, etc.) be fully understood and anticipated. True business analysis uses this foundational understanding to translate strategic direction into internal and external changes.

Figure 1 – Business Analysis Based on Process Analysis

In fact, defining and documenting an organization’s processes also adds widespread ancillary value to a project. It provides:

• A common language between teams (especially business and IT) for referring to each part of each process in the business, reducing confusion and increasing consistency.
• Cohesive end-to-end visibility for all pieces of all processes, eliminating uncertainty over accountability by detailing it objectively.
• Reusable process maps that can be used later to jump-start other projects and define linkages between project teams.
• A basis for creating training, methods, and procedures.
• An estimating tool to quickly identify and quantify impacts to the organization.

Once you’ve accepted process analysis as the foundation for business analysis, the next step is to create the process framework.

Process Framework

In most cases, the primary output of business analysis is a set of requirements in some form or another. A common mistake made by many business analysts is to start requirements gathering by jumping straight to solution brainstorming, discussing desired outcomes. But framing the topic first around business processes is critical to producing high-quality, consistent, and complete business analysis deliverables.

There are a few key aspects to a good business process framework.

• It articulates one or more end-to-end business functions.
• It specifies the inputs and outputs of that end-to-end process.
• It details which areas of the process are the focus of the project at hand and just as important, which are not impacted.
• It is at a high enough level to be easily understood by all areas of the business and IT, yet detailed enough to facilitate specific functional requirements gathering.
• It specifies the key actors performing the business functions; the channels, the customers and other external entities affected.

As an example, here’s a first draft at a high-level process framework for a health insurance customer lifecycle:

For a particular project, the focus may only be on one area of the business. In this example, the Service process is further broken down into process segments to show a greater level of detail:

Obviously, the framework shows just the high-level process in question, but it can be an important tool for discussing scope and aligning project work. It is often just as valuable to show what is not in scope as it is to show what is in scope.

This framework is highly reusable and becomes a handy starting point for all projects. Once you have a framework in place, you can use it as a guide to begin the deeper steps of analysis, what we call the process methodology.

Process Methodology

With the process framework as a scope guide, the methodology works like this:

• Using the process framework, determine the areas your project impacts.
• Create business scenarios in each of those areas. These are real-world situations that describe the desired business functions as they should be once the project is complete – what you want to be happening in your business. Think of them like UAT test scenarios. Keep the project goals and constraints in mind, and incorporate strategic objectives and measures.
• Create and update detailed process flows for each of the process areas in the framework. Do not limit yourself to the areas you identified as impacted. All process areas must be assessed for impacts (this is key to ensuring coverage of scope).
• Divide the processes into smaller, manageable parts called process segments. Label each of used throughout the project.

Then and only then – when the process analysis is complete – can the second phase of business analysis begin. Now it’s time for requirements analysis, which will make use of the process segments you just outlined. In brief, requirements analysis takes place in two steps:

1. Iterate through the writing of business requirements and rules for each process segment. As a team, move systematically through the smaller process nodes of each process segment, documenting all inputs, outputs, functions, rules, reports, etc. Focus on the "what," not the "how," at this point.
2. Document other requirements that may not be directly reflected on the process flow like non- functional requirements, reporting/measurement requirements, as well as impacts to external groups, including customers.

As you can see, the process foundation, framework, and methodology are essential to complete before moving along to business requirements analysis. And while there are many other important support functions (such as communication, traceability, change control, and prioritization), business analysis will not succeed without process methodology.

Project Benefits

Beginning business analysis with process analysis in this way yields an objective, detailed understanding of your organization and how it functions at a granular level. Establishing this understanding early will keep the rest of the project lifecycle tied more closely to the ultimate business goals of the project. It’s a results-oriented approach.

One of the outputs of this methodology is a set of clearly labeled process segments that factor easily into various metrics. This creates several other benefits, all of which reduce expensive delays and defects. For example:

1. Completeness - Because the business analysis scope is determined via a detailed understanding of processes, even the smallest foundational elements of the business drive the project. Nothing is left out. That means fewer costly surprises later.
2. Planning Accuracy – The process segments fit into planning and tracking metrics that facilitate more accurate daily planning and make status reporting more objective, less emotional.
3. Predictability and Repeatability – Because the methodology lends itself to clear, reliable tracking of the completion of each step, it becomes possible to measure factors that show the team’s typical working velocity. This knowledge helps not only accurately plan for the remainder of the project at hand, but also estimate future projects.
4. Speed – The process framework and methodology take place step-by-step in a clear structure; so your group works toward results in a visible, team-oriented atmosphere. Teams develop a cadence, stay focused, and don’t lose time.
5. Reduced Variability – With a standardized methodology, variability in approach and outcomes among business analysts is minimized. The use of a formal structure with scientific planning and measuring tools throughout reduces unnecessary tension, as the focus stays on objective steps and procedures.
   
   repeatable business analysis, even more important is the methodology, or how you go about acquiring the information to put in the template. Analysts often confuse template instructions for methodology. By beginning with process analysis, you place greater weight on true understanding of the business and its processes, versus undue emphasis on the templates themselves.
6. Fewer Changes and Defects – Thorough planning and scoping phases as part of process analysis minimize change requests and defects in downstream phases, saving time, frustration, and money.
7. Minimized Missed Expectations – A grounding in business process understanding across teams minimizes miscommunications and unfulfilled expectations among customers, business, and IT.

It all adds up to a greater return on investment.

Getting Started

The fact is, business analysis and process analysis can’t really live apart. Time and again, project leaders find that simply writing requirements without first undertaking a thorough process analysis has dramatic effects on the integrity of the results.

Is your project ready to get underway? Begin by creating a process framework for your business. Share it throughout the organization. Then gather your team and perform the process methodology, step by step. And be prepared for the experience to change the way your organization views business analysis.

About the Author

Brian Betkowski (brian.betkowski@jabian.com) is a Partner and Co-founder at Jabian. Brian created Jabian’s industry accepted methodologies for Business and Systems Analysis as well as standardized processes for IT Strategy and Planning. He is well known for his Business Process Management work and Enterprise Architecture leadership. His real passion and expertise lies in Business Strategy and Financial Planning, which he practices regularly for internal Jabian projects as well as for Jabian’s strategic clients.

About Jabian Consulting

Jabian Consulting is an Atlanta based IT and management consultancy that applies senior level consulting specialists to our clients’ top priority projects. Jabian takes an integrated approach to creating and implementing strategies, enhancing business processes, developing human capital, and better aligning technology – ultimately helping clients drive business value by increasing revenue and decreasing operational costs. Jabian Consulting is a division of Jabian, LLC, a privately held corporation based in Atlanta, Georgia. For more information, visit www.jabian.com.