Data Collection and Checking

Part of the Decision Engineering book series (DECENGIN)


Data collection is one of the most important step for being able to prepare future cost estimates — as reminded in the previous part — as the only way we, as human beings, are able to forecast the future is by extrapolating the results of past experiences.

A first question which has to be answered is: What data should be collected? In the cost domain it is impossible to “generate” data and we have to live with the data we can get. However, experience shows that most data are incomplete and therefore sometimes unusable. This chapter starts by reminding this fact and insists on the fact that a cost by itself is worth nothing if what is measured in this cost is not properly defined: economics, product description, list of activities, abnormal phenomena, etc.

It also reminds the fact that (and this regards mainly large organizations) internal costs should also be considered, especially if the ratio between external and internal costs changes from one project to another one.

Expert judgments are very interesting pieces of information and should be added, each time it is possible. In this domain one important point is to be able to cope with the experts’ subjectivity which is a normal phenomenon. This is generally speaking difficult to detect; one way is to check the experts’ consistency; this chapter gives some hints in this respect.

Large organizations (and sometimes small ones) must subcontract projects or parts of projects. Contracts are important data if the price figures are properly displayed which means that:
  • The prices hierarchy should be the same for all projects. For instance the same product breakdown structure (PBS) must be used for the different types of projects such as production and development: the basis of the structure should therefore be the product structure.

  • Product/activities descriptions should be added: generally product/activities descriptions are not given in parallel to price description, which makes price allocation difficult.

  • Details must be given. Most often details are present in the proposals but are not updated in the contracts, especially when negotiation is made at the project level.

This means that the structure should be a two dimensions matrix: one dimension should be the product structure, the second one being the activities. Quite often both structures are mixed: this produces the common work breakdown structure (WBS); this may be sufficient for small projects, but for large projects, we advocate the two dimensions matrix structure.

There is a normal trend towards fix price contracts as opposite to cost plus fee contracts. This is quite understandable for both parties. However, organizations must know that, in doing so, they loose a lot of information; this loss must be compared to the advantages of using these fix price contract.


Unable to display preview. Download preview PDF.

Unable to display preview. Download preview PDF.

Copyright information

© Springer-Verlag London Limited 2006

Personalised recommendations