Big change lesson – Poorly chosen or ill-defined scope
Setting the scope for change is a critical choice that leaders exercise early in any project. It invariably involves competing considerations of investments, returns, time and risk. In other words, bang-for-the-buck and do-ability. Such choices are almost inevitably constrained by available resources and assessed benefits and returns. But scope must also take account of critical inter-dependencies such as natural value streams and dependent business processes. The aim is to find the goldilocks zone between impact and effort.
As a general rule of thumb, the greater the scope of the change, the greater the risk. But constraining scope to exclude critical inter-dependencies – such as adjacent business processes or organisational units – undermines target benefits or introduces uncontrolled business risks out of sight for those making the change.
All too common is to see scope constrained by self-defeating considerations. The desire to keep everything inside the one organisational unit because involving others “will only slow things down”. Senior leaders falling in love with their own answer to a question that hasn’t been properly defined. Solutions trimmed to limbo under an executive’s spending limit under the organisation’s delegations of authority. Organisational politics precluding entrusting change responsibilities with the requisite functional owner. Executives protecting sunk investments from previous changes, however poorly executed or relevant to current business needs. Functional leaders ignoring the workloads and costs they shift onto others in their bid to optimise their own processes and metrics.
Sweating the scope is one of the most valuable investments in front-end loading change. Yet scope often receives too little debate or is based on gut feel rather than informed through structured insight. Sometimes best to invest in learning more about the nature of the opportunity and required effort (did I hear someone mention some form of discovery and hypotheses testing?) before settling project scope and making informed decisions about the resultant trade-offs.
And questions of scope should continue to be tested as learnings arise through the progress of change. This is not an excuse to constantly change scope – as often as not that simply suggests poor planning and control – but to reflect the learnings and insights generated through the change effort.