All Posts by Bob Lewis

|In: Industry Commentary|Last Updated:

RFP stands for “request for pain.”

The practice was seriously awful when I first wrote about RFPs in InfoWorld back in 1996, and the situation has, if anything, deteriorated since then.

Requests for proposal and their request for information (RFI) brethren is to select the best vendor to handle a particular business need.

The actual results are, at best, hit and miss. What goes wrong?

Overspecification: I’ve seen RFPs that list hundreds of specific, detailed requirements, presumably as an attempt to minimize puffery, blow-hardery, and general-purpose hand-waving in the responses.

On the surface this might seem admirable — a way to minimize misunderstandings and assure solutions that solve the actual problems.

Regrettably, the requirements listed in the RFP are only as good as the business analysts who wrote the list. Strike that — they’re only as good as the insights provided to those business analysts by those who will be stakeholders.

Worse, even the best lists are just headlines and not the complete stories, and as responders weren’t part of the discussions that generated the list, their responses are sadly lacking in context.

But wait. It’s even worse! By insisting responders address specific and detailed requirements the requester loses the opportunity to take advantage of responders’ creativity, expertise, and innovation. Instead they force every vendor to submit a response that’s just about identical to the responses submitted by every other vendor.

Price tyranny: Overspecification leads to undifferentiated responses. As an inevitable consequence, evaluators are left with little beyond price and intangibles for their decision.

But intangibles are what RFPs are supposed to drive out of decision-making.

As for price, imagine you’re responding to an RFP for creating a custom application. The other vendors estimate the cost of building it. You also estimate the effort that will be needed to modify or redesign business processes, and to identify and deal with sources of organizational change resistance, something not included in the RFP but vital for real success.

But your proposal costs more. What a shame.

Agility exclusion: Those issuing RFPs understandably want responders to provide a fixed price for their proposed solution. Increasingly, they also want projects that make use of Agile techniques. The contortions needed to commit to a fixed price in the face of Agile’s core strength — dynamic adjustments to the project backlog as everyone involved in the implementation “learns their way into it” — are, to be as diplomatic as I can manage, something of a challenge.

Case studies: All RFPs ask for case studies — demonstrations that a responder has done this before. This would be logical if responders were individual human beings.

Actual responders aren’t. They’re corporations, which aren’t just like individual persons only bigger. Which means that even though a responding corporation might have done this a dozen time before or more, that doesn’t mean even one member of the implementation team will have participated in even one of the case studies included in the response.

This can’t be fixed, because even with all the best of intentions, even if a responder can state that several members of the response team were, in fact, involved in one or more of the case studies, there’s no way to guarantee any of them will still be on the bench and available for the project, given the multi-month delays that are typical between the time responders submit their proposals and the issuer signs a contract with one of them.

One more problem with insisting on relevant case studies: They completely preclude innovation. In case the reason isn’t obvious and self-explanatory, innovation means coming up with something new and different, which means there can’t be a case study.

The result of which is that proposers either (1) avoid proposing anything innovative; (2) propose an innovative solution and explain, clearly, why case studies aren’t possible; or (3) propose the innovation and stretch actual case studies to fit.

Most responders will play it safe and choose option #1. But to fix what’s wrong with RFP-driven vendor selection, proposers will have to take the lead, playing it the opposite of safe. They’ll have to try something quite different.

For example, speaking as a more-than-occasional responder, I’d love to receive an RFP that says, “Here’s the business problem we’re trying to solve,” followed by a clear and compelling narrative, followed in turn by this question: “How would you go about solving it for us?”

I think all parties would find the results quite refreshing.

Comments

|In: App Dev Methodologies|Last Updated:

As participles go, “excited” is a bit too strong, but “interested” is too limp.

I’m trying to describe my reaction to the email I received from a major air carrier, letting me know I was only a couple of hundred miles short of a first-class round trip ticket to anywhere in the United States. And if I had no immediate travel plans that would take me over the top, I could buy enough miles to cover the spread.

The minimum miles purchase was 2,000 for $59. Not too bad, so I clicked where I needed to click and arrived at the checkout page, which informed me that in addition to the sixty buck price tag, I’d also have to pay $35 in administrative fees.

My wife used to shop at Herberger’s. No longer, because Herberger’s is no more. One reason, we’re convinced, is that we weren’t the only customers who, attracted to the store and website by the many discount coupons they sent us, were annoyed to find that the coupon we held at any given shopping moment could not be used to buy the merchandise we had in hand.

The terms and conditions associated with Herberger’s coupons put your average end-user license agreement to shame.

Which leads to this conclusion, which in turn will lead to the point of this week’s essay: When it comes to structuring any sort of promotion, keep stupid out of it, and empathy for customers in it.

In the case of my first class ticket I can imagine the discussions that led to the $35 admin fee: “Deal momentum” would carry enough customers through that the net revenue gain outweighed the net reduction in total sales volume.

The math probably works. But the psychology doesn’t. All things being equal, the next time I travel I’ll do my best to avoid the airline in question. It’s an entirely predictable outcome, which would have been avoided through the simple expedient of concealing the $35 admin fee … an utterly preposterous number … within the purchase price, just as e-tailers that offer free shipping do.

Which gets us to the point, which is software quality assurance.

No, really.

Increasingly, as part of Digital this and Digital that, businesses are paying far more attention to the customer experience than they used to. As part of this effort, they’re creating mechanisms to understand how customers feel about their interactions with the company.

For telephone callers, it’s standard practice for companies to record calls so as to measure how well their call center staff are handling customer requests and complaints. Web and mobile apps are tougher, but methods for evaluating the customer experience in these environments are rapidly increasing in accuracy and sophistication.

It’s what internal IT would call UAT — user acceptance testing, which, done well, includes end-user suggestions as to how to improve overall usability.

Paying attention to the (real, paying) customer experience on the web and through mobile apps is admirable. I’m in favor of it.

What I suspect receives too little attention, though, is that unlike internal applications, the web and mobile customer experience includes more than layout, design, and functionality.

It also includes matters of more substance, such as the $35 admin fee I’m griping about here, coupons that are (or, in the case of Herberger’s, weren’t) redeemable on e-commerce websites and mobile apps, and, for a third example, requiring shoppers to establish userid’s and passwords before being allowed to buy merchandise.

Those who think in terms of organizational charts are likely to divide aesthetics, functionality, and substance into separate testing regimes. As with so many other forms of business dysfunction, this misguided use of the org chart is a likely step on the path to, if not perdition, at least suboptimalism.

This is because unlike everyone inside your company, for whom the org chart might be sacrosanct, Real Paying Customers don’t care an infinitesimal fig about who reports to whom or how responsibilities are divvied up.

They (which turns into “we” when you and I go home and shop for something) just find all of the above annoying.

Annoying, that is, is for Real Paying Customers a collective gerund, not a decomposable one. Which in turn means that customer experience testing should be collective as well.

KJR’s readers are increasingly being pulled into Digital initiatives of one sort or another. If you’re among them, promote this thought process:

The customer experience is holistic. We have to pretend we are, too.

Comments