As Business Analysts, we have become pretty proficient with respect to requirements. Understanding the Who, What, Where, When and How to develop, document and manage requirements has seemingly become part of our DNA. But when it comes to performing analysis, the “how” unfortunately doesn’t come as natural. Whether you’re a BA generalist, specialist, or somewhere in between, our core competency should be the ability to effectively analyze things. By analyze, I mean possessing a level of proficiency to examine, interpret and transform information (implicit and explicit) that enables sound decision making. So why, even with the word Analyst in our title, is the role of BA more associated with requirements rather than analytics? My hypothesis is pretty simple:
If Business Analysts are not required to produce specific analysis related artifacts, then both analytical competencies and requirements efficacy will be diminished.
Think about it. First, the BABOK v2.0 defines an Analyst as “a generic name for a role with the responsibilities of developing and managing requirements”. Second, examine the principle deliverable we produce called a Business Requirements Document / Specification. A typical BRD/BRS confines BA deliverables into three primary categories: Project, Requirements, and Support / Administrative.
So, let’s address a few elephants in the room – where are the artifacts supporting how we determine the requirements? How do the requirements ensure the business objective and all of the Success Factors are satisfied? Do we understand enough about operational relationships, process interdependencies, and potential risks to effectively contribute to the solution design?
As a professional in this field for over 20 years, I have addressed these elephants in the room on many occasions. Having spent years operating in the world of process, statistics, and quantifying value, combined with having worked in Agile environments as well as on Lean Six Sigma projects, these elephants have proven to be very real and can create material risks in developing and delivering appropriate solutions. However, this article is not to promote one methodology over another, or identify all the potential failure modes insufficient analysis has on the overall project (we will address that in a separate article). The purpose of this article is to introduce, or perhaps reinforce a few analytical tools and techniques to our tool belt. These tools and techniques that are common practice in process analytics can have an immediate and positive impact on reducing project risks, requirements efficacy and the overall value the BA brings to each and every project without modification.
A Different Perspective
First, one of the most helpful techniques that will provide both a starting point and an analytical baseline throughout the entire project is a Fact Model. Alternately referred to as a Concept Model or a Business Entity diagram, a Fact Model illustrates basic structures, relationships, and interactions the business has with both internal and external entities. This is key to develop an understanding of the big picture. Incorporating this “Systems Thinking” approach enables the BA to identify and synthesize all of the parts that shape the desired behavior of the target system/environment.
Below is a Fact Model that represents an elementary view of an ATM environment (i.e. the whole). It contains the parts (nouns), and the facts (verbs) that illustrate the relationships that enable the system to operate. Typically, if we were creating requirements for an ATM system, multiple BAs would be assigned to focus on the various parts of the system (i.e. security, transaction business rules, user interfaces, etc.). Unfortunately, it’s not until the completion of the BRD where the big picture, logic and/or requirements defects are discovered. Moreover, consider the effort expended refactoring requirements when a Part or Relationship between Parts change. For example, what’s the impact if the business decided to limit cash withdrawals from Checking accounts only? A FACT model would help us easily identify the impacts, gaps and effectively construct an alternative solution to handle those inputs, outputs and relationships to sustain the environmental integrity.
Fact Model Benefits:
|
|
|
|
|
- Effective problem solving
|
|
|
|
Establishing Boundaries
Although the central artifact that establishes project boundaries is the Project Charter, we need to understand the scope of our analysis. What processes are involved? What outputs do these processes create? Who consumes these outputs? Who supplies what materials and information that are used to create the output? A tool that is most effective in quickly answering these questions is called a SIPOC diagram. SIPOC is an acronym for Supplier, Input, Process, Output and Consumer and is used to identify these essential elements associated with the processes that helps to define our analytical boundaries around a complex project that might otherwise be problematic or difficult to determine.
For example: if we continue our previous scenario to limit cash withdrawals from Checking accounts only, developing a SIPOC diagram provides additional information to our FACT model to effectively focus our analysis. First, we can see from our Fact Model that we need to capture those processes associated to cash withdrawals. A SIPOC will identify specific inputs coming from the suppliers (Bank, Account, Debit Card), identify what transformation happens to these inputs to enable the withdrawal (the Process), and the specific outputs that feed the cash disbursement (the consumer).
A SIPOC diagram is a pretty standard template with minimal variation from company-to-company. However, the steps to create it is where the variation exists. Personally, I prefer the POCIS approach as opposed to moving from left to right starting with the Supplier. By capturing the high-level Process, the Output it creates, and the entities that consume it makes it easier for the SMEs to follow and accurately identify the inputs and suppliers who provide them.
SIPOC Cheat Sheet
SIPOC Example (ATM)
SIPOC Benefits:
- Process context for cross functional team
|
- Visualize how the suppliers, inputs, process steps, and outputs affect customer(s) needs
|
- Excellent foundation for cause-and-effect analysis
|
- Quick and effective way of capturing process attributes in a non-threatening manner
|
- Quickly identify potential in efficiencies (i.e. inputs received but not needed, Outputs that customers don’t want, but receive anyway, Process steps that are completed, but add no value)
|
- Excellent visual communications tool
|
Recommended Reading:
- The Lean Six Sigma Pocket Tool book: A Quick Reference Guide to 100 Tools for Improving Quality and Speed by Michael L. George, John Maxey, David Rowlands and Mark Price
Recommended Viewing:
- YouTube: Problem-Solving Techniques #9: SIPOC Diagrams, Eugene O’Loughlin
- YouTube: Optimize SIPOC – Introduction, and How To; Sandra Harris
Connecting the Parts
Two elements that are fundamental components to understand how the parts produce the end state are sequence and time. Sequence is the flow and transformation of source materials and information that create the intended end state - usually a product or service that is consumable by a customer. Time is knowing whether or not the sum of the sequences are both acceptable and efficient.
While most Business Analysts are familiar and competent in capturing the sequence through flow charts, process maps, swim lane diagrams or activity diagrams, integrating the element of timing may be somewhat unfamiliar.
Value Stream Mapping (VSM) is a process capture technique that adds the dimensions of time and control amongst a variety of other metrics that enable statistical analysis. It enables the BA to view, identify, and understand the flow of information/materials across the entire process from source to consumption. The primary analytical benefit is the ability to quantify the process in terms of time, and quickly identify where potential inefficiencies and constraints may exist to effectively target their analysis.
Here are two examples of a VSM. The first, developed to capture a statistical analysis of an assembly line and the second, is a hybrid VSM that integrates the element of time into a more widely used swim lane artifact.
Value Stream Map
Hybrid Swim lane / Value Stream Map
Value Stream Benefits:
|
|
- Visualize more than just the process level
|
- Qualify & quantify the process as a whole and its individual parts
|
- Identify process controls
|
- Quickly identify potential in efficiencies
|
- Excellent visual communications tool
|
Recommended Reading:
- Whitepaper: 10 Steps in 10 Minutes Value Stream (VSM) Manual; John Szemler (LEAN Center of Excellence)
- Learning to See: Value Stream Mapping to Add Value and Eliminate MUDA / Edition 1; Mike Rother
Recommended Viewing:
- YouTube: Value Stream Mapping (5-part video); simpleximprovement
- YouTube: Jim Womack on Reasons for Value-Stream Maps
If there is one tool I would have liked to have had in my arsenal earlier in my career, it would be the Failure Mode and Effects Analysis matrix. For BAs, this should be a staple in our tool belt. I have also made recommendations to the IIBA that the FMEA, at a minimum, should be covered in the Techniques chapter of the BABOK.
The FMEA is a step-by-step approach for identifying all current and potential failure modes in a process, product or service for remediation, improvement and design efforts. A Failure Mode (FM) is defined as the ways in which something is or may potentially fail. The Effects Analysis (EA) refers to identifying the consequences of those failures – again either potential or actual. The beauty is in its flexibility and completeness to perform and align analytical facts and recommendations in phased approach in a single comprehensive view.
We won’t get into the procedural process to create the FMEA as there are many (see recommended reading and viewing), but let’s take a look at an example of an FMEA on an ATM system to gain some context into its analytical value. Keep in mind that a prerequisite to start any FMEA is a strong understanding of the functions or process steps in scope (accurate current state process maps and/or procedural documentation is highly recommended).
Each function or process step is itemized and associated with known or potential ways failure will occur. Each FM is broken out into the effects/impacts to a person, process or system assuming it happens. The workgroup will collectively assign a (S)everity rating to the failure mode. The group then itemizes what could trigger that specific FM, and scores the probability of root cause occurring (O). Next, is to identify the existing controls in place to (D)etect each potential cause (note existing control, not what could/should be there). Scores are then calculated to generate a Risk Prioritization Number (RPN) (Severity*Occurrence*Detection), and (CRIT)icality score (Severity*Occurrence). These ratings provide prioritization guidance for the team to effectively determine next steps. Note that industry standard scoring definitions have been developed and associated with each rating area.
Possessing this information collaboratively gathered and quantified by the working group, gaining agreement and establishing next steps is a relatively straight forward process that can easily be integrated into the project Work Breakdown Structure. Moreover, the FMEA matrix provides the ability to capture and compare, using the same working group, the results between current state and end state. The ability to quantify improvements to the project stakeholders is typically a win-win situation.
FMEA Benefits:
- Collaboratively captures cross functional knowledge of a team
|
- Logical, structured process for identifying areas of concern
|
- Documents and tracks risk reduction activities
|
- Identify preventative actions and therefore minimize the risk of potential failures
|
- High potential for cost reduction associated with rework – getting it right the first time
|
- Enables additional, more complete testing scenarios and deficiencies in detection controls
|
Recommended Reading:
- The Basics of FMEA, 2nd Edition; Raymond J. Mikulak; Robin McDermott, Michael Beauregard
- Effective FMEAs: Achieving Safe, Reliable, and Economical Products and Processes using Failure Mode and Effects Analysis (Quality and Reliability Engineering Series); Carl Carlson
Recommended Viewing:
- YouTube: What is FMEA; QualityQAI
- YouTube: FMEA: How to Perform a Failure Mode and Effects Analysis (Tutorial); leansixsigmasource
Conclusion
Analysis can be defined as the process of separating something into its constituent elements to uncover their interrelationships. Yet, it seems BAs are frequently tasked to develop requirements solely on the constituent elements in the absence of a comprehensive understanding of that something – the whole (note I do not qualify the Business Case or Project Charter as that something). So it doesn’t surprise me, nor should it shock many, that multiple research efforts focused on identifying the root causation of failed projects identify poor requirements as a major contributor to failed or substantially delayed projects – some as high as 68%. However, what does surprise me are the perceived causes of the failures ranging from poorly scoped projects, inadequate cohesion and traceability between the business case, requirements definition and software specifications, to ineffective requirements management with no mention of analytical related activities or competencies.
Since my exposure and experience with these and other analytical techniques, I have come to find that quality requirements are the output of a structured analytical transformation process rather than the translation of business speak into appropriately structured requirement statements and templates. Additionally, when a methodology and/or approach includes “Analysis” as a specific phase and associates explicit deliverables as outputs (e.g. Six Sigma’s DMAIC, DMADV) the analyst has a very different perspective. A perspective that focuses on quantifying the logic and linkage between deliverables and facts, organizational structures and outputs, and business processes with potential risk.
The analytical process is more than just a collection of tools and techniques that produce effective artifacts. It’s an approach that creates organizational knowledge and promotes a culture around quality, efficiency and continuous improvement. Conceding this can and will take time and may ultimately require a culture shift, adding all or some of these tools to your tool belt will have an immediate and positive impact on reducing project risks, requirements efficacy and the overall value you bring to your project.
About the Authors:
|
|
Eric Spellman is a Managing Director at Magic Hat Consulting. He has 20 years of experience as a key strategic leader and tactical contributor with organizations engaged in transforming, transitioning and integrating process improvement within requirements development, program management and strategic planning areas. Eric’s business domain experience includes Banking, Insurance, Pharmaceutical, and Software Development. Eric is a certified Lean Six Sigma Black Belt and SCRUM Master. He has served as a chapter board member for the IIBA and an active member/contributor to several Process, Requirements, and Project Management groups.
|
|
|
|
|
|
|
|
Jack Merritt is a Senior Director and leads Magic Hat Consulting’s Business Enablement practice. He is a Lean Six Sigma Master Black Belt with 17 years of experience deploying Lean & Six Sigma programs and executing projects delivering over $200M of demonstrable annualized savings from operations and improved effectiveness of sales forces. Jack has taught DMAIC, DFSS, DMADV, Statistical Process Control, Innovation, and Practical Statistics at several universities. His areas of expertise include: Sales and Marketing processes, Customer Service effectiveness, and Transactional Finance. Accomplished in executing Hoshin and Strategic Planning programs, Operational Metric Development, Kaizens, Work-Outs, Lean Value Stream Mapping and Process Flows, Project Management, Financial and Process Modeling.
|
|
|
|
|
|
|
|
|
|
Magic Hat Consulting
455 Pennsylvania Avenue, Suite 125
Fort Washington, PA 19034
215.540.1200
|