FPPs – Mitigating Some of the Risks


I’ve written two sets of notes on the risks of Fixed Price Projects in the world of ERP implementations. My own experience at LLP Group has taught me that the more thought and definition you invest in a project before it’s started, the lower the risk for both you and your client. This is true irrespective of whether you are undertaking a fixed price or a time and materials project.


FPP – A Frightening Acronym

FPP – Estimating Fixed Price Projects

Although you would hope never to have to refer to it once a project has begun, the contractual paperwork and the project scope and definition that it refers to or contains, are of vital importance in establishing an understanding between you and your client. If you don’t encapsulate your thoughts, ideas and discoveries in these you might as well not have bothered. Protection is essential both for you and your client, and the best protection is a clear understanding precisely documented.


Contracting and Scoping

When you enter into an FPP agreement with a client inaccuracy is the devil, ambiguity is the killer, imprecision is the plague. There should NEVER be a list of tasks that includes completely unqualified items such as:

  •  8 Management Reports
  • Assistance with Data Import from legacy systems
  • Support during Go Live
  • Documentation
  • Etc

What’s wrong with these? They are open ended. What sort of reports? (And what is a report, anyway?) How much assistance with Data Import, and what legacy systems, and how many times? How long is Go Live?

So, an FPP must be well-scoped with dozens of pages of definitions and clarifications, and descriptions of what the client will get. And if all of this is done with a client who understands the FPP game, that both sides need protection from undue risk, this is perfectly possible. We should do it even if we don’t get paid for it. Ten days given for nothing before the project begins saves hundreds lost later. And if you do it well, you also have a chance to impress the client with your understanding.

These are some typical areas of risk:

  • Data Import/Transfer from Legacy Systems
  • Reports
  • Training
  • Documentation
  • Interfaces
  • G0-Live Support
  • Delays
  • Accuracy
  • Payment Terms
  • Get-Out Options

Let’s look at some of these:

Data Import/Transfer from Legacy Systems

This needs to be qualified:

You must list the systems from which data will be imported and the data items

You must quantify the data – how many records?

You must make it clear that you assume that the data are ‘clean’ (i.e will not fail repeatedly on import because they don’t conform to the requirements of the new system)

You must specify the format in which data are to be provided and make it clear that you are not responsible for and estimating for the job of exporting the data from these legacy system

Your scoping document and contract should include a clause such as this:

‘Our obligations under this agreement include the importing by us of data into NEW SYSTEM. To reduce the risk of an open-ended obligation to spend an unlimited time on this task, we assume that:

  • These data can be provided by you to us in text-file or Excel formats as specified by us and at the time specified in the agreed project plan, or if delayed, as notified to us with at least two days’ notice
  • These data are ‘clean’ in the sense that they conform to the parameters of NEW SYSTEM and do not need repeated correction and reimport (we assume that import will succeed by the second attempt)
  • You confirm the correctness of the data in NEW SYSTEM in writing before any dependent tasks in the project commence
  • Volumes do not exceed nnnnnn records from system x, nnnnnn records from system y, etc


We reserve the right to charge for any additional time incurred during the process of data import if any of these conditions is not met.’


Next time I’ll look at some more areas of risk that need careful mitigation.

FPP – A Frightening Acronym


There’s nothing more frightening in the world of consulting, especially IT consulting, than the Fixed Price Project (FPP). We avoid them if we can.

Customers, on the other hand, love them, or the idea of them. And they often set out on their software procurement path with the conviction that it’s their best option. But for both parties, supplier and customer, the result of a poorly scoped FPP can be disastrous, with the customer rueful that he didn’t describe his requirements precisely enough, and the supplier digging in his heels and delivering only what has been precisely contracted. Even if additions to scope are carefully managed using Change Request Procedures the final result will come at a cost to the customer that is far higher than anticipated.


The problem is that knowing precisely what is needed in advance is difficult for the customer, and understanding precisely what the customer requires is difficult for the supplier. If the project is a large one, and will bring radical change to an organisation, you really need to do a scoping project before the real project begins, but most customers are reluctant to approach FPPs that way.

LLP Group and systems@work regularly undertake FPPs but always cautiously. Generally we work with software that is configured rather than adapted at source code level, and this helps, since the configurable options are constrained. When a software package allows unlimited possibilities through source code change and extension, the dangers are huge.

We’ve tracked the difference between estimates and actuals for FPPs over several years using our time@work professional services management product, and the results are not entirely as I would wish them to be, though there’s a gradual improvement. In recent times we’ve end up doing about 25% more days’ consulting than initially estimated.

FPP Trends

These are some notes I’ve written for our sales and project-management teams on risk avoidance:

Notes on Fixed Price Projects

Fixed Price Projects (hereafter FPPs) often end tragically, with actual consulting and development days greatly exceeding estimates. They can result in bitter argument with the customer, who may believe you have promised him everything for nothing.

The key to happy FPPs lies in intelligent selling, intelligent estimating, intelligent scoping and contracting, and good commercial project management. The key to the avoidance of bitterness is good management of client expectations.

If client expectations are not managed well, these are the possible outcomes:

  • In a minority of cases, a profitable project delivered on time and on budget, and a happy customer (who doesn’t know how lucky he is)
  • More often, a deeply unprofitable project and an adversarial client, or,
  • Worse still, legal action

If client expectations are managed well, then a good outcome might be within your grasp:

  • A profitable project (even with all necessary extensions) and a reasonable and satisfied client


Managing client expectations starts during the selling process, when you must help the client to understand how things look from our perspective:

  • That FPPs are a risk for us, unless we know clearly what he expects, in advance
  • That FPPs depend as much on his contribution to the project as on ours
  • That, in return for the risk we take, we must impose reasonable constraints on what can be expected and what can be delivered
  • That both we and the client benefit from an appropriately constrained project, in terms of delivering benefits on time

Often the client thinks it’s obvious what he wants and needs and he’ll say things such as:

  • We just need what everyone needs. Nothing special. It’s obvious.
  • You’ve done all this before. It’s what you do. You know what we need.
  • I want what that other client has.

In the face of such confidence it’s difficult to demur and say, ‘Well, actually, I need to know more. I need to ask you some questions.’ The temptation is to say ‘Yes, I can do that.’

But never say ‘Yes, we can do that’ unless you know precisely what the client means by ‘that’ and you can make reasonable estimates as to how long it will take us to do it. You’ve got to make the client understand that our profession has its established ways of doing things, that this involves questions, discussions, presentations, analysis, imagination, design, and so on..

It’s even possible that by insisting on our processes, and through seeking a detailed understanding of what the client wants, by showing that you can describe it well, and appreciate the benefits it will confer, you are also establishing your own skills in his eyes. ‘Yes, we can do that’ tells the client nothing about your own skills and understanding. Don’t forget that saying ‘That can’t be done at reasonable cost’, or ‘We don’t think you should do that’ can impress the client even more, if done well!

The process of selling an FPP has to be even more disciplined than the process of selling a time and materials project. Time spent describing the client’s needs, outlining a solution, demonstrating your understanding and wisdom, even if this time is commercially non-recoverable, is time well spent, especially if it’s accompanied repeatedly by assertions and explanations that the client will get ‘that’ and only ‘that’, unless changes are requested and estimated separately during the course of the project.

And it’s important that until there is a clear description of the client’s requirements and a proposed solution, nothing should be said about price. And, even more painfully, nothing should be said about price until our consulting team (and that means at least one good consultant and a services manager) have given you some idea of how long the project will take. Regardless of how many days you’re going to sell, you must know accurately how long it’s going to take.

So, to summarise, an FPP price proposal must be preceded by:

  • Your establishing the consulting process in the client’s mind
  • A detailed description of the client’s requirements
  • An outline of the solution you propose
  • An estimate of consulting and development days signed off by a senior consultant and a services manager, with material assumptions clearly documented
  • Confidence that the client understands the FPP game

In fact, client expectations are at the heart of the entire process from selling to delivery. There must be a continuous and seamless process, beginning with sales, that aims to establish optimal client expectations:

These include:

  • That in return for taking on the risk of an FPP we expect that the client will meet reciprocal obligations:
    • Accurate descriptions of requirements
    • Timely and accurate delivery of data and clarifications
    • Cooperative and positive behaviour
  • That with the best will in the world, we, and they, will make mistakes
  • That client staff must expect disruption and in some cases a heavy commitment of time to the project
  • That software is fallible and that bugs may need to be corrected before go-live or worked around
  • That software development is notoriously difficult and that perfection is expensive
  • That our fee rates are reasonable, based on the utilisation we expect, our investment in training, the relatively high salaries that consultants command, realisation that is lower than 100%, management costs, and overheads


If all of these things are clear during the sales process, then there’s a chance that we and our customer will end up satisfied.

Next time, some notes on Estimation.