Our Management Process Can't Tell us How to Get From "Repeatable" to "Defined"
The CMM model likely contains useful organizational design guidelines in the form of Key Practices, and some extremely useful checklists. And it is very important to be aware of the dangers when using it. And neither the described organizational goal of "CMM 3 (and higher)" nor the CMM model itself gave us enough transformational model or process definition of how to get there for solving the actual problems.
In the context of a group of development labs in a global telecom organization, in a small Engineering Process Group (EPG) team with mostly engineers, we, with the authors in the respective roles of internal consultant and quality assurance manager, had a commitment to work on process improvements.
And of course, all commitments have a goal. Where were we supposed to go?
The organization had an explicitly described process improvement goal of getting to Capability Maturity Model (CMM) level 3 (and higher).
Our assignment: Make It So!
Our understanding of the CMM model started with the framework of software process maturity [Carnegie95] shown in Figure 1.
Figure 1: The five levels of software process maturity in CMM
The five levels can be briefly described as:
In Initial state the software processes are ad hoc and chaotic, success depends on individuals and heroics.
The next level is called Repeatable. Cost, schedule and functionality are being tracked and the process is fairly disciplined to repeat earlier success.
In the next step, Defined, the processes for management and building are documented, standardized and integrated in one software process that can be tailored to a project's needs.
In Managed condition the product and the processes by which these are produced are well understood, measured and controlled.
And on the final level, Optimizing, processes are continuously improved by using feedback from the development processes and trying out new stuff.
Stacks of guidelines
Besides the framework, the CMM model comes with an enormous stack of guidelines for designing the development processes and mountains of checklists of what needs to be in place for moving from one level to the next.
After reading and reading and reading some more, we realized we were heading for many disasters. And asking the "old hands" in the organization about our chances didn't make us feel any better. On the contrary, we could see danger lurking everywhere.
Danger number one
The often-used visualization of the framework in Figure 1 suggests we'll be walking up a staircase to "heaven." And who doesn't want to go there? This can land us in a mode of wanting to do "everything" and never getting around to doing anything. We thought it more important to solve the actual problems we had for serving our customers more effectively for our organization's business purpose in a reactive manner.
Danger number two
There are many people in the industry that have visionary preferences. Visionaries like working with ideas and models and to them the CMM model can look like an architectural description for designing a universal successful system. The system in this case being a company or an organization. And any model that attempts to serve all by including solutions to the problems, is by definition a repeatable state model. Meaning that it will, by use of it's own standardized and consistent processes, get in it's own way of leaving the state it is in.
Danger number three
There are also many organizers among the people in the industry, especially in management. Organizers like order and system and can easily see the CMM model as a set of checklists of which all items need to be in place. If we were to just put a structure in the company or organization by following the checklists we run the risk of solving some non-existent problems and also of not solving some of the actual problems for having a for our products and environment effective process. And that would not be very productive either.
Our conclusion: The CMM model likely contains useful organizational design guidelines in the form of Key Practices, and some extremely useful checklists, and it is very important to be aware of the dangers when using it. And neither the described organizational goal of "CMM 3 (and higher)" nor the CMM model itself gave us enough transformational model or process definition of how to get there for solving the actual problems.
Danger number four
And right there is danger number four: If our management process were in a "defined" or "higher state," we could be given a clear picture of the current situation, of where to go, and what boundary conditions to use in the solution space. Yet the "where to go" is unknown territory or at best not charted yet. And if our management process could help us better, we would already "be there" and we would not have been given this assignment.
Reframing the problem
We clearly needed to reframe our problem to give us a better sense of direction, provide us with some clues on "how to get there" and to acquaint ourselves against the dangers we could already see and the ones we could not see yet.
What we don't see, our invisible processes, usually gets grouped in the concept of "culture." We concluded that we needed to include cultural and human interpretations of CMM and we translated the CMM levels to the cultural patterns of Gerald M. Weinberg [Weinberg97].
In CMM level 1, "variable," we are in a cultural "variable" state. A way of development that has proven itself useful enough to be repeatable has not been found yet. Products are made with variable success, and there is no configuration control and no project planning based on experience. This may cause problems to not be recognized due to a focus on other, seemingly larger, problems. The question "Why is this happening?" when a problem "shows up" during development, serves to find "Who is to blame?" for we can not afford to be held responsible.
In CMM level 2 "repeatable," we are in a cultural "routine" state. One way of development that has earned its existence by proven success is used. There may be small differences and changes, but the essence of the used processes is the same. The set of available management tactics and strategies is small. Yet, many other tactics and strategies are known as possibilities but are not used often because of the risk involved. If something new is tried, it must be an immediate success, or we will fall back to our former ways. Especially for organizing successful improvement processes there is no strategic and tactical plan. The question "Why is this happening" is not asked at all because we do not see how we can change anything and if we did, we cannot afford to do so anyway.
In CMM level 3 "defined," we are in a cultural "steering" state. In this state there is closed-loop feedback control of the processes that are used to develop products. New tactics and strategies are collected and compared.
This is where the management process becomes easier by being able to "pick and choose" tactics and strategies as needed, hopefully opening the possibilities for moving to CMM 4, "managed," where the organization can anticipate on most problems and effectively deal with them. The question "Why is this happening" serves to answer "How can we change how we do things, in order to solve this problem?"
We assessed the organization we were in to be in a "routine" state and the mapping to cultural patterns resulted in the following goal for us:
Provide possibilities and support for progress of the labs towards having effective feedback loop processes for product development.
With this reframing, we could focus on "how can we support the necessary changes in how we do things, in order to have more effective management feedback control in our labs?"
What this meant in practice
And our support took the form of
Using an open-ended planning with feedback loops (nice way of phrasing that we were rather chaotic and learning on the spot and guiding ourselves intuitively);
Making the existing problems more visible (running around asking what the problems are, asking the "old hands" about other improvement attempts in the organization's history);
(Re)aligning purpose (running around with an artifact document in which people could add their perspective of how to organize problem solving);
Supporting boundary-spanning activities (expanding the team into a network; setting up web pages with information from across the boundaries; getting management to support the team members and more key people to go to AYE and PSL);
Introducing problem solving techniques (by showing the problem solving approach in our facilitation (breathing it!), and whenever possible with an actual development problem as grounding tool, by facilitation).
Open-ended planning
By using an open-ended planning we can create the necessary space for unexpected events that are bound to happen when entering into uncharted territories. We do not have to enter in a "failed" state, just in a "hey, there's some more information" state. Even "failed" solutions do not have to cause us to "fall back" to our old ways, for even these can be reframed to "well, at least we now know more about the complexity of this problem and it's obvious we initially missed some information. What did we miss?"
Making problems more visible
Making problems more visible can provide the grounding in reality for the entire effort. We can discover "what may actually need changing."
Realigning purpose Realigning purpose can help create a focus on our products and processes. The process of realigning purpose itself can create awareness on the human and cultural aspects of our current development processes and problems. It also allowed for uniting different perspectives that live in the organization and improved our positioning for success.
Boundary-spanning activities
Boundary-spanning activities can serve to gather tactics and strategies that other systems already have discovered and that may also be useful in our context and for our processes. Learning from our own mistakes is smart, learning from someone else's is smarter and learning from what works for someone else by trying it out in a by management processes feedback controlled environment is even smarter.
Introducing problem solving techniques
During (facilitation) problem solving we included the human and cultural dimension in our efforts by asking (ourselves):
What is the real problem?
Why are we doing things the way we do them?
What other ways can we see or find?
How can we optimize how we do things for solving our problem (and without hurting other well-working processes)?
We're on our way
The organization seems to us to be on its way: The small EPG team that started out can grow into a network of creative problem solvers and change artists, and management is more visible in their participation.
Our conclusion on our experiences: By using the cultural patterns as catalyst we were able to avoid getting blocked (early), we improved our positioning, and the organization can use of CMM what the organization needs and wants for solving their actual problems.
References
[Carnegie95]
"The Capability Maturity Model," Carnegie Mellon University. SEI series in Software Engineering, 1995. ISBN:0-201-54664-7.
[Weinberg97]
Gerald M. Weinberg. Quality Software Management: Volume 4, Anticipating Change. Dorset House Publishing, 1997. ISBN:0-932633-32-3.
Email this article to a friend.
Comments to:
