_edited.jpg){kind=small}
As I work with business analysis clients around the globe, one area that tends to be a challenge is planning and organizing the business analysis work. Especially for individuals new to business analysis, or in organizations that have no project management methodology, or organizations that have never leveraged a business analyst in the past. I have been doing project work for over 2 decades now, don’t really want to date myself, but I will let you guess where I may be in my life 😀. I have worked on large, medium and small scale projects. I have worked on projects where I was the Business Analyst (BA) and Project Manager (PM), or where I was the Lead BA working with other BAs, or where I have been the sponsor and/or manager of the BAs. Regardless of the type of project, and the role I played at the time, I approached the majority of the projects the same way. Now, why I say majority and not ALL is because some projects were totally out of my control on what I was able to do because decisions were made prior to my engagement. That’s another blog post for another day as far as navigating through that. But, for the projects that were more in my control I approached planning and organizing the work relatively the same. What I am going to share in this blog is my approach to BA planning that has worked for me in multiple industries, organizations and regardless of project size. This is just my approach and some tips on how to get started. There are many ways to approach this work.
Now one caveat I must make here, it is important to understand the culture and environment in which you are working. I will not be going into that in this post, but those components can definitely play a role in how you approach the work as well. You will definitely see a difference on what tools and techniques you will leverage based on the culture, environment and project management maturity. The below approach is a high level approach to help individuals who feel stuck, or don’t really know how to start.
Tips:
Understand Scope – first step is to understand the project holistically, but more importantly the scope of the project. I still consider the scope my boundary check. Many times, the scope is clear and sometimes it’s not. It’s important before you start to plan that you have a real clear understanding of the scope. If you have any questions at all, ANY questions, get those answered before you start planning. I know, there are many times BAs are added to a project and you have to hit the floor running, but you don’t want to be running in the wrong direction. The scope for me is the foundation and I want to be clear on the problem being solved and all components to be focused on in regards to that problem.
Work Through Expectations with Project Manager – this tends to be a step overlooked, but so critical. If you are on a project with a Project Manager, or another role that will be working with you closely to provide guidance on the project timelines and deliverables, it’s imperative you have an initial conversation on how you will work together, and who is responsible for what. I have watched project teams go through unnecessary challenges during the project because this was not done. I have watched individuals on project teams get so frustrated with each other, and develop unhealthy tensions due to this. There is power in CONVERSATION! Take a moment to have a conversation with the individuals you will be working closely with to ensure everyone is on the same page and understands how the other works. I will admit that these conversations do not always go smooth, but at least having the conversation is a start.
Understand project timelines – now I don’t know about you, but I have been on many projects, where the timelines were already established for me. I typically had to fit getting my work done within those timelines. I would determine my dates by backing into the date of when the requirement work needed to be completed. Now, it is important to note here that companies use different methodologies and approaches to project management, but regardless you still have to understand the timelines you are working within. In addition, if timing doesn’t feel right, speak up about it. You may, or may not, influence change, but if you know something is just not realistic speak up and have that conversation of why you feel that way.
Conduct Stakeholder Analysis – take time to understand who your stakeholders are. If you are not familiar with the term stakeholders, these are the individuals who have some sort of stake in the project. This consists of individuals like the subject matter experts (SMEs), business partners (technology, testing), sponsor, executive leadership, and more. Understand who all the players are, what role they play, and what is their stake in the project. It’s prudent to understand who the decision makers and influencers are in your list of stakeholders. The more you know about the stakeholders the better equipped you will be in navigating through the project and ensuring needs are being met from all sides to drive the project forward. This is another area that tends to get either glossed over or rushed through, because the focus is more on delivering the project. However, I have found that building these relationships, and gaining this knowledge as early as possible, served me well as far as navigating the work I needed to get done.
Determine Requirements Approach – now this is the fun part, and is usually based on past experience, or determined by the way you organization runs projects, or is set up. There are some organizations that require you to produce requirements a certain way so that’s why I add that caveat here. However, if you are left to drive the requirements here is how I walk through determining the requirements approach:
Step 1: Determine what work needs to be done based on the scope – as stated earlier, scope is my boundary; therefore, based on the type of project this will give me some insights on how I will approach the work.
SCENARIO 1: For example, if I have been assigned to work on a project where an existing software tool is being replaced by a new one, my approach may be to:
PROCESS MAP: Understand how the current tool works through observing others using it, or reading documentation that exists. I may find that creating a current state process flow would beneficial.
INTERVIEWS/FOCUS SESSIONS: Conduct some interviews, or focus sessions, to understand the pain points of the existing process from the SMEs perspective.
PROCESS MAP: Determine what the future state process should be and document based on the pain point discussion.
DOCUMENTATION: Determine the types of requirements documents I will produce (e.g. business requirements document, use case documents, user stories, data mapping, etc.…)
ELICITATION: Elicit the requirements based on the future state process.
DOCUMENTATION: Document the requirements based on information received from the elicitation session.
VALIDATION: Validate the requirements are documented correctly with the stakeholders.
APPROVAL: Obtain formal approval on the requirements from all necessary stakeholders.
TRACEABILITY: Create the traceability matrix to ensure the requirements are developed, or if there are gaps, identify those to ensure they proceed through to the change management process.
So, at a high level these are the steps I would take for this scenario. But let’s take another example to show how my approach may change.
SCENARIO 2: Let’s say I have been assigned to a data migration project, where my organization is acquiring another company and my role is to focus strictly on the data needs, in order to get their data incorporated into my organization’s existing systems. An approach I may take:
RESEARCH: Understand the data coming from the acquired company.
DATA GLOSSARY: Create a data glossary so everyone is on the same page on what the data means.
SYSTEMS ANALYSIS: Identify the systems that capture the data in the current company.
DATA MAPPING: Create a data mapping document that outlines the current data stored and how the acquired companies data maps to that current data store.
GAP ANALYSIS: Identify what gaps may exist (e.g., is there data the acquired company captures, that is not in the current organization’s data structure? Or is there data the current company structure requires that is not part of the acquired data). I would document the gaps and recommendations for resolution.
Again, at a high level you can see the difference of approach I took based on the need. That’s the beauty, and sometimes frustration, of business analysis. It’s not black and white. However, as you continue to work on projects you will get better at determining what approach makes the most sense for the scenario.
Let’s move on to the other steps s of approach and planning.
b. Step 2: Communication Plan – determine how often, and to whom, you will be communicating your requirements status. It’s important to have clarity on stakeholder’s expectations as it relates to requirement updates.
c. Step 3: Change Management – determine how changes to requirements will be handled. Is there an already established change management process, or does one need to created. There may be requirements that cannot be delivered in the current project and will need to be moved somewhere else. You want to ensure you understand and have a process in place to handle those situations.
d. Step 4: Requirements Maintenance – make sure you have a method of managing the requirements. Depending on the project you may have many different categories of requirements. For example, you may have transition requirements that will go away once the project reaches a certain stage. Your traceability matrix is your friend as that will keep you abreast of what requirements are being developed and where you may have requirements gaps.
Now it’s time to move on to the final tip. Some of these items we discussed in the scenarios above, but I wanted to lay them out how I conduct the work with some additional context.
6. Conducting the Work: As stated before, based on the type of project the way you execute the work may be different, but what is the same are the components that make up your work. Even though those components may look a little different by how you execute them. Here are my thoughts on conducting the work:
RESEARCH: There will be some level of research/understanding of the current state. You need to have a base understanding of the current state and how you document that current state may vary by project type.
CURRENT STATE ANALYSIS: In most cases, when understanding the current state, there will be some analysis done during that research. During that research pain points will be identified. Now, it’s one thing to understand the pain, but you need to understand the root cause of the pain as well. Therefore, there will be some root cause analysis conducted as well.
DETERMINE FUTURE STATE: Now that you understand the pain points, and the root cause of the pain, determining the future state will come to light. Once you determine the future state you will then need to determine what tools and techniques you will leverage to drive out the requirements.
TOOL SELECTION: Now this is where some individuals get stuck. You need to determine the best tools and techniques to drive out the requirements for the audience consuming the information. So, what do I mean by that? As you saw in the above scenarios, depending on the type of project the tools used can vary. So how do you know what ones to use? Some of this is based on experience, but a lot of it is really based on the audience consuming the documentation. At the end of the day, you need to communicate to your audience in a way they can understand and consume the information to know their needs are being met, and accommodated for. There has been, and always will be, spirited debate on the methodology to use, or documents to produce based on the type of project. But, at the end of the day if no one uses the documentation created what was the point of doing the documentation? So, I listen to my audience more than anything else and leverage the tools that conveys the message and will be consumed. Now I would be remiss if I didn’t mention organizational structure here as well because every organization is different. Here are some things to take into consideration as you execute the work based on organizational structure.
Organization has established project documentation standards: leverage the standards already established and ensure the output adds value to the audience. Meaning, don’t fill out every document in our standards don’t just fill it out because it exists if it does not add value. In addition, if you find the information you have doesn’t fit into those standards, then this may be your opportunity to creative. Create documentation that adds value and then share it. You never know you my state a new standard. raise your hand and advise of that.
Organization has no established project documentation standards:
Option 1: create documents you believe communicates the requirements and take samples of them to your audience to get feedback before your complete all the requirement work. This ensures you are not wasting time creating something people won’t use.
Option 2: There are many free project document templates on the web. Take a moment to research them to see what’s out there and may serve your purpose. Make sure you look at any copywrite disclaimers as you do this research.
Option 3: Reach out to other fellow BA’s to get ideas on what has worked for them in the past. Leverage your network and gain some knowledge from others.
ELICITATION – as stated before with many of the concepts in this blog post, there are many ways to elicit requirements. You can do this work through focus groups, workshops, interviews, 1 on 1 meetings, and more. Just make sure when you conduct these sessions you have an agenda with the desired outcomes. Make sure everyone is on the same page on the purpose of the meeting and the desired outcomes PRIOR, and during the meeting. Time is precious, and some of your stakeholders may have very limited time. You don’t want to waste their time, by advising in the meeting the desired outcomes, to only hear that you need more people to attend, or that topic is not ready to be discussed.
DOCUMENTATION – at this point you should have an idea on what tools you are going to use to document your requirements. I have found that use cases, or user stories, are great tools to use for software development projects. Mockups/prototypes can also be a great tool for software development projects as long as you place the caveat that it is a just a mockup and not exactly how the system may look in the end.
REVIEW – make sure to carve out time in your requirement timeline to review the requirements with all the necessary stakeholders, as well as, any time to make updates based on feedback. Hopefully, you won’t have to go back too many times with requirement updates, but make sure to build this into your timeline.
APPROVAL – it’s also important to build in time to get the requirements formally approved. You want to have a baseline of the requirements that everyone has agreed to. If there is no formal approval process in your organization, you may want to take this opportunity to create one, or at least capture the approvals somewhere for yourself for audit trail purposes.
Okay, so for now here are the 6 tips to help you plan, organize and conduct the requirement work. There are other activities that occur after this, but that is for another post in the future. 😉
In conclusion, the approach discussed may be tweaked based on the culture, environment, and state of the project; however, for those who may be stuck and just need a little bit of a roadmap of where to start here is what has worked for me. Also, don’t be hard on yourself if you start approaching the requirements work one way and then switch it up. I have had to do that in the past for a variety of reasons and that doesn’t mean you are a horrible BA; it just means you realized what you were doing wasn’t working and you need to change it up. There is nothing wrong with that, and the simple fact you realized it speaks volumes in itself.
Stay encouraged, conquer this transformational work for your organization, and continue to provide the immense value BAs provide.
WE GOT WORK TO DO IN ’22!!!
Until next time,
The BA Martial Artist is signing off 🥋
Commentaires