Are you responsible for the solution? If you read the BABOK closely, you might be surprised to learn that the answer is a resounding “yes.”
Of course, the BA is not responsible for delivering the solution or implementing the solution or ensuring the solution is made available on time or on schedule. But in the task called “Assess Proposed Solution,” it’s clear that we do not get a Get Out of Jail Free card when it comes to the solution, not even the technical solution to our detailed requirements.
Assess Proposed Solution. There is a lot buried in those words: assess – to critically evaluate; proposed – an idea that’s “on the table”; solution – meeting a business need by resolving a problem.
But really, the definition of this task in the BABOK is quite simple.
“To assess proposed solutions in order to determine how closely they meet stakeholder and solution requirements (121).”
You may assess a single solution or multiple solutions. With multiple solution options, this may involve ranking the options.
This task is all about making a decision and solving the problem. Like many tasks in the BABOK, at first glance it might appear that this is something you haven’t done. I would contest it’s more likely you haven’t done it formally, but you’ve participated in this process.
Early in my career, we held these meetings called “use case reviews” where we did a combination of elicitation, analysis, verification, and validation. Part of verifying the requirements involves ensuring they are feasible. With the implementation lead in the room (on a technology project this would usually be your architect or lead developer) often this is a quick assessment. But sometimes the technical solution to a set of requirements is more complex and requires more analysis and discussion. It’s not an immediate decision as to whether or not the requirement is feasible.
In these instances we’d schedule what I called “problem solving meetings” to review the selected “troublesome” requirements and identify potential solutions. We’d bat around ideas, debate the options (sometimes hotly), get multiple developers with varying areas of system expertise involved, and have one or two drag out meetings until we came up with a solution that met the requirements.
My role as BA in these meetings was two-fold: facilitator and watch cop. I helped facilitate the discussion about the solutions and I was the watch cop for the stakeholder and solution requirements. I can’t tell you how many times a solution would be presented and discussed, the developers would be ready to call it a day, and I’d step in and ask, what about this requirement? It ended up that didn’t meet the requirements. Back to the drawing board!
(In fact, I feel so strongly about the value these meetings added to these projects that I designed step 7 of the business analyst process around accommodating this type of work, in a variety of different forms.)
These meetings are some of the most fun I remember having in my BA career and are an example of the task Assess Proposed Solution. While I didn’t have the BABOK to guide me way back when, I felt responsible that the final solution meet the key stakeholder requirements…because that is how we achieved the business objectives of our project and kept the sponsor happy. With a project manager, several technical developers, and potential a QA engineer in the room, I was the only one without another agenda to fulfill and so I stood up for our project sponsor.
This post is an installment in our Journey Through the BABOK with BA Stories series.
>>Define Your Business Analyst Process
Join us for the BA Essentials Master Class. You’ll learn a step-by-step business process that you can customize to meet your organization and project situations.