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/

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.