The art of keeping calm
I delivered last week the website for a big client, and after a few months of very tight schedules, technical explications on the solutions chosen and the limitations of web browsers, debates and frank disagreements, I can’t say it’s been a smooth ride.
However, most of the problems that come up along the way can boil down to some important points that I may not have highlighted enough as being critical for the delivery, and the client’s inability to have things done and agreed in a timely manner:
Make sure they read and understand the whole contract and brief. Working with tight deadlines usually yields some (late) disagreements on the terms of the contract. But they signed it… To avoid problems, take time to detail each point with them and make sure they understand them all.
Make a delivery plan and stick to it, no matter what. Again, with tight deadlines, it’s easy for your client to think something is small enough to be added to the backlog of work, and won’t impact the delivery date. IT ALWAYS DOES! Remind them of the agreed scope and the deadlines set.
Be as inflexible as possible once the deliverables are… ahem… delivered. That is: no change to the design after it’s been signed off, no change to the platform after it’s been chosen and development started, and no change to the website host once it’s been deployed. However, do welcome and discuss minor changes before the deliveries, as they (usually) are small enough to be integrated, but push back on the big ones for further development after the site launched. Once items have been delivered, I consider them done and not requiring changes. Unless there is a major bug that is.
Document all aspects of the website, what your client can, cannot, and should not edit. This last point is important in that it frees you from the kind of situations where your client comes back saying “You didn’t tell us…”. Simply cover your back that way, as you always have a reference to point them to when they try to do things the wrong way.
After the deployment of the site, depending on your support agreements, identify what you can do, and filter out what’s not your job. I deployed the website to one server under one domain name, but it turns out that this client now wants the website to be deployed on a different server under a different domain name. I agreed to do it once, this now falls in the “extras” category. Also, changing the domain name of the website on platforms such as wordpress is not as easy as flicking a switch, and may involve much more work than one might think.
So at some point one have to become inflexible, to play the role of the bad guy in the eyes of his client, and be strict on the deliveries. Ultimately, after the initial awkwardness passed, that can only be beneficial for the agreed outcome of the project.
And while I’d like the website to remain as clear and usable as possible, exactly as it’s been designed, no documentation or training can, unfortunately, prevent it from being ruined by changes made to the content without supervision, control, enforcement of the design rules, ownership, and ultimately… care.