FPPs – Yet More Thoughts on What Could Go Wrong


Fixed Price Projects (FPPs) are difficult enough to estimate when everything lies within your control. Of course, in the real world of business system implementation there are many things you can’t control. You’re planning the work of people you don’t know, assuming preconditions of which you have scant knowledge, and you’re always at the mercy of the unexpected, such as a change in business conditions, of priorities and of sponsor.

If there’s one particularly risky area it lies in the interfaces you must build between your system (the system you know) and existing systems (which perhaps no one knows fully).

When drafting a contract or scoping document, consider these risks.


Interfaces can kill. Be very clear what you mean by them. Just as wars can be fought over the differences in meaning between ‘interfaced’ systems and ‘integrated’ systems, so battles can be lost and won over what you promise when you promise interfaces.

Just for the record, I use the term ‘integration’ when I mean that two systems (usually separate packaged software systems, and often supplied at different times or by different suppliers) communicate at database level, by which I mean that one system might write or read data directly from the other system’s database.

I use the term ‘interface’ to describe situations where one system exports a file or table specifically for the other system to do something with. But I’m not sure this is standard usage.

But whether we mean integrated or interfaced precision is essential. You must list the ‘interfaces’ you are promising (and here I mean program code that will read or write interface files or tables), together with the purpose of the interface, the frequency with which it will run, the data fields it will contain (or ‘data sufficient to support the standard …. function in system xxxx’) and your assumptions, which MUST include an assumption that the data are CLEAN and do not require additional validation. A clause such as this is needed:

‘We will provide the listed interfaces on the assumption that your systems will provide complete and accurate data in an interface file or table that are sufficient for the purposes [described if possible] of system XX such that no additional validation will be required to ensure compliance with system XX, and no conversion unless according to rules that are stipulated within the scope of this contract, and as and when these data are required. You accept that we need make no provision for the inaccuracy or incompleteness of these data unless otherwise stipulated in this contract.’

The last thing that you want to happen is that you find yourself unexpectedly committed to developing a whole subsystem for the provision, validation and conversion of data.

Go-Live Support

Go-live support can last forever. Its function must be clearly defined. It is not consulting by other means, or training by other means. It’s supposed to be support to deal with functions that have failed, on the assumption that the client’s staff can already manage standard situations and standard exception conditions. In reality it is often more than this, and therefore you must be all the more careful to limit your obligation. Your FPP plan must clearly limit the number of days provided, with this part explicitly agreed with the client..

You might include a clause such as this:

‘You and we understand that your staff’s ability to manage the system depends not only on the quality and duration of the training we provide, but also on the complexity of the requirements you have given us, and on the ability and conscientiousness of your staff. We have agreed that the FPP includes a fixed number, NN, days of go-live support and we agree that if more days are needed, then these fall outside the scope of the FPP and will be charged separately.’


When project tasks or phases are delayed, we often find ourselves doing additional work whilst waiting for things to happen. If this is the client’s fault then it is unreasonable that we should bear this cost. You must therefore always include a clause such as this one:

‘Our estimates are based on an agreed project plan, which depends for its success and on-time delivery on both parties to the agreement. When there are delays due to whatever cause, additional consulting time is often incurred. When the delay is due to our fault then we must provide any additional consulting time at our cost. When the delay is due to your fault then we reserve the right to charge for any additional time incurred.’


Accurate scoping and estimating depend on the accuracy with which a client has stated his requirements. When it comes to a contract and scoping document these requirements must be restated without any ambiguity, and with ALL material assumptions stated. A material assumption is one which will affect your estimates. A crude example:

Suppose that you have included ‘product costing’ in your scoping. No qualifications, no stated assumptions, just ‘product costing’. You have assumed one cost and a specific method (perhaps the client has even told you to make that assumption). Later you have this sad conversation:

FD:      I understand that you think you’ve delivered product costing. You have, and it’s working nicely. But I only see one part of it.

YOU:   Thanks. Glad you like it. We’re glad to have finished it.

FD:      You haven’t finished it. You’ve only finished local costing. You’ve forgotten we’re an international company. We need to calculate product cost in USD too, using a slightly different costing method.

YOU:   But you didn’t say!

FD:      Did we need to say something so obvious. We assumed you knew. And anyway, you’ve signed up for ‘product costing’ and that’s what product costing means to us. And it can’t be much trouble to add it. A system like NEW SYSTEM should be capable of multiple costing methods.

YOU:   S**T (quietly)

What your scoping document and contract should have said is ‘product costing based on the XXXXX product costing method in local currency’ or something even finer.

In any case your contract should include a clause like this:

‘Our estimates are based on the definitions, data and descriptions contained in the scoping document and on no other assumptions, whether expressed verbally to us, or by means of any other written communications. If these are incorrect then you agree that we will charge for any necessary extra time incurred as a result of such inaccuracies, subject to your agreement that such work should be carried out. If these are ambiguous then we will attempt to agree on a reasonable compromise in terms of charges for extra work arising from an interpretation at variance with ours, and will seek third-party arbitration if we cannot agree.’

See also:

FPP – A Frightening Acronym

FPP – Estimating Fixed Price Projects

FPPs – Mitigating Some of the Risks

FPPs – More Pitfalls to Avoid


2 thoughts on “FPPs – Yet More Thoughts on What Could Go Wrong

  1. FPPs – Getting Paid and Getting Out – Adam Bager

  2. FPPs – You Need ‘Commercial’ Project Management – Adam Bager

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s