Maturity models are all the rage in IT circles. There are maturity models for nearly everything an IT organization does. Lots of IT professionals, in practically every IT discipline, talk about improving maturity as if it was the ultimate goal for the organization. And that’s a problem for the IT professional.
The heart of the problem is that “maturity” is not value. Value is an outcome, and maturity is not an outcome; it’s something we pursue in order to develop the capabilities that make an outcome possible. At best, increasing maturity is a leading indicator for value, not the thing itself. An IT organization that touts its improving “maturity” to an executive team is not talking about value, but about IT activities. Executives are at most mildly interested, and at worst worry that IT isn’t focused on the right things–which of course means initiatives that explicitly deliver more value to the enterprise.
I’m not opposed to increasing maturity. I’m all in favor of everyone improving performance, ideally by leaps and bounds. I merely think that in most cases maturity is not a topic for discussion with the executive team. What IT professionals should discuss is not “maturity”, but the outcomes that increasing maturity produces.
As an example, consider the grand-daddy of all maturity models: the Watts Humphries Capability Maturity Model (CMM) for applications development, developed in the 1980s at Carnegie Mellon University. The point of this model is to rate the ability of an AD organization to consistently execute against project plans. Humphries tied the original model to quality; it can just as easily be tied to outcomes that include higher productivity, improved user satisfaction, and any others that can benefit from systematic execution.
And here we encounter our first maturity dilemma: consistency in execution says little or nothing about what outcomes are supposed to be consistently delivered. Should our AD organization optimize for quality, adherence to schedule and budget, or for productivity? The first is what NASA’s space shuttle program optimized for; the second is what the typical large external serivce provider optimizes for; the third is what the typical AD shop thinks it’s optimizing for. Which of these outcomes is the desired one for a given IT team?
The answer is dependent on what the enterprise needs, which can change over time. Twenty years ago most enterprises wanted high quality systems, the stuff we now call “systems of record’ in Gartner’s applications development pace layering model; now most enterprises want rapid delivery, figuring that an 80% solution now is better than a 100% solution three years from now. An IT organization whose “maturity” defaults to rigorous methods for creating high quality above all else might find itself losing value in the eyes of peers throughout the enterprise when the goal shifts (as indeed it has for many of our clients).
The solution to the problem is to avoid discussing IT’s performance in terms of maturity, and focus instead on the outcomes that maturity is supposed to produce. Let’s assume for the sake of argument that desired outcomes for a given enterprise include delivering more projects, in shorter time spans, with less waste for both IT and non-IT personnel. As opposed to reporting to the executive team on AD “maturity,” the AD team can talk about percentage of projects delivered on time and budget, and increased value delivered as represented by reduced waste and higher yields on resources invested in business imperatives.
Any of these outcomes represents real value, as opposed to “maturity”, which is at best a proxy for value–a symbol, not the thing itself, and a symbol that doesn’t resonate with anyone outside IT. When you want to talk value, talk outcomes, not maturity. If the outcomes don’t resonate, the increased maturity that makes the outcomes achievable won’t either.