Maturity Matrices are Immature – I Hate Them!

I’ve been an IT Director or consultant/coach for over 40 years. As a director, consultants would show me how to “mature” my operations or IT service desk practices by providing me with a maturity matrix like the one below. The suggestion being “We built this model based on our understanding of “best practices” and, frankly, you’re not very mature.” I found it amazing that in 30 years of “directing,” no one ever presented me with one that showed how brilliant we were!

Here @DanielBreston takes a look at #ITSM Maturity Matrices and why predescribed ones will never work right for your organization. Click To Tweet

Dissecting the maturity matrix model

When I reviewed the model:

• Ad hoc – meant “this is what we are today,” and I felt the name was insulting
• Repeatable – what does that mean? Am I repeating being ad hoc?
• Systematic – means “done or acting according to a fixed plan or system.” But how does it relate to our performance or customers?
• Measured – the whole matrix is a measure, isn’t it, so why have a column which doesn’t seem to signify that we’d accomplished anything special?
• Optimized – IT service management (ITSM) or Agile or DevOps or Lean are all about optimizing and improving, so, again, is this not captured as you move across the maturity matrix? Why have a column for this?

The consultants tried to explain that the columns indicated what our behaviors should be at each point in time. My response: so not until we’re Systematic do we know how to correctly fill in an incident record? Really? Then we jump from we can fill in the form to Measured, and as we’re already measured on our performance, we don’t need this column!

I won’t bore you with the rest of my tirade. I promised myself that if I ever became an independent consultant, I’d not use them. Best laid plans – because a CIO at a major client wanted a maturity matrix for several processes that he defined: provisioning environments, cloud management, security, IT service desk, DevOps, and Scrum Development. Well, what the customer wants!

Although I cheated

I didn’t have a package of maturity matrices to provide her, and as they were going to measure the performance and improvement of various teams, I decided to let them create a maturity matrix that made sense to them. Using representatives from the Operations, Service Desk, SRE, and Scrum teams, I explained how I wanted each of them to work together to create a matrix that made sense to them.

I also wanted them to consider the rules of use and that they’d have to share this with their colleagues. We created a model for them to work from like the one below, and I facilitated the completion of the columns by challenging them on what was the difference between one column to the next and to be aggressive in stating the capabilities of each column to prove performance improvement and value.

I also made sure they knew that the matrix was not a fixed document and must be changed based on circumstances. This was new thinking, and it took a couple of hours per matrix until we were satisfied. We presented our matrices to IT senior management and, using Agile terminology, ensured everyone agreed that these would show the iterative improvement over time for each process. We even created a simple roadmap on how to go from column to column to help sell and explain the matrices to the rest of IT, Product Owners, and stakeholders.

We then made them visible! No hiding! A web page where people could comment – which drove changes to the maturity matrix as appropriate. Finally, the model shown is illustrative only as some teams modified the words to fit their circumstances.

Now here’s the real trick for maturity matrices

This exercise took two weeks and became a fun way to articulate progress. We highlighted where they were using blue because no team behaved in just one column, but had characteristics across the matrix.

When the majority of “Getting the hang of doing it” was blue, I asked them to reflect on the next two columns and whether they still applied given their current level of performance. In most cases, they didn’t. So, and now the real trick, we made the third column the first column renamed to “This is what we do now” and rewrote the rest of the matrix. The old maturity matrix was archived every time a significant redesign was issued, which allowed the portrayal of the journey.

How do you measure maturity? Asks @DanielBreston. Do you use pre-described maturity matrixes or one that's tailor-made by the people involved? #ITSM Click To Tweet

Collaborative conversations to continuous improvement

This practice is still in use although some teams have moved to a more of a “canvas” model. The way they track and report progress is based on an agreed view of current performance versus future expectations. As it’s visible, comments aid the teams in stretching their goals and thus facilitate rapid improvement based upon customer perception.

Modern management helps their teams “mature’ by allowing them the freedom to judge their journey by setting signposts that makes sense to them and their customers. As a leader (Manager, Product Owner, Team Lead), consider these questions to help you guide your teams to better practices, no matter what their work entails.

How do you measure maturity across people, processes, and ITSM tools? How do you help teams mature? Do you use pre-described maturity matrices or one that’s tailor-made by the people involved? I’d love to know, so please leave a comment.

ITIL 4 Explained

What is ITIL?

Which ITSM Tool? Here’s an ITSM Tools List

Enterprise Service Management Explained

What ITSM Pros Need to Know About CMDBs

How to Define, Measure, and Report IT Service Availability