Mustafa Bootwala

As a business analyst, or any customer facing role involves facing different types of customers and at times we will face angry or irate customers

How to deal with angry or difficult customers
1) The first thing we can do is remain calm, we need to undertand that they are not angry on us, they are angry on the situation they are in.
2) Listen and acknowledge, Keep your ears open and rather then replying to him by making excuses are in or giving clarifications, just hear him out
3) Take ownership, winning an angry customer is to take the ownership of the situation, process either we can choose to pass the task to someone else or we can assure him that we will look into it and get back within reasonable time
4) Empathise, put yourselves in their situation and analyse the pain he is going through
4) Always follow a project management guidelines and have everytihng in writing.
Example we follow Agile development, so we need to document every requirements in User stories with clear Acceptance criteria and proper sign off having everything in black and white helps a long way

How to manage high touch customers

In high-touch accounts, status quo is not sustainable. You need to constantly be planning how to get more strategic and larger in the account—or you will be engineered out. We need to make sure that we are driving for value and just project
completion

Ability to set expectations
Setting expectations early on in the project is very useful as it gives everyone clarity about roles, responsibilities and expected deliverables. If we can under commit and over deliver that can generate a wow factor. If the customer knows early on the project what he will get and by when that will save a lot of time for everyone
There are many ways to do this
1) Create mockups and take sign offs
2) Work on Data models and agree with all and take sign offs from all stakeholders including client SMEs and other integration experts
3) Share test cases with client early on
4) Document the US in a concise and easy to understand manner for all
5) Make sure all stakeholders inclucing client, dev team, test team are on the same page early on calling a spade spade early on is a good practise if there is any amibuity or doubt in a Business Analysts mind, get it clarified before signoff and before dev starts
6) Follow Agile and take iterative feedback of client on every step

Once the development has started and then we set expectations that will lead to customer dissatisfaction and will leave you with no time to correct course if something is going wrong

Push back on requirements
1) Push back from the Tech Team

We often face a push back from the tech team saying "Thats not possible". When we discuss some requirements with tech team they just say its no possible and close the discussion.
Its very important for a business analyst to understand the technical workings and ask the correct questions to break down why its not possible ? is it a data model change ? is it just a UI change / will it require some re-work etc etc. If we are aware of the technical architecture and technologies that are used then we should be able to discuss with tech team in their own
jargon and that should help us in knowing the exact issue and then we can build our solution accordingly

2) Push back from the client
Often times we need to push back clients and say NO to certain requirements
When we are doing it we need to make sure
1) We have facts, data, technical clarity and business knowledge
up our sleeve
2) Shold stay cool, our demeanour can diffuse the situation at times
3) Be active listener, before speaking just hear out the client
4) Take notes if required
5) Dont use words like but, nopes, not possible, etc
instead try and use positive words like yes, ok etc
6) Be assertive dont let them push you around
7) Make sure you have all the documents, emails, data correctly in your favour while you rest your case
8) Be smart and have an equal counter
ex. a client wants to add a new attribute and change data model logic, which is a major change given the deadline is very near
You can simply counter by saying yeah sure we can do this, we will have to extend the Go Live by two weeks and reschedule the roll out plan and charge extra
ex. a client wants to have a new major change at the last moment, a business analyst can simply put that sprint is about to be delivered and at this last hour change has to be taken as part of next phase or release cycle

When you counter with equal argument, you are basically saying No very politely

How to handle chaning requirements
One of the best way to handle requirements is to follow a project management guidelines, one of the best methodologies used these days in IT is Agile development.

One of the key principle in Agile Manifesto is: “Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.”

Lets look at how Agile helps

1) Regular customer inputs and discussion with the team
There are constant status update calls and stand up calls with all the team members, this ensures that every one is in loop and customers requirements are understood correctly, even if customer changes its requirements
2) Agile sprint planning, a working product is shipped to the customer after every sprint, this gives customers time to test it and incorporate new changes if any, this can be handled by agile two weeks sprints. This way customers are constantly in sync with what is being developed and there is always scope to handle new requirements in new sprint cycle.
3) Task boards for tracking who is working on what
A task board simply lists down what are the tasks, who is working on it and dependancies if any, it tracks
To do
In progress
In testing
Done
Tasks boards help manage changing requirements because of the visibility they offer
4) User Stories and sprint planning
User stories help document every details possible, a concise and well written story with acceptance criteria helps delivering a good working product

How to handle vague requirements
With Agile development we can handle vague requirements easily. When customers have vague requirements, we should try and ask them more Open ended questions, this helps in knowing more about the reqs.

Give examples to customers of other similar projects that you have worked on, this way the client can have more clarity as to what can be achieved

Try phased development / multiple releases divide the project into different phases to work with the unknown. break down the user stories and start working on the most clear ones first and then that should give clarity into the unknown.

Make assumptions
Put down the assumptions and communicate it with all the stakeholders

How to handle too many requirements
Follow MoSCoW.
MoSCoW method or MoSCoW analysis,is a popular prioritization technique for managing requirements. This method helps key stakeholders understand the significance of what to develop in which release.
The acronym, MoSCoW, stands for 4 different categories of initiatives: must-haves, should-haves, could-haves, and will not have at this time.
Sometimes, the “W” in MoSCoW is used to stand for “wish” instead of “will not have right now.”

Best wishes for your next project