Discussions

When You Suspect the Customer Might Be Wrong

+
0 Votes
Locked

When You Suspect the Customer Might Be Wrong

A.Russell
I recently worked in a project where the requirement came from a client who wasn't very knowledgable about technology. The initial requirements were vague and contrary to subsequent, ever escalating requirements after a quote was made and work was well underway.

For example, intially a client insisted there was to be no multi-document interface and no tool strips or buttons, as they were far too complicated, against my advice. During development, he changed his mind and insisted on them.

My question is, when you receive requirents that you don't think the client really wants/ needs, how do you tell him he is wrong, or how else do you handle it.
+
0 Votes
Hendry_Betts
Collapse -

Everyone here has given sound advice on how to manage change in a project. Once development has begun, a formal change process with impact analysis should exist. So, if half way through the project, the customer wants something new, they know it will be delivered after milestone 'X' and cost them '$Y'.

However, what I see in your post is that you are trying to guide your customers "interface" decisions based on your personal preferences. "... they were far too complicated..." Perhaps they are too complicated to implement? If that is the case, you should have planned for them since you never really convice a customer to change their mind [a sad fact].

Given this state, I would suggest either a) hiring someone who can implement the UI the customer wants or b) planning an exit strategy with a subsequent refund.

+
0 Votes
usr19x@
Collapse -

Clients always have an idea of what they are looking for. Ask them if they have seen something similar to what they want you to do for them. It may take a combination of solutions that they have seen to bring the project to fruition (If they could buy it off the shelf they probably would have).

Some clients will agree to anything and then complain simple to renegotiate the price after the fact. Don?t let yourself be sucked into this trap. Always present your proposal in writing. Specifically detail every aspect of your proposal. Do not begin a project without a signed contract and appropriate upfront payment.

I like to use a multi-stage development process. I begin with a general design which includes layout/color scheme and indicates tools/features. Once the user interface has been agreed to, I proceed with connecting the general functionality and present a working model to the client. Hopefully any changes/corrections can be intercepted at this point. If the client approves I then collect additional payment before continuing with the final version. When the project is complete I make a version available to the client for final testing. Upon acceptance of the completed project (use a written Acceptance Statement and get it signed) I collect final payment prior to releasing a ?live? version. The client then has an additional ninety days to find quirks/problems with the solution and if it was covered in the original proposal it is fixed with out additional charges.

If I have concerns with aspects of the project I will discuss them prior to submitting the proposal and place those concerns within the proposal. Additionally I list options in the proposal to address those concerns including price changes whether +/-. Each option has a checkbox and a place to initial to indicate its acceptance.

The proposal is not one sided. I include time frames for project progress, quality and professionalism. The proposal includes caveats for signing and NOT signing as it becomes a contract upon authorization. No proposal is presented without this paragraph - ?Changes or additions to services listed in this proposal will be charged separately and in addition to service fees outlined in this document?.

+
0 Votes
Dr_Zinj
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.

+
0 Votes
BALTHOR
Collapse -

And--"If you want this--this is what it will cost you".

+
0 Votes
ttocsmij
Collapse -

The Customer requests bids and provides a detailed explanation of the work to be done.

Review the Customer's requirements document and (assuming you wish to work for this Customer), respond with a bid including a list of the deliverables and cost for same. It is here you would add addendum(s) describing features that you believe would enhance the deliverable (including their estimated cost).

The Customer reviews your bid and accepts it or rejects it. There may be questions which you should address promptly. In the end, the Customer will accept your bid or reject it. Either way, you will know what needs to be done and can get right to it.

Note that there should be a contract clause stating specifically that changes requested after the contract is signed will be quoted separately; and will not be considered until signed off by the Customer as to scope, impact on the project time line, and cost.

At no time should you argue or attempt to persuade the Customer that they don't know what they are doing. That is like arguing with a secretary or a policeman; how far do you think you will get?

Does that mean that you have to design the product to exclude your enhancement ideas? No. You probably should design flexibly enough to add features later (since if you are correct they will be back for version 2 and why start from scratch, eh?). But remember that the Customer needs the product on-time.

Now how do I arrive at this process? Well, I worked seven years for a company whose product was totally custom; ie all work was contract-driven. Yet time and time again we agreed to extra work and design changes after the contract was signed to make the Customer happy. Consequently we were constantly late and/or lost money on every contract. But our parent corporation had deep pockets and hoped we would do better next time. We didn't and we're no longer in business. But our competition followed the contract process described above. And they are now the world's leading supplier of the product.

+
0 Votes
Goody-tooshu
Collapse -

I have the same things that happen to me! People that come into a business want to sound smart and know what they are talking about but they are always and normally wrong. They won't know all the things you do because they don't know all the facts and things that would happen behind the business. It's like a picture. You only see the front not the inside of what it is all about.

+
0 Votes
Why Me Worry?
Collapse -

If the client forces a change in the scope of the project after the project is put on paper and in the process of being developed, then it should be required of the client to shell out additional cost for deviating from the original project scope. All project managers work this way, and even home builders/contractors. If the customer throws in additional items while the work is being done, then it should be billed back to the customer because the original scope of the work is now being deviated from.