The Right Ways to Work with Clients

You’ve got the technical skills, but are you doing things right? Are you a pro-active or re-active worker? You know, in the past two years being a contractor, I’ve learned a lot. I changed a couple different ways to work and every time, learned a few things from the past experiences. 

• Always be prepared for a meeting with an agenda!
  
  Don’t go to the meeting just to hear what others have to say. Before the meeting, prioritize a list of things you are doing and what you will do. Bring a list of issues that concerns you/ having difficulties with and a list of things you might need others to collaborate with. Take one or two hours to really think about them. The point is to have an agenda prepared and this way, your manager and peers would know what you are doing and not assigning you extra works.
  
  Here is a story.  I used to go to the meetings in reactive mode, no list, no agenda. Just to hear what my clients and others have to say. I just sat there and listen. One time, my client asked me if I can add a few changes to the application and how long would it take? Not being prepared, I couldn’t remember of all the things I’m doing, I felt nothing at the moment is much work, so I said a week. Well after the meeting, when I went back to my code, I remembered I had this bug in the app that I was fixing and it turned out I spend three days to fix it and another issue still needs to be finished before I can start these new changes. Well, I ended up work extra hours to get all these done before the weeks end. Lesson learned, first I didn’t have a good sense of my current priorities, second, I didn’t look into how long would I need to finish my current bugs.
  
  
• Don’t do nor suggest extra things just because you can. 
  
  
  You got enough things to do right? The reason I’m saying this is that anything you take on will be YOUR responsibilities and be accounted for.  
  
  Here is ONE of my experience. I developed a demo for my client and I was supposed to give them the code and database backup files for testing. In fact, they asked for it.  I thought why not take an extra step, just host the web files and database on my own site and have them test there? Normally, it takes 30 minutes at most for any updates anyway. This way, I didn’t have to email them and then give instructions on how and what to setup. They on the other hand, didn’t have to go through the trouble of setting it up.   My intention was to avoid troubles for both sides. (STOP reading here, can you see what problems this could cost? Okay, read on)
  
  Well, one time, the db administrators was too cautious, went back and forth in email with me on how and what to set up while I already told my clients it will be ready in an hour. In reality, it took 2 hours. The blame of course is on me.  Of course it was something not expected, but hey, you took on this, anything unexpected happened is YOUR responsibility. You can’t blame others.
  
  Trying to be “nice” is good, but it comes with a cost! When things go wrong, you are accounted for.  Lesson learned; don’t do things just because you can. Do what you are supposed to do and be done with it.
  
  
• Don’t easily say “Yes” and always ask them to provide details FIRST!
  
  Make sure you know what you are doing before you say “yes”. Always ask questions and ask them to provide details before you say the big word “yes”.  Have you been in a meeting where someone asked you, “hey so and so, will it be possible if you do this?”  You know generally what they are talking about, but they didn’t give you any details. It doesn’t seem hard, so you said “Why not? Doesn’t seem like a big deal.“ Only to find out in details later, it’s not so simple. Well time to beat up yourself again. You should’ve asked, can you elaborate in a little more detail and provide me with specs first.
  
  Here is another story of mine. My client asked me if I can write some functional documentation for the current application.  Without thinking, I said, “Yeah sure” Thinking, what’s the big deal of writing some documentation? BIG MISTAKE. I’ve never been in this situation, a rookie for sure.
  
  First of all, broke rule #2 – doing things just because I think I can.  I’m a developer, not a technical writer. It’s not my job in the first place to do it. They have an in-house business analyst that knows intimately of the business logic. Functional requirements should’ve been his job. At least I should’ve brought up the issue that he should’ve wrote it.
  
  Second mistake, I didn’t ask for any details on the documentation such as the format, style, their expectations and purpose of the documentation. Well, as it turns out, I wrote in the format and the style that I used to see and it’s not what they were looking for. They got pissed because it wasn’t in the format they wanted.
  
  This reminds me of this recent dilbert :)
   
• Don’t take on the responsibility of making decisions upon yourself. Your client should make the decision. After all, they are the one who’s taking cash out of the pocket.
  
  When you are asked to do things and there is a conflict of interest in priorities, always and always ask your client which one you should do first. Never take on the responsibility to make this decision upon yourself.
  
  Here goes another story.  I had a busy week working on my application for a demo next week and the team-lead of my client in the middle of the week gave me a bunch of bugs of some other applications to fix and she’s in a hurry. I thought, okay, she was the team lead of client, whatever she says, I do. Well, the bug was fixed by the end of the week but had to tell her the demo had to be delayed. Well, guess what? Only to find out the team lead wasn’t aware that there is a demo next week. She complained (which is bad) why didn’t I tell her that I had a demo coming where I was thinking, you are the team lead, how could you not know? You asked me to do it, so I decided upon myself to do the bugs first since she wanted in a hurry.
  
  The correct way should’ve been, I have this demo coming up in a week, do you want me to stop what I’m doing now and fix the bugs first, or continuing on the demo? Make her decide. The team lead probably knows what’s more urgent than you.
  
  
• Disagreement between you and your clients. Make sure you raise your concerns and document it.
  
  We all have disagreement on which way is the best to do it. If your client insists their ways are better, raise your concerns and make sure document down in whatever ways that they are aware of the issue. In case when things blow up on the exact issue, you’ve raised the concerns before. 
  
  I’ll save this story because it turned ugly.
  
  
• Clients don’t remember what they said a few months ago, recode them down! Change of orders form or can you say Email? (Not verbal nor phone agreement!!!)
  
  It’s normal. No human remembers exactly what they said a few months back. Just make sure you document it down and whenever a decision is changed, remind them of what they said.
  
  No explanation needed here right?
  

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS