A critical question arises as traditional banks focus on how software figures into the quest to accelerate the time to value (TtV) of their digital products. That is: How do you define and measure value to improve—and prove—the impact IT has on the business?
Answering that question isn’t easy; each organization defines value differently and subjectively, especially between IT and the business itself. To improve TtV, both “sides” must match their understanding of value.
Story points vs. business outcomes
Agile engineering teams tend to speak in “story points,” which measure the effort to complete backlog work. Story points assign an arbitrary number—similar to a t-shirt size (S/M/L) or a numerical sequence—to measure factors such as effort required, complexity and impact on other parts of the product. It’s an easy way to compare and prioritize backlog items and enables teams to track velocity of features shipped without relying on hours. But since story points are arbitrary, they don’t correlate to other empirical metrics.
What’s more, banks don’t care how many story points a team has delivered. Instead, they define value as products that impact their bottom line, win new business, improve customer satisfaction and generate revenue. Yet enterprises can’t improve IT’s business value if each side disagrees on how to deliver and measure value. The business side also doesn’t know when it will get a product or its quality in general. This makes marketing the product and estimating revenues a huge challenge.
How to identify a common understanding of value
To establish a common understanding of value, identify what a software product contributes to the business. Geoffrey Moore’s framework (from Dealing with Darwin) defines all business activities as “core” and “context.”
For example, most CEOs and CIOs at leading retail banks are mainly interested in increasing customer transactions through mobile and online channels. Products that directly impact this key performance indicator—such as seamless apps and online banking interfaces, or investment banking trading applications—are considered core.
But a payment processing system, while vital for handling transactions via the app and other channels, isn’t necessarily core. Changes and improvements to this organization-wide system will eventually get rolled into the app itself to enhance performance—and can be considered context. Therefore, working from the top and focusing on business key performance indicators can help identify your core products.
Once that’s done, ascertain how the business measures the success of these products. Let’s go back to the banking app example. One key outcome would be an increase in transactions a customer completes. From then on everything you do in the app—and measure—can and should align to those outcomes. This shared interpretation of value can bridge the gap between on-the-ground teams doing the work and leadership steering the ship.
What does business-related work look like?
Reaching this goal can be broken into four broad work categories.
Any new business value added to a product directly impacts customer business outcomes in the form of revenue, retention, customer experience, etc. New mobile app capabilities such as adding new payees, and less obvious infrastructure changes to improve performance, fall into this category.
A defect is a product issue that damages customer experience. As with features, customers see these issues upfront, which more often than not reflect product and brand quality. Examples include IT service management incidents; quality assurance defects or fails from code and security scans; and a mobile app defect that derail payment processing.
Predominantly an engineering term, technical debt has a large potential impact on software performance. Some engineers choose an easy solution over the right technical solution to accelerate time to market or minimize cost impact. Technical debt is the cost of an easy solution and all software incurs it. So track these issues carefully and add them to the backlog to ensure timely reduction. Otherwise they can pile up and severely impact software performance and business operations. Track these separately from defects and features; they provide leadership with visibility on the trade-offs made in favor of new added features and flag the importance of technical debt.
Regulatory and security changes can severely impact software performance. All work that follows compliance needs must get separate treatment to ensure safe business operations and protection of highly sensitive customer information. GDPR regulations and security compliance are some examples of risk-related work that go into a product. Flag these issues separately from other work as they will take precedence. If not addressed in a timely way, they can prove costly.
Start with four steps
Every organization has to map out its own products and product value streams—and reach a consensus on value to propel this transformation. But there are some common steps to take, and questions to ask, to start the process of normalizing value.
As a subjective and contextual concept, value can change over time as business direction and vision evolve. Core activities become context as added players in the market increase competition. This means new core activities can take their place. High-level business outcomes measured over time give way to new ones and lead to more reported products.
While value as a notion is top-down, the framework that measures value—no matter how you define it—must spring from the bottom up. Tools, teams and processes tend to remain the same and realign as new initiatives arise. So if tools and the work between various parts of the organization are connected value can always be measured. These parts could include:
IT service management
operations, and more.
Refactoring outcomes and related metrics over time is markedly easier if all your tools are connected, instead of storing work and value in fragmented systems.
Identify the initial set of obvious products that contribute to core activities/products and aim to make the transformation visible. It’s OK if you haven’t mapped out the entire organization’s product view. For the initial experimentation, choose a small, low-risk and yet impactful product. The faster you see the impact and value, the faster you can improve and roll it out across the product portfolio.
Model your product:
Dive a little deeper into the product itself. What tools do you use to get work into production? What are the interrelationships? How do artifacts (from critical product development information) morph/transform as they travel through the value stream? Common patterns will emerge and enable you to condense the value to the four broad flow items discussed earlier.
Identify the product’s business outcomes and understand the correlation of workflow to those outcomes. A flow-focused framework can make this correlation visible, so you can directly explain how the work impacts the business outcomes desired—be they cost, revenue, quality, happiness or some combination.
Any go-to-market strategy worth its salt must reflect a strong understanding of when a product is coming and its quality, so you can gauge its value and estimate its impact on the company’s bottom line. A story point doesn’t provide that core information and widens the gulf between IT and the business.
When banks understand the value work that builds a core product, they can educate themselves on how software is built and determine where to invest and optimize. This in the end accelerates value delivery of digital products and services: a fast track to success in a fast-paced digital world.