FPPs – You Need ‘Commercial’ Project Management


Project management skills are in short supply. Good project managers are rare, but you need to find the best of the best if you’re to make Fixed Price Projects (FPPs) successful. It’s not just a matter of getting things done on time, but of getting things done profitably for you, and to your customer’s satisfaction.

Although project management is often regarded as a specific skill, my own preference is that a project manager should have a good understanding of technical aspects of the project. Without this it is difficult for him or her to judge the plausibility of estimates, solutions and excuses.

project management

Good Commercial Project Management means:

  • Delivering the project at a level of quality that meets the client’s reasonable expectations
  • Delivering the project on time, assuming that the client has met his obligations in terms of timings, and assuming that the project manager has accepted the project plan
  • Delivering the project within estimated consulting and development days, assuming that the project manager has accepted the estimate
  • Ensuring that staff are motivated to deliver on time and estimate
  • Ensuring that the project meets its profit targets
  • Ensuring that the scope of the project is, at all times, well-defined and that all out-of-scope work is charged (usually through separately contracted Change Request Forms/Orders)
  • Ensuring that staff document their activities well enough to support all out-of-scope work if it happens either ‘accidentally’ or is agreed
  • Managing client expectations to ensure they are reasonable

When passing a project from the sales phase to the delivery phase it may be wise to document the salesman’s understanding of the client’s expectations. Does the client expect perfection? Is he willing to compromise? Is he reasonable? We might call this an ‘expectations audit’.

Collectively, when starting the delivery of a project, you must be able to answer these questions:

  • Does the client understand that a fixed price project is limited to a defined scope?
  • Does the client understand that estimates must be based on documented assumptions, specifications, and descriptions, and that if they are not, areas of imprecision must be highly constrained in terms of requirements (for example, if reports are not clearly defined)?
  • Does the client understand that it is we who can say whether a requirement is clearly stated or not
  • Does the client understand that out-of-scope work must be separately specified using a Change Request Form and that he will be charged?
  • Does the client understand that if we carry out extra work due to the mistakes of his staff or due to delays for which his staff are responsible, then he will be charged for this time?
  • Does the client understand that our fees are reasonable?
  • Does the client accept that compromise will sometimes be pragmatic if he is to obtain benefit from the project?
  • Does the client understand that his staff must be motivated, and encouraged, and must behave reasonably and cooperatively?
  • Does the client understand that software development is difficult?
  • Does the client understand that software quality is rarely perfect?

If the answer to many of these questions is ‘No’ then the salesman hasn’t done a good job, and a question arises as to whether the project is worth the risk. If it is, then all involved, and principally the project manager, must continue to move the client’s expectations towards the ‘optimal’ ones.

If a project manager is to manage a project well, he must keep in close contact with consultants and developers who are involved more deeply in the detail of the project, and must be alert to out-of-scope tendencies. It is also essential that time spent on the project be captured at task level so that comparisons with estimates (assuming, as one should, that estimates are drawn up at task level) can alert the project manager to commercially dangerous situations as early as possible.

If all of these and other issues have gone through your mind when considering, scoping, selling, planning and contracting a fixed price project, then you might just do it well.

See also:

FPP – A Frightening Acronym

FPP – Estimating Fixed Price Projects

FPPs – Mitigating Some of the Risks

FPPs – More Pitfalls to Avoid

FPPs – Yet More Thoughts on What Could Go Wrong

FPPs – Getting Paid and Getting Out


  • Ensure that client expectations are reasonable and that the client understands the implications and risks of a fixed price project from both his and our perspective
  • Ensure that scoping is as precise as possible and well documented
  • Ensure that initial estimates are based on well stated assumptions and are agreed by sales and consulting staff
  • Try to persuade the client to engage in a first clarification and design phase that is jointly funded and which will deliver more precise scope and estimates
  • Make sure that the contract protects you from the unknown unknowns, and that nothing is open ended
  • Make sure that staff are motivated to deliver on time and within estimate
  • Monitor task actuals continuously during project execution
  • Make sure that payments cannot be unreasonably withheld


FPPs – Getting Paid and Getting Out


I’ve listed so many risks associated with Fixed Price Projects (FPPs) that you may well have decided to avoid them entirely. That would be a mistake. If approached carefully, and with reasonableness on both sides of the contract, an FPP can be both profitable and the beginning of a long and mutually beneficial relationship, based on trust and understanding.

As well as all the other risks inherent in and FPP there is also the risk of not getting paid for it, or not being paid on time. This is a much greater risk in FPPs than in time and materials projects.

Not what you want to be doing…..

getting paid

Payment Terms

Most fixed price projects involve payment terms based on phase completion or the delivery of components of the project. There are many risks in this:


  • A client may unreasonably withhold confirmation of delivery or completion of a phase, and yet allow other phases to continue
  • A client may halt or suspend the project


In both cases you may have difficulty in obtaining payment.


Include a clause such as this in your contract:


‘Where payment is dependent on acceptance of the completion of a phase or upon delivery of stipulated components of the project you may withhold acceptance if grounds are reasonable. In such cases it is essential that you put in writing your reasons for withholding acceptance. You also agree to provide us with immediate opportunity for clarification and remedy. If you do not do so within two weeks of delivery or completion of a phase then you agree to pay us as if you have accepted the phase or delivery. Furthermore you agree that other phases and deliverables may be suspended until payment is made. You also agree that during the period of remedy, however long, and until payment is made, later phases of the project will be delayed and deliveries suspended.’

It’s also vitally important that you build in to your contract and into your project plan an (albeit early) option to escape.


Getting Out


If you can persuade your customer to engage in a serious design phase for the project so that final estimates can be made on the basis of clarified requirements, then do so. You will save money and reduce risk, even if you pay for half the days yourself. You will probably have put forward an initial estimate, of say 100 days, and you may find that you arrive at a new estimate of 200. In this case you must make sure that both the customer and you can extricate yourselves form the contract. You must have a phrase such as this:


‘We have made estimates on the basis of the discussions we have with you, and assuming certain circumstances, intentions and needs. Those assumptions that might materially affect our estimates are documented. Following an initial design and estimation phase of the project we may find that some material assumptions are false, and that other circumstances are not as we understand them now, and in this case we may revise our estimate. Both you and we reserve the right to withdraw from the project at this stage, or to renegotiate the scope of the contract.’


Your client may try to argue that in this case he has spent money for nothing, but you should and can very reasonably argue that he will have obtained a very much more precise idea of what an implementation project involves, and what can be done in the specified time. This represents real value.

See also:

FPP – A Frightening Acronym

FPP – Estimating Fixed Price Projects

FPPs – Mitigating Some of the Risks

FPPs – More Pitfalls to Avoid

FPPs – Yet More Thoughts on What Could Go Wrong

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


FPPs – More Pitfalls to Avoid


The key to successful Fixed Price Projects involving business system implementations is a good imagination, an imagination that encompasses everything that might go wrong, every misunderstanding or wilful misinterpretation by your client. And your client must possess the same imagination to protect himself or herself from you.

One impediment to this, of course, is that you are more experienced and more aware of the mistakes that both sides can make. You would be foolish to consider this an advantage. It is your job, whether the client thinks it’s necessary or not, to drag him or her through the tedious but essential process of project scoping. Nothing material should be left undefined.


In my last post I looked in detail at some aspects of scoping and contracting. In this, I’ll continue by addressing some areas that are often defined too vaguely – Report Development, Training and Documentation.


FPP – A Frightening Acronym

FPP – Estimating Fixed Price Projects

FPPs – Mitigating Some of the Risks


If you don’t say what a report is and don’t know what the client wants to see in his reports it is very dangerous indeed to make vague promises. If the client has the open ended opportunity to say what he wants in a report he can say anything and require anything of you.

Just suppose that you have a clause in the contract or scoping document that says ‘8 Management Reports’. He might say:

‘I would like a report that shows me the locations of all deliveries within a specific period, with a map on the second page showing the current weather conditions and forecast, some notes on the current local political situation, and a picture of the most interesting local marsupial’. And you would be legally bound to provide it.

Ideally, therefore, you should have a description of these reports in advance, and you should include such descriptions in your scoping document. These descriptions might be full pictures of the report and its layout, or might specify data items, summary groups, etc.

But if you have to be vague (‘8 management reports’) then you must include a clause such as this:

 ‘Our obligation under this agreement includes the provision of reports which are not yet defined in terms of layout , data items, format, summary levels, and so on. To reduce the risk of an obligation to create reports of any arbitrary nature, we therefore make the following assumptions: 

  • A ‘report’ means a document that presents data in a single format at detailed level and at specified summary levels. It does not involve repeated presentations, in different formats, of the same data. For example, if transaction data from an account are to be reported, a report that shows all transactions in date sequence, with summaries by calendar month, is one report, but a report that shows all transactions in date sequence, with summaries by calendar month, and then all transactions in sequence of transaction value, is two reports. 
  • All such reports can be created from the unaltered structures of an unaltered Version N of NEW SYSTEM and based on unaltered workflows and valiidation rules inherent in NEW SYSTEM Version N.


  • All such reports will be described once, and finally, and signed off by the client prior to development


We reserve the right to charge for any additional time incurred in developing reports which do not conform to the assumed definition of ‘report’ above, or which require extensive modification of the underlying data structures of NEW SYSTEM, or modifications to the application program to support non-standard workflow processes, forms or validation rules, or which must be modified due to the client’s change of specification.’


It’s hard to estimate how much time is required for training. It depends on the commitment and capabilities of the client’s staff as well as on your own skills. But you can be sure that the training you do will never be enough. You must protect yourself from the endless refrain of ‘I still don’t know how it works’. If the client needs more training than you have given he should pay for it.

It’s hard to enforce this, but it might help if you include such statements as:

‘Training is designed to teach users how to work with the system in standard ways and to deal with specific exception conditions (which will be described in the training plan). Training is limited to NN days, and trainees will be asked to confirm in writing that they have understood what they have been shown and taught. If additional days of training are required these days will be charged additionally.’


There are many kinds of documentation:

  • Project Plan
  • Requirements and Scoping Specification
  • Prototype Description
  • Training Manual
  • Procedure Manual
  • Technical Manual
  • Etc

The first two are essential tools for both you and the customer. The third, a prototype description, can be useful if you are designing and building a system using iterative prototypes. When the customer finally says, ‘Yes, that’s it. That’s what I want,’ it can be sensible to describe that carefully, with screenshots, so that he and you can sign off on it and you can refer to it if changes of mind occur later.

The other documents are ones that the customer will find useful during training or during system administration. Make sure that the customer knows what he is getting in these cases. You don’t want to be sent back again and again to your desk when he says ‘I want more. I want it described keystroke by keystroke.’ Provide examples, in the contract itself, or by reference to external examples, of what he will get and include a phrase such as this in your contract:

‘Documentation provided under this contract will conform in terms of appearance and level of detail with the examples provided (as specified in Appendix NN) and will exclude the following:

  • Instructions on the management of SQL databases, on the assumption that database administration is system independent and is described in manuals provided by Microsoft
  • Etc’



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 – Estimating Fixed Price Projects


I posted a blog a few days ago on Fixed Price Projects (FPP – A Frightening Acronym). FPPs frighten me because part of LLP Group (a part I’m happy to have sold) worked with the wonderfully open-ended Microsoft Dynamics business software products. We sold, scoped, estimated, and executed such projects poorly, to the extent that we made no margin at all, sometimes on hundreds of days of consulting, even whilst satisfying our customers. Our consultants and developers were no doubt excellent, but our sales processes and project management skills were insufficiently sophisticated and cautious.

Because of this I’m wary of FPPs, even if I know that they can be done well, can be controlled and can be profitable. To that end, I try to make sure that everyone in the company is aware of the risks and how they might be mitigated.

My last notes were about the Sales process. Here are some thoughts about Estimating.



Estimating is a process that must involve both the sales and the consulting/development team.

It’s a time-consuming business. But FPPs get off to a bad start if we calculate estimates poorly on the basis of incompletely understood requirements, and half-baked solutions. Even ten free days up front might save hundreds of days later.

Of course, it’s the sales team that has to sell the project and who, in conjunction with management, must decide on price (for a defined scope), but our sales and management team MUST listen to what the consultants have to say. If they say they must know more about the client’s requirements, then the sales team must provide them with more. Never be tempted to think ‘Well, if I add another five days or so, that’s bound to be enough’. It isn’t.

And ALWAYS add contingency to your estimate. (And then more.)

In the end it is a commercial issue as to whether you knowingly ‘sell’ fewer days than you know that you need to execute the project. Whether that is commercially wise or foolish has nothing at all to do with the deadly sin of starting a project with inaccurate estimates of how much time the project will actually take you.

What if your estimate is insanely too low, and you discover that once you’ve started the project?

Well, it’s important when creating an estimate to make your assumptions explicit. This isn’t a slippery way of avoiding commitment, a trick that you’re playing on the customer. No, it’s an honest statement of the basis for your estimate. If it turns out that there are material facts that you’re unaware of, then you’ll be glad to be able to go back to the customer and ask for more time. And make sure that you make it clear that it isn’t your fault that you didn’t ask. You need to include a statement like this one in your proposal:

This estimate is based on materials provided by the customer and discussions with [named individuals]. Whilst we have built a certain level of contingency into our estimates to deal with the unexpected, the following assumptions are material, in that if they are incorrect our estimates may be materially wrong in either direction. These assumptions are [examples]:

  • In valuing your inventory you use only one method of valuation, weighted average valuation in local currency in conformity with statutory tax regulations
  • In valuing your inventory you value it only in one currency
  • You have no need for lot tracking of purchased, intermediate or final products
  • Etc’


And very importantly…

  • Your staff are motivated and committed to the process of implementation and will provide timely support as required
  • Your staff will be available for the time that we have estimated is required of them’


If possible you should build the estimation process as a first step of the project itself, or present this as a project stage where estimates and assumptions are confirmed. If necessary, give some free days to this, since your risk is greatly reduced by it, and you have a chance to demonstrate competence.

But if you do this it is also important that you build into your contracts an escape clause.so that both parties can terminate the contract or renegotiate it if the estimates or assumptions turn out to be incorrect.

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.