Martin Colebourne

There is a saying in development that “anything is possible”. It tends to crop up when designers ask whether something can be implemented. “Anything is possible”, the developers say, the implication perhaps being that they should not be seen as the limiting factor in this decision. The statement is probably true, but, of course, it ignores the fact that not everything can be implemented easily and quickly. Anything is possible, but some things will be expensive and take a long time. 

The question then should not be :“can this be implemented”, but: “can this be implemented within the timescales and budget of this project”. Framed this way, the problem becomes one for the stakeholders and project managers: How much investment do they want to put into the project? How much time is there? The more you invest, the more you get out.  However, I think that this debate misses an important point: the cost of implementation is not linear. Spending more time and money does not automatically produce a better result. Developers need to be good about helping other people in the process understand how the cost varies across the range of possible solutions; and designers need to understand how to frame their questions so as to get the information they need.

THE COST CURVE

I believe that in most projects and also in most subsections of a project, the cost of implementation follows a curve as shown in the following diagram.

The y-axis represents cost – a combination of money and time – this is simple enough. The x-axis represents the quality, completeness and ‘idealness’ of the implementation. This axis is initially tricky to understand, but it is important. The idea is that for most requirements, whether at an individual level, or at the level of a whole system, there are a range of possible solutions. Some of these are relatively easy, but less ideal; others are more ideal, but harder. For example, if you are unhappy with your house you can redecorate (easy); remodel and extend (harder); or knock it down and rebuild (very difficult).

For designers, there is a constant tension between creating simple, small-scale improvements; practical, pragmatic, but perhaps unimpressive redesigns; and exciting, crazy, blue-sky dreams. The question is often: How far should we push? How high should we aim? Shoot too low and stakeholders will be unimpressed; shoot too high and your work will never see the light of day.

This is where the cost curve comes in. The cost of implementing progressively more ideal solutions is not linear: it starts steadily, then turns sharply upwards in a phase where cost accelerates significantly, before levelling out again.

WHY DOES THIS HAPPEN?

During the first phase of the curve, designs are working with the grain of technology, which means that solutions can be implemented using of well-understood capabilities: basic coding and configuration, off-the-shelf libraries, and standard deployment methods.

During the second phase, designs move outside of the know space – they begin to ‘push the boundaries’ of the available technology and the knowledge and experience of the development team. This means that developers must spend time researching solutions, building proof-of-concept prototypes and turning these into reliable, deployable code. This takes significantly more time and effort than the first phase and brings with it a higher risk of failure.

During the third phase the complexity hurdle of creating new solutions has passed, and further development can occur on top of that base – in effect a new baseline has been established and the process can begin again.

WHERE SHOULD YOU STOP?

The answer to where on the cost curve you should aim to stop ultimately depends on the nature of the project:

Some projects have a limited time and budget – they need to deliver maximum value for the investment: In this case, you want to operate within the first phase – stopping just before the cost curve starts to shift upwards. This is the ‘golden point’ where a good result is achieved for a reasonable cost and within a manageable timeline.

Other projects are much more open ended, with a strong focus on research and development. In these cases, pressing on through the cost curve to deliver something new is the whole point.

However, in a great many situations, the right approach is to consider the project not as a single cost curve, but as a set of cost curves: one for each chunk of functionality. This way, the question becomes: where do we want to stop for each chunk of functionality? For the core value proposition of the project, it makes sense to invest and push through the expensive portion of the curve. But for everything else – all of the subsidiary elements – this would be a waste of time and effort. The right course of action is to work within the first phase.

Designers need to understand which parts of the the product are worth pushing for and in which cases it is important to keep costs under control. For those areas where investment needs to be limited, they need to understand from development what kinds of features and design approaches will push the cost curve beyond the golden point. This allows them to rework their designs to maximise the result whilst working within those limits.

Developers can use the cost curve to help discuss the relative costs of different choices with all stakeholders. Explaining where solutions lie on the curve doesn’t rule out any option, but helps to foster a more realistic discussion around requirements and prioritisation.