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.
Nope.
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 (we'll get to that task eventually, I promise!). 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 feasi ble.
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!
Say what you will about whether or not this was the best way to address this challenge. These meetings are some of the most fun I remember having in my BA career and, I must attest, are an example of the task Assess Proposed Solution. While I didn't have the BABOK to guide me, I felt responsible that the final solution met 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.
And, quite honestly, while the structure of the assessment and the participants have changed throughout various projects and organizations, I've never let go of this bit of ownership. I've sometimes even over-stepped my bounds when it came to the assessing the solution, but that's another story. The mistakes were well-intention, if ill-advised.
How about you? Do you see yourself as responsible for ensuring the solution fulfills the requirements? How have you either assessed proposed solutions or been involved in this part of the process?
This post is an installment in our Journey Through the BABOK with BA Stories series.
Related posts:
- BA Stories: Evaluate Solution Performance (BABOK 7.6) As I went through my journey towards the CBAP, I...
- BA Stories: Getting Elicitation Right – With Preparation (BABOK 3.1) It’s difficult to even think about being a business analyst...
- BA Stories: Warning – Stakeholder Analysis is Not Just About Discovering Requirements (BABOK 2.2) One of the most essential aspects of planning your business...
