This is dedicated to everyone who does things “on good faith” only to end up in a bad place.
Names and identifying details have been changed to protect the guilty.
First, the background. Not long ago we were involved in a web project that was outsourced to us through an agency. In an “it’s a small world” kind of way, we all – client, agency and us – knew each other professionally and had worked together before.
In this particular instance we contracted not with the client but with the agency. As is always our practice, we built a proposal, stated our role and clearly outlined our participation in the project. The agency signed the contract and the project began.
Things went well until the client became disillusioned with the agency and came to us to sort out the details.
A conversation ensued.
“I’m not happy with the color blue.”
As it turned out, color selection was not part of our responsibilities. We advised the client to speak to the agency.
“But I’m your client, too. Can’t you fix the blue?”
No, we don’t have access to colors. Did you speak to the agency about it?
“The agency likes the blue. I’m not getting anywhere.”
Is there a provision in your contract with them for changing the blue?
“I have no idea. Do I have a contract?”
Sticky situations aside, the fact that the client didn’t know what was in his contract, let alone whether he even had one was a recipe for misery.
A whole lot of debate ensued followed by finger pointing, complaining, explaining and even yelling. Eventually the project went on to be completed, much to the irritation of the client.
Now for the story.
After the debacle over blue, and once the project was finished, the client fired the agency and called us in for a meeting to reboot the project. We talked a lot about blue, what we could do to fix it, and what other expectations the client had. A few days later we presented another proposal – this time to the client. Another conversation ensued.
“This is a really long proposal. Can you just tell me what’s in it?”
Sure, we can review it, but you should read it yourself and make sure it’s clear and that we’ve included everything you want.
“I don’t have time for that. Why do we need a contract anyway? Can’t we just do the project?”
We will do the project, but don’t you remember what happened last time? The expectations weren’t clear, you weren’t happy, and you’re about to spend more money on a do-over.
“Why are you trying to lock me into something? It sounds like you’re just trying to protect yourself.”
What we thought, but didn’t say to the client, was “hell, yes!” No blue conflict for us! What we also thought, and did say, was that the contract was designed to protect the client, too. The agreement went both ways – he couldn’t ask more of us than we’d agreed to provide, and we couldn’t provide less than we’d agreed.
In a strange case of “some people never learn”, the client refused to sign the contract and the project never rebooted. He seemed to think – even after the way his last project turned out – that we were trying to rope him into something by putting it in writing, and that somehow knowing what to expect was worse than having the ability to argue over it later.
These kinds of things just make us sigh.
In this case, we suspect the client had a flair for high drama. But the fact remains that either party would be crazy to accept a job without a written contract that defines the parameters of the project. Who’s to say the blue won’t be wrong? Or missing entirely? And who’s to say whose problem it is?
Developers can promise everything – and clients can demand anything – if nothing is defined in writing. This is why the universe invented project specifications. And for people who don’t use project specifications, the universe invented words for them, too: scope creep. And budget overrun.
It wasn’t the first time a client had asked us in that exasperated “do you seriously expect me to, like, read?” tone whether we couldn’t just start the project. But our answer is always the same: what project? The one with the blue, or without the blue? The teal blue or the aqua blue? A contractor wouldn’t go out and “just build the house”. A chef wouldn’t go out and “just start the party”. But every day, clients expect web developers to “just build the site”.
The proposal – the contract – the specification – whatever you call it at various stages of the project and however it fits into your process… we’ll bet there hasn’t been a successful project on the planet without one. Developers need them so they know what to build and clients need them so they know what they’re getting.
Otherwise, you end up where our client was: lots of disagreements, a complete budget collapse and a product he wasn’t happy with in the end. Why would you want to go through that, or start over and waste time and money on something that could have been avoided with clear expectations?
To the developers out there whose clients think that asking them to understand their own project is a form of underhanded torture: we share your pain.
To the clients out there who think their developers are trying to “rope them in” or make them go too blind reading the fine print to be able to see that the blue is the wrong shade: take a lesson from this story and make sure you get your project specifications in writing.
You can’t be roped into anything you don’t agree to, so be sure to read and understand your contracts, because you can sure be disappointed and flat out of luck when the developer fails to read your mind and the project doesn’t turn out the way you imagined it.
