Proof of Concept – Paint the Eaves before the Doors

I was recently in a meeting with a client of mine and one of their most respected vendors. The vendor was proposing a “Proof of Concept” exercise, implementing a bare bone version of their newest software.

The client proposed real world issues which the final version of the software needed to address. The vendor baulked at including them in the PoC*; concerned with the PoC failing. Through a long series of conversations, the vendor agreed to adding limited portions of these requirements. They insisted on a vast array of disclaimers in case it didn’t work.

I’m not trying to pick on the vendor, they were doing what we all do in these situations. They want to impress the client and drive as much functionality into the three month PoC as possible. Martin Fowler touched on this issue in his blog the other day.

I agree with him and in this case, would have liked to see the Vendor approach the Client with proving their technical limitations first. I don’t see that happening and anticipate a PoC that fails to live up to the client’s expectations.

I owned a painting franchise in University. I often told painters to avoid painting the easy stuff first. Leave the ground floor doors and basement windows until the end. Get up on the high ladders and paint the eaves first. By tackling the toughest task first, you have an accurate indication of how the rest of the project will go.

I think back to those projects all the time and marvel at how painting a house draws such significant parallels with building software…

*PoC – Proof of Concept


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 )

Google+ photo

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

Twitter picture

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

Facebook photo

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


Connecting to %s