Picture this: A financial services company employs a number of advisors who spend a most of their time on the phone with current and potential clients. They're using their CRM system to get relevant client information that may be needed in a conversation - client's notes, address and the important dates.
The company undertakes a project to add client portfolio and other relevant information to their CRM. Business analyst (BA) on the project carefully defines all the additional fields and arranges them in clear and logical manner.
Developers take the requirements and implement them. The system passes the QA with flying colors and rushed into production... Financial advisors are trying to use it but it just doesn't work.
No, the queries are executed fairly quickly and correct information is coming up on the screens, but to get to the relevant information, advisor has to follow several steps and drill down, and it's really difficult to do... with a client on the phone! So they now end up excusing themselves to look up client's information and then having to call them back!
What happened? The system brings up relevant information, response times are adequate and all of the forms look good, so weren't business requirements recorded correctly? Were business users wrong to ask to add portfolio information?
One man at the helm
A while back when I was a development team leader I noticed that, to paraphrase the Godfather, one BA with a pen can create more value (or damage) then a gang of developers with latest computers. And the same is true today. We have cross functional teams, automated testing and requirements validation in place yet one person, the BA, can easily send the entire team down a wrong path.
As I mentioned before, most business people tend to express business requirements in a form of solutions. And good BAs know to look for the real business goal behind them, learn how users are going about their daily tasks, and come up with better solutions. In our example, watching advisors talk to their clients on the phone could provide important insight and help design a much more usable system.
Is your BA a strong one?
Clients often ask me if they need to replace a BA, and many times it's a tough decision. BAs take time to get up to speed, so organizations are often slow to replace them. Training helps to a degree, but most of the critical qualities that make up a good BA are difficult to develop.
One BA error may literally cost millions of dollars when a large team is sent down a wrong path or a wrong solution is procured. And when some of the critical requirements are missed upfront, they are discovered later in the project and treated by PM as 'new requirements'. This makes projects fall behind, cost more and introduces a lot of waste in the process.
So here's the list we offer our clients to help assess the skills of their BAs and gauge the degree of requirements related risks they have in their projects.
Five most critical BA skills
Here’s a list of most critical skills a successful BA must possess. If one or more is missing - your projects may be at risk:
Skill No. 1: Attention to details.
No surprise there. A missing column in a report may seem like a small thing but may take weeks to add later on, after the back end is built... A missing search box may cause weeks and months of combined time lost across your user base. So the system needs to be airtight and business requirements captured exactly and nothing left to chance.
Skill No. 2: Personal organization skills.
Time management, getting things done without being reminded, focusing on priorities, communicating ahead of time when they feel that they may be late on commitments...
Competing priorities is a reality of today's enterprises and ability to focus on critical tasks, make judgements and come through on commitments is not to be taken lightly - especially when a large team or a vendor is on the other end waiting for these requirements.
Skill No. 3: Empathy, interviewing and facilitation skills.
A good BA needs to be able to conduct effective meetings. They need to be asking to a problem and be able to get to the key business goals - preferably, measurable goals. They need to be able to facilitate meetings and elicit ideas instead of merely taking notes.
Skill No. 4: User research skills.
Observation is an essential part of any requirements gathering phase. It doesn't need to take long, but taking note how business users are interacting with systems, notice details about the environment - noise, temperature, light, stress level, interruptions etc may make a difference between a productive user and a user who refuses to use your system, a successful system and a failed one.
Still No. 5: Communication skills.
It's kind of obvious, but I still see this overlooked often enough... and cause serious damage. An elaborate requirements document or a detailed user story is all good and fine, but many times a BA needs to be able to communicate their ideas effectively to development teams and external vendors.
Ability to create mock-ups, diagrams, wireframes is also very valuable. Especially in fast paced environments where documentation is minimized and it's way too easy to just assume that it's kind-of obvious and that developers will figure it out.
Coming up next
There you have it. Hope I was able to communicate how easy it is to overlook the role of a BA, how big of a difference a strong BA can bring into a project and how to tell a strong BA from a weak one.
In the next article I'll show you the process we use for hiring BAs, both for our own team and for our clients.
This article is published as part of the IDG Contributor Network. Want to Join?