Why do website projects go off the rails so often?

More often than not, when we speak to someone who has just had a new or refreshed website finished, they are not that happy with it. They’re often not happy with whoever made it. And in our experience, the more complex the website’s functionality is the more likely this is to be true.

It’s true that there are many website developers, planners, project managers etc who might not be great for that particular project, or even out of their depth/incompetent in general.

However we don’t think this is the biggest contributor to the disconnect. Instead it’s:

• Lack of clarity in communication. Most specs are not precise enough (see chapter 8) and the ones that are (usually for larger organisations) may still be contradictory, contain wrong decisions or even destroy your business if implemented.
• It’s almost never the case that the requirements by the end of the project are the same as when the project starts.
• Clients who need a website often drastically underestimate how much time/work is involved on their end, mainly in supplying content and other decisions. As a result I’ve seen website projects where for over 80% of the project time everything was with the client.
• As a result of the above, it’s notoriously difficult for anyone to predict the time and cost a website might need. This is summarised in Hofstadter’s Law which even if not written about website builds explains it perfectly: Hofstadter’s Law: It always takes longer than you expect, even when you take into account Hofstadter’s Law.

There are entire branches of industry dedicated to trying to overcome this for website development but it’s by no means a problem that any person in the world (no matter their experience) knows how to solve in the general case.

This doesn’t mean that you should give up expecting things to go well, or that it’s never the creator’s fault. But if you keep this in mind throughout the process, it will reduce the chances of things getting out of hand.

Other items to keep in mind as a client in a website build/refresh project

• Unless you’re a developer it may be very hard for you to know which features are the most complex and time-consuming to implement. A good spec will therefore list features by priority: which ones are must-haves? Which one are ok to have after launch? A good developer will then provide feedback or push back against things that are a lot of effort for little value.
• You may be constrained by reality but it’s always a huge risk to be required to launch a new/refreshed website for a hard deadline.
• Speaking of which, the launch is never the end of the project. Expect to need several post-launch updates.
• The more time you spend planning things from the start the cheaper it will be. If the website doesn’t follow the principles in this book it may need to be rebuilt, possibly from scratch!

Commonly forgotten pre-launch items

This is not a comprehensive checklist but it’s the type of stuff that in our experience is most likely to be forgotten in the mad rush to a launch deadline. (If this makes you eschew hard launch deadlines our work here is done.)

• Robots.txt file not allowing search engines to visit the website (chapter 18).
• Website pages instructing search engines not to index the website (chapter 18).
• No analytics on the website (chapter 13) – a launch is a very bad period to have a data outage!
• Redirects from old URLs to new URLs not implemented for a website refresh (chapter 3).
• Image, video or other resource files still pointing to the test website domain – this may result in the SSL padlock being missing from some pages (chapter 7).
• Login systems and payment gateways not being updated to the new domain – this may also result in the SSL padlock being missing from some pages (chapter 7).

Additional considerations for a website refresh

• Is your website refresh actually a homepage refresh? See chapter 11 but a lot of the time, the most changes are applied to the homepage, even if it’s often only visited by a fraction of visitors.
• Has someone looked at the data in terms of what works/doesn’t work on the old website? There’s a big difference between you thinking something doesn’t convert or that nobody goes to certain pages and that actually being the case, again a lot of the time this part is completely skipped. Nobody wants to launch a new website only to have it deliver less value and customers than it did before.
• Do you really need to kill content/pages in the name of simplicity? It’s common for large websites to cull thousands of pages during the refresh even if those pages are ranking on search engines, generating considerable traffic etc. We’ve seen websites permanently and irrecoverably lose over half their traffic this way. It’s one thing if you’re making a considered decision about this because of, say, a change in direction, but often this is not realised until it’s too late. Your current content is probably generating more of your long-term traffic than you think, even if it is old.
• How will you make the website backwards-compatible? People, ads and search engines will have old links which you will not be able to update instantly, and it’s not like you can change the bookmarks in the browsers of your most loyal visitors. You will need to make sure that you implement redirects, old-to-new page maps and so on. For large/deep websites this mapping work often requires hours of painstaking attention to detail (if you have hundreds or thousands of pages), but without it you will be locking out your most loyal visitors.