My role on the projects that I work on is that of a Business Analyst, although my official title is Business Systems Analyst. Recently I read another blog post that discussed the pros and cons of a Business Analyst on an Agile project. Given that the article touched on a topic close to my own work I sent it out on Twitter. The author came back to me asking what my thoughts on the topic were and I realized that they could not be encompassed in a tweet so I will address them here.
An image circluating the web, and also included in the post, is entertaining so I’ll include it here. It mostly illustrates how difficult the actual process is.
My first reaction is that I have no idea if a Business Analyst is needed on an Agile project, as I’ve never worked on one. Until very recently I’ve been one of many analysts that supports PeopleSoft ERP, a large software solution that is broken up into interrelated modules. Outside of the large traditionally managed upgrades to the software, I have been involved mostly on what I consider to be mini-projects where the users, myself and a technical resource (think programmer) are the only ones involved. In this case a Business Analyst is a role that effectively overlaps other roles. We do the tasks of a project manager (although at a micro scale), we are the SMEs (subject matter experts), we generally have some general technical knowledge and regularly act as the first person to research and trouble shoot issues or determine solutions. We then wrap it all up for the programmers and test it once it is done to make sure the deliverable meets the requirements before turning it over to the users to test. Finally, we document the final solution from the user/business point of view and train the user group acting on how to use the solution and act as a go to person once the solution is in to get the users functioning and to solve any problems that inevitably come up after the solution is in production.
From my forays into the Business Analyst community online I’ve gotten the impression that the Business Analyst role is a relatively new, and an increasingly important one. Different companies and different teams use the role differently. Some are required to be able to program where as at my work place they are not. Given this there is a lot of debate in the IT world of what titles that contain the words “Business” and “Analyst” in them, such as Business Analyst and Business Systems Analyst title, really mean. Even between the IT groups at my company Business Analysts perform different duties.
During the last major upgrade to our ERP solution at my company a very good technical consultant on the project let me know that at most companies the analyst (sometimes known as the functional analyst) is a much more respected and valued role than a technical one, which can be easily outsourced. That in and of itself may explain the sudden upsurge in Business Analyst roles. As technical jobs go overseas there is still the need to have someone at home who knows the business and can communicate with these resources in order to get a usable final product from them.
In any case, I see the role I play on the project as a vital one. I say this because my role is often the one truly driving the changes and making sure that the software solutions in place meet the needs of the employees that use them.
Here are a number of areas that we add value:
- We analyze user requests weeding out the work that does not actually require IT. Sometimes it is a business process that needs to be changed, additional setup that needs to be done, or a lack of understanding of the functionality of the software features in place. A little time spent between a user and functional resource can prevent programmers from putting in time on unneeded fixes or customization. A good Business Analyst can go a long way in helping to define and control scope.
- We do a lot of work such as requirements analysis and initial testing that the user does not have the time or skill to do. The users that are often called on to help to define requirements or test changes are also the ones that are the most experienced and utilized in their areas. They are typically very busy. It is not helpful to the company to have them off working with IT perpetually rather than performing their functions.
- Most technical resources forget that users have no idea what they are talking about and often make the users feel lost and overwhelmed. A good business analyst will be able to walk a user through the requirements and the testing process in such a way that the user is able to contribute their knowledge and expertise. They can then turn and around and frame user feedback in such a way that it is useful to the programmer.
- Most users have no idea what they want, they only know that they need a solution. The might say “make this better” or “recreate this thing we already have”, but requirements of this type are very frustrating place to develop software from. A good Business Analyst gets to the heart of what it is the user really needs. What is the end result they are looking for? How will they use it? From here the requirements can be created and given to the technical in a form that gives them something solid to work from. Programmers should not have to guess at what is needed.
If the argument is “why can’t other members of the project team pick up this responsibility?” The answer is they may be able to, but there is a tendency to underestimate the difficulty involved in doing this role well. Technical will meet with users and try and define requirements but may not understand what the user is asking for any more than the user will understand the technical point of view. Programmers that I work with need to have uninterrupted time to deliver. Will they be able to do this if a user is coming by, e-mailing or calling constantly with some new emergency or concern?
I found another post that probably does a better job of describing what a Business Analyst actually is. Definitely take a look at it if you want another point of view.
I also recently discovered a new official body of knowledge and certification has been formed around the role, in a similar fashion to the PMP certification for the Project Management role. The IIBA or Internationl Institute of Business Analysis offers their own definition of the role. To really understand their requirements I would have to purchase their BABOK guide. I know more about the PMBOK material than whatever secrets this guide may hold.
So to wrap this up. Yes, I think that a good Business Analyst adds value to the project team, even if it is using agile. Just as a good Project Manager or a good Technical will. In my mind the only time a BA is not an asset is if they are not particularly good at the job, in which case if the team has the bandwidth it may be able to make due without one.
I am, admittedly, a little biased. So what do you think? Please leave a comment below and let me know what roles the Business Analysts play on your team and what value they add. Does a Business Analyst add value on an Agile project?