We have all been here. You’ve defined just the right feature or solution to solve a specific business problem.
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.
>>Looking for More Support?
Consider the Effective Conversations Template Collection which contains 20 conversation scripts with 3-5 minute videos to ensure you know exactly what to say in some of the toughest situations business analysts face.
Click here to learn more about the Effective Conversations Template Collection
20 thoughts on “What To Do When a Developer Says “That’s Impossible””
Hi Laura, I subscribed to your lessons a few days ago and I just went through the 2nd lesson and this article. Amazing! I think your lessons contain useful, not only interesting information. I am happy I subscribed, I congratulate you and I am so looking forward to read all of your articles!
Pingback: EFFECTIVE COMMUNICATION –A MUST FOR A BUSINESS ANALYST | Anisan Technologies
I am definitely familiar with that situation but I don’t necessarily see it as a problem unless people who do not care about those details are in the meeting. When you say “over-complicate” are you speaking from your business expertise or technical expertise?
In my experience, developers and technical architects often need to have long discussions about possibilities and details to fully understand the technical scope of the problem. If you feel that you or your business stakeholders are being unnecessarily dragged through these discussions, one solution is to make someone from the IT side accountable for holding and leading the technical discussion, then coming back and collaborating with the larger group on the technical possibilities related to solving a specific business problem.
I agree that should be collaborative discussions as early as possible.
But a challenge I’m facing when involving technical teams is that discussions suddenly get very detailed and technical.
Certain technical people tend to over-complicate things and the entire scope of the meeting is screwed: hours of talking about all the details. This is even worst when there is a cross-functional requirement when more teams need to be involved.
Anyone familiar with this type of situation? 🙂
Thanks for all the great posts!
I could only read the first couple of comments and i also agree that it is a very common thing in the BA world. In my project, i always try to have a lead from the development team to be a part of JAD sessions and during the same day i discuss the out come of the JAD with him seperately. By doing this, we both find ourselves connected and be on the same page. Thanks for the posting 🙂
It was a great discussion. Expecting the same brilliant and realistic topic form you for discussion.
This is really a very common situation if we, as BAs, worked in isolation. The word “collaboration” used by Laura is the key to solving this issue.
Whatever methodology (agile, waterfall) is being used by the organization, it is the best idea to collaborate and have a joint discussion of the business requirements before proposing or suggesting a functional solution.
The technical team should be empowered to come up with their high level solution ideas to solve the business requirement. This way, there will be no surprises and the requirements document will elaborate the details but not provide surprising suggestions to the technical team.
I have found this to be the most useful way out of that situation.
Hi. It’s very important to build a team rapport bewtween the BA and the Developer(s). I find that when I present the “what”, allow the Developers to be creative in the “how”, and leave room for their suggestions, we come up with a solution that fills the bill (within the time constraints, of course).
If an complex user requirement leads to a task that demands more time than expected, discuss options and present them to the users. Explain the pros and cons to the users- taking into consideration the Developer feedback. This seems to help in most cases.
It’s important to let the Developers know that their knowledge and experience is respected– just as you would like the opportunity to explain why the requirement is important.
Hi Mahipal, Yes, of course. My point is oftentimes things appear impossible at first glance but after some thoughtful collaboration become achievable.
Can we modify the proposed solution if technically is not possible to implement?
Thanks everyone for all the great comments. I’m really excited about this discussion and looking forward to posting more on some related topics.
As I read through the comments one thing that occurred to me is that I have most often gotten myself into this situation when outside circumstances prevented me from getting the IT team involved early enough. This happened to me several times in my early days as a BA when BA resources outstripped the development ones (because other projects in the company were facing delays) or we were out-sourcing development so we got much further down the solutioning path than I would typically suggest.
I agree, it’s always a balancing act as that line between requirements and design / problem and solution remains (and will remain) gray.
In our Feature Blitzes, the Business Analyst (BA), programmers, and others all decide the design together, so this situation rarely comes up. When a timeline can’t be met, we just break the feature down to pieces that give benefit to the customers by themselves, without being the full solution. Then we take this back to management and say either we need more resources to finish it in the time frame or we can finish x of 7 pieces by the deadline/release. We more often got more resources as the features were importants, but other times 2/3 of the feature reached the customer by the release and the other 1/3 for the next release. Releases were every 6 weeks for one product and 3 times a year for another, so either way the wait wasn’t extremely long.
I have just recently been stung by such a situation i lead a small team of Architech’s and senior dev’s to produce a N-Bus SOA system that uterlizes REST based routing and solved a number of problems which had stopped the companies product range moving forward.
It was complex internally but it was all test driven and using it if you followed the recipe of do X, Y, Z as it were was simple all the complexcity had been abstracted away.
We presented it to the product teams and they just slated it for 3 days.
In truth little of what they had to say had any real body in facts when you examined it but it was enough that force of opinion was against it for the company to bin it before it had even been properly tried .
Now this was a system that had been driven from requirements and had been built with full business buy in demo’s had been given at several stages. And we were following a weekly release cycle to business.
The mastake i made was to not involove the product teams the reason i didnt was because there schedule didnt allow the time for there involvement but as you pointed out had i of got them involved sooner i would have got by in and got them on board and things i think would have worked out better.
Having been a developer for 10+ years, I’ve personally been the developer that says “that’s impossible” although I normally backed it up with “within the timeframe needed.” I’ve always said that ANYTHING is possible, the only thing holding you back is time, money and/or resources.
This issue and your solutions can actually be used across multiple departments. SEO’s run across the same problem all the time. One thing I’ve found to be effective is to have an advocate on the “inside.” Now this isn’t always possible, but if you have someone on the development team who clearly understands the business and the reasoning for the requests, they are more likely to help push solutions along. Or at least help the dev team to come up with workable solutions for everyone.
Also, I completely agree with letting the developers come up with the solutions. Often times if developers are told what and how to do something, they’re going to react negatively. It’s the idea that those who don’t code, don’t know. (Believe me I’ve felt this many times) So letting the tech team figure out the how, is going to get you much farther in the project.
Thanks for this post! Luckily not all developers are like this. 🙂 And as you said we have to learn to deal with those BA types also ;).
I really enjoyed reading this article. This is very common in the BA world. The key like you said is to bring the implementation team early enough so that you don’t spent too much of the project’s time negotiating or re-working your solution. Implementation team just like us take pride in “solutioning”. They want to know that somehow their idea is heard and adds value. It’s really an art to know when to bring in the implementation team. My advice is always to understand/define the business requirements (objectives, problem statement, the “whys” of their undertaking) with the client/customer and bring in the implementation team when you are ready to “solution” (building the solution requirements). You will find that because of their experience, they may actually come up with things you never thought about. And as you said, if the BA is open minded, it’s only going to benefit the customer in the end. They will receive the quality they deserve; You would have won the implementation team; You would have saved yourself hours of trying to be creative or trying to convince the implementation team of your idea or producing re-work on the requirements you just finished writing 🙂
“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. Save this for a friend over drinks, not for your team.”
Yep. It’s important to be right. It’s less important to be CREDITED with being right. If you let the techs “own” the answer even though it’s your own answer, they’ll have an emotional commitment to making it happen.
I think that building a good rapport with the development team AS you are doing requirements gathering/analysis is crucial. Once you know those “guys” you can get a feel of how to respond to each one when they say “it’s impossible”. Then you can respond to the one guy that likes to argue by disarming him. The other guy, you can smile and get his input. Surprisingly, it’s often a lot like your idea. It’s never about being right, it’s about getting the job done and getting the job done right. If the project succeeds, you succeed.
I agree with David – good insight in this post, as always.
Collaborating on solutions is always good, but other BAs probably have been through many cases like the ones I’ve experienced multiple times, of being told that something was impossible only to come up with a solution myself (via a simple change in the database structure, or a new way to handle an exception, etc.).
If the IT team is used to seeing the BA as an ally, there’s a good probability that the offered solution will be gladly accepted–here is yet another good reason to put an effort into building a healthy, respectful relationship with the implementation team.
Hey Laura! great advice, i like the last para especially and particularly, that you can’t force, but should lead them there.