Why I am avoiding the acronym “POC” in my IoT projects?
Over the last years I’ve been confronted with a lot of POC’s, but were they really POC’s?
Just like “everything is IOT”, also the term “POC” is loosely used and could unintendingly undermine a perfectly good project scope.
With POC standing for “proof of concept” it is usually interpreted as “proof that the concept works end2end” – so almost like making sort of a blueprint for later roll out,
But, is that really the stage companies are in when launching POC’s?
- This would mean they are ready for an end2end evaluation, not only technology, but also all the services surrounding it.
- It might be about testing “the technology chain” of IoT?
- Or as part of a selection process for vendors
That is exactly the point I’m trying to make.
A POC means something different for each IoT project and each stakeholder. It’s an idea as much as it is an acronym.
In addition to that, IoT projects are often long and sometimes messy.
Do you really want to add possible misinterpretations?
So, what is there to misunderstand about a POC?
In its core, not so much…
noun: proof of concept; plural noun: proofs of concept
- evidence, typically deriving from an experiment or pilot project, which demonstrates that a design concept, business proposal, etc. is feasible.
Keyword in this wiki-description is “feasible”.
Thing is that, in order to define if a project is feasible, you need to have a view on all IoT building blocks.
As next step you need to test or evaluated all blocks and bring them in balance. This includes the all services to integrate them AND all the elements to keep them integrated.
Timing versus “promises of feasibility”
As POC’s (only in name) are often done in the beginning of a project,
often while testing only a narrow part of the IoT spectrum,
they usually don’t provide a “yes” or “no” on the feasibility question.
So inherently promising, by using the acronym “POC”, that you will be able to make a statement on feasibility (while you probably can’t), is not necessarily the best strategy.
Because… technically everything is possible.
There is so much wrong with the previous lines that I will not even start explaining.
So, back to the POC.
Think about what the acronym “POC” means for your internal and external stakeholders before you use it and if it is really a proof of concept that will determine the feasibility.
Words have meanings.
While for yourself the purpose of your POC is clear (hopefully), this is not necessarily the case for everybody.
- A solution vendor (platform, security, device, infrastructure etc.) would see the step after POC – as selling their solution. (now, as this is rarely the case and it explains why I don’t do free POC’s ).
- A C-level executive would see it as a “last step” before rolling out a solution (it’s feasible, so let’s go).
- You, as project owner, might see it as part of a longer process that identifies risks, or as a part of the roadmap to establish feasibility, or to calculate the TCO and ROI, or just to get better understanding of IoT projects.
- Other stakeholders (like legal, operational) might only see it as purely IT related, while the opposite might be true.
So, don’t loosely use the term POC but rather describe what you “exactly” plan to do.
It will make everything clear for everyone and will set expectations right.
IoT is already complex and using terms that have a loaded connotation, in a wrong context, doesn’t really help making it transparent.
- If you want to learn about IoT , then describe it as such. This IoT project is meant to infuse knowledge about IoT technologies in order to evaluate options for …
- Testing critical components, then define as such, The scope and purpose of this IoT subproject is to evaluate following critical …
- Comparing vendors (end2end or a component), then define as such….
if you can then even put it in a project context, with previous and next steps.
Jumping back to “feasibility”
You will need to balance a number of operational and functional building blocks, certainly if you want to be able to answer the feasibility question; How will we set up support? What with warranty management? What with change management? and so on.
These components, not only have impact on your TCO, they might even define your total solution architecture.
- Your device choice or design might depend on the way it is installed or the way it is maintained.
Feasibility includes all these questions, it balances hardware with functionality, maintenance with security etc.
When you are defining your project in a single header, think how you will report on it, how it will be perceived, how it will be distributed towards stakeholders .
You are often allowed to do one or two POC’s before people lose trust, while critical component testing can even bring you more credibility with each time you do one.
It’s all in a word and perception still means a lot.
Kris Van der Hoeven