We have all been here. You’ve defined just the right feature or solution to solve a specific business problem.
It’s elegant.
It’s simple.
It’s even got a hint of beauty about it.
When you get ready to present it to your technical team for implementation, you get the answer you least expect…”that’s impossible” or it’s close equivalent “that will take us months” (when the budget is weeks).
As the business analyst, what can you do?
Well, one option is to let the project manager deal with it. After all, you did “your part” in figuring out the problem and the requirements. You can sit back on your laurels knowing you’ve provided a solution that the customer wants and stay out of the fray. But that’s not what you will do because it’s in your DNA to handle these things differently.
The best BAs do not simply define requirements, they create change and solve problems.
Now there are many ways to handle this situation and how you proceed will depend as much on the individuals on your team as your history with these people.
First of all…breathe. I mean take a really deep breath and relax. Let the tension of the situation out and focus on what you want. You want to help the business solve this problem, right? What’s the best way forward?
One tactic I like to use at a cross-roads between requirements and design is to take a couple of steps back. Oftentimes we get so excited about our own ideas and those of our customer that we forget to get the implementation team involved early enough. So by the time we’ve got it all worked out, they feel like all the intellectual challenge is gone. They push back because it’s easy to find issues with another person’s solutions when you have no ownership in them. Think about it, you’d probably do it if you were in their shoes too, just to spite you and your difficult BA self.
So, take a few steps back. Go back to the problem you are solving and get crystal clear on it as an implementation team. Encourage them to ask questions and help you clarify your thinking. It’s important you go into this activity with a truly open mind. You have to trust your implementation team, but also respect their intellects and believe that there is most likely a better solution.
Then start collaborating on solutions. Brainstorming sessions can work. List out 10 ideas. Pick 3 and dive a bit deeper. Be open to hearing what they have to say. Facilitate active discussion amongst them.
Only chime in if the solution is far off track from a real business requirement. And then say something like “I see the value of this idea, but I’m not sure how XYZ would be accomplished.”
Oftentimes after these sessions you’ll be surprised how close the team’s solution is to your own. It will be tempting to point this out. Don’t.
Remember, it’s never important that you know how to solve a problem. As a BA your hands are most often tied when it comes to implementation. What’s important is that your implementation team is confident they can solve a problem within the constraints of time and budget.
You can’t force people to code your solution.
You can lead them there.
You can facilitate discussions.
You can help find good solutions.
But you can’t force them. In the end, they have to own it or it’s simply not going to work.