Tag: proof of concept

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.