Preliminary Contract

From EUDP
Jump to: navigation, search

What

Preliminary Contract


How

The dish

Preliminary Contract

Ingredients

Process

Gather the information produced in the PreProject Phase. The Preliminary Contract must contain:

  • A time schedule for when activities will occur and with a deadline for completing the Launch Phase
  • An expected maximum price
  • An estimate of customer involvement, i.e. who and to what degree you expect to engage the customer in the analysis
  • A specification of the result of the Launch Phase: Analysis Report, Architecture Design, Development Plan, Verification Specifications, Deployment Specifications, Product Documentation, Acceptance Document and Quotation
  • Evaluation reports
  • A specification of the frequency of progress reports - daily, weekly, every two weeks, etc.
  • A specification of the events in the general analysis that can lead to termination of the analysis and possibly the project: Exit points
  • Payment methods for the Launch Phase. We suggest time-based payment with a prepayment of 40-50% of the maximum price
  • A specification of the enclosures: Rich Picture, System Definition, Storytelling, Storycard, Preliminary Use Cases, etc. i.e. the artefacts produced in the PreProject Phase.

What

Preliminary Contract - entering the Launch Phase

After the PreProject Phase (where it is the developer who invests time and money in the analysis), we now enter the Launch Phase. This phase 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 option to estimate 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. Therefore, the developer shall prepare a plan specifying the activities in the analysis phase as well as highlight when interaction with the customer will occur.

Pricing the analysis phase is a difficult task, because the analysis in its nature contains many 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, i.e. due to unknown technologies, organisational problems at the customer's premises, market changes, etc. This may prolong the analysis far beyond the specified time schedule, consequently exceeding the maximum price. In such cases, a negotiation with the customer must be initiated by the developer, and a decision must be made either to exit the analysis or renegotiate the price.

In terms of the customer's planning and in particular his/her motivation and involvement in the analysis of the system-to-be, the developer must provide a plan that shows 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 cases, 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, completely 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 simple IT product as opposed 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 allows the customer to view the progress in the analysis phase, and it keeps the developer focused on the task. Additionally, any misunderstandings can be clarified 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 emails, separate documents and eventually the artefacts produced so far in the process. It is important to clarify with the customer what her or his reporting expectations 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 he/she might conclude that the product is not feasible. Reasons for the developer to stop may be the lack of the right competencies in the development company to continue the process. For example, if an analysis reveals serious problems or conflicts in the customer's organisation, and the developer is not capable of handling such 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 the 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 a deadline for completing the Launch Phase
  • The expected maximum price
  • A estimate of customer involvement specifying who and to which degree you expect to engage the customer in the analysis
  • A specification of 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
  • A specification of the frequency of progress reports: Daily, weekly, every two weeks, etc.
  • A specification of the circumstances in the general analysis that may lead to termination of the analysis and possibly the project. Exit points
  • A specification of the payment methods for the Launch Phase. We suggest payment based on an hourly rate with a prepayment of 40-50% of the maximum price
  • A specification of the enclosures: Rich Picture, System Definition, Storytelling, Storycard, Preliminary Use Cases, etc., i.e. the artefacts produced in the Preproject Phase.
Retrieved from "http://eudp.net/index.php?title=Preliminary_Contract&oldid=419"