Tag: pricing

What Venture Capitalists Can Teach Us about Driving Transformation | Sherpas in Blue Shirts

The current way we buy complex services through a purchasing department is to come up with elaborate detailed requirements, which often can only be implemented over several years. We put these out to bid, forcing the vendor community to respond with far more detail and waterfall project plans laying out in excruciating detail how they will architect and migrate this environment to the new desired state. We then conduct the services version of the limbo dance – how low can we go – where providers compete the price of the solutions. But there is a huge fallacy in this procurement methodology.

We have a long history of unhappy results from this methodology, a body of work spanning 10 to 15 years demonstrating that these procurement efforts mostly result in unmet expectations, cost overruns, and evolving service levels. This is insane. Insanity is doing the same thing again and again and expecting a different result.

The fallacy of the procurement methodology

By using this methodology, we effectively try to articulate a transformational journey in an overly precise way even though we have only a limited understanding of both the existing and future environments. The result is exercises in creative writing with overly precise work plans and cost estimates. The only thing we can be sure of is that the plans are wrong because of the lack of information (no matter how much time we spend on the plans), and the fact that the world changes during this timeframe. So we’re guaranteed to be wrong.

Therefore, our preferred way to purchase services is flawed. It pretends that we know with precision things we don’t know and it does not adequately accommodate for the nature of change in technology, business process and business conditions.

What can venture capitalists teach us?

For years VCs have faced a similar problem. How do they develop breakthrough, compelling new technology products, fund them, manage them cost-effectively and, most importantly, how do they get to great offerings?

They achieve these objectives by accepting that, although the vision for the journey can be had, the length of the journey is unknown, the amount of money required to accomplish is unknown, and the exact nature of the end product is also unknown.

This is very similar to the problem we find in most service transformations. We know the direction we want to head, but we can’t describe accurately and precisely where we’ll end up, can’t quantify how much it will cost, don’t know how many resources it will take to get there or how long it will take to get there. All of these factors vary. Yet, using the procurement methodology, we pretend we know these details and set up artificial constructs.

Applying the VC principles to transformation services

Why don’t we do what the venture capitalists do? First of all, they break the project down into a series of gates. The only detailed road map is the one between where you currently are and the next gate. That requires a detailed plan. One of the parts of the plan is to develop a plan for the next gate.

Using VC principles, the vision and the dimensions of what you want to accomplish are clearly stated. For example, “I want to bring the cost of IT down by 40 percent” or “I’m going to standardize my components and move them into an elastic or consumption-based model, and I’m going to develop agile vehicles to integrate the components.” But how you will do that and how it will involve your current environment is unknowable.

All that is knowable is how you develop a proof of concept and how you move from POC to rapid implementation. You can fund each step much like VCs do (Series A, Series B, and Series C funding) and break it down to create funding associated with milestones that get you to the next gate.

This is a broad application of the VC philosophy, and there’s much more to it. But I believe by applying these principles, we can change how we drive transformation. We can dramatically lower the interaction costs of the purchasing process, and we can spend that money and time instead on the actual transformation. And we can deal with our providers or ecosystem partners in a much more transparent and direct way.

It’s best to apply this VC-based methodology where the benefits of design and architecture drive the value, instead of price reduction as the driver. You can still get lower unit prices, but the old procurement process is dead. That process is useful if you’re trying to take a stable environment and reduce its unit price. But it is not useful where you are driving a transformational agenda, which cannot be precisely defined. Using the old methodology for a transformational agenda tends to waste time, frustrate ecosystem partners and create false promises.

Transformation Services Procurement: What’s Wrong with this Picture? | Sherpas in Blue Shirts

For large transformation projects, the services world has locked itself into a world permeated with high dead deal costs, wasted solutioning, and long transitions of nine to 18 months where the client sees low value and tries to get the provider to absorb the cost as well as expensive consultants and legal fees for the client on top of distracting management. And in the end, we have a lot of unhappy clients. This needs to change.

Remember John Lennon’s song: “Imagine?” Imagine a world in which we compress these cycles and we don’t have high transition costs. As Lennon wrote, you may say that I’m a dreamer, but I’m not the only one. Over the years there have been a lot of experiments in how to shorten the sales cycle. But largely they were frustrating. Even when you rush through the process, it still tends to straighten back out to the nine-plus months’ duration because it takes time for the enterprise to understand and absorb the journey and get to decisions. Others have experimented with sole sourcing, but it doesn’t really shorten the sales cycle and has a lot of limitations from the client side in terms of leaving them wondering whether they got a market deal, despite benchmarks and pricing assurance.

From studying this over the years, I’ve come to believe that as long as providers and clients define the goal in terms of procurement, they’re likely to be disappointed. The process and price become too influential and the provider loses sight of the client’s real goal. So they end up with incremental gains but not breakthrough, transformation gains.

Let’s think about these deals as transformation journeys instead of procurements. Just imagine ….

After all, the client doesn’t want the outcome to be a contract; the outcome needs to be a transformed state of the client’s process or capability. So we need to reconceive the origination of these transformation deals along this line.

We need to first focus on the benefits, defining the game-changing benefits the enterprise wants to build. Typically those benefits in today’s world have something to do with efficiency gains, cost savings, better aligning the process to the requirements of the business users, and improving the speed and agility to be responsive to the business needs.

If service providers stop thinking about the procurement process and think from the consumer’s point of view, it works great. The client gets what it wants and needs, friction is reduced, it’s clear what the client needs to reach its goal, and the provider gets to pull the client on the journey rather than pushing and selling to the client.

After defining the business outcome goal from the client’s perspective, the next step in developing a solution would be to develop breakthrough metrics to drive the change through the client’s organization. I’ll discuss this in my next blog post.

The parties build the journey together, and the client sees the solutioning as value rather than a sales exercise to be viewed with skepticism. In effect, this method turns the procurement process on its head and eliminates the sales cycle. The provider get paid to assist the client in solutioning rather than for building a complete construct to be compared to competitors’ solutions and examined at every level.

The result is a better outcome, focused not on contractual terms but on results for the client. And this process goes a long way to eliminate the nettlesome issues around the procurement transition phase because transition is accomplished as the transformation journey progresses. Just imagine.

In John Lennon’s words, I hope someday you’ll join us, and the world will be as one.

Automated Services Need a New Licensing Structure | Sherpas in Blue Shirts

Service Delivery Automation (SDA) encompasses cognitive computing as well as RPA (robotic process automation). Software providers that provide SDA come to market with an enterprise licensing structure that basically requires the customer to license a number of agents for a specific length of time. But in using this licensing model, service providers unintentionally constrain adoption and open the door for competitors’ differentiation.

The problem is that many of the uses for SDA are cases where companies need variable amounts of agents and computers. For example, the client may have a million transactions to process. So it could buy a license for one agent to run through those transactions in a week; but to reduce cycle time requires buying the license for 10,000 virtual agents for one hour. At Everest Group, we clearly see clients becoming frustrated with this lack of licensing flexibility.

This situation calls for a consumption-based approach to SDA in which the customer pays the software provider handsomely, but the provider doesn’t constrain or force unnatural motions on its customers and doesn’t create unnecessary cycle-time issues.

This blog is a call to service providers to come up with a consumption-based pricing model for SDA services. I’m not advocating that providers give away their software or take less money for it. I am saying that the current pricing structure inhibits adoption and is a constraint on the growth of the industry. Employing a consumption-based pricing model doesn’t mean that the client won’t pay a fair compensation or that the provider won’t be profitable. To achieve this, providers need to create some kind of metering vehicle in which time or activities are metered and they need to link their pricing to this meter.


Photo credit: Flickr

Three Ways Services Customers Can Switch to as-a-Service Model | Sherpas in Blue Shirts

As the services industry begins moving into the as-a-service era customers look for providers that change their traditional services to make them elastic or consumption based. We at Everest Group have spent some time studying this, and we believe there are three key ways to change take-or-pay (fixed costs oriented) services and make them elastic (pay as used). One or even a combination of all three ways are present in the services model that customers now demand.

1. Multitenant sharing

Customers benefit from a provider sharing its capacity among multiple clients. AWS and Salesforce are classic examples of this elastic type of service. They redeploy servers or capacity when not in use to other customers and therefore achieve an extremely high utilization rate. In fact, arguably, AWS has over 100 percent utilization rate because it can charge customers for capacity when they’re not using it, yet can use that capacity for other clients. The model is much like an airline selling more seats than its actual capacity.

2. Automation

Repeatable process automation (RPA) or robotics spins up a virtual robot to do the work and then shut it down again. This fundamentally aligns a customer’s costs with usage and thus makes the service elastic.

3. Change purchasing method

The third way customers can have elastic services is to change their purchasing so that they only buy services as they use them. An example of this would be changing the way a customer acquires software, switching from enterprise licenses to consumption-based licenses where the customer pays for the software only as they use it. A note of caution here for customers: Although this makes the service elastic to you, there may be a stranded cost to your provider, and that cost may be embedded at a higher cost to you in your cost structure. So be careful about overly using the purchasing mechanism to make a component of your IT service stack be elastic.

Although customers can use these three methods separately, it is also beneficial to look for service providers that use a combination of all three methods to make a material difference to an entire service line to make the service far more flexible and consumption based to meet your needs.

We have not uncovered other mechanisms to make a provider’s service line elastic, but we are very interested to know if you have discovered another way to achieve elastic services. Please post your comment and share your experience.


Photo credit: Flickr

Request a briefing with our experts to discuss the 2022 key issues presented in our 12 days of insights.

Request a briefing with our experts to discuss our 2022 key issues

How can we engage?

Please let us know how we can help you on your journey.

Contact Us

  • Please review our Privacy Notice and check the box below to consent to the use of Personal Data that you provide.