Again, like we did in Assess the Proposed Solution, we are finding ourselves in the midst of the solution world in a very defined way. 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, like it or not.
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 those use case review meetings I've talked so much about, 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 manual process or a technical solution. As we explore the value of building a specific technology feature vs. creating a manual process to deliver a specific business capability, we're allocating requirements based on business value. 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.
How about you? What stories do you have about allocating requirements and how did your contributions maximize the business value achieved by the project?
This post is one installment in our Journey Through the BABOK with BA Stories series.
Related posts:
- BA Stories: Are You Responsible for the Solution? (BABOK 7.1) Are you responsible for the solution? If you read the BABOK...
- BA Stories: Evaluate Solution Performance (BABOK 7.6) As I went through my journey towards the CBAP, I...
- BA Stories: It's Not "All Requirements" – Assumptions and Constraints Matter Too! (BABOK 6.4) As BAs we very easily get wrapped up in our...
