Tag Archives: project scoping

FPPs – Yet More Thoughts on What Could Go Wrong

Share

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

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

Delays

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

Accuracy

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

Share

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.

bananaskin

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.

See

FPP – A Frightening Acronym

FPP – Estimating Fixed Price Projects

FPPs – Mitigating Some of the Risks

Reports

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

Training

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

Documentation

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’

 

 

FPP – A Frightening Acronym

Share

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.

FPP

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

Selling

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.