Business Analysis Q+A-EN

As a training company, you can imagine all the questions we get from our students. There are some though that we hear more than others. We’ve compiled a list of these and our experts have documented their best answers.

What does a Business Analyst really do?

The question might actually be: what does business analysis really mean? In this rapidly changing, digital, agile world, the business analyst seems to be a role that companies are forgetting or ‘reallocating’. I actually don’t care what you call me, but let me do my analysis and let me help my business succeed! So a BA or a person in the BA role, be it Product Owner, Domain SME, System Analyst, whatever you call them, needs to understand what value good business analysis provides to an organization. The IIBA has a great definition in the BA Body of Knowledge v3.0®: “Business analysis is the practice of enabling change in an enterprise by defining needs and recommending solutions that deliver value to stakeholders. Business analysis enables an enterprise to articulate needs and the rationale for change, and to design and describe solutions that can deliver value.”

In a nutshell, business analysis is helping the business understand itself, and using that understanding to communicate how to drive to a successful solution that will deliver business value. We help the business help itself. The main job within business analysis is asking A LOT of good questions and then figuring out how to best communicate the answers to the team that will provide the solution. That could be formal documentation, informal documentation, verbal communication, drawings, videos, etc. It all depends on your organization, the product or project you are supporting, the team with which you need to work, and the approach you take (agile vs traditional, for example). It means having a huge skill set: communication (oral and written), negotiation, mediation, prioritization, facilitation (meetings and workshops), patience, empathy, attention to detail, big-picture thinking. The list goes on…our Essential Skills for Business Analysis course can help you understand and address each area of concentration.

Do I really have to scope?

Nope, there is never a need to scope. That pretty much ensures that your project will never end, will have problems, and will cost too much. Should I go on? So obviously I’m saying that YES, YOU DO NEED TO SCOPE! Scope will provide you and the entire team some good stuff:

• Clear goals and objectives – how do you know what to do if you don’t have clearly articulated direction?
• Alignment with organizational strategy – if you aren’t tied in to the organization’s vision, then why are you doing this?
• Innovative thinking – if you really understand the problem or opportunity at hand, you can brainstorm more effectively around solutions.
• Identification of impacted parties – get the right people involved early!
• Assists in managing changes – how do you control changes if you don’t have scope to begin with (even on agile projects)?
• Team building / morale building – if everyone understands the direction and are all rowing in that same direction, you have a better chance of good teamwork!

All of this will help drive to the right solution for your business. Get more on scope: Scope Creep’s Impact on Analysis blog post, Leverage the Context Level Data Flow Diagram Quick Tip and Scope Your Area of Analysis course.

What do you need in order to get a user story ready?

A user story goes through what we at B2T Training call the “4 Rs”: Raw, Rough, Refined, Ready. Let’s go through these four stages and I’ll explain why each is important.

• Raw: the initial discovery of feature, function, enhancement or defect, often written in the “As a ___, I need to ___ so that I can ___”. It’s the place-holder with no judgement. Why is it important? All ideas deserve a placeholder for a future conversation.
• Rough: an initial conversation has occurred with the “three amigos” (developer, tester, and product owner). At this point the key points of the conversation are captured in bullet points. This information is used to determine if the story is in scope or out of scope. There should be enough information for a high level estimate.
• Refined: the story has formal acceptance criteria, examples, models, and any relevant requirement information. The team should be confident in their estimate or refine it as needed. All larger epics/stories are sliced or broken down. See our Advanced Agile User Stories course for a deep dive into prioritizing, estimating, splitting, and organizing your user stories.
• Ready: the story should have the business and functional analysis “done” in order to be ready for technical design and development. It’s the team that determines what is “just enough” to be able to sprint with that story without delays or confusion due to missing requirements.

Also, the 3 C’s of User Stories will help keep the purpose of the user story in perspective. See our blog post for more on this concept!

How do I know when I’m ‘done’?
When business analysis is complete? Well, the real answer is probably never, but that’s not realistic! Failing to elicit, analyze and communicate requirements can result in bad decisions being made and/or a team getting ‘stuck’. One of our core values as a BA is helping teams learn to achieve better business outcomes by using “just enough” analysis to ensure they’re building and delivering the right thing. Here are a few quick tips to understanding how much analysis is enough to solve the business problem.

• Make sure the business problem is actually understood (and that we have arrived at the root cause or causes)!
• Understand and involve your stakeholders so that you can set expectations on what you need to help make them successful.
• What we elicit, analyze and communicate should give us enough information to support decision-making and help resolve or mediate conflicting opinions in the business.
• What we elicit, analyze and communicate should clearly depict to the business the solution to their problem.
• What we elicit, analyze and communicate should be enough for the technical team or solution developer to effectively and correctly develop the solution.

Working closely with the business and solution or technical stakeholders can help you achieve the right level of analysis! We recommend attending our Essential Skills for Business Analysis for a deeper understanding of how to determine what “just enough” analysis is for your project.
What are T-shaped skills, and why should I develop them?

A person’s skill set is often categorized as being I-shaped or T-shaped. A person with I-shaped skills has deep knowledge, but in a very narrow area.

A person with T-shaped skills has deep knowledge in a specific area, but also possesses knowledge across a range of disciplines.

In teams, a combination of I-shaped and T-shaped skill sets can prove extremely beneficial. For certain highly skilled tasks (think of some really technical areas) you just need someone who is very talented in that area. You don’t need them to strategize, you don’t need them to innovate, you just need them to do that one thing really well.

By contrast, individuals with T-shaped skill sets are often the “glue” that hold teams together. They can reach across boundaries and draw people together. They know enough about other disciplines to understand how the team’s actions will impact other groups. They are able to look at the bigger picture and ensure that the team stays on the right track. Many organizations use this concept in leadership development programs. Leadership candidates work in a variety of jobs across an organization to help them develop this diversity of skills. For more on T-shaped skills and developing a cross-functional team, take a look at Jacqueline’s From a Dysfunctional to Cross-Functional Agile Team blog post.

How do I know I am not missing anything?
You are likely never going to catch everything and every requirement – you might as well go ahead and accept the fact. However, if you do a good job on the front end, usually the pieces come together by the end. Asking the right questions is one of the most critical aspects of knowing you aren’t missing something. Be sure to ask: “Why are we doing this?”, “How are we going to do it?”, “What do we need in order to accomplish our goal?”, “What amount of effort is it going to take?”,  “What data do we need?”, “What processes need to be adjusted?”. For even more great questions, see our Ask the Right Questions Checklist. Along the way, you’ll have to fill in information that you missed as you get down to the details… and its actually OK that it gets filled in later rather than sooner.
Scoping is an important element to any project. Go back to your scope diagram and make sure that you understand the big chunks, and then as you detail into them, they will help you identify the smaller chunks. It will also help you identify how to test those. Oftentimes, when you’re considering testing your solution, you realize a missed detail that you’re going to have to go back and pull into the project. For more on scoping and managing change, check out Jacqueline’s blog post: Scope Creep’s Impact on Analysis.
Also, having the right people involved is critical; requirements gathering, management, validation, etc. is a team effort. Don’t go it alone; use the resources at your disposal to take a second look and to look at it from their perspective. Someone might even remember something from a previous project. Ali details some more tips on validating your requirements in her blog post.
How do I keep the business from going straight to the solution?

We all know that this can be one of the most detrimental aspects of a project… and something that happens all the time (even to BAs). Solutions are the shiny new object, and unfortunately, in our digital world they are everywhere, so even a technology novice can make solution recommendations. However, solutions can’t be determined without analysis. Just because something looks good doesn’t mean it will work for the need of your organization.

The real thing to think about is how you roll them back. Don’t get frustrated or be immediately dismissive. Accept the solution, but start asking questions to get to the core of the thought process and business need. For example, “You’ve already gone through the thought process, and you have a solution. Help me understand so the team can make sure we’re hitting the mark,” and “What are the overall needs that we have to accomplish?” Get back to the business requirement type stuff. Then, you can make a determination if the solution presented will achieve business value. For more help with understanding business value, get your Business Value Framework in Kathy’s Business Value Framework and a Really Big, Strong Guy blog post.

If you see a disconnect between the need and the proposed solution, start having conversations about maybe changing that solution. This can be hard for a BA, and there will likely be politics involved, so acknowledge their vision and creativity, but don’t be afraid to identify the gaps and validate your recommendation. Also, don’t forget – even though they think they know what they want, they are still coming to you because they need you.

What do I do if I get put on a project in the middle of it and don’t understand what’s going on?
Get your hands on everything that you can and do it fast. Stick with your PM, your sponsor, or whatever key stakeholders that you know, and determine where things are. Good places to start are to:

• Read the business case. Find out what the goals, objectives, and outcomes are for the project.
• Review any kind of roadmaps, and milestone documents that can summarize where the team has been and where they plan to go.
• (if applicable) Get a hold of user manuals and start training yourself so you understand either the package that you’re implementing or the tool set that you’re going to have to use.
• Do your homework on the industry. Find as much background information as you can to help come up with baseline questions.

Once you’ve done some  research, start asking questions to clarify and find out new information! Not only does asking questions help you understand the project, it helps build relationships. Another great resource for getting started in your analysis is our Ask the Right Questions Checklist. These questions provide a framework for eliciting information about processes, data, and business rules. The bottom line is to get dirty and don’t be afraid to ask the questions!
How technical does a business analyst (an IT business analyst) need to be?

There really is no direct answer. On a scale of 1-10, you need to be a 7 on the technical side of what your role needs, what your team needs, or what your organization needs you to be. Also, you have to define what you value. Do you like being technical? Do you like the technical side? Do you like to keep up with new languages and technical solutions? Do you like to know the latest and greatest thing?

A non-technical BA is going to be talking to the business about their business data and understanding the data needs they need to run the business. Once these business needs are determined, the developer and technical leads can then take over to determine where the data is actually stored, what database they should use, what server it will be on, etc.

However, if you are working with offshore developers, they might need to know exactly how you want it done and then they will code it. If this is the case, then you need to be really technical. Some BAs are great at understanding the business and can dip into the technical stuff enough to have a conversation but aren’t able to write SQL queries. This isn’t a bad thing, he just might not be the best person to fill the role on that team.

As with most BA related questions, it depends on your team needs and who can fill those needs. That said, if you’re not on the technical side, you need to know enough to have a conversation. Take a class or job shadow someone on the technical side. Think about it like a car, if you are going to drive one you need to know a couple of basic things, but you don’t need to know how it was built.

How much detail should I put into my requirements? Is more always better?

Actually, more isn’t always better. The rule of thumb is to stop adding detail when everyone who needs to use the requirement understands it.

As an example, let’s say you’re developing a process flow. In it, there’s a step to “Enter Customer Profile Data”. It’s certainly possible that you could expand on that, and describe how to enter information in the profile step by step. But should you? Only if you need that level of detail to ensure understanding.

It’s important to note that you have to know your audience to determine when you’ve got enough detail. Also remember that models and diagrams can be used to express complex requirements in a concise way, so if you find yourself overwhelmed with text details, consider an alternate way of representing the information.

What percentage of the overall time spent on a project should be allocated to analysis?

There’s no standard for this, because there are so many variables that come into play. Think about the “Three Ps” —  People, Project and Process:

A project making minor changes to a well-understood system is likely going to need far less analysis than one that is launching an entirely new line of business. A project that involves a large number of stakeholder groups with competing needs may need more analysis than something that involves only a single group of users.

A solid analysis plan or approach will help you determine the amount of analysis to perform. And, if you’ve been given a tight deadline or insufficient resources, it can help you negotiate for the time and resources you need to do effective analysis. Ali writes more on this in her 4-Task Solution for Estimating and Defending Your Analysis Plan blog post. Our Estimating Analysis Time Template will also help provide structure to your planning!

Are process maps required if I’m using Agile?
Stop me if you’ve heard this one before… but it depends! Process maps are all about communication. If your team is successfully communicating without process maps, more power to you. However, process diagrams frequently add value by providing a visual component – they illustrate how work gets done in ways that text descriptions alone can’t.
In addition, a good process map not only shows relationships, handoffs, sequencing, and flow, but also provides additional information at a glance. For example:

• Swimlanes or shape colors can emphasize who does what.
• Icons and callouts can focus attention on what’s important at this moment.
• Hyperlink indicators can signal when additional documents or resources are just a click away.

Process maps of various types – flowcharts, swimlane diagrams, BPMN diagrams, value stream maps, workflow diagrams – all exist because a picture can be worth a thousand words. Use them when a visual assist will help your team communicate more effectively. For more in process mapping check out our Business Process Analysis course or read these blog posts: The Unofficial Guide to Flow Chart Symbols.
Do I really need a degree in Psychology to be a BA?

No, you don’t. However, understanding and communicating effectively with many types of people is a key job requirement. The more you can appreciate the idiosyncrasies of the nerds in IT and the dollar-driven motivation of the business folks, the better you’ll succeed at being the bridge between the two. And you’ll be even more effective as a BA when you realize that both of the descriptions in the preceding sentence are just stereotypes: There are “business people” who excel at business, psychology and communication, just as there are “computer people” with serious technical credentials and some who struggle to get their points across.

You don’t need a degree in psychology to be an excellent listener, negotiator, and influencer, but understanding a bit more than the average person about human nature will make you a better BA.

Do you have a question about business analysis? Let us know and we’ll answer! 

Let us know and we’ll get you an answer!

Submit Question