What Business Analysts Really Do: Seven Steps Beyond Requirements
I started 2012 by taking on a major project -- a book titled Beyond Requirements aimed at helping people who identify themselves as analysts be more effective on project teams. I want to dispel the myth that an analyst's main purpose is to "gather and document requirements." This myth reinforces the picture of analysts as stenographers or note takers. It also implies that, ultimately, analysts produce requirements. On highly effective project teams, analysts describe the problem a project's stakeholders are trying to solve, describe the constraints on a solution, and work with the rest of the team to deliver that solution.
That description sounds a little esoteric, so what follows is a more concrete description of what someone with an analysis skill set may do on a project. The particular project I'm describing is maintenance of the submission system for the annual Agile Conference hosted by the Agile Alliance. The conference selects presentations using a community based process: Potential presenters submit their session proposals, which are made available for public comment and to a program committee consisting of stage producers and reviewers. Once a proposal is submitted, a group of reviewers provides feedback to the presenter, who can make revisions to their session proposal in response to that feedback. All of this back and forth requires some system support, so the Agile Alliance created a submission system to support the process. I'm going to walk through my role as the Product Owner for the Agile Conference Submission System.
The premise of understanding context is to get familiar with the nature of the business and share that information with the rest of the team. You want to put the project in perspective of the overall organization and determine what the project is intended to do.
- Will it increase or protect revenue?
- Will it decrease cost?
- Will it support progress toward some business objective?
If the project is not intended to do one of those things, don't do it.
I understand the context of the agile conference because I have attended the conference since 2004, as well as being a presenter and serving on the program committee. This gives me experience from many different perspectives. It's a unique situation, and not all analysts have this luxury. When I don't enjoy this in-depth background, I develop the necessary context by researching the business domain, observing people working in the environment, and talking to the players involved in the project.
Get To Know the Players
It is extremely helpful to understand who is involved in the project. This includes the rest of the delivery team as well as all the stakeholders. You want to know who you need to work with for what information, and whether they support the project or are likely to get in the way.
I interact with the conference and program chairs, the Managing Director of the Agile Alliance, stage producers, reviewers, submitters, and the developer that helps maintain the system. In each case, I need to get on good working terms with them and understand, to some extent, their concerns and needs. I also seek to understand their general impression of the system.
Once you get to know the players, you have to work with them to accomplish everything else I discuss here:
- Understand stakeholder needs
- Understand the underlying problem
- Understand constraints on a possible solution
- Share that information with the rest of the delivery team
A key aspect is figuring out the right amount of collaboration for your circumstances.
With the submission system, most of the changes come from that year's Program Committee. In this case, we've found that email supplemented by an occasional phone call is sufficient to convey the information we need. It helps that I am generally more familiar with the selection process and the submission system than the Program Committee is. The team working on this product is distributed, and no one is dedicated to the team full time, so we have worked out informal processes for communicating. We don't have a great number of changes (we capture them as user stories), and we don't have much need for metrics, so we found that tracking our stories in a Google Docs spreadsheet is sufficient for what we are trying to accomplish.
Define the Problem
Understand what the people with a need (your stakeholders) are trying to accomplish and why they are trying to accomplish it. Don't fall into the trap of taking their suggested solution as gospel. It may hint at what they are thinking, but they may be making things way too complicated.
I always take time to define the problem when a member of the program committee or a speaker contacts me with a request to "fix" the system or to add some functionality. This is probably the one point where I have to utilize my analyst skills the most. Many of the requests this year seek to implement new functionality to support reporting or data analysis. The requestor often uses the jeopardy pattern for change requesting: They phrase their problem in the form of a solution. I have to clarify what they want to accomplish, usually by rephrasing the request, asking why, or asking what they hope to accomplish. Often, I find that I am able to point the requester to functionality that already exists, but in a slightly different form.
Identify the SolutionsOnce you understand the problem, you'll work with the rest of the delivery team to come up with possible solutions based on your understanding of the context and the problem.
With the submission system, when I know functionality exists to address the need, I point that out to the requester. In cases where the functionality doesn't exist, but I knew fairly well how to accomplish it, I provide suggestions to the developer. In all cases, I convey stories to our developer in terms of what the requester was trying to accomplish, and where I have suggestions, I pass those along as well. The developer is very good at suggesting alternatives where there are some, and at giving the pros and cons of each option. I am able to make some suggestions on solutions because of my familiarity with the submission system and with the intended uses of many of its users.
Implement the Solution
It's not commonly accepted that analysts should get involved in implementation, but if you are working on a highly functioning team, you most likely will find yourself helping out your teammates. Utilize your understanding of why the solution is needed to help implement it in a simple, yet elegant manner.
In many cases, I can make the requested change to the submission system using configuration options. Other changes require developer intervention. Wherever possible we use use a solution that requires configuration only, to facilitate a quicker turnaround time.
Validate the Solution
Validating the solution includes both testing the solution as built, and also validating with customers that the solution meets their needs.
Whenever we make a change to the submission system, I test the resulting solution and then have the requester take a look. The system is still fairly simple, but it continues to grow more complex as we use it year-to-year and make tweaks to the overall process. It is always helpful for me to walk through the system to make sure there were no unintended consequences in the changes we make. We often find some.
I Know What You're Thinking
The example above illustrates how we involve an analyst in all parts of the project. If you're not used to this level of analyst involvement, you might be wondering if this is just another way of trying to make a specific role the most important role on the team.
It's not. An analyst is part of a team that has a joint commitment. The typical analyst tasks only occur during a portion of the overall project, but as a member of the team, analysts need to pitch in with the other bits too. In this example, I've tried to describe the activities an analyst could do if the situation warrants it.
On every project you start, one of the first activities the team should do is have an all hands meeting where everyone agrees on what role everyone is playing, and what activities each role is expected to perform. Descriptions such as this one, and even "industry standards," should be viewed as guidelines only. Each project is unique, with different people with different skills working in different environments. Use the various guidelines available to you, but decide specifically what each person might do on this project based on their unique mix of skills.
Copyright ©2012 Kent J. McDonald. Published on ProjectConnections.com by permission of the author. Kent is President of Knowledge Bridge Partners and has over 13 years experience as a business analyst and project leader. He writes and speaks on leadership, business analysis, and agile principles and practices. Kent's new book, Beyond Requirements, will be available next year. You can reach Kent with your own project leadership questions at email@example.com.