All Posts in Industry Commentary

|In: Industry Commentary|Last Updated:

Travel is supposed to broaden the mind. Regrettably, after more than 21 years of writing this column, my mental ruts seem to resist travel’s broadening impacts: Everything I see turns into guidance for running businesses, IT organizations, and all points in between.

And so, following a couple of weeks touring in Rome and exploring bits and pieces of Sicily …

> The Romans built the Colosseum in eight years, with no project management or CAD software to help them. It’s about 2,000 years old and still standing. That should worry us.

> The Colosseum’s construction depended on two innovations: concrete, and interchangeable parts built to standard specifications. If any Roman architects, artists, or engineers suffered from change resistance, those who embraced the innovations apparently drowned them out.

> The Colosseum’s standard program was executions in the morning, followed by slaughtering exotic animals, followed in turn by gladiators trying to hack each other to bits.

I think this means we have to give the Romans credit for inventing standing meetings with standard agendas.

It also suggests they were early victims of the consequences of bad metrics. Because every day started out with executions, the Roman courts had to convict enough suspects of capital crimes to fill out the program, whether or not a sufficient number of capital crimes had been committed. I presume the parallels are obvious.

In any event, combining the morning executions and gladiators who got the old thumbs down, a million corpses exited the Colosseum’s fabled arches during the years it was in session, although the pace slowed a bit when Rome became Christian and did away with the gladiators.

I guess that was progress. Speaking of which, for the Roman Empire, conquest was what you did if you could. Now, it’s frowned upon. That’s progress, too, I guess.

> While walking through the Pantheon our guide pointed out a row of headless statues. They weren’t, he assured us, early examples of Dr. Guillotine’s work products.

It was due to Roman parsimony. Coming from a practical society, Roman artists figured out the average statue would greatly outlive the person it had been carved to honor. And so, they designed their statues to have replaceable heads.

In IT we call this “modular design.”

> We didn’t spend all of our time in the Colosseum (and Pantheon and Forum). We also toured the Vatican, where, in the Basilica, we saw evidence of St. Peter’s tribulations. As it happens, visitors rub St. Peter’s feet for luck. No, not St. Peter himself but a bronze statue thereof. Bad luck for St. Peter. After centuries of this his feet are being rubbed right off, toes first.

I’m pretty sure we in IT have parallels to muster. If not, elsewhere in technology land I’ve read we’re running out of helium, one birthday balloon at a time.

Sicily has been more relaxing, at least from the perspective of spotting IT parallels. I’m hopeful this might mean I haven’t completely lost my ability to disconnect from the world of information technology. But there is Mount Etna, an awesome and awe-inspiring site.

> On the not-a-parallel-at-all front, shortly before its recent eruption, data integrated from a variety of sensors reported a 10 centimeter increase in the mountain’s elevation (about 3 inches if the metric system isn’t your bag; also about 3 inches if it is your bag only you don’t need me to handle the conversion for you).

Where was I? Oh, that’s right, 10 centimeters, and I hope you aren’t so blasé that you aren’t awed by our ability as a species to measure such things with such precision — a precision that allowed geologists to warn everyone potentially in harm’s way so they could get out of harm’s way.

> On the back-to-parallels front, Mount Etna doesn’t have just one crater, although the main caldera is enormous.

It has hundreds of craters. That’s because, when pressure increases and the old eruption paths are plugged, the magma doesn’t metaphorically say to itself, oh, gee, I guess I’d better calm down and head back to the earth’s mantle.

Nope. The pressure is there, the result of physical forces that can’t be eliminated and physical laws that can’t be repealed.

The result: The magma has to go somewhere, and where it goes is the path of least resistance, culminating in it pushing through the side of the mountain, resulting in a new eruption and new crater from which it spews out.

The business/IT parallel is, I trust, clear: Good luck trying to stamp out shadow IT, which is also the result of pressures that won’t go away just because you want them to.

It’s time for me to head back to the beach. The IT parallel? None.

Ahhhhhhh.

Comments

|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