“Oh, &$@%#, not another &%^ing RFP!”
Requests for Proposal (RFPs) and runners have two shared characteristics. First, you see a lot of both of them. Second, nobody ever seems to actually enjoy either one. (To the runners I just offended: how come I never see you smiling?)
Clearly, we’ve become a nation of masochists.
But how else than an RFP to evaluate vendors and products? Form Follows Function. Your method of evaluation depends on the circumstances.
You generally face one of these three situations: (1) you fully understand your requirements and the market, and you need equivalent information from all suppliers; (2) you understand your business, have a general understanding that technology can improve it, and want open-ended suggestions on how different products can help improve or transform your organization; or (3) you need to choose a product from a well-defined category and need something that’s good enough. These situations call for different approaches.
When You Know Your Requirements
Here’s when you should write an RFP. Quite a few books (including my own Telecommunications for Every Business, Bonus Books, Chicago, 1992) provide detailed guidance. Three principles are worth mentioning here.
First, specify your design goals, not the means by which vendors should address them. For example, if you need a fault-tolerant database server, don’t say you need a system with redundant power supplies, backplanes, CPUs, and network interface cards. If you do you’ll get what you asked for (in this case, a system that frequently fails from software bugs). Instead, ask how the vendor ensures fault tolerance. Then you’ll learn one of the vendors provides mirrored servers with shared RAID storage for a lower overall cost and higher reliability.
Second, don’t withhold information. If you’re a Windows/95 shop, for example, don’t pretend to be open to other solutions. Just say so in your RFP. You’ll save both your vendors and yourself a lot of work.
And finally, if any vendor offers to “help you write your RFP” just laugh gently, compliment them on their sense of humor, and go onto the next vendor (who will make the same offer). Don’t take offense – they’re just doing their job. Don’t take them up on the offer, either.
Looking for Help
Sometimes, you don’t know all the questions. You know you want to phase out your nationwide SNA network, for example, but have an open mind regarding the best replacement strategy.
You can hire a consultant to help you write an RFP, I suppose … or, you can hold extensive conversations with a variety of vendors to learn what each has to offer. By doing so you’ll get a broader look at the market, and you’ll also get a wonderful education into the strengths (from each vendor) and weaknesses (from their competitors) of each approach currently selling.
In this example, you may find yourself talking to two frame relay vendors, a Transparent LAN Service provider, AT&T and Novell regarding their Netware Connect Services, and an independent systems integrator. You’ll benefit from an unstructured dialog in which each vendor can assess your situation in depth and describe a scenario of how their approach will work for your company.
When Good Enough Will Do
Let’s imagine you’ve been asked to select a new standard Ethernet network interface card (NIC). You could write an RFP or hold extensive conversations with sales reps, but why? Read a few reviews, ask a few basic questions, insist on a few evaluation units (to make sure they work and to learn about any installation glitches) and pick one. Flip a coin if you have to. It’s a low impact decision.
Oh yeah, just one more thing: very few of us make decisions based on logic. Salespeople know we make emotional decisions, then construct logical arguments to justify them. Don’t fall into this trap: recognize your emotional preference up front, figure out how much weight you should give it, and keep it from dominating your process.
All Posts in Leadership
Welcome to the IS Survival Guide (first appeared in InfoWorld)
It’s re-run time. This week’s presents the three principles IT managers (and, for that matter, non-IT managers) need most if they’re going to do their jobs well.
It is, by the way, the first “IS Survival Guide” ever published. It appeared in InfoWorld January 8, 1996, and I’m delighted to report that even after twenty years, if you’re going to limit things to just three management principles I can’t come up with a better list.
– Bob
Welcome to the IS Survival Guide, the column that asks, “How can anyone succeed at such a bizarre job?”
You’re responsible for technology traditional IS executives still wish would just go away. You manage the most eccentric employees in the company. You deal with vendors who constantly use terms like partnership and value-added. And while this all goes on, you end up on five committees to advance the management long-term-direction-of-the-year.
Think of this column as management with an edge.
You won’t find any 7-S Paradigms here. No facile graphs that encapsulate a whole industry into four quadrants. No seductive alternatives to the hard work of being an effective manager. No panaceas.
Here’s what you will get: Suggestions and ideas that come from years of real management and executive experience managing technology; conversations with other managers and executives; discussions and debates with consultants, writers and academics; and just plain reading and thinking.
A lot comes from real-world experience of what works well. A lot more comes from real-world experience of what didn’t work so well.
Let’s get started.
The Three Principles of Management
A lot of management comes down to just three basic principles. Understanding them is easy. Applying them is harder. They are:
- Customers — paying, external customers — define value.
- Form follows function.
- Everyone involved must be aligned to a common purpose.
When things go seriously wrong, you usually find something that violates one or more of these simple propositions.
Future columns will often touch back to these principles. Some will cover them in depth. Here are the Cliff’s Notes.
Customers
Customers define value, by exchanging something else they value — money — for your product or service. (A commonly misused term, value-added, is simply the difference between the cost of raw materials and revenue from goods sold.)
Paying customers define value. Internal customers (a nasty oxymoron) do not define value (or quality, which is just one component of value). How can they, when they don’t pay.
The usual definition — anybody whose inbox receives the contents of your outbox — reveals the core fallacy. Customers make buying decisions. And unless your internal customers establish your capital and operating budget, they aren’t the people who make the buying decisions for your products and services.
Always find a way to link your priorities and plans to paying, external customers, or at least to the hot-buttons of your company’s top executives.
Form Follows Function
Well this should be obvious, and it is — when engineers design machines. Designers of organizations fail miserably at it. Compensation plans frequently encourage employee behavior that’s at odds with the organization’s goals. Accounting techniques encourage obstructive bureaucracies and political infighting. When we measure performance at all, we measure what’s easy to measure, not what we care about.
Usually, violations of the FFF principle stem from asking the wrong question. For example, “Should our analysts have an incentive plan?” The right questions: “How do we want our analysts to behave? How do we measure that behavior? How should we reflect its value in our compensation plan?”
Aligning Everyone to a Common Purpose
Well of course, but we have internal customers. Our job is to satisfy them. Somebody else deals with paying customers.
Unless every part of your organization embraces the same externally focused goal, your company’s products and services will lack focus and cohesion. That includes you. Here’s a test: what’s your industry? Information Systems? Or the marketplace your company participates in?
Request for Submissions
I’m collecting examples of ManagementSpeak (ManagementSpeak: “I’m not saying no, but I’m certainly not saying yes.” Translation: “No.”). I’ll publish the winners (and their definitions) in future columns.
Welcome to the IS Survival Guide. I hope you find it valuable.