Author: Virginie Terry

Virginie Terry is Principal Business Analyst at National Physical Laboratory and has over 18 years' experience in Business Analysis roles in organisations across different sectors of the economy. She champions the importance of the Business Analyst role in her work and balances the use of best practice, pragmatism and organisational culture in her approach to Business Analysis. She is passionate about the profession and particularly enjoys supporting colleagues in their early careers and helping them develop their skills. https://www.linkedin.com/in/virginie-terry-0a9638a3/

Upskilling Your BA Team

Written by Virginie Terry on April 22, 2025. Posted in Articles.

Upskilling Your BA Team

AUTHOR: Virginie Terry

1. This is the way we’ve always done it…

One of the most common barriers to adopting new ways of working is a belief from the long-standing BAs that their delivery or operating models are different from the norm, or that their business stakeholders are unusual, and therefore different BA skills or standards apply. This is particularly true with BAs who have learned their skills on the job: internally and without any formal training. Typically, they will have moved from a different part of the business, and they know the ins and outs of specific departments, including the quirks of their systems. This can manifest itself as skills gaps (e. g. made up notation to model business processes); undertaking tasks which should legitimately sit in other areas (e. g. writing test scripts); or not being effective in their role because they don’t challenge their business stakeholders to work differently when defining to be processes.

These individuals need to understand internal expectations as well as the BA industry standards, and in particular the skills that as a manager you are looking for in new joiners. They need to appreciate that refusing to upskill could put them at a disadvantage in terms of the projects they work on or future career opportunities.

2. I’m looking to retire in a few years, why should I bother?

Not everyone thrives on learning something new and getting out of their comfort zone when they are counting the days until they retire.

As a manager, it’s only worth pushing if there is still time for these individuals to apply new skills before they retire. These BAs need to understand how this will improve or expedite some of the great work that they already do. For example, if you’re looking to get a BA trained on use case diagrams, you can easily demonstrate how much more engaging they are to project stakeholders than Jira tickets or an Excel spreadsheet when it comes to reviewing the outputs of a discovery workshop.

3. My project can’t afford to release me for any training, sorry!

A misconception which comes up time and again is the belief that project teams can’t afford to release their BA(s). The truth is that there is rarely a time in any project when a project or programme manager feels that they can afford not to have their BA(s) around, regardless of the stage of the delivery.

A tough one to win if project teams don’t have enough time to plan it. Give the BAs and project teams plenty of notice – ideally several months, so that the BAs can block the time in their calendars, and the project teams can plan for it. It’s important to show some flexibility and collaborate with programme and project managers, for example by staggering the training dates if multiple BAs work together on the same programme or project, rather than taking them all away on the same day(s)

4. I am too old to learn something new

Not quite the same as the BA who’s retiring soon, in this case we’re looking at BAs who may doubt their ability to learn and apply new techniques, or even have some anxiety about sitting exams because they are out of practice. You may also have a BA who’s just not very academic and really struggles with formal learning and assessment / exam situations.

Getting back into a classroom (albeit a virtual classroom) can be daunting. It is the manager’s responsibility to provide support and minimise stressors where possible. You should be able to negotiate revision sessions with your training provider in the run up to any assessment, and if not there is always internal support available from BAs who have already completed the training. Reminders about exam techniques and dealing with exam nerves are useful – as well as being honest with your team and sharing your own story. It is very powerful for team members to be aware that their manager may have gone through the same thing, and how they have overcome their own demons.

5. Celebrating success in the right way

It is necessary to find the right balance between celebrating the team’s successes, which is entirely legitimate and appropriate, and not inadvertently making people feel any pressure or “less than” if they haven’t taken the exams yet or they have failed.

Ultimately, as with so many situations, the key to success is for BAs to realise what’s in it for them. And in the vast majority of cases, once get a few people over the line – once they are, they become your strongest advocates and allies for change.

Working Well with your Test Team

Written by Virginie Terry on June 14, 2023. Posted in Articles.

Business Analysts and Testers are the two cornerstones of software projects delivery. The BAs define the business needs, they validate solution options, and they remain present throughout the project delivery to ensure the project’s objectives are met.

The Testers’ role is to ensure that the solution does operate in the way that it has been specified before it is implemented: they verify that there are no defects, and that the users can achieve their outcomes without introducing new risks or issues into the organisation.

Is there anything you could do to enhance the collaboration between these two teams in your organisation?

Clarify your own understanding of the work the Testers do

Does your Business Analysis Team understand the complexity of testing, or is it an amorphous phase they have no real interest in? Do they appreciate that the test plan will vary depending on the nature of the solution? Do your BAs understand the Test Team’s structure, the tools and templates they use, their dependencies, or how they test non-functional requirements (NFRs)?

Awareness of their operational model and what’s important to them is hugely beneficial to understand the types of pressure they face and how the Business Analysis Team fits into it all.

Conversely, make sure that the Testers know how your team operates

The Test Team may not appreciate the challenges that you face on every project to agree the scope – the back and forth with senior stakeholders who can be reluctant to sign off. They may not realise the importance of some of the documentation that you produce, or why it takes so long to get it right.

Taking the time to explain how your team operates will increase the Testers’ appreciation of your skills and avoid misunderstandings or assumptions on the execution of your work, particularly when it feeds into their own deliverables.

Avoid functional silos

Avoid the “them and us” culture, which can be a real barrier to success. Functional silos become particularly problematic when the project team is under pressure, for example if the delivery isn’t on track. They can easily create an unhealthy tension within the project team.

An effective counter to this is to collaborate and involve your Tester(s) early into, and throughout, your analysis work. Make them aware of what you’re working on before the business case is approved. Give them an opportunity to review your requirements and feed into them before they are signed off. Walk them through the business processes so they understand the intentions behind the new system.

Not only will their feedback improve the quality of your analysis work, but it will also deliver a myriad of efficiencies during the project delivery, from the Test Team resource allocation planning to the ability to produce an early strawman of the Test Plan, for example.

Listen to the Test Team’s feedback

Recognise that sometimes the BAs’ work can fall short of quality expectations and address these issues appropriately, whether individually or at team level. Is there an unusually high number of change requests on all projects from a particular BA for example, in which case they may need some coaching on their requirements engineering skills? Or should you consider new standards or templates, or maybe even some team training, if common analysis problems are emerging across multiple projects?

Be very clear about your role on the project

Let the Tester(s) know how you are working through any issues, particularly if they are not of your own making, to avoid any misunderstandings about the quality of your work. In extreme but not uncommon cases, the solution is agreed, and a new system purchased, without a clear definition of the business need or other systems it may need to integrate with.

On these projects, your role as a BA is to retrospectively write the requirements, and unfortunately, you’ll need to battle with business users throughout the analysis and design stages to justify the scope, particularly the elements that the new system doesn’t support but they would like to have. It’s not insurmountable, and you will likely come up with viable manual workarounds.

It’s important for the Testers to be aware of this history so that the Testing phase, and specifically user acceptance testing (UAT) can be managed effectively, as these contentious, out of scope items, may be raised as bugs by users in UAT.

Conclusion

Business Analysts and Testers work together to guarantee that solutions are fit for purpose. With mutual respect and an appreciation of each other’s work, the teams should naturally be able to collaborate effectively and work through the challenges of the project delivery.

This doesn’t mean that the two teams will always agree on the best option to resolve them, but they will understand each other’s perspective and be more inclined to compromise or make concessions where they are necessary and possible.

Factors Impacting Analysis

Written by Virginie Terry on May 3, 2023. Posted in Articles.

As Business Analysts, we are experts at defining good quality requirements and processes that enable the implementation of solutions which are fit for purpose and deliver the benefits from the business case. We may have several Business Analysis qualifications and many years’ experience working on all types of projects, from simple process changes to complex technical overhauls with multiple integrations, data migration and significant business change elements, and everything in between.

Yet our skills are just one of the many components that enable us to do our job well. There are some other factors which we don’t have much control over but which are also hugely important. We need to be aware of them and should consider them upfront and throughout the delivery of our projects to set ourselves up for success. Unsurprisingly, they can all be grouped under communication within project teams and organizations’ delivery standards and processes.

Consider the delivery model

Are the delivery frameworks from your organization and any third party you are working with aligned? Organizations tend to have slightly different definitions of the same terms, for example “delivery phase”. Does the delivery phase consist purely of coding and configuring what has been defined in great detail in previous, distinct analysis and design phases? Or will the delivery phase also include collaborative sessions at the start where technical teams, BAs and users flesh out these details together?

Consider roles and responsibilities

This is particularly important in organizations which have a high staff turnover, use many contractors or employ staff on short, fixed term contracts. The execution of testing can be a grey area for example, particularly User Acceptance Testing (UAT). Who is expected to write the test scripts? Is it the Tester(s) on your project, the business Subject Matter Experts (SMEs), or even yourself?

Consider the experience from other key roles within the project team

Do the Project Manager and other key roles within the project team have a good understanding of the role BAs play, what we do and don’t do? For example, do they know that BAs need to be present in all meetings with the users and technical team(s) where the scope is discussed? Or that we cannot make an on-the-spot decision about the validity of a change request, such as descoping an area of functionality because of new budget constraints, without assessing the impact on the processes and the integrity of the solution overall?

Consider the project plan

How will the project plan be produced? Do you need to do some “right to left” planning, because the go-live date can’t be moved, which is common on a lot of commercial or regulatory projects, or can you estimate the duration of each phase before agreeing on a go live date?

In the first scenario, you will need to timebox each activity and almost certainly compromise on some elements of your analysis. In both cases you need to really think through any assumptions which are being made around the effort required to produce each deliverable and any dependencies. You should also document any risks you foresee as a result of the approach being undertaken.

One common oversight is the business users’ availability to support the project, which can really hinder progress if not managed effectively. This can range from planned absence, such as annual leave, to having to perform Business As Usual (BAU) activities no one else can backfill, or supporting other projects which have a higher priority.

Consider the project governance

Does your organization have well defined processes to govern the decisions required around the different project milestones and the challenges you will meet in the course of the delivery? For example, are you clear on the documentation that you need to produce, or contribute to, at each stage gate? What is the change control process you need to follow when a new requirement emerges after the requirements catalogue has been baselined?

Consider the Sponsor’s role

Sponsor engagement, and the BA’s access to the Sponsor, are critical to the success of the project. Are you able to have one-on-one meetings where you can speak openly to update them or seek guidance when you are uncertain about the direction you should follow? Does your Sponsor know the level of involvement they need to have so that they support you, the Project Manager, and the delivery of the project, without interfering with the methodology or the due diligence required, for example?

Conclusion

There are no simple answers to these issues. Every organization has its own culture, and each project team has specific dynamics.

However, identifying them as early as possible means that you can prepare for them and address them effectively within the constraints that you operate in, even if it means you’re not able to follow best practice. When dealing with these challenges, regardless of your level of experience, you will achieve something much bigger than the delivery of your project.

This may be learning something new about the way that you communicate, educating your colleagues about the role of the Business Analyst, or even instigating an improvement in the way in which your organization delivers change.