The meeting had been underway for about half an hour. Our departmental and quality assurance managers were debating what specifications should we measure against and what database would we need to keep the data in. The meeting had been called by the Engineering Process Group (EPG) of our R&D Optical Networking Business Unit, weeks after an ISO assessment had been done. I was attending as an internal consultant to the EPG.

I felt rather lost. Finally I mustered up what remained of my energy, and asked, "What problem are we supposed to be solving?"

After an odd silence followed by a chaotic discussion on what my question actually meant, an Engineering manager answered: "We are working on customer satisfaction issues!"

My mind wandered to the CMM and ISO Process Improvement activities of our Business Unit. The general perception in the trenches seemed to be that the process assessments were needed to "sell" our product to potential customers. That had nothing to do with our "real" problems of course. Storms come from Above and we just hide until they blow over. Some wished to use CMM and ISO assessment results to solve some of the real problems: The people in the EPG, for instance. In the EPG we were maintaining an overview of problems with an affinity grouping and interpretation of first order measurements (observed data).

History

The "old hands" of the Business Unit told us that earlier process improvement attempts had failed. "Failing" meaning "never meeting written down goals." They were cynical of our attempt but very happy to share why they thought earlier attempts had failed. With further inquiry it seemed to boil down to "mixed messages from executive management" like

"Speak your mind but don’t ask too many questions; Be passionate but don’t show your real feelings; Improve quality and production but hurry up and get it right the first time!"

Deployment

In a haphazard fashion, in between peek pressures for deadlines, problems were investigated, solutions found, a single one chosen for all project members to use and then described. And that was it. Problems were considered "solved" after a new procedure or process was created and placed under version control in "approved" state. The solutions were virtually unknown to others. Nor were they used much.

Management Process

Management asked the EPG to support the transition to a next CMM level, but support from management processes for the improvement activities was not visible and clear enough through actions and resources. Unknowingly, problem solvers in many different small Process Improvement (PI) teams spread over all departments and locations in different countries were working on same or similar problems. And every time a deadline came near, which was nearly the case at all times, people dropped PI work to do "the real work."

We seemed to be too busy using our crippling processes to improve them. Were we solving non-problems then? The Business Unit definitely had problems. And seemed not very effective at solving them. And the waves of jokes on mixed messages from executive processes, showed clearly what the "distribution speed of information in the organization" could really be: highly effective! Why did these messages get through, when other formal communication seemed to be blocked and bottled up?

My mind fled to the larger context. I also had a role in teaching systems architecture and facilitating retrospectives and architecture reviews in the larger organization, providing me with some more experiential and grounding information. I could easily recognize many organizational patterns and problems playing in this Business Unit:

Prioritization

There was a lack of visible organizational priorities in the operational part of the BU. A list was available however, on a web page on the intranet. A web page that hardly any techie ever visited. These prioritized issues changed often, and not always on the web page: The page was last updated a year ago. Every time a Big Boss from the US visited the site, the CMM level that we were supposed to "go for" in our Process Improvement efforts went way up -if not in reality then rumored- only to be lowered again a couple of weeks later at the cost of EPG members spending time and energy on managing the managers.

Negotiations

Projects were often trying to do everything. Promising customers too much or working on too many projects at the same time happened regularly. The Guessing Game, where one is only to guess at and agree with what others want to have happen, seemed part of the culture. And the Guessing Game can make requirements, specifications and planning documents untrustworthy beyond simple recoverable mistakes. This opens up many spaces for wishful thinking.

Problem Definitions and Requirements

One of the moments I realized this, was during a simulation where participants in a workshop were challenged to meet a customer’s expectation. To the participants, the customer requirements seemed to change while in actuality they didn’t: The participants had been sorting cards according to their own assumption of what "the order of sorted cards" means, instead of asking the customer for more specific requirements. I heard a participant say with a frustrated undertone, "The customer doesn’t know what he really needs."

As a result of wishful thinking about what a customer needs and wants, problem or project statements were unclear, incomplete or even missing. In some projects the related documents became unstable, so much that many techies stopped caring or bothering. In others they seemed to be written in stone -considered unchangeable- while their contents was no longer very useful. It’s not amazing that there was no project wide understanding on the purpose of these projects. And without project purpose it is impossible to do explicit expectation and goal setting in relationship to project purpose and significance to the business.

Organization

In turn, without explicit expectation and goal setting, getting clarity on roles and responsibilities becomes impossible. And we found hardly any explicit management of internal (organizational) interfaces and relationships between components/groups, so developing them wasn’t happening either. Indeed, the engineers seemed to have no clue about the impact of their work on the development departments, and the development departments no clue about the constantly swamped testing & integration department.

Testing and Quality

We were trying to test quality in! Which quality?? What is quality to whom?!?

The global organization had a list of 5 company values for all thousands of employees all over the world. One read "Exceed Customer Expectation." How many projects had we shipped in the last year that did not live up to customer expectation, let alone "exceed" it? I had no idea. None of us was directly in touch with customers and users so how will we know how we are doing?

Hhhmm, maybe the real problems could be found in our models, or rather in mistaking models of reality for Reality itself. We are extremely good at drawing cause and effect relationships, and that predisposes us to stepwise programs for making improvements in our organizations. Maybe this "blocks" change or improvements?

What were some of the dangers of modeling I had experienced, fallen prey to or seemed to have seen around me in this organization?

A Staircase To Heaven

Many of us like working with ideas and models and Quality and Process Improvement models can be interpreted as an architectural description for designing an Universally Successful System, The Essence. We are attracted to abstract models of perfection whether the object is a project, an organization or the entire company.

Visualizations of models can suggest we could be walking up a staircase to Heaven. For instance, the CMM framework can easily be seen like that. Heavenly visions can land any organization, small or big, in a mode of discussing and wanting to do "the essential thing to solve all problems" and never getting around to doing anything in a more earthly manner.

Causality Loops

If there is a best way, and if I see It and if you are one of the best modellers like me, you will understand my solution and that it is True. It’s nearly like a mantra. But when we think we can choose a solution before we can experience it we may be caught in a causality loop. Older organizations in routine state seem especially susceptible to causality loops by use of their own standardized and consistent core -essential- processes:

We have procedures that have guided us effectively and fast (in the past) — Their description covers our mental models of "the way to do things"

The problem must be solvable using our guides — Else, it is not a problem that can be solved.

We do not have to try a new way of doing things — For we already have our (perfect) guides. Go To 1.

Cultural patterns that might be related, were

When people made an agreement, it was often assumed that all involved were thinking the exact same thing.

A problem was considered solved as soon as the till then experienced as fastest thinkers had reached an answer.

People were often discouraged from speaking out, even with verbal messages from management like "open door," "feedback" and "doing together".

People rarely gave accurate descriptions of the opinions and reasoning of those whose opinions were at odds with their own.

Questions were often perceived as challenges, as being questioned means one has possibly done something "wrong" " I am "wrong??" That can’t be!

Systems architecture and engineering were seen as a primarily pro-active effort, before development, and development before testing.

The Treadmill

When finally organizing a change, checklists of which all items need to be in place are a relief. Now we "know what we’re doing" Ö with the details of the modeled solution replacing reality. We can be problem-solutioning instead of problem solving if we’re not careful. When only putting a structure in place we run the risk of Only Going Through The Motions. The actual problems hardly get solved while some non-existing problems do get solved. And who would notice?

The Business Unit is in a paradoxical state? If the management process could provide direction based on feedback, the organization would already be in a much better state for satisfying its customers? Models and standards do not provide enough transformational model or guidelines, simply because the "where to go" is unknown territory?

I came out of my reverie and discovered the meeting had continued: We were now discussing how to measure how well implementations were meeting our engineer’s models of customer wants and needs. And the schemes envisioned were big and costly.

I thought, "Customer Satisfaction? Can we start by asking our customers?"

(1) None of the symptoms, problems, perceptions and categorizations in this article are to be taken as absolutes. This is absolutely not intended to contain the last word, but more some words to stimulate thought, sharing of observations, discussion and (other) actions.

convert this post to pdf.

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.

convert this post to pdf.