Ben Nadel
On User Experience (UX) Design, JavaScript, ColdFusion, Node.js, Life, and Love.
I am the chief technical officer at InVision App, Inc - a prototyping and collaboration platform for designers, built by designers. I also rock out in JavaScript and ColdFusion 24x7.
Meanwhile on Twitter
Loading latest tweet...
Ben Nadel at the jQuery Conference 2010 (Boston, MA) with:

Import Lesson: Always Codify Change Requests From Clients

By Ben Nadel on
Tags: Work

I have recently learned a very important lesson. Always codify the changes that clients have requested. If a client requests something over the phone (or even over an email), always, always, always send them an email saying something to the effect of:

"As per our conversation, these are the changes that I will be making..."

And then LIST THEM OUT. This way, 3 months down the road, when a client complains that something wasn't done, you can simply point out that you did exactly what you said you were gonna do AND you did exactly what they SIGNED OFF on. And, you have the paper trail to back it up.

I guess the real lesson here is to always have a paper trail. Always have accountability explicitly defined on something that can be printed out and passed around.

Now, this might sound like this is just for covering your butt in business. Yes, that is a big part of it. But there is more to it. By forcing yourself to get in the habit of reiterating the client's needs back to the client, it forces you to think it out (thereby gaining a better understanding of the work to be done) and it gives the client another chance to say "No, actually you didn't understand... this is what I want."

It's really a win-win situation. Learn from me. Don't get in trouble.



Reader Comments

Spot on, and as you say, the practice is valuable way beyond CYA. It clarifies the transaction, serves almost as an are_you-sure? step, and provides an audit trail for whatever purpose you might ever need it, technical or otherwise. Plus, it adds a level of professionalism to the contact stream with the client.

As it happens there have been a few times when tracking down the confirmation email in my archive has given me some needed info that might or might not be related to the edits in question!

Reply to this Comment

I would also add that the email should CC or go directly to the person authorized to make change requests. Not the assistant, sister, co-worker, etc.. AND CC the person paying the bill (often different people).

More than once I have seen change requests OK'd by someone who thought they were important only to find out the big boss doesn't care, didn't approve it and will not pay. Or worse yet the accounts payable people get involved and say 'we don't care it isn't on the PO'. If the change request involves hours and money having that clear in the email or signed fax, etc. is very important.

Reply to this Comment

Josh,

It's funny you mention that because this lesson that I learned was pretty much along those lines. The person who made the change request for an application was not even the person that uses the application. Once the changes were rolled out, the main guy called me up and was curious as to why the system had been changed. :)

Now we have to roll back changes to the code and the DB (on a remote server) all the while being careful to not corrupt data that has been put into the new DB structures. Sweeet.

Reply to this Comment

If anything like a current client of ours they will ask you about 3 weeks later to reinstate all of your changes you just reverted. And be angry you are charging them again.

Reply to this Comment

Ben,

Good advise. In my experience most programming problems come from misunderstanding the requirements.

Detailing your understanding is a good way to help make sure your understanding is correct.

Reply to this Comment

That is good advice. I don't send an email to the client, but I do keep a version log of all the changes I make.

Reply to this Comment

Post A Comment

You — Get Out Of My Dreams, Get Into My Comments
Live in the Now
Oops!
Comment Etiquette: Please do not post spam. Please keep the comments on-topic. Please do not post unrelated questions or large chunks of code. And, above all, please be nice to each other - we're trying to have a good conversation here.