Creating a Value Delivery Machine Part 1 of 3: Solutioning for Value

Sarah Marshall
15 min readMar 15, 2024

--

Creating a Value Delivery Machine [Part 1 of 3]

Creating a Value Delivery Machine — Series

I have a confession to make. I do not love ‘process’. Nor do I love enterprise tooling. I am ambivalent about both. While either, or both in combination, provide clarity, consistency, insight, and alignment on common efforts across complex organizations and even more complex workflows, they also cause inflexibility and represent both a development and an ongoing maintenance investment. These days, when developing operations or programs to deliver operational changes, my obsession is in delivering value. In order to deliver value we need to understand the entire ecosystem and the full set of implications, good and bad, for any delivered solution.

As a young program manager I had the luxury of setting up programs simply focused on designing and building to outcome expectations. The work was challenging and complex, but had a clear end state. As I progressed through my career as I took on new roles, I was organically introduced to the broader organizational ecosystem in which a program lives. In turn, I have served as a program portfolio owner, change manager, operations owner, transformation leader, strategist and organization leader. In those roles I became intimately familiar with the entire spine for creating operational value.

In this series we tackle the framework for organizational improvement by identifying and delivering the highest possible value through planned organizational efforts. Our discussion has three parts:

  • Solutioning for value — Defining the gap between current state and our business model needs and then designing the solution that yields the highest value to the organization.
  • Framing the delivery programs — Designing and resourcing the program or programs that will deliver that solution.
  • Guiding organizations through change — Dealing with the human side of the equation to ensure that the organization is ready to receive the solution and that we hit our adoption targets.

This effort covers the last three steps in the value delivery spine — defining, designing and delivering solutions.

Creating a Value Delivery Machine Part 1 of 3: Solutioning for Value

Since I started my career organizations have chased big objectives, and delivered complex programs that have moved organizations toward their objectives. Over those many years, popular approaches to accomplishing that work have been substantially refined and consultancies have flourished in supporting all aspects of the value delivery efforts. In the meantime, I have had the opportunity to work in, manage and develop frameworks to support those activities. However, I have rarely seen materials that address the value delivery spine in its entirety.

High Value, Robust Solutioning

In this article we will discuss a general approach to developing solutions. Solution development is an exercise in casting into the vague future with incomplete intelligence and developing a tangible approach for which we will invest our precious time, people, money, and other company resources, in the belief that that effort will bring us meaningfully closer to achieving our objective. These efforts are focused on bridging the gap between where we are today and where we need to be to deliver on our vision and mission. That gap represents a problem to solve. A clear problem statement enables us to define a solution structure to solve that problem. Once we fully understand that solution, we can plan the work to deliver that solution. As I mentioned, this effort is full of vagaries and unknowns.

In my article ‘Crafting a Living Strategy’ we looked at how to develop a strategy. One of the key outcomes of strategy development is the Objectives and Key Results [OKRs]. Objectives [Os] tend to be long term, often multiple year efforts that provide wiggle room for how to get there. The Key Results [KRs] on the other hand, are the time bound, specific near term goals often structured to be delivered within the current year. They represent the real, measurable, incremental step toward realizing the Objective. In this series we will walk through the framework for turning those OKRs into tangible, landed improvements and the approach to ensuring that they are delivering the highest possible value.

As we dive into solutioning keep in mind that:

  • Achieving organizational alignment around the problem statement is no small effort.
  • Solutioning toward that KR will have multiple options for delivery. Our job is to identify the highest value solution.
  • Remember that the entire OKR and solution development effort is done with imperfect information. We need to anticipate unpleasant surprises and deal with them quickly.

Defining the Problem

One of the most challenging aspects of the solutioning effort is to achieve leadership alignment for the problem statement. Each of your leaders come to the table with their specific, singular, often functionally oriented, point of view [POV] and experience set. They view the problem statement from their unique perspective and are not afraid to voice it. Defining the problem statement requires facilitating these disparate points of view into aligned agreement. While dealing with the differences can be frustrating when trying to close out alignment, those differences are extremely powerful in contributing to the problem statement definition. It’s incumbent on us to anticipate each leader’s concerns and complete the necessary trench work to speak to those concerns.

Defining the Problem We Need to Solve

There are many methodologies for defining a problem statement. Some of the most popular include Fishbone Diagram, Six Sigma DMAIC, PDCA Cycle, and 5 Whys. Regardless of whether we use any of these or something else, the methodology is designed to break up your problem into its constituent parts so as to better understand each aspect. In the fishbone diagram below I provide a way to break down a problem statement to address typical C-suite perspectives.

Problem Breakdown via a Fishbone Diagram

We need to complete our due diligence in breaking down the problem statement and gathering data from functional experts to fortify your assessment. Getting alignment for our problem statement is likely to be iterative and take a combination of 1:1 discussions, problem statement updates, debates, and ultimately leadership team sign off.

Establishing Priorities and Conditions for Satisfaction

Wait, but that’s not all. Since your organization will have multiple Objectives, with even more KRs requiring even more programs, resolving one or even multiple problem statements does not provide a sufficient assessment framework within which to assess the required efforts.

OKR — Program Hierarchy

The example above results in three programs, one of which, program 1.1.2, supports both KR1.1 and KR1.2. We need to assess the value of each program towards the priorities created by the Objectives. To that end, we need to understand our priorities and the conditions of satisfaction for the priorities. With those conditions of satisfaction we can assess the value for the solutions we create to address the gaps/problems we are bridging. Similar to the problem statement breakdown we need to look at impacts to various aspects of our operations. Those might look like:

  • Revenue contribution
  • Margin contribution
  • Customer engagement / channels
  • Customer satisfaction [CSAT]
  • Product / Service development velocity
  • Operational efficiency [cost per $ of revenue]
  • Employee satisfaction [survey rating]
  • Regulatory compliance [legal costs & fine reductions]

Program contributions to each of these conditions of satisfaction give an actual value. However, you may need to prioritize between these conditions. To accomplish this prioritization we can weight the conditions.

Program Valuation Table

The above table calls for some definitions.

Projected Impact — The actual projected KPI value of the solution based on that projected contribution based on that particular contribution’s performance metrics.

Standard Value — Based on a total value of 0 to 10, the relative standardized value translates the KPIs into something that can be calculated into extended values for portfolio valuation. We use the standardized value to calculate the extended value. For example, if the total targeted revenue increase is $140M. The $50M projected contribution is 40% of that target or 4 of 10.

Weighting — Weighting, in this case, spreads 10 points across all success factors, establishing the relative priority of that particular contribution. For this example, weighting indicates that contribution margin is the highest priority with revenue contribution, customer engagement, and customer satisfaction being high priorities as well. Programs contributing to these priorities are going to be weighted higher than other types of programs.

Extended Value — The extended value is the calculated value of the standard value and the weighting to provide the relative value against priorities for that effort.

Where do we invest? We want to invest in all improvement programs if we can afford to do so. However, if we have limited resources, as we always do, we invest in the highest value programs. Program 1.1.2 has a value of 50.65. Let’s say we value the other programs with extended values of Program 1.1.1 at 42.3 and Program 1.2.1 at 47.2. Even if all three programs are initially resourced, should one or more programs become distressed and require resource adjustments, the valuation above tells us that we want to keep Program 1.1.2 fully resourced even at the cost of other programs.

Establishing Your Portfolio

In setting up the program valuation we are most of the way to establishing our portfolio. Finally we need to establish the investment categories in which the programs reside. Typically, enterprises establish three investment types — keeping the lights on, incremental improvements, new investments.

Keeping the lights on — This investment simply maintains our capabilities and the availability and performance levels that they currently are in. Regulatory compliance investments, replacing unsupported technology, and replacing positions that have experienced attrition are all investments that maintain the status quo. These investments are a must otherwise our capabilities will be degraded. If we can, and it supports organizational direction, rather than replace capability ‘in kind’, we would prefer to replace current capabilities with better capabilities. Then we cover both keeping the lights on and provide incremental value. Regardless, keeping the lights on programs are ‘must do’ efforts. They are by nature a high priority.

Incremental improvements — Incremental improvements typically either improve current capabilities with say better reporting, improved product / service delivery, or reduced cost for the same performance. Incremental improvements are important, and often necessary, but will not radically improve the organization’s performance position.

New investments — New investments are the riskiest because they are the least familiar. However, they are investments that yield the largest performance leap. Some examples of new investments may include setting up a new sales channel, adding new products / services, automating a manual process, and so on.

Once we have set up the valued programs within the investment categories we now have a way to fully evaluate how we make and shift our resources as design / build efforts yield unforeseen issues and risks.

Now that we have clarity on our portfolio and the value anticipated from our investments, we can develop solutions to meet these commitments.

What is a Solution?

Many folks in the enterprise platform delivery game get confused that the delivered platform is the solution. A platform is NOT a solution. It is a part of a broader solution.

Finding the Highest Value Solution for Our Problem

When driving change programs to fill the identified gaps we deal with three areas of change:

  • Organization & People
  • Enterprise practices and processes, and in most cases,
  • Supporting technology systems architecture.
Solution Impact Areas to be Assessed

All enterprise solutions will affect changes to all three areas. Impacts, both positive and negative, roughly correlate to the breadth of the solution scope. Breadth can range from incremental tweaks to radical shifts depending on the business model requirements and solution ambitions. These shifts are outlined if the problem statement is well crafted and then detailed as the solution is developed. None should be ignored.

Organization & People

The organization and people impacts may cut across the company’s culture, [via vision, mission, values, and policy], the company’s governance, organization structure, and the types of expertise required to support this change. I covered culture extensively in my culture series. If you have not read that series please take a read here. Any changes driven by this aspect of the solution needs to be tightly aligned with your organization’s human resources experts.

Enterprise Practices & Processes

Typically, solutioning focuses most heavily on changes to enterprise practices and processes. These practices and processes are the operational work horses of the company. This is how we get work done day-to-day. In companies of any size these practices and processes number in the hundred if not thousands. However, at the enterprise level processes, the mega processes so to speak, include:

  • Leadership practices and process
  • Core value practices and processes
  • Enabling practices and processes

Leadership Practices & Processes

Enterprise leadership practices and processes focus on setting direction and monitoring performance to the commitments to arm themselves for difficult decisions and the associated trade offs. Those efforts include:

  • Strategic insights & strategy development
  • Track operational performance

Core Value Practices & Processes

The core value practices and processes are the heavy lifters for the company’s day-to-day operations. We depend on these efforts to keep ourselves literally in business. This and the next set of practices and processes are likely where the bulk of the changes will occur in either improvements or adding wholesale new capability including:

  • Sales & GTM partnerships
  • Market insights & campaigns
  • Product / Service sales and GTM partnerships
  • Operational performance technologies
  • Product / service development lifecycle
  • Product manufacturing
  • Supply chain & logistics
  • Customer support

Enabling Practices & Processes

Enabling practices and processes provide support for the workhorse processes in tracking resourcing, cash flow, financial operations, and other necessary services within which we get our work done. They include:

  • Financial management
  • Facilities & equipment management
  • Workforce management
  • Internal services

Systems Architecture

The above two arenas can stand alone, without automation technology, and in small companies largely do stand alone. Systems architecture and platform deployment come into play when the level of transactions, reporting, and knowledge management becomes so large and complex that automation is necessary to hold down the costs, sluggishness, and confusion caused by managing large volumes of data through complex transactions.

The bottom line is that the cost and risk of manual practices and processes outweighs the cost to develop, deploy and maintain these large platforms, modules, and applications. That said, systems architecture is costly, time consuming, complex, and difficult to change once it is deployed. Additionally, processes within platforms are institutionalized, and therefore are somewhat to completely inflexible. You need to be sure that the processes you build into these platforms are common and designed exactly as they need to run. Deploying platforms should be done with open eyes to the downside and as an absolute necessity. There are four types of supporting platform categories.

Customer relationships management (CRM)

Customer relationships management (CRM) platforms manage the front end of your business that is engaged with customers and go-to-market [GTM] partners supporting processes for sales, marketing and customer engagement.

Supply chain management (SCM)

Supply chain management (SCM) manages the flow of materials from procurement raw or component part purchases through customer delivery. These platforms manage procurement, inventory management, product lifecycle management, demand and supply forecasting, replenishment, warehouse management, transportation and logistics management, and risk management.

Enterprise resource planning (ERP)

Enterprise resource planning (ERP) does the heavy lifting for human resource management, manufacturing, finance & accounting, regulatory compliance, and operational efficiencies.

Knowledge Management & Sharing

Finally, Knowledge Management & Sharing may be tied into the other platforms or separately provided for website management, collaboration tools, business intelligence, and back end data hub tools for amassing and manipulating large information flows and historical trending.

Framing Your Assumptions, Risks and Dependencies

Now that we have covered all of the changes we need to assess in developing our solution we need to establish our understanding of potential issues and risks to ensure we are armed to plan and track the development and delivery execution for the solution by capturing assumptions, risks and dependencies.

Managing Solution Impacts — Assumptions, Risks & Dependencies

Assumptions

While developing your solution and planning its development we need to capture the assumptions we are making about both the solution and its delivery. Understanding our assumptions gives us early warning for problems in that, should we, or I should say when we find assumptions failing you know a problem is emerging. So we will want to not only identify assumptions, we will want to review them regularly to determine if we either have proved them as fact or that our learnings in the planning and execution phases break one or more of our assumptions.

Risks

Every solution has associated risks. These risks range from evolving circumstances to losing critical expertise at an inopportune time. In fact, we can probably, if we put our mind to it, identify hundreds to thousands of risks for a large, complex solution deployment. We want to capture the handful of big, ugly risks for which the likelihood of the risk is high and the negative impact of the risk is substantial. For these risks we want to build into the solutioning plan, as much as possible, mitigations. The earlier we catch the risks and mitigate the lower the cost to us in time and effort. These risks need to be reviewed often, perhaps weekly, to avoid disruptions.

Dependencies

Just as every solution has risks, every solution has dependencies that range from inputs from other programs or functions, to vendor developed aspects, to having the right people engaged at the right time. Like risks, dependencies require regular review plus a solid relationship with the functions, program leads, and vendors on the other end of those dependencies.

As we move forward in designing and deploying our solution we need to track our assumptions, risks and dependencies to identify issues as early as possible. They become a big part of program planning and monitoring.

Initiating Discovery

With this work done we have placed ourselves deeply in the heart of the discovery phase. We will cover the phases of solutioning in the next article. The discovery phase is the planning pre-work phase in which we rough out and align on the solution before we go into deep planning. The rest of the discovery phase is engaged in due diligence to ensure we have a solid enough proposed solution that we do not waste our planning effort on something that will not work. This is the phase in which we engage internal and external efforts, pull data sets to fortify our assumptions, and align leadership, experts and selected heavy users to wring out the initial rough design.

Takeaways

Solutioning kicks off a long and hard effort to bring your organization through the change we need to make to fill the gap between where we want to be and where we are. By the time we finish this effort we will have a clear picture of the solution we minted and clear alignment across the organization for the effort in front of us. We have accomplished:

  • Tying the effort to our strategic north stars,
  • Assessing its value to the organization,
  • Aligning the key stakeholders, and
  • Defining the solution.

We have also assessed the key considerations that we need to track and are deep into the due diligence necessary to validate our work.

We are Tied to Our North Stars

We have tied the solution to the organization’s OKR and gotten leadership sign off on the outcomes we are seeking to achieve.

The Value is Projected

We have forecasted the value to be delivered by the effort and built the portfolio of the efforts we are undertaking to deliver on our commitments and are tracking portfolio performance to rapidly identify distressed efforts for which we will need to make trade off decisions.

The Solution is Defined

We have defined the whole solutions and the associated changes to organization and people, practices and processes, and system architecture as needed.

We are Deep in the Discovery Phase

The due diligence effort is well underway with a path to complete it and move into planning.

Next Steps

We are ready to jump into the rest of the solution delivery phases addressed in the next two articles.

Find more articles from Sarah at: www.operations-architect.com.

--

--

Sarah Marshall

Sarah is a writer, mother, partner, tech industry professional, and transgender activist.