Do you think that you as the business analyst should be involved in figuring out how the solution is put together, even though you are not responsible for designing it or implementing it? Do you wonder how you can communicate the insights you’ve developed as part of the requirements process to the technical team without stepping on anyone’s toes? Would you like to find that perfect balance between influence and ownership?
If so, look no further than the “Allocate Requirements” knowledge area of the BABOK.
Allocating Requirements is a task that is done by someone, and if it’s not done by the BA, we might be missing an opportunity to create more value for our customers. So, yes, BAs no doubt have a role in aspects of the solution design.
The purpose of Allocate Requirements is:
“Allocate stakeholder and solution requirements among solution components and releases in order to maximize the possible business value given the options and alternatives generated by the design team.”
To read the first part of this sentence you’d think the BABOK has us bleeding into project management activities! Urgh! But if you finish through to the end, you’ll find this is not so. The real underlying purpose of this task, like so many in business analysis, is to maximize business value.
How I understand it, this task can happen at multiple levels. And I have examples from my career at varying levels of granularity. During use case review meetings, we would decide what requirements would be implemented in what technical solution component – there were 3 or 4 main components and each had a different technical owner. To finalize the requirements (for feasibility) we’d need to have representatives from each technical component involved in the decision-making and design process. As the BA, I was again in a bit of a watch cop role, ensuring each requirement was fulfilled through the design. Sometimes I’d also discover areas where we could enhance the solution a bit without increasing technical scope – is it just as easy to implement with an extra field because the stakeholder mentioned that would be useful, but not necessary? If yes, that extra requirement was slid in – more benefits, same cost.
On the completely opposite scale, while I was working on one variation of the plan to implement the consolidated system for 5 independent companies, I was largely responsible for allocating high-level solution requirements amongst various projects and releases of the new system. This involved an understanding of inter-dependencies within the system as well as what requirements were most likely to deliver the most value first to the business. (Even at the time I remember thinking this was more of a PM task, not realizing it was truly a BA task until preparing for my CBAP).
In the middle, where I’d expect most BAs have some experience, is in the negotiation between whether to allocate a requirement to a business process or a technical solution. As we explore the value of building a specific technology feature vs. creating a business process to deliver a specific business capability, we’re allocating requirements based on business value.
For example, as a consequence of web-enabling several features for our customers on one project, we needed to build new internal capabilities. We looked at these capabilities carefully, explored the potential solutions, and then decided what aspects of the capability to automate vs. keep manual. In many cases, the manual process was preferable for a variety of reasons, so this allowed us to keep our technology support for the internal process very simple, while still achieving the business goals of the process.
This post is one installment in our Journey Through the BABOK with BA Stories series.