Issue in managing changes

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.

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."

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.