Pilot-first Transformations (aka "Flintstones")

I specialize in the for-purpose sector, and I've yet to hear a positive story of a big consultancy coming in and running a multi-year transformation program. Even with heavy discounts and pro bono work from well-intentioned folks like KPMG, I hear stories of big budgets, long projects, 6-month stalls, failed attempts, and disillusioned staff—not a single example of "hells yeah, they've transformed my life."

To be honest, this isn't unique to the charity sector; I saw the same thing in big corporates for a decade with EY.

I'd like to share the main tool in my kitbag from my digital project rescue days, my secret sauce for turning failed digital programs into "hells yeah" successes in short order. That trick is really simple: don't do a transformation program at all. Do a bunch of quick-wins, one business process at a time. Thanks to advances in hosting technologies and the widespread adoption of free “open source” software libraries, this has been possible since around 2010 without the limitations we suffered before that (in architecture, primarily).

Actually I was first introduced to the idea by a customer back in 2001.

Let's call it pilot/scale, pilot/scale. Or as one of my clients used to call it, "a bunch of Flintstones projects". For those who didn’t watch The Flintstones, it’s the metaphor of a stone-age, foot-driven car

First, we don't spend 6 months cataloguing all our "as-is" and "to-be" business processes because we're delivering nothing of value—just documents. Instead, we hold a one-day workshop to brainstorm a list of the most costly and risky process issues, then narrow down to the worst one. It'll likely be a labour-intensive manual process propped up by spreadsheets with a bunch of fragile macros.

And we don't get sucked into analysing the whole list; we get stuck into the first cab off the rank, and carry on prioritising the rest in parallel (not analysing or designing them though).

Then we set a 1-month timebox to build a pilot solution for the worst problem, using free technologies on almost-free cloud services. Hit me up for a list of those.

The process will start with a bullet-point list of five high-level things that this system can do, just to give the developers a running start. We won't be speccing, scoping, defining, or doing UX for this project before you start. The developers will work directly with the people who will eventually use the system, in this example, workers. The other stuff will happen as a step 2 (because the risk of deploying on a tiny scale is, by definition, tiny).

Within the first week, the developers will be able to get something up and running that will tick off each of those five bullet points in a basic way. They'll be demoing that stuff, and depending on how fast they can work, we may have a working solution that one worker can use for a day before putting it back down and returning to the original process.

The rest of that month will be rinse and repeat. There are some tips and tricks to avoid, and I can provide a list of those if you hit me up via email. I'll also be writing an article on some of that stuff.

It's crucial to understand that we're trying to demonstrate we can solve the problem, not that we can solve it at a human-supportable scale.

So during the pilot, it's normal and acceptable to re-key the information captured in the system into downstream systems. This is fine because it's a pilot, not the scale phase.

What's interesting is that within the first week, or certainly by the end of the second week, we have almost certainly solved the problem we’re trying to fix on a small scale. This creates a huge amount of excitement within a small group of people without setting broader community expectations.

We're running a small, temporary pilot with a limited blast radius. As I like to say, “no humans were hurt in the filming of this pilot”.

In 15 years of using and refining this approach on over 250 small and large project in govername, corporates and scaleups, I've never had a single example where we couldn't solve the business problem at this point.

I used to think failing quickly would be common and cheaper than failing after six months of documentation, but I've not seen a situation where we failed to build technology to solve a business problem, which was unexpected for me. In the early days I assumed that there would be more failures - but that the failures would be detected super early (according to The Lean Startup). Not so, at least for my projects - in every case we were able to build something useful that solved the problem.

At the end of the pilot, we have a small group of people with huge smiles on their faces because they've had developers building a solution that works for them. We then get those people to present back to a committee, management, or team leaders to get the funding to scale that solution.

Depending on the organization's size, budgets, and problems, a fully outsourced pilot will typically cost between 60 and 120k over two to four weeks. We're talking relatively small amounts of money for a potentially massive upside when you multiply out the numbers.

After the pilot, people might go back to work as normal, so we can think about what we've learned. We've built a custom solution that we could throw away if we find an off-the-shelf solution with a strong fit. But even in this case we’ve saved time and money by taking the “flintstones” approach because we’ve seen what “good” looks like in detail and this confidence leads to a shorter, lower-cost software selection process by focusing on the features and functions that have actually worked, not the 90% that are “nice to haves”.

In many cases though, it’s faster, chapear and better to simply connect up the user experience we’ve created in the pilot with the various existing back-end “systems of record”.

We can firm up a budget for this and ask for the money to scale it out in a project that looks pretty traditional. I would still use many of the concepts from the pilot, but it's not necessary. You can run it as a traditional project, spec it up, and scope it up.

If you have to go out to tender (which is often a zero sum game) then it still makes sense to start with a pilot for the aforementioned reasons.

I've found that the pilot, plus the time it takes to request and get the money, and the time to deliver the project for your top business problem, is always shorter than any project where we've defined as-is, gone to market, bought software, implemented it, modified it, and changed it. Typically, the smallest, most conservative project duration and cost is half the length of its equivalent traditional product-first process.

What's next? We go back to the list from our first workshop and spend two hours in a follow-up workshop. Eventually, you'll get to the point where you can do that follow-on workshop in 30-45 minutes and bang out quite a few of those.

We can set up two or three teams, especially if we have many business processes. One of my recent clients had 70. We might want to split it into teams that do pilots with the same group of pilot communities all the time and teams that come in behind them to scale.

There are many ways to slice and dice it, but the point is to use excitement to generate more excitement and kick off the next program. We're never looking for funding for a whole business transformation program, only a fast payback for a small investment in a pilot and then again to scale it out based on demonstrable, real-world success.

Andrew Walker
Technology consulting for charities
https://www.linkedin.com/in/andrew-walker-the-impatient-futurist/