Issue in managing changes

Question

I was coordinating a Project and we constantly faced a problem where the customer was not ready to pay for change requests.

The project was to automate most of the processes of an existing system i.e. instead of manually uploading a file using forms in existing system, know the source of files and automatically upload them at specified time and update reports accordingly.

We created the scope statement by interviewing client and documented the source of information, the type of action required to be applied on those sources, the time of taking that action and the expected outcomes.

This was a Fixed Price Project and the domain was new for us.

As we kept progressing, we came to know about the more information/sources and more dependencies due to which we had to do extra work to achieve the documented outcomes resulting in added efforts.

Many a times the customer gave feedback on the features implemented based on agreed upon solutions and those feedback led to alternative solutions which should be accepted as change request.

Every time we represented those added efforts to customer as a change request, he rejected the same saying this feature is the part of scope and we will not pay extra for this.

I tried convincing by showing the initially approved and documented solution VS changes proposed in the solution as feedback which demanded added efforts. But the only efforts he approved was the new features requested to add in scope.

How can we handle such situation?

Answer 1

This is not an issue of managing changes in scope, this is an issue of trust and respect. When two business parties trust and respect each other, they will usually find ways to collaborate and agree on things. When they don't trust and respect each other, they choose to sign contracts then argue and fight over contract clauses. Bring in the lawyers...

You decided on a fixed price contract. What's important is now what's written in the contract and how it's written. If all situations are not clearly formulated in the contract or there isn't a clause that says how to deal with new situations that are not covered by the terms of the contract, then that means that things are subject for interpretation by anyone, like:

• you: this is additional work that we didn't knew about, so the customer needs to pay for the extra effort;
• customer: We thought this was included in what we originally discussed, so why should we pay more than agreed?

Fixed price contracts are used when you have clear requirements and projects are small. From what you mention in the question I gather that you weren't clear on the requirements but you assumed you knew how long the project will take. A Time and Material contract would have worked better.

But you have a fixed price contract.

There isn't really an authoritative answer to this, but you need to:

• check very well what's written in the contract, what's properly defined in writing and what can be subject to interpretation and assumptions;
• try to think at ways to increase communication with the customer and earn their trust because you need to renegotiate the things from the contract that are not clearly defined;
• define and agree on a proper change control process.
• think hard about this project and decide if you are going to swallow some of the costs for extra work to keep the customer, or if you give up on the customer to limit your loses (depends on the contract termination clauses). Ideally, you can find some middle ground using the previous points by agreeing on contract clauses or negociating another type of contract.

Answer 2

The SOW or PWS of your FFP prevails. You need to refer back to the contract and how explicit the language is regarding what you were to produce and how you were to produce it. You only indicate that you have an "alternate solution." That could mean a ton of different things, some which you might be able to argue a change is needed, and some where you are still well in scope. In the world of IT, I would bet your contract is vague and ambiguous. In my experience, seller wins few arguments of something out of scope with the buyer. Hopefully, you built in enough contingency in your price to absorb these differences.

In a very real way, a FFP is supposed to minimize the constant change requests and threat to growing costs based on these changes or other unforeseen issues. You have to extremely explicit about what's not covered in the FFP to warrant a change request--even stronger language than an "assumption."

Answer 3

The nature of FFP (Firm Fixed Price is its formal name) for software development projects is not that the price is fixed but that both parties will negotiate over scope and pricing as inevitably will be required. Some customers don't properly understand that so it needs to be explained to them early and excluded costs ought to be explicitly mentioned in the contract along with how such costs will be calculated. Some customers on the other hand are well aware of how FFP works and want to take advantage of the negotiation aspect to get a good deal.

It is notoriously difficult to make FFP work unless the parties trust each other well and both have a thorough understanding of the problem domain. Otherwise relationships tend to become strained and failure is very likely. It helps if the relationship is longstanding or ongoing. If the work is likely to be a one-off then there's no incentive for either party to maintain a good working relationship and short term commercial considerations will probably rule.

My advice: whether you are a vendor or a buyer, try to avoid FFP software development because it's often more trouble than it's worth and it actively works against getting a good job done. When quoting a fixed price, build in a significant premium to account for the additional risk that you are shouldering, then always quote for the same work on a time and materials basis. Since the T&M price is much cheaper there's a strong incentive for the customer to go for that.

What you have to do now is decide what it's worth to you to continue in this way. You could take what the customer is offering, you could set some limits around how far you are willing to go, or you could walk away and call a lawyer. In all cases the customer relationship is probably going to be difficult.

You may have some additional leverage if there are incentives for the customer to see the project through to the end. For example if you have intellectual property or software licences under your control. I am not a lawyer however.