Richard Hunter

A member of the Gartner Blog Network

Richard Hunter
VP Distinguished Analyst
17 years at Gartner
32 years IT industry

Richard Hunter is vice president and Gartner Fellow in Gartner's CIO Research Group – Office of the CIO Research Team, where his recent work has focused on issues of interest to CIOs, including risk and value. ...Read Full Bio

Coverage Areas:

Maturity models are proxies for value, not value itself

by Richard Hunter  |  October 23, 2013  |  3 Comments

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.

 

3 Comments »

Category: value     Tags:

3 responses so far ↓

  • 1 Manifestation   January 28, 2014 at 2:51 pm

    Since the popular book and movie The Secret hit the shelves in
    2006, the concept of The Law of Attraction (LOA) has spread like wildfire,
    attracting believers and critics alike. You’ll be
    fascinated by these and other stories of eight great inventors
    who stumbled onto their inventions by sheer luck.
    As a result of Michae’s resistant thinking of the LACK of a
    proper find, this is what he manifested in his experience.

  • 2 Reiki Therapy   May 3, 2014 at 2:41 pm

    Always remember that iti does not replace medical consultation or treatment.
    If you’re looking for a Reiki Master and are willing to enroll in a Reiki school, here are the things that you have to know before enlisting:.
    ” This enables the person to find activate Kundalini during meditations, balance between the left
    and right side of the brain, bring harmony and peace,
    cleansing, improve one’s memory, clear blockages and
    aligns the upper chakras, provide psychic protection, remove addictions, bad energies and negative vibrations.

  • 3 Harold Hunt, PMP   October 22, 2014 at 3:50 pm

    This is the first time I’ve heard of anyone equating “maturity” to “value”. Of course the AD team should be reporting “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” but is it possible that this article proposes a solution to a nonexistent problem?

Leave a Comment