Value Driver Modelling – Part 2: The 15 fundamental principles of good VDM design

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.