Monday, July 14, 2008

Saving The Contract



Contracts definitely have their ups and downs. And their downs can be pretty low sometimes. When you find a cash cow client (and I'm talking a project that pays like $3200 every two weeks, several paychecks in a row), so does the expectation level. And the longer you wait before delivering results in phases, the more frustrated the client can become. My frustration on this go around was because I didn't have any page templates to hang stuff on because the client didn't have them ready yet, and the site was supposed to be a very beautiful site. I had bitmaps to go on, but son of a gun those things were hard to pull off in my browser and make them look great on IE6, IE7, FF2, FF3, Opera, and Safari, looking exactly the same. Meanwhile, the client shifted gears on framework, shifted gears on requirements, and seemed to want to forget the project delays were largely because of them.

So I was told to stop all work! Holy cow, that's not what you want to hear, especially after doing two weeks of work and needing to invoice on the next day.

Well, my wife and I went into damage control mode. We saved the contract. We not only saved the contract, we renewed my client's faith in me, got ourselves back on target with the project schedule, and got the client to agree to let me invoice him for the past few weeks and the next 3 weeks ahead, which is a major windfall.

My wife sat next to me, took notes, managed my time, got me drinks and things I needed, and did everything she could to encourage me and keep me going for two 12 hour runs to try and save this contract. And we pulled it off.

You see, I was worried that if I default on this contract, then the client might come back and ask for all or much of his money back. Well, normally it's a good idea to not spend that money right away. Unfortunately, however, I've had such a need to pay some bills and get my home office infrastructure going here that I had no choice but to use these funds.

So, anyway, the lessons learned here are:
  • Don't be fooled by wealthy clients -- they expect more from you than lesser-paying ones.
  • Time your deliverables two business days before invoicing time and make them substantial with something they can click on.
  • If the client says stop doing something a certain way, stop doing it that way, even if you think you know better. For me, I was focused too long on implementing my own page templates, thinking, well, it will look so much better and I thought I could knock them out fast. Well, fast turned into way too slow.
  • On larger projects, don't begin until all the page templates are drawn out. This helps you visualize the functional spec a lot more, and it's far easier to build the app. I sat down and realized the other day that I was spending enormous amounts of time simply thinking how the fields will go on a page, and then fighting with CSS to make it work right with all browsers. Instead, let that be a project for your client and his designer.
  • Sometimes you have to drop the distractions and get a friend, girlfriend, or wife to help you focus, sitting next to you or checking in on you if need be. It was tough giving up a bit of blogging, forum interaction, live chats, and lots of email interaction, or doing my typical routine, but I got a lot accomplished and caught up again.
  • Get your workstation, desk, and home office exactly as you like it. It will make a HUGE difference. Clutter around you also tends to lead to clutter inside your applications too, for some reason. It also leads to distractions.
  • Every project has key deliverables and quick-hit deliverables. You need to tackle both. It's hard sometimes to focus purely on one -- it drains you. So, flip between the two by knocking out a couple quick-hit deliverables that don't take too much time, and then flip back to two key deliverables. This produces more results in faster time and gives your client the impression that you've worked much of the application out in very little time.
  • When the client wants to put you on the defensive, you can guarantee that he knows you're the wrong developer when you sound overly defensive, go on a tirade, write something extremely wordy back to him, get short with him, or make a big deal out of something he says. You'll find that keeping your cool, not reacting to what he said for an hour, and trying to stay positive -- these things help. In my case, the client turned around and apologized for his harsher tone, explained himself, and we worked it out. Now, had I been a much younger developer and not learned this lesson, I would have failed to not sound defensive and would have more than likely lost the client.

No comments: