One of the key issues many corporate entities run into on a regular basis is evaluating a new technology before it’s greenlighted for broad implementation across the company. This stage, called Proof of Concept (PoC) or pilot can often prove to be a make or break phase as it often involves many more people and organizational processes than the ones preceding it.
When the time comes to see how the technology works, after months of defining the needs, determining the overall process and development there seems to be certain weak links in the initial implementation phase which have brought entire projects down.
With our ongoing experience of dealing with both corporations and tech companies, we think it would be prudent if all sides keep a close eye on three particular aspects which have turned out to be problematic on several occasions.
Before any integration work begins, it is important to properly define the pilot in a way that will achieve a fair proof of concept. This includes, but not limited to, a predetermined time frame, the set of competencies being tested and mapping out the scope of the pilot. This framing must be determined and agreed upon ahead of time. We’ve encountered quite a few cases where a PoC was pushed into asking for more technical capabilities, increasing the number of processed data sources or dragging out the time period used to make a proper evaluation of the technology. All of these issues and more can cause the pilot to lose its focus and sometimes even its original purpose, making it hard to conclude and move onto the next stage in the process.
It is also essential to assign a champion who will lead the process on behalf of the business unit. It will fall on this person’s shoulders to appoint any required resources as part of the pilot’s efforts from the corporate side. They will also need to arbitrate any conflicts that may arise and possibly decide which are the most burning issues that need a proper overhaul. Perhaps the most important role will be that of the evaluator. This manager will be the one to eventually present to upper management with a summary of the pilot and a clear verdict if to continue the integration or present other options.
An example case we encountered was of a large enterprise which started a PoC process with a tech company, setting up realistic KPI’s and timeline. The project became too difficult to handle when more stakeholders and business units were introduced to the process and eventually the responsible innovation manager was sidelined. The project languished in the corporate’s legal department and for the entire time, the startup was left out of the loop. You can probably imagine the outcome that came eventually.
Last, but certainly not least, is the need to take the right amount of time and properly document the feedback of the operating team. In almost every organization that doesn’t have an existing methodology to implement external technologies, the occasional projects and pilots can often be forgotten or swept up in the day to day workload. The final phase of the pilot, when all the parties involved are supposed to share their professional opinions, is often rushed or dismissed.
This is a mistake which not only reflects on the pilot the team was working on but also on future projects. The participants must map out what worked or didn’t work in this specific PoC as well as the lessons learned about the project in general. This feedback needs to encapsulate everything that needs to be applied for the next pilot to be conducted more efficiently. This includes defining the terms from the start of the process, cost efficiency, end results and, no less important, proper communication between all of the parties.