Cost of change

There is little doubt that as the project life cycle progresses, the ease and practicality with which changes to the specification can be made decreases and the cost of making those changes increases.

It is a dangerous thing to try and represent this relationship in a diagram because every project is different but as an indication it may look like this:

 

Graph showing high gradient cost of change

 

Changes are always easy to make in the identification process because we are just beginning to capture requirements. During the definition process, we are firming up the requirements and maybe even producing some prototypes, but is still relatively easy and not too expensive to make changes.

Once we start delivering the outputs of the project, it gets harder and costlier to make changes. The steep curves above might be typical of a project with ‘hard’ outputs e.g. construction and engineering. Once you’ve laid the foundations of a building and built the first floor, it’s completely impractical to change the layout of the load-bearing structure. Anyone who has remodelled a house knows that it may be possible to demolish some walls and build others, but that’s not cheap.

Projects that deliver ‘softer’ outputs such as software or business change don’t have such extreme limitations. It may be possible to make significant changes to the look and feel of a web site relatively easily and cheaply by simply changing the style sheets. New features can easily be added that don’t affect the principles of the underlying architecture. In this context the same curves are shallower (once again this should only be seen as indicative):

 

Grapg showing low gradient cost of change curve

 

Understanding this principle helps to understand the degree of agility that can be applied in different contexts.

In ‘hard output’ projects, agility has to be focused in the identification and definition processes, which is why techniques such as Concurrent Engineering concentrate on the early phases of the life cycle.

‘Soft output’ projects can carry agility through to the delivery process, which is why projects that derive their inspiration from the Agile Manifesto can use techniques such as scrum as their way of implementing the development process.

These factors also have a significant impact on the requirements management and solution development functions. In hard output projects these are more focused on the identification and definition processes because we need a fuller specification before starting the delivery process. In soft output projects, much of the requirements management and solutions development can be performed as part of the development and delivery processes. The specifications produced in the earlier processes can be much looser.

Of course some projects will include both hard and soft elements and will need to blend differing degrees of agility into the governance of the project.

SHARE THIS PAGE

Please consider allowing cookies to be able to share this page on social media sites.

Change cookie settings
No history has been recorded.
Back to top