VOC & Fast Focused Change

Nice-to-haves are a serious cause for overruns. The solution is simple and at the same time a though mindset and discipline.

It doesn't matter what indusry and it doesn't matter at what stage of development it is. I know that 20 years ago the same difficulty existed and continues to exist.

The solution sounds so simple: create and only create what is minimaaly necessary. What is preventing us and what can we do about it?

I can built the case on most if not all the projects I became involved with. Most likely you can relate to many yourself and therefore I will skip this part.

In hindsight what I learned is what many others learned as wel; with me, after me and before me. My learning emerged as the MIN=MAX-rule: the minimum what is required to achieve the objective(s), is the maximum we are going to do. To make this rule pragmatic I developed a very solid procedure to quickly create a visual project network called PFD+.

Riece, author of Lean Startup, strongly suggests to concentrate on getting the MVP - Minimum Viable Product - quick to the users. His credo: build-measure-learn; a more fast-paced versie van PDSA.

Keep it small is an important part of the message of Riece. The second part is: don't pretend to know it better than the user. As soon as you have something, give it to the user and learn from it. Maarten de Winter says: it isn't about the result, it is all about the use.

How easy as it might sound, how difficult it is. The ugly head: I-know-it-better quickly raises in the disguise of this-can-be-improved and it-is-much-better-when. Fine if this comes from the user, but usually it isn't. Why are we doing it? Or better put: for whom is meant and what do they want/need?

As most have learned the hard way, you usually can't ask the user what they need/want. They wanted a faster horse, less poo in the streets ...doesn't sound like a car, but the automobile was the solution. Most of the time the user only know through the use and experience what they want and need. The best way to create the ability of usage and experience: build a MVP - a Minimum Viable Product.

Very much like what Riece proposes, Snowden strongly recommends the usage of experiments. Experiments not to prove something, but experiments aimed at learning. This means that the set of experiments should include contradicting experiments as well. The objective is not to know if something works. The objective is to learn what does work AND what doesn't work. Or like good old Deming asks: where is the theory? Unless you can say what does AND what doesn't work based on experience all you have is an uncontested believe that might be very well false and stab you in the back.

What I particulary like about Snowden is that he provides this very nice framework called Cynefin. The Cynefin framework helps to frame a situation in a way that it becomes pretty clear when it is opportune to and when not to do lots of experiments. The framework is powerful enough to be used when the people involved have become too stuck to see they're stuck.

Putting it together

So what can be the cause for all these nice-to-haves more than likely to cause serious overruns? If I was to put all these experiences and ideas together, IMHO the cause boils down to: the people involved become too involved in  the creation and loose track for whom, why and what is minimally needed. The 'what therefore quickly explodes and looses its connection with the intended user.

The solution: what is minimally needed get that as quickly as possible in use. Don't be afraid to put contradictionary or half finished solutions in the market (of course well framed). You don't know most of the times if something is half-finished or sufficient or even redundant. There is only one clear way to tell: Listen to the Voice-Of-the-Customer (VOC) they are the only ones who can tell.