How a BA is Like a Waiter
I read an interesting article recently, that used a restaurant scenario to highlight why the customer shouldn't see the inner workings of how food is created in the kitchen, and a lot of this rings true in the world of the BA too.
Let's explain the roles in the restaurant scenario first. We have:
The customer in the restaurant ordering food is like the stakeholders of a software project. They have a set of requirements (what they want to eat), which is eventually built for them and returned for their consumption.
The chef is the development team (you might even say the head chef could be â€‹the system designer). They build the meal to the customersâ€‹ expectationsâ€‹.
The waiter can be see as the Business Analyst in this scenario. They speak to the customer (stakeholder) in order to find out what they want to eat and drink. Sometimes they might push a certain agenda to the customer (if perhaps one of the meal options contains an expensive ingredient, or simply because a lack of a certain ingredient means making one of the meals cannot be done, or worse, substituted with a different ingredient!).
The waiter also interfaces with the chef, informing them exactly what the customer wants, including anything specific that isn't part of the original meal, or even perhaps a customisation (medium-rare steak please!
So lets try and use the above scenario to explain some best practice.
The customer is really only interested in the meal that will be placed in front of them. They care that the meat has been cooked medium-rare, that there is a side of peas on the plate, that the steak sauce is sufficiently spicy enough for their tastebuds, that a steak knife has been provided.
They do not care about how that piece of meat has been cooked. They have no interest in the type of frying pan used, or what position on the hob the pan was placed on. They don't even really care about what specific ingredients have been used to create their wonderful steak sauce.
Could you imagine walking into a restaurant to order a steak, and the waiter walking over and asking you to confirm the pan to be used to cook your meal? Or to decide which herbs to put into your sauce?
There are three main issues with the above.
Firstly, the customer doesn't care about those little details, bringing them into the conversation means more time spent over the how, and less time spent over the what. They'll end up picking the pan to cook the steak in, but you'll end up serving them a chicken as the requirements have been lost in the detail, or potentially not even discussed!
Secondly, the customer is probably not even the right person to be deciding on the pan to be used. That's the Chef's job. The Chef understands the world of pans a lot more than the customer, they are in the best position to be making this decision.
And thirdly, what if all the pans the customer had chosen are old and battered, and not up for cooking steak any more? If the customer chose the pan, the Chef has to inform the waiter this cannot be done, the waiter has to then go back to the customer and tell them to pick a different pan.
If the customer lets the Chef choose the pan, then the Chef is free to pick the best pan out of those available to do the job. No need to hold up the process to ask the customer to raise a "change" with the waiter. The customer then gets their food quicker, and maybe even to a better quality as the SME (the Chef) has already picked the best approach.
I see this a lot, and it's one of the biggest reasons as to why requirements are not met, and sometimes not even gathered.
A project's success is defined by how well it meets requirements. So... How can we deem a project a success if we don't even know what the requirements are?