It is impossible to write a good RFP for custom software development.

Instead of looking for people who can check off your carefully spec'd boxes, you want to look for people who can help you figure out what boxes to spec.

The easiest things to filter for in an RFP response are expertise in a given tech stack or industry experience. But what if there's a better tech stack? What if the answer isn't a tech stack at all? And what if the way it has always been done in your industry just isn't very good.

For example, department stores thought they had distribution figured out pretty well. Then came Wal-Mart. Then came Amazon. Are you sure you want the current "industry" expert?

The point of hiring a collaborative partner is to get insight unfettered by conventional "wisdom." And results beyond what you thought was possible. Not every project can get there, but one thing is for sure -- the RFP process makes it harder for everyone to do their best work.

And worst of all, RFP's make it harder for the smartest, most informed people to work together and solve problems. Is the most brilliant person in your organization writing your RFPs? Are they reading the proposals? Do you think the most brilliant developer in our partner organization is going to respond to your RFP?

Whom do you imagine writing the physical RFP response?

At their worst, RFP responses don't even say anything useful about the participating organization. If you need some semblance of procurement process, fairness, or openness, here's our suggestion.

Instead of an RFP, give everyone a simple problem. A problem that might or might not be related to the big, complicated, hairy issue that faces your enterprise. See how all the people you want to work with attack that problem. See if they listen. See if you like their approach.

See if they challenge and inspire you.

And they you do, hire them.

FTRFP.

More "Changing Procurement" Articles