My previous posts have discussed the basics about value driver modelling (VDM) and how to build a well designed VDM-based model. The purpose of this post is to explore a practical implementation of VDM through a value calculator.

I’ve seen the introduction of value calculators transform the way organisation’s think, plan, track and report on the benefits of their projects. One of the clearest examples I’ve been involved in was developing a value calculator to model the benefits of combining two coal mines located next to each other.

The challenge facing the owner of these two coal mines was how do they decide if they should combine two multi billion dollar mines based on the potential value of 74 different but interrelated benefits. To provide certainty for the owner all the different benefits were explicitly mapped through a benefits dependency network diagram. These relationships were then combined with the 74 benefits, modeled through a sequence of value driver trees resulting in a report that showed which benefits best worked in combination with each other, what the different permutations of options were and did it all without double counting interrelated benefits. In this particular project, we identified $1.4 billion dollars in profit over 20 years.

While I have seen this tool be useful in the mining’s operations, I’ve also seen it used successfully in other sectors like retail and other functions like procurement. I’m currently developing a VDM tool based on elements of organisational psychology to value the benefits of human capital investments – an area that has historically performed poorly when building robust business cases for change.

What is a value calculator?

A value calculator is a tool that uses VDTs to dynamically calculate the benefits arising from improvements. A value calculator is the tool that allows VDM to be used across all stages of the benefits realisation process. It is particularly useful during when quantifying and prioritising benefits.

What does a value calculator do?

A value calculator’s primary purpose is to value improvements across the operations of an organisation. It can provide a valuation that incorporates the constraints and dependencies unique to that organisation’s specific operations. The tool is able to value improvements as either individual changes, or as part of larger projects or programmes of change.

The development and delivery of a value calculator, as part of a proejct, could happen in a number of different ways. Below is an example, generic project plan that delivers a value calculator for an organisation. The process itself if agnostic of any industry or company and could be used to deliver either small or much larger value calculators. The key elements to be mindful with this plan are that it allows sufficient time for good design. It also ensures that the tool is built in modules so that it can be progressively validated and tested. While this plan is only focussed on delivering a value calculator, it is equally possible for a value calculator to form part of a much larger project focussed on benefits realisation and cost reductions.

The seven components of a value calculator

So now that we know what a value calculator is and what it does, let’s look at the components that go towards making it work.

1. Parameters effectively the value drivers for the tool. That is, each parameter represents a box on your VDT.
2. Baseline data populates a realistic, “current state” of the operations you are modelling. This data is effectively the value of the inputs that go inside the boxes on your VDT.
3. The list of improvements change the value of the baseline data with the parameters. Changing these values reflects an improvement occurring within the operations.
4. The value stream is a series of connected VDTs, each flowing into the next. These VDTs are effectively the engine that drives the calculation of the benefit.
5. The benefits are the output of the VDTs. It could be expressed as an increase in profit, decrease in costs or increase in production.
6. Dependency groups are groups of improvements whose outputs are somehow connected to each other. A dependency group applies a maximum, minimum, average or cumulative rule to a set of parameters. This means that the calculator can determine how a complex programme of improvements should interact with each other.
7. The last component is the application of constraints to the benefits. As I have discussed previously, these constraints are built into the VDTs to limit an organisation’s ability to create value based on the reality of their operations.

How to navigate a simple value calculator

Now we’ll go through an example value calculator. You can download an example create in Excel here (note that I don’t recommend building value calculators in Excel as its difficult to update data, conduct advanced statistical analysis or to quickly and intuitively report findings).

Open the workbook and on the second spreadsheet you’ll see a value chain for an open-pit coal mine. This will be the context for our example (keep in mind that VDM can apply to different sectors and different functions, so think through how this modelling could be used for your context).

You might recognise part of the diagram below as the components of a simple value calculator. I’ll go through and show you how these components translate into the example Excel document.

• The grey boxes show the structure of the simple value calculator. Each box is a spreadsheet in the workbook and each spreadsheet produces an output that feeds into the next spreadsheet.
• The select improvements spreadsheet allows a user to turn improvements on and off in the calculator.
• The define improvements spreadsheet lists all of the parameters and how they change with each improvement.
• The determine dependencies spreadsheet defines how different improvements interact with each other.
• The allocate improvements spreadsheet lists out the individual changes to every value driver in your VDT.
• The calculate benefit spreadsheet contains the VDTs that calculate the benefit of the changes.
• The report benefits spreadsheet summaries the benefits for a chart. Now that you have an overview of the calculator let’s have a look at it.

Overview of the haul coal process

So that you can better understand the context of this tool, I’ll briefly go through the VDTs for the haul coal process. The VDTs are located on the Calculate Value spreadsheet where I have used a series of VDT tables. I have created a table for each piece of equipment operating at this mine. This is quite a small mine with only two trucks and one loader.

There are three main parts to these VDTs.

1. Time is calculated by starting with the total number of hours in a year, then subtracting all the lost hours due to maintenance, repairs and other delays. The result is an amount of hours called Operating Time, which is the amount of time a piece of equipment operates productively.
2. The productivity section describes how often a piece of equipment completes a cycle of tasks. In this context, the cycle means how often a truck completes a dump run or an loader fills a truck.
3. Payload represents the average amount of material a piece of equipment moves.

We can multiply all these value drivers together to calculate the total amount of material moved a year. This calculator applies improvements to all the value drivers in these tables in order to calculate an improvement.

How does the value calculator know what to improve and by how much?

Benefits extraction describes the process of identifying, defining and allocating improvements to your VDTs. You can see this process work by using the tool.

1. First, select some of the improvements from the options we have available on the select improvements spreadsheet. For example, select the two projects under the reduced casual idle time due to better people management hypothesis.
2. Next, on the define improvements spreadsheet, you can see which parameters for the VDT match up with each of the improvement projects as well as the extent of the improvement. For this tool all improvements are described in terms of a percentage improvements. You’ll also notice that the projects that you’ve activated have their value flow through to the calculating value column. This is also where you define the dependencies between improvements.
3. The next stage of the calculator is the allocate improvements spreadsheet. Here you’ll see that the improvement percentages from the parameters defined in the last spreadsheet are allocated to each piece of relevant equipment. These percentage improvements are applied against a baseline in order to calculate what the new improved performance will be. The baseline productivity could be different between every type of machinery, so the improvements are applied at the machine level (you could also make an assumption that improvements are applied at a fleet level and roll-up all the parameters that you see defined here to a fleet level). So, these improved percentages are what will flow through our VDTs.

How is the value of the improvements calculated?

The baseline information in this tool provides the basis from which to apply our improvements. The baseline represents a point in time for our model and should best reflect the context within which our improvements are applied. In this tool, we have baseline information for every value driver.

It’s best to establish your baseline through analysing historical data. It’s also possible that you’ll need to fill in the gaps using technical specifications, expert assumptions and your own observations. An important limitation to note from this particular value calculator is that it is based entirely on averages. The statistical variance that is inherent in operations of any description, are not considered here.  It is possible to design a more sophisticated model that uses VDTs driven by statistical variance instead of just the mean.

How does the value calculator avoid double counting benefits?

On the define improvements spreadsheet is the Dependency Group column. This column allows the value calculator to group improvements together when their outcomes are dependent upon each other. In this instance, we see that the Stand in Operators and Optimise Hot Seating improvements both affect the same outcome, Truck Operating Standby. The dependency group is called Idle Time Management.

We can modify the behaviour of this dependency group by going to the determine dependencies spreadsheet.  On that spreadsheet you’ll see the various behaviours that this group can exhibit. In this instance the min attribute has been select and is being used to calculate the benefit of the improvements. The min attribute means we expected the minimum benefit from the combination of the two improvements to flow through the operation. Depending on the change, any of these four behaviours could be possible.

How does the value calculator visualise the improvements?

The report benefit spreadsheet visualises the culmination of all the value calculator’s analysis. For this calculator, there’s one graph showing the mine’s hauling and loading capacity. It also shows the total change in tonnes for the improvements selected.

If this were a real operation you’ll see (if you were to turn on all the improvements) that productivity is currently constrained by the amount of material it can haul. Accordingly, any improvements for loading would be wasted because there wouldn’t be any hauling capacity to match it. This is a clear example that demonstrates how a value calculator can clearly show which improvements, and in what combination, will actually benefit an organisation.

Have a play with different combinations of benefits and follow them ‘through’ the model to see how each section takes an input, transforms it and then passes it on the the next stages in the model.

The next post will be the final for this series and will explore, in more detail, other ways that value driver modelling can be used.

Early in my career as a management consultant, a colleague and I were working on a project for a large gold mining company. The mine had more improvement opportunities than they had funding for and so wanted to ensure that they spent their limited capital on the best possible combination of opportunities. They needed four months worth of modelling completed in two weeks to meet budget deadlines. So, we locked ourselves away in tiny, windowless room with a steady supply of coffee and ingenuity and two weeks later we had created two value calculators identifying 35 million tonnes in increased productivity.

I’ve taken what I learnt from that project, and many like it, to identify 15 principles that allow you to successfully use value driver modelling and avoid many of the pitfalls that can derail a project.

These principles group into three broad categories:

1. Building a model
2. Using correct logic
3. Working with data

Building a model

1. Prioritise the model’s features

Often on a project you will have more requirements expected of you than time to deliver them. Prioritisation will help ensure that the most important features are completed within time and budget. It also allows you to understand the broader purpose of the model and not get distracted by minor problems or features.

There are many ways to prioritise a model’s requirements. I’ve used the matrix below which is based on the factors of “importance” and “ease of implementation”. An alternative approach is the MoSCoW method. This is particularly useful if you have a client who has a clear understanding of what they want.

2. Model in a single direction

To avoid confusion, VDT elements should only exchange inputs and outputs from with other elements of the same level or one level above. This ensures simplicity and reduces any unforeseen interactions between entities. To illustrate why this is important, picture a factory making widgets. The manufacturing process moves forward from delivery of raw resources, processing, manufacturing, packaging and delivery. The creation of  value (in this case, the widgets) goes from one stage to another; widgets never go ‘back’ through the process.

3. Build and test a prototype model as soon as possible

It’s rare to have a model perfectly and completely documented at the start of a project. Additionally, you may have a client who doesn’t really know what they want until they see and use it. To avoid spending time and money developing a completely polished product that the client does not want, instead produce a working prototype as soon as possible. This will quickly highlight the actual requirements for the model and allow you to focus your efforts for the rest of the project. Even if the entire prototype is discarded, so long as it contributes towards progressing the project, it was still worth producing.

4. Develop the model as a series of interrelated modules

Overly complicated models are difficult to troubleshoot which creates the risk of inaccurate or unpredictable outputs. It also becomes difficult to expand if new features need to be added. It’s best to design the model into modules that can be developed and tested independently. It also allows you to reuse similar modules for other models that require similar features.

5. Structure the model flexibly so that it is responsive to change

A potential risk with models is that they become quickly out-dated because of changes over time. If the model’s context is likely to change, identify those sections most at risk, and spend additional time building in flexibility. Typically changes that you will need to anticipate include expanding the scope and number of inputs (e.g a new call centre is added), create in new inputs and outputs (the model is expanded to include ‘delivery activities’ for a factory) and new data is updated (e.g a new set of cost figures).

6. Use assumptions to ensure the model is both deliverable and useful

Not all of a client’s operations can be understood to the level of detail required to model it. However, often complex issues can be resolved through making reasonable assumptions. For example, does the model need to output daily figures, or can results be aggregated by month.

When making assumptions, there are some key issues you should consider:

• Has the client and/or the subject matter expert signed off on the assumptions?
• Are the assumptions clearly recorded along with their value and rationale?
• Do you understand how the assumptions impact the model’s output?

7. Elicit clear requirements for specific end users

‘Use cases’ are an intuitive way of working out exactly what a model needs to do. Use cases like the example below explains the relationship between a user, their requirement and the resulting benefits from using your model.

Using correct logic

8. Use well conditioned formulas

A model could be poorly designed such that its outputs were very sensitive to small changes to its inputs. For example, the diagram below for widgets calculates the Widget Conversion Rate by subtracting the Statistical Rate from the Historical Rate. However, a 1% change in the historical rate drives a dramatic increase in Hourly Widget Production. This is called ill-conditioning and there is no automatic way of detecting the problem nor is there an obvious solution. However, thorough testing should highlight the problem. Then using an assumption, for this example, changing widget conversion rate to a static value may solve the issue.

9. Ensure rounding is consistent

The prevailing level of accuracy is limited by your least accurate result. This means that despite having value drivers with various decimals, the highest level of rounding is the most accurate. For example, the widget conversion rate inherits the level of rounding from the historical rate. In turn, the hourly widget production value driver, inherits the level of rounding from sheet productivity.

10. Select the appropriate method for modelling the distribution of your inputs

There are different ways of modelling an organisation’s variability. Simple value driver models use a conventional approach by using averages. More sophisticated models can use statistical methods to simulate the changes in productivity that real organisation’s face. Additionally, these advanced models can simulate the dependencies between value drivers highlighting the inter-relationship between key parts of the organisation.

11. Avoid feedback loops

Avoid inputs that become their own outputs. While this example below is overly obvious, in more complicated models it important to know how your inputs are being calculated and if those assumptions impact the accuracy of your results.

Working with data

This final section deals with a series of universal truths concerning the data you use in your models.

12. You cannot get all the data you need

You can never get all of the data you need. A complete set of the data you require for project will not exist. And the data you do received will most likely have been collected for purpose extraneous to your own. However, you can use the principles we’ve already discussed like use cases, assumptions and prioritisation to overcome this issue.

14. You cannot use all the data you have

Despite not being able to get all the data you need, you may be overloaded by the data you do have. Picking the information you use is very important, as it will form your model’s point of view. Information from different sources at best will be slightly different, at worse will be contradictory. Ensure that you understand the limitations and assumptions behind your data to ensure that it matches the reasons for you to use it. Lastly, when dealing with massive data sets, you can improve the performance of your model by only loading the data that you need. However, ensure that the model is flexible enough to broaden the scope of the data in case requirements change.

14. You will need to produce your own data

You always have to develop some of your own data. Not all the data required to build the model will exist in a system already. You will need to work with the client, key stakeholders, subject matter experts. You may even need to go out into the field to ensure that information that is critical to the model is collected accurately and completely.

15. You will need to synthesise your own data

You always have to synthesise data to meet the needs of the model. To bridge the gap between the data you cannot collect or does not already exists, you will need to make assumptions or synthesise some data. This is to allow the model to operate despite the fact that some of its components are currently unknowable. Ensure that these assumptions are well documented and understood by you and the key stakeholders.

The next post in the value driver modelling training series will show you how to create your own value calculator and use it to decide how to best to improve your organisation.