Project delays are one of the most common pitfalls that can keep even the best project managers, web designers and web developers from launching a web site online. Delays can come in all shapes and sizes but they have one thing in common. They can run any project into the ground and keep designers and developers from getting paid. In our nine+ years of experience building and launching web sites and web applications, we’ve encountered delays in just about every form they can take. Most delays are resolvable but some leave us scratching our heads, wondering what went wrong. Below are some of these stories and some project management tips on how to resolve delays by creating a project plan.
Ironically, the client is usually the one responsible for most delays. The same client, who in the beginning, is putting on the heat to get the project started, is pushing for crazy deadlines and an early launch date. As the project gains momentum and the time comes to start plugging in copy or adding photography, it can become incredibly difficult to pin down the client on such deliverables. Obtaining final copy is usually the biggest hurdle to overcome with any client, but other common delays occur delivering design feedback, data for web applications, and final photography. These delays are usually caused by a committee who is in charge of overseeing web site development on behalf of the client; and it only takes one person to hold up a committee. We typically include a clause in our contract to address such delays, but we also do everything we can to help resolve them. There is no right or wrong answer on how to hold a client’s hand through web design and development planning. You just have to assess each delay as it happens and find creative ways to help the client complete their deliverables in a timely manner.
As is the nature of web site design and development, the client may not have a clear picture until they see their project begin to take shape. It is normal for the web site requirements to change during development, but on a small scale. When requirements and features begin to appear from nowhere, you’ve officially entered a project phase known as “scope creep.” This occurs when clients insist on adding features to the web site that are outside the budget or the original scope. If not handled properly, these requests will not only result in the project going over budget, they will delay the project. There are several ways to deal with scope creep, the worst being not to deal with it at all. We recommend adding clauses to your contract to address new features. Another way of dealing with such requests, as we’ve often done, is to advise your client to postpone such additions until after the web site has launched. At that time you will have a better handle on how much budget is left and can enter into a second contract. Ultimately, getting the web site launched on time and on budget is in the clients best interest. When framed in this context, it is easier to fend off scope creep.
Just One More Revision…
Not all delays are the fault of the client. Web designers and developers, at least the ones at Pelago, are notorious for tweaking and tuning a web site until it’s absolutely perfect. As designers we find ourselves changing colors and adjusting type as the deadline looms, engaged in a losing battle with perfection. As developers there is always another algorithm that will make the site run faster or a design pattern that will make the code cleaner. For both designers and developers the last minute tuning items usually fall in the realm of improvements that the client will never notice. When designing and building web sites and web applications we have to remind ourselves that the web is a fluid medium. The goal is to launch something compelling, not perfect, and to follow up with adjustments post launch. There will always be some tuning required on the client’s behalf after the initial launch. It’s best to go along with the nature of the web as a process and as a medium and change with it.
The AWOL Client
The client who goes missing in the middle of a project is a more rare occurrence, but it does happen. They may not go missing in a physical sense, but clients will check out mentally from their project. This can happen during various phases of a project and will always stops the project cold in its tracks. Sometimes the client will get back in touch with us a few years later, excited and ready to get their web site launched. Other times we never hear from them again. We actually have fully-built web sites still lingering on our development servers from two years ago, waiting to be launched. When clients come crawling back out of the woodwork it can be disruptive to your workflow because you’ve already moved on and are likely in the middle of designing and developing other projects. Again, it helps to cover this scenario in your contract, usually by including an expiration date on your response time. This way, the client understands that if they do come back later, they will have to secede their priority to your current clients.
The final payment of your contract is the last piece of leverage you have should something go wrong, so it is highly advisable not to launch a web site until that payment is received. Clients may have a difficult time understanding this and you may want to make an exception for clients with whom you have a longer history. But the truth is that once you launch their web site or web application, the client has far less incentive to pay you on time. It is usually not the client’s intention to skip payment, but it does happen for unforeseen reasons. Often times the person writing the checks is on a different schedule and simply gets you the check a month or two later. However, in this economy it is not uncommon for a company to go under before they can pay you. Whatever the reason a client may have for not paying you on time, it’s their problem and not yours. By completing their web site on time and on budget you have fulfilled your end of the contract. Now it is time for the client to fulfill their end by fully compensating you for your work. It’s always easier to be the nice guy and give the client some leeway, but when running a small web design and development business, being the nice guy can put you out of business.