How to specify the problem; build a shared model; validate ?

Some common issues came up in replies to my recent survey. Some of these are specifically for those who build models:

  • How to specify the problem in the first place.
  • How to get a model everyone agrees on.
  • How to validate the model, and get data.

I thinks these issues are all linked, and have a common cause, and a common solution.

Why these problems? These issues have been around for longer than I have been building models! And (sorry to say) I fear they arise from the process we were all taught to follow. In great summary, that process is something like:

  • Work with the team to build a qualitative feedback diagram of all the causal connections that they think are important.
  • Throw the diagram over to an expert who can build the model.
  • With the model structure built, go find the data to make it work and validate it.

I won’t detail the problems with this process here, but go straight to an alternative. (This is set out in my short article on the AgileSD method. There’s more on the problems with the standard approach and why AgileSD solves those problems in this bigger article.)

Time-chart the issue of concern. If someone, or some team, is concerned about something going wrong, or with potential to go better, then they must be able to chart that – over what time-scale has what indicator been changing, along what path, that worries them?

So … give them the white-board pen – or the mouse if building the model in real time – and get them to sketch that chart, including a scale for the numbers and the time-scale over which it has changed to date, how it will likely change in future if they do nothing, and how they want it to change in future.

Follow the AgileSD process – rigorously. The process explained in those articles above works back from those outcomes step-by-step,  It ensures:

  • that every element in the model is a real-world entity, properly specified and quantified – not abstract or ambiguous words that mean different things to different people (including intangible factors, when you get to them!)
  • that every causal connection is validated against reality before moving on to the next link in the chain
  • that everyone involved can see that the model is valid at every stage – if someone believes some other causal relationship[s] are involved, then they should get them added to the model, quantified, and validated against reality. If they can’t do that, and the model matches reality without it, then it’s probably non-existent or irrelevant.

… and a huge benefit – the model starts giving its users real insight right from the start. They don’t have to wait to the end of the normal lengthy process, when a large model has finally been validated, to see anything useful and actionable.

Estimate missing values. There are always items for which no reliable data exists. But don’t let that stop the process!

Invite knowledgeable individuals to estimate the values of any missing item, how those values have changed over time, and might change in future. If those estimates are good, using them in the next step of the model should give results that reconcile with values of items that are known. (In a recent case, I wanted to know how a product’s falling sales reflected changing numbers of customers and their purchase rates – both unknown. But knowledgeable people in marketing and sales gave me estimates for both items, and agreed on most-likely scenarios for each). 

THEN – of course, start tracking those unknown item-values so they are not unknown in future!

What NOT to do … Well, don’t do the opposite of these things! In particular, do not try to capture people’s unsubstantiated beliefs – don’t put things on the model that are unspecified and unquantified – don’t go “loop hunting”, seeking feedback loops for which there may be no evidence (feedback is discovered by the AgileSD process – it is not assumed or allowed to force the model’s structure). 


Learn to do this!. The AgileSD process explained in the articles above has now been used thousands of times – to build strong plans, to plan important initiatives, to fix local issues, and more. And it has been used on organisations of every scale, across many different sectors – including non-business cases – and on all continents (except one!). 

The method is reliable and fast, and – crucially – can be picked up by anyone who is reasonably numerate and can think logically. Three things you might do …  

  • Get a quick experience of how to do it, try the FREE AgileSD course – which uses a non-business example
  • Even quicker – get an idea of how the super-easy software to build these models actually works from its intro video-quide.
  • Enrol in our core course on building ‘digital twin’ dynamic business models – there’s a short ‘Essentials’ version too.

Leave a Reply

Your email address will not be published. Required fields are marked *