Skip to main content

T is for time.

Internally at my agency we now have a running joke – the two-year web site. This is mostly based on our experiences of the past six months.

Since mid-2011 I’d estimate we acquired ~six new clients who were escaping bad situations with other agencies taking excessive amounts of time to complete website development projects. And in the cases we experienced, the timeline always seemed to be around two years.

The conversation kind of went like this:

Client: “I’d like to see if you could help us out.”

Voltage: “Sure, tell me what’s going on and I’ll see what we can do.”

Client: “Well, we hired this agency to build our website and it’s been in development for about two years now, is XX months past due, and $XXk over budget.”

Voltage: “I’ve heard this story before.”

On the upside for my agency, a pretty low bar has been set. On the downside for my agency, we are now starting in a position of distrust and we’re immediately on the defensive.

My point is this … I understand. I understand where the client is coming from: why they’re distrustful, why they’re hesitant to start over, and why they’re considering just giving up on the project altogether. And while I thank the other agency for practically handing me business, I’d like to give them the “what-for” for making my job harder.

So why does this happen? In our experience, it seems to follow a standard formula. Here are the things to keep an eye on when starting any website project:

  1. RFP:
    Many companies initiate a web development project by issuing an RFP to agencies. They collect estimates form those agencies and then select an agency for the project. Make sure your RFP is written in a manner that will garner apples-to-apples pricing and deliverables from your potential vendors. Too many open ended requests (etcetera and miscellaneous items) and little specifics leave room for speculation and great variation in deliverables and pricing. In the case of some larger projects it’s well worth the time and money to hire a technology consultant to help with this process.
  2. Requirements:
    Whomever your vendor may be, make sure they plan to detail the requirements of your website project in a written format. If they don’t plan to do this, run. These requirements are essential and should be based on your goals for the site. By their very nature website requirements will be highly technical, so if you’re not technically savvy then make sure to ask lots of questions. If your vendor can’t explain the document, then run. If they can and you still don’t understand, then seek the assistance of a third-party IT professional who can check the validity of the document.
  3. Revisions and Approvals:
    Make sure you understand how revisions and approvals will be managed. Most agencies allow for two rounds of reviews and revisions on project deliverables – it’s an industry standard. And if you go beyond two rounds, you’re looking at change orders. This responsibility falls on both parties: a) the agency is responsible for communicating to the client the phase of revision being reviewed, and b) the client is responsible for making sure all decision makers provide input before submitting revisions to the agency. Change orders are not unheard of, and certainly not the death of a project, but run-away change orders can sour a relationship.
  4. Realism:
    You’ve probably heard the term “You can have it cheap, fast, or good. Pick two.” This truism never fails in the website development business. For example, good and fast work will be expensive, and fast and cheap work will be bad. Unfortunately, some agencies will tell you what you want to hear to get your project (it’s hard not to). If your website project is large and complex, then be prepared for more money, a longer timeline, and more in-depth discussions with your agency – it will pay off in the long run. And if that’s not possible and you need something cheaper and in short order, then consider a phased approach where you launch a minimum viable product and phase-out the less essential items for post-launch.
  5. Vendor Lock-In:
    Beware of systems that you don’t own, must license, can’t access or that beholden you to the agency that developed them. This is not always a bad situation, especially if you have an a-typical need that requires the application of specialized technology like vast e-commerce installations or CRMs (and even then, many open sourced solutions can be modified to fit your needs). But if you’re building a primarily content-driven website that sells products in a standardized fashion, accepts donations or allows users to register for an event (to name a few), then you probably don’t need a proprietary system. Some estimates state up to 80% of websites are powered by open source¬†technology¬†systems or are hard-coded in a standard programming language like PHP or ASP. Chances are you fall into this category.

In the end, consideration of the above will go a long way in keeping your project on time, on budget and you and your technology partner on speaking terms.

Sharing is caring.