BPM: Proof-of-Concept (POC)

I find it hard to understand why anyone would buy enterprise software, let alone BPM software, without going through a Proof-of-Concept (POC).

I love POCs. I really do. I find them challenging, I find them exciting, I find them creative…
I also believe that they are in the customer’s best interests.

A Proof-of-Concept is an opportunity to demonstrate the capabilities of the BPM software in a controlled manner and to verify that the solution is actually capable of solving the enterprise’s business pain.

POCs are the best way for the customer to really see what it takes to get a process up and running, from start to finish. How long it takes, how much effort, and what kind of skills are needed.
Most POCs take between 3 days to a week, one process (usually one of the first business processes that they are looking to implement, or a generic kind of process, like complaints, purchase or HR) and are run on the customer’s environment.

They best kind of POC is a “hot house”.
You’re put in a small room. The laptop is connected to a projector on the wall so that everyone can see what you’re doing, (no monkey business). It’s just you and the customer’s review team.

The sales guys are politely asked to leave until the end of the POC. (It’s a smart move as this ensures that the POC doesn’t turn into a sales presentation, and enables the customer to resist any sales pressure to make quick decisions).
Techies, specially experienced techies, are usually more open about what works, what doesn’t, customizations, capabilities and limitations (but lets not kid ourselves: we still want to win the tender).
POCs enables us techies to shine and gives the customer a chance to evaluate the quality of skills that the vendor supplies.
It’s now up to my experience, my skills and the BPM software!

By developing a POC for the customer, it forces us to fully understand the requirements earlier on.
The understanding required is more deeper than what one normally learns at the start a new project by simply reading through the requirements document. The POC requires you to show that: not only do you understand the business pain, but can actually solve it…

Most business analysts know what they want only after they have seen an initial version of the solution.
POCs enable them to get a better idea of what they want the final deliverable to look and behave like, to adjust their requirements and to better define their expectations for the final deliverable.
During a POC, they actively participate, get real “hands-on” experience with the product and can ask more specific questions, placing them in a better position to evaluate the product.
Although POCs are an excellent risk mitigation strategy, there is a risk of raised expectations where the customer will expect the delivery of the rest of the system at the same pace that the POC was developed.

POCs force the vendor to allocate technical, sales and management resources for the POC duration (instead of sending the regular presales jockey)
POCs create an extra level of competition between vendors. Competition adds pressure on the vendors, increasing the customer’s bargaining power.
As long as the tender is not “fixed”, and that the decision is based on a fair set of scoring rules – it’s an investment worth taking.

POCs require the customer to allocate budget and resources to design the POC and spend time evaluating the products, but as long as the POC is well planned, the schedule set and the target clear – it’s an excellent choice.