Author: Angela Wick

A Business Analyst’s Best Friends: The Business Sponsor

Written by Angela Wick on March 12, 2013. Posted in Articles. 1 Comment on A Business Analyst’s Best Friends: The Business Sponsor

Successful BAs are the calm, center point of a complex group of interrelated people, roles, and processes. BAs maximize their value to the organization by ensuring the alignment of stakeholder needs and value.

In order to promote alignment, BAs rely on strong relationships with many friends. BAs need to anticipate their friends’ needs and learn how to influence cooperation.

In January, I set the stage for a monthly series describing the BA’s best friends. This month’s friend is the Business Sponsor.

How does the Business Sponsor benefit from a BA?

To answer this question, consider the Business Sponsor’s primary concern: Will the solution meet the needs of my organization, add value, and make me better off than I am today?

On behalf of the Business Sponsor, the BA protects the vision and the goals the solution is set out to bring. The BA safeguards the connection between the Business Sponsor’s needs and the project team’s solution. Here are a few common BA functions that secure the link between needs and solution:

Needs Analysis: Especially, valuable when the Business Sponsor does not have a clear or accurate vision. The BA may be acting as a consultant or evaluator—assessing the needs of an organization and recommending system and/or process changes. In this case, the BA identifies the needs and works with the sponsor to address the needs to create maximum value.
Traceability: The BA ensures the solution satisfies the requirements and all requirements trace back to a business need.
Change Control: BAs facilitate the change process to ensure that changes align with business needs and maximize value.
Full Life Cycle Participation: BA value is maximized when BAs participate in all phases of the project. The BA protects the project vision by providing context and history when critical issues arise during development, system testing, user testing, and implementation.

What makes a top-notch BA from the Business Sponsor’s perspective?

Business Sponsors are most impressed with BAs that can adjust their communication style, both verbal and written, to their audience. Whether in a meeting, on the phone, via email, or in person; the Business Sponsor likes a BA that is confident, makes their words count, and uses an appropriate level of detail.

Given that different Sponsors seek different information in different formats, how is a BA to know what level of detail the Sponsor wants? I don’t think there is one answer to this, except to do the research to find out. Here are few hints:

Listen and observe. Take cues from the Business Sponsor. Who are his “go-to” managers? How do they present information? When the Business Sponsor presents information what format does he use? Observe body language. What seems to energize the Business Sponsor and what causes frustration, eye rolls, sighs, crossed arms.
Prepare. When meeting with the Business Sponsor, anticipate needs. Who will be in the meeting? What topics will be discussed? What issues might arise? What documentation will you need?
Prioritize. In most cases, direct interaction with the Business Sponsor is limited. When you have the sponsor’s attention, be sure to prioritize your needs so that you get the most important topics out of the way first.
Get visual. A picture says 1000 words! A great diagram can make details easily digestible…even for the Business Sponsor.
Learn how to draw, spontaneously. Most interaction with the Business Sponsor happens when critical issues are escalated. Time is short and you need the sponsor to make a decision. Use simple, spontaneous whiteboard pictures to define the problem and propose solutions.
Master the one-pager. Unless you have a Business Sponsor who loves details, learning how to communicate with a one-page document is critical. The one-pager forces you to focus on the most important information. Status reports, project dashboards, decision sheets, or recommendations are perfect candidates for the one-pager. Use color, pictures, or diagrams when appropriate.

What frustrates a Business Sponsor about the BA role?

Too much information, too often.

Most Business Sponsors do not have time to digest massive amounts of detail. They delegate details to managers or SMEs. Given that, BAs need to know when to engage the Business Sponsor. Here are some common reasons a BA might engage the Business Sponsor:

Understand project and solution vision and goals
To approve final documents.
To present a summary of the technical solution.
To escalate critical issues that may compromise value.

The BA needs to remember to use time with the Business Sponsor wisely. Summarize. Demonstrate buy-in from trusted business managers. See the previous question to guide format and level of detail.

How to say no to a Business Sponsor?

The customer is always right! Assuming the Business Sponsor provides funding for the project, I am not sure a BA would say “no” to a Business Sponsor.

However, the BA is a key source of information. BAs help the Business Sponsor understand the ramification of changes, the impact of decisions, the pros and cons of recommendations.

BAs need to speak up when there are issues, communicate why a new direction is inappropriate, look out for risks, impacts, bottlenecks, and assumptions.
BAs also provide context for decisions—real world scenarios that may highlight the need for change or the need to stay the course.

How to influence a Business Sponsor to get what you need?

In most project environments, a BA needs the following things from the Business Sponsor:

Direction – clear vision, defined scope and prioritization of needs and goals
Decisions – make timely, well-informed decisions
Influence – ability to escalate and resolve issues, build consensus, motivate
SMEs- make appropriate resources available to the project

If any of these are missing, how do you get them?

Determine what motivates the Business Sponsor. Listen, review documentation, or ask. Sometimes success hinges on accuracy, timing, cost, forward progress, visibility, efficiency, innovation, creativity, status quo…
Frame your needs within the sponsor’s definition of success.
a. Example 1: If your sponsor values organizational efficiency, explain how access to the correct SME will ensure that every process will be reviewed and optimized.
b. Example 2:If your sponsor values accuracy, explain how accuracy of the data will be affected if an issue is not resolved before implementation.
Determine the proper path to communicate your needs. When interacting directly with the Business Sponsor, present accurate information at the appropriate level of detail. If you don’t have direct access to the sponsor, use your influence with the Project Manager or a key SME to get what you need.

How to communicate the value of the BA role to a Business Sponsor?

In most cases, Business Sponsors delegate project details to managers or SMEs. Sponsors only appear when key decisions need to be made. During these decision points, BAs demonstrate their value to the Business Sponsor.

BA value shines brightest during project transitions when issues arise with potential to impact timelines and budgets. Decisions need to be made quickly and BAs provide the information needed to make a good decision.

As requirements are wrapping up, as UAT ends, during the “go/no go” implementation decision, BAs need to be prepared to speak up.

BAs see the big picture. They understand the impact of potential decisions and communicate the risks and benefits. Asking relevant questions and providing clear, concise information. Often the Business Sponsors are engaged and present and these critical times and this is the perfect stage to demonstrate your value.

What do you think?

BAs: How do you find out what level of detail your sponsor needs?
Business Sponsors: What are the key pieces of information you need from the BAs assigned to your projects?

Don’t forget to leave your comments below.

A Business Analyst’s Best Friends: The QA Lead and their Team

Written by Angela Wick on February 19, 2013. Posted in Articles.

Successful BAs position themselves in the eye of the project storm. They are the calm, center point of a complex group of interrelated people, roles, and processes. BAs are in a prime position to ensure—when the project storm settles—that all pieces are connected and aligned to maximize value to the organization. In order to do this, BAs rely on strong relationships with many friends.

In January, I set the stage for a monthly series that describes the BA’s best friends. This month’s BA friends are the QA lead and their QA team.

How does QA benefit from a BA?

QA teams need BAs to provide clear requirements with context. QA teams need context in order to plan their testing strategy; by context I am referring to the set of circumstances, environment, and facts that surround a particular project, requirement, and/or solution

The QA Lead and their team members want to understand context for the project and for the requirements:

Why is the project important?
How does the project fit into the big picture of the organization?
How does the requirement fit into existing business processes?
What business scenarios trigger a requirement?

For example, BAs might provide a requirement to add a new button to a system screen, a screen mock up, or a lengthy list of outlined text requirements. The QA team cannot test these requirements properly unless they understand why/when a user would update the button and what events should be triggered by the new button, what capability does the button provide? What is the acceptance criteria for the requirement/story/design? How/When and in what situations will we know it is working?

What makes a top-notch BA from the QA team’s perspective?

Obviously, the tactical BA requirement skills are critical, but top-notch BAs bring a variety of soft skills to the project environment. The QA Lead appreciates BAs with these top-notch soft skills:

Effective Communicator
A BA with effective communication skills increases the efficiency of the QA Lead. If the QA Lead trusts the BA to communicate delays, issues, requirement changes, priority changes, etc., then the QA Lead can focus on testing resources and doesn’t need to waste time trying to chase down the BA or PM for project updates.

Excellent Organizer
BAs are responsible for creation and maintenance of the requirements package. Obviously, requirements are the primary input for test plans and test cases. QA teams want access to the most recent requirements. They do not want to get lost in the chaos of version control issues. They want to know when requirements change and where/how changes are documented. They want to know when and how outstanding requirement issues are resolved.

Respected and Knowledgeable Partner of Subject Matter Experts/Business Users
The QA Lead and the QA team members rely on the relationships the BA has with business users and SMEs. The BAs knowledge and partnerships are critical when QA teams need quick decisions about priorities, issues, and defects.

What frustrates a QA team about the BA role?

The QA team wants testable requirements from the BA. This sounds simple and obvious, but how would you define “testable”? Here are some tips for producing testable requirements:

Invite QA to participate in the requirement process. Including the QA team early in the elicitation process will help them gather context and will ensure the requirements process meets their needs.
Be precise: Avoid pronouns like “it”.
Be specific: Avoid terms like “many” or “all” or “most”. BAs need to list groups that are applicable or not applicable.
Identify Links or Dependencies: Be sure that QA understands the dependencies between features or requirements – visual models are a huge piece of doing this right!
Break it down: Be sure the requirement has been decomposed…it’s not divisible…can’t be broken into smaller requirements.
Describe Scenarios: If a requirement is only true in a specific business scenario, then describe the scenario in the requirements for the purpose of testing or link requirements with specific job functions or processes.

How to say no to a QA Lead?

Points of tension between a BA and the QA Lead tend to center around changes that would impact resources and timelines. Too frequently, QA time is cut short because of delays in analysis, design, or development. Often requirements change or features are added when system testing is already underway.

Here are a few examples of why and how a BA might say no to a QA Lead:

QA wants final requirements, but they are not complete yet. Be sure to proactively communicate any delays. Help the QA lead understand the impact of moving forward without complete requirements. Help them understand which pieces are incomplete, what is likely to change, and if some testing can move forward without a complete requirements package.
QA needs more time to complete testing. If the deadlines are negotiable, then it might be appropriate for the BA to work with the QA Lead to advocate for more testing time. If the deadlines are firm, the BA can help the QA Lead prioritize test cases by business need and risk level.
QA wants to save time by doing a thorough system test but skipping integration and regression testing. In some project environments, this might be acceptable and even common. If it introduces too much risk in your project, then you need to help your QA Lead understand the risks. If the QA Lead is willing to accept the risk, then you may need to escalate your concerns to the project manager or project sponsor.

How to influence a QA Lead to get what you need?

To influence the QA Lead a BA needs to understand how the QA Lead defines success. If the BA can frame their needs within the QA Lead’s definition of success, then the BA will have a better chance of getting needs met.

QA Leads want a successful testing cycle. In most cases, this means nothing major breaks when the system goes live. Other components of success might include: meeting deadlines, quick issue resolution, quick and correct defect resolution, and effective workarounds for unresolved issues.

If a BA needs to add ten new requirements to the QA workload, the BA should be prepared to communicate the priority, risks, and dependencies of the new requirements. The BA should be prepared to discuss how the QA team can be successful despite the new requirements.

How to communicate the value of the BA role to a QA Lead?

When initiating a project with a QA Lead, discuss expectations. Ask them what success means. Let them know about the skills and experience you bring to the project…especially the soft skills that will help the QA process run smoothly:

Requirement prioritization
Issue resolution
Risk management
Defect Resolution
Relationship Management with business
Problem solving and critical thinking

What do you think?

BAs: How do you make sure your requirements are testable?
QA Team Members-What are the characteristics and skills that the best BAs bring to a project team?

Don’t forget to leave your comments below.

A Business Analyst’s Best Friends: The Project Manager

Written by Angela Wick on January 22, 2013. Posted in Articles. 16 Comments on A Business Analyst’s Best Friends: The Project Manager

Successful BAs position themselves in the eye of the project storm. They are the calm, center point of a complex group of interrelated people, roles and processes. BAs are in a prime position to ensure—when the project storm settles—that all pieces are connected and aligned to maximize value to the organization. In order to do this, BAs rely on strong relationships with many friends.

Last month, I set the stage for a series that describes the BA’s best friends. Each month, using the following questions, I will explore the relationship between the BA and one of their key stakeholders.

How does this stakeholder benefit from the BA?
What makes a top-notch BA from their perspective?
What frustrates this stakeholder most regarding the role of the BA?
How to say “no” to this stakeholder?
How to influence this stakeholder to give you what you need?
How to communicate the value of the BA to this stakeholder?

Without further adieu, please allow me to introduce THE PROJECT MANAGER.

Obviously, the BA’s relationship with the project manager can vary based on the structure of the organization; the project size and structure, and the experience level of the BA or the PM.

Despite these variations, the key components of the BA/PM relationship are collaboration and communication. The BA and the PM must work closely together to manage solution scope, risks and stakeholders.

How does a PM benefit from a BA?

Scope, schedule and cost are the Project Manager’s primary concerns. PMs rely on BAs to provide timely information about anything that might impact scope, schedule and/or cost.

Because the BA is positioned at the center of an active and evolving project, they are the eyes and ears of the project manager. BAs see details that the PM may not—connections between people, processes, products and timelines.

The key word here is timely. BAs need to understand when to communicate potential scope, schedule and cost impacts to the project manager. In most cases, sooner is better than later. Proactive communication gives the BA and the PM time to plan an approach.

Obviously, collaboration and communication are two-way streets. The PM needs to communicate context and details with the BA. I often hear from PMs that their biggest fear of BAs is “scope creep.” Fearing that BAs will promise things to stakeholders that increase the scope of the project beyond what the PM has planned. There is a balance here that I hope each BA takes very seriously. The balance is value vs. scope boundaries. The BA role needs to collaborate with the PM and champion scope changes where the value of the solution is at risk, while ensuring that scope changes that do not add value are kept at bay.

What makes a top-notch BA from the PM’s perspective?

The PM wants timely information from the BA. Top-notch BAs will do more than present a problem. They will present the issue and an approach, or a few potential approaches. Top-notch BAs keep the PM informed, ask for help when they need it, stay connected to other BAs and project teams to help PMs see impacts, build great relationships with stakeholders, build trust and ease users into changes.

Top-notch BAs have a broad vision. They can focus on the detailed requirements, but they understand how their piece of work fits into the larger project and organization at large.

Top-notch BAs offer strategy. They understand how pieces of the organization connect and how they align them to give the organization value.

Top-notch BAs use the PM’s time well. They come prepared to meetings with a list of questions and concerns and approaches. Be efficient with the PM’s time. If you don’t have a regularly scheduled team meeting with your PM, then set a recurring appointment with them so that you have time each week to touch base. Provide a simple, concise status update each week, indicating things that might impact schedule, scope and cost.

What frustrates a PM about the BA role?

Scope creep is arguably the biggest fear PMs have about BAs and their work. Successful PMs deliver projects on time and within budget. Scope creep is the biggest threat to project management success.

In many cases, project managers are pressured to give firm cost estimates and implementation dates before the scope of the project is clearly defined. This means PMs need to understand how the elicitation and requirements process is evolving. Are BAs uncovering issues that could impact timeline? Are new business needs being uncovered? Are risks avoidable without impacts to time and cost?

A great BA knows the scope and objectives of the project and gathers requirements that link back to them. Through the requirements process, the BA ensures that users asking for other requirements (not in scope) are managed effectively, and requirements gathering sessions are not reeling in “features” that are not in the scope of the project.

The BA understands when scope should be changed in order to ensure the success of the project and communicates these concerns to the project manager in a timely manner.

How to say no to a PM?

Sorry to answer a question with a question, but — why would a BA need to say no to a PM? Here are a few examples:

The PM sets an unreasonable deadline for the completion of the elicitation process.
The PM only budgeted half of the BA hours needed to effectively support the project.
The PM asks you to prioritize her project above the work you are doing on another project.
You discover a new feature that is required for the project to be successful but the PM says you need to move forward without the scope change.
You uncover a risk that needs to be addressed. Proper mitigation would delay the project and add significant cost. Your PM does not agree and directs you to move forward.

So how do you say no?

Well, we all want to be successful. One way to say no to a PM is to help them understand the situation in the context of their definition of success. For many project managers, a satisfied project sponsor is the definition of success. For other project managers delivering the project on time and within budget equals success. I have even worked on some project teams where success involved convincing the stakeholders to cancel a project.

Ask questions or provide information that helps the PM key in on how his ability to be successful might be affected; focus on the risk:

If my requirements elicitation or analysis time is cut, critical requirements will be missed that will delay user acceptance or cause issues at implementation that would be extremely costly to the project in terms of customer satisfaction, cost to fix issues and value ultimately delivered.
I need to focus on this project right now, but I will meet the deadlines we agreed on for your project.
The project sponsor will not be satisfied with our product if we move forward without this feature.

As I said before, timely communication is the key. Don’t wait to tell the PM two days before a deadline that you need more time. Don’t fully elaborate requirements for a new feature before you notify your PM. Communicate your version of no as soon as it makes sense.

How to influence a PM to get what you need?

As a BA, the primary things you need from the PM are support and information. BAs need to understand the expectations and priorities of the larger project team and the organization. The PM is a key resource for this information.

The PM also offers support and back-up for the BA, often in the capacity of protecting scope and timeline. PMs can help the BA get key stakeholders to participate and is an escalation point for helping the BA resolve issues that are impeding progress.

A BA needs to help the PM see consequences if the needed information of support is not provided. The consequences should be in terms of scope, cost and schedule. That is the language of the project manager.

In order to clearly define the scope, I need to get some quality time with this key stakeholder.
In order to meet my deadline, I need your help to escalate this issue.
If we don’t find a way to mitigate this risk, the product delivery will be delayed by three months.

How to communicate the value of the BA role to a PM?

Ask them what success looks like for each project and then tell them how you can help them be successful.
• Build trust with stakeholders
• Keep open communication on schedule, risks and issues
• Help manage scope

Your Thoughts?

BAs: How do you build trust and promote collaboration with PMs?
PMs: What are the characteristics and skills that the best BAs bring to a project team?

This article is the second in a 13-part series about BAs and their best friends. Next month’s friend: The QA Lead

Don’t forget to leave your comments below.

A Business Analyst’s Lucky 13 Best Friends

Written by Angela Wick on January 8, 2013. Posted in Articles. 1 Comment on A Business Analyst’s Lucky 13 Best Friends

Who are a Business Analyst’s best friends? Who would like to be and Why?

Who are the people we interact with most on the job?

What is it that makes these relationships work and serve our end goal of providing value to the organization?

As Business Analysts we face changing project situations that challenge our skills and relationships with many stakeholders. He have an opportunity to serve our stakeholders and team members in many ways to add value to the solution being delivered.

We are often labeled as the ones that gather and document requirements. In reality, we are the critical link in the middle of a complex group of interrelated people, roles, and processes. Our role is in the prime position to ensure all these pieces are connected and aligned to maximize value to the organization.

How are we viewed by all of these people we work with? How do we want them to view us?

I would like to start a series about the “best friends” of BAs – all the major roles that BAs interact with. The roles I am currently targeting for this series are:

CIO – Chief Information Officer
BA Manager
Project Manager
Product Manager
QA & QA Lead
Developers
Tech Lead
IT Application Managers
Business Sponsor (Director/VP Level)
Business Subject Matter Expert or Domain Expert
Business Manager
Administrative Assistant
Project Controller

With each role (and more with your ideas), I would like to start a series in 2013 about:

How does each of these roles benefits from the BA role
What makes a top notch BA from their perspective
What frustrates these roles most from a BA
How to say “no” to these roles
How to influence these roles to give you what you need
How to communicate the value of the BA to these role

To start us off, here is a brief summary of each stakeholders needs from a BA, as we move through 2013 we will visit each in detail with the questions above.

CIO – Chief Information Officer
CIOs need a lot from BAs, one thing I will focus on is the need for BAs to collaborate and build great relationships with the project team and stakeholders so that the right requirements, solutions, priorities and risks are identified to maximize the value of the solution to the organization.
BA Manager
BA Managers not only need BAs to serve clients and projects in maximizing solution value, but also need BAs to work together with peer BAs to share best practices, lessons learned, risks, cross functional impacts and risks. They need BAs to be continuous learners of their field, mentor each other, and help grow the BA talent in the organization.
Project Manager
PMs needs BAs to collaborate on scope, planning, risks, and stakeholder communications. Scope creep arguably the biggest fear PMs have of a BAs work. Risks and stakeholder communications and collaborating on these is cortical to a PM managing the scope, cost, and schedule.
Product Manager
Product Managers are focused on marketing and product usage and development. Some focus on one more than the other. They need BAs to help understand markets, users, provide options and alternatives, and collaborate to truly understand the product features that they are looking at implementing.
QA & QA Lead
QA teams need to understand the details and big picture requirements. They need BAs to provide understandable requirements with context. Context is key to QA teams planning their test approach to maximize risk and the value of the QA process.
Developers
Developers typically have two concerns about requirements from BAs: Requirements are too vague or they are too detailed. What gives? Too detailed means that BAs are not providing enough context and/or are providing too much design details without looking at options and alternatives. Too vague means that requirements are lacking critical details about the Who, When, and Why.
Tech Lead
Context and non-functional requirements are king for Tech Leads, they are looking at architectural options to effectively produce potential designs to meet the need. Tech Leads are also looking for capability driven requirements statements to ensure that they can leverage existing technologies.
IT Application Managers
Context and options/alternatives are important to these Managers. They are looking to know what pieces of the solution requirements will their teams need to be potentially involved with.
Business Sponsor (Director/VP Level)
These executives need high level pictures and visuals about the solution and impacted areas, people, external players, data and processes. Also knowing key risks are critical to their needs.
Business Subject Matter Expert or Domain Expert
SMEs need to know where their detailed knowledge fits in and where there are still gaps that they can fill in. They are full of detailed knowledge but don’t always know when to give what knowledge. So a framework with context to help determine where detail goes is very helpful.
Business Manager
Business Managers want to know the big picture and how it will impact their teams. WIIFM – What is in it for me? How will this help my team, impact my team or change my team. With this focus they can better participate and collaborate on requirements.
Administrative Assistant
Admin Assistants of the executives you are working with need to know why your meetings are important to the executive they are supporting. Why do you need the executive in the room? This helps them determine the level of importance the meeting has compared to other meetings the executive is scheduled into that day and time.
Project Controller
Project controllers need to understand your true status towards milestones on the project plan, your risks and any insight into the project risks you can provide as well is issue resolution paths and ideas. They are trying to manage a lot of details, often without much context. Your view into estimates, timelines, risks, and issues helps them manage them and help you collaborate with the PM better.

Don’t forget to leave your comments below.

“I Said My Name Is . . .”

Written by Angela Wick on November 20, 2012. Posted in Articles. 1 Comment on “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.

Understand Interfaces

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.