Is it a model? Is it a tool? Its ...
In this 7th article in the series on how to reduce risk in a cost investigation, we take a break from the process, to define terms that will be used in subsequent articles.
When the terms 'Tool' and 'Model' are used at Edif ERA in the context of a cost investigation, they have specific definitions. These definitions ensure that we understand each other and can communicate concisely; hence, reduce the risk of misinterpretation.
Figure 1 represents the increased levels of sophistication in software architecture used in communication between a computer and a human. For many cost models used on a desktop, laptop or tablet, the Operating System (OS) may typically be Microsoft (MS) Windows or iOS and the application may typically be MS Excel, MS Access or Witness. *
The 'tool' should be considered simply as a human-friendly means to interact with the computer (via the application(s), etc) and as such is independent of the data to be analysed. Tools my be developed for specific investigations or may be purchased from suppliers; examples of off-the-shelf tools include OPUS10 and TruePlanning. Typically a tool will permit input and storage of data, consist of equations / formulae / algorithms and permit presentation of output but have no data.
A very simple tool, which was constructed in a spreadsheet application, is illustrated at Figure 2. This simple tool permits values and source references for 2 data elements to be entered; the product of the values is derived through a simple formula; tool version is recorded for configuration control; cells are colour coded to ease use.
The tool becomes part of a model when a scenario specific set of input data is entered. This concept is illustrated at Figure 3 and an example of a model built with the previously discussed tool, is illustrated at Figure 4.
Figure 5 shows a different model; the tool is identical to that in the earlier figures but the input data has changed, as has the output; the input data and output represent a different scenario to that of Model 1.
The separation between tool and model also ensures that tool development and modelling are treated as different activities. Both require very different mind and skill sets so such separation is wholly appropriate. Tool development, cost modelling and analysis are the subjects for later articles in this series.
You views on these definitions and the consequences of the approach described would gratefully be received.
*Please note that other OS, spreadsheet, relational database management system and event based stochastic simulation applications are available.