The two most powerful questions in business should be these two:
Can we? Should we?
My sense is that they are actually a very distant second to these two:
How much? How quickly?
This is wrong.
What follows is not a paean for a slower-paced, more genteel world. Indeed, like Ike and Tina, I actually like it fast. And rough.
Let’s Build Then Test Then Perfect
Certainly bypassing the objective criteria of price and schedule might seem irrationally exuberant, even youthfully reckless. In light of our new “information everywhere” society, it seems that predicating the life of a project on such unidimensional considerations as money and time alone is not sustainable. With technology continuing to morph dramatically across use cases, and with new delivery methods being introduced almost quarterly, the leadership in neither the marketing department nor the IT group can be expected to accurately track and meet the arc of today’s user expectations.
On the basis of recent project work it’s clear that right now there is an opportunity for a focused team to explore if the goal of the project is possible, and once the outcome is known to determine whether following through is even a good idea. This means devoting time (and money) in the project plan to a test phase, with the outcome being a “Go / No-Go / Go with modifications” decision.
It’s this last part that is key: senior management needs to be given enough information and context for them to have the courage to spend a small fraction of the overall budget on some exploration. Would you spend $10,000 to not waste $220,000?
Some senior leadership teams reply with, “I shouldn’t have to spend $10k to know if I should jump into a project 22 times larger.” This thinking simply doesn’t hold true anymore. The continual lightning-fast evolution of user behavior, which manifests in shifts in application architecture and interface – much less the speed of improvement and innovation in the gizmos that transport and display our data – means that a test will yield exactly the kind of intelligence needed to turn good into great. On top of this, as it pertains to the finances we can think of this test as the digital version of that old saw, “measure twice, cut once.”
The vehicle for doing the cutting is called a proof of concept, which is nothing more than a smaller-scale, contained version of the grander vision. Project plans rarely accommodate the development of proofs of concept, and this is a shame and a mistake.
A proof of concept is not a practice run, it’s Big Idea Validation. The concept is not limited to technology: Formula 1 teams do both computer simulations of engine changes and extensive half-scale (and sometimes full-scale) wind-tunnel testing of design changes. Testing a proof of concept is baked into their processes, as it should also be with simple web applications.
Proofs of concept can take on many forms, and they need not be employed to solve only massively complex constructs. Often times simple ambitions can be vetted and plussed up by a proof of concept. What’s needed are the standard groups of SME’s, senior leadership, and the voice of the user(s) to design and test the pre-program.
The evolution of both data management and user experience has made conventional technology approaches all but obsolete. Dedicating an early phase to a proof of concept is the most effective risk-reduction move a management team can make when facing any technology-driven project.