Most folks in non-profits that I’ve met think that contracting a vendor to create a website is like buying a car. The RFP is their list of things they want in the car and the vendor’s job is to find the right car on their lot. If there’s nothing on their lot, you just go to the next one. In reality, choosing a technology vendor is a lot more like dating then it is shopping. In this installment of Breaking the Cycle of Doom I’m going to introduce some of the high-level concepts of agile programming, agile billing and the process of finding the right vendor.
The first date – leave the RFP at home
Scenario – you show up to your first date with someone and the first thing they do is pull out a list. You must be able to deliver 3 kids, 2 of them boys, get along smashingly with the in-laws, bring home at least $80K per year and this has to start happening in 3 weeks. Your date needs a written response detailing how you will make this happen, and a list of references of people for whom you have made this happen in the past. They need an answer by Friday at the latest. That’s what it feels like as a developer when I get a 70-page Request for Proposal from an organization I’ve never worked with, from people I’ve never met.
RFP’s take a long time to write, read and respond to and in most cases are completely unnecessary. Instead, I suggest going on an in-person, 1-hour first date with each vendor you are considering. If in-person meetings are not possible because of distance, you may want to consider looking for someone closer to home. Consider the fact that many of the biggest web sites that have shaped the information age came from the same 12-mile radius of Silicon Valley. Long-distance relationships are much harder to maintain in your personal life, and your organization relationships are no different.
On your first date, the vendor really only needs to know:
- What’s the real goal? is it to find new donors? Treat existing donors better? Enhance your services?
- Where’s the pain? What do you do now that you wish you didn’t have to? How long do those things actually take? Can you even do what you need to without your website?
Keep in mind that if you had all of the answers, you would be able to hire the programmers yourself but you don’t – you need help. Your RFP gives vendors the false sense that you know what you are talking about and closes off communication early on. You have a goal and you are looking for someone to help you achieve it withing your budget and you need to know when that can happen. Articulate what you want early on, in person, but leave the writing for later.
Like any first date, honesty and good listening skills are key. Is the vendor listening to you? Coming up with suggestions? Raising red flags? Can they talk about money (they should be able to tell the difference between a ~$10K site and a ~$200K site)? Do they come up with helpful suggestions on other ways to accomplish the same thing? Can they give you detailed timelines for a few small features? Nobody will be able to tell you with certainty how long or how much things will cost, but honest, knowledgeable vendors will be able to give you ballpark figures for specific types of functionality immediately.
I recently spoke with salesperson for a web host who suggested that I go to another hosting company because he thought that it would be a better fit for both of us. He flat out told me to go to the competition rather than just taking my money knowing it wouldn’t be ideal. In doing so he built my trust, and now I use their hosting company for several other clients for whom it’s a great fit. Vendors who are not willing to speak frankly about other options are likely hiding big flaws.
Going steady – one step at a time
Scenario – after a few dates you realize that you’re a great match. It’s time to go steady. Your date immediately slaps down a prenup the size of war and peace that details every date you’ll go on, what you’ll eat and who will pay. They ask you to review it and sign it, but there is a deadline. You look into each other’s eyes with puppy love and they promise it’s just a formality but you can’t escape that nagging feeling that you forgot something. You’ve already been asked to step into a point of no-return, but you barely know each other. As odd as that sounds for dating, that’s exactly what happens when you sign one of those massive scope-of-work (SOW) documents (usually after several weeks of revising the document itself). Even just the name, SOW, sounds awful.
In relationships I’ve always been told to take things one step at a time, and in programming it’s no different. In programming a step is called an “iteration” – a short period of time in which a small, complete set of working functionality is added. Let’s say there is a big vendor and they are going to design and build your site. The first iteration might be just to design it, and turn over the Photoshop files. They have a massive content management system? Great – the next iteration is to put your new designs into their CMS and transfer your content.. Every week, or few weeks, your vendor should be providing you with something that you can use immediately or take away – and you should pay them for what they do.
Most vendors won’t structure their contracts like this, which is troublesome. If that’s the case, maybe you’re not such a good match. After all, if they are confident that they can deliver, they shouldn’t be at all nervous about taking smaller chunks at the beginning. You’ll get to learn how they bill, and they’ll get to learn how you pay (let’s be honest – you’re a non-profit, sometimes bills are paid late).
This kind of iterative programming that puts relationships before contracts is called Agile Programming, sometimes called Extreme Programming. You can learn more about it at http://en.wikipedia.org/wiki/Agile_software_development
Breaking up – keep your apartment
Scenario – You’ve lost that lovin’ feeling. No one is really happy – you’ve changed your mind a million times, they want to know “where you are in the relationship” and you just want to chill and take it slow. You both decide that it’s time to move on. 2 weeks later you get a bill for all of the times you didn’t pay your half at the restaurant, and there’s an early-break-up fee that wasn’t in the prenup, not to mention the fact that the credit card is in their name and you have moved into their apartment. Now you not only need to deal with starting to date again, but you also have to find a new place and a new bank. Sound ugly? That’s what happens when these 134-page contracts end prematurely – it’s enough to make you want to just see it through even though it’s clearly not working out anymore – and that’s exactly what many non-profits do.
Contrast that with a more iterative approach where you have been paying all along for working features. Contracts are short and specific, and you can adapt them as your organization changes over time. If you get a massive spike in donors you can change priorities and focus on scaling first, instead of real-time event management software synchronization. When it’s time to go you are in a better place to have constructive conversations with the real human beings that work for the vendor to figure out an amicable way to change services.
As utopian as it sounds, I’ve seen this happen several times, but rarely in non-profits. You can’t function in a relationship if you are constantly thinking about what’s going to happen when you break up, but you can certainly have honest conversations about the consequences of certain decisions should you break up. The same is true for technology partnerships. If you split from a vendor prematurely you will both likely lost money. The bigger the upfront contract, the more is at stake and the more likely you are going to have a contentious and ugly break up.
In addition, the more you depend on them for every aspect of the site the easier it is for you at first, but the harder it is to ever make a change. Let’s say they use Verisign as their payment gateway, but Authorize.NET just became a big donor of your organization and said they’d give you service for a huge discount. Having the merchant account coupled with the hosting fee, coupled with the programming work makes it difficult or sometimes impossible, to take advantage of the ever-changing technology landscape.
Summary
- Ditch the RFP – meet in person, consider this a partnership from the beginning
- Ditch the bulky SOWs – instead create short, specific contracts that culminate in working software every week or two weeks
- Don’t put your eggs in one basket – keeping things separate helps you move update small parts of your site without lots of dependencies
Jeff,
As a (small-time) contractor I would love to be able to write contracts the way you recommend, but I have enough trouble writing a single contract, let alone writing one every few weeks – do you have anything you can recommend to make this process easier?