A message posted by in the discussion forum of the Business Analysis Leadership group got me thinking. We were talking about requirements reviews as a good practice to improve the quality of the requirements delivered by a business analyst, and a manager wrote,
I have seen some companies where the manager tried to implement a requirements review done with the other BAs. Because the other BAs don’t know much about the project, and nothing about the business needs, processes and requirements, this kind of review was soon abandoned because it was not productive at all.
It’s curious how people will find all sorts of excuses to give up on an approach that has been proven to produce a positive impact. The book Software Requirements by Karl Wiegers, among others, provides good advice on how to set the stage for effective requirements reviews. Among his tips:
Give reviewers context for the document and perhaps for the project if they are not all working on the same project. Seek out reviewers who can provide a useful perspective based on their knowledge. For example, you might know a coworker who has a good eye for finding major requirements gaps even without being intimately familiar with the project.
In my experience, it’s not hard to find people within the organization capable of highlighting issues with a set of requirements (or user story acceptance criteria). Members of the BA, QA, development, and support teams are typically good choices. Even when they’re not very familiar with the specific project or business process, by reading a project overview and reviewing the process flow they should have enough context to make a positive contribution during the requirements review process.
But this is only one of many examples I see in the BA community of people finding excuses not to apply proven techniques to their business analysis work. Here are others:
“Oh, but it’s easy for you to do that [ take a step back to focus on the problem space before jumping into “solution mode”] because you shifted to product management from business analysis. It’s much easier for you to impose resistance when stakeholders are impatient to get their project started before the problem is fully understood”
(Hmm… No, I’ve used the same approach while working as a senior business analyst at a large tech company, and it succeeded even when I had been explicitly told by IT management not to talk directly to our business stakeholders. )
“This book doesn’t provide any solid material for reuse – its full of theoretical approaches which will never work on the job practical approach. The methods and the approaches are good for schools or colleges which teach BA for first timers.”
(Really? Before I made the recommendation in reply to a request for a good reference book on BA activities, I had worked on two successful large projects that used the exact same techniques it describes. Clearly this person was looking for a “silver bullet” that doesn’t exist, while refusing to try techniques that do work, but only if you put significant effort to prepare, educate executives and teams, etc.)
To avoid falling into the same pitfall, here are a few things to ask yourself:
- Am I looking for excuses for not doing the hard work? For example, not defining quantitative success criteria for my project because there’s no time or people to provide context?
- Did the approach I use fail because it’s not applicable to my situation, or because I’ve not applied it the right way? Scott Sehlhorst has written great article that illustrates this situation. His post is about product roadmaps, but it could be applied to useful BA practice: “Drawing a stupid relationship diagram is bad, therefore, don’t draw a relationship diagram!”
- Did I use the premortem technique to avert failure? When you’re attempting a new approach, it pays off to pretend a success or failure already occurred so you can identify the conditions required to win, instead of waiting until the end of a project to find out what went wrong.
Image by Mario Klingemann