Gone are the days of companies deciding what their IT strategy will be for the next 10 years, and going to huge systems integrators, with multi billion dollar contracts to roll out static IT systems. Technology is advancing at an unprecedented pace, and in order to remain relevant, companies are having to look at new approaches to innovation. The most important factor by far, is the ability to innovate quickly.
It should be no surprise to the industry that smaller companies are able to innovate faster. A smaller company, with less people, a more agile structure, and less legacy structure, is always going to be able to innovate faster than a large company with thousands of employees, decades of legacy systems, and a very rigid structure. In order to remain relevant, large companies are increasingly working with startups, many of which have existed for less than a fiscal cycle, and with a fraction of a percent of the workforce of the larger company.
The disparity between startups and large companies creates friction from a number of areas. Startups are notoriously bad for understanding their own capacity, or the implications of business and technical requirements from their large clients. Startups who land a big client are blinded by the opportunity and will typically take on as much scope as possible to inflate the size of the project. Furthermore this leads to the dangerous impression that their startup is being successful – they can correctly claim that their clients keep increasing the size of the project, and therefore the potential rewards are higher, but they will quickly find themselves drowning in that success.
After founder disagreements, over commitment to projects is the biggest reason that startups fail. Because of over-commitment, startups will often find themselves having to dedicate a large proportion of their team to the project, and if not careful, can find itself in a position where the success or failure of the company is intrinsically linked to the success of the project. What is an industry defining project for a startup, is likely a small side project for the larger client.
The sheer number of pilots we are seeing at the moment (in particular in the blockchain space) would suggest that there is a lot of success happening. However, the sad truth is that the vast majority of projects will never make it past the pilot stage, and were doomed to fail before they even started.
A pilot is a small scale preliminary study conducted in order to evaluate feasibility, time, cost, and various other criteria of a project before committing to a full scale project or change in strategy. What most companies (both large and small) fail to understand is that by far the most challenging part of a project is – to borrow a phrase from Geoffrey Moore – crossing the chasm from pilot to production. For a project to have even a remote chance of success, a significant amount of the work in the pilot has to be dedicated to how it will cross the chasm.
The Thin Wedge Approach is an innovation methodology developed at BTL to enable us to work with clients who are many thousands of times larger than us, ensuring we are able to deliver projects that can cross the chasm from pilot to production, while not letting individual projects balloon out of control. The key principle of the Thin Wedge Approach is as follows:
The goal of the Thin Wedge Approach is to deliver the smallest possible product fully into production, while demonstrating how value can quickly be increased in neighbouring areas of the business.
The Thin Wedge Approach achieves 2 key goals. It ensures that project scope is always manageable by the startup (allowing it to cross the chasm to production), and it reduces the risk to the startup if the project does not succeed. The latter is because, by keeping the scope limited until the product is fully launched in production, the startup does not have to invest significant resources until they know the product has succeeded, rather than tying up the majority of their workforce trying to deal with pilot scope – and drowning in their success.
By applying this approach, startups are able to reduce much of the friction that is created when very large companies work with small startups, while at the same time allowing both parties to achieve their individual goals, at a much lower risk and cost.
Companies do not set out with a goal to expand the scope of projects beyond what is manageable, but without specific controls in place, this often becomes the case. Most importantly, the Thin Wedge Approach needs to be applied from day one, and all participants in the project need buy into it. Critically, all parties at the table need to understand the key principles of the approach:
• A significant amount of the pilot project needs to be dedicated to crossing the chasm to production
• Smaller scope is prioritized over larger cost savings (or revenue generation)
• The pilot needs to demonstrate how, once launched, the scope can be expanded to handle additional requirements or other areas of the business
Some of these principles, in particular when it comes to prioritizing scope reduction over cost savings need to be approached carefully with the client. Importantly, a smaller scope means the project will be deployed in production faster, and therefore the cost savings, while smaller will be realized much sooner. Additionally, every incremental improvement on the project will have an immediate impact on the bottom line, rather than delaying the start of the entire project.
The reason pilot projects exist is to provide an environment where we can fail fast, and the Thin Wedge Approach should not be confused with an attempt to salvage pilots which don’t meet the technical or business goals that have been set out for them.
Many of the pilots we read about today, however, are fundamentally flawed in their approach and, even if they do achieve the technical or business goals, will never succeed in crossing the chasm from pilot to production, and are at risk of dragging the associated startup down with them.
The Thin Wedge Approach lays out a framework for running a pilot, with a clear goal of turning a successful pilot into a production product.