Maturity Levels

While working on a maturity model, a colleague pointed out a potential pitfall to me. The way I had defined the levels, they were too focused on standardized processes, which was not my intent. Indeed, many maturity efforts, such as CMMi, tend to be all about establishing standard processes across the enterprise. The problem with this is that just because you have standard processes doesn’t mean you’re actually getting the intended results from the capability. I’m sure this will ring true with my friend James McGovern who has frequently lambasted CMMi in his blog. So, to fix things, I propose the following maturity levels, and I’d like feedback from my readers.

  1. Not existent/Not applicable: The capability either does not exist at the organization, or is not needed.
  2. Ad hoc: The capability exists at the organization, however, the organization has no idea whether there is consistency in the way it is performed, whether within a team or across teams, there is no way to measure the costs and benefits associated with it, and there are no target costs and benefits associated with it.
  3. Measurable: The capability exists at the organization, and the organization is tracking the costs and benefits associated with it. There is no consistency in how the capability is performed either within teams or across teams, as shown by the measurements. The organization does not have any target costs and benefits associated with it.
  4. Defined: The capability exists at the organization, the organization is tracking the costs and benefits associated with it, and the organization has defined target costs and benefits associated with the capability. There is inconsistency, however, in achieving those costs and benefits. Note that different teams can have different target costs and benefits, if the organization believes that a single, enterprise standard is not in its best interest.
  5. Managed: The capability exists at the organization, the organization is tracking the costs and benefits associated with it, target costs and benefits have been defined, and the teams executing the capability are all achieving those target costs and benefits.
  6. Optimizing: The capability is fully managed and processes exist to continually monitor both the performance of the teams performing the capability as well as the target costs and benefits and make changes as needed, whether it is new targets, new operational models (e.g. switching from a centralized approach to a decentralized approach, relying on a service provider, etc.), new processes, or any other change for the better.

Maturity levels need to show continual improvement, and it can’t be solely about standardizing a process, since it may not need to be standardized across the enterprise, nor may those processes actually achieve the desired cost levels, even though they are standardized. Standardization is one way of getting there, and I’ve tried to make these descriptors be applicable for many paths of getting there. Let me know what you think.

4 Responses to “Maturity Levels”

  • Ken LaCrosse:

    Hey Todd,

    Sounds like my Twitter icon. Pull it up and enlarge it or I can send you a full size JPG of it. I’m finding that before you can focus on ITIL, CMMi or anything else of that sort you have to have some foundational pieces in place for any chance of success. Leadership with a vision and the authority to move the organization towards that vision. A set of Guiding Principles to help managers make the right decisions to fulfilling that vision. An effective and engaged management team that believes in the vision and follows the Guiding Principles. Finally you must have a focus on making all aspects of your organization and operating environment fully visible to all of the participants in this journey. Without that visibility you can’t prioritize improvements and you can’t see if the improvements you’ve put in place are having the desired effect.
    I’ve got a graphic for that too BTW.


  • Hey Todd – like it very much! Maturity levels based on outcomes, not on processes – very sensible. Neil

  • As you pointed out maturity level must be based on outcome. But processes also set the outcome. For a more complete picture maturity level must be coupled with process improvement programs like Lean and Six Sigma.

  • Industry Insider:

    I agree results count and we have some flawed ideas about how to measure IT success. Starting with governance, IT departments have been left to their own ways of doing things for years and its a tough mode to break out of. Laws like Sarbanes Oxley changed the way we do business, IT managers need to be careful that their decisions can stand the bright light of the investors and the SEC investigations. You are accountable and need to organize your IT processes to align them to the rest of the business. Whether you use ITIL, SPICE, CobIT, ITIM or any number of others to avoid a prison sentence doesn’t matter. Imagine you just made a decision to change something and it causes an outage costing your business millions of dollars. You better have documentation of the configuration management, change management, financial management, risk management processes that were used and the business case behind your decision ready for court. Todays investors are fickle and they will leave if they don’t think your IT management is up to speed. Then the way we attempt to measure our maturity can be flawed. For example many companies attempt a self assessment failing to realize the score will be less objective due to internal political pressures. Others will use a web site tool that is a very high level snapshot and think that is good enough. Some will use the tool and compare themselves to others and think its good enough if they are close to the pack. You need to look at all of the process dimensions and interactions to really develop a heat map of where you processes need the most. Then you need to start working on the low hanging stuff and it takes most about a year to imporove by one point. Nothing ends a career faster than pointing out all of your companies flaws, never accept this type of project internally. It is best to hire an independent consultant that has no skin in the game. Often the scores will be lower if the survey is completed by top level management and highest if done by the technology workers. The speed of business today pushes business past the point of using spreadsheets and silo’s. To be compeitive today you need integrated systems and processes that automatically respond based on defined business rules to correct problems or head them off before the chain of domino’s starts falling. You start with adopting a framework and have a maturity assessment performed, that creates the roadmap for future success. Without a structured approach you will continue to be a reactive IT shop and possibly spend some time in court. Oh one more thing the investors called and want to know why you haven’t reduced your carbon footprint yet.

Leave a Reply


This blog represents my own personal views, and not those of my employer or any third party. Any use of the material in articles, whitepapers, blogs, etc. must be attributed to me alone without any reference to my employer. Use of my employers name is NOT authorized.