Make Leather Soft And Shiny

The fixed-price fiasco

once followed a false alarm on the night bell - it's never make good. (Franz Kafka: A Country Doctor)

What is screwed up in the fixed price offer can not be repaired more often throughout the project. Accordingly, like developers are reluctant to give a cost estimate (" it takes just as long as it takes "), especially if you still do not know what exactly sooo in the project will ever be made. The customer wants to know just very early, and who wants to blame him: he must organize a budget before the project began. Would you build a house (and massive personal debt) without knowing what it costs? Exactly.

first Ideally, one makes a technical calculation based on a concept paper and a technical analysis. This one has both, unfortunately, in the rarest cases.

second If it is for the technical requirements of a tight briefing (" we like our website will expand to a shop system ") attacks the principle of " An application at the earliest then be calculated if you can imagine, as a user . So one has to list all pages and all processes and can roughly describe. If those descriptions do not exist, it must be indicated on the basis of a short workshops or Telephone conversation with the customer or alternatively make assumptions based on himself. This then comes as a tender in the offer.
is whether the request later in the project to be implemented just not that important, it is important to have a description against which you can define additional expense, if needs change (and that is used in the design phase safety ) to pass. The more inaccurate the description in the offer, the more likely it is that the customer wants is something which is more complex than originally kalkuliert.Im area of the business requirements you can get by a little detail work project risks pretty well under control. This applies to the following item 3 only restricted.

third If the technical analysis is not available, one can try to make at least a brief search and a short prototyping an overview of the unclear technology or interfaces to get. For technical risks, there are different technical requirements for no power to mitigate through boundaries in the offer. The customer is what counts no matter what their requirements are solved by technology, so it makes no sense to formulate assumptions on offer, because if they do not apply is not a change requested by the customer but quite simply the wrong assumptions of the service.
exception interface to external or customer systems. Here it is quite common to write something like "assumption: the product data is provided by a SOAP web service available by the customer."

4th be happy to forget quality assurance, deployment into the live system, documentation, etc. is also here: delimit delimit delimit,. Since this is not quite trivial example in technical documentation (because you can define the level of detail is difficult) you must make do with crutches, such as: "Development of technical documentation, scope about 20 pages. Even if the page number here seems entirely reasonable free, they still fulfilled the purpose impart at least a rough idea of performance.