A checklist for business-transformations
What’s a key tool to help manage something as wide-ranging and complex as a business-transformation? Answer: a checklist.
The following checklist for business-transformations is adapted from one that we use in our own work on transformation. A matching slidedeck with additional explanatory detail is available for free download via the Slideshare website.
For more on the checklist’s context, see the companion YouTube videos ‘Digital-transformation is human-first – Episode 77, Tetradian on Architectures‘ and ‘Digital transformation: a services-based checklist – Episode 78, Tetradian on Architectures‘. For an alternative checklist, using a more story-based approach, see the YouTube video ‘Digital transformation: a story-based checklist – Episode 79, Tetradian on Architectures‘.
1. Story and purpose
Do we have clarity about what the aims are for this transformation, and how do we describe those aims? What’s the story here?
2. Scope and stakeholders
Do we have clarity on scope and stakeholders for this transformation?
Map this out both within the organisation, and to at least three layers beyond it: transactions with suppliers and customers; direct-interactions with other players in the broader market; and indirect-interactions in the shared-enterprise space, such as government, communities, investors and anticlients.
Connect this with the previous check on vision and values (Checklist item #1) to build appropriate value-governance for the context.
3. Context, scale and scaling
Do we have clarity on the applicable scale(s) for this transformation, and how we manage increasing and/or decreasing scale?
Design tests for extremes from very-small to very-large – for example, Agile-type methods may work well for prototypes, but not for large-scale high-reliability operations.
4. Full-cycle governance
Do we have clarity on how we will guide not just initial change for the transformation, but for the entire lifecycle of everything arising from or affected by it?
This includes commissioning and decommissioning, development and maintenance of required knowledge and skillsets, and anything else needed to guide and govern change throughout the entire lifecycle of everything arising from the transformation.
5. Structural flaws in the context
Do we have clarity on inherent structural-flaws in the context for this transformation, that will need to be resolved for ongoing viability?
Note that larger-scope structural-flaws such as whole-of-context feedback-loops may only become visible when systems interact with each other across the whole shared-enterprise. Beware too of Conway’s Law, that organisations tend to design systems that reflect the existing communication-structures of that organisation: we need to take care not to replicate existing structural-flaws into new system-designs.
6. Limits and constraints
Do we have clarity on all constraints that may apply within the context of the transformation?
This applies especially to non-negotiable constraints, such as those that arise from physics or from limits to scaling. For example, the speed of light becomes a very real constraint on options to reduce system-wide latency in high-speed communications at global scale.
7. Resistance to change
Do we have clarity on any resistance to change for this transformation, on the underlying drivers behind that resistance to change, and how to resolve those factors within the transformation?
For useful guidance on this, see standard references on the human side of change-management, such as Sengé et al’s The Dance of Change. For example, one key concern addressed in that book is how to shift perceptions of a change from “We don’t have time to do this!” to “We don’t have time to not do this”. However, watch out also for any vested-interests – such as from vendors and others – not only in maintaining existing dysfunctionalities in current systems, but also in creating new ones within the intended transformation.