During my career in the IT industry I have been involved directly and indirectly with a number of PoC’s. I have seen good, bad, really bad and crappy PoC’s been delivered. If you read between the lines, you may have noticed that the good PoC’s is not those I have encountered the most. And there is probably a lot of reasons and circumstances for why I have seen this trend. This is something I want to dig into in this blogpost and point out some key elements for doing a PoC right!
Lets start of with defining PoC. PoC stands for Proof of Concept. This is a generel term which is used widely across different industries. In IT we often relate it to demonstrate a technology within the organization, before fully commit to a full scale deployment of the technology. I believe PoC’s are a great starting point for any organization.
When I reflected on what made the good PoC’s a succes, I realized that the technology was a small part of it. The major difference was where the PoC emerged. It came from within the organization – not the IT department. Now, many of my readers are IT administrators and will probably give me the killer look next time I meet them, but I want to clarify that it is not their technical skills I am challenging. It is more that they do not necessarily possess the project management and communication skills. And clearly, that is something that the IT department doesn’t focus on when they hire IT professionals. Why should they? They need skills within the technical stuff – right? Well thats another story for another blogpost someday – the transformation for the traditional IT to become IT as a Service.
Back to the PoC stuff. So what happens when a PoC emerges from within the IT department and why do they often fail? The IT department looks out for new technology all the time – and they should as at the end of the day, that is what they deliver to the organization, which enables their users to be more productive or making their life easier. I sometime see, when new technology is hot and trendy in the industry, the IT department wants to be a part of the wave for the technology sake.
So what is the key differentiator? Well PoC’s emerged from within the organization had a business need and they already had prerequisites and expectations for the solution delivered. If the solution met the prerequisites and expectations, they were happy = succes. Of course we can discuss that the business don’t understand IT seen from an overall organization perspective and they may have failed in security, compliance etc., but for making my point in this blogpost, its irrelevant.
So how should you do a PoC from within the IT department.?
Well there is, unfortunately, no one model fits all for a succesfull PoC. But lets do it like a case – this way it will be much more fun to read and understand.
A US based law firm, Lannisters, which currently have 5000 users, are looking into xyz technology. They heard that their closest competitors – Starks – have implemented xyz and they gained measurable increased productivity for their users with reduced costs. The Lannisters wants to try out xyz and contacts Targaryan Implementers (Consultant firm with xyz partnership) for a PoC.
On their first initial meeting The Lannisters tells Targaryan Implementers that the Lannisters always pay their dept. Money is not an issue. When can xyz be installed.?
Targaryan Implementers explains to the Lannisters, that it is not only about having it installed. They have seen numerous PoC’s done which just runs in a corner of the server room and never touched. They further explains that there are a lot of business aspects that needs to be covered and predefined.
The Lannisters seems surprised but asks Targaryan Implementers what they had in mind.
Targaryan Implementers brings up a slide deck where they had some bulletpoints.
When Targaryan Implementers do PoC’s for their customers they start of with defining:
- Succes criteria
It is really important to have set some succes criteria for a PoC. This could be that xyz proves that it is capable of running on multiple devices, browsers etc. Find the usecase for xyz within the Lannister organisation.
xyz is a monster and have a huge set of features. Scope the PoC based on the usecase and succes criteria. Scope how long the PoC will run.
- Project Management
at least 2 project managers should be involved. One project manager will represent Lannisters, and the other will represent Targaryan Implementers. With the project management team in place, the intention is to ensure that the information and communication goes smoothly between the the two organisations and keeps the PoC on track with the defined objectives and time.
- Involve the Organisation
Who is going to be the SME(‘s) on xyz within Lannisters? Select a group of test users across the organization and different business units/departments. Some business units/departments might find xyz more supportive/appealing/useful than others. A subset of features may be extremely beneficial/Not Applicable for some business units/departments.
- Understand the technology
For every technology there is a need of some basic understanding and perhaps even some light training. What good is a PoC of something you dont know how to administer and control? Do you expect that the testusers will find xyz useful if they do not know how it is used?
These are neccessary to held. A initial workshop that will define all of the above and afterwards a set of workshops will be held with SME(‘s), test users, management etc. to ensure that the correct information is being collected/given and from different perspectives.
Review the PoC. Did xyz meet your succes criteria.? Did Targaryan Implementers deliver as expected? Did Lannisters fully commit to the PoC? What are the next steps.?
The Lannisters were surprised but impressed about the approach to a PoC. This approach were appealing to Lannisters and they agreed to follow the recommendations from the Targaryan Implementers.
Okay, I will stop here as the next steps will vary from technology, the customer etc. I also think that when the above is completed then you have the right foundation for a successful PoC. I know that this would apply in a perfect world, but why not try at least to do PoC’s this way? One could argue that this would not apply to SMB’s but you could cut down on the process – f.ex. Project Management could be done by the consultant firm, the workshops could be consolidated to one or just a few. In the above case the output would result in some kind of deliverables – this could also be cut down to some simple emails. The important part here is that the above steps have been discussed with the customer and agreed upon at some level.
Some PoC’s are offered free by technology vendors/partners – Why on earth would you do that.? I mean, if you are doing a PoC for free, where is the interest and commitment from the customer? Granted that miracles do happen and the customer sees the potential in a product, but most likely you are wasting time and money. If the customer are paying you will see a lot more interest as they have invested in the PoC.
If a customer doesn’t want to go through the above mentioned steps, what are the chances for a successful PoC? As a partner/vendor I would reconsider and maybe leave the opportunity and work with another customer who would not be concerned about the proces.
Seen from a customer perspective, you should be concerned if you have meetings with partners who would perform a PoC for you without any business related questions asked. They are perhaps asking how many testusers are going to be onboard the PoC (for sizing purposes) – Instead of asking who are the testusers? What are their job roles, what tools are they equipped with today.? You should stick with partners who are interested in your business and the challenges you are trying to solve.
I wrote this blogpost just to highlight some of the elements you should consider doing PoC’s. Use it for inspirational purposes as there can be factors for your PoC that I haven’t covered. But I hope that you enjoyed reading it and hopefully with some inspiration for your next PoC. I surely enjoyed writing it.