Regardless of the type of project, no matter how big or small, it is important to understand the multi-faceted role of the business analyst and how you can add value from start to finish. So let’s take a look at the main project phases and a high level view of the responsibilities of a Real World BA™. The size and complexity of your project will dictate the level of formality and detail that is required in each step, but by considering each of these phases you can bring great value to your projects.
(A quick note before jumping in…Much of my experience is in software development projects both from within IT departments and as an outside vendor. I have tried to generalize some key terms so that they could apply to a variety of projects and environments. For example, I use the word “client” to mean whoever you are working with to deliver a solution. This could be an internal business partner or an outside company purchasing your product or service. Please replace these generalized words in your mind with whatever terms you are accustomed to using.)
1. Understand the Need (Requirements)
Your key responsibility is to make sure that you and all your stakeholders understand the true underlying needs. You’ll hear me say it a lot – you are not an order taker. That means you don’t just write down what your client asks you to give them. There are many methods and techniques for getting to the requirements. Utilize whichever methods you feel will help you understand the need – and yes, that was methods…with an s…meaning use multiple techniques.
2. Identify Possible Solutions (Solution Analysis)
This is when you get to stretch your creative muscle. Once the requirements are completed and approved, you will work with your delivery team to define one or more possible ways to meet each requirement. Working within whatever constraints you might have, what are the possible ways that you could fulfill the requirements? Not all solutions that you pursue may end up being viable, but you should be looking to present to your clients their options with enough information to help them make an informed decision.
3. Define the Details of the Solution (Specifications)
Once the solution has been identified, you will work with your client to understand and specify all the details necessary for the solution to be realized. This is where you dig into the details and think of all the possible pieces of information that your team will need to deliver the solution. And yes, details matter…a lot.
4. Watch for Changes in the Need (Change Management)
No matter how well you think you were able to understand and document the requirements or specifications, new information will come up that could change what you think you are working on. It could be information that your client thought you knew or “assumed” was included. It could be clarification of information as you work through the specifications and realize there is a key piece of functionality that really you hadn’t yet discussed. Or it could be that the needs of your client have just changed. Whatever the reason, changes may occur. Your job is to be keeping an eye out for things that are “out of scope” (meaning not included in your current project) and to help to assess the impact of the change. You’ll be responsible for understanding and educating the team on what the change means, and working with your project manager to determine whether the change will be included and how.
5. Ensure the Solution is Created/Formalized (Development)
Once the project moves into the phase of creating or formalizing the solution, your job shifts to a consultative role (unless you are also helping to build out the solution). You’ll be the subject matter expert representing what is captured in your specification documents, and the liaison between your development team and your client. You may be participating in regular check in meetings, answering questions, or updating documentation among many other things.
6. Make Sure the Solution Works (Testing)
Whether you have a formal testing group or not, you should be available to help verify that what is developed actually fulfills the specifications. This could mean you are involved in reviewing test plans to ensure that critical functionality will be tested. You may be called upon to answer questions and provide additional clarification. You might be the one responsible for actually performing all or part of the testing, depending on how your project is staffed. I personally have to see the solution for myself to feel good that what we are delivering will meet the client’s expectations.
7. Help Put the Solution in Place (Deployment)
You may or may not be part of actually putting the solution in place (for example deploying software or conducting training for a new set of business processes), but you are part of the delivery team and you should make yourself available during this transition. You might conduct or attend user training sessions, which is a chance to answer questions and listen for opportunities for additional improvements. You might be transitioning knowledge and information to a team that will support the new process or application and can provide them helpful tips for troubleshooting known problems. Whatever the case may be, you are probably the most intimately knowledgeable of the details of what is being rolled out. Share that knowledge to empower everyone involved and to ease the transition of what you’re rolling out.
In the next series of articles, I will start to share some of the details of how I like to work projects through each of these phases. You can also find all posts related to each of these phases in the “Being a Real World BA™” menu item above.
Do you see the business analysts in your organization having all of these responsibilities? Are these responsibilities met by different roles?