Thursday, 08 March 2018 09:31

Giving the stakeholder what they need over what they want

Written by

"Akash this is not the solution I wanted or was expecting. You have come up with something I don't need".

I wish every Business Analyst faces this situation at least once.

I recently had to deal with this challenging situation where I had to make the tough call of giving the stakeholder "a solution he needed, over the solution he wanted".

Convincing your stakeholders about a solution can sometimes get tricky. Very often stakeholders come up with a solution to their problems on their own and expect it to be implemented as is. I agree that stakeholders with good technical and business acumen often make a BA's role easier by knowing exactly the problem to be addressed. But, if that is not the case, then it's the duty of a BA to study and understand the real problem and come up with the solution which is needed, as sometimes the real problem is not the one which the stakeholder thinks is and is trying to address.


Below are some useful things I learned from this situation and would love to share with you all:

  1. Listen to understand: How well we listen, is as important as how well we speak. It is always beneficial and truly a good habit to give the stakeholders our complete time and attention, so we can better understand the problem they are trying to address and the reason behind it. Also, we must figure out and decide whether the problem they wish to solve is actually the problem or not. When it's our turn to speak, we must be very polite in expressing our denial to the solution the client thinks is right.
  2. Don't rush into thinking a solution: Most of the time we are excited enough to quickly jump to forming a solution, even to the extent of designing mockups and screens (especially if we are new to the BA profession, as I am). But it is always better to peacefully give the problem a second thought, and think of different approaches to solving it. We shoulddiscuss it out with our peers whom we feel can innovatively contribute to our solution.
  3. Win the stakeholder's confidence: It is only when we win the stakeholder's confidence, we are at a level to discuss out or advice on solutions. A Business Analyst must show that he cares & understands about addressing the stakeholders problem as much as they wish to. As Damon Richard said, "Your customer doesn't care how much you know until they know how much you care".
  4. Do very strong research: If we feel the solution stakeholder is expecting is not the one he needs we must always back our solution and recommendation with in-depth statistics, market research and studies. Provide them a detailed walkthrough about your solution, comparing the pros and cons of the solution they want. A practical backing will always help in convincing and get them ready for other solutions.
  5. Be ready to adjust and incorporate changes: It's always in every ones best interest to keep more than one solution ready so you can amalgamate and blend the best from different solutions. We must always be ready to incorporate changes to the solution we feel are best for the stakeholders interest.
  6. Appreciate them for their understanding: We must never forget to appreciate the stakeholders for their understanding and acceptance of a new solution, even if it was our idea. Thank them and give them the credit for accepting "the solution they needed, over the solution they wanted!"

In the end, I would like to say that we must never hesitate or be conservative in disapproving a solution. To quote Laura Brandenburg "We are Business Analysts and being a Business Analyst is not for the faint-hearted". And yes, my stakeholder is now happy and satisfied with the solution I came up with. Haha!

Read 3211 times
Akash Deshpande

I have been working in the exciting profession of Business Analysis for just over a year. Although I am at an entry level of my career in this field, I find myself grateful to be a part of this ever-growing and highly challenging profession. I have relevant experience as a Business Analyst in web and mobile application development. I like working in teams & a fast paced environment, not to mention "Agile." Also, have knowledge of below-mentioned points:

  • Requirements Gathering Process & elicitation with Workflow/ Process Modeling and technical requirement Documentations like BRD, FRS, and RTM with others.
  • UML Interaction Diagrams, Class Diagrams, Activity Diagrams, Use Case Diagrams and others.
  • Knowledge of Enterprise/ Business Analysis and techniques.
  • System development life-cycle and Project planning techniques and requirements engineering, Agile.
  • Tools like MS Visio, Balsamiq, Axure, JIRA.
  • Comprehensive knowledge of presentation software, word processing software, and spreadsheets.
I am an empathetic person with good attitude and always on hunt for opportunities to enhance my professional knowledge and skills.

Thank You!

© BA 2017

macgregor logo white web