To give a brief overview, a POC (Proof of Concept), at least in my experience, basically consists of a sales guy, and a sales engineer. They spend a couple of days with a client, and build a solution to prove they can integrate with the customer’s technology. Ash came up with 3 major complaints:
- A typical POC is just a glorified demo.
- The success of the post-POC demo is highly dependent on 2 individuals on the vendor team: the Sales Engineer (the guy who duck-taped together the POC) and the POC-demo-guy
- A POC is typical technology focused. Most IdM deployments are business process centric.
I have a 4th and major complaint, coming from the point of view of a integrator who must implement the solution after the deal has been sold:
POCs typically stretch the system to its technical limits, and are able to do so because they are built in a very controlled environment. When it comes time to scale, the demoed solution won’t work. This leads to unreasonable expectations.
This can create a lot of problems for the consultant/engineer implementing the final solution. I consider one of my most important jobs to be managing the customer’s expectations. A typical overly elaborate POC make this job extremely difficult.
The sales folks may not realize it, but the customer remembers more about the POC than you think. They remember how pretty the screens were. They remember how seamlessly all the pieces fit together, and how quickly each task executes. What they don’t realize is that all of the data is massaged and simplified. Of course the POC could do these things! It has 3 users with 4 roles to choose from, and doesn’t include any of the “exceptions” often found in the customer’s environment. When it comes time to actually implement this feature with 30,000 users things can (and do) get quite a bit more complex.
Has anyone else had bad experiences due to a POC? If so, let us know by leaving a comment.