To summarize this LinkedIn post:
Imagine that you’re a Business Analyst in a software project and your customer has escalated about you to your Project Manager saying “your BA has no experience and lacks the competency to handle our requirements”. You do have experience and competence as a BA – that’s why you got the job and were put on this project! But the customer’s industry is new to you. You’re learning and doing your best to get things right. At the same time, your customer is not supporting as expected in terms of providing requirements due to their internal political reasons. You’re caught in the crossfire between customer’s IT and business and are being blamed for substandard quality of output from your side.
What should the BA do?
As program director, I went through a very similar experience when the project sponsor escalated to me about slow progress of requirements.
As illustrated in the following exhibit, requirements is the first stage in a software development project and any delays in this phase will have knock on effects on the timelines of the whole project, so this was serious.
The BA concerned in this case not only had experience and competency as a business analyst but was also well versed with the customer’s industry.
Therefore, I didn’t take the customer’s word as gospel truth. Instead of directing the project manager to fire the BA from the project, I decided to probe a little deeper.
When I talked to my delivery org and the user champions from the customer’s side, this is what I found.
Our BA (and even PM) thought the customer was supposed to provide requirements. Whereas the customer expected the BA to elicit requirements. The difference between “provide requirements” and “elicit requirements” might seem like a matter of semantics but it reflects a 180-degree difference in understanding of roles and responsibilities. “Provide” implies that the customer owns requirements whereas “elicit” implies that the delivery org owns requirements. In software development projects, especially in western markets, requirements must be driven by the BA.
Business users admitted that they did stonewall the BA at times since they were irritated by his frequent pings via chat to seek requirements in a piecemeal fashion. When I conveyed this to the project manager, it was an AHA moment since chat was the SOP in the delivery org. My team didn’t realize that many customers, especially in western world, hate too many interrupts and expect requirements to be gathered in chunks.
The solution was clear. I counseled the BA to follow these steps:
5 Tips to Business Analysts to Accelerate Requirements Gathering
- Take the initiative to book meetings with business users and escalate if there was stonewalling
- Elicit requirements in a structured fashion, and document them in a version-controlled document instead of chat transcripts
- Use proper file names for the progressive versions of the document (e.g. brd-v01.docx, brd-v02.docx instead of doc1.docx, doc2.docx)
- Send the documents as attachments via email with appropriate subject line (#ProTip: Just the filename works!)
- Send a chat message simply saying email has been sent (#FunFact: Back in the day, we used to send a telex and then send the printout of the telex as Post Confirmation Copy by courier. While the modes of communication have changed since then, the need for reminders has not!)
Long story short, everything went through smoothly from there on and the customer withdrew his earlier request to roll off the BA from the project.
To summarize, the delivery org, most specifically the BA, owns requirements. The moment they see the BA taking ownership for requirements, most customers fulfill their end of the bargain to ensure that requirements flow smoothly from their side. But the initiative must come from the BA.
Before closing, let me copy-paste another tip for BAs from my blog post titled Role Of Business Analyst:
There are many things that customers won’t elaborate in formal settings. A good business analyst will develop a rapport with customers and engage with them informally, thus hoovering up more information than the customer has shared with her company during meetings. This will help the vendor to design a more compelling solution.