The Business Analyst's Dilemma

Bridging the Gap Between Business Needs and Data Products

“That means absolutely nothing to me! It is just a throwaway comment!” the General Counsel for a large telecommunications organisation, let's call him Gary, boomed across his desk at a colleague and me. We were working on a process optimisation project, and Gary had been identified as one of our key stakeholders. Gary had mentioned an important element of his job, we duly documented this, and my colleague replied, “Noted”. This set Gary off on a tirade about how the term “noted” had no legal significance, nor did it commit us to taking on board his requirement. Clearly a miscommunication, when we were all actually aligned.

Business Analysts are the important bridge between technical teams and business stakeholders in data projects. They translate complex business needs into technical specifications while making technical constraints understandable to non-technical colleagues or clients. A skilled BA doesn't just collect requirements – they uncover underlying business problems and ensure the final products deliver genuine value. In my experience, the success of data and AI projects often hinges on having someone who speaks both languages fluently and keeps everyone focused on outcomes rather than features.

In the example above, whilst functionally doing things right, we had failed on the communications aspect.

My career as a Business Analyst, working with Business Analysts, building teams and practices, and training, coaching, and mentoring Business Analysts, has taught me so many things.

If I were to retain the skills from only a single lesson, the lesson would be this: The ability to effectively translate between technical and business languages is a core skill that drives successful outcomes and sets not only Business Analysts but anyone up for a long and successful career.

The Communication Challenge

The biggest disconnect I see between the technical and business domains can be summarised as the difference between features and benefits. Technologists tend to talk about features, and business stakeholders understand benefits. The quote from the 1967 film, Cool Hand Luke, says it all: “What we have here is failure to communicate”.

A real-world example of this was the Apple iPod. The iPod was not the first or only MP3 player on the market, but whilst competitors, such as the Creative Zen Mozaic, led with messages like “16GB, 1.8” TFT Display, 8EQ settings”, Apple simply stated “1,000 songs in your pocket”. Features versus benefits.

Sometimes the divide is even simpler than this. I remember having a robust discussion with a report developer who refused to include the client’s logo in the initial version of a report because “It was not important and could be easily added later”. The client didn’t think it was unimportant.

These are all examples of poor translation between the technical and business domains. Factor in enough of these seemingly “unimportant” elements and you are jeopardising the successful outcome of a data project. Missed benefits, unused solutions, and white elephants.

Practical Techniques

So, how do we ensure that as Business Analysis, we help our business, our clients, and our teams through these challenges? Here are three key techniques that, as a Business Analyst, need to be mastered.

Develop a Business-first Mindset

It is so easy to be distracted and directed by technology, and this remains a challenge for so many data projects and programmes. Yes, the shiny new things are fun to play with, prototype, and test. However, one needs to recognise that technology should always remain an enabler and not a driver of change.

Every data project or initiative that is undertaken should have a clear business purpose, desired outcome, and measurable benefits.

Are you thinking of migrating your data lake from Microsoft Azure and AWS? Or vice-versa? Why? Because one technology has cooler features than the other? Wrong decision! Instead, ask questions like:

• Once migrated, will cloud consumption costs be reduced?
• What will the migration cost be?
• What will the internal upskilling cost be?
• How long will we need to run the ‘legacy’ solution?
• All things considered, how long will it take before the business recognises a net positive return?

Be Curious

Curiosity killed that cat, so the saying goes. The full saying, though, is “Curiosity killed the cat, but satisfaction brought it back”. Some people are naturally curious, and this is a powerful trait for Business Analysts.

As with any skill, this can be honed and the simplest way of doing this is by asking questions, specifically ‘Why?’. Don’t stop after asking it once. Keep asking it, to the point that people might begin to think you are stupid.

Bringing this level of curiosity to your business analysis role will help you unpick the difference between the business’s wants and the business’s needs. And importantly, clearly articulate this to your business stakeholders, which also supports the next point.

Build a Shared Understanding

Business is, as life is, constantly managing unlimited needs and limited resources. Building a shared understanding and consensus within the business is key to achieving success. This is where a Business Analyst needs to leverage their communication skills. Spoken, written, and visual.

Building Your Skills

Progressing your career as a Business Analyst will involve growing a set of functional skills. The key ones to focus on are:

• The ability to use workshops, interviews, and observation to elicit, understand, and prioritise business requirements
• The ability to analyse and interpret (often disparate sets of) data
• Process modelling skills to document current processes and to define improved or new business processes
• Excellent writing skills to produce high-quality, non-ambiguous documentation
• Visualisation skills that can represent complex concepts in an easy-to-understand manner, using both structured and unstructured data

In addition to your functional skills, you will also need to grow your soft skills. The important ones to consider are:

• Active listening being the ability to fully concentrate, understand, respond, and remember what stakeholders are saying
• Communication and translation by explaining complex concepts simply and adapting your communication style to different audiences
• Critical thinking to objectively evaluate information, question assumptions, and identify the real problems behind stated issues
• Stakeholder management for building relationships, managing expectations, and navigating organisational politics (yes, everyone has to!)
• Adaptability and resilience to adjust to changing requirements and to persist in the face of challenges or resistance

Leveraging functional skills, soft skills, and domain knowledge will allow you to develop credibility with not only your business stakeholders but also your technical counterparts.

Conclusion

Being an effective translator between the business and data worlds is an invaluable skill to both yourself and the organisations that you can help. It really is a role to embrace and one that is very sought after.

Where to start? Begin by performing a skills assessment on yourself and looking for gaps. There are myriad resources out there to help you address these gaps and develop your functional and soft skills, but the number one step you can take is to find a project or a role where you can be exposed to the business end of data. For me, it was learning and implementing ERP software in the 1990s. Given the vastness of the data and technology world today, it could be anything for you.