The Many Hats of a Business Analyst

Setting up the “perfect” project team would see dedicated people in all the roles required to deliver a successful project.

This could involve a Project Manager to track progress and finances, Business Analysts to analyse pain points and elicit requirements, through to Change Managers, Testers, Trainers and Technology teams. However, in the current economic environment we are seeing more and more organisations ‘making do’ with the resources available to them.

This article explores some of the common crossover skills and activities a Business Analyst could complete which may help augment a project team across the lifecycle of a project. A common approach is to see the Business Analyst taking on activities which would normally be allocated to a Project Manager, Change Manager or Tester, as demonstrated in Figure One. Or at times a SME from within the organisation will take on the Business Analyst role while sometimes still attempting to do their day job.

Traditional Business Analysis Hats

In every project, the person filling the Business Analyst role would be responsible for the core activities which are used to determine the scope and the requirements for the initiative. The activities are likely to cover:

• Stakeholder Management – Engaging across an organisation to identify people impacted by the project, understand their needs and manage communication and expectations.
• Workshop Facilitation – Organising and leading workshops and meetings with impacted and or interested groups.
• Requirements Elicitation – Gathering and refining pain points, opportunities, and system functionality into a clear set of requirements.
• Analysis and Documentation – Processing all the variables and information to identify root causes of problems and patterns to help determine how a future solution should be shaped.
• Business Process Mapping – Understanding the flow of the business processes and identifying points to improve or redesign for an improved outcome.

To understand the full scope on a Business Analyst’s role and the value they bring to a project you can read this related article What is Business Analysis and What does a Business Analyst Do?

Additional BA Hats

On small to medium sized projects, it is often only the Business Analyst who has dedicated time allocated to work on the initiative. They are also more likely to have been involved right from the initial discovery work so is seen as the best person to explain the purpose and provide a summary of the project. Having this overview and touch points across an initiative, they are often asked to extend their responsibilities to take on some or all of these roles:

• Project Management
• Testing
• Release Management
• Change Management
• Training

In this article we will look at how a Business Analyst might be able to assist in these areas to help ensure a successful project outcome.  It is very important to point out here, while we think Business Analysts are pretty wonderful and very skilled, we are not advocating they should regularly take on all these roles.

Project Management

When a Business Analyst is asked to cover for a Project Manager, there are some tasks more suitable than others due to them more closely aligning with the Business Analyst’s other responsibilities.

Stakeholder Management

Project Managers and Business Analysts have always had a shared responsibility for stakeholder engagement, so this one is a natural fit for a Business Analyst to expand the reach of the stakeholders they interact with.

Traditionally a Project Manager tends to engage with the Senior Leadership team and works closely with the Project Sponsor. If a Business Analyst is to take over the engagement with these parties they would need to be added to additional meetings such as management briefings or programme governance updates.

Risk Identification

It is in the discovery phase of a project where risks are first raised, so a Business Analyst is well placed to begin collating a risk register.  In each workshop or meeting they can then add new risks and discuss mitigation strategies with the business. The Business Analyst can then work with the Project Manager to track the identified risks and ensure solutions developed mitigate as many risks as possible.

Team Management

The other activity which comes naturally to most Business Analysts is running the project check ins or standups for the project. They are already coordinating other project meetings and workshops so adding the team check ins can be a natural fit. The Business Analyst is also working closely with all the project team members so has a good understanding of how the project activities are tracking.

Testing

Testing activities and Business Analysts tasks are often merged as the responsibility of one role. The reasoning is a Tester is the person who picks up the requirements or user stories and adds further detail to create testing scripts.

Testing Scripts

Therefore, it can be a good stretch for a Business Analyst to document the acceptance criteria for the User Stories and draft the testing scripts. They normally have a clear idea of how the solution will work and can adapt them to make sure they accommodate the business requirements.

Unit and Smoke Testing

If the project involves developing or implementing new software applications, the Business Analyst can assume the role of unit tester to test out the new features as they are developed. Having written the requirements they have a good understanding of what the solution should look like or how it should function.

In a Go Live deployment, the Business Analysts will normally complete the smoke testing. This involves checking the deployed solution does not impact anything unexpected in the Production environment and the new functionality works as expected. Smoke testing with the developers to resolve any small issues before the business users then get involved to confirm the deployment testing.

User Acceptance Testing Support

A Business Analyst is likely to be involved in supporting the business as they complete user acceptance testing. This could involve a solution walk through and testing user support sessions to ensure the users can access the testing account and understand the intention of the test cases.

The Business Analyst is usually the point of contact of the completed testing scripts. They can then assess the outcomes, test raised bugs to ensure they are valid before they are escalated to the development team and then coordinate any retesting which is required.

The one testing activity a Business Analyst should never take on is completing the user acceptance testing instead of end users. The Business Analyst has written the user stories, and it needs to be the business who validates that the solution meets their requirements.

Release Management

It is very unusual on a project, or even at an organizational level, to have a dedicated release manager. When a release is part of an implementation project, the Project Manager normally coordinates and manages the release.

Smoke and Unit Testing

As outlined in the testing section, a Business Analyst will normally be involved with the smoke testing aspect of the implementation to ensure the solution is working as expected before opening the testing up to the business.

Release Planning

After the initial implementation, there can be a product owner who manages the ongoing releases of bug fixes or enhancements. In the absence of a product manager, the Business Analyst can be best placed to manage the release of bug fixes and enhancements.

They understand the solution and have tested any bugs before they are escalated to the development team. They also understand the impact of the bug resolutions or enhancements for the users. It means they can coordinate testing by the business, plan the deployment and prepare communications to the business regarding the changes.

Change Tracking

In the absence of an organisation having a full release management approval process, a Business Analyst could create a change tracking register. The register will note for each release, the date and time, the changes deployed and the outcome. They can also use this to note any open bugs from the release and track when they have been resolved.

Change Management

Like the other disciplines, there are many aspects to change management as a discipline. However, the primary focus of all change activities is to engage and captivate people​. Business Analysts’ people skills, the ability to engage with those around others, to support and help them understand, accept and adopt the change, is a superpower.

There are three main change activities which a Business Analyst can use to help deliver a successful project outcome.

Consistent and Relevant Communication

Change Management is about storytelling​ and ensuring any discussions about the project reflects the story, especially:

• Why are we doing it?​
• Why are we doing it now?​
• What if we don’t?​

A Business Analyst can consistently reinforce communications in workshops, interviews, documentation or even casual chats in the office.

Resistance Identification

Resistance can be detrimental to a project​, so identifying possible instances early is important.  A Business Analyst can gather the detail and make sure it is addressed before it becomes significant and/or widespread. This will save the project time, money and pain.

Business Analysts are most likely to identify potential resistance as it is common in the discovery and analysis phases to hear comments like ‘well that won’t work’ or ‘that has been tried before’. Acknowledgement of their concerns and asking them to provide suggestions about previous attempts or frustrations, what options could work, helps reduce the opportunity for resistance early in the project.

Stakeholder Reassurance

Change Managers and Business Analysts both possess traits which can increase their influence with stakeholders on a project. Being honest, empathetic and transparent greatly increases your ability to reassure. Displaying empathy for possible challenges along the way, even simply acknowledging them, can be valuable.

Focusing project messaging on what is changing, why and what isn’t changing, is a great way of doing this is.​ When the focus is on what is changing it can be hard to see what isn’t. Reassuring those impacted of the things that remain unchanged, can go a long way to alleviating their fears.

Training   

This is a project activity Business Analysts would most typically perform. They are uniquely placed to support the training to the end users as they have likely established relationships with them. A Business Analyst may have worked with them from the discovery phase, through solutioning and into testing. They are often the person who knows the new solution best from an end user’s perspective. Providing training support for the end users is a great way to assist the success of the project and foster strong user adoption.

Support Materials

If there is a dedicated trainer on the project, the Business Analyst would support training activities by drafting user support materials and providing input to training plans to ensure all impacted groups have been included. They are also able to provide context to the trainer and help them work out the important features to focus on.

Training Facilitation

Where there is no such resource, a Business Analyst can create the training material and deliver the face to face or virtual training sessions. It is also common for the Business Analyst to be involved in Post Go Live support alongside the BAU team who will be supporting the new initiative long term. This support might involve some drop-in sessions where a user can ask specific questions related to how they use the application.

Summing It Up

There are many additional tasks a Business Analyst (BA) might take on when other key project roles are unfulfilled in a project.

While BAs should ideally focus on their core responsibilities, it is important to acknowledge that in the interest of a project’s success, BAs can provide support in these specific areas, when necessary.

However, ensuring this doesn’t become a regular practice is key, as it may dilute the BA’s primary function and impact overall project efficiency over time.