Discussion on:

When You Suspect the Customer Might Be Wrong

Message 19 of 18

View entire thread
0 Votes
Collapse -

First of all, fall back on the old adage of, ?Proper Preparation Prevents ****-Poor Performance.? (Just don?t tell that to the client after they?re in a bind.) I approach projects from a two-contract concept; where the frist half of the project is a system analysis contract, and the second half of the project is a product/system delivery.

Doing a good, in-depth, system analysis at the beginning of any contract is so crucial that I feel it needs constant reinteration. You can?t give people what they want when they don?t understand themselves what they want. You need to know what the current business rules are for the area(s) you are going to be providing solutions for. You need to know WHY they have those rules, and you need to have them understand why they have their rules. Education of the customer is important, and the goal of this part. You could say you are conducting a seminar on business automation for them. I?ve lost a couple of minor projects where the clients actually modified their business rules after analysis because just making those changes and removing junk processes that had crept in over the years removed any immediate need to automate.

Once those current conditions are clearly stated, then it?s time to learn where they want to go from there. You may already have most of this information just from the initial analysis portion. Nail it down, be specific and all encompassing. Be prepared for a large number of feedback sessions. Make sure they sign off on the final statement of goals.

Draw up a good timeline with milestones and deliverables along the way, and with sign-offs on each part. This is basically putting together a product contract for them to agree to. Specify a change control process and make sure the client understands what changes on their part will cost them in time, money, functionality and quality. Conversely, you need to know what changes on your part will cost you.

All this is well and good if starting from the beginning. Not so easy if you take over a project in midstream, or discover that you made a mistake only after you?ve gotten halfway into the project. So what are your options? Basically they are break-even, poor, bad, and worst.

With a break-even, you can firm up the deliverables in terms you can mutually agree upon. I?m a bit odd in that I?d prefer to come clean with the client and tell them straight up that I/we can?t make head or tails of what they really want, and that we need to nail it down before proceeding. Tell them the goal/deliverable just isn?t specific enough to provide. Get the requirement, in writing, and add it the the contract, with a clause on what further changes will cost. You may lose on the profit you originally sought for the job, but it should stop further losses.

Your poor option is to decide what you think their deliverables are and if they can?t agree to a firm set, do just that and hope they?ll pay in the end. You?ll probably be looking at legal action on this one.

The bad option is to let them lead you around by the nose while your budget hemorrhages to death and the project never gets completed, or it gets done and nobody gets what they want. You may be looking at legal action on this too.

Worst, you can break the contract. If the client is not amenable to making specific, hard changes to the contract deliverables, you may want to consider what the cost of breaking the contract would entail versus the losses from completing it. (Not just penalties, fines, fees and such, but loss of customer goodwill and bad advertising.) You?ll almost definitely be looking at legal action on this, and you?ll need lawyers and accountants to figure the all the costs out anyway.