More on simplifying SCORE

How do we use SCORE, as a practical, more strategy-oriented replacement for SWOT?

These are some additional notes as a follow-up and extension to the previous post ‘Simplifying SCORE‘. They perhaps apply in particular to the new simplified layout for SCORE:

Yet they should also work well with the existing ‘standard’ layout for SCORE:

First, some notes on the model’s domains:

— Strength: this is typically about what we already have available to us, what we can use, such as assets, capabilities, knowledge and skillsets. This is a common starting-point for when we want to use SCORE to explore our current capabilities and assets – our existing strengths – could be re-used in new business-models and other options.

— Challenge: this is typically about what we at present don’t have available to us – in terms of assets, capabilities, knowledge, skillsets and the like – that acts as a constraint on our options and ability to respond to others, and that we need to resolve in order to alleviate such constraints. The point here is that we’ll need to do something to resolve these – and it may be a challenge to do so. (Note that this isn’t necessarily a ‘weakness’ – in fact it’s only a ‘weakness’ if it’s something we need to do or build but can’t resolve it.)

— Option: this is typically about the opportunities (and concomitant risks) that become visible and available in the ‘external’ world, that presents us with the option to choose or not-choose. This is a common starting-point for when we want to use SCORE to explore new business-models and other possible options.

— Response: this is typically about how we expect the ‘external’ world would or could respond to the options that we choose or don’t-choose. There are number of side-themes here – rewards, returns, new regulations, new risks and suchlike – that in each case would typically imply some form of constraint, and on which we would need to act. (Note that even a ‘response’ of rich rewards can cause constraints, as it can create challenges on effectiveness-themes such as scalability and the like.) This is perhaps a less-common starting-point for a SCORE-session, but one that we’d use if we need to act on upcoming legislation or the like.

— Effectiveness: every strength, challenge, option and response, and every change in any of these, is likely to have impacts on overall effectiveness that we will need to govern. Note that the effectiveness-themes listed as ‘outcomes within action’ on the existing ‘standard’ layout for SCORE – efficient, reliable, elegant, appropriate, integrated – are really only a default-set that we would be likely to need to assess in every case; in practice, many others are likely – such as resilience, anti-fragility, scalability, adaptability, versatility and so on – dependent on context.

Note too that the process is iterative and interactive. With SWOT, many people seem to think that all we need to do is just make a list of strengths, weaknesses, opportunities and threats, and that’s it, we’re done. But even in SWOT, the whole point is not just the list, but what we do with that list – the analysis, the assessment, and above all the strategic, tactical and/or operational implications of each of those items. So to emphasise this, each time we add an item to one of the SCORE domains – such as by placing a sticky-note on the respective part of the SCORE base-graphic – we immediately explore the implications on everything that’s currently listed in all of the SCORE domains. Everything connects with everything else, everything depends on everything else, everything impacts on everything else – that’s what we’re exploring here.

To give a practical example, if we succeed with this new product-idea, and get paid (Response), will we be able to scale our operations to meet the new demand (Effectiveness)? At what point will our existing capability (Strength) need to be upgraded or changed (Challenge)? What new possibilities (Option) would become available if we rise to that challenges of that upgrade? What would be the impact on operations (Effectiveness) and returns (Response) if we don’t?

Round and round we go on this, if potentially to infinity – an obvious risk of ‘analysis-paralysis’, of course. Hence it’s really important to remember here the enterprise-architect’s mantra of ‘Just Enough Detail‘ – and use that as a practical guide as to when to bring each SCORE-session to a close.

Again, hope it’s useful, anyway – and over to you for comments, if you wish.