Managing Web Projects #12 – Sign-off and “Delivery”
Wow, it’s been rather a long time since I posted my last entry in this series – Managing Web Projects #11 – The Change Request Form. I haven’t forgotten about this series honest, I’ve just been procrastinating over it!
Yeah, enough with the excuses. Get on with it!
Okay! Okay! Here we go…
Why bother with a website sign-off form? The customer told me it was okay on the telephone.
Well, as the old saying goes: “A verbal contract isn’t worth the paper it’s written on!” Who’s to say that the client won’t turn around and say that the project’s not complete because of X, Y or Z, or they may even turn around and say that they didn’t want it to go live until the summer. Whatever their excuse, you need to cover your behind hence the sign-off form.
Anyway, you need something to say that the project is finally finished otherwise you’ll just sit there in developer limbo for all eternity and won’t be able to get paid!
Er… Okay, I can sort of see the value in that. What’s it do?
The Website Sign-off form is another form of contract between you and the client. It forms an agreement that the website meets the design and development specifications (as set out in the TRS and that the client is happy with the way the site looks, works and its content.
Yeah? Well it still sounds like rubbish to me!
Really? Perhaps a little horror story might help sway you.
About 6 years ago we had a client who was, to put it politely, a royal pain in the backside.
During the project they tried to change the functionality of the website (which they couldn’t thanks to a tightly written contract and TRS) so at the end of the project (or what we thought was the end of the project) the Managing Director decided to hold us hostage by threatening to sue us as their much needed (according to them) functionality was missing and we’d put the website up.
Funnily enough, the Project Manager for “We’re a pain in the Arse” Ltd. had already signed the website off and was happy for it to go live so the Managing Director was whistling in the wind – hoorah for the sign-off form!
Without having that little piece of paper, we would have been sucked into a never ending round of change requests and feature creep which would have meant that the project never went live.
Funnily enough, the reason why the Project Manager had happily signed the website off was that he knew that the functionality being requested by the MD wasn’t even needed – the MD had read a buzz word in an industry magazine and latched on to it not knowing what the heck it meant. The Sign-off form certainly saved our skins on that occasion!
Okay, you’ve convinced me. What do I do?
Actually, this one’s quite simple. Use the following list as a guide to the content of your sign-off form (they’ll vary slightly depending on the type and complexity of the website) then email a PDF version to the client (always use a PDF so they can’t change it!); ask them to sign it, fax you back a copy and send the original in the post. Then, when you receive the fax you can put the website live for the whole world to see your wonderful development skills!
- Project Manager for the Website
- Client’s Contact for the Website
- Person responsible for sign-off (may be the same as above)
- Date of sign-off
- Required “Go Live” date
- Project Milestones (e.g. Design, special search functionality, integration with backend systems etc.)
- Completion statement
This will read something like:
I, [Name Here], being a representative for [Company Name], certify that we are happy with the design and functionality of the website and that it can be made live from [Date]
Disclaimer: Of course, I’m not a lawyer so the above is an example and may not necessarily be legally binding enough depending on the country you’re operating in - Signature, Printed name & Date
So, once you’ve got the signature you can put the site up – hooray!
Yeah, yeah, I know, I just copy it over and away we go
Hmm, right! Sure, you should copy the staging server version onto the live website but then make sure you test it! Set up a development URL (preferably behind a password protected directory so no wandering customers can find it) and test all the functionality of the site. There’s nothing worse than letting your client know that the website’s gone live only for customer’s to ring in and complain that they can’t place any orders because there’s a different email component installed – although you made sure the staging and live servers were the same, didn’t you?
Once you’re happy that the site is working as it should now comes the big “change over”.
Yeah? So what? I just turn off the old site, repoint the DNS and away I go, easy!
If only it were that simple! Of course, this only applies if you are moving hosts but as I posted recently on my problems with domain name moves nothing goes smoothly.
It is supposed to take a maximum of 72 hours for the DNS to change over but I have seen it take a lot longer than that (over a week!). If you shut down the existing site (by basically turning it off), what customer will want to return to the site when the new one is up and running? None I should imagine as they think it’s broken. If you are running an e-commerce website then your entire ordering system could get screwed up by one person ordering from the old site, one person ordering from the new site and both users being issued with the same order number! So, what do you do?
If you have a static site then personally I’d run both at the same time until the DNS changes have taken effect then delete the old site. If it’s an e-commerce or dynamic website (such as a blog), shut down the dynamic components (ordering, commenting etc.) until the changes have taken effect or remove the site entirely and replace it with a nice “We’re upgrading, please check back shortly” message. As an added incentive for people to return you could capture their email addresses and then email them to let them know the new site is up.
Point taken, I’ll shut the website down and when the DNS is changed I’ll invoice the client
Not so fast buddy! Just because you can see the new website doesn’t mean everybody else can!
Different ISPs take different amounts of time to update their DNS servers so try and check the website on as many ISPs as possible – or get your friends to help. Only when you’re completely sure that the changeover is complete can you move on to step #13 – Invoicing the client.
- Follow Katy Whitton on:
“This article explains how to geographically distribute a web site for $100 or less per month, including web hosting, geo-ip services, and DNS services.
“