Import Lesson: Always Codify Change Requests From Clients
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!
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.
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.
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.
Ha ha, quite true. I think we've all had clients like that.
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.
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.