As part of my mission for the Compliance Group Solutions and Tech&Ops department, I worked closely with the Business Product Owner (BPO) team to help them define and evaluate the Business Value of their work.

Pictet Compliance Group Solutions is a dedicated Business Unit under the Head Compliance Group in charge of developing and managing solutions for internal compliance teams across the entire Pictet group, working with Tech&Ops services as the tech providers.

Why Define A Business Value?

During 2019, Compliance Group Solutions began a process of change in its key products' health indicators. So far, products were evaluated each quarter mainly based on deliveries compared to requests (regulatory, features, improvements, bug fix, etc.). If these criteria give a good idea of efficiency, it was hard to measure the value of was delivered. Moreover, such metrics do not account for future changes/improvements and anticipation of future value: they were measuring the past.

Not satisfied by the predefined tools and canvases proposed by Agile, the Compliance BPO team reached to me to help them co-define their Business Value (BV) and begin a broader reflection on how we define the value of what is delivered. They trusted me to plan, organize, research and synthesize the entire process.

As for popular things, “Business Value” has many definitions depending on what tool, process, and framework you refer to. Here, the BPO team members had many ways of categorizing their intent behind these words. I believe that our tools and metrics should serve our intent, thoughtfully. This requires being able to consciously formulate & articulate our intent.

Tools and metrics should serve our intents.

The first step was for us clearly to understand what the team meant by “Business Value”, and research existing formulation of it and understand its implications. All together we theorized a concept that brought shared understanding.

What's A Business Value?

Most Agile/Scrum definitions of Business Value are closely related to the Value Proposition from the Business Model Canvas or rely on the analysis of the existing. They revolve around clearly defined notions such as the “customers”, “impacts”, and “value” in standard C2C context. To simplify, we can observe:

  • The customers are the users (and most probably the buyers). They are most likely NOT the clients, as Agile/Scrum often position teams as service providers to the “business”, the clients.
  • The impacts are often equated to “customer value” or outcomes. They are the change that results from the outputs and supposedly wanted by the customers.
  • The Business Value is defined by the potential value (money) one can make out from is delivered and how much it is valued by the customers. In other words, how much they will be willing to pay/get out of it.
  • The deliverables are the outputs + the impacts. They are also called Product Value and can be measured by the outputs vs the perceived value from the customers.

That being said, we can observe two different ways of approaching this issue. First, in a retrospective way, where the value is devised by looking at the past and from measuring certain criteria. Secondly, in a prospective way, by anticipating value from the present. The two are not mutually exclusive though, and most definitions are a combination of the two.

What is interesting with the prospective approach is that the goal of defining a BV is to be able to attach the estimated impacts to the outputs the team will work on, allowing them to prioritize their work upstream. Scrum tends to materialize this into “points” to be attached to stories.

An exercise is to bring (business) experts during dedicated sessions (i.e. Story Mapping) and let them “guess” the estimated BV to each story. Several technics exists to reach this results, such as a “poker cards game”.

Well, the problem of relying on experts is precisely to rely on single points data when you have a web of interconnectedness and to assume their motivated (business) thinking will not frame priorities & goals around myths. Yes, business people (should) know their customers, but they do so through the prism of business objectives.

Would you look at one tree to understand the whole forest ecosystem?

The several biases at play may hide opportunities to create real empathy from the team, challenge business goals, and foster innovation. This is the gap.

Is customer value what business wants to see?

Different Contexts, Different Definitions.

More generally, the problem with these definitions is that it applies when you have certain prerequisites (context): a business willing to “extract” value (money) out from customers by providing solutions to their needs through the facilitation of technology. But what if you don’t meet all these criteria?

A bank’s compliance entity is a specific, complicated environment and it is not as simple as a single App product business.

Its mission is to ensure that the regulatory requirements and the bank (risk-appetence) strategy are met. For that, solutions are provided to allow Compliance Officers to retrieve, track, monitor and review potential threats. The goal is to mitigate the risk. It is mandatory for all (Swiss) banks, and are regularly audited by authorities.

  • The business, the users, and the customers are the same but layered between the actual users, their management, the auditors, and the authorities.
  • In such a context, the business value is NOT in terms of earning money from customers, but instead “how well” the necessary tools are provided to fulfill the mission.
  • Because of the complicatedness of the relationship between the business, the bank strategy, and the regulation, the impacts CANNOT be equated simply to the customer value. What users value is not necessarily what management values, and most likely different from what authorities value.

How We Redefined Value

In a series of small workshops with the BPO team and key stakeholders, we worked toward defining where “value” lies for the Compliance business. I organized and facilitated the sessions, providing guidelines and ensuring rhythm & shared understanding.

A Descriptive Understanding

The participants first came with an understanding of where “value” lies by describing the current process of delivering solutions to the users. This is the “what is” which brings the first-level understanding: acknowledgment of the current reality.

However, as participants realized, it is hard to derive a tool, a model, to estimate future value from the observation of the past/present. We needed another perspective.

A Prospective Understanding

Looking at the near future, how might we be able to devise value from what we already know? This the question participants had to tackle. Interestingly, when looking at coming requests, they found that we know some things:

  • The business/users’ needs
  • The expected outcomes/impacts

The value lies in the proposition that will help meet the needs with the expected outcomes. Of course, this proposition is unknown at this point.

This realization felt like a stop. But with little help, participants found that they could focus on deriving an estimated value from the anticipation of impact.

Interesting though, the team learned something really important:

Thinking in terms of value requires to think about what is valued by whom. This demonstrates that [things] have no intrinsic value, but rather those we give them.

Furthermore how one anticipates the value of [something] is a form of ethics (consequentialism).

Measuring Value

The final session was about taking this understanding and creating the tool, the model that would help BPOs to devise a Business Value.

Here’s what the team learned from previous sessions:

  • The Business Value is the measure of the impact of what we do on the business.
  • The Business Value should help us prioritize the business/users’ needs based on their future impact.

The team summarized this understanding in one sentence:

Business Value = Importance of impact for the business

Moreover, it's a guess, an assumption, on the impact. It's about probabilities.

Participants also concluded that the Business Value can only be deduced indirectly, based on other criteria:

  • Which level of the organization will be impacted
  • What potential impact for a specific level it holds

Here are the different business levels from which needs usually arise, and that delivered impact:

  1. Compliance Officer level: the most “frequent” end-users of the solutions. What's delivered at this level impacts them directly with generally very few consequences on higher levels.
  2. Compliance Management level: a less frequent user. What's delivered at this level is mainly to generate better overviews (metrics, KPIs, etc.) of the activities done by compliance officers (level 1), and may impact this first level.
  3. Bank level: a strategic level that drives management's need for metrics, compliance officers processes, etc. What's delivered at this level necessarily impacts all lower levels.
  4. Regulatory level: a regulatory level that drives strategic level, metrics and processes. What's delivered at this level necessarily impacts all lower levels.

The following question was how could we be able to assess these two criteria? By asking questions to the users and key representatives when they start to articulate a need.

To help them devise relevant questions, the team had to list “notions” or thematic “labels” associated with the type of requests/needs they usually get for each level. The questions should then lead requesters to give them a "chances of impact", a probability, on a scale to have granularity.

These notions add meaning to the level and probability of impact.

Questions by level:

Level 4

  • Is there a regulatory risk?
  • Is it based on regulatory evolution? (i.e. change in law)
  • Is it based on regulatory recommendations? (i.e. after an ext. audit)
  • If yes (to any above), what is the risk?

Level 3

  • Is it directly related to the bank's strategy and/or risk tolerance?
  • Is it based on internal audit recommendations?
  • If yes (to any above), what is the risk?

Level 2

  • Is it related to a decision-making process? (i.e. typically, a need of KPI)
  • If yes, which one and what is the associated risk?

Level 1

  • Does it ease the work?
  • If yes, what is the gain(s)?

Also, the team devised a “formula” to estimate the Business Value of a need (and the associated User Story): if the Business Value (BV) equals the importance of impact on business, this importance varies depending on its chances of impact (COI) and its level of importance (LOI).

Therefore, the Business Value (BV) equals the level of importance times the chances of impact.

In other words:

BV = LOI x COI

Here, “Chances Of Impact” (COI) expresses a probability whereas “Level Of Impact” (LOI) expresses a weight. In other words, we can turn the formula this way:

Business Value = [Probability] x [Weight]

Additional Dynamic Value

A question arises during the workshop on whether or not we should include the notion of "deadline" or time in the formula. The interesting thing is this adds a dynamic aspect to the BV, where a BV can be reassessed on a regular basis and will explicitly evolve in time.

Business Value = [Probability] x [Weight] x [Time] ?

The issue is that it may put unnecessary emphasis on short-term important stories against long-term important ones (where the two may be equally important without this notion of time).

Further Development

It could be good to calculate an overall value, where BV is represented against the amount of effort. This could give a solid reference point for backlog prioritization. The actual existing measured effort is technical's one through Story Points.

For instance:

Product Value = Business Value / Story Points

Additionally, an organizational effort or structural effort could be added to refine the measure of effort. To simplify, our formula model should look like this:

Product Value = [Business Value] / [Effort]

Conclusion

This exercise helped the team articulate and define a spurious notion with a lot of expectations from each participant. This also showed them the necessity of properly understanding needs without falling too quickly into solutionism.

Furthermore, and beyond the metrics, the BPO team is now able to attach meaning to Compliance requests and prioritize accordingly the deliveries that better satisfy them.

Important definitions discovered by the team:

  1. Value is not an intrinsic property of [things];
  2. Value is based on the (anticipation of) impact of [things];
  3. Value arises from needs (or goals) and how we act upon them;
  4. Both “need(s)” and “value(s)” exist within a context, which should be defined to make sense;

What went well

Despite some preparation beforehand, a huge part of the facilitation was “improvised” which turned out to be quite positive to the outcomes. The preparation served as guidelines, which helped when participants were sometimes lost.

BPO’s management and head were really impressed and showed keen interest in either the approach and the result.

What could have been done better

The result of the workshop should have been an experiment. This did not really happen due to a change in priorities, and the devised model was only partially adopted by the team.

BPO’s management also adopted it but tried to bend it to other needs, which lead to mitigated results despite my warnings.