It’s a classic scenario: a group of people want to use a tool, but before they can, they do a proof of concept (or POC) with the technology as a means of showing that it will do what it says it will do. In the past the proof of concept was purely a technical issue: how does the tool act when working with the various use cases we’ve identified? We create a sandbox and show the value at a demo or two, then we’re ready to move forward.

It’s easy to stop there. But I’ve learned to take things further. The proof of concept should include at least two other aspects beyond technology:

Culture: can you prove (through an experiment or two) that the people who will be involved with the new tool or change will be engaged as expected? It’s nice enough to have the person who is excited about the technology get it to provide value, but can an average person within the organization?

Security: how does your SecOps team feel about this change? Are they on board with it or resisting it? Will they cooperate to the extent that they can put it in production in a limited capacity?

For our Chef initiative both of these elements were concerns that were outside the scope of our proof of concept. If I were to do things again, I would have put them in scope. That would have better clarified and added urgency to all elements that posed a risk to the change.

A good test for a true proof of concept is whether you can get something running in production. If the answer is yes, then you are probably ready to go. If the answer is no, then watch out for what you’re buying and how easily you will be able to roll out the change you are promising.