You know what it’s like – the scoping, wireframing and design is all consigned to ancient history, the development team are adding the final flourishes to the build and hey, we’re almost ready to launch.
Or are we?
Despite our best intentions, we often find that the final stage of a project can take longer than anticipated meaning that all-important completion date begins to look less likely, and we find ourselves (for want of a better expression) burning the midnight oil and making industrial-sized orders with Dominos Pizza.
So why does this happen? Well often it is simply a case of us having designed and built a new website around assumed content and when we eventually get it, it turns out to be incomplete or vastly different from what was expected and planned for. Of course this issue can be easily solved if content is supplied earlier in the project – even if it hasn’t been approved, a rough-cut of content is usually better than no content at all – it helps the design team when formulating their ideas and the development team can refer to it when crafting the build. It can also help you because if we get content earlier in the project, you can see if it works whilst the project is in progress and it gives you more time to refine and adapt it. Which, at the end of the day, means you’ll get better results. Win! Win!
But sometimes (shhh – whisper this bit) mistakes can happen or something gets overlooked. And that’s where you come in… We’re in this together and although we’ll be doing most of the work, you need to be involved too – and that means you need to understand what is going on, you should read and understand documents we send you and you should only sign-off and approve site maps, wireframes and designs if you are happy they cover everything you expect to see when the site goes live. Because if it ain’t there, it probably hasn’t been allowed for and, as Phil likes to say, ‘Assumption is the Mother of all Cock-ups’. And he’s right.
There are also many tasks that need to be done before we will launch a site and they can sometimes take longer than expected simply because we find bugs causing conflicts or incompatibilities with one of the many browsers or platforms we support. For example, we always check for display issues in all commonly-used browsers, we check for any dummy content used during development that may have been inadvertently left in the CMS (Content Management System – WordPress usually if you are interested), then we check HTML/CSS validation, ensure a favicon exists, set 301 redirects where required, check the URL structure, ensure pages have meta-data, configure Google Analytics and Webmasters and so on. If it’s a new site (or just a site we haven’t hosted before) we also need to configure the DNS and email settings. Finally we have a pre-launch client review before migrating the complete site from our staging server to a live environment. Or ‘the internet’ if you like.
The upshot of all this is (and because we are perfectionists and pay meticulous attention to detail) we won’t allow anything to go live until we are delighted with it ourselves, so the Final 10% can take longer than we anticipated. And even now a new project can throw up surprises and new challenges but we do learn from them. We promise.
So. What are we saying? If your site needs to be live for a specific date, we should all be planning around a launch date well in advance of it, so you, as a client, should take ownership of your project and if you don’t understand something, ask. If you still don’t understand then ask us again. And again. Until you are confident you do understand. Ohh, and don’t leave anything to the last minute or there are bound to be last-minute delays!
And besides, all those pizzas aren’t good for us.