BPM: A proof is a proof

A proof is a proof. What kind of a proof? It’s a proof. A proof is a proof. And when you have a good proof, it’s because it’s proven.

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

Proof-of-Concept is meant to be a good 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.

The downside of it is: that if not planned and executed correctly – it doesn’t provide any real value or insight for the customer, and a waste of time, effort and resources for the vendor. A glorified presale.

Anatoly Belychook had an interesting view on these issues in his latest blog post:
“No more POCs” and correctly identified the problems vendors have with POCs.

Engaging with new customers is always a delicate issue.
You know the product works. You need the customer to feel comfortable with it also.
POCs are part of the sales cycle.
As long as the targets and scope of the POC are defined, and the vendor is being paid for their time, and you’re not being brought in just to be a column filler – it shouldn’t be an problem. If fact, POCs are usually good fun (it’s only the sales guys that are panicking..) It’s also a good time to bond with the customer’s team.

That all said, although we still do POCs, I try to discourage the use of them nowadays.

Instead, we prefer to run workshops.
We find workshops provide better value to the customer, and lower the risk for us.
It’s the same concept of a POC, but more emphasis on building a real process, less emphasis on building a great demo.

The best place for workshops are at the vendor’s office. This enables the customer to concentrate on the process they need, they don’t need to play host and removes them from their regular day-to-day stress and distractions. (it also gives overseas customers a good excuse to come to London…)

The target of the workshop is pre-defined, the time spent is pre-defined (usually 2-4 days), the required outcomes are predefined.
Workshops are less stressful than POCs, enabling to build an informal relationship (as you are sitting with them all day).
Because they are visiting your office you can bring in additional resources to talk to them. (I’m regularly called in for the technical sessions…)
Workshops are not free. There is a daily rate. A defined budget. No scope creep, or adding features.

We usually spend a couple of days on process discovery and process design
and then a couple of days building a mock-up of the required process. A few steps. Not an end-to-end solution.
Its a mockup of the process they are looking to implement, not an example of an unrelated process

I’m not saying that POCs are not used, or not needed. Everything has its place.
If it’s a tender, then a POC is probably the way to go. If the customer is looking for the BPM software to be used as a development platform, then a technical and functional POC is probably the way to go.
But if it’s possible, I try to steer away from POCs and towards workshops.

In the end it’s in the hand of the customer. They need to feel comfortable that the tool, solution and relationship can work.

Proof of concept?
As Jean Chrétien, Canada’s Prime Minister, once famously said:

A proof is a proof. What kind of a proof? It’s a proof. A proof is a proof. And when you have a good proof, it’s because it’s proven.