Although Business Analysis is about helping the business solve their problems, there’s a dark side to this which often gets us into trouble.
After a long and shaky flight I got to the immigration counter in Orlando airport, and was excited to greet my friend on the other side. It was years since we’d met, and we had plans to connect and explore Florida. I really needed the break after a long arduous project, and a lot of difficult stakeholders.
At the counter the official asked me how long I was staying for.
“4 weeks”, I said.
He asked me for my visa. I was a bit surprised - maybe he’d misheard it as 4 months - longer than the 3 month visa free period. I told him I didn’t need a visa.
“You need a visa - that’s your responsibility. You can’t come into the country without a visa.” I repeated that I’m only here for 4 weeks. And he started getting irritated. “Sir, you need a visa.”
All of a sudden another official came and barked “Come with me sir”. He escorted me out of the queue and into an isolated room. I had no idea what was happening - and they wouldn’t let me make any phone calls. It was like being in prison.
After 2 hours of waiting without any information, an official came in and explained I should have completed a visa waiver form. They told me I risked being deported or having to pay a $500 fine. Sure I should have completed the form on the UK side, but since I was at the border, surely this could be quickly rectified.
Similarly as Business Analysts when we’re at the sharp end of solution delivery that doesn’t match a customer's needs, at that time it just can’t be rectified and we can’t help thinking that we might have been able to prevent this at the early stages.
In this article we’ll explore 3 ways to get out the trap of being solution oriented up front to shift more into the problem and needs to get better requirements. We’ll cover how to:
- Understand pain points deeply
- Ignore the ‘solution chatter’
- Let the customer lead on solution
Technique 1: Understanding Customers Pain Points Deeply
Often times as Business Analysts we come straight into a project and are asked firstly to put together requirements - going through the motions of elicitation, modelling, and validation.
The problem with this is that it’s assumed that we are focusing on the right problem, and are deeply solving it. You and I both know that everyone goes into solution mode very quickly - so it’s pretty likely by the time you land up in the project the solution has already been chosen. But that’s dangerous.
By taking a step back and understanding a client's pain points thoroughly, your whole perspective changes. And so going through a robust process of understanding pains and problems around the project you’re on is an investment of time - and you’re very likely to uncover some of the subtler elements that will guide the solution down the line.
That means making sure you set expectations and carve out time when you start a new project (in whatever stage it’s in) to conduct this exercise. Even on a fairly complex project this can be done quite quickly if you are focused and have a system.
And you’ll get a lot of respect and credit for this.
Technique 2: Ignoring The ‘Solution Chatter’
As you are exploring and understanding problems and pains with stakeholders, immediately your mind will go into solution mode. It’s like comfort food for a business analyst because you are, after all, there to solve problems.
The problem with this is that it will cut short your exploration. Because your mind has raced to the end (the solution) you might justify that you know how to solve this even before fully exploring because:
- You’ve seen the same problem before and the solutions you’ve been involved in have fixed them
- The client doesn’t really know how to solve the problem, and because you do you feel like the ‘hero’ you want to show them how it could be solved
- You find it hard to dig deeper with the client because you aren’t familiar with the method, and so it’s easier to settle on a solution
What this will do is create a premature picture of the problem. It then becomes a bit like going to the doctors who does a quick assessment and then prescribes you some medicine - which doesn’t really fix the problem.
What they should have done is probed more deeply and sent you for some tests to establish the underlying cause. Treating that would then properly solve the problem.
Technique 3: Letting the Customer Lead On The Solution
Once you’ve all established what the solution is, the next temptation is to lead the way the solution will be put together on behalf of the business.
Why do we as Business Analysts do this?
Firstly because we don’t want technical teams to steer the ship. Technical teams are there to deliver the needs of the customer.
If the Business Analyst were not in place to referee the solution implementation, what would happen is the customer would be blindsided by the technical teams jargon and concepts.
This would impel them to helplessly let IT do whatever they needed - “because they obviously know what they’re talking about, so must be on the right course.”
This is where the Business Analyst steps in. But for the same reasons we might steer the ship - because the customer doesn’t understand requirements and change delivery, there isn’t time to help them understand - or they just don’t have time to be involved in detail. And so you might find yourself inventing requirements for the customer, filling in the blanks so to say.
By facilitating the discussion and framing concepts and ideas in a way that empowers the customer, the burden of responsibility shifts from the Business Analyst to them.
This is the very purpose that Business Analysis techniques exist - to help the thinking process.
But Customers Don’t Know What They Want - So How Can They Lead?
The artful Business Analyst acts as a coach to help the customer uncover what they really need. So we aren’t just giving the customer free rein to decide everything. As I said before, we act as the referee.
On one side, the customer asks for EVERYTHING. On the other side, technology wants to make shiny toys, or just get something over the line. But when you help the customer dig deeper they realise that they don’t need everything at all.
The Business Analyst, therefore, is an expert facilitator of change delivery. Through questioning, cross questioning, challenging the status quo.
It’s not that customers don’t know what they want. It’s just that the field of technology is highly complex, and it’s hard for them to visualise what a finished product looks like. They also might not appreciate that priorities need to be applied - because delivery resources are finite.
Through this process, you are demonstrating to clients that they do know what they want. But they need someone to help them discover it within themselves. And this is what elicitation is all about.
Let’s Put This into Practise
You’re on a project. Your manager has asked you to put together a requirements document for a new system build. You don’t really have a clear understanding of the exact problem you’re solving.
What do you do?
Spend a couple of days getting to know the background behind the project - and putting together a clear problem statement, specific objectives for the project and a solution scope. If you can’t articulate this then either:
- The project you’re on is a behemoth, and the area you’ve been designated to work on is a tiny fraction of an overall delivery
- There isn’t a clear problem and you need to dig deeper
To deal with number 1 above you should see where your piece of work fits in to the overall delivery and understand what problem it’s solving. Just because it’s a fraction of the overall delivery it doesn’t mean it isn’t solving a problem. That means you need to dive deeper into a finer grained problem area. Keep searching.
Let’s Do A Quick Recap
- It’s easy to fall into the trap of solution mode as a Business Analyst and we need to control it
- The first step is to take a step back and understand the problem we are solving much more deeply
- What this does is creates enormous clarity, raises unanswered questions and could save a project from going down the wrong path
- When you first start a project, make sure you tell your manager that you need time understanding the problem we’re solving before starting on deliverables
- This will earn you respect and credibility
- As you are going through understanding problems, ignore the ‘solution chatter’ that your mind throws at you because this will cut short your problem investigation
- Now when you’re in the process of requirements (which is what customers want from a solution), facilitate it in a way that empowers customers to lead their thinking
- Because of politics, lack of training and other factors, it’s natural for the business to be led by IT or even Business Analysts and this can be dangerous because their true ‘wants’ won’t come out
- Although you might think customers don’t know what they want, you’ll be surprised once you start acting as coach and helping them come to conclusions
- It’s because software is complex and hard to visualise, therefore your BA tools and resources can help elicit better quality wants from the customer
So Did I Get My Holiday In The End?
The US immigration let me in. I’d like to think it was due to my charm, but I was grateful I could have a much needed holiday. But it could have been a lot worse, and so doing my homework up front was the biggest lesson.
Find out more
Author: James Compton, Director of Professional Development, IIBA
James Compton is the Director of Professional Development for the IIBA. He is a Business Analyst Consultant and Trainer with over 20 years of experience, and is on a mission to raise the profile of Business Analysts as highly valued members of any good project team.