Operations | Organisation | People | Process | Strategy
STAY CONNECTED AND SIGNUP TO RECEIVE INSIGHT updates
What are you and your organisation capable of doing? By when? For how much? How quick are you? How reliable? What steps are you taking to improve your performance, and what does the end state look like?
[Listen to audio version, read by David Hodes]
What we’re talking about when we address those questions is your organisation’s capability. We can define capability as the ability to perform or achieve certain actions or outcomes through a set of controllable and measurable faculties, features, functions, processes or services.
The possibly apocryphal story goes that the US department of defence became thoroughly disenchanted with the idea of paying exorbitant amounts for not very much when procuring their products and services on a cost-plus basis. However, the nature of their procurement was such that they couldn’t really nail down a precise scope. Moreover, the risk was too significant for most vendors to offer a fixed price when the advanced technologies they were developing contained such colossal uncertainty. So the US government put out a tender to solve the problem, which Carnegie Mellon University ultimately won. They were the institution that created what we have now come to know as the CMMI or Capability Maturity Model Integration. The CMMI is a process level improvement training and appraisal program administered by the CMMI Institute.
The illustration below provides a graphic view of the intention of the CMMI when applied across its five maturity levels, being initial, managed, defined, quantitatively managed and optimising:
In brief, the application of the CMMI enables repeatable success over the long haul. It is no instant panacea but instead provides a framework to systematically lift both the capability and maturity of an organisation’s people. The three critical dimensions which make up the capability model are: procedures and methods defining relationships and tasks; people with skills, training and motivation; and tools and equipment.
To get a richer rendering of what these mean, let’s take a stroll through an example.
Five levels of maturity
Imagine you work in an industrial organisation that has several operations in different parts of the world. Let’s say our organisation has a profound capability in engineering. Based on the amount and complexity of any given project, those projects are allocated either to the Major Projects services of group functions or to the local engineering function of the given operation. In addition, at the local level, the operation undertakes heavy maintenance and is accountable for controlling all the self-performed, consulting and contracting work associated with doing so.
We observe when we ask some questions that although each of these business areas does project management—in that they need to deploy resources to define a scope of work to be completed to a desired timeline and budget—there is little consistency between them.
Thus, for example, heavy maintenance runs late in determining the scope, rather primitively defines a labour and materials plan in a multitude of spreadsheets, and has a rudimentary schedule used solely for high-level reporting purposes. The work management is done by the maintenance manager, based on years of experience and their tacit understanding of what needs doing.
However, they rarely, if ever, meet their promised return-to-service dates, often forego scope items because of time pressure, and overspend labour budgets by reactively addressing crisis after crisis by throwing people at them. This scenario would be an example of an initial level of maturity.
We swing past engineering and are pleased to see that, for their projects, they can show you a schedule in one of the popular scheduling tools. But, of course, different project managers have their own ideas of what makes for a good enough schedule and, in the absence of a standard, they do the best they can.
These engineers pride themselves on the fact that their plans are end-to-end; that is, each of the phases have detailed schedules. In addition, the deliverables required to go through the mandated tollgates are listed, the completion of which will allow funding for each of the phases.
As a result, the engineering department is more reliable in terms of timeliness and costs than their heavy maintenance colleagues. However, there are still issues with rework, and everyone knows that if they were better organised, especially across the silos, they could be more productive. This scenario would be an example of a managed level of maturity.
We leave the operations and head into the big smoke, where the heavy hitters from major projects hang out. They have a plethora of veterans of the world of project management and have a whole compendium of rules and tools required to plan and execute their big, costly, complex projects. They are strong on governance, steering committees, and standardised reporting frameworks.
Because they are a centralised function, they service all operational units within the organisation. Thus, they are more inclined to standard ways of working, as anyone from their team could end up on any of their projects at a moment’s notice. It helps with productivity if everyone is well versed in the rhythms and routines of standardised ways of working.
From the vantage point of the major projects’ function, they can collect linked projects into programs of work and can further aggregate them into defined portfolios. Their people are given the training and develop the skills necessary to professionally manage the complexity associated with their portfolios. And, they are equipped with industrial-strength tools for the planning and execution of their work.
The stakes are much higher in the major projects arena than in engineering or heavy maintenance, with a bad project having the potential to cause material damage to the organisation. So a lot more attention is paid to governance and how that flows through to the management of risk and performance. This scenario would be an example of a defined level of maturity.
Expanding across the enterprise
One day, you wake up and wonder what would happen if you were to take an enterprise view across all of your projects, be they maintenance, engineering or major? You get excited about the vision and go about the work of defining and collecting relevant data.
You create a standardised resource taxonomy and develop a scheduling standard that is mandated across the enterprise. Then, you take the best of what you have in areas such as procurement, risk, HR, safety, performance and communications management – amongst others –and incorporate them into your governance framework.
You invest heavily in your teams’ training in the new ways of working and in the technology needed to provide the information necessary to run all your projects in a consistent fashion across the enterprise. You can compare one project’s performance against another’s using a standardised set of data and criteria.
Internal and external stakeholders notice the significant improvement in your ability to reliably deliver what you promised in ever-shorter turn times. Even the chief beancounter is your friend as you and your teams consistently hit or exceed budget expectations. And, it keeps getting better as everyone is motivated by the living idea and shared experience of continuous improvement. This scenario would be an example of a quantitatively managed level of maturity.
Anyone reviewing your organisation finds that you are both stable and flexible at the same time. Everyone involved is focused on continuous improvement, allowing you to fend off any threat and seize every opportunity.
There is an intrinsic appetite for change, but based on a stable platform of capable people using standard processes and fit-for-purpose tools. The teams have an ever-growing sense of being at one, with an aligned and shared vision, in service of a grand and ennobling mission.
Over many years, you have done the hard yards of attaining mastery and relish the idea of improving it for good. This scenario would be an example of an optimising level of maturity.
The table below gives a tangible sense of the process areas covered by the capability maturity model for services. The process category abbreviations used in the table are as follows:
PcM – Process Management
PWM – Project and Work Management
SED – Service Establishment and Delivery
Sup – Support
There are no shortcuts to attaining capability maturity. For example, you cannot skip a level outlined in the target profile, as each process area builds on the others. Getting and sustaining the target profile at level 5 is a years-long endeavour applying what Deming would have called consistency of purpose. The prize, however, is an unbeatable sustainable advantage and a remarkable opportunity for learning and growth.
____________________________
What’s next?
To get a flavour of the cohort experience, come to the Systems Thinker Foundations Workshop. It’s free, and you’ll leave with a framework you can immediately apply to your organisation. I hope you’ll join me.
Got a more urgent challenge? Schedule a free call with me.
We’d love to run it with you. To learn more:
- download the brochure (no email required)
- schedule a call
____________________________
[Background image: Man on his back, on Shuttershock]
____________________________
