Kevin P. Taylor

Conversations over RFPs

I had a conversation recently with a friend who also runs a software development company. During the conversation, the topic strayed (as it often does), to how we each find new clients. I was shocked by his response. His relatively successful company finds many of its new clients by responding to RFPs.

For those of you who haven't had to deal with them, RFP stands for Request for Proposal. Companies write RFPs that explain a problem that needs to be solved and then the company invites one or many vendors to respond with proposals describing how the vendor would solve the problem and how much it would cost.

It sounds wonderful for a client company. The company has an opportunity to compare multiple proposals against each other and choose the most appropriate one. And, in fact, RFPs are used successfully in many business situations, such as building out a new data center or replacing a roof.

But, when a company is looking to purchase custom, creative services such as software development, RFPs become an obstacle. We all know that one of the primary determinants of a successful software project is the cooperation between the different members of the team. The product owner, business stakeholder, developers, and designers need to be pulling toward the same goal. There must be trust and collaboration.

How are potential trust and collaboration measured via an RFP process? Well, they aren't, of course. So, a critical aspect of the client-vendor relationship is left eerily unaddressed during the RFP process. The crucial question of, Can we successfully work with these people?, is left unasked and unanswered.

So, instead of responding to RFPs outright, we always attempt to engage the company in a conversation. We do this because, quite frankly, we don't want to take on doomed projects. Only through the series of conversations and brainstorming/planning sessions that happen during the sales process can we get a read on whether we think we can trust and collaborate with the potential client. And, I want them to take that same read on us.

Ultimately, if the company is unwilling to discuss their problem with us outside of the RFP process and iterate with us over possible solutions, we disqualify them from our sales pipeline and move on to prospects who are looking for a relationship based on trust and collaboration instead of a relationship based on commoditization.

Build Trust Box Relationships

Remember your last road trip through the countryside? As you drove down that country road, chances are good that you spotted a trust box or two sitting alongside the road.

A trust box is one of those unmanned "for sale" stands you'll see sitting off the road, near a farmhouse. They'll typically consist of a weathered sawhorse or table, a basket of farm-fresh tomatoes or a few cherry pies, a rusty coffee can, and a big, hand-written sign spelling out the terms: "Tomatoes: 50 cents each or 3 for a $1. Put money in can. God bless!"

Image by keeeks

If you buy or sell contract software development services, what can you learn from a trust box? Let's walk through how a trust box works and see what it provides.

In the best case scenario, a customer picks a tomato from the basket and puts money into the can. Everyone is happy. The customer gets a fresh tomato at a low price. The farmer gets to spend more time farming. The cost of the relationship between the farmer and the customer is at its lowest possible level.

Now, what happens when the customer picks a tomato but doesn't put money into the can? If it only happens occasionally, the farmer can simply factor that slippage into his prices and carry on.

However, the trust is diminished and the cost of the relationship increases.

What if we take it to an extreme and imagine that lots of customers regularly don't pay for the tomatoes they take? At the end of each day the farmer has a good chance of having very little or even no money. Now uncertainty exists. The farmer can no longer trust his customers to meet their commitments (to pay for the tomatoes).

Of course the farmer wants to continue selling tomatoes--this is his livelihood. So, he locks down his processes. Yep, he pulls up a lawn chair and mans his tomato stand, dog gone it. He still sells his tomatoes but what are the repercussions? The customer pays more. The farmer farms less.

The trust is gone. The cost of the relationship goes even higher.

So, what can we learn from a trust box? Trust is a lubricant. The more trust, the less friction. The less friction, the more everyone benefits.

In software development, devices such as contracts, upfront deposits, specifications, change orders, CMM Level 5 certifications, and multiple sign-offs are all used to lock down the process and control uncertainty. But, each of these increase the friction in the relationship. It gets pushed further away from being a simple trust box.

Build trust early and work hard to keep it strong. Its value is quantifiable.

Quality, the Four Variables' Stepchild

We've all heard of the four variables (a version of the Iron Triangle) that comprise the inputs of a software project (or any project, for that matter).

1. Time: The calendar time required to complete the project, i.e., the completion date.
2. Resources: The cost of the project in scarce resources, such as salaries, tools, data center space, or bandwidth.
3. Scope: The value to be delivered. In software, this is typically measured in business value via story points, features, or a similar measuring unit.
4. Quality: How well the scope is delivered.

Arguably, the most controversial and difficult to define of the four variables is quality. 

Some people believe quality and scope cannot be separated. They believe that scrimping on quality is just an underhanded way of reducing scope. Others believe that quality is not a variable at all. These folks would argue that the quality of the output of a particular team is a given, not a variable. Others even believe that quality is an absolute. Quality must always be at 100%. But, 100% of what?

I tend to think of quality as the professional practices of the development team. How rigorously do they follow good (XP) development practices? Are they pair programming and testing first? Are they using continuous integration? Are they designing maintainable software using techniques such as the open-closed principle and refactoring?

If defined in this way, quality can be a useful variable. For instance, a team may choose to do without pair programming during an iteration  in order to increase scope. Or, they may choose to delay particular refactorings until a later date (or forever). Or, a startup may have limited financial runway and simply will not takeoff without massively reduced quality. How many successful products, such as Microsoft's Office or Amazon.com would not exist today if they hadn't scrimped on quality early on in order to get to that first revenue producing stage.

Is reducing quality always the right or wrong approach? It usually will be the wrong approach just as would be paying your mortgage on a credit card. Eventually, most reduced quality must be repaid with interest. 

But, by evaluating potential project input decisions within the framework of the four variables, you can make tradeoffs intentionally and increase the chance a challenged project will be considered a success by the stakeholders.