Preliminary Contract
What
Preliminary Contract
How
The dish
Preliminary Contract
Ingredients
- Rich Picture
- System Definition
- Storytelling
- Storycard
- Preliminary Use Cases
- Other relevant ingredients from the PreProject Phase
Process
Gather the information produced in the Preproject Phase. The Preliminary Contract shall contain:
- A time schedule specifying when activities will occur and deadline for completing the Launch Phase
- Expected maximum price
- An estimate of customer involvement specifying who and to which degree you expect to engage the customer in the analysis
- Specify the result of the Launch Phase: Analysis Report, Architecture Design, Development Plan, Verification Specifications, Deployment Specifications, Product Documentation, Acceptance Document and Quotation
- Evaluation reports
- Specify the frequency of progress reports - daily, weekly, every two weeks, etc.
- Specify in which circumstances the general analysis can lead to termination of the analysis and possibly the project: Exit-points
- Specify the payment methods for the Launch Phase. We suggest time-based payment with a prepayment of 40-50% of the maximum price
- Specify the enclosures - Rich Picture, System Definition, Storytelling, Storycard, Preliminary Use Cases, etc. i.e. the artifacts produced in the Preproject Phase
What
Preliminary Contract - entering Launch
After the Preproject Phase, where it is the developer who invests time and money in the analysis, we now enter the Launch Phase, where it is at the customer's risk. The Launch Phase contains enough analysis to enable the developer to set a fixed price and time schedule for the development of the system-to-be, as opposed to the Preproject Phase which only contains a minimum of analysis giving the developer the ability of estimating the amount of time required for the Launch Phase.
To obtain an effective progress in the analysis, it is essential for both the customer and the developer to know what tasks will be initiated and when. Hence the developer shall prepare a plan specifying the activities in the analysis phase and highlight when interaction with the customer will occur.
Pricing the analysis phase is a difficult task, because the analysis in its nature contains a lot of unknown factors. For some projects it might be evident to set a fixed price for the analysis due to well-known systems or technologies. On the other hand, if the analysis proceeds faster than expected, the developer charges the customer a higher price than the effort actually required, i.e. the customer pays an overprice. Consequently, the developer must specify a maximum price for the analysis, and the customer only pays for the hours actually spent on the analysis.
In rare situations the analysis can turn out to be very complicated, for instance due to unknown technologies, organisational problems at the customer, market changes, etc. This may prolong the analysis far beyond the specified time schedule, consequently exceeding the maximum price. In these cases a negotiation with the customer must be initiated by the developer, and a decision must be taken either to exit the analysis or re-negotiate the price.
In respect of the customer's planning and especially her or his motivation and involvement in the analysis of the system-to-be, the developer must provide a plan that schedules when customer involvement will take place and how much time the customer should expect to invest in this process.
It is important that the customer understands that the result of the Launch Phase is a real product. In some situations the results of the analysis are twofold: Products with organisational impact and products with non-organisational impact.
As to products with non-organisational impact, the analysis concentrates on technical issues, i.e. functionality, hardware platform, etc.
As to products with organisational impact, there can be many critical issues which are at first glance totally irrelevant to the system-to-be, but due to organisational or work flow conflicts the analysis should deal with these issues. The result of the analysis is therefore a clarification of what the customer should deal with through work instructions, organisational changes, etc. The rest of the analysis concentrates on the definition of a simplified concrete IT-product in contrary to a complicated IT-system with built-in conflict solutions.
To keep the customer involvement at a high level during the analysis process, it is important to report to the customer frequently. The reporting shows the customer the progress in the analysis process and keeps the developer focused on the task. Additionally, any misunderstandings can be discovered early in the process thus keeping the necessary hours at the lowest level possible. The reporting can be done daily, weekly or every two weeks depending on the type and length of the expected analysis phase. Reports can be e-mails, separate documents and eventually the artifacts produced so far in the process. It is important to discuss with the customer what her or his expectations to reporting are.
Another important issue in analysing is to define 'exit-points'. They are points or reasons for stopping further progress. It is important for the customer that the developer does not just work the amount of time agreed upon after which his conclusion may be that the product is not feasible. For the developer reasons to stop can be the lack of the right competence in the development company in relation to handling the further process. For example, if an analysis reveals serious problems or conflicts in the customer's organisation, and the developer is not capable of handling those kind of issues, the developer can suggest the customer to engage external consultancy (e.g. human processes or work organisation). After the organisational problems have been solved, the analysis process can be re-initiated possibly resulting in a less complicated IT-system.
Payment is always an issue that can divide two parties. The developer needs to have confidence that the customer will pay the amount agreed upon. The developer may also need the money to finance the analysis process - a question of liquidity. With prepayment the customer shows commitment and confidence in the developer.
Consequently the Preliminary Contract shall at least contain:
- A time schedule specifying when activities will occur and deadline for completing the Launch Phase
- Expected maximum price
- Estimate of customer involvement specifying who and to which degree you expect to engage the customer in the analysis
- Specify the result of the Launch Phase: Analysis Report, Architecture Design, Development Plan, Verification Specifications, Deployment Specifications, Product Documentation, Acceptance Document and Quotation and Evaluation Reports
- Specify the frequency of progress reports - daily, weekly, every two weeks, etc.
- Specify in what circumstances the general analysis can lead to termination of the analysis and possibly the project. Exit-points
- Specify the payment methods for the Launch Phase. We suggest payment at an hourly rate with a prepayment of 40-50% of the maximum price
- Specify the enclosures - Rich Picture, System Definition, Storytelling, Storycard, Preliminary Use Cases, etc. i.e. the artifacts produced in the Preproject Phase
