Skip to content Skip to navigation

Site Retired

As of May, 2022, this website is no longer updated and has been replaced with a static copy.

Expository Sketch is the New RFP

At SWS, I have developed an improved method for vendor selection over “traditional RFP”, but it can take a little explaining—to clients and vendors alike—as to why it’s better, and why its worth the time investment.

Why change?  To be honest, a couple of years ago we were pretty happy with the traditional Request For Proposal process, and didn’t feel the need to change much of anything. It was a useful tool to articulate a specification for web development services, publicize this opportunity, and review the resulting proposals based on their relative merits.  It seemed straightforward and fair.

Problems became apparent when I started listening to industry leaders whom we at Stanford regard as partners in building the future of our web platforms.  They hate RFPs. With a passion. Publicly.

So, I started talking with some of them about what a post-RFP world would look like in really specific, nitty-gritty ways. If we were to replace the RFP with something, what would that thing be? I’ve spent the last year and half on this problem, and have formulated what appears to be a viable alternative. And I’m going to share it with you nice people because Stanford supports open source, open access, and information wants to be free.

Defining the Alternative

On this post-RFP frontier, I begin with a document that I call an Expository Sketch, which is not actually a replacement for RFP by itself, rather it is the first step (of many) in a rigorous and thoughtful process that can take 4-6 weeks. The premise of an Expository Sketch is that we should not start with a specification, rather a conversation.

RFP represents document-to-document communication:  Here is the specification that we, the client organization, have produced. How much will it cost to procure these services from your company to build this exact thing?

But what if our assumptions are not completely valid? What if we can’t see around all the corners, or see new possibilities of connecting with new methodologies or technologies? A pre-emptive spec locks you into your current best guess ... and the web changes faster than that.

Instead, the Expository Sketch is an invitation to open a dialog about the parameters of a  project. Though it may contain something that looks like a specification (and could be used as such) its purpose is to define how we on the client side are thinking about the problem space, and to invite commentary from the vendor side. To underscore this difference, any proposed build-out in an Expository Sketch should come with a preamble:

"The following is not intended as a prescriptive specification, rather one plausible path to solve for this problem space, to convey a sense of what we are thinking in terms of scope. We recognize that Drupal developers and designers are creative professionals, and we look forward to your input and interpretation. We have no intention of tying your hands. The following are suggestions, a baseline."

By setting the tone in this way, you open the door for surprising results. If you start with, and insist on, a hard spec at the beginning, that's likely the best you will get. By being open to the ideas of others, and stating the problem you want to solve rather than telling the vendor how to solve it for you, you may find that the outcome can be far better than you imagined.

The final attribute of the Expository Sketch worth mentioning is its focus on exposition. At best it will call out the constraints and potential gotchas of a project as we can detect at the outset. (It’s surprising just how many of these are detectable in the beginning if you know what to look for.)  Even if it might resemble an RFP, the Expository Sketch differs in focus: instead of calling out exactly what we expect from the developer (that comes later, with the Statement of Work), the Sketch embraces collaboration and focuses on exposing all parameters as openly as possible, for the benefit of everyone, client and vendor alike.

To some clients this approach will sound risky —how can we start a project without stating specific requirements that the vendor must fulfill? Actually, you still get to do that at contract time, what makes the Expository Sketch different is that we don't start with hard requirements.

No Spec Work

Just to be clear, I take a hard stand against spec work and will never ask for it. (No, not that spec, the other spec: speculative work.) No project I am associated with will ask for up front work to qualify a vendor, and the idea exchange that the Expository Sketch engenders has nothing to do with surreptitiously mining ideas from vendors who never had a shot a winning a contract. There is a special circle of hell for those people. Spec work, and its abuse, is one of the reasons why agencies have soured on RFPs. Agencies can spend 40-100 hours or more (that's real money folks!) writing proposals, and to ask them to do so only to acquire free work from them is unethical.

At Stanford Web Services I do a whole lot of homework on vendors to qualify them for work at Stanford before ever inviting them to bid on a project.  We do not broadcast RFPs (unless the law requires it, in the case of government contracts). Instead I send a personal invitation to bid to each shop, and I start with a very short list. Stanford requires 3 competing bids, but I try to keep the list as short as possible (I have a version of the Hippocratic Oath: "waste no one's time.") If an agency is invited to submit a proposal for work at Stanford, they have my personal guarantee that they have a fair chance to win.