Evidently, one of the basic building blocks of any product and project development lifecycle. Proven to be a widely known term and in practice for ages. But what proof of concepts (POCs) really are? And why 50% of POCs are sent to the trash?
Let’s jump right into it!
What is a PoC?
Generally recognised, a proof of concept is a test exercise of an idea or a concept in a functionally and controlled environment to validate and prove that if the proposed idea can even work in real life or not.
For instance, self-driving cars, a drug test on a mouse before it’s given to public or running a software or data processing task on a sampled data before it could start executing on an immensely large amount of data in a real-time application e.g; airline schedule, weather updates, etc.
Benefits of using a POC
Running a POC helps in:
- Identifying and mitigating potential risks of failure of a product much earlier before phasing out a product to a pilot or production. Hence…
- Can save time, money, resources and even lives of many living beings on this very planet.
- In software world, having a well defined and successfully executed POC would mean a successful launch of an application, from technological standpoint!
Now that we know what is a POC and some of its benefits, but our focus is, why they fail half of the time? So, hazards like waste of time, money and resources can be prevented timely fashion. Let’s find out what sort of rationale, general practices or challenges come into play which might push or turn a great opportunity into a disaster.
Misaligned Stakeholders
The example above can’t be any better to explain than this. Guess what happens in this situation? Chaos, failure, blame games, wastage of time, money and resources. Now remember the stakeholders and the guys who are oftenly found having cordially relationships with them? Exactly! I hope you have already gotten an idea of what I’m going to say next.
Basically, there has to be good relationships with those key stakeholders as most of the POC’s work will be depending on them. Not just financially, but socially too!
In case the POC has to be extended and gets adapted by other departments, stakeholders can use their influence to drive the idea. It is vital that there are weekly meetings arranged with them and get aligned with the vision of the POC with them. That would also help them understand the resultant value this product could bring in once gets successfully launched. Not having the progress presented to them oftenly or ensuring they are on the same page, would lead the POC to failure before even getting started. So, get aligned with all of them!
Miscommunication
Lack of communication could cost not just a failure of a POC but companies may suffer millions of dollars per year. During a survey conducted on around 400 companies, it seemed the invidiual companies lost an average of $62.4 million annually, because of bad communication practices.
Specifically, during the execution of a POC, make sure everything is transparent and well communicated with the stakeholders. That helps in building trust and eliminate any obstacles which might cause the failure of a POC. Ensure that if too many meeting(s) aren’t possible to conduct, emails with change-log, a newsletter and updates are sent out timely, so when having a next tollgate meeting, key people don’t get surprised with the information they were not expecting. Provide context of the information you are sharing without making any assumptions which produces vagueness or ambiguity.
Bad Requirements Analysis
One of they key phase of any project, whether it’s a POC or a pilot. In many cases, technical people are not part of this phase which lead to bad documentation what was not supposed to be built or result in a wrong delivery of POC.
In other cases, the business analysts think that they have it all covered and when the document is handed over to developers or technical staff, they build something wasn’t even asked for. So, to solve this issue, the first thing is to have at least one of the team member be involved during the elicitation phase to avoid any such risks.
Secondly, and the most common one, business owners might change the requirements and scope which may have an impact of overall delivery. To eliminate such risks, have a clear goal right from the start and have it well communicated to the stakeholders or business owners. Unless the new requirements are really critical and a POC is incomplete without them. Then, listening to them won’t hurt much.
Third and most important one, are the collection of ambiguous requirements. From the very start, document all the requirements. And all of these requirements should follow a standard template where everything has to be crystal clear. There are multiple ways to ferret out the ambiguous requirements. For example, peer reviews is one of them.
In a nutshell, getting clear and concise requirements are difficult but also very critical which if not collected correctly, may become another reason to the failure of the POC.
Did you know?
About 50% of product defects reside in the requirements.
80% of rework can be found in the collection of wrong requirements
In one of the report published mentioned the impact of business requirements, where 41.5% of the budget goes to the poor requirements collection.
Even the, 70% of organizations are not taking action to change their ways-of-working!
Lack Of Planning & Design
Now, it’s important to be aware of the timelines and deadlines of the delivery of a POC. Let’s say, the time to deliver a POC of a data migration from on-prem to the cloud is 2 months, don’t just spend all of the time on making it perfect, i.e. from the architecture point of view or everything else (e.g; data pipelines, devops, orchestration etc).
The POC doesn’t mean that you need to deliver a fully functional architecture and the whole project in just 2 months. That’s neither ideal nor it was asked to do that. In fact, it may put you down and turn against you. You are supposed to only ensure if the pitched idea is going to work or not, nothing more!
Overcommitted Features
Suppose, the POC was to cover only 5 graphs on a dashboard using a business intelligence or analytics tool. The data set had to be a scoop of rather a larger historical data set, for instance last 2 months of data. To give it a try, you must bring your team of engineers and analysts onboard before committing this. It is wise to sit together with your team and to go through from the details of what all those graph may entail. A good practice is having a work breakdown structure to transform those features into smaller tasks, can usually help demystifying the complexities.
It’s also vital to do that in an early phase and communicate openly with the stakeholders of what can be achieved and what not.
In case, it’s not done right and later on complexity of solution is found, all the dirt would sit in your lap. So think rationally not emotionally before committing any impractical or unrealistic features which cannot be done within that time period.
Poor Cost Estimation
Yet another most important parameter which measures the success or a failure of a POC. This might not be a very fun part of the game to play, but still has an unavoidable impact.
Many POCs fail because of wrongly estimated cost in the beginning. Hence, the organizations decline to continue the work on such a POC. Thus, one has to be extra careful while doing the budgeting of a POC.
There are several reasons which may lead in poor cost estimation. For instance:
- Unavailability of the right resources and competence
- Underestimation of the require infrastructure or services
- Incorrect of time of delivery
- Enforcing multiple team-members to perform duties parallel on a single job – which entails the risk of getting delayed.
To avoid that from happening, try instead implementing Agile methodology and have a clear view of each and every tasks along with the responsible person to compelete it. Also, again, be transparent with stakeholders of what the estimation might look like. In summary, total cost should include the required man-hours, infrastructure and licencsing fees of softwares will be used. Additionally, add a buffer budget in the estimation which gives enough breathing space before it starts to hit the ceiling.
Wrong Expectations From Vendors
Finally, this might not look too obvious to see but bites you in the back. It is highly likely that a particular vendor hasn’t provided all the details on their webpage about a specific product for various reasons, e.g; it’s under development or not well tested to be available for customers to use. Here this is your responsibility to get all the required features straight before choosing such a product for your POC. If a certain functionality is found out to be not available or in a beta phase at the vendor side, that would surely lead to a failure of a POC.
For instance, if the multi-geo availability was one of the key requirements but during the selection of the service/product this feature wasn’t considered, the POC may not survive for too long. Being the leader or a driver of the POC, ensure all such measure were taken care of before starting working on a proof of concept.
“Good judgment comes from experience, and a lot of that comes from bad judgment.”
Will Rogers
I hope these guidelines would add a great deal of value in constructing a right Proof Of Concept (POC).
Good Luck!
