Business Analysis Approach | Why is this unique for every project?
When you are assigned to a new project one of the first things for you to do is to determine what your Business Analysis Approach will be. Each project that you embark on is somewhat unique and will have it’s own nuances, demands and culture which means that as the lead or senior Business Analyst responsible for determining the Business Analysis Approach you must adapt and ensure that your business analysis approach will work effectively, comprehensively and in alignment with the project objectives.
What is the Business Analysis Approach?
Before we continue exploring the considerations for you to assess prior to developing the Business Analysis Approach it is important to understand what we mean with the Business Analysis Approach:
The Business Analysis Approach is the plan that the senior or lead business analyst on a project would create describing the way that all the Business Analysis activities will be executed. This could include: Business Analysis resources and their Roles & Responsibilities, Requirements Gathering Approach for the project (techniques to be used, high level planning), Stakeholder Engagement, Requirements Review Process and Approval Cycles, Change Management approach to requirements and agreed deliverables. Other elements such as team structure, assumptions and constraints could also be included.
Considerations prior to doing your Business Analysis Approach
In order for you to develop a relevant, comprehensive and aligned Business Analysis Approach you must consider many individual factors and elements of the project that you are assigned to. This is vital to the success of the implementation of your Business Analysis Approach and ultimately to the successful outcome of the project.
So let’s consider the factors to assess before you decide and plan out the Business Analysis Approach for your project:
#1: Background.
In many cases Business Analysts are assigned to a project or program of work only after it has existed for a few months. This is because most organizations have implemented a Project Methodology, which doesn’t dictate the engagement of Business Analysts until the “Analysis Phase” of the project. This is a somewhat problematic issue for Business Analysts today but not what we will cover here. In light of the fact that most Business Analysts will be assigned to the project during or at the start of the Analyze Phase it is important for the Business Analyst to get a good understanding of the background of where the project has come from, who is sponsoring the project and what the general direction of the project has been up until this point. This will provide the Business Analyst with very useful information when progressing to analyze the next factors in more detail.
#2: Scope.
Needless to say, the Business Analysis Approach must consider the scope of the project to gage what is included and what is excluded in terms of what must be delivered by the project. An example of this may be that the project is responsible to not only deliver the software solution (whatever form that might take) but also a comprehensive set of training manuals and help files. This will have an impact on the approach taken when engaging with a wide variety of the stakeholders in terms of discussion points around training requirements and delivery requirements for training and help files. Understandably this needs consideration when planning out the Business Analysis approach of the project. Other elements to scope could include the nature of resources to plan for, the methods for executing Business Analysis techniques and an array of other relevant considerations. It is therefore essential to understand the scope at the earliest point of your research prior to defining the project’s Business Analysis Approach.
#3: Nature of project.
With the nature of the project we mean that each project consists of a combination of different types of deliverables. It can be that a project is a custom software build or perhaps it is a software solution being purchased “off the shelf” and implemented into the organization. Another example could be a project where a professional service is purchased, such as a processing platform for credit cards or it could be the project is purely based around business process optimization with minimal technology considerations. There are many other types of projects out there but the important point here is to consider the blend of these different types of deliverables for your project before you define the Business Analysis Approach. It is important because your Business Analysis Approach will be (should be!) significantly different when implementing a ready-made software solution as a ‘vanilla implementation’ as opposed to embarking on a project where a software solution will be build from scratch in-house.
#4: Timeline.
Unfortunately time always plays a part when making choices around what the Business Analysis Approach will look like. In most cases the project works against the clock and this means that you may want to include certain Business Analysis activities to ensure a high quality deliverable but the timelines may constrain you. Understanding the real time lines for the project will enable you to make well-informed and appropriate decisions about prioritizing your Business Analysis activities within the Business Analysis Approach. An example of how a timeline may impact you could be: You may believe that having a series of requirement gathering workshops to include a wider audience of stakeholders will mean a more comprehensive and valid set of Business Requirements but then due to a time constraint you are unable to run as many workshops and therefore not able to include such a wide audience of stakeholders. You might in this scenario need to consider your requirement gathering approach by building some time efficiencies such as running a few workshops with key stakeholders to create a base set of requirements and then include a wider group of stakeholders in the validation only of these requirements which you can do via an email or survey based approach. In essence, it is therefore important to understand the timelines you have available to execute your business analysis approach prior to planning what and how you will be doing the business analysis activities on your project.
#5: Number of stakeholders.
The more people you need to engage with from a Business Analysis perspective the more time intensive the activity will be but on the flip side you could potentially end up with higher quality requirements when utilizing the number of people effectively. Also when you are dealing with a large number of stakeholders on a project it is very important to be very up front and transparent about how you plan to engage each stakeholder. This is achieved by ensuring that your Business Analysis Approach (as far as it impacts the stakeholder group) is clearly communicated in the appropriate format (steering committee packs, email communications etc) to bring all your stakeholders onboard with how and what you would be doing that will require some input or time from them. When people understand what is required from them, how they will engaged with and why they are involved, it makes an enormous difference in the general perception and level of engagement the project receives from the wider organizational community. This also helps tremendously in managing stakeholder expectations and consequently you will gain their support in all your business analysis activities.
When you have a very small group of stakeholders to engage with for the project, again it is good to engage early, be open and transparent about your plans and potentially ask them what format of engagement will be most suitable for them in terms of understanding their Business Requirements.
Something else to consider at this stage of your research is the current perception that exist among your stakeholder group about the project. This could dictate how you approach each stakeholder initially or throughout the project to ensure effective Business Analysis results.
#6: Size.
The size of the project will have become more obvious to you as a result of the previous factors that you have considered. This factor however needs careful consideration from a size (number of) of business requirements that you will have to manage on the project. This can have an impact on the types of tools you use to manage the business requirements and the methods for gathering review feedback, organize your structured walkthroughs and present your requirements packages at different stages of the project. There are other considers around the size of the project and hence the size of the business requirements set which include the change request process, the validation and prioritization approach to follow and so forth. Size does matter, so don’t underestimate this consideration factor.
#7: Resources.
The consideration around which resources will be available to you is another very important factor. If you are for example leading a team of four business analysts and only managing about 500 business requirements you can probably afford to do multiple requirements workshops and validation interviews because you have enough Business Analysts to help manage this task. If however, you have 2 Business Analysts on your team who are also responsible for developing user stories on an Agile Software Development project, you might struggle to have too many stakeholder requirements interviews and clarification sessions. You may need to then consider some ideas for finding a balance between stakeholder engagement and delivering functional design specifications or user stories as it were by adapting your business analysis approach.
#8: Organisation.
Some of the larger organisations will have a project management methodology implemented, which means that there will be certain Business Analysis deliverables, which are mandatory for you to deliver in a certain way. This can potentially hamper your ability to develop a Business Analysis approach, which will perfectly work in your project environment and you may once again need to compromise or adapt to suit the organizational requirement. However, on the other hand if you work within an organization where the Business Analysis approach is very flexible and fluid it might be the perfect opportunity to provide some formal structure around the business analysis approach which could add tremendous value to the organization.
#9: Culture.
Last, but by no means the least important consideration when preparing to define the Business Analysis approach. What is the organizational culture like? In some organizations it is almost expected that a project of a certain size will run requirements elicitation workshops and expect stakeholder engagement as a matter of course. Then in other organizations the idea of running requirements elicitation workshops is quite a foreign idea and people expect to be individually consulted about their requirements. Another example would be where the culture of the organization is very heavily dependent on email communication and hence people expect to be engaged with via email about requirement reviews and approvals and yet in other organisations the email communication method around business requirements approvals is not accepted at all. It is therefore very important, especially if you are new to the organization to understand what are the main cultural elements that need to be considered before you define your Business Analysis Approach and present that for approval.
In Conclusion.
The Business Analysis Approach is sometimes a very formal step for a Business Analyst to consider, define and execute and sometimes it is almost an unspoken but generally agreed method of operation. Regardless of how structured your Business Analysis approach planning tends to be it is very important to understand the previously mentioned considerations before embarking on executing any Business Analysis Approach on a project.
