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.
Deliverables:
Successful proposal will include the following components.
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.
Learn about an easy yet little-known feature of a popular ad blocker that lets you…
With attacks on our privacy coming from every direction, it's tough to know where to…
I'm fairly convinced the internet has become a cesspool of advertising and coercive content meant…
Learn about the iSeries educational collection from NAA, watch the last episode and register for…
In my review of the Samsung Galaxy Note8 on Verizon, I found a beautiful device…
You should always use a VPN whenever you're connected to a wireless network that's not…
View Comments
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.
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.
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.
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.
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.
ok friend i like you comment, this is high thought concept, if any body flow they reach there destination....
Thank you for sharing this very useful tips. The examples and images really help me understand your article.