Establishing clear and measurable business analyst performance metrics and KPIs is no easy task. The business analyst role is interdependent on contributions for other team members, and many of the best business analysts excel based on soft skills and contributions that are inherently more difficult to measure.

Why Measuring Business Analyst Performance is Important

High-performing business analysts are essential to the success of software and business improvement projects. Business analysts help everyone get clear on what the problem is and how to solve it. Their contribution to clear requirements helps everyone else be more efficient and successful, which ultimately impacts the performance of the entire project.

Meaningful performance metrics help ensure that business analysts keep their attention on what matters. Success as a business analyst is not about writing more requirements, holding more meetings, or, really, doing more of anything!

At the end of the day, business analysts add value by bringing clarity to project outcomes and getting the business to own the solution. Just because this seems difficult to measure, doesn’t mean we shouldn’t measure it to the best of our abilities.

KPIs for Business Analysts

When I think about high-level business analyst performance, the following questions come to mind:

1. Does the project deliver the anticipated value? Does the project meet the objectives of the business case?
2. Are the stakeholders aligned around the project concept? If you asked each of them individually about what is to be achieved, would you get the same or at least consistent answers?
3. Are the stakeholders satisfied that the scope being delivered is the best possible solution to the problem they are trying to solve?
4. Does the implementation team deliver on the requirements without a lot of wasted effort? Did they understand what needed to be accomplished?
5. Is the test team able to validate that the final application met all the requirements or do they come across areas of ambiguity that need to be addressed?
6. Are there big surprises at the end of the project? Do unexpected requirements come up? Every project will experience a bit of churn toward the end as you flesh out the final details, but missing a big piece of functionality or a critical business process is a sign that the business analysis effort was lacking.
7. Did the business analyst have a business analysis process and create a business analysis plan? How close was the actual work to their intended plan? What was the root cause of any variations?
8. Did the business analyst choose the most appropriate requirements documentation for the type of project and methodology in place?
9. Is the business happy? Do they find value in what was delivered? (A no answer can have many root causes, but a yes answer is typically the sign of good business analysis work.)

If having a business analysis process is a new concept, check out this video on our 8-step business analysis process framework.

>>Plan Your Next Step with a Free Workshop

While this is a lot of information, you might be wondering exactly what steps you can take. We offer a free Quick Start to Success workshop  that will help you figure out your next step.

Click here to learn more about how to start your BA career

Taking Project Considerations Into Account for Business Analyst Metrics

Another way to evaluate the performance of business analysts is to consider aspects of the project:

• How many stakeholders were involved? From how many different areas of the business? And at what level of the organization?
• How much communication was necessary? (Meetings, messages, emails, etc)
• How many deliverables (business processes, use cases, user stories, data models, etc) did the business analyst need to create?
• How many systems were impacted?
• How many technical stakeholders were involved?
• How up-to-date is the current state documentation? Does it even exist or did the BA need to create it to kickstart the project?
• How long did the business analysis effort take?
• How many defects were due to missed requirements?
• What was the end result or ROI of the project? What benefits were delivered or costs saved?

Again, you are looking to show that your business analysts lead teams to alignment and clarity as effectively as possible, given the complexity of the problem, solution, and stakeholders involved.

How to Measure the Performance of Business Analysts

One thing that makes measuring business analysis performance so challenging is the interrelationship between the business analysis effort and that of the team. If the business analyst does a great job preparing for meetings, invites the right stakeholders, and then they don’t attend or they come unprepared, should the business analyst performance be downgraded?

Most likely, your answer would be no! But many business analysts today are seen as bottlenecks who miss deadlines or deliver incomplete requirements, when the reality behind the measurement is that they are lacking stakeholder engagement on their projects.

A good business analyst will be proactive and strategic, they will gain buy-in from stakeholders, and smooth the path to engagement throughout the project. But in some situations, their hands are tied and they are unable to break-through certain areas of resistance.

To compensate this, any measurements need to be considered in context. Did the business analyst manage what they could? Did they go above and beyond to gain buy-in and engagement? Did they elevate risks? Did they ask probing questions? Was their communication clear and actionable?

This is what you are looking for in a great business analyst. So be sure your measurements aren’t just numbers on a spreadsheet without context – you are likely to get exactly what you measure, which might not be the outcomes you actually want!

>>How to Learn the Foundational Business Analyst Skills

When you join The Business Analyst Blueprint® training program, you’ll gain real world experience in the industry-standard techniques and business analysis processes so you can upgrade your skills, bring a fresh perspective to your business analysis approach, and know exactly what to do on your software projects.

This can bring up a lot of fear and uncertainty in an already uncertain time.

I, along with Disha Trivedi, a senior business analyst and Bridging the Gap instructor who has worked from home for the last few years, hosted a complimentary coaching session. You can catch the replay below – and be sure to scan down for a summary of tips and resources.

Working From Home – Challenge or Opportunity?

While working from home is a new challenge for many of us, in every challenge lies an opportunity. We have to be willing to step away from the fear, worry, doubt and open ourselves up to the opportunities all around us.

For example, this situation could shift the needle a bit and help organizations embrace the effectiveness of remote work so it becomes more standard practice.

As BAs, we have a great opportunity here to step up as leaders. To show how we can work effectively remotely. To be the glue that teams absolutely need to stick together in this challenging time.

Business analysis as a practice is more important than ever. Our businesses will be making significant changes over the coming weeks and months to respond to these events. The businesses that adjust will survive – and some will even thrive. How can we help our organizations capitalize on opportunities?

Finally, cultivate a sense of gratitude. So many have jobs where working from home is impossible, and are either suffering financially or risking exposure for themselves and their families. We have an incredible privilege to be given the opportunity to continue with “business as usual” from the safety of our homes.

Working from Home – Set Yourself Up for Success

Your Workspace

Your physical work space will help you focus and be productive.

• Separate desk space.
• Monitor and docking station.
• Comfortable chair.
• Headset for conference calls/video sessions.

While in long-term work-from-home situations, it would be natural to expect organizations to cover the additional costs of working from home, it’s important to give our employers some grace right now as events unfold and they figure out how to best support their employers through these new challenges.

Work Hours & Breaks

Decide in advance what hours you will work and when you will take breaks. Since you’ll be at home, consider what will serve you and your productivity best. Are there opportunities to start early and take a longer mid-day break for a workout, shower, and lunch?

Support

What support do you need from your family? Your team?

Connectivity

Is your connectivity adequate for screen sharing and video conferencing? If you do not have high-speed internet, now is a great time to see if you can upgrade. Your employer may cover this expense.

VPN connections can slow down connectivity. Explore what you can do (within company policies) outside the VPN.

Have your Outlook web access link handy, so you can access email even if the VPN goes down, and a list of important phone numbers so you can reach out for support with any connectivity issues.

A hot spot on your phone is also a great back-up.

Priorities

Ask and confirm your organization’s priorities. Likely a lot has shifted. So check in now about this. And again later in the week, and then next week. Things are moving so fast, and organizations are trying to respond the best they can. Checking in to ensure that you are working on what’s most important is key.

Our Project Prioritization Organizer template toolkit will help you identify, sort, and create buy-in on organizational priorities.

Also incorporate your personal priorities for the day, and realize that your priorities may shift from day to day.

What if your kids are at home?

While working from home while caring for your children will impact your work time (there is no way around it), we’ve found these strategies help us stay focused and productive.

• Collaborate with your partner to be clear is who in charge at various times. We like to make day-to-day decisions based on the times we have calls.
• Set your kids up with activities (like new craft projects) while you do less focused activities (like catching up on email).
• Allow yourself grace when it comes to technology/shows. The normal standards might need to bend a little.
• Incorporate kids into activities they can be part of – like workouts and meal prep. Involve older kids in chores.
• And be OK with the fact that your kids might show up on a video conference or interrupt you in a meeting. Everyone is working home with kiddos. Expect your employer to show some compassion to the situation.

Working From Home: Practical Virtual Communication Strategies

Be proactive

This situation is new to everyone. Reach out over waiting to be reached out too. Teammates, management, stakeholders. Aim for 1-1 connections too.

Set expectations for meetings

Are people expected to share video? Then be clear about that in your meeting request.

At the beginning of the meeting, go over the meeting agenda and let them know what to expect and how you want them to engage.

To increase engagement, plan in aspects of the meeting where you individually call on each person for their input – let them know in advance you’ll do this.

Identify the specific questions you have to cover in your meeting, and use these to keep the meeting flowing and gain more valuable input.

Our Requirements Discovery Checklist Pack can help you identify more questions to ask and ensure a more complete view of the requirements.

Use visuals and demos

Prepare visuals that you can share in meetings. Not sure what visual models to create? Here are 22 Visual Models Used By Business Analysts.

Ideally, you’ll share your visual models using screen sharing technology, but visuals can also be sent out via email in advance if connectivity is a problem.

Some screen sharing and collaboration tools:

• WebEx
• GoToMeeting
• Zoom
• Skype
• FreeConferenceCall

For collaborative visuals:

• Microsoft Whiteboard
• Microsoft OneNote (screen share, and then use the draw functions)
• Visio (with screen sharing)
• Zoom whiteboard function

Our Visual Model Sample Pack is an excellent resource of additional visual models to be incorporating into your discovery, analysis, and validation processes.

Active listening

Reading body language is much harder virtually, even if you are on video. Active listening reflects back what you’ve understood. Asking each person to contribute something, even if just to verbally say “no additional comments” gives you a confirmation of where people are at on a topic.

Regular communication

Communicate more regularly than normal Be thinking about daily status reports and daily check-ins with key team members. Some participants are doing daily stand-ups to stay connected and informed. Some teams keep chat open during the day and share personal updates as well. One person reported her CFO set-up a text chat group so people could keep up with each other.

Our Email Communication Templates are designed to help you increase your effectiveness and handle common BA work scenarios.

Here are some of the chat tools participants mentioned using:

• MS Team
• Skype for Business
• Google Hangout
• RocketChat
• Jabber
• WhatsApp
• Slack

Here are 10 Ways to Communicate More Effectively as a Business Analyst.

Working From Home: Protecting Your Mindset

Mindset is so important. Stress increases cortisol in your body and weakens immunity. If you want to protect your health, yes eat your vegetables and take your vitamins, get fresh air and sunshine. But also protect your mindset.

Take a few minutes right now – yes, RIGHT NOW – and take a few deep breaths. Feel the weight of your body on your chair or your feet on the floor. Feel how supported you are. Allow your weight to sink down into the floor or chair.

Now take a few conscious breaths in and out through the nose. Breathing in and out through your nose signals safety to your brain. This is a free exercise you can do anytime to help reduce yourself and increase your sense of safety.

Let’s look at some additional mindset strategies.

Focus on what you can control

You can control how you show up, the structures you create, what you learn. You can’t control how others show up. You can’t control the decisions your organization makes. You can control the government or what your neighbors do, but you can choose how you respond and react.

Focus on the VALUE you create

Focus on the value you create as a business analyst, not the hours you put in. There is this concept we talk about in Circle of Success called “Einstein Time,” where time literally shows up for you. Allow this to happen. It may show up in the form of a colleague sending you exactly what you need to get started, a bit of input that leapfrogs you ahead on a task, a template that gets you 50% there, or a stressful task getting erased from your to-do list.

When we release the stress about time and work from the belief that there is more than enough time for everything, often what we must get done has a way of flowing seamlessly.

You don’t have to believe me, just give the belief a try and see what happens. Post your results to celebrate!

Limit negative news

This is essential. Be informed – yes. But once you are informed the news is just one big cycle on repeat, so listen once if you have to and then turn it off. The news creates a pattern of scarcity in your mind that tears you down.

Embrace a leadership role

An attitude of service helps us overcome scarcity thinking, and keeps us in an abundance mindset. Everyone here has something to give. People are craving positive examples now more than ever.

Your organization needs you to step up.

Invest Your Time Intentionally

Invest your time consciously. If you are home alone, what book could you read, online training course could you take, or closet declutter? Connect with your partner in a deeper way? Time with your children can also be an incredible investment. This flips your mindset around from kids “taking away” from work time.

Also, be sure to re-purpose your commute time in a way that serves your best and highest good.

Bonus points – consider a meditation practice.

Working From Home – You’ve Got This

Just remember…in every challenge, there is an opportunity. You are a problem-solving agent of change and your organization needs you now more than ever. When we keep ourselves focused on results, embrace the challenge, and give our best selves, you, your organization, and the business analysis profession will emerge stronger than ever.

If your colleagues or contacts could benefit from this resource, please share this link with them. We are better together.

Resources to Help You More Effectively Work From Home

In the live session, I was asked to share more templates and techniques that are relevant when working from home. We offer 5 collections of Business Analyst Templates at Bridging the Gap, and all of them are relevant for remote business analysis work.

• The Business Analyst Template Toolkit will help you save time with simple, streamlined documents that help you gain essential buy-in on projects.
• The Email Communication Template will help you more effectively set expectations, get information, request input, and manage issues with copy-and-paste templates you can use for email or tweak for chat or phone communications.
• The Visual Model Sample Pack will help you more easily incorporate more visuals into your requirements process, which is a more effective way to gain buy-in when requirements gathering remotely.
• The Requirements Discovery Checklist Pack will help you identify new questions to ask, and keep the conversation flowing in virtual meetings.
• The Project Prioritization Organizer will help you gain buy-in on clear organizational priorities, which have likely shifted as your organization figures out how to respond to new challenges and opportunities in our current environment.

What’s more, you can save and get all 5 template toolkits at a discount, with our Bridging the Gap Template Bundle.

Like so much in BA, it depends. The best answer to this question has to come in the context of your organization – what projects are you working on? How big are those projects? And what are the skill sets of your business analysts?

In this video, I talk through the pros and cons of the various options and give you some important tips for structuring your business analyst team.

For those who like to read instead of watch, here’s the full text of the video:

I’m Laura Brandenburg from Bridging the Gap. We help business analysts start their careers.

Today, I want to talk about a question that came to us from our Facebook community. That is:

“How do you structure a business analyst team? If I have multiple business analysts, should I be putting them all on each project in different roles or different stages of the process, or should I be giving them each their own project?”

Of course, like everything in business analysis, it depends, and it depends on a lot of factors. There are a few options to consider, and I’m going to talk about the pros and the cons of each.

Business Analyst Team Option #1 – Splitting Roles Among Projects

The first option for structuring your team is to split roles among projects, meaning that each business analyst has their own project or often their own set of projects that they’re responsible for when they’re filling the entirety of the business analyst role on that project. This is a good option if you have a strong team, people with similar capabilities. A mid-to-senior level business analyst, they want their own project.

This is part of the independent fulfilling work that drives us as business analysts, is that ability to own the project, own the requirements for the project, negotiate with the stakeholders for that project. See that through to completion. It’s a good sense of ownership to have if you have a team of strong, capable, business analysts that works well.

It’s also a good thing to be thinking about if you do have more junior business analysts to be creating a path to bring them up. Maybe they’re shadowing and supporting a little bit at first, and then they’re eventually transitioning into their own projects as well. But that’s not the only way to do it.

Business Analyst Team Option #2 – Splitting Roles Between by Stage of Analysis

Some teams also split the roles by stage of analysis. There are a couple of different ways this can happen.

One could be that you have a more business-focused business analyst, and a more technical focused analyst. Sometimes that’s the business analyst and the systems analyst. Those job titles are used inconsistently. Don’t go looking for those job titles as a sign of what type of role you necessarily have.

In that, the split works well in complex environments. If you have a complex set of business stakeholders and that business-focused analyst is figuring out how to process flows through multiple departments and working with, perhaps, dozens of stakeholders to figure that out and negotiate those business needs. And then if that system is complex as well, and so the systems analyst knows how all the systems work together to achieve that business process, and how to specify the different changes that need to happen to all the different systems to make a project happen. Having somebody focus on the business side and focus on the tech side can make a lot of sense when there is complexity on both sides.

Other times we’ll see the split happen more from a stage level. A more senior business analyst might be responsible for a whole collection of projects that, and they’re doing that initial business needs and scoping work and putting a high-level plan together. The more junior business analysts are defining all those detailed requirements within the scope of that plan. That senior level business analyst will still be involved in all those projects throughout, but not in all the details, and the more junior level business analysts would be fleshing all that out.

Now, junior level is relative there because, on a bigger complex project, there’s still a lot of responsibility and analysis work to do and things like that. So, that’s not necessarily just like an entry level, junior level role, but a way that you might see business analyst partner when there are varying skill levels in your organization.

It also creates a path for that more junior level analyst to get involved in the early parts of the projects as well.

Business Analyst Team Tip: Look for collaboration opportunities

No matter how you structure your team, I just wanted to share a few tips for collaboration because it can start to feel like there are walls. Like, “Hey, I’m a senior BA. I only work here. I don’t do these things here.” Or, “Hey, I’m the business process BA. I don’t do the tech stuff.” You want to avoid creating walls. As business analysts, we bridge gaps in communication. We create collaboration. We don’t want to put up walls between ourselves and our own roles. What are some of the ways that you can make sure that your business analysts are collaborating?

Sitting in on meetings is one, cross-training each other, maybe the technical business analysts have. So, much to learn as you train about new systems and the business, focused business analysts talk about the business processes in the department. In the context of a project, there’s got to be a lot of that happening, but it can also happen more globally as well.

Peer reviews. So, doing reviews of each other’s documentation. Even sitting in on each other’s meeting and assisting with meeting notes. The technical BA could take meeting notes while the business BA is facilitating the session, and then the business BA could take meeting notes while the technical BAs are facilitating their sessions. There’s some cross collaboration there. It’s an area of mutual respect and support. That can work, as well, if your BAs are all similarly leveled and have their own projects.

Also, look for opportunities. One of the first things I did in my first business analyst role is I created a peer review meeting. There were just four of us. It wasn’t a huge meeting, but we were all on different projects. We had no visibility into what each other was doing. Every other week we would meet, and we would review a couple of documents for each other. Not everybody had each something reviewed every week, but we would review some documents and give each other feedback. It was a great way to get consistent about how we did things as a business analyst team. We’d see variances. “Oh, I don’t put things like that in a use case. I do it this way.” We would discuss what we thought was better and agree on a go forward approach.

You’d also start to learn about the other projects that were happening in your organization. We could start to see overlaps in terms of the actual functionality and the business needs that were being addressed as well. That just made us all more aware and stronger business analysts, and able to start to contribute a little bit more strategically in the organization as well.

Always be looking for those ways to get your business analysts collaborating regardless of how their roles are defined in making sure that they don’t end up in their own silos and own boxes. That’s the exact opposite of what we want to do as business analysts.

How Do You Structure Your Business Analyst Team?

I would love to hear how you structure your business analyst team. Do the skills that people have play a big factor? Do the types of projects you’re working on play a big factor? What was the factor that drove that organization, or is it just sort of what evolved? Maybe this is a good time to re-evaluate and think about what would be best for the environment that your organization is in right now.

Again, my name is Laura Brandenburg, from Bridging the Gap. We help business analysts start their careers.

Thanks for watching.

For those who like to read instead of watch, here’s the full text of the video:

This is Laura Brandenburg from Bridging the Gap. Today’s question comes to us from Marie, who is a business analyst manager, and often has people in her organization approach her for help getting started in business analysis. She wanted to know how to find that right task, or the first assignment, that will help increase their confidence and expand their capabilities.

My First Business Analyst Tasks

First, I wanted to share my first experience as a business analyst because I feel really fortunate that I worked with a senior BA, and I believe that the way things unfolded for me provides a good model for many to follow.

As you know, I was in QA before I was a business analyst. Many of you know. I talk about that often. I had experience with testing, test planning, reviewing requirements, and the flow of software projects. I had never written a requirements document before. I started by shadowing a BA in her meetings. I got to take meeting notes and update her deliverables and draft deliverables, and gradually, I was taking on more and more responsibility to help her. A new project opened, and I was assigned to work on that project. I went from shadowing her, to a huge, big project. It was one of the bigger projects our organization had ever undertaken. I also had her guidance, at first. That provided a lot of confidence and stability for me.

First, Choose Business Analyst Tasks to Increase Confidence

How can you take this experience and create a model for how you assign your new tasks to business analysis?

First, I think you want to start with a skills assessment. I shared my approach to that in another video, so we’ll link to that here, about how to go through what their transferable skills are, and what they bring to the profession.

You want to choose a task that’s going to help increase their confidence. It’s either going to be formalizing something they’ve done before, but not in the “formal” way, or something that they had a big gap in. Maybe they’ve never done a data model, or they’ve never done anything like a business process. (And if this is their first time analyzing a process, be sure to download our free business process template which incorporates a host of best practices on process modeling and will give them a head start.)

For a business subject matter expert, you might ask them to meet with a few stakeholders and analyze a business process in their area. Give them a structure. A goal of what that process would be. Perhaps, even a few questions to ask so they know what they’re looking for.

For a QA engineer, you might ask them to document an area of system functionality in a use case. To take that knowledge they have of the system and how to write test cases for the system and get more prescriptive into the view of how the system actually should work.

Ideally, they’d start, for a current state system view, and then the next step would be to evolve that into doing some discovery work and evolve that into updating the functionality in a to-be use case as well so you’re getting that full range of business analysis experience.

So that’s starting with the technique. I think, we think we have to give them a whole project. I think starting with the individual techniques, this is what we do in The Business Analyst Blueprint®. It’s a great way to get that confidence started without having to tackle the entire project all at once.

Assign Business Analyst Tasks to Cultivate Independence

Once you do this, you want to create experiences for them, though, to cultivate more independence. I’ve done this technique, and this technique, and this technique. Could I put that together on a project, or could I start it from scratch or identify the process from start to end? Find the stakeholders myself that I need to work with. Kind of all these ways to take that first level experience and expand it to new experiences.

You also might start to bring them into the projects that you’re working on. Maybe, at first, they’re doing this specific use case, business process, or data modeling work, like on a project that you’ve led and scoped and planned out. And then bring them into the beginning and say, okay, now I’m starting a new project and I don’t know what information I need. I don’t know what the business objectives are. We don’t have to scope to find, yet.

Let me walk you through how I approach that and have them shadow you through some of those tasks, and then take on the more detailed analysis as well.

Go From Individual Business Analyst Tasks to New Projects

Then, eventually, of course, you want to prepare them to start a new project all on their own. It might start with a small one, and then gradually get to more stakeholders, more complexity, until they’re running full-fledged projects like you’re doing as a business analyst today.

And, so, I think just starting with the independent tasks first, and then merging that into full projects, and then thinking about how they would shadow you on some of those projects and then take some of those projects independently on their own is a good way to think about graduating tasks.

Once you go through a skills assessment with somebody, you might discover they’ve done a lot of things before. If somebody is coming from a background of a project manager, or a technical development lead manager, which is a common path into business analysis, they might have more experience with that business objectives scope definition phase, and they might need more help with the detailed requirements phase of how to put together the business processes and all of that. You might shadow them to get the project started, and then provide more guidance and support as they do those detailed business analysis deliverables.

Always be looking for what that person knows and brings to the table already. Leveraging that strength, giving them the next thing that’s going to help them expand their skills and experience.

Another thing to be looking for beyond that, in terms of building a career path, is once I’ve done all that with a set of stakeholders or a specific system, or a specific area of the business, how can I tackle a new challenge? A new set of stakeholders, a new area of the business, an unfamiliar domain. That’s when your business analysis skills start to get put to the test, and that’s where you start to see how generalized these core skills that we have are, and how applicable they are in different environments.

It can get tunnel vision when you’re first getting started in a specific environment. It’s when you start to apply that across multiple environments that you take your skills to the next level. Be looking for those opportunities for people on your team as well as they get comfortable in their business analyst roles.

I hope you find this helpful. Whether you are helping a business analyst, or transitioning yourself, it’s a way to think about how to get to where you want to be.

I’d love to hear from you. What was your first business analyst task? How did that come to be?

Share in the comments below. I’d love to hear from you.

Again, I’m Laura Brandenburg from Bridging the Gap, and we help business analysts start their careers.

>>Download Your Free Business Process Template

Get started analyzing a business process today, with our complimentary business process template.

• Help business users from multiple departments clarify their actual step-by-step workflow;
• Avoid wasting money on software solutions that don’t solve the right business problems;
• And even helping new business analysts figure out what questions to ask when starting on a new project or domain.

Business process analysis is often the very first technique used by business analysts when we start learning a new domain or analyze the scope of a project.

Click here to download your free business process template today

This video addresses how to deal with this challenge by looking at a specific scenario from one of our community members – in this case, a new central business analyst team has been created, along with each development team having their own business systems analyst.  And the team leader’s concern was advancing the central business analyst role in the department and getting recognized for their value.

For those who like to read instead of watch, here’s the full text of the video:

Today, I want to talk to you about a common challenge that business analysts face, and that’s getting their value recognized, or the value of their business analysts team recognized.

Today’s question comes to us from Jeff who has a specific take on this challenge. Jeff is part of a centralized business analyst team that just got formed within his IT department. Now, there’s a centralized business analyst role as well as a business systems analyst role. His question is, “How do I get this central role that I’m a part of recognized within my department, and how do I make sure our value is truly seen and appreciated?”

Five suggestions

Well, Jeff, I have five suggestions for you. These apply to anyone who’s ever struggled with getting the value of business analysis recognized within their organization, which I know from my experience, there are a lot of you.

#1 – Create a team charter

The first thing to do, Jeff, is to create a team charter. What you want to do is look back at why your team was formed in the first place. Why is there this new centralized business analyst role? What problem was this team designed to solve?

Put that down on paper clearly so that you know what your main pain point is, your main problem that you’re here to solve so you can share that, effectively, within your organization. You can spread that message and talk to other team members about that as well. So, that’s the first thing; get your team charter in place so it’s clear why you’re here and what that team is here to do.

#2 – Assess your team’s skills

Next, you want to assess your team’s business analysis skills.

• What are the unique value, unique skills, unique qualifications that put people onto the centralized BA team vs. one of the other teams in your department?
• What is unique to the people on this team?
• What kinds of challenges can you and your team solve for the organization?

You want to make sure that’s reflected in your charter and that people are really set up to capitalize on their unique strengths. That’s how you’re going to add the most value to your organization.

#3 – Deliver immediate value

That leads to the third suggestion which is to deliver immediate value. Most likely you have this big idea in your head about what this team is going to be and the value that you’re going to provide for the organization and some newer expansive ways that you want to deliver value to the business, and the responsibilities that you want to take on. That is all fine and well. We will get to that with suggestion #5.

Before you get the license to do that, you need to make sure that you don’t get your feet cut out from under you before you ever get started. The way you do that is by delivering immediate value.

• So, look at the projects that are on your plate right now.
• Make sure that your BAs are assigned to the most important, high impact projects in your organization, and make sure that you’re using your unique skills to accomplish the goals laid out in your team charter, and to solve some problems on projects right now.
• Help those projects get moving quickly, get moving effectively, and solve any challenges that are coming up.

You might look at the intersection between the business process and the functional requirements making sure that the new functional requirements that your systems analyst might be creating are reflected in the business process. Or meeting with those stakeholders to understand the problems in the business process and make sure they are reflected in the more detailed system or technical requirements. Just an idea.  It depends on how those roles are defined in your organization, but make sure you’re adding value.

#4 – Share wins

As you do this, suggestion #4: share your wins. Make sure the BAs within your team are sharing wins with each other. Provide suggestions for how they can share wins within their project teams, so if they solve a problem, identify a missed requirement, get a new stakeholder involved, or save somebody some time, make sure that win is shared and people are starting to recognize the value your team is bringing to your organization.

Share those internally, have little celebrations, maybe team lunches or cupcakes or whatever it is that would reward the people inside your team. Share them within those project teams. Share them up to your manager as well of your IT department. And share them beyond, if you can, on the company intranet or however it is that you can share it within your organization.

That’s how you start to get your value seen and noticed so that people are more open and understanding of what your role is and what kind of contribution to expect from that centralized BA team.

#5 – Expand value

Finally, you want to look at expanding your value. Now you’ve dug in. You’ve made an impact, you’ve shared those wins, you’re using your unique skills.

What can you do next? This is probably the idea you had when you formed the centralized IT team or centralized BA team in the first place. This could be things that are outside the project like business case work, evaluating ROI between different projects, or helping look at a program of projects and how these are going to deliver value for the organization. Thinking about that next level of expanding the value.

Essentially, you go through these same five suggestions again where you’re expanding your team charter to account for those new ideas, assessing your team skills, making an impact, and sharing those wins. You’re continuing the cycle so that you’re continually expanding your value, which is also going to expand the career potential for you and everyone else on your centralized BA team and really getting you into doing some of the more cutting-edge, advanced level business analyst work that we see out there.

I hope these suggestions are helpful. Please leave a comment and let me know how they work for you. I’d love to hear from you regarding any challenges that are coming up for you, specifically, around getting your value as a business analyst or your business analyst team recognized in your organization.

Here is a list of 65 business analysis techniques that are useful to know about. Not that you would use every technique on every project (though some of these are definitely my tried-and-true, go-to, techniques), but so you have a toolbox of ideas to refer back to when your business analysis process isn’t flowing like it should, so you can get your project unstuck and moving forward again.

**If you’d like to expand your business analyst toolbox, take a look at our business analyst templates. At $97 for each toolkit (or $347 for the Bundle of all 5), these provide an affordable way to bring a wider variety of techniques to your business analysis work.**

And please feel free to add a business analysis technique in a comment below. Just be sure to include a description so we know what it is and/or link to an article that shares more detail about it.

1. Active Listening – A communication technique that involves paraphrasing back what you heard during a conversation to confirm understanding.
2. Agenda – A document containing the pertinent details for a meeting, including an objective and list of topics to be discussed.
3. As Is Process Analysis – Defines the current state of a business process in an organization.
4. Brainstorming – A spontaneous group discussion designed to generate ideas without initial critique or evaluation.
5. Business Analysis Plan – Document that summarizes the business analysis approach, list of deliverables, and schedule for completing the business analysis deliverables.
6. Business Domain Model – A visual model that logically represents the business concepts to be fulfilled by the system and how they relate to one another.  It should not be confused with a data diagram, which represents the actual database design or architecture.  Although they may look similar, a business domain model should use terms that are in the business domain.
7. Business Process Model – A step-by-step description of what one or more business users does to accomplish a specific goal. Those steps can be manual, paper-based, or software-based.
8. Business Process Modeling Notation (BPMN) – A standardized notation for creating visual models of business or organizational processes.
9. Business Rules – A statement that defines or constrains some aspect of business.
10. Change Request – A document or collection of information summarizing a change to be made. Often associated with a formal approval process.
11. Competitive Comparison – Document or matrix comparing the current or potential future state of a product or system to that of an organization’s competitors.
12. Conference Call – A meeting conducted via a conference bridge, with multiple participants joining from different physical locations via a phone line.
13. Data Dictionary – Also called a Data Definition Matrix, provides detailed information about the business data, such as standard definitions of data elements, their meanings, and allowable values.
14. Data Feed Specification – A document containing the business and technical details involved in exchanging data between organizations. Can be used as part of managing API integrations or other types of ongoing data feeds.
15. Data Flow Diagram – Illustrates how information flows through, into, and out of a system. They are especially useful when evaluating data-intensive processes and looking at how data is shared between systems or organizations.
16. Data Mapping – A specific type of data dictionary that shows how data from one information system maps to data from another information system. Creating a data mapping specification helps you and your project team avoid numerous potential issues, the kind that tends to surface late in development or during user acceptance testing and throw off project schedules, not to mention irritating your stakeholders.
17. Deliverables List – A list of deliverables to be created as part of the business analysis effort for a project or initiative.
18. Document Analysis – The process of analyzing documentation to discover information related requirements.
19. Entity Relationship Diagram (ERD) –  A data model describing how entities (or concepts or things) relate to one another. When created by business analysts, ERDs can be used to understand the business domain, clarify business terminology, and connect business concepts to database structures (see Business Domain Model above).
20. Feature Map – A visual representation of multiple features, often user stories on a product backlog, that shows their relationships.
21. Given When Then Statements – A formula for writing acceptance tests for a user story. Given (some context). When (some action is carried out). Then (description of observable consequences, or requirements).
22. Glossary – A deliverable that documents terms that are unique to the business or technical domain. A glossary is used to ensure that all stakeholders (business and technical) understand what is meant by the terminology, acronyms, and phrases used inside an organization.
23. Grooming the Product Backlog – A process for reviewing new product backlog items for clarity, estimation, and priority, prior to or during sprint planning.
24. Interface Analysis – The process of analyzing an interface, such as a user interface to connect between two software systems, to discover information related to the requirements.
25. Interview – A session with one to multiple stakeholders to ask and answer questions related to any aspect of the problem, project, or requirements.
26. Issues List – A document or repository that contains a list of all issues relating in any way to the requirements for a project.
27. Meeting Notes – A document capturing the essence of topics discussed during a meeting, along with any resulting decisions and action items.
28. Mind Map – Suggested by Bola Adesope, a visual model with a topic in the center that shows a hierarchical relationship between different concepts and ideas. This is a great tool for brainstorming.
29. Observation – The process of observing people using a system or executing a process, often in their actual work environment, to discover information related to the requirements.
30. Organizational Chart – A visual model representing the organizational hierarchy in place for an organization or a part of an organization.
31. Performance Measurement – Process of collecting, analyzing and/or reporting information regarding the performance of an individual, group, organization, system or component.
32. Performance Report – Document or model showing the results from a project, project phase, or business activity.
33. Portfolio Management – Process for organizing, prioritizing, and showing relationships between multiple active and proposed projects for an organization.
34. Problem Definition – The process of discovering and defining the actual problem to be solved by a project or solution.
35. Process Improvement Progress Report – Visual model showing the improvements made to a business or technical process as the result of a project or initiative.
36. Process Walk-Through – A working session in which subject matter experts walk through a future state process to validate it.
37. Product Backlog – List of all requirements under consideration (written using a user story syntax), rank ordered, and matrixed with other key characteristics that facilitate planning and prioritization for an agile software development team.
38. Project List – A single list of prioritized projects under consideration by a team or organization.
39. Prototype – A functional visual model that shows the user interface of a not-yet-built software system. Often prototypes allow for some limited interaction based on sample data.
40. Requirements Questionnaire – A list of questions about the project requirements. Typically the questions are organized by feature (or business requirement or project objective).
41. Requirements Review –  A meeting gathering stakeholders together to walk through the requirements documentation, page-by-page, line-by-line, to ensure that the document represents everyone’s complete understanding of what is to be accomplished in this particular project.
42. Retrospective – The process of reviewing a work completed (often for a project or segment of a project) to discover and bring forward lessons learned.
43. Root Cause Analysis – The process of analyzing a problem to discover the underlying causes, or true issues, creating the problem.
44. Scope Model –  A visual representation of the features, processes, or functionality in scope for a specific project, solution, or system.
45. Stakeholder Analysis – A document defining who is part of the project team and what they are responsible for.
46. Stakeholder Map –  A visual diagram that depicts the relationship of stakeholders to the solution and to one another.
47. Stakeholder Request List – List of requests related to a project or solution prior to defining scope.
48. Survey – A series of questions posed to multiple stakeholders in an asynchronous format, such as an online questionnaire. Useful for gathering lots of information from multiple people.
49. SWOT Analysis – A visual model showing information about the Strengths, Weaknesses, Opportunities, and Threats an organization faces.
50. System Architecture Diagram – Visual model that identifies the system components and how they interact as part of the solution and can help you figure out how to best organize the detailed requirements.
51. System Context Diagram – A visual model defining the primary system to be addressed during a project or initiative and the relationships between the primary system and other systems.
52. To Be Process Analysis – Defines the future state of a business process in an organization to clarify how the business process will work, at some point in the future, once changes are made.
53. Traceability Matrix – Suggested by Nikkita Nguyen, this document is used to map business requirements to functional requirements.
54. Triple Constraint – A model showing the balance between project budget, schedule, scope, and quality.
55. Use Case – Use cases are a type of textual requirements specification that captures how a user will interact with a solution to achieve a specific goal. They describe the step by step process a user goes through to complete that goal using a software system.
56. Use Case Diagram – A UML (Unified Modeling Language) diagram that shows the actors, use cases, and the relationships between them.
57. User Acceptance Testing – A validation process in which business users use a new solution, often before it’s deployed, to confirm it will meet their needs.
58. User Interface Specification –  A document defining the rules of engagement for a user interacting with a specific page on a website or screen within an application.
59. User Story – A short document capturing a description of a software feature from an end-user perspective. User stories are often written in the following syntax: As a ____ {user}, I want ____ so that ______. User stories are often coupled with acceptance criteria (see Given When Then Statements).
60. Video Conferencing – An expansion on a web conference, where participants are also able to share video of themselves.
61. Vision Document – A document describing the business objectives and scope of a project.
62. Web Conference – A meeting held via a webinar, online meeting, or combination of screen-sharing software and conference bridge, with multiple participants joining from different physical locations via an internet connection being able to all see one visual screen and talk to one another.
63. Wireframe (Also called a Mock-Up, Related to a Prototype) –  A visual representation of a user interface screen, typically one that is fairly low-fidelity.
64. Workflow Diagram (Also called Activity Diagram) – A simple visual model that captures the steps, decisions, start point, and end point of a functional, technical, or business process.
65. Workshop – A meeting in which real-time collaboration on one or more work products, such as requirements deliverables, occurs inside the working session.

What business analysis techniques do you use most often? Do you have a favorite technique that’s not included on the list? Please share it via comment below and be sure to include a short description to define what it is and when to use it.

And, if you’d like to expand your business analyst toolbox, take a look at our business analyst templates. At $97 for each toolkit (or $347 for the Bundle of all 5), these provide an affordable way to bring a wider variety of techniques to your business analysis work.

I won’t lie. It’s a lot of work to make this happen.

You, personally, need to be motivated to make this year different than than the last. And your organizational leaders also need to understand what’s in it for them.

(And we’re here to help you do that with the Project Prioritization Organizer.)

But back to your motivation. Let’s look at some of the positive outcomes that happen when you are managing all of your delivery team’s work on a single list, both for you and your organization.

#1 – The top projects get done

While it might feel like a lot of work isn’t getting done (after all, a ranked list means some things fall to the bottom), the projects toward the top of the list start to experience more momentum than they ever have before.

Everyone’s attention is on them. Roadblocks are worked around. Hold-ups are batted down.

And then all of a sudden they are done. Then it’s on to the next item on the list, please!

#2 – Executives hold each other accountable

When your Steering Committee meets every other week to review the active and pending projects, executives will start to hold each other accountable. Is this project being held up because you can’t get stakeholders to come to your meetings? All of a sudden that issue gets a lot of visibility. It’s not just holding up this project, but holding up the projects under it on the list.

#3 – Business cases come under scrutiny

You’ll also start to see executives hold each other accountable to the business rationales behind each of the projects. Because they are all negotiating over a shared pool of resources, they will start to call out each other’s false projections.

This might not happen the first time around, but when the next project pops up with the same expected benefit, you better believe someone is going to notice and say something.

#4 – You are less of the bad guy

All of this amounts to the business analyst and project manager being less of a bad guy. It’s not about you saying “no”; it’s about this versus that.

It’s a powerful position to be in, because you get to offer up choices and options and enable your executive team to buy in to what they choose to do with the resources they have.

#5 – Developers get more committed

But the changes do not just happen at the executive level. In the old world, your development team gets involved after a project is prioritized, scrutinized, and an arbitrary delivery date is set.

The full implementation of a portfolio management process requires you get delivery team input early. Once the project is active, they’ve already had a say. And as a result, they are more invested in following through.

#6 – More good ideas surface

In an organization that has little track record of delivering results, good ideas never see the light of day. No one expects anything to happen from them anyway, so why bother bringing them up.

Once you start finishing projects and delivering value, people notice. This can result in a flood of new project proposals, which is a great way to surface game-changing ideas.

#7 – Elevated business analyst role

But something needs to be done with all those new ideas. We know they can’t go straight to the development team. What’s more, there is likely to be redundancy and overlap among the ideas.

In comes the business analyst, who gets to work at more of an enterprise level, vetting new ideas and ensuring they are fleshed out enough to get a solid development estimate. This is a great place to be as a BA.

#8 – Requirements meetings get a little easier

Once people see projects getting delivered, your message of “that’s out of scope, but let’s put it on the parking lot” becomes a lot more effective. As a result, you start to see your requirements meetings for active projects being a little easier to manage in terms of staying on scope.

The parking lot isn’t a deep, dark place where ideas never see the light of day. An item on the parking lot can become a project request which can get prioritized on the project list.

>>Get the Project Prioritization Organizer

The Project Prioritization Organizer contains all the templates and processes you need to implement a project portfolio management process, as well as a guidebook to walk you through how to implement this process the first time through.

Click here to learn more about the Project Prioritization Organizer

Perhaps even more than planning for elicitation, planning the business analysis approach will set a mature business analyst apart from the crowd. The purpose of ‘Plan the Business Analysis Approach’ is to select an approach to performing business analysis, which stakeholders need to be involved in the decision, who will be consulted and informed of the approach, and the rationale for using it.

Although the BABOK is not a methodology, that doesn’t mean the BA is off the hook for creating a methodology in the context of their project or organization. And this is the task where that methodology, more generally called an approach, is put together.

First, BABOK distinguishes between plan-driven approaches and change-driven approaches, noting that most methodologies are somewhere in the middle. Plan-driven approaches focus on minimizing upfront certainty – we might think of “pure waterfall” (if such a thing even exists anymore) as a pure plan-driven methodology. Change-driven approaches focus on rapid delivery of business value in short iterations. The most visible example of a change-driven approach is agile, though continuous process improvement initiatives such as Six Sigma would fall under this category as well.

An important note is that the BA methodology does not live in isolation – it is either part of or integrated with the methodology for the project, which will cover many other aspects of delivering the project in addition to the requirements development effort. By the time you’ve defined your BA methodology, you’ll have a good idea of the role of the BA for this project, timing of BA work, formality of BA documentation, approach to requirements prioritization, change management process, business analysis planning process, and any requirements management tools you’ll employ.

This is quite a lot of decisions to make! My formal experience in this area is somewhat weak. The reality is that I’ve done individual pieces of BA planning often, such as choosing a prioritization scheme. Others I’ve done informally, such as timing the BA work with the project and choosing a level of formality that suits the project.

Instead of upfront planning to figure this out, I often approach timing and formality through trial and error. Sure, I’ll start by asking about expectations and look for guidance, but instead of starting from scratch, I’ll leverage something from my repository of templates (which I’ve now made available in the BA Template Toolkit), ask for feedback, try something different, rinse and repeat. I have also worked in many smaller environments where we are building the BA practice from scratch and my stakeholders just don’t know what they don’t know about what they want from a BA. So instead of diligent planning,  eyes-open trial and error tends to lay out an approach most efficiently.

There is one story I have to share where I truly did complete a much more rigorous plan. I’ve written a few times about my role in helping consolidate technology systems from 5 disparate organizations. In this position, I hired first one BA, then a second to help support the project. With more than one BA on the same project, a defined approach became essential. We developed some common templates and set expectations about the level of granularity of requirements within each template. We defined some common ways of working with a very large stakeholder group and prioritizing requirements. We explored potential tools to store and manage requirements, first using Excel spreadsheets and a SharePoint site, then exploring DOORS and other configuration management tools. This was one area that we iterated through several times throughout the project and modified as plans for delivering the solution changed.

This post is one installment in our Journey Through the BABOK with BA Stories series.

Kick-Start Your BA Methodology

The Business Analyst Template Toolkit includes a set of fully annotated business analysis templates you can use to develop your BA methodology or plan for your next project.

Click here to learn more about the BA Template Toolkit

Should we use the BABOK process?

Do I need to understand how to follow the BABOK methodology?

How can we apply the BABOK framework in our organization?

The idea that the Business Analysis Body of Knowledge contains a business analysis or requirements development process is a common misconception. The BABOK professes to do no such thing and we’d make a huge mistake if we use it that way.

The BABOK represents the collection of activities that make up business analysis. It’s the stuff that we BAs do. It’s not a process or a methodology.

At the risk of being self-referential, here’s the BABOK definition of a business process.

A set of defined ad-hoc or sequenced collaborative activities performed in a repeatable fashion by an organization.

Here’s a quote right from the master of the BABOK himself, and VP of Professional Development at IIBA, Kevin Brennan:

The Guide to the Business Analysis Body of Knowledge is not a methodology. While it defines the activities, tasks and knowledge that a business analysis professional needs to know, it does not do so from the perspective of prescribing an order or sequence.

While the BABOK is not a process, a careful reading of the BABOK might help you define your business analysis process. Because it collects together the set of activities that make up business analysis, you might find a technique or a way of thinking about a knowledge area that helps you improve your business analysis process. But the decision of what to do when needs to be yours.

The process that works for your organization or your project will be heavily dependent on the following factors:

• How is the BA role defined? And, what are the other roles on the project team?
• What type of project is it?
• Who or what has the knowledge about what needs to change? (This could be in people, such as subject matter experts, or documents, such as regulations.)
• What sorts of decisions about the project need to be made by the project team or organizational heads outside the project team and how will these decisions be made?
• How will the solution be implemented?

This last one might surprise you. While the early requirements documentation to scope the project might not be affected by solution decisions, the detailed documentation to implement the solution will definitely be. For example, you are not going to create a detailed functional specification if you are buying a third-party tool. That would be a ridiculous waste of effort. You would instead focus on your key features, your integration requirements, your customization requirements, and your data migration requirements.

On the other hand, if you are building custom software from scratch, you’ll likely create very detailed functional requirements.

Yes, turn to the BABOK for a list of ideas that you might consider and as a checklist of activities you might do, but don’t let it do your thinking for you. It’s simply not designed to achieve that objective.

Looking for more? I developed a business analysis process based on the principles I’ve found help me be effective as a business analyst.

>> Learn the Business Analysis Process

We walk you through an 8-step business analysis process in the BA Essentials Master Class. You’ll learn a step-by-step business process that you can customize to meet your organization and project situations, how to create a timeline for a new business analyst assignment, and be prepared to handle the more common issues BAs face on new projects.

Click here to learn more about the BA Essentials Master Class

Although the best employees will always go above and beyond their specific job role, starting with a well-thought out job description can make the hiring process much more effective and give current employees a solid benchmark against which to evaluate and improve their performance.

Define the Need Behind this Business Analyst Job

The first thing I ask is: What is the purpose of bringing in a business analyst? What need does the business analyst serve? What gap exists that needs to be filled? I boil this down into a 1-2 sentence statement that I include in the Job Summary section.

For example:

The Business Analyst works with stakeholders from all business units and related third parties to define and document business processes and software requirements for technology initiatives, including online products, content management systems, and business information systems.

My goal with a summary is to enable a candidate to quickly be able to determine whether or not this job might be a good fit for them. (Yes, I do want to make it easy for the right candidates to apply. It’s the first way to improve the hiring process.)

Define the Essential Job Responsibilities for the Business Analyst

Next I walk through the process lifecycle for the business analyst and lay out the essential responsibilities.

Some questions to ask yourself:

• What responsibilities does the business analyst have within each of the core BA knowledge areas?
• What are the key deliverables that the business analyst will create?
• Who does the business analyst directly support and what are those stakeholders able to do with the information or analysis provided by the business analyst?
• Is there a defined process the BA will follow or does the BA need to create the process?
• What non-BA responsibilities might the business analyst have? (Project management, QA, Development….)
• Are there any areas where the BA will be responsible for assisting those in other jobs or departments?

Here are a few examples of essential responsibilities:

• Analyze and model the business domain to create a complete picture of work-flows and technical requirements fulfilled by existing and proposed software.
• Define the business problem and primary objectives of new projects. Identify and validate the key business requirements.
• Lead cross-functional business process re-engineering teams and continuous improvement efforts.
• Evaluate potential software solutions, including off-the-shelf and open source components, and the system architecture to ensure that they meet business requirements.
• Create functional requirements in use cases. Coordinate requirements walk-through and sign-offs, verifying with user representatives/stakeholders that use cases and process models accurately portray specific business needs.
• Contribute to project plans.

Decide on Necessary Qualifications for the BA Job

This is often the meatiest section of the job description. Break down each essential job responsibility and ask yourself what a candidate needs to know or have experience in to be able to fulfill that function successfully. What I find in reviewing most job descriptions is that they tend to blend qualifications with responsibilities and the result is somewhat muddled. By breaking qualifications out separately, you should be able to trace each qualification back to a responsibility and eliminate extraneous qualifications that aren’t directly tied to what this person will need to do.

I capture each qualification in a term (1-2 words, such as “Listening”) and a clear description (1 sentence such as “Ability to listen actively by summarizing, asking clarifying questions, and interpreting.”)

I typically break this section down into sub-sections, one for each of the following areas:

• Core Business Analysis Skills — This section includes the items you might find in the BABOK or a text on business analysis. I might include use cases, process models, or BRDs here.
• General Management Skills — This section includes skills in self-management, appropriate project management skills, and the soft skills for engaging with stakeholders. Listening, communication, and scope management are placeholders.
• Technical Skills — This section includes any tools the BA needs to know to fill the responsibilities. It could be your requirements management tools, your project management tools, or specific business applications that are used to run your business. Often I substitute in a specific tool with a type of tool. For example, when I was hiring for an online job board, I preferred candidates who had familiarity with search engines and database concepts, but I did not list our specific tools.
• Experience and Education –– This section includes the specific background that is required. Does the candidate need to have strong BA experience or related IT experience or related business experience? Is a college degree required or would equivalent work experience be acceptable? Think hard about what experience will actually best support a successful candidate. Often there is a tendency to assume you need a candidate with relevant industry experience, but as finding good BAs with that experience might be tough, ask if this is really necessary to meet the job requirements?

Identify the Success Criteria for the Candidate

When recruiting, I develop this section for internal use only. It forms the basis of how I will use the responsibilities and qualifications above to evaluate potential candidates during the hiring process. For each success criteria, I capture a clear definition of what success looks like and our rationale for including it.

For example:

Strong communication and validation skills. Able to iterate through the requirements in phases. Evidence of staying in alignment with business sponsor, stakeholders, and management. Rationale: This project has gone off track a few times because the business was not involved all the way through. This person needs to be able to regain their trust and communicate the requirements in multiple ways. We cannot afford to go off track again.

After listing out all the success criteria, I add another sentence to the Job Summary that starts with “A successful candidate will…” and I summarize the most essential success criteria, again hoping to help the right candidate self-select for the position.

Although I did not use success criteria like this as a manager, I think in the position of having a business analyst staff again, I would make these a collaborative effort. We’d start with the list I recruited with, amend it with input from the employee, and use this as our joint understanding of what successful business analysis looks like.

Validate the Business Analyst Job Description with your Stakeholders

In a way, we might think of a job description like a requirements specification. And just like an unvalidated requirements document is only as good as the understanding of the business analyst, an unvalidated job description is only good as the understanding of the hiring manager. Oftentimes as hiring managers we overlook responsibilities and qualifications that our employees and stakeholders can help us fill in. So circulating the job description or otherwise eliciting job requirements from the very people who will work with the new business analyst is a great way to both pave the way for the new candidate-to-be-employee as well as ensure you are hiring for the most essential qualifications.

Hi, My manager asked me to define KPI for the business analyst job. I’ve tried do to some research but everybody seems to have a bit of a problem around this. Do you have any ideas from where to start?

Finding a Meaningful KPI for a Business Analyst

Trying to measure what appears to be an intangible item (BA Performance) is truly difficult. It takes some imagination and thought to figure out whether there are actually tangible objects that can be measured. If the conversation was about development performance, we could measure defects per lines of code. For project management, we could track cost overruns or schedule slips.

For business analysis, what exactly is there available to measure?

We have to start with our products that we deliver – and look at the value of business analysis. Since most of what we actually deliver is a service, what could be considered an actual product that is created? The only thing that comes to mind is the requirement itself, which is either captured in BRD for Waterfall, or as an individual or small set of requirements grouped together for Iterative/Agile. Either way, since it is produced, it should be able to be measured for quality, right? Kind of.

Measuring Business Analysis Performance Through Peer Reviews

I’ve found that it’s not a simple comparison, but rather a multi-step process that offers an illustration of quality over time. What I do is mandate for my projects that documentation is exposed to the peer review process .

A peer review comprises of a review of the documentation against pre-defined acceptance criteria of quality characteristics. The BABOK 2.0 discusses these criterion at length starting on page 115. The review process should capture a percentage of overall requirements (maybe 2% of the total number of requirements) and should result in feedback that highlights flaws in requirements.

For instance, if I request a review of a BRD from five peer analysts with direction to review a random set of say 20 requirements each, I would receive feedback on 100 +/- reqs and indication of what is wrong with each. The initial review provides a picture of how well the analyst is writing requirements and the feedback can be used for rolling improvements. I then keep that feedback even after I correct the flaws.

Measuring Business Analysis Performance Through Evaluating Defects

The second piece is to run a report of defects for the release during the UAT cycle and perform some analysis to try to determine if any of the defects map directly back to requirements (or missed requirements). The number of requirement related defects can then be compared against the number of peer review requirements flaws for an overall percentage that can be applied toward a performance KPI.

The kicker here is the time it takes to perform all this comparison analysis and usually results in this second piece not getting done. Simple cost/benefit analysis usually indicates that the first part is fairly adequate and adds in the needed quality where it has the most impact.

How do you measure your business analysis performance? Have you found a truly valuable KPI to evaluate a business analyst?

Learn How to Measure BA Performance

Adriana Beal has address this challenging topic in Measuring the Performance of Business Analysts, a practical guide to finding meaningful KPIs that can be measured without unnecessary overhead.

Click here to learn more about Measuring the Performance of Business Analysts

Laura: We started this conversation because you tweeted about a “learning network” and how you encouraged your BAs to be building one. Can you explain to me what you meant by that?

Mark: I learned the term “learning network” from my girlfriend’s educational technology professor who called it a “PLN – Personal Learning Network”. Essentially it means that you build a network of resources and people and bring their ideas into your organization. When I took on the management role in my BA group, I challenged them to first look and see what was out there. I challenged them to bring new ideas to the table about how we could improve our BA practice. There is so much business analysis knowledge available. There was really no need to start from scratch.

Laura: That makes good sense. I was recently speaking with a BA team lead Kym Byron and she made a parallel comment. She said that if a BA does not experience what the role is like outside their organization, their perspective of the role can become very limited. The learning network seems to be a good force to counteract that.

Mark: Exactly.

Laura: Tell me a bit more about your team.

Mark: In addition to project work, business analysts on my team have a business relationship management role. This means that 25% of their time is spent managing IT relationships within a department. They work with business stakeholders from a department on project proposals, business processes, and ideas related to technology. When we can, we assign BAs to the projects for that department, but this is not always possible.

As a BA moving from department to department on different project assignments, one of the challenges I faced was getting back up to speed on an aspect of the business domain. By maintaining continuity and developing an ongoing, consultative relationship the BA stays abreast of what’s going on in a department in the absence of active project work with that department. In my experience, it also allows the BA to move beyond being regarded solely in a project sense and more as a consultant or advisor. It also really helps maintain a solid relationship between the business domains. With a team of BAs acting as a “corporate CIA”, colleagues can alert their designated department of potential downstream impacts from the actions taken within another department.

Laura: That sounds like a great role for your business analysts. How did you justify the resource commitment to your management?

Mark: It was actually fairly easy to justify. The project managers used to have the role, but they were more focused on activities they could manage. So it was easy to bring this responsibility within the BA group. Stakeholders truly value the relationship and my manager gets good feedback from people at his level as well. This justifies the commitment long-term.

Laura: What other improvements did you make within your BA practice?

Mark: The first thing we did was build a requirements process. In the past, each BA tended to do things their own way, with an inconsistent approach and documentation formats.  Stakeholders, as a result, were seeing different documents at different times and the requirements process was taking longer than it needed to. To help resolve this, we focused on building requirements, process, and planning templates that supported our standardized process.

Another challenge we had was giving management and stakeholders input in the early part of the requirements process. In the past, analysts would go into a hole for a month or more and emerge with a requirements document. IT management was not getting feedback and the business users were missing the big picture. So we began to separate requirements and analysis. After 2-3 weeks of discovery, the BA would present the project findings to the larger group, often in the form of high level business requirements and process flows. This happened before the detailed requirements were written. This allowed stakeholders across the organization to redirect the project if necessary and provided a good turning point for the project manager to get involved and start actively managing the project execution.

Laura: It sounds like your team is in a great place. I am sure they will miss you. Good luck in your next venture. Thank you very much for your time today.

Mark: Thanks Laura, I really enjoyed talking with you. One of the things I love most about the BA community is the willingness to share ideas and work together to improve what we do. I think this is a really exciting time to be a BA!

>>DefineYour Business Analyst Process

Join us for the BA Essentials Master Class. You’ll learn a step-by-step business process that you can customize to meet your organization and project situations.

Click here to learn more about the BA Essentials Master Class

John Davis writes:

We’ve been looking at IAG’s BA Benchmark 2009 that deals with the impact of poor requirements practices on project and organisational success. Short of hiring a company such as IAG, how can we as BAs best help our organisation – or a client organisation for those of us in IT Services – develop more maturity in requirements definition and management?

Speaking from my experience working as a consultant for large organizations which frequently lack structure and discipline in requirements definition and management, making the case for a stronger business analysis practice is not as easy as one would expect. With the number of studies demonstrating how flawed requirements development processes generates all sorts of problems in software development projects (from scope creep to defects found at later stages compromising product quality and resulting in ballooning costs), it is somewhat surprising to see so many business leaders failing to recognize the value of consistently following a mature, disciplined business analysis process in their organizations.

One of the main reasons for this lack of understanding is that it’s not a simple task to connect improved process capability with better results in IT projects. Skepticism about the value of investing in process improvement remains not only for business analysis, but for other disciplines as well (software development, user experience, testing, etc.). Such resistance is understandable in light of the fact that many problems, from requirements volatility to implementation issues, can cause project failure even in organizations with excellent processes in place.

What can a BA do to help overcome the resistance to change? A conversation with senior management about current project issues is a good starting point. Is your company missing commitments? Suffering from late delivery of software products to the market? Experiencing last-minute crunches, or too much rework? By focusing on existing project shortcomings, and the range of expected results that can be achieved by following a better requirements process in terms of cost, schedule, functionality and product/service quality, it is possible to raise awareness, obtain the necessary support in the form of sponsorship, and secure the resources needed to start a process improvement effort.

Once the initial resistance is overcome, what should be done next? A good first step would be to get management and the BA group thinking of what needs to change. A reference guide such as the BABOK can be used to facilitate the process of answering the question: “What is the real situation here?”. In order to improve its requirements practices, organizations may need to work in several directions: processes, planning, training, technology, relationships and coordination with other disciplines, measurement. Disciplined change is important, as well as approaching the problem iteratively, like a series of projects that break the work down into smaller, more manageable pieces, so that inefficient or defect-prone BA activities are identified and replaced or revised in a consistent, effective manner.

There is a lot to be discussed about developing a true business analysis discipline and establishing an effective BA practice that supports the need for both stability and continued improvement. I hope to continue to develop this topic in future articles.

#1 – Impart Business and System Domain Knowledge

As a business analyst, you need to gain an understanding of the business domain and how the software systems support the business. Consider pulling together the following documentation to share what you’ve learned about both:

• Business Domain Information — share an understanding of the customers, products, and how the operational processes support the products.
• Key Business Processes — share knowledge of the key processes that support the business.
• System Diagram — list of the systems the business process and what they do.
• Actors / Use Case Diagram — overview of the key roles and what they do with the systems.
• System Walk-through — functional walk-through of the key systems, including a description of how they support the business processes. Some organizations may have detailed systems documentation. Include a review of the documentation, but provide context with a walk-through.

#2 – Identify the Business and IT Stakeholders

Business analysts work with a variety of stakeholders. During your tenure in a position, you build knowledge of who needs to be involved with what types of questions. This technique is called stakeholder analysis, but it’s unlikely that all of your knowledge is pulled together in one easy-to-refer-back-to document.

Consider putting together a document that includes the following sets of information:

• Functional Departments — a high-level organizational chart of the departments you work with and how they are related from an organizational perspective.
• Business Stakeholders List — list of individuals within each department that serve as stakeholders on projects. Include their role, their expertise, and a list of reasons they may be brought into a discussion.
• IT Stakeholders List — list of individuals on the development and IT support teams that you work with to define and implement the requirements, including their roles and expertise.

If time allows, it’s also a great idea to individually introduce the new business analyst to each stakeholder. Otherwise, consider an email introduction.

#3 – Share Information on Outstanding IT Requests and Projects

In most cases you are not in a position to leave everything you’ve worked on in a complete state. You’ll need to share information on active projects in development so the business analyst can serve as the new touch point for questions and concerns.

• Share the project vision and purpose.
• Explain what steps you’ve taken so far and what still needs to be completed.
• Conduct a walk-through of any available documentation so the new business analyst has a complete understanding of what has been done to-date.

You’ll also need to review the backlog of requests you’ve started to analyze. Consider how you’ve got your documentation organized. Will it be easy for someone else to establish the context of these new requirements or does that need to be developed? Is it clear who requested the change or enhancement so that follow-up questions can be asked and answered. This part of the transition involves leaving things as organized as possible while also conducting a walk-through of the structure so the new business analyst can pick up where you left off.

#4 – Describe the Business Analyst Responsibilities and Software Development Process

There is a lot of variations among IT shops in terms of how projects move from from initiation through to completion and how the business analyst supports that process. Go through the software development process in detail. Outline who does what and how everyone works together. Dive into detail about your role as the business analyst. Some aspects to include are:

• What are your inputs? How do you learn about new work?
• What are your outputs? What is your work product like? (It may be helpful to share some sample work products from past projects.)
• Are there standing meetings? What is expected of the BA in those meetings?
• What meetings do you normally schedule throughout the life cycle of a project? What is the BA role? Who gets invited? What is a typical agenda like?
• What steps do you typically take to complete your work? (Recognize that each person might have an individualized path toward completing their work.)
• What tools do you use? How do you use them?
• Where do you see opportunities for improvement?

>> Don’t Forget About Career Planning!

While career planning may not be part of initial onboarding, as your new business analyst becomes secure with the business domain and job role, you’ll want to work with them to form a path to career development. Consider starting with our free step-by-step career planning course. Upon joining, you’ll also receive our BA career planning guide and follow-up insider tips via email.

Click here to learn more about the free course

One of the topics that appear to be on the mind of many business analysts lately is the expansion of the business analysis role. How can a BA make a difference in his/her organization, perhaps going beyond conventional analysis to become a visionary? What are the challenges a BA may need to overcome to respond to the increased expectations of companies who hire business analysts not just to manage requirements, but also to perform project management and participate on decision-making processes?

Questions like these reflect the natural desire that business analysts have to better understand their role and focus on the development of the skills that will not only support their career goals, but also generate the most value for their organization.

Obviously, there isn’t a one-size-fits-all answer, but one thing that may be helpful for BAs pondering these questions is to remember that the most value a business analyst working in the IT solution space can offer to an organization is to excel in the processes related to the discovery, analysis, negotiation, and validation of the requirements of a new or modified software system. End users, project sponsors, subject matter experts, project managers, etc., all get involved in the process of eliciting requirements, but the business analyst (regardless of the job title he or she has) “owns” the requirements processes, and is responsible for making sure that the requirements adequately and completely represent business and user needs. To be truly effective, a BA must consider the project requirements their primary concern, from the development of a product vision and scope to detailed user and software requirements specifications and the change control processes that will be used to manage requirements during the lifetime of the project.

What about blended roles, then? It’s normally hard for a single person to balance goals like getting the project done on time and budget vs. delivering the right product. In my experience as a consultant, the most successful projects typically have a business analyst and a project manager working together to accomplish project goals. Activities such as planning the work to be done, identifying and securing necessary resources, determining tasks that must be completed, assigning the tasks, delegating authority, tracking progress, etc., are the responsibility of the project manager, while the business analyst remains in charge of producing consistent, complete, feasible, truly needed, accurate, traceable and verifiable requirements.

I see the “expansion of the business analyst role” as a double-edged sword. The consequences can be favorable if the intention is, for example, to involve business analysts in enterprise-level activities related to identifying gaps in organizational capabilities, developing models to describe the desired future state of the organization, or performing other tasks that allow BAs to deepen their knowledge of business goals and contribute to the formulation of business transformation projects. If, however, instead of aiming to get more from their analysts’ skills and capabilities by extending their involvement across the enterprise, the organization is simply trying to cut costs by having the business analyst simultaneously act as project manager, tech lead, or QA tester, there’s a substantial risk that the change will result in loss of value and quality of the output provided by the analyst, which in turn may result in extensive and expensive rework, or contribute to the already high statistics of IT project failure.

While discussing the BA role in their organizations, business analysts must be ready to fight unwarranted assumptions, needless compromises, and wild guesses about the responsibilities they have and the contributions they make as part of a solution team. An experienced business analyst is typically busy throughout a software development project, bridging the gap between the business and the technology teams, determining changes in processes and operations that need to take place as a consequence of the new system, investigating and advising on the project’s impact on other systems and initiatives across the enterprise, and so on. While BAs working for smaller organizations (or dedicated to smaller projects) may be able to successfully wear multiple hats, the acceptance of additional responsibilities, particularly when in conflict with business analysis core responsibilities, can have devastating consequences for both the organization and the analysts–a few of whom may even find themselves victims of the infamous Peter Principle.

To borrow the words of Laura Brandenburg,

I do think we need to balance our desire to help with an understanding of what it takes (in terms of time, effort, and focus) to be the best at what our core responsibilities are. It can be tricky… but sometimes it is better to “just say no”.

The IIBA(R)  Denver Chapter hosted a panel of 4 BA managers and 2 recruiters in mid-September to talk about the business analyst profession in the local area. Throughout the discussion it became clear that these business analyst managers faced challenges as well. All of them had staff from multiple disciplines and between the 4 managers, the following areas of responsibility were mentioned: documentation, quality assurance, customer service, project management, and product management. A few managers were responsible for working on customer-facing projects or system customizations, others had a myriad of systems used to support a diverse set of internal stakeholders. But they all believed steadfastly in the value of the BA and supported the BA in their organization. And that’s why they held the attention of the 45+ attendees for an hour and a half.

We rarely stop and give our managers credit for what they do for us and how they are contributing to our profession. I think we can all benefit from a slightly better understanding of the challenges they face.

Misunderstanding the business analyst role

Managers reported that the upper management in their organizations often misunderstood the role. There was a need to continually communicate about the role, the software development process, and define “what everyone does”. Despite these efforts, they still get questions such as “why can’t the business just talk to the developers?”.

Requirements take too long

When asked “What is the biggest complaint you here from business stakeholders about your BAs?” they practically rang out in chorus with “requirements take too long”. Even though business experts appreciate their projects are more successful with a BA involved (per the panelists), they still find the time spent on requirements to be a difficult pill to swallow at times. This means we can help our managers by being respectful our stakeholders’ time and facilitating focused meetings with meeting agendas.

Recruiting the best business analysts

These managers, all of whom had hired at least one person in the last 6 months and many of them more, found the role difficult to interview for. As Jenny Nunemacher mentioned in a comment on “What makes a great business analyst?”, the panelists were clear on the soft skills and personalities they wanted when hiring business analysts, but not clear how to ascertain those skills through a traditional interview process. As a former manager myself, I agree. I often lacked confidence in my hiring decisions until I saw the analyst at work for a few weeks and then would breathe a big sigh of relief.

Executive support for enterprise analysis activities

While some of the panelists reported business analysts getting directly involved with the executive team to support business strategy and business case development, others found it a challenge to get their staff members involved in this way. One panelist reported that in most of the companies he had worked for, this type of work was often left to outside consultants with a presumed level of expertise, even when an existing employee was the most qualified for the role. Much of enterprise analysis requires high degree of objectivity and as business analysts become entrenched within an organization it can be difficult for them to take this bird’s eye view.

These were just a few issues that came up in a discussion not really focused on the challenges of the manager. Our managers and leaders play a key role in advancing our profession and our careers as individual business analysts. If you are or have been in a position of leadership on a BA team, I’d welcome the opportunity to hear your thoughts about these and other topics.

Another aspect of this, though on a grander scale, is the need for cohesion between Business and IT on projects that involve  process development or improvement efforts. Process work is only one facet of a business analyst’s skill set, but these projects often span multiple organizational units, disciplines, political boundaries, technologies, and personnel resources. So, no matter where in the process a failure occurs, the feeding or consuming portion of the process that surrounds the failure is impacted. To make matters worse, a single failure can have multiple downstream consequences due to dependencies that are sometimes not viewed as direct consumers of an upstream activity.

When I think of process work, I generally think of a business process that starts and ends on either the business or IT side. In other words, the boundaries that currently separate an IT department from an organizational business unit generally contain the processes within each. Recently I came across one that DID cross over (and, no….I didn’t get to speak with my deceased grandmother). I work for an organization that has multiple divisions in different states and multiple business units inside each division. When requests for change to their common application suite come in to IT (which services all divisions), it has not been uncommon to see duplicate or conflicting requests. Moreover, our IT development capacity is limited and the various tidal waves of changes, defects, and project work orders was overwhelming us. To make matters worse, once a change arrived in IT’s hands, the original process no longer was able to handle the request efficiently, thereby double-dipping IT resources.

At some point, I began to look at the process that was governing all this and realized it was very broken. Immediately, I identified the largest siphon to our capacity, and that was the fact that we were spending huge amounts of time facilitating conversation between business partners who had previously not discussed among themselves what their wishes were. Some of these conversations went on for weeks as meetings were adjourned and decisions were delayed. Additionally, we had no method for funneling all work of this nature down a single path to realistically define impacts to capacity. The obvious choice was to push all of this back onto the “business side” to let them fight their own battles.

When I first began to broach this subject, there was considerable consternation, defiance, avoidance and other push back. Much of that was simply because there was no visibility as the consequences of this issue.  Eventually, when a negative dollar value was attached to it, the light went on. What’s a negative dollar value? For this scenario, I showed them step-by-step where business was paying for IT to participate in core business functions (like decision-making meetings) yet were providing no deliverable to business and were also not providing value worth the time we in IT were spending doing it.  I had to come up with a way to communicate that we did need to place some activities on the business side, and I did that by doing two things.

First, I dug deeper into the problem and was able to identify the productivity failures that IT was having due to the high volume of non-productive work when engaging with business on the change process requests. Each one of those was mapped to a function that if taken over by business, would better serve them in the end, because IT would be able to deliver more code when not working through business issues.

The second thing that really helped was two-fold. We created the new process that governed both business and IT when handling change, but each activity was created or modified during a partnership between the two entities. Each improvement in the process also included a value statement for both Business and IT, so there was clear understanding of the goals. All participants were as much a part of the solution as they were the initial problem. I also created a full set of checklists that governed all the major decision making, set expectations for deliverables up front, and assisted in making determinations for when to bypass portions of the process due to emergency needs. The checklists were delivered as aides to business to help them function, and each would start getting used very early in the business-only portion of the process and follow the request through as it is turned over to IT. These set the expectations for business from IT and helped to define areas that business could understand what the expectations were before they started to work on a change (read: less rework).

To wrap this up, I could have reworked everything on my own and presented it as an IT solution. People don’t really like change though, and having them be a valuable part of the solution creation process allowed us to change together for the good of the whole. We are currently in the middle of implementation and are working through small portions of the flow in each phase together. The creation, adjustments, measurements, decisions and successes are all a result of this collaboration….and all of a sudden people are geared up to change. “Their” problem is now “our” problem and we’re fixing it together.

I believe that good requirements make the technology shop a better place to work and make that work more fulfilling for everyone involved with technology.

What causes low morale on technology teams?

If you are a leader in any business or organization, then you probably understand that part of your role is to help others find fulfillment in their work while at the same time generating business value from that work.  I learned this a few years back while reading James Autry’s book titled The Servant Leader.

Few developers on a technology team are fulfilled in their work when they deliver a brilliant piece of code that no one ever puts in production.  No product managers are fulfilled when they wait 2 months for that perfect feature that would generate more revenue only to have it miss the mark.  No software tester is fulfilled when they find every bug in the code, ensure it’s fixed before release, and then hear someone from the business say “it doesn’t work”.  These are not positive situations for your employees.  They breed discontent and distrust.

Leadership can support alignment between business and IT

The alternative is to be an advocate for two accountabilities within your organization:

1. Aligning your business team around what is to be built. And this means everyone: marketing, product, sales, customer service, and finance.
2. Aligning your technology team around a solution that solves the business problem and delivers real value.

Yes, it can be a difficult process to gain alignment on requirements and project outcomes and to make the time up and down the organization for the collaboration and reviews necessary to create this alignment.  But, creating focus on these two accountabilities can create a waterfall effect within your organization of clearly defined work directly tied to business value. These are the spheres within which the best business architects/analysts,  project/portfolio managers, enterprise architects, and development managers are their most productive.  I am proud to take on these challenges not just because they create value within organizations (although they most certainly do), but also because they help create better places to work.

So, if you’ve put off this challenge within your own organization or just hoped it would solve itself, take a hard look at the impact it’s having on your employee morale, productivity, dedication, and motivation.