I’ve spoken with many auctioneers recently who are at the beginning stages of a new technology project, usually a website redesign or new build of some kind. The questions everyone asks mostly revolve around the expectations they should have of the person or company being hired to build the website.
I’ve put together some content that I consider important to include in an RFP – request for proposal. It’s by no means exhaustive, and at least some parts of it will have to be changed for every application, but it’s a start to a baseline set of what I believe to be good standard practices when entering into a relationship with a service provider. For the purposes of this post, buyer is auctioneer, seller is service provider, employee is a backend user and user is frontend user. We’re going to assume that the buyer will provide a mock-up created by a designer. This mock-up would show exactly the layout and presentation requested by the buyer so that all the seller has to do is build the site using web standards. This draft assumes that your provider will install the website on a purchased or rented server controlled by the buyer. It assumes that the buyer has an email list system – I recommend phpList – and wants ownership of the auction calendar as opposed to using a third party’s auction calendar like that from Auction Services or AuctionZIP. I’m neither endorsing nor recommending against either of those popular auction website providers, I’m merely giving an example of a possible permutation. Perhaps a third party calendar is desired, as well as housing the site on the seller’s servers. Each auctioneer’s needs and desires are different. I’ve intentionally tried to stay away from most functional pieces of a good website and focus instead on the deliverables and legal requirements that should set the ground rules of a work for hire.
Website must include a calendar system that will facilitate easy creation and display of auction title, date, time, location and thumbnail images. Frontend layout is provided by attached mock-up. Backend must allow upload of images, auction event creation and modification and be available only over secure connection. Seller must install security certificate on buyer’s environment if it doesn’t already exist. Backend login must be employee-specific with ability to grant access to various resources to various employees.
Email subscription form must allow direct subscription ability and integration with a bulk email list management system such as phpList or Intersend.
Sales lead generation form must email leads to email address or addresses as specified by buyer or employees in the backend.
In order to anticipate future browser compatibility we require conformance to the following W3C standards.
- Markup must validate to the W3C’s XHTML 1.1 doctype at http://www.w3.org/TR/xhtml11/
- Style sheets must validate to the W3C’s CSS 2.1 format at http://www.w3.org/TR/CSS21/
- Javascript will never use browser detection but instead object detection to test for browser support of properties, arrays and methods.
- Site must not use tables for layout purposes. Tables will only be used for tabular data.
- Website must be tested to display similarly in current and the last major release of Internet Explorer, Mozilla Firefox, Apple Safari, Opera, Konqurer, and Google Chrome on stock installations of Microsoft Windows XP and Vista, Apple OS X and Ubuntu Linux where each browser is available on each operating system, as well as Internet Explorer 5 and 6.
Deliverables:
- All deliverables must be installed by seller on buyer’s environment.
- All deliverables will be considered “work made for hire” under U.S. Copyright law. Buyer will receive exclusive and complete copyrights to all work purchased. Any use of open-source content must be expressly defined and agreed to by buyer before implementation.
- No dependence on outside services is allowed. The website must function completely and independently of any third party site, service or server, unless expressly permitted by buyer.
- Seller will have no rights to use, reproduce or access any content, materials or other information stored on the website, including but not limited to form submission, customer information, email addresses, sales data and account records.
- Work must be original and not based on existing templates or previously-constructed components used by other customers of the seller.
Successful proposal will include the following components.
- Bid for construction of website using web standards with layout defined by provided mock-up and functionality defined above. This construction must include documentation and training sufficient for buyer to understand and operate site completely and effectively.
- Estimate of time to completion as well as financial implications of delays should they occur due to additional requests made by buyer or developmental hardships experienced by seller.
- Bid for continued ad-hoc support and maintenance on an hourly basis. Support must be provided by website creator if that person is different from seller.
- List of hours with guaranteed availability for support.
- List of five websites created by seller and contact information of website owners to serve as list of references.
Now, I realize that this draft is very strict. Some providers may balk completely, and some that don’t balk may intentionally price themselves out of the competition because, like using perfect English, using web standards is hard for some. Hopefully, however, this example may serve as a valuable starting point for someone looking to start from scratch. Compromises may be desired on certain parts, like XHTML validation, but an auctioneer should always retain the rights to your data (deliverable 4) and be sure that the provider will support the product after it’s built. Above all, be sure to have a very clearly-defined, counsel-approved contract that you can use to hold the service provider accountable should you believe that the work is incomplete or incorrect. Writing an example RFP was requested by many. These are some of my ideas. Do you have a must-have condition for the work that you hire done? Leave a comment so we can build on this document and add it to the resources page.
By Rob Spectre 25 November 2008 - 2:03 am
Here a few other tips from experiences both good and bad in web dev outsourcing:
1) Require a submitted portfolio with references. Five sites with traffic levels doing more than 40k monthly uniques you can verify with independent services like Compete or Quantcast with a good sprinkling of both technical and business contacts.
2) Always have a MSA, SoW, and SLA. The first is the Master Services Agreement (MSA) and contains the general terms of the contract with appropriate indemnification, jursdiction, and penalties for breach. Second is the Statement of Work (SoW) which serves as the gospel for the project; the full list of all deliverables, their delivery dates, and the delivery acceptance terms. Finally, the Service Level Agreement (SLA) contains the specific terms governing support. These three documents serve as the context for a successful relationship and ensure all the sticking points in a web dev project are clearly defined before it is engaged.
3) The right partner is more important than your tech organization’s favorite scripting language. Java, PHP, Python, and Flash all have standard best practices surrounding their implementation on the modern web and have examples of very high scale. More important than the language is the ability to deliver on time and provide consistent support after launch. A vendor insisting on Ruby on Rails with a 24/7 support line is infinitely more valuable than a vendor with the most elegant PHP yet written who is chronically unavailable on weekend / holiday outages.
4) The site must have comprehensive web analytics support. You can’t manage what you can’t measure. Whatever your analytics package of choice (Google, Omniture, WebTrends, awStats, etc), be sure the SoW includes a *full* integration beyond a little javascript cookie in the footer of each page. Before you launch, you must be able to verify full path segmentation, defined funnels for each of your goal pipelines, and being able to track each visitor’s conversion to both the lead *and* the sale.
By Rob Spectre 25 November 2008 - 7:03 am
Here a few other tips from experiences both good and bad in web dev outsourcing:
1) Require a submitted portfolio with references. Five sites with traffic levels doing more than 40k monthly uniques you can verify with independent services like Compete or Quantcast with a good sprinkling of both technical and business contacts.
2) Always have a MSA, SoW, and SLA. The first is the Master Services Agreement (MSA) and contains the general terms of the contract with appropriate indemnification, jursdiction, and penalties for breach. Second is the Statement of Work (SoW) which serves as the gospel for the project; the full list of all deliverables, their delivery dates, and the delivery acceptance terms. Finally, the Service Level Agreement (SLA) contains the specific terms governing support. These three documents serve as the context for a successful relationship and ensure all the sticking points in a web dev project are clearly defined before it is engaged.
3) The right partner is more important than your tech organization’s favorite scripting language. Java, PHP, Python, and Flash all have standard best practices surrounding their implementation on the modern web and have examples of very high scale. More important than the language is the ability to deliver on time and provide consistent support after launch. A vendor insisting on Ruby on Rails with a 24/7 support line is infinitely more valuable than a vendor with the most elegant PHP yet written who is chronically unavailable on weekend / holiday outages.
4) The site must have comprehensive web analytics support. You can’t manage what you can’t measure. Whatever your analytics package of choice (Google, Omniture, WebTrends, awStats, etc), be sure the SoW includes a *full* integration beyond a little javascript cookie in the footer of each page. Before you launch, you must be able to verify full path segmentation, defined funnels for each of your goal pipelines, and being able to track each visitor’s conversion to both the lead *and* the sale.
By Mario 13 March 2009 - 11:12 pm
Some excellent information…getting a group to partner with you even in a shared revenue JV is sometimes very beneficial as it entices the developer to stick around and maintain interest in the site.
By Mario 14 March 2009 - 1:12 am
Some excellent information…getting a group to partner with you even in a shared revenue JV is sometimes very beneficial as it entices the developer to stick around and maintain interest in the site.
By Mario 14 March 2009 - 6:12 am
Some excellent information…getting a group to partner with you even in a shared revenue JV is sometimes very beneficial as it entices the developer to stick around and maintain interest in the site.
By home builders website 9 March 2010 - 6:44 am
ok friend i like you comment, this is high thought concept, if any body flow they reach there destination….
By website builder 11 June 2010 - 9:10 pm
Thank you for sharing this very useful tips. The examples and images really help me understand your article.