As a business analyst, there are two types of clients that, while extreme examples, can be the reason a project fails.
These two groups are made of:
Those who know exactly what they want, but don't know how to express it in a meaningful way.
Those who only have a vague idea of what they want, but aren't sure how to explain that.
Dealing with these two can be frustrating, but doesn't detract from the fact that you need to elicit the requirements in a way that work can begin, right?
Many online forums tend to focus on strategies to engage your client, but only when they know what they want. They conveniently ignore the shitty times when gathering requirements is like pulling fucking teeth from a rabid pygmy marmoset.
With that, we share our four-step process for pulling the requirements from your client. Important to note that this process can be used on all types of clients, not just the two mentioned above, however, it was developed with them in mind.
Ask why five times: This is a pretty standard strategy that gets shared a lot among project members, but it's a fantastic place to start. Five times is used to stress that it should be asked a lot. The closer you can get to the purpose of the project request, the easier it is to assess the risks involved, in an informed way. If the purpose of introducing the man-eating Bengal tiger is to improve productivity, you can argue that having a weekly, company-sponsored social hour would have the same positive effect on productivity, and probably cut down on turnover.
Ask "and then what" at each step of the discussion. This is to avoid the problem of having an unknown between the idea and profit. Ok, so you let loose a Bengal tiger in the office… and then what? The requestor needs to understand that the tiger does not directly lead to productivity. Also, it can help to identify potential gaps in the process, like the Tiger should be famished when it's released.
Embrace your inner pessimist. In my experience, a problem is decision-makers don’t fully understand the gravity of the risks involved. Let’s say that the tiger eats Cheryl from accounting who is the only one who knows how to use the payroll software. Not only will we need to pay a settlement to her family, but her daughter will probably also use this tragedy as the inspiration to become a supervillain in the future.
Be a pain in the ass. Initially, I said “don’t be afraid to push back against bad requests, but I see this as a culmination of the previous three steps. I see it frequently, both at my current organization and in various articles regarding other companies… decision makers get blinded by the dollar signs at the end of the project. Being a real fucking pain is what I think makes this philosophy work; annoying the client to the point that they have to think about the project in a way that doesn’t just involve a magic money button. Being a pain in the ass is especially useful when there are concerns over security, safety, compliance, or accessibility. Releasing the tiger in the office isn't fair to those with disabilities, since their wheelchair will prevent them from all the benefits of having a tiger running through the office.
There are times when the client will tell you to stop worrying about things and just do your job, which sucks, but we also have strategies for that, but that is for a future Quick-Take.
Comments