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. 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.
Click here to learn more about the BA Essentials Master Class
Pingback: BA Stories: Oh where, oh where does this requirement belong? (BABOK 7.2) | The Agile Radar
Hi Laura,
Thanks for posting this article. I’m new to the site and relateively new to the BA role in general. So I find it helpful reading these practical examples to items in BABOK. Will definitely help in unearthing previous experience that counts.
Regards
Amede
And to answer your questions:
“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?”
I don’t work directly with developers but I work in a team whose primary function is to support our commercial department by proposing solutions for prospective clients (as part of the sales and bid process). From understanding requirements to contributing to solution discussions and ensuring the proposed solution meets the requirements, is feasible and cost effective for the business.
Last year I worked on a project where I had to look into options to meet a product gap for an increasing need that propsective and existing clients have. It involved looking into in-house and external options.
I started by gathering requirements from a number of interested clients and then working with others to find out the options available to us. I had to assess each option against the requirements and other business criteria.
I ranked each option against what seemed to be the most common requirements, listed the pro’s and cons and then presented back to stake holders for a decision to made.
It was small scale and really enjoyed it. I didn’t know at the time that it counted as relevant BA experience. I’m now involved in such activities on a more regular basis.
When you said ‘not even the technical solution to our detailed requirements’… it is quite challenging for us who don’t have solid IT background knowledge, i.e accountant or management.
as my experience grow, yes the statement is absolutely rellevant. If I compare with software engineering, we don’t have to dweel deep into programming languages, but we should know about the algorithm that lies beneath it.
Hi Laura,
Great point. I have been involved in multiple projects but mainly as an implementer – sometimes with independent BA(s) but most of the time without an independent.
I find that as techies, we would sometimes be lost in the “best technical” solution and not remembering to step back and think about the business.
On the other hand, sometimes the business thinks that IT is the be all and end all to their “problem”.
However, sometimes the best solution is just as simple as a workflow change or a process change. This is where I find where an independent BA who is responsible for check and balance on the solution useful because the BA should / would be able to propose such an insight.
On another point, a BA who could be the middle person with an overview of the whole program / project would be a good person to also make sure the QA team come up with a proper test case to test the solution vs the requirement rather than the QA testing the solution base on the Technical Design or worst, what was already implemented base on the implementer’s understanding of the “business requirements”.
So yes, I think an independent BA who has no vested interest in the technology who can be responsible for the check and balance of the solution would definitely be very helpful to the effectiveness of the program/project.
Pingback: BA Stories: Are You Responsible for the Solution? (BABOK 7.1)
Laura – a great topic for BAs to learn and understand. While there are many IT-associated people ready to quickly dismiss the BA in the assessment of solutions, the BABOK absolutely indicates we should be at the table. While we may not be the one to make the final decision on the technology used, the coding language and standards to follow, nor the servers on which to install the software, we are responsible for the stakeholders realizing as much business value as possible. If a proposed solution is easy but meets only 30% of the stakeholder and solution requirements, it is the BA’s responsibility to discuss this tradeoff with the sponsor(s) and/or other key stakeholders. If a different, slightly more “costly” solution delivers 85% of what the stakeholders have prioritized as critical or high, then BAs are responsible for finding out if the cost is worth the business value. The stakeholders should have final say in what they are willing to fund, approve and accept as long as the assessment team is honestly communicating the pros and cons of the various solutions. An educated decision is the best we can ask for in the ever-changing world we call “business.”
Tanya,
Great point about trade-offs. Sometimes the best solution for the business might not meet all or even most of the requirements, but if you are achieving the most possible value on a limited budget then you’d still be doing this task. Very good point and one I think many BAs tend to overlook (myself included).
Tanya – I totally agree with your response and find it very helpful. We may not come up with the solution, sometimes we may contribute to it but still not have the final say however it is important to stay close to both the needs to be met, and the proposed solution ensuring that it is assessed properly and stakeholders have enough information to make that educated business decision. This is definitely a point for me to remember given the nature of projects and tasks I get involved in.
Thanks.
Hi Laura,
Another great thinking article.
I absolutely am involved with the proposed solution ensuring that it is meeting the business requirements. I use several methods – talking through the solution with the developers and the business; requirements traceability matrix; and use cases – although I have found with my projects if we are using the use cases during UAT – then we are in trouble as the solution does not meet the buiness need.
Thanks Michelle and thanks so much for participating in the whole series. You are slowly building up everything you need to be ready for your CBAP application. 🙂
I completely agree that this aspect of BA is best done before the implementation is begun. If you can be part of the solution planning and not wait until testing then you can have a much bigger impact. Solution ideas are much easier to change than implemented solutions…and solution ideas can often be hard enough to change anyway!
Hi Laura,
Great article. I especially liked the part about developers thinking the solution is done, only to be reminded about requirements, and that the work isn’t done.
That particular theme hit home, as I see that exact situation quite often in my daily work. It was somewhat rereshing to know it’s not a unique scenario.
Cheers,
Les
Thanks Leslie! You are definitely not alone. There are many reasons why sometimes developers create solutions that miss requirements but so often an extra bit of communication and attention from the BA can help avoid that situation before it becomes a significant issue on a project! Nicely done.