Managing Clients – draw the line and hold your ground.

One of the most frustrating aspects of being a web application developer (a Web nerd) is found in the dynamics of dealing with clients.

I’ve been known to say: “I love everything about programming … except for the clients!”

This aspect of the web business (managing clients,) falls under the umbrella of project management – something every web developer, must learn at least a little bit about.

Who are the clients?

Clients can be the actual company for whom you are building the software, they could be the department next door or perhaps it is just your manager.

Whichever the case, you need to learn how to manage your clients, otherwise you will suffer a long and painful life – as a programmer.

A story all too common …

I was chatting with a nerd friend of mine recently and he describe a situation he was dealing with – a situation that made him consider leaving his job.

… He described his hair-pulling situation where his client was adding new functionality with each meeting. It was becoming such a regular event, that he was purposefully avoiding meetings.

These additions are commonly known as ‘change request’ and unfortunately, my old buddy was not handling them the way change request should be handled.

This is the scenario:

• Client request additional features/functionality NOT in the original quote.
• Client expects these additions at no additional cost.
• Client expects the project to be finished by the original deadline, even though they’ve requested a bunch of new stuff.
• … Client gets angry because you can’t meet the above expectations.
• You start hating your job because the rug keeps getting pulled out from under you and yet, all the fingers are pointed at you!

Programmers need to draw that line in the sand, and then stand their ground!

The frustration is really rooted in how YOU manage the client’s expectations. You (as the programmer) need to be clear at the start, on how things are going to go with regards to the project.

Put it down on paper.

You need to clearly define the parameters of the work (what you’re doing exactly) and then set that down on paper where everyone concerned signs on the dotted line and everyone gets a copy.

It should also be clearly stated in the document (and to their faces) that any changes will affect the price and the deadline.

… If they want to add features or change requested functionality, the price will change and the deadline will be pushed back – it only makes sense that it will take longer to finish.

The contract before the work.

This paperwork should all be hammered out before you write one line of code. Actually, this should be done before you do any real work on the project.

I’ve found that (most of the time) if you establish the working relationship at the beginning (defined by the contract), the vast majority of clients will respect you, and the process much more so.

… Rampant change request will simply not happen because the client understands.

That said, if your client still turns out to be a little dense, you need to pull out the paperwork and stand your ground.

You have been warned:

If you don’t do this, programming will be like the slow pull on your back molar … as the dentist extracts your tooth. And then, there will be blood.

Stefan Mischook

www.killerphp.com