Why the BA Role is more Critical than Ever in Enterprise IT

Angela Johnson interviews Business Analyst Brooke Schuhmacher

The success of Enterprise IT projects no longer relies on just the IT team. As the digital capability of businesses has matured, the priority and reach of technology projects has increased and this is reflected in the teams that deliver new solutions. The central role of the Business Analyst (BA) is becoming more and more critical to the success of development and implementation projects, acting as a critical link between increasing numbers of (and more varied) stakeholders, from developers to Subject Matter Experts (SMEs) to Product Owners to CEOs; bringing both technically minded and business-focussed people on the journey. It may not be a stretch to say that, today, the BA is pivotal to the success (or failure) of a new IT solution.

For our second instalment of the SDLC from the Coalface series, I spoke to Business Analyst Brooke Schuhmacher, who has 10 years of experience as a BA across integration, application development and automation projects in aviation, higher education, government and financial sectors.

See our interview below for her take on the skills and experience that make an exceptional BA in the digital world, and some of the key factors that contribute to their success in bringing many stakeholders together for a product that is on time, on budget, and solves real business challenges efficiently.

Q1: What are some key skills you would call non-negotiable for a BA, particularly in the world of digitisation?

That’s a good question…I’d say attention to detail is a big one, not only in understanding the requirements, but also in documenting them. In most software development projects the smallest of details can make or break a solution, and because BAs write the requirements and work on the design of the solution we definitely need to notice those details. For example, missing a keystroke in an RPA project can mean the process failing; missing a field mapping in an API design could result in a failed integration — it’s all in the detail.

Another key skill is communication. One of our RPA developers said in a previous blog that BAs are the ‘translators between business needs and technological solutions’ and it’s pretty true! You need to clearly communicate to all stakeholders, set expectations and work to resolve competing priorities, as you are often the conduit between the development team, the client SMEs (subject matter experts) and the product owner/executives. My role is to communicate with clarity, empathy and to ensure everybody is on board with the project and working together for the same outcome. If there’s no Change Manager on the project, this is usually a role that the BA will also take on, as they are the person in the project that really understands the current state of the project environment as well as where the project is heading.

Q2: What things do BAs need from their team and project sponsors to be most effective?

One of the most important things is to have one key point of contact on the client side who has the authority to make design decisions. Having too many ‘cooks in the kitchen’ can mean you end up trying to please everybody and documenting requirements multiple times. If you have one or two decision makers ready to make the final call on features or areas to prioritise, it makes life a lot easier for the BA and keeps the project on track and on budget.

Q3: What would you say is the difference between a good and a great BA?

I think a defining feature of a great BA is that they’re always asking the ‘why’, and really trying to understand the problem that the project/customer/team are trying to solve. A lot of people do their jobs without thinking too much about why they do things a certain way and what the actual end goal is. But when you’re relying on those people’s input to design the best possible solution, you’ve really got to constantly say ‘why are we doing this?’, ‘why are we doing it this way?’ and ‘what outcome are we trying to achieve?’ That critical thinking is what is needed at every stage of the engagement.

Q4: How do you usually approach documentation and requirements? What would you say is the most effective way?

It depends on the project delivery approach, however in my experience I’ve found some approaches are more effective than others. When I first started doing BA work (a decade ago now) I was documenting very long word documents with extensive stories and scenarios. However, when it came to handing over a 100+ page document to the developer(s), it was very rare that they would read it and see the vision of the end game.

On one of my recent projects we’ve found it worked well to document the requirements on wireframes with detailed business logic/rules and explanations in annotations on the wireframes. This worked well as I was quickly able to get both the client and the project team agreeing what the deliverable was. Where more detail was required, this was explained in supporting documentation, or if anything was unclear everyone was able to just reach out to me. The visual approach worked really well on that project, though of course it’s different every time — most projects I work on use more of a hybrid approach.

Q5: You talk about the need to interact with many stakeholders. What factors are important for a BA in order to work with each different group?

When working with developers you absolutely need to have an in-depth understanding of the requirements, right down to the lowest level of detail. And sometimes I’ve had the developers take documentation really literally! And at other times it’s been very important to explain the end goal, and why something that seems insignificant from a development perspective might make a world of difference to the end user.

But it’s a two way street too — sometimes end users and SMEs and even higher leadership request things that are really cool for the user but technically very complex or expensive and won’t have a good ROI. It’s our role to present the information and say ‘here are the pros and cons’ and make our recommendations — although ultimately it’s always up to the client or manager to make the final decision.

Testers are great to work closely with as well. Getting a Tester involved can challenge your designs and your detail, finding scenarios that you’d overlooked or hadn’t thought of. Testers find where things can go wrong, whereas BAs focus more on the happy path and the desired outcome. My colleague Claire Huang referenced this partnership from the Tester’s POV in her blog, that ‘even in an agile project it’s important that as the BAs write the requirements, the test cases are written alongside.’ It’s a symbiotic relationship between the two.

Q6: What are the biggest challenges you come up against in your role?

Usually the time it takes! It can put some people off to look at the budget and see the amount of time needed for analysis. It’s frustrating from a numbers perspective sometimes, when you have to spend a lot of time (and budget) on just planning and design. But generally the more analysis we can do up front, really the better the outcome. There is value in all parts of the project, however if you don’t get the design right then you’re really in trouble. It’s a balance though, of course — you also don’t want to over analyse.

One final thing that I’d say is be aware of the budget. Like an architect, if you design a $1M home and the client only has a budget of $400k, then you have not done your job. Think critically, solve the problems and bring everyone on the journey.