In order to help people to get away from ‘production think‘, I’ve been struggling with trying to precisely define a Proof of Concept. It’s almost easier to define what it’s not…
Back in March this year, I thought:
A high risk, high trust and low governance project that creates a conceptual solution for the client. Focus solely on the concept. Forget security. Forget firewalls. Forget QA etc. What is delivered is a bare-knuckled prototype which demonstrates how it could solve the issues your client deals with.The project has no limits other than Time (approx 3 months) and Resource a small team working part time within a small financial budget. Concluding each POC month is a ‘Show and Tell’ to an audience of sponsors, users and internal teams - each one being more public than the last.
Not satisfied this with mouthful, I had another go in early October:
“A practical process designed to discover and focus on the core of what and how to innovate.
By placing people in a deliberate environment of trust without real-world constraints other than limited resource, timelines and lightweight project management, a PoC nurtures innovative creative solutions.
Chatting with Mike Seyfang - he would also chip in:
- a vehicle for embracing risk
- an environment that creates space in work for play “expect 6/10 to ‘fail’ but 3/10 might just be ‘hum dingers’
Then again he had the urge to spurt out:
3 people - 3 months - $30k
…there’s a certain appeal in the above’s simplicity.
What’s your thought’s about trying to define an innovation process?
3 Comments
Tom, Andy is thinking about his too!
His thoughts over at:
http://processofinnovation.com/wordpress/?p=28
Fang
The 3 people 3 months $30k has its appeal - but it doesn’t work that way. My guess that in your edna PoC you’ve used the input, thoughts and ideas of 30+ people that are being funded by other organisations or projects for the time they participate in or contribute to the thinking about or implementation of the PoC. Collaboration provides richness, some input into the hive mind, a better more realistic result perhaps - but it can also be more expensive to do.
I think the PoC approach can be problematic, because as we know the 85/15 rule where the 15% takes 85% of the time. With proof of concept you’ve often worked out most of the 85% - the conceptual stuff. The 15% is the hard implementing stuff - when firewalls, accessibility, metadata compliance, internet speed etc etc all comes into play. Someone might want to buy a proof of concept, but it’d be pretty risky to sell it ;-)
I think you have highlighted the problem: not many people understand that a PoC is a precursor a full blown project.
It directly informs a proper project’s analysis, business case and scoping aspects.
Classic project management has to be safe because of to 85%-15% concept. In this framework you can’t take risks. In a PoC you can.
As you have correctly identified, a PoC looks at the concept. This dramatically reduces the big project risk of developing the wrong ‘concept’ - way before committing traditional serious project resources.
I liked your “Someone might want to buy a PoC…” comment because it’s made me think that a PoC outcome should be “someone might want to back this PoC - by funding it as a true project”
One Trackback/Pingback
[…] Defining PoCs […]
Post a Comment