Mod­els on their own are unre­li­able. Utter­ly point­less. Too often, we see mis­lead­ing deci­sions being made from that spike in an excel line graph or the absolute val­ue from a finan­cial mod­el. But mod­els are only a sim­pli­fi­ca­tion of real­i­ty. A reflec­tion of his­to­ry. A bench­mark or an anchor for future pre­dic­tions.

Mod­els are pow­er­ful when they’re show­cased in a sto­ry — con­tex­tu­al­is­ing the data from intro­duc­tion, analy­sis and recommendations.I recent­ly had drinks with a friend who works in invest­ment bank­ing we came to a sim­pli­fied (over­ly sim­pli­fied) con­clu­sion that invest­ment bankers and con­sul­tants do the same thing. We val­i­date an oppor­tu­ni­ty by build­ing a mod­el around the future-state. This is the ground work. We then hook the deal by inject­ing indus­try insights, play­ing with vari­ables of financial/operating mod­els, and align­ing pro­posed options with strate­gic objec­tives of the organ­i­sa­tion. So how do you turn a beau­ti­ful­ly com­plex mod­el into a com­pelling sto­ry?


1. Buffer for assumptions and variances

If you haven’t built the mod­el your­self, its well worth invest­ing the time to under­stand its mechan­ics — i.e. what are the data sources and how are they applied to pro­duce an out­put? Ide­al­ly, most mod­els should have a buffer in a range where a set of options might sit. A basic mod­el­ling prin­ci­ple which requires a thor­ough under­stand­ing of the qual­i­ty of the data, the con­text of the busi­ness and how it might impact the over­all result. For instance, you might apply a 20% con­tin­gency buffer to an opex fore­cast to fac­tor inci­den­tals, or use indus­try bench­marks for a val­u­a­tion to include worst and best case sce­nar­ios around the actu­al val­ue.

There’s a clear sto­ry here. Adding a buffer to a mod­el says this mod­el isn’t per­fect, but there’s a sci­ence to how we man­age the down­side of assump­tions or vari­abil­i­ty in the data.


2. Test alternate worlds

p>The fun with mod­el­ling is in play­ing with vari­ables to pro­duce dif­fer­ent sce­nar­ios — be it chang­ing prices, rates of return, stock vari­ances, labor util­i­sa­tion or even failed projects. You might do this with fan­cy Monte Car­lo sim­u­la­tions (which I’ve nev­er got right!), or man­u­al­ly change a model’s inputs to test its impact on the final out­come.

We cre­ate sto­ries through these sce­nar­ios. How would the out­come dif­fer if we canned a project half-way through its lifes­pan? What would hap­pen if the price of wool sud­den­ly sky­rock­et­ed up by 80%? What would hap­pen if we acquired com­pa­ny Y instead of com­pa­ny X…or both?

Cre­at­ing alter­nate worlds with our mod­els allows us to make deci­sions about the risks we need to mit­i­gate and the extent to which we might want to con­trol vari­ables depend­ing on their rel­a­tive impact.

3. Clinch it with a business case

A mod­el becomes mean­ing­ful when it inspires action. Action which comes from a deci­sion. A deci­sion which comes from see­ing an oppor­tu­ni­ty that ties direct­ly with a busi­ness and social need.

A mod­el is ulti­mate­ly used to make rec­om­men­da­tions on a set of ini­tia­tives, draw­ing upon the vision and strate­gic intent of the enter­prise. But it takes a lot to get to the final cut. It takes a deep under­stand­ing of fac­tors that would dis­rupt the organ­i­sa­tion inter­nal­ly, in the broad­er indus­try and how these fac­tors trans­late to a prob­lem state­ment and call for action.

The rec­om­men­da­tions itself must tell a sto­ry through a sol­id busi­ness case. It tells us:

  • Pur­pose and need
  • Oppor­tu­ni­ty costs (of choos­ing one ini­tia­tive of anoth­er)
  • Risk mit­i­ga­tion
  • Mea­sur­ing per­for­mance

At the end of the day, the mod­el is real­ly only a small part of a pitch. The sto­ry is in the detail, the assump­tions, the data sources and all the lit­tle nuances which con­tex­tu­alise its exis­tence.

Next
What is a good website?