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.

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’