Cost estimation methods must be quickly applicable – even without expert knowledge – to plan and control development projects reliably.
Recently in a development project in Aschaffenburg:
In order to plan the team size necessary for developing a new release in due time, a cost estimation is required. A colleague decides to perform an expert estimation. He breaks down the existing concept into many separate tasks and evaluates them based on his extensive experience in developing this system. His estimation takes a day’s work. The result is an estimated effort of 153 man days – which I do not know initially.
I start simultaneously with an indirect cost estimation. Also for me, the most important estimation basis is the concept. I count the dialog elements needed for inputs and for merely displaying data, the attributes required in the database and the data elements to be put out in reports. Due to the structure of our concepts, counting can be done almost entirely by Excel formulas. I transfer the counting results into a template, where they are weighted accordingly depending on types such as GUI input/output, GUI output-only, database writes, and so on. The result is then divided by an empirical value of our productivity, which I measured when the previous release was completed. My result: 153 man days. The effort required for the estimation: one hour.
Measuring and counting instead of rating and assessing
Basically, the counting of data elements based on a concept or the measuring of productivity has nothing to do with rating or assessing. It is a rule-based automatable task, and measuring the productivity of a development process, for example, does therefore not require more than one hour of human working time.
The accuracy of a cost estimation highly depends on the quality of the concept. Anyway, a detailed concept reviewed thoroughly by the customer is always necessary for planning and controlling a development process within binding conditions agreed by contract. However, a first rough cost estimation can be made by using indirect methods even prior to submitting a tender, for example on the basis of a requirements specification.
The key is a method for measuring functional size
Indirect cost estimations are initially based on the “size” of requirements to be developed. This value is then set in relation to an empirical value: Which “size” can the team develop within a specific number of man days? This is the principle behind the Story Point Method, which is very popular in agile development. Methods measuring functional size are more precise, however. A classic instrument is the Function Point Analysis (FPA), with the COSMIC Method being widely accepted, too. PASS uses the Data Interaction Point (DIP) Method, which is completely free of manual assessing and can therefore be automated easily and efficiently. More about these methods, examples of application, and comparisons can be found in the following recommended book:
Which methods do you use for cost estimations and what are your experiences?
Picture credit: Shutterstock