Posted by: Adam Deane | 03/06/2011

BPM: A proof is a proof

ProofA 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.


  1. Great post, Adam. PoCs can be whatever you define them to be. A proof, even a mathematical one is based on conventions and perceptions. There is no absolute proof. We even demand that the customer pays for a scoping exercise before the PoC to define what proof the PoC should deliver. I therefore do not agree with Anatoly at all. It is one of the reasons that we do not offer low-priced software with free services because high-quality can’t be delivered that way in an enterprise market. PoCs at ISIS Papyrus are in many cases like workshops too, because the interaction with the customer is essential to ensure that the perceptions about what proof is delivered are aligned between vendor, IT and business. Typically one can’t proof the outcome of the project, but only that the software is capable of delivering the functionaly intended. And yes, one of the key elements of the PoC is to see if the relationship can work!

    Proof is an illusion. Perception is the reality. Human interaction more than anything defines those perceptions. In the end the quality of the relationship and how committed the vendor is to deliver is more important than the functionality of the software. If one delivers such a huge set of functionality as we do then it is essential that the project is a collaborative effort to utilize it the right way. While doing the PoC the vendor must also identify if the customer has the ability and the people to actually create and maintain the solution he is offering. If that does not happen and is not considered in the project, it will fail regardless of how great the software is.

    So for me PoCs are more about relationships than about software functionality.

  2. Hello Adam:

    We are not on the same page, I think the cause it’s the semantics, or the meaning of what is a POC is, simply because the POC I run deliver the solution the customer is willing to assess, meaning the customer can put hands on the “beast” and decide if it can resolve or not the challenge the customer is facing. True. Also it puts the vendors thinking how it can truly help the customer, and this is important to know if they are up to the job, or they just master making spectacular demos.

    On the other hand, vendors minimize the project risk because if the proposal is awarded, they know what it’s going to be implemented rather than a could be something scenario than latter transform into tears.

  3. Proprietary enterprise software vendors could afford to offer POC at no cost, go through the traditional sales cycle, as the licensing charges are substantial enough to cover the costs incurred at pre-sales stage.

    However, on the other hand, open source software vendors shouldn’t fall prey to the practice of free-of-charge POC. There is no software licensing fee that can recover the pre-sales cost :p

    Having said that, I’m not against the practice of offering POC at pre-sales stage. But, as long as long the partner understands the service-oriented revenue model behind open source software, and willing to pay by manday for POC development, I’ll be agreeable to implement a pilot. We have been successfully keeping up this model, and the result is good — real commitment from the POC requester.

  4. Hi Adam,

    I can’t believe you are making fun of the ex-Canadian Prime Minister 🙂

    Very good post!

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s


%d bloggers like this: