Have you ever had to respond to an RFP (A Request for Proposal)? Chances are you have – if you are in any kind of business providing goods and services to institutions and business. I don’t know that I have ever met anyone on the receiving end of the RFP process who is fundamentally happy about it – and that give me pause. I’ve certainly been on boards and committees where we needed to solicit bids from vendors and the RFP seems like the best way to bring definition to the project, but I think there is a better way.
In my business we primarily receive RFPs for building new websites for institutions The RFPs generally lay out the scope of the project, the needs of the institution, some background, qualifications and requirements of the vendor, and that kind of thing. They can be extremely time-consuming to respond to as each and every element needs to be accurately addressed or your bid will be disqualified for being incomplete. The RFPs vary widely from institution to institution – some include forms that need to be filled out and attached, some require an exact structure to the document you are preparing. All of them have a major, fundamental flaw – they assume that the requestor knows more about what is being asked than the vendor.
This is a key point – the RFP frequently presents a set of requirements that is so well thought-through from the client end that there is very little, if any, room for the vendor to add value to the discussion. Actually, its not a discussion – its a request for a unilateral response. Oftentimes any conversation, questions, or discussion is strictly off the table in an effort to create a perfectly level playing field. And this is where the RFP fails completely for me.
Servers on the web 1995-2012
In my business we design and develop websites. The manner by which we provide this service has changed and continues to change at an accelerating rate as a consequence of the rate of change in the underlying technology of the web itself. The web itself is only a bit more than a decade old – go back to 1995 and that was about when things started to take off. In the intervening 15+ years the rate of change – the growth of the web and its dominance on so many aspects of our daily life and how the world works – has been phenomenal and continues to increase exponentially.
Ok, so we know all this. What’s the issue? As an example, the aviation industry took 70 years to traverse the distance between the Wright Brothers and the Concorde. If you were an organization that needed an airplane in say, 1950, you could have written a specification for the airplane based on your present understanding of aviation, submitted it to manufacturers, and received something in 2 years time that was quite relevant to the progress of the rest of the industry – perhaps engines had improved in that period, or wing design, but it would still be recognizable as a contemporary expression of aviation design. Of course this scenario (unless you are the US Govt.) doesn’t happen – you would go to the industry leaders in aviation and describe your requirements (“I need to transport 30 people 2,000 miles safely”) and you would listen to what they had to say.
Unlike airplanes, most people who use the web everyday feel they have a good understanding of what works and what doesn’t. They feel qualified to write the RFP based on their experience using their own existing sites, surfing the sites of their peers or competitors, and researching trends and technologies on the web. Generally the specification they write is a good one – it outlines clearly the requirements as a snapshot in time and this becomes the goal. Here’s the problem – in the time that it takes to create the requirement, draft it, submit the RFP to vendors, collect responses and engage in the project, the underlying systems that the requirements are based on have moved forward. The playing field has changed.
It knows where it is. Does your desktop?
The web is an organic entity. As a dynamic meme, it evolves and mutates rapidly. For those of us who are engaged in that evolution on a daily basis, it’s exciting – challenges you had yesterday are easily solved tomorrow. New tools, technologies, code and whole environments spring up every day. Back 5-6 years ago, we struggled to write original code to solve challenges on a daily basis – today we rarely need to do fundamental programming because the solution is “off the shelf” somewhere out there for us to download and plug-in. My mantra as a web developer is to always assume that someone else has already built what I am seeking, and done a good job of it – my job is to find that tool and bring it to the task. The rise of open-source software and the whole underlying ethos of open-source has created a situation where I can participate in an ever-evolving, ever-updating core architecture (like wordpress) for the sites I build. Imagine if you will, an office building that is constantly changing, twisting, morphing, adding, subtracting and growing as you live in it – that’s what the web is today and what open-source creates. One aspect of participating in this world – even as an expert – is humility. Neither I nor anyone else really knows where it is going to go. Take the rise of the mobile device – as web designers we weren’t even thinking about delivery to phones 6 years ago – now it is a requirement to consider, and I suspect it will become the primary delivery modality in the next 3 years. What a change that is! A complete re-articulation of the whole user experience, interface, design and technologies. I know I am not the only person frustrated by the fact that my state-of-the-art desktop iMac is essentially “dumber” about its place in the physical world than my iphone – which knows where it is at all times and gives me data based on the geolocation.
So back to the RFP. In trying to create a level playing field, institutions are actually trying to freeze in time this rapidly developing architecture. Instead of saying “The website must do this and that” they should be asking “Who is our audience? What do they want to know? How can we best reach them today and tomorrow?” and they should sit down with vendors like myself and have a conversation. What I would dearly love to do would be to take the RFP, set it to the side as part of the overall definition of the project, and have a chance to tell the client my views on contemporary web design and the future of the medium. One conversation I have been having with clients in the last year goes like this:
“We can build the site you have defined in the RFP – it will take 3-6 months, cost $xx,000 and go through a traditional design process. Or we can launch a new site for you in a couple of weeks.”
This is a statement designed to create a conversation about the contemporary web, the design process that we prefer, and a completely new way of looking at the web as less of an edifice and more as an evolving, organic medium. The RFP process precludes this conversation – freezing the specification in time – and relegates my perspective to the boundaries where it can’t be heard.
I can understand the challenge that any organization faces in this process – how do you create conditions for success? You don’t want to hire the wrong vendor and be left with no budget and a site that doesn’t work. To that end I suggest that the client invest significantly more time in vetting the portfolio of the designers they are interviewing, and following up in detail with provided references, and stepping outside of those references and contacting people at all the organizations that the vendor has worked with in the past. I believe that good businesses are made on succesful long-term relationships involving trust and performance. If the vendor can’t display those qualities, they need to prove otherwise, in person, how they can guarantee the success of the project.
Let’s set aside the RFP and have a conversation. I think it will be fascinating.