Calling All Product, Requirements, and Design Tool Vendors – Can You Report on the Business Value Your Products Create?
Every IT shop could improve its technology performance and operating metrics. This is just good, plain sense when you run a business unit. It also reinforces the devastating perception of IT as a cost center. There is no such thing as a business process that isn’t enabled by technology. That makes technology a key part of the value creation engine of an organization. As long as IT focuses on cost and performance-centric metrics, they are missing the boat. It’s Goldratt’s Law all over again, “If you produce something, but don’t sell it, it’s not throughput.” Our research shows CXOs get this; CXOs think business value reporting is the most important area for IT to improve its reporting.
It is hard though. Even more value-centric metrics like velocity are aspirational. The question they answer is, “Do you think this software is valuable?” That is all apps and oranges to the more important question of, “Did this software create the expected benefits?” The gap we face is that the delivery tools we have today can answer the first question. The tragedy is that they can’t answer the second…. We develop or implement software disconnected from the requirements that it was supposed to satisfy. Whether you call those business requirements or epics, good practice requires them to have a defined benefit and an expected impact on business KPIs. This means the products or applications we manage should be able to report on value created. Without the requirements to provide context all the software can do is create another arcane log file for us to try to parse.
The solution lies in integrating value reporting by the software we deliver back to specific requirements. The technology exists to make this happen. Software can quantitatively measure revenue from a transaction, the time (and hence cost) of executing a process interactively or in batch, adoption rates of internal services, and customer experience. All it needs is somewhere to report it in context.
Our Take
There is a huge opportunity for the first product, requirements, and design management tools vendors to implement business value reporting features. It will differentiate them from their competitors and cement the value proposition of their tool. I put this challenge to Tony Higgins, the CPO of Blueprint Software Systems (Storyteller), Tom O’Reilly, the COO of Sparx Systems (Enterprise Architect), and Ashu Potnis, VP of TechnoSolutions (Top Team Analyst) this past week at BA World Toronto. Here is my challenge in two user stories:
As a product owner I need to be able to report on the value my product created in order to ensure I am investing in solutions that create the benefits the business needs.
As a software developer I need to be able to send business value data to our requirements repository in order to report on the benefits my software created.
Reporting is a table stakes feature in this category, and the software could be as simple as creating a code snippet for each requirement in the common programming languages. A POST call to the tool’s existing REST APIs with the targeted requirement and the measurement as parameters would do the trick.
What are you waiting for?
Want to Know More?
Info-Tech’s Build a Better Backlog has the information and exercises to help you determine the practices you need to define the business value proposition for your requirements.
Explore How to Measure Throughput and Win the Business’ Trust and Seven Reasons You Need a Data-Driven Approach to Application Lifecycle Management to understand why value metrics matter as a part of your software delivery life cycle!