Friday, October 14, 2011

The 9 key things to make your POC successful

The 9 key things to make your POC successful

POC1A few posts ago I raised the question whether POC is a hurdle to the sales process or actually an enabler, and got a lot of great feedback and opinions which most of them were very decisive that POC’s are enablers and key in making the right decision during the sales cycle of big and complex solutions. Actually not only the sale cycle benefits from POC’s but also actual project implementation could and should make use of this technique to ensure it is dealing with the project challenges the proper way.
In my personal career over the years I initiated and led near to a 100 different POC, prototypes, evaluations and other related activities, all around banking & technology enabling banks to make decisions based on real proof points not only on paper but also on a working live landscape, whether it was during the sale cycle or the actual project.
Today I would like to share with you my insights on the 9 key things that will ensure your POC will be successful and will deliver its value:
  1. Clear Agreement on what is a POC – sounds basic but the first step toward a successful POC is to agree on the actual term. Some see it as an exercise that should be done on paper, some see it as something that should touch topics never done before, some thinks it should be used to show an idea and some feels it should be the actual starting point of the real project. Agreeing on the POC with all stakeholders would be a key success, sometimes you see great work being done however the stakeholders do not appreciate as they expected something else. In our terminologies a POC should always be based on real working solutions together with paper work that describes the results and some of the aspects could not be shown on a system, and more important it always need to answer a question someone asks. if there is no question their should not be a POC.
  2. Clear Scope for the POC – of course any POC should have a very clear scope before it starts. Many POC’s I have seen had a “rough” scope with a lot of “flexibility” which made them un-effective and very costly. If you don’t have a strict scope you will lose the POC very fast. as a POC have the clear objectives of answering a specific set of questions in a very specific timeframe the scope has to be clear and strickt.
  3.  “Less is more” focus the POC on 1 or 2 things – when you come to scope a POC the “less is more” concept should guide you. In my experience the most effective POC’s were the ones that focused on 1 thing, 2 is also OK however if you are trying to deal with more than that you risk once again the effectiveness of your POC.
  4. Clear deliverables  - every POC should define up front a clear set of deliverables that will be produced during its period of time. It could be real working end to end scenarios, or parts of a scenario that represents specific aspect of it, it could (should) include different documentation artifacts (scenario description, lessons learned, configuration rational, etc) and clear end result. if you do not have a clear deliverable it means the POC objectives requires clarification.
  5. Work according to a well-defined method – I have seen to many POC’s that were done as a “ad hoc” setup and “improvised” their way through the POC (actually I saw many projects did the same;-) ) , however as a POC usually requires to bring fast results it is important that the team doing it will follow a specific agreed approach, not too many “methodologies” touch that kind of activity but you can find and if not prepare one before starting (not that complicated).
  6. Small team – one of the main success factors to a POC is to have a very small team run it, for that you need versatile people with cross skills that could cover the full aspect of the POC. Building a too big POC team will ensure its failure as instead of dealing with the content you find yourself dealing with people management and alignment. Most POC’s in the business solutions industry should not be more than 5 people.
  7. Time boxed – a POC must be time boxed, actually unlike with regular project where you first scope then evaluate your efforts and duration, in a POC you need to do the other way around. Start with time and cost boxing, than start evaluating how much content you can take on this POC. Anything that is beyond the time and cost should be left out according to priorities the organization provides.
  8. Proper link to decision process – one of the important objectives of every POC is to support some kind of decision. It could be to decide on a specific software to solve specific requirement, it could be to decide on a specific implementation approach or to decide on a specific implementation vendor, in any case  the importance is that the POC approach and schedules would fit the decision-making process. What is the point in doing a POC that will end only after the decision is already made? What is the point in doing a POC that its end result does not answer the question the decision-making people are asking? So POC is not just about technical challenges but also should be linked to the decision process initiated it.
  9. Self-sufficient &  Independent Environment – to be clear when I say POC I mean for a fact an exercise that uses real working systems in order to answer the questions on the table. I recently encountered team referring to a POC as a “on paper” exercise and this is definitely not the kind of POC I am referring too. In that respect one of the key success factors is to have a dedicated self-sufficient and independent environment such POC could make use. In my past I experienced situation where specific POC teams had to share environments with other activities (like the project sandbox or QA systems) and this is a bad practice. I also know that the need for a real system (or landscape) with all the proper components and data is sometimes the main hurdle in executing a POC, it also could be the main cost factor.
To summarize, a POC (prototype , evaluation , PoU , etc) is a very important approach when dealing with complex business solutions mainly in the banking industry , it is a decision-making enabler as it provides the decision makers have it be in the sales cycle or project the ability to evaluate and investigate specific challenges on close to real life situation reducing the risks and provides great insights. However a POC requires experience and special skills if one wants to ensure it will provides its objectives and would be cost-effective.

Web 3 - blockchain layers

Layers from a blockchain perspective. My plan is to write 5 articles:  1 Intro: Web 1.. 2.. 3.. 2 Layers in crypto.  [this one] 3 Applicatio...