“I Said My Name Is . . .”
After several years of experience as a business analyst you begin to see examples of good and bad business analysis everywhere you look: your bank, city hall, the IRS, your grocery store, your cell phone company, etc. We are all end users, customers and consumers.
For better or worse, business analysis collides with many aspects of our personal lives.
Over the course of the last few months, I have been in a fierce battle with bad business analysis—all because of marriage and moving. These are two relatively common life events. Name and address changes should be simple, standard processes. And yet, most organizations fail to successfully manage changes to basic customer data.
My battle started when I realized, after the wedding was over and the witnesses had left the state, that there was an error on the marriage license. My new name was incorrect. I filled out the application properly, but the data on the application did not transfer correctly to the license. A process failed.
Eventually, the marriage license problem got fixed, which allowed me to get an updated driver’s license. Three months later, when I went to vote on Election Day my name on the voting registry was incorrect. It matched the erroneous name from the original marriage license. Now, my ID and voter registration, created by the same organization, did not match! A process failed.
My favorite airline was the source of my next skirmish. In order to get through security, the name on my airline ticket needed to match the name on my driver’s license. My license was “in progress” which means I had a piece of paper instead of the card. Surprisingly, a simple phone call can get tickets re-issued with a different name.
The process to update a frequent flyer account is more complicated—requiring a copy of my marriage certificate and an updated passport or driver’s license. (So no proof needed to change the name on a ticket to fly, but two legal documents needed to help me earn points and get my bags checked for free. Hmmm?)
So for my honeymoon flight, I had to pay for my bags because the frequent flyer name and ticket name did not match, and the documentation needed to get them to match was “in progress”.
The main issue is that the two processes are not connected. I can change my name on my ticket, but until the long frequent flyer change process is complete, I miss points, bags, and upgrades. Ugghh! A process failed.
Once I got the airline situation under control, bad business analysis continued to bombard me via the daily mail. Despite my effort to comply with each organization’s change process, the mail continued to arrive with a humorous variety of names and addresses. My favorite mailing included an envelope, a form letter and a check. All three pieces of the mailing had a different combination of name and address. Many processes failed.
So messing up a name or address change is frustrating and inconvenient, but what if bad business analysis leads to financial loss for the business or customer? What if my financial information, accounting transactions, purchase order modifications, invoices were incorrect?
The quality of an organization’s business analysis affects its bottom line. Understanding and communicating the links or disconnects between policy, procedure, and systems is what gives you value as a BA. BAs prevent risk. BAs minimize loss. BAs prepare organizations to change successfully!
So how can good BAs prevent failed processes and negative customer experiences? Here are a few suggestions:
Create an Event/Response Matrix
An Event/Response Matrix identifies external, internal and temporal events and what happens to the process or system when the event is triggered. If “name change” is an identified event, then analysis would be completed to understand what would happen when “name change” is triggered.
Event/Response Matrices help BAs discover issues and reduce the risk of missed or assumed requirements. “Name change” is a perfect example of assumed requirements. Stakeholders tend to focus on the new features of a system specific to their line of business and often assume that we understand requirements for standard tasks that span the enterprise. We must look “outside-in” with requirements, looking at events outside of the products, systems and business processes; evaluating the impact.
Find the Duct Tape and Bandages
Every organization has duct tape and bandages—little manual processes or databases or spreadsheets or macros that meet a business need but have not been integrated into formal procedures, policies, or systems.
The duct tape and bandages were applied to the business for many different reasons. The primary reason: good leaders found a way to do something cheaper, faster, better while wading through the red tape of official policy or system change.
Identifying and understanding these obscure workarounds can be critical to the success of the organization. We need to evaluate these disconnected practices and determine if they need to be integrated into projects. We need to understand the risks and rewards to determine if the practices should continue or be shared with other parts of the organization.
BAs need to understand how systems share data. Even an informal interface assessment with stakeholders can uncover requirements and minimize project risks.
A few good questions to ask yourself or your stakeholders about interfaces during the elaboration process:
- Where else do we use this type of data?
- Are there existing interfaces between all of the systems?
- Does the current interface meet the business need?
- How does data transfer between systems?
- How do these systems get updated with new data?
- How frequently are changes updated?
Learn About Data Management Strategies
Among other things, a data management strategy defines how an organization moves, integrates, maintains, audits and archives data that is used enterprise-wide.
Does your organization have a data management strategy? Is it comprehensive? Do people actually use it? Is it up-to-date?
Most likely, you will find an answer of “no” or “not really” for at least one of the questions above. So you need to investigate and understand the informal, unwritten data rules in your organization. It is likely these rules will vary across the organization.
So many systems get built and updated without looking at data migration, external events, and the customer experience. BAs add value to the organization when they can anticipate and communicate data management inconsistencies.
Be a Data Integrity Advocate
Given the fact that most companies do not have an effective data management strategy, BAs are left to help business leaders understand the pitfalls of bad or out-of-sync data.
Inform stakeholders how bad data negatively impacts the customer experience and the bottom line. Guide them through decisions about value, risk, and impact.
Today, I am still working through name change processes and resolving errors of the processes I thought I followed correctly! As frustrating as it is, ironically I was in a recent requirements workshop where this exact scenario came up. The discussion evolved and this scenario became a low priority requirement. Why? The volume of customers that get married and move at the same time in a given year is pretty low and the impact and risk to customer value is relatively low. I understand this, and to be fair to my profession, I must conclude that bad data and process is at times the right decision when we must balance value, risk, impact and budget.
Have you bumped into bad business analysis in your day-to-day interactions with companies and organizations? How would you prevent or fix the problem?
Don’t forget to leave your comments below.