Many of us have been there. The pressure is on. The deadlines are looming. The project manager keeps asking when the requirements will be completed. You are still grappling with the conflicting information coming from different stakeholders. Just as you think you are putting the finishing touches on the requirements document, someone mentions:
“That’s not what we do…”
“When I was there, we sometimes had to…”
“I don’t know why, but…”
Or, as you are re-reading the requirements, you realize something is still bothering you or sticks out as a sore thumb.
This is a critical point where so much depends on your business analyst mindset.
You may decide:
- It’s too late to dig into that
- You are uncomfortable reopening a topic
- You don’t want to appear uninformed
- There is no time – you have to get requirements signed-off tomorrow
- The developers will figure it out when they get there
- It’s probably not that important since it was only mentioned in passing and by only one person…
This may become a moment of opening the door for an undetected requirements gap. And each of us will probably have a story where such a gap turned out to be a big pain, missed dependency or even a project showstopper.
If instead you listen to your business analyst mindset, you might hear in your gut that it would be wiser to check it out and ask a few more questions. Is there a hidden exceptional scenario there? Did we misunderstand current process? Are we overlooking another business rule?
He who asks a question is a fool for five minutes; he who does not ask a question remains a fool forever.
Unless you understand each scenario and each business rule, and embed this understanding into the business requirements, chances are that others may also not understand. And anything that is not well explained and understood is at risk of being misinterpreted, misrepresented or simply disregarded.
So, if a stakeholder requested to change the order of process steps – ask why. “Because that’s my requirement” is not a good enough answer. Unless you understand why the order of steps needs to change, you will not know what else is impacted, what additional requirements are needed to support the change, or what potential problems might this change create.
As a business analyst, you have to assume that every problem you encounter has more dimensions than you can see at first. Assume that your customers will not provide you with enough details to solve the problem without encouragement and probing. Assume that the information you are given may not be correct and will need to be validated, and certainly will not be complete. Assume that stakeholders may withhold information, intentionally or not. Assume that some critical details that will turn out to be very important will be buried deep in the application code, forgotten documents or one person’s memory. Assume that you will not get the answers you need until you ask persistently and investigate tirelessly.
If the above sounds pessimistic and intimidating, remember that this is also what makes business analysis rewarding and challenging. If you ever wanted to be a detective, this is a chance to practice your investigative skills. When you discover something important, the resulting ah-ha moment can give you a professional thrill and satisfaction that you may come to crave. In summary:
- Ask questions to resolve ambiguity
- Ask questions until things make sense
- Ask “Why?” until you get to the root cause
- Ensure your questions are clear, so that your get answers to the right question
- Don’t forget to listen to the answers
Your most important role as a business analyst is not in finding answers. The exceptional value you bring is in asking the right questions.