Flintstones Are Also Better Governance

It’s easy to look at a Flintstone-based pilot as a natural extension to an existing delivery model. In reality, though, it’s a fundamentally different approach to governing work. The difference begins even before the project has started.

In a traditional governance model, we do months of work to define scope because the scope document is used as the primary form of governance along with a project plan of the phases required to deliver that scope. The scope document is also necessary because, in a traditional governance model, we have to ask for all of the funding at once. To ask for the funding, we need to know what the cost is going to be, so we need to estimate based on the scope of work. Interestingly, we have known since the 1950s that this approach of estimating and choosing technologies before a project starts is highly unreliable. A good reference for this research is the book "The Mythical Man-Month," which is studied by most computer science students but unfortunately not most managers.

In a traditional approach, the cost also depends on the technology chosen, so repetitive redundant activities are carried out across many projects to define a technical architecture instead of using modern cloud technologies that obviate the need for this architecture entirely. If we think of this pre-project phase as the business case phase, or cost-benefit statement, I’m saying that 90% of the effort is spent on the cost side of the equation and only 10% is spent on the benefits side of the equation. It occurred to me during the project rescue phase of my career that this work was unnecessary if we abandoned scope as the primary governance model.

At the right moment in the early days of this millennium, one of my clients introduced me to the idea of using Flintstones projects as the primary mechanism for requesting funds for the larger project. From a funding and governance perspective, the Flintstones model replaces the traditional cost-benefit phase with a pilot. The goal of the pilot is to demonstrate that we can deliver the business benefit without concerning ourselves with the work required to scale that solution across the organisation. If the Flintstones pilot fails to deliver the business benefit, then no more thought or expense is put into investigating technology or scope.

Or, in the words of my client, a Flintstone pilot is designed to demonstrate the business benefit, albeit at an unsupportable cost. The costs that he was referring to were the semi-manual and semi-automated procedures, generally in the back office of the project itself, required to deliver the relevant experience or solution to a small group of pilot users. This almost always involved re-keying of information or sometimes downloading or uploading files from and to source and destination systems. This is a really important facet of a Flintstones pilot because the pilot is designed to be temporary, so it’s important to ensure that data ends up in the current systems without incurring the cost of integration.