Today we’re talking about a problem all business analysts face – what to do when the developers push back on your requirements.
Here are a few key points:
- Re-frame what the developer means by “that’s impossible”…everything is possible, given unlimited time and budget.
- Be sure to understand the true business need, and not present a business solution.
- Collaborate to find possible solutions to the real problem, which may not even involve technology changes.
To learn more about the business analysis process and handling sticky requirements challenges like this, check out the BA Essentials Master Class.
For those who like to read instead of watch, here’s the full text of the video:
I wanted to jump in and talk to you today about what to do when we hear from the development team, “That’s impossible.” I know I’ve heard that my career. We actually just had it come up with a course participant last week that she had this beautiful business need that had come out, a really exciting way to help the business. She brought it to the developer and he’s like, “No, we can’t do that. It would require re-engineering the whole database. It’s way too big.” “Impossible” is what he said.
In the reframe on that, we’re going to talk about three steps that you can take and three things to think about when that happens. The reframe is that everything is possible. It just maybe isn’t feasible given the budget that you have, the timeline that you have, and the current technology you have.
#1 – Define “Impossible”
“Impossible” really means we may have to spend three months reworking the database to solve the problem in the way that she presented the solution to that developer. That could be true. That developer may be thinking, “I know I have 10 other things on my list and nobody is going to approve this.” And that really is what impossible often means.
The first thing you want to do is unpack what does “Impossible” mean? It’s never that it’s not possible; it’s usually that it’s not feasible given a certain set of assumptions. The more you understand that, the better that you can do as a business analyst to come up with a feasible solution to the true business need.
#2 – Clarify the True Business Need
That’s the second thing you want to do is clarify what the true business need is. In this case, it’s not so easy to do. The business came up with a solution. They say, “We want these specific data elements removed from our process.”
The developer responds, “We can’t do that. Those data elements are connected to all kinds of other things and it has an impact on reporting, and it has an impact on other parts of the application that aren’t even touched by those business stakeholders.” It has this broader impact when they were just saying, “Well, let’s just remove those three fields on the screen and then our problem is solved.” That isn’t really the business need.
What was the business need driving the removal of those fields? That was how they were setting goals with the clients. There’s a deeper need there. Their work performance was being tracked based on something that they couldn’t control. That’s a huge thing. There are a lot of factors that go into resolving that, not just the technology.
That is the first lesson. Look at the true business need so that you can understand the true scope of the solution which may or may not be just the technology.
#3 – Reframe What Impossible Means
The third piece we talked about, reframing what impossible means. First, you find out that true business need so you can go back to the developer with a business need instead of a business solution to the problem. The next piece is to figure out a way to collaborate to move forward.
What needed to happen from there is to get a couple of the key business stakeholders together with that technology stakeholder.
- Maybe there are some other people to be involved and talk about that business need and brainstorm together possible solutions to this problem that aren’t, necessarily, to remove those fields completely.
- Maybe they can be disabled.
- Maybe different content can be captured in those fields.
- Maybe they can be made optional.
All kinds of different possibilities exist. At least give the group the benefit of having some time to talk through that and to come up with possible solutions that may or may not be what the business originally presented.
Oftentimes, our best developers are going to come up with creative solutions once they understand that true business need. Our jobs as BAs is to be in the middle of that process so that we’re communicating, helping our business stakeholders understand what their true need is and not just what they see the solution as. Then helping the technical stakeholders come up with solutions that meet those underlying needs. This is what we do as a business analyst.
“That’s Impossible” is an opportunity to step up as a business analyst
When that example came up in class, I was so excited. I was like, okay, this is where the juicy stuff happens that we get to deal with as BAs. This is a normal thing to have happen. The course participant was a little frustrated. “Why did this happen? I finally had this great idea and it just got brushed aside.”
No, it’s an opportunity for us to step up, for us to engage, for us to really facilitate solving the true problem to be solved there. It’s not the time to step back, it’s the time to step in, but to step in in a much different way than, “Really, you can’t do this?” Let me show you how it’s possible. It’s not stepping in or forcing the developer to a specific solution. It’s stepping in to facilitate that collaboration process so that the most possible value can be delivered from the technology in the best possible way.
That’s a lot of what we do as business analysts.
To learn more about the business analysis process and handling sticky requirements challenges like this, check out the BA Essentials Master Class.