Requirements Management: A Value Mapping Exercise

The requirement management exercise is very closely related to the needs assessment producing the required artifacts while documenting the decision-making. It is critical to understand how the value, benefit, and output get mapped in a few critical documents namely the business case, charter, roadmap, and benefits register.

In a nutshell, the business case is the first point of entry in the requirement management. In this document, the accountable stakeholders for product strategy or the business strategy justify the company’s decision to take up the strategic initiative and formally declares the benefits expected out of the initiative. This decision is supported by documenting the specific short-term and long-term benefits by executing the initiative, the extent of market research to justify the need for this initiative, the amount of funding and funding schedule required to carry out the initiative, and finally the specific measures such as the payback period, net present value, to justify return on investment and future opportunities.

When such initiatives are rolled out, these initiatives could be done as a program containing multiple projects because of the extent of management and control required to integrate the benefits gathered from carrying out this initiative as an integrated program rather than as a set of stand-alone projects. Either way, this is when the program charter or project charter is created appropriately. This document names the program or project manager confirms the decision to execute the project outlining the high-level outputs and outcomes, and the authorizes the use of the company’s resources to carry out the work.

Now whether one is developing a product roadmap or program roadmap, you can think of the roadmap as a visual, hierarchical and powerful representation of the what high-level functionalities make up that initiative, dependencies among functionalities or projects within a program, and how the product will grow over time, how to acquire the required funding to support the product or program, and how to align the various stakeholders to ensure the required benefits are realized.

Finally, the benefits register is an artifact that lists all the planned benefits expected to be delivered at various points in the releases or iterations or program and its component projects. 

Having talked about value so much, I have come up with my own way of categorizing value. I call these CVA, BVA, TVA, PVA, and NVA.

The first category is the customer value add. For instance, what does the paying customer want? And what exciting things can we add to keep the customer with us?

Then, we move to the next level of business value add. Examples could be looking at the types of documentation required to sustain the business or training needed for internal and external users.

This business value-add can also manifest as a technical value add. Here, we look at technical debt maintenance. On the hardware side, we can look at keeping the infrastructure current to avoid any risk from using any product beyond their shelf-life. On the software side, we can look at ensuring the code is stable, manageable, and scalable by refactoring the code, automating areas that could benefit from automation, etc.

Another way the business value add can manifest is on the process value add. The processes themselves should act as a catalyst for transforming the inputs to outputs but not add too much overhead. The efficiency improvements through continuous improvement and effectiveness augmentation through operational excellence become the focus here. 

If it is not the customer, business, technical, or process value add, then, most likely this leads to a non-value add. The requirements in this category are to be avoided as they are contributing to some type of waste. In lean management, we discuss the uneven demands or overburden of resources that may lead to eight types of waste (Rajagopalan, 2016).

What are your thoughts on this blog article?

References

Rajagopalan, S. (2016). Management Debt: Costs of Non-Delivery. http://agilesriram.blogspot.com/2016/10/management-debt-costs-of-non-delivery.html