TrendWatch Blog
Thinking beyond the RFP
03-Aug-2009 --
There's a saying in Hollywood, made famous by screenwriter William Goldman, that "nobody knows anything." It's a lament that sometimes seems to apply to the IT world as well. There are counterexamples for every rule, and every time you think you know something, circumstances find a way to humble you. Pretty soon you realize it's impossible to make any generalizations, except that you can make no generalizations.
Consider the RFP process. Mind you, I'm no expert on Requests for Proposals (or tenders, as they're also known), but after you read enough of them, it's clear that nobody else is, either. Every RFP is different, and almost all are seriously flawed in one way or another. No one seems to know how to write a "good" RFP, perhaps because "nobody knows anything."
And yet, most of us cling to the Quixotic belief that the RFP process is essential. Going through the exercise of creating an RFP (or better still, an RFI) is worthwhile, one could argue, because it helps crystallize thinking around the business drivers behind a project. At the same time, it stimulates dialog on how operational needs intersect with the sundry technological (and other) considerations that go into the selection of products and vendors. Even if you never show your RFP to a vendor, chances are you'll have learned a great deal just by going through the exercise of creating it.
But banish the notion that you're going to create the "perfect tender." Your RFP will be flawed. The point isn't that it's flawed but that you learned something while creating it.
Before the RFP gets written there's usually a needs-analysis of some kind. Once "needs" (which are often actually wants) are assessed, they ultimately get translated to requirements, which in turn find their way into the tender, or RFP. This is already a treacherous path. Needs assessment is a tricky thing in and of itself, but even assuming you can get a good handle on your needs, you should be clear on the fact that needs aren't necessarily the same thing as selection criteria. After all, the point of the RFP isn't to identify products or vendors that can meet a given set of feature requirements, but the one(s) that best address your business problems.
Even before you start down the slippery path of needs assessment, though, you should take the time to create a glossary. Until everyone agrees on vocabulary, it's impossible to have a meaningful dialog. That sounds obvious, doesn't it? But think how many terms there are in this business that mean different things to different people:SOA, roles (versus groups), security, integration, "content reuse," template, compliance, workflow, Web Services, "REST API," reporting (which many people seem to think means logging), scalability, performance. Minefields all.
Not long ago, I was reading a vendor's response to an RFP (for a WCMsystem) in which some 200 or so requirements had been enumerated by the customer. The vendor's response to the majority of the 200 challenges was "Our solution natively provides this capability." That phrase occurred over and over. (Someone did an awful lot of cut and paste.)
How do you avoid this type of situation? Well, for starters, don't phrase things along the lines of "Do you support XYZ functionality?" unless you want to hear (over and over again) the Obama campaign slogan "Yes we can."
Likewise, don't ask "How will you be able to handle XYZ?" unless you're willing to tolerate answers like "Our standard user interface allows a user to do this" or "our application programming interface allows the product to be easily extended so as to accomplish this."
Instead, write a user narrative or concrete scenario for every one of your key requirements, and demand a narrative answer in response. For example, rather than ask whether a product natively supports delegation of authority in workflows, compose a concrete user narrative. "Cathy, the Managing Editor, has the necessary rights to designate authors for stories and reassign stories from one author to another in her department. Cathy will be traveling frequently on business, and in her absence she wants her assistant, Bill, who does not have Managing Editor rights, to be able to assign and reassign stories in her stead. Describe the steps that Cathy would need to carry out before she goes on vacation, including any GUI features Cathy would use, to delegate the necessary authority to Bill for a period of N days. Describe any administrator or developer interventions that might be necessary. Describe what actions Bill will have to take in order to act as Cathy's proxy."
It may turn out that all the vendors on your short list say they can support this scenario. But the details could be quite telling. Vendor A might simply say "Cathy should give her log-on credentials to Bill until she returns from vacation." Vendor B might say "The administrator can temporarily assign Managing Editor rights to Bill." Vendor C, on the other hand, might say: "In Cathy's preferences tab, there's an 'Assign Proxy...' button that brings up a dropdown menu populated with the names of people in Cathy's department who have a privilege level equal to or higher than Cathy's. There's also a special field where Cathy can override the dropdown list by manually entering the user name of any person in her department. And there's a date-picker control that lets Cathy specify a range of effective dates through a point-and-click gesture."
For most cusotmers, Vendor C has a much more compelling answer to this use-case than Vendors A or B. But the point is, you'll never get this kind of information if you merely submit a list of "checkbox" requirements that invite short, meaningless answers.
Of course, writing user narratives takes time. You probably won't have time or resources to write hundreds of them. But that's good. Most RFPs are grossly over-specified. Reducing 200 or 300 "requirements" to 40 or 50 well-considered narratives (covering only the most important use cases) will bring clarity to the selection process by putting the focus on real-world user needs and business priorities. Also consider that user narratives can become acceptance tests later on, if you write them with that in mind.
And by the way, don't lose sight of the fact that when you're selecting a product that's mission critical to your business, your vendor becomes (in essence) a new business partner. Thus the RFP becomes a kind of interviewing tool. Standard interview techniques apply. Which means anything goes. You're perfectly free to insert brain-teasers in an RFP -- questions for which there's a "trick answer," or no answer. Likewise, feel free to pose an open-ended question (an open-ended "requirement") and see what you get in reply. "If I migrate your software to a more powerful machine and see server-response times deteriorate, what are some likely causes and how will I proceed to troubleshoot it?" The vagueness of this kind of question practically demands that the respondent ask questions back. You'll learn a great deal from those questions -- and the dialog that ensues.
One final thought. After your project has finally rolled out (months after the selection process), bring your stakeholders together again and do a post-mortem on the entire selection process, including the RFP itself. Ask: How much value did the RFP end up bringing to the process? Was the RFP you finally produced appropriate (in size, scope, and quality) to the task at hand? Could other groups in your organization use your RFP as a starting point for their own RFPs? (Is it resuable, in other words.) Were the user narratives useful for acceptance testing? And of course: What would you do differently, if you had it to do over again?
With any luck, you might be able to prove William Goldman wrong.
(Note: A different version of this post originally appeared at E-TechnologyManagement.com.)
- Submitted by: Kas Thomas, Analyst - Twitter: kasthomas
Join the conversation
Get a Free Sample
Wondering about CMS Watch research? Sign up to receive free samples of any of our products.