The Living Analytical Model

How analysis accumulates into analytical memory

Earlier in my career, I supported commercial decision-making in a large global technology business. Some of the most demanding work took place in bid and pricing review meetings, where decisions had to be made while important information was still emerging.

The meetings deliberately brought together Sales, Marketing, Product and Pricing, with me participating from the Finance business-partnering role. Each function contributed different information, analyses, priorities and perspectives on the opportunity. Sales might bring customer intelligence, expected volumes, competitive information and its view of future pipeline. Marketing considered market-share objectives and the company’s current market position. Product brought product strategy and an understanding of the technical and commercial strengths and weaknesses of the offer relative to competitors. Pricing contributed its view of possible commercial positions and the implications of different price points. I brought the financial and commercial model, including unit and revenue growth, profitability, affordability and the effect of an individual decision on the wider P&L.

The analytical foundation was a broader commercial portfolio-management model I had progressively developed. Rather than evaluating each opportunity in isolation, it placed the deal within the wider commercial portfolio: current and expected revenue and unit growth, profitability, market position, pipeline, previous decisions and the capacity of the broader business to absorb a particular margin investment. An individual deal could therefore be evaluated partly through its effect on the overall portfolio rather than only on its standalone economics.

My role in the meetings was to take the information and analyses contributed by the different functions, understand their respective priorities, incorporate them into the overall decision model, assess how they interacted, and make and justify the commercial decision that best served the company as a whole.

The decision space included many factors that could not be reduced to the immediately quantifiable economics. The customer’s use case and existing relationship with the company could matter. Previous successes or failures could influence the customer’s current perception. Local political or procurement preferences might favour a domestic vendor over a global one. Recent win-loss experience could provide evidence about competitive behaviour. A transactional opportunity could justify a different approach from a deal with wider relationship value. A price agreed today might become an anchor for future negotiations. Even the credibility of the information being presented mattered: intelligence about the current bid or future pipeline needed to be considered in the light of how reliable the source had proved in the past.

These considerations were often entangled. A product disadvantage could affect the price required to win, which in turn changed profitability and affordability. A strategically important customer might justify a different trade-off, while the same concession could create an undesirable precedent for future deals. Expected future value depended partly on the reliability of pipeline intelligence. Market-share objectives could alter the acceptable balance again. The value of the analytical model therefore came from both the range of considerations it could accommodate and the relationships among them.

The inputs remained functionally specialised; the decision required an integrated view. Sales might naturally place greater weight on winning the deal, Marketing on market position, Product on product strategy, Pricing on price discipline and Finance on financial outcomes. The commercial decision required these perspectives to be considered together. The decision model was therefore not simply the Finance view of the deal. It was my attempt to construct an integrated view of the opportunity from the information and perspectives available across the business.

The resulting decision could also extend beyond the price or bidding strategy for the individual deal. It might include conditions or additional actions required to protect the overall commercial outcome. A deliberate margin investment in one opportunity, for example, could be accompanied by a requirement for Sales to develop a plan for recovering the resulting loss in margin dollars elsewhere in the portfolio. In another situation, the analysis might point towards changing the commercial route – for example, moving a customer from purchasing through an intermediary towards dealing directly with the company where the additional channel mark-up was materially weakening the offer. The model therefore supported both the immediate deal decision and the actions required around it.

Much of the information needed to make these judgements became available only during the meeting. Yet I could often synthesise it, form a position, explain the reasoning and respond to questions in real time, sometimes without opening the underlying Excel model.

Years later, I found it interesting that the business introduced a sophisticated data-driven pricing capability that reflected a similar underlying principle: pricing decisions were considered in the context of a wider set of commercial characteristics and expected outcomes.

Later still, while leading performance and analytics in a New Zealand public-sector organisation, I saw a different version of the same pattern. Senior leaders would come to me with analytical questions and often find that much of what they wanted was already available, or could be produced quickly from structures already in place. At one point, two senior leaders commented to each other that whenever they came to ask me for something, it seemed I already had it.

For a long time, I thought of these mainly as examples of experience, preparation and being proactive. Looking back, I can see a more consistent practice underneath them. In both environments, I had been progressively building analytical models that extended beyond the immediate question. Those models incorporated what I had learned from different stakeholders, previous work, professional practice, difficult questions, trial and error and continued learning. Each new interaction became another opportunity to understand the business, test the model and improve it.

I now think of this as living analytical modelling.

Beyond the immediate question

Starting with the business question is fundamental to good analysis. For an individual piece of work, I want to understand what decision needs to be made, what the user is trying to understand and what evidence would be relevant.

A different design question arises when building the analytical infrastructure underneath individual analyses: the data structures, definitions, measures, relationships and reusable models from which future work will be produced. If that infrastructure is designed only around questions currently being asked, its capacity will naturally reflect the organisation’s current understanding of what analysis can do.

I find it useful to distinguish between the analytical instance and the analytical infrastructure. The individual instance should begin with the question. The infrastructure needs a broader specification:

Given this business, what should be knowable?

What people know is analytically possible strongly influences the questions they are likely to ask. Someone who has only seen a table of budget variances may ask which cost category is over budget. Someone familiar with structural variance analysis may ask how much of the same variance arose from volume, rate, mix, timing or another underlying mechanism. The difference does not necessarily reflect intelligence or business understanding. The second form of question has become available because the person knows that such analysis is possible.

Current requests are therefore valuable design inputs while representing only part of the potential analytical space. If analytical capability is built solely around existing requests, an organisation can develop what I think of as a question ceiling: the range of questions tends to remain bounded by the analytical vocabulary already available.

This is why I tend to build for classes of question rather than individual instances. If someone asks about a labour-cost variance in one month, the reusable question is broader: what is the structure of labour cost, what drives it, through which dimensions should it be analysable, and which comparisons or decompositions should be available? The original monthly question then becomes one use of a structure capable of supporting many related questions.

The objective is not to anticipate every request. It is to build a sufficiently coherent analytical structure that future questions have somewhere to go.

How a living model learns

A living model develops through interaction with people as much as through interaction with data. Different stakeholders carry partial views of the business, shaped by their responsibilities, information and experience. My own finance and commercial perspective is also only one part of that picture; the analytical structure is what allows those different perspectives to be brought together, compared and tested.

For me, work has therefore been a continuous process of learning how different stakeholders see the business. The analytical task is to understand those perspectives, identify where they reinforce or conflict with one another, understand how they interact, and incorporate them into a more complete model that can be tested against further evidence and outcomes.

The commercial bid reviews were one form of this learning. Repeated discussions taught me how Sales assessed customer intent and relationship value, how Marketing thought about market position and share, how Product evaluated technical and commercial differentiation, and how Pricing considered concessions, precedent and competitive positioning. Those views did not simply sit alongside my own Finance perspective. I incorporated them into the common decision structure and learned from the eventual outcomes. A salesperson’s assessment of customer intent could later prove more or less reliable. A product strength might turn out to matter more than expected in one market and less in another. A pricing concession could produce an unintended precedent. Each decision therefore provided further evidence about the model itself.

The learning also moved in the other direction. By repeatedly explaining how I analysed opportunities and why particular considerations mattered, I was exposing the structure of the decision model to Sales and Pricing. Over time, when they worked together on a proposal before bringing it to me, they would often already have considered many of the same questions, relationships and trade-offs that I would apply. This did not remove the need for final review and judgement; it raised the starting point of the discussion. More of the conversation could then focus on the unusual assumptions, genuine trade-offs and decisions that still required attention.

A living analytical model can therefore do more than absorb organisational knowledge. It can return analytical structure to the organisation. As people become familiar with the structure, it can influence how they frame problems, assemble evidence and prepare decisions before the formal analytical process even begins.

This process gradually created a richer representation of the business than any single functional perspective could provide. The more varied the people I engaged with, and the more challenging the questions and decisions became, the more opportunities there were to test and strengthen that representation.

The public-sector environment required a somewhat different balance. The extent to which I start from a normative view of what should be knowable depends partly on the analytical maturity of the organisation. Where analytical practice is already mature, existing questions and methods provide rich design input. Where the existing analytical environment is less mature, current demand provides a less complete specification of what the eventual capability should support. Professional experience and established analytical patterns therefore need to play a larger role in generating hypotheses about what should be knowable. Those hypotheses still need to be tested through use.

In the public-sector organisation, I progressively developed a Common Data and Analysis Model, supported by a Master of Measures that governed the semantic definition of the measures used across it. The Master of Measures captured definitions, calculation logic, inclusion and exclusion rules, rationale, reporting cycles and other analytical properties, while the Common Data and Analysis Model operationalised those definitions through reusable data, relationships, measures and analytical structures.

The analytical model preserved reusable structures and relationships; the Master of Measures preserved the meaning behind them.

For operational teams, I wanted the model to make the underlying flow of work visible rather than present a collection of disconnected measures.

Demand could be understood through incoming request volumes, their seasonality and incoming phone-call activity. Capacity and effort could be considered through the time spent processing requests and handling calls, together with relevant workforce information. Flow and processing performance were reflected in processed volumes, average end-to-end processing time and differences by request type. Accumulation of work appeared through the volume of unprocessed requests and their ageing, again with the ability to analyse different types of work separately. Service outcomes included processing accuracy, processing timeliness and customer-experience measures. The model also connected operational performance with financial and automation perspectives, including overtime expense and the split between transactions processed automatically by the system and those requiring manual intervention.

Measures refreshed automatically in Power BI at frequencies appropriate to their nature – daily, weekly, fortnightly or quarterly – and broadly similar analytical patterns were used across teams. This consistency meant that people did not have to learn a completely different analytical language each time they looked at another area of performance.

The more interesting analysis came from relationships across the structure. Did processing effort move with incoming workload? Were longer end-to-end processing times associated with more complex request types? Did backlog and ageing appear to move with staffing levels, workload, quality or timeliness? How did operational conditions relate to customer experience? Which manually processed request types combined high volumes with long processing times and therefore offered the strongest potential opportunities for automation?

That last question illustrates the wider purpose of the model. Combining manual processing volumes with processing time by request type could help a technology team prioritise which processes to assess for automation and where automation might release the greatest amount of staff effort. An operational analysis could therefore become an input into technology investment and process-design decisions.

I also kept a Sandbox area for tentative analyses. New decompositions, relationships or visualisations could be exposed to stakeholders before becoming part of the production environment. Some generated useful questions and deserved further refinement; others turned out to be less useful than expected. This allowed the normative element of the model to remain experimental rather than prescriptive.

The model could therefore educate and learn at the same time. Showing people an analysis they had not previously encountered could expand what they knew was possible. Their reactions, questions and alternative interpretations then provided further evidence with which to improve the model.

The cycle was roughly:

Model → demonstrate possibilities → provoke questions → learn → generalise → improve the model

The ‘should be’ was therefore an evolving hypothesis, informed by professional practice and continually tested against organisational experience. The resulting standard emerged through use rather than being fixed once at the beginning.

Across both environments, the relationship was two-way: the model learned from the organisation, while the organisation also learned from the model.

Every question should leave something behind

This leads to a principle that I now see as central to the approach:

Every question should leave something behind.

A request needs an answer, and it also contains information about the analytical environment. If a question is difficult to answer, why? Is an important dimension missing? Is a measure ambiguous? Has someone introduced a perspective that is not represented? Does the question reveal a reusable relationship? Is it genuinely unique, or one instance of a wider class of question?

The useful learning can then be generalised and retained.

For analysis that reveals a recurring or reusable pattern, automation should normally be the default rather than repeated manual production. A useful decomposition should not need to be reconstructed every month. A recurring measure should remain available. A relationship that matters repeatedly should become part of the analytical infrastructure.

I think of the process roughly as:

Conceptualise → model → use → challenge → learn → generalise → automate → govern → reuse

Generalisation is what allows analytical experience to accumulate. Someone can solve hundreds of problems successfully while much of the analytical work remains attached to the individual assignments. Generalisation extracts what can be reused: a better definition, another dimension, a new decomposition, a stakeholder perspective, a tested relationship, an assumption that proved unreliable or a clearer understanding of which analytical approach works.

The next piece of work then begins from a higher base.

This changes the economics of analysis. In a largely request-driven environment, a question arrives, data is gathered, logic is established, analysis is performed and an output is produced. Much of the effort is consumed by the particular request. A living analytical model tries to preserve more of the value created along the way.

A definition once established can be reused. A driver relationship does not need to be rediscovered repeatedly. A reconciliation can become part of the common logic. A difficult stakeholder question can add another perspective against which future decisions are tested.

Analysis begins to accumulate rather than being repeatedly consumed.

Retrieval and real-time evaluation

Accumulated analytical structure creates responsiveness in two distinct ways.

The first is retrieval. A new question belongs to a class that the existing model already supports. The exact request may be new, but the measures, dimensions, relationships and logic required to answer it are already present. Much of the analytical work has effectively been completed before the question arrives.

This explains many of the occasions when senior leaders found that I already had much of what they were asking for. The answer might never have existed as a particular report, but the analytical capacity required to produce it was already there.

The second case is real-time evaluation. The information itself is new, while the analytical structure is familiar. This occurred frequently in commercial bid reviews. Customer expectations could change, new competitive intelligence might emerge, volume assumptions could be revised or the conditions required to win might become clear only during the discussion.

The answer could not have been pre-computed. What already existed was the structure into which the new information could enter. A new fact might change a parameter, revise an assumption, alter a probability or affect the attractiveness of one scenario. The work of understanding which dimensions mattered and how they interacted had largely been accumulated beforehand.

Repeated modelling also gave me a feel for the response surface – the shape of how outcomes changed as key assumptions moved. I understood broadly how price and volume interacted, where margin became difficult, how much investment the wider business could afford, which variables were more sensitive and how different combinations of assumptions affected the overall commercial position.

This was particularly useful because new information from the meeting did not arrive as a clean set of numbers. A comment from Sales could alter my assessment of win probability. Product information might change how much pricing concession I believed was needed. Marketing could change the strategic value assigned to a market-share opportunity. Pricing might reveal a precedent risk. I could incorporate those changes into the overall model while the discussion was still taking place.

Over time, enough of this structure became internalised that parts of the evaluation could be done mentally. Mental modelling in this context was less about complex mental arithmetic than locating new information within a familiar structure and understanding how the overall position was likely to move.

This is also why I see deep analytical-tool fluency as more than a production skill. Repeated model-building can expand the range of analytical structures a practitioner can readily imagine and manipulate. Driver-based modelling develops intuition about variables and sensitivities. Dimensional and semantic modelling develops a habit of thinking about grain, reusable dimensions, measures and relationships. Scenario modelling develops a stronger feel for dependencies and alternative outcomes.

The senior analytical role does not require personally building every formula, data transformation or visual. There is a natural progression from building the model, to designing the model, to understanding the structure deeply enough to test it, challenge it and direct its development while others implement parts of it. Execution can be delegated while analytical understanding remains close.

Flattening the analytical workload curve

One practical consequence of a living analytical model is that it can flatten the analytical workload curve.

This does not necessarily mean doing less analytical work. It means changing when the work happens, how much of it has to be repeated, and what kind of work remains when an important decision arrives.

In a reactive environment, analytical workload tends to peak after the question appears. Data has to be assembled, definitions established, calculations built, relationships tested and outputs checked, often at precisely the point when management most urgently needs an answer.

A living analytical model moves more of this work earlier and spreads it across time. Measures are progressively defined, relationships established, recurring analyses automated and reusable structures maintained as part of ongoing analytical work. New questions increasingly extend an existing model rather than trigger a fresh build.

Work that would otherwise arrive as a series of reactive peaks is therefore partly converted into continuous development, learning and maintenance of analytical capability. As the model expands, the marginal effort required to answer many subsequent questions can fall.

The effect can also extend beyond the analytical practitioner. In the commercial environment, once Sales and Pricing had become familiar with the structure I used to evaluate deals, more of the initial analytical work could be incorporated into the proposal before it reached the review meeting. In the public-sector environment, common measures, analytical patterns and automated refreshes similarly reduced the need to reconstruct routine analysis each time a question arose.

The more important effect, however, is what happens at the moment of decision.

When the analytical infrastructure already exists, scarce decision-time does not need to be dominated by producing the analysis. More of that time can be spent making sense of the evidence, directing attention to what matters, testing explanations, considering implications and discussing action.

The objective is therefore not simply efficiency. It is a redistribution of analytical effort:

from reactive production towards continuous accumulation, and from producing analysis at decision-time towards interpreting and acting on it.

As the model matures, the analytical function can progressively devote more of its scarce decision-time to understanding the problem and shaping the response, rather than reconstructing the analytical foundation required to begin.

What keeps accumulation valuable

Accumulated analytical capability can be difficult to see. People observe an answer arriving quickly; they rarely see the years of modelling, refinement and learning behind it. Reactive work is often more visible because the effort occurs after the request. A mature analytical structure can make much of that production work disappear from view.

There can also be a difference in benchmarks. The analytical practitioner may compare the environment with what they believe should be knowable and remain conscious of what is still missing. The organisation may compare the same capability with what it previously expected and experience it as unusually advanced. Both are looking at different reference points.

The value of accumulation also takes time to emerge. In the beginning, building reusable structure may appear slower than satisfying one request at a time. The advantage becomes clearer through repeated use, as definitions, measures, relationships and analytical patterns are reused and the marginal effort required for many subsequent questions falls.

That compounding effect depends on discipline.

The model needs to remain connected to the real business. A sophisticated structure based on the wrong conception of what matters is simply sophisticated irrelevance. This is why normative design must remain open to evidence and why different stakeholder perspectives are important inputs to the model.

Analytical capacity also needs to be exposed and used. Building possibilities nobody encounters creates overhead. Experimentation, demonstration and dialogue help determine which additional analyses deserve to become lasting capability.

Finally, accumulated structure has to remain coherent. Reusable analytical structures remain valuable only if their meaning stays stable and traceable as the model expands. Definitions need to be governed. Measures should be traceable. Inclusion and exclusion rules need to remain clear. Sources and relationships should be understood. Changes require enough control that different parts of the analytical environment do not gradually produce conflicting answers. Without this discipline, accumulation becomes technical debt rather than analytical capital.

A model compounds only while it remains coherent.

This is why I see modelling, analytics and governance as closely connected. Governance allows accumulated analytical work to remain reusable and trustworthy as the model grows.

From a living model to analytical memory

Looking back, the commercial and organisational examples appear quite different. One involved making commercial decisions while new information and competing perspectives were entering the discussion in real time. The other involved progressively building an organisational analytical capability.

Their underlying logic was similar.

In the commercial environment, I was continuously developing a model of the decision space. My organisational foundation was Finance; the decision model progressively incorporated what I learned from Sales, Marketing, Product and Pricing alongside financial analysis, as well as previous wins and losses, assumptions that proved more or less reliable, questions raised in meetings and the outcomes of actual decisions. The underlying portfolio-management structure allowed individual opportunities to be understood within the wider commercial position, while repeated use progressively embedded more of that structure into how other people prepared and discussed decisions.

In the organisational environment, I was progressively developing a model of the analytical space. Because the existing analytical environment was less mature, the starting point was more normative. The model exposed common analytical patterns, showed people what could be understood, learned from the questions those analyses generated, and incorporated useful learning into an increasingly automated and governed structure.

Both developed through the same underlying practice: learn how different people see the business, incorporate those perspectives into a coherent model, understand the relationships between them, test the model against real questions, decisions and outcomes, generalise what is learned, and preserve what remains useful.

The relationship is not one-way. The organisation provides information, perspectives, questions and experience from which the model learns. The model in turn provides structure through which people can frame problems, ask better questions and make better-prepared decisions.

This is what I mean by living analytical modelling.

Living analytical modelling is the practice: learning, modelling, testing, generalising, automating, governing and reusing.

The living analytical model is the capability: an evolving representation of the business or decision space that becomes richer through use.

What accumulates is a form of analytical memory: retained understanding of measures, relationships, drivers, scenarios, stakeholder perspectives, questions, analytical possibilities and lessons from previous work and decisions.

That accumulated memory changes the starting point of future work. Some questions can be answered through retrieval. New information can be evaluated against familiar structures. Repeated analytical production can be reduced. Analytical workload can be spread more evenly across time. When an important decision arrives, more attention can be devoted to understanding its implications and determining what to do.

The objective is not to build a structure containing every possible answer. It is to build one that can absorb new information, integrate different perspectives, expose better questions and preserve useful learning so that future work starts from a higher base.

Answer the question. Learn from the question. Improve the structure that will answer the next one.

Over time, good analysis should do more than produce answers.

It should create analytical memory.

© 2026 Colin Wu. All rights reserved.
Quotations permitted with attribution. No reproduction without permission.