A cost model for software in capital projects

A growing number of capital projects, like a motorway tunnel or a specialised MRI scanner, needs software to make it a useful investment. To determine the investments in time, money and resources a number of key cost-drivers is essential:

• Delivery schedule
• Productivity
• Size of the software
• Required resource effort
• Quality

Each of these key cost-drivers has its own merits that should be taken into account to make the right decisions on how to integrate software in capital projects.

Delivery schedule

In most capital projects the investment in software development or integration is only a small portion of the total CAPEX. In a growing number of capital projects the project is only ready to be accepted when the software is properly functioning. In the case of the Leidsche Rijn motorway tunnel the opening of the tunnel was delayed for more than a year because the software was not working properly by the time the civil engineering part of the tunnel was ready.

Where the IT industry is currently largely focussed on delivering software within budget, misalignment of the integration of software in the schedule of a capital project can generate cost that are manifold. For the delivery schedule several general principles apply:

With a given productivity the relationship between delivery schedule and resource effort is described by the black line. A longer delivery schedule requires less resource effort than a tighter delivery schedule. This trade-off is bounded by two other laws that describe the “impossible zone” and the “ineffective zone”. The impossible zone is the area in the upper left corner of the diagram and describes the area where it is physically impossible to deliver a result, like building a river crossing in a day. The ineffective zone is the area in the lower right corner of the diagram where a project becomes ineffective. An increasing number of team members will have to work on the project on a part-time basis. In this way they will lose effectiveness because they have to split their attention over more projects. They will lose time because they have to restart their assignment on the project at hand when switching project. In the ineffective zone the theoretical reduction in resource effort will not be achieved.

For a given productivity this means that there is a point where the software integration or development can be done with a minimum of resource effort. This point comes with a certain delivery schedule.

There is also a minimal delivery schedule in which the software development or integration can take place. To achieve this delivery schedule more resource effort is required. These boundaries for the delivery schedule should be integrated in the general schedule of the capital project.

Productivity

Not all software can be produced with the same productivity. One high-level discriminator for productivity is the programming language that can be used to produce the required software. Each programming language is characterized by its generation. The first generation stands for the bits and bytes that devices and software use to communicate instructions and information. The fifth generation stands for models that generate software based on a problem description and preconditions on the possible outcome. Most common program languages are third generation (procedural structures) and fourth generation (conceptual descriptions) languages.

In software development the term productivity is often use to describe the software delivery rate – the number of hours it takes to deliver one (COSMIC) function point – which is in economic terms the reciprocal productivity. So a lower product delivery rate (less hours per point) means a higher productivity. This is very useful background knowledge when productivity is discussed with an IT service provider.

Size of the software

The size of the software to be developed or integrated influences the investment in more than one way. The first way is obvious: more software means a larger investment. The second is more complex: size has a significant influence on productivity. Experts are not in unison about the underlying mechanism and model.

A small software project is relatively expensive, because a relatively large amount of one-off cost to start the project must be distributed over a small number of units of measure. Up to a point where software can be produced under optimal conditions. This occurs when relatively small chunks of software are produced by a small and efficient team. From that point the product delivery rate rises to a point where the project becomes large enough to improve on productivity internally.

Size also has a significant impact on project success. Larger software development projects have a higher tendency to overrun schedule or budget and have an increasing risk on failing completely. To keep software projects cost effective and successful they should not be too large but also not too small.

Required resource effort

The major investment in software development or integration is in human resources. The impact of capital goods is usually small. The required resource effort is bound to the laws described under delivery schedule and is the result of productivity and schedule. Productivity is a property that is dependent on the programming language and organizational aspects. For a project they should be treated as fixed property. Schedule is – within the boundaries described earlier – a decision whether budget or schedule should prevail.

Quality

Software will virtually never be defect-free. The defect detection rate within a software development or integration project has a known pattern. Based on the defect detection pattern one can decide the point when the software is defect free enough to be accepted.
The right investment

When all aspects that are part of the cost model for software development or integration are taken into account they can be combined to the right investment in terms of budget, schedule and resources.