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