All Posts in Policies and Procedures

|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: Office Politics|Last Updated:

I didn’t have time to write anything original this weekend. Instead, a cautionary re-run from November of 2003 about information security and how not to go about ensuring it. – Bob

# # #

Students of corporate behavior, attempting to account for the seemingly incomprehensible level of self-destruction evident everywhere in the business world, often find themselves at a loss. Why, they ask, would a business do something like this, whatever “this” is this time?

The answer is usually easy to find, if you know where to look: Businesses can’t be self-destructive, for the simple reason that businesses aren’t selves. Human beings make the decisions, either individually or in groups.

Some of these individuals and groups make their decisions with the good of the company in mind, even though “The Company” is a fictional beastie that lacks any actual intent, consciousness, or independent reality. Others focus on “shareholder value,” showing an admirable, albeit misguided altruism toward their employer’s legal owners — misguided because their altruism is rarely returned by the shareholders whose interests they hold paramount.

The majority of decision-makers do neither. They base their decisions on exactly the criteria they’re supposed to use in a capitalist society: They look out for their own best interests. Often, their best interests have nothing at all to do with what’s best for the company.

How else to explain the following event:

A character arrives from corporate headquarters. Looking in the mirror, he sees a secret agent looking back. Or maybe he thinks he lives in The Matrix. Hard to tell.

“Why are you here?” the head of security asks him.

“I can’t tell you.”

“What are you planning to do?”

“I can’t tell you that, either.”

“What can you tell us?”

“I need a work space with a network connection, telephone, desk and chair. And please don’t interfere with what I’m doing.”

He’s from the holding company’s headquarters. A quick check confirms he has the authority and the right to ask for this, and so it is done. A few weeks later, he packs up and leaves, having downloaded a number of security intrusion tools used to … keep in mind, this is a true story, not paranoid fiction … break into and damage several production servers, thereby proving, I guess, that the network is vulnerable to someone from headquarters connected inside the firewall, with no oversight or supervision, no responsibilities other than breaking into the network, and the authority to insist on being ignored regardless of his actions.

From a security audit perspective, his behavior is unprofessional on at least two counts. The first, of course, is that he did actual damage instead of simply leaving evidence of his successful entry.

But that’s the lesser example of the complete worthlessness of his efforts. The greater is that he ignored the basics. The test of an organization’s security isn’t whether it can be hacked, let alone whether it can be hacked from inside its firewall. The test … actually, the two tests of any organization’s security are (1) Does the organization’s security policy fit its needs? and (2) Does the organization’s actual security implement its security policy?

Since Mr. Bond never bothered to read the security policy, he’ll never know. All he knows is that it’s possible to penetrate his subsidiary’s firewall from inside the firewall.

An impressive performance.

How does one go about explaining behavior this bizarre? It requires neither a conspiracy theory nor a temporary shortage of Thorazine.

All it requires is an understanding that everyone in every company acts solely in their own best interests. It’s up to the company’s leaders to ensure their best interests line up with those of the company, and that they understand this alignment.

At a guess, HQ’s secret agent saw a possibility of career advantage from showing up the subsidiary’s IT staff. Viewed in this light, his behavior makes perfect sense: By engineering a situation in which he couldn’t fail to successfully intrude, he can claim to have revealed serious security deficiencies. And because he works at corporate headquarters, he figured he could use his superior access to decision-makers to paint any objections to his behavior by the subsidiary’s IT staff as nothing more than a defensive attempt to cover up incompetence.

I’m speculating, but at least this explains this odd event. Viewed from any other perspective, the behavior of this strange visitor from another city would be incomprehensible.

I take that back. There is one other perspective that would explain it.

Maybe he’s just stupid.

Comments