What happens to a maturity model when it becomes too mature? It retires. Or, to be more accurate, it is retired. That’s a polite way of saying that it’s taken into the desert and buried. It happened to CMM (the Capability Maturity Model for Software) which yielded to the upstart CMMI (Capability Maturity Model Integration). The Software Engineering Institute handed CMM its gold watch on 31 December 2007. Now, here’s the fun part. It turns out that to stay in line with the evolving standard for software maturity, you need to use the processes encapsulated in the previous standard, because the new standard is pretty much the same as the old standard. Got that? Here’s how the SEI put it in their FAQ:
To upgrade to CMMI, organizations that are using one or more CMMs should compare their current processes and approach with the CMMI model and create an upgrade strategy that meets their business needs. Many of the skills used in applying the Software CMM are useful in implementing a CMMI-based process improvement program, since many of the best practices, issues, and improvement approaches are essentially the same. Organizations close to a process improvement milestone using the Software CMM may want to measure their progress before upgrading to CMMI.
Nothing wrong with that, of course. But it does highlight a major problem with model-driven capability management. No matter how good your model, it’s going to evolve. Since the model is designed to help you manage something else that’s evolving – your business and your IT – you’re going to find the goalposts wandering around the playing field from time to time.
To be clear, we’re not knocking CMM or CMMI. We’re not knocking any genuine attempt to guide management with rational models. If anything, we’re concerned to change people’s expectations about the rate of change in reference models. Model versions should indeed be turning over – and turning over faster than they do. Your business is fluid, and the tools you use to direct it and articulate its behaviour need to be dynamic. Your tools need to be responsive to change.
The software profession’s engineering foundation and heritage means that there’s an instinctive affection for freezing models, organising training related to them, arranging accreditation, and so on. Constructing migration paths between versions is another default activity. Management techniques derived from software practices attempt to force-fit the business world into this release pattern. But the goals and the tempo of business rarely match this software practice rhythm. Perhaps product-centric companies behave in a similar manner – although many such companies are trying desperately to move away from the release pattern towards customer-driven production. In service industries, the release pattern has no connection with customer needs, being driven purely by the organisation’s conception of its own efficiencies. And as organisations of all types strive to become more agile, synchronising to a release pattern becomes an obvious inhibitor.
So, are maturity models doomed to redundancy in today’s fast-moving enterprises? We believe that the maturity model concept is still valid – in fact, more valid and vital than ever. But we question the label “maturity”. Maturity suggests a defined threshold – a benchmark at which perfection is announced. When we try to encapsulate “maturity” in organisations, we’re actually seeking to assess fitness-for-purpose – a more unwieldy term, but one which implies that the standard being measured against is context-dependent and likely to change. By building the concept of fitness-for-purpose into our management models, we can break the release pattern and provide tools that evolve alongside the business they are designed to measure.
Here’s another way of thinking about it… We’ve got used to the idea that we live in a digital age. Well, actually, we live in an analogue age. That’s right: we experience continuous change. The environments we work in are in constant flux, as are the boundaries of those environments. The discrete step changes delivered by digital-style release strategies will never fit the curve of real life with fidelity. There will always be a mismatch. So, to get closer to the truth, you need to embrace the analogue.
We’ll be publishing some white papers over the coming weeks that will develop this and related themes in more detail. Watch this space. . .
A thoughtful and relevant piece. Personally I believe EVERYTHING a business does (IT, organisation design, rewards, innovation etc etc) needs to be tied to and aligned with the strategy and goals of the business and as these evolve so do they. This is a tall order and we are a long way from it in most organisations. Isolated ‘best practices’ such as software maturity models that exist in glorious isolation from the business strategy are nothing more than a Band-Aid to the real challenge of creating a connected, agile and dynamic business. Those organisations that are closest to this nirvana are inevitably small (or act like W L Gore does with unit’s of no more than 150 employees) and I guess the challenge is can we find a way to scale to the next level and find ways to mitigate the obvious challenges being small entails?
You write very well.