Process maturity is neither a necessary nor a sufficient condition for improving service.
Yesterday we looked at how CMM-type maturity is not a measure of how well you are delivering service. CMM only measures sophistication of management, and actually only sophistication of empirical management. The corollary is that maturity assessments are not a measure of whether an improvement exercise was successful, not if the objective was to improve quality of service.
But wait! there's more! Mature management-by-numbers of process is neither a necessary nor a sufficient condition for improving service.
There is a strong correlation between increasing your process management maturity and improving quality of service. If you measure the process and manage to the numbers and actively try to improve the numbers (which is what CMM maturity means) then you will probably succeed in improving.
But only probably. There is no guarantee that CMM maturity 5 will result in improved efficiency or effectiveness of service delivery nor improved quality of service. It only helps: it is not a sufficient condition. I can think of a few managers and teams who could have maturity 5 processes and still degrade the quality of service.
Nor is it a necessary condition. Managers don't have to formalise process, measure it and optimise it in order to improve service. That is only one path to the top of the mountain. Many a good manager has fired up the team and motivated them to better results without formal process measurement and CSI structures.
If you ask me, one powerful tool for service improvement has been turned by the industry into a cultish goal for its own sake, a mystical measurement of process purity. It is very important but it is not the end in itself.
More posts on maturity
Made in New Zealand 
Comments
Academic skeptical of process maturity
Colleague pointed me to Mary K Benner at the Wharton School who is casting a critical eye on some of the same issues. Caveat lector, but first glance is intriguing.
http://www-management.wharton.upenn.edu/benner/
Charles T. Betz
http://www.erp4it.com
Like ISO certification. ISO
Like ISO certification. ISO certifies the Quality Management System, not the product or service. [Skep's note: the visitor is referring to ISO900x]
shameless pointer
oh, I can't resist, since Rob gets about 10 times the hits I do.
have posted on some related things here:
http://www.erp4it.com/erp4it/2009/11/maturity-the-antithesis-of-lean.html
Is the idea of process maturity actively harmful to a Lean view? Inquiring minds want to know, or at least stir up debate.
Charles T. Betz
http://www.erp4it.com
less direct value proposition
Yeah I saw you had asked that question but i must admit I didn't understand it, not being very lean myself :) I see now you were saying the same thing "evolving an organizational platform that in theory will then more effectively (consistently) produce value. It's a less direct value proposition." You may have seeded it in my head.
Hi, I'd like some advice
Hi, I'd like some advice from the many experts out there.
In the Release & Deployment Process, when does it end?
I work within the release and deployment process at a major UK company and this is an issue. Most deployment have weeks of tweaking and config changes post deployment. This seems to run into the release that never ends scenario. I'd like to establish criteria for when a release ends and would very much be interested in anyone's thoughts.
Thanks
A few more points
In addition to all the good advice already given I would suggest you need to look at Service Management's involvement throughout the life-cycle, including defining non functional requirements as early as possible. I've also found it very useful to establish a strong relationship with the test manager and to work together with them to ensure there are as few surprises as possible after go live. It also helps, though this is much easier to say than do, to get specification freezes built into the life-cycle.
James Finister
Wolston Limited
www.wolston.net
www.coreITSM.com
http://coreitsm.blogspot.com/
tweaking and config changes
"weeks" of settling in a release sounds perfectly reasonable to me. I get upset at Early Life Support (God! I hate that term!) periods of only one month if it is a new service or a major upgrade.
John's point is good about well-defined acceptance criteria: if it meets the criteria and the acceptance period (ELS) is over, then it's in. Anything beyond that is just BAU problems and changes. (Hopefully all those "tweaking and config changes" were controlled as problems and changes anyway, right? otherwise you run the risk of going backwards as the developers panic trying to be rid of the thing)
If Solutions group have trouble meeting acceptance criteria then the design process is flawed and nothing you do to improve release process is going to help.
Never-ending Release
the Service Transition lifecycle stage 'ends' with early life support being provided to Service Operations, so a 'never-ending' release is conceivable. However, if the service has a clearly defined Service Acceptance Criteria then there should be less gray area as to when the release is out of the transition stage and formally into Operations' hands...
perhaps this is one reason we want to define a service (rather than an application) with all of its associated aspects...the boundaries of tweaks and config changes that are acceptable as part of 'early life support' might be worth some discussion early on as well.
with the emergence of virtualized service infrastructures, Service Operations will require greater skill sets in performance management but that doesn't mean they (or services) are perpetually in a state of transition....even though it may seem that way.
Check the Good Book (Transition) page 111-112....
John M. Worthington
MyServiceMonitor, LLC
UK hospitals and uk childcare
Interesting post considering all the newspaper reports in the UK about a Hospital passing it's inspection but later found to have a blood spattered A&E. Also a social services dept passing it's inspection but then failing a child that died.
I know a lot of techies who are deeply suspicious of service management. All they see is experienced technical staff being made redundant because of the cost and boys in suits being shipped in (at a very high cost) to implement service management.
Strange world.
Its about the patient - not the process...
Glad you posted - albeit anonymously. I'd be suspicious of service management if I was back in my old days of running a huge cost center - sorry data center. Service management, like process improvement, is irrelevant unless it directly affects the value equation as defined by the USMBOK. Value = Results achieved from using a service compared with the cost of using the service. Results are viewed from two perspectives, customer (in your case the patient) and the provider (hospital). The tragic example you offer should impact both audiences.
The other equation (there are 4-5 in the USMBOK) that service management must respect is the 'expectation' equation. Expectations are defined and set based upon a negotiated settlement that respects needs and wants expressed as 'requirements', and matches them with the provider capabilities (offerings and options).
If a service management initiative or project does not have these equations or similar at its core, and instead seems focused on the process - cancel it, abandon it, change it. Just don't do it. I'm afraid we have let the process and to some extent technology focused ignorance place ring through our collectives noses when it comes to service management. How many of those shouting 'service management' have actually been part of a successful service provider organization and system.... ?
Strange world... we are surrounded by service but would not recognized service management if it bit us on our assets.