Mac's staff meeting was slow that day. In an offhand sort of way he asked, "Anybody interested in bringing in the CMM?" Two hands went up, Jack's and mine. Jack had Air Force experience with the Capability Maturity Model (CMM). My interest came mostly because I was bored with accounting systems.
And so it began. "Bringing in the CMM" was, in retrospect, not the sort of run-of-the-mill quality improvement project you raise your hand and volunteer for casually during a slow staff meeting. Qualifying for a high-level Capability Maturity Model certification (see Sidebar), as anyone who's tried it knows, can be a grueling, all-consuming mobilization of your best and brightest, and a test of your organization's mettle. But sitting around that table on that quiet Tuesday afternoon, it seemed as good a time as any to explore a CMM effort.
I work for a large financial services company in one small corner of an empire spanning thousands of software engineers worldwide. Quality is key to the success of our business, but customer expectations for quality seem insatiable. A few years ago, data processing with 99.9% quality was good. Now clients are talking about quality at the level of Six Sigma: less than 3.4 defects per million opportunities.
Despite the heroic efforts of a bright and willing workforce, things in our shop do "go bump in the night." If an application error results in even a few minutes of downtime for the system, thousands of transactions may be rejected. A bump in the night can be incredibly costly for us, our clients, and their customers. One tiny mistake in a handoff or one small misunderstanding can cost millions of dollars in penalties and good will. A mistake at the wrong time can have a hundred engineers sacrificing their Thanksgiving dinners to tend a balky computer.
As the size and age of our system grow, so does the risk of failures. We took a risk, for example, when we expanded into Asian markets in 1997. A major deal fell through and our stock took a nosedive. They say pain is a necessary precursor to change, and we definitely qualified.
Something fundamental had to change if we were going to manage our risks effectively. Mac knew it. Jack and I knew it. We also knew that a CMM initiative could improve quality and reduce risk. But none of us knew then what we were getting ourselves into.
Exploring the Problem
Software author and teacher Jerry Weinberg had introduced me to a Colorado-based consulting firm at a Consultant's Camp in 1993, and its name came to mind as Jack and I left the staff meeting and brainstormed about our CMM project.
When I called the firm to ask if they would consult with us, the consultant responded in a decidedly atypical fashion. He interviewed me! He boldly asked just why I thought I wanted to get involved with CMM. When I replied that the CMM could improve the quality of life for my sometimes sleep-deprived colleagues, he seemed satisfied.
We scheduled the firm for a marketing visit in August of 1998. When their consultant came away satisfied that Mac would provide the strong executive support essential for success, our partnership began. We started with an Informal Software Process Review (ISPR).
In the ISPR, we interviewed over fifty engineers and studied six projects. The resulting evaluation, although far less rigorous and costly than a formal SEI appraisal, documented that our company was, to no one's great surprise, what the consultant laughingly called a "bottom-feeding mud-sucking level-one organization." After our consultants presented the results of the ISPR, Mac asked me to step out of my current job with accounting systems, report directly to him, and work full-time implementing the CMM. I was delighted to do so.
Jack, who also reported directly to Mac, was named co-champion of the effort. But fortunately Jack retained his position as vice president of a large software product division. Having Jack as a strong ally in a powerful position was very important to our later success.
Jack and I selected about twenty people to be trained as Change Agents. These agents attended a three-day SEI-certified course called "Introduction to the CMM." They also went to a two-day course called "Accelerating Change," developed by a local company to teach people how to implement a large cultural change project. Agents also participated in a three-day Action Planning Workshop led by our consultants' firm.
Part of implementing change is understanding your corporate culture and fitting your change strategy into that culture. We talked a lot about culture in the classes and in the workshop, and agreed that it's human nature to resist change. Two elements of our organization's culture that we would examine in a spirit of change were our rules and our reaction to rules.
We knew our company had no shortage of software process rules. When we baselined our software process documentation, including our Software Development Methodology, we counted 1776 total pages. At the same time, we were aware of our long history of the "Nike slogan" approach to building systems: "Just Do It!" Neatly understated by one of our internal audit officers, "Compliance with the Software Development Methodology is a problem."
We are a company with strong grounding in the Midwest pioneer spirit. The independence and self-reliance and the native stubbornness of our people may be our greatest asset. But independent, self-reliant, stubborn people are usually not comfortable with what they perceive to be bureaucracy.
While the CMM demands discipline in following processes, our culture demands that a process make sense before people will follow it. Clearly, we would have to build sensible processes and sell the CMM as bottom-line basic to business.
Capturing the Vision
The New Year brought me back to the office brimming with ideas. I had been to the Web site of SEI (the Carnegie Mellon Software Engineering Institute, creator of the CMM process) and to dozens of connecting sites. I had read articles about organizational change. I had rethought previous experiences from my long and checkered career. I even reread Anticipating Change, the fourth volume of Jerry Weinberg's series on Quality Software Management.
I tend to be one of those people who is not always sure where the rubber meets the road because I'm usually focused on where the rubber meets the sky. I kept imagining how to roll out CMM across the empire. I wrestled with the concept of change. I asked myself, "Why don't we do what we know we should do?" The CMM is not rocket science. It is straightforward, best practices, good management. I told myself, "This shouldn't be too tough," even though my pragmatic side knew it would be.
Next I needed someone to talk with; someone to challenge my ideas; someone to ground me with a no-nonsense interpretation of what would and would not fly in my hometown.
Sue was ideal for the job. Sue manages all the technical administrative assistants, and she has her fingers in almost every support activity. She has come up from the ranks and has been with the company for years. She knows everybody who is anybody and how to get their attention. Sue is a practical foil to my creative side. We talked for hours and gradually enlarged our circle to include other people with special skills. Together we conceived the structure and operation of what would become our Software Engineering Process Group (SEPG).
Finally, after all of my processing, I wrote a proposal describing my vision and some of the challenges I foresaw. Mac liked the proposal and shared it with his staff and others. His approval was all that was necessary to move ahead, and together we compFeted the first step of a change project: we had captured the Vision.
Selling the Vision
Leaders of change need a legitimate base of operations. They need to be touched with the "magic stick." The entire empire needs to know that they have been appointed to lead, and that they have the unequivocal backing of the powers that be.
Cynics abound in big business, and I know of none more cynical than software engineers. Tackling a change like CMM is not for the timid or faint of heart. No one must sense a leader's fear. If you haven't the confidence to proceed, how can others dare come after you? Your first flurry of activity must be big and bold. It must leave your audience with the feeling that this movement is inevitable. They can either join, follow, or get out of the way.
Now don't misunderstand me. I don't mean that your opening gambit should leave the impression that resisters will be shot. To the contrary, resisters are welcome; their ideas will improve the outcome. But resisters need to know that change will happen.
Mac simply said: "We're doing the CMM. If you don't want to participate, you can find someplace else to work." Mac is a powerful leader, and his statement was not viewed as a challenge-it was simply accepted as fact. Mac was demonstrating "strong executive support," saying loud and clear that CMM was not the "flavor of the month."
After making it clear that he was leader of this change, Mac and I led a series of meetings to introduce the CMM to staff. We facilitated roundtable discussions of the issues facing these key players. We spoke to analysts, first-line managers, project managers, and gurus, using video teleconferencing to reach outlying areas. Altogether we reached over five hundred people.
We got the message out in a variety of ways. Mac and I taped the initial meetings in which we talked about the CMM process, and created a training video on CD. We distributed that CD to Client Services and Technology Services managers, and we also made it available to our growing cadre of change agents. Our public relations staff produced a flyer that was distributed to over four thousand employees. We arranged speaking engagements at staff meetings, and we built a Web site.
Within weeks, word had spread across the empire that a Software Engineering Process Group (SEPG) had been formed and was active. Now we had shared the vision.
Organizing for Action
The CMM effort would become a long-term part of our overall organization, and now we began building the structure that would make that possible. The group evolved over several months to include the following SEPG subgroups: agents, staff, core support, local SEPGs, Technical Working Groups (TWG), and the SEPG Change Council. Each of these units serves a vital function in the CMM initiative. We need these groups to assure that each person has a role and responsibility commensurate with his or her time and talent. We need lots of people creatively involved in order to spread support for change.
Before becoming a software engineer, I worked for eight years with volunteer agencies. I believe that building a CMM project in a large organization shares much in common with building a volunteer organization:
Recall that we started with a group of about twenty people called change agents. We soon grew to over a hundred agents. It was significant that each participant was invited by a staff person who reports directly to Mac: This means each person was invited by his or her vice president to be a part of this important movement.
We try to have one agent for every two dozen engineers. Agents represent their own work groups at monthly meetings, and they are responsible for communicating between the SEPG and their work groups (each agent receives meeting minutes, which helps clarify the communication). Meetings aren't held for the sake of having meetings; agents receive advance notice of proposed process changes and have an opportunity to comment on those changes.
Agents are organized into local SEPGs. Each of Mac's immediate staff has a local SEPG, with a chairperson responsible for ensuring that the CMM is implemented in his or her area. The SEPG chairpersons meet weekly as part of an SEPG leadership group.
Technical Working Groups are cross-functional ad hoc groups organized around a particular challenge. They are temporary groups operating under an approved charter. TWGs define and propose new processes and process changes, and their group leaders meet weekly with the chairpersons of the local SEPGs. TWG leaders also meet weekly with their own groups.
Some agents represent support areas such as Documentation, Training, Change Control, Tools, and so forth, and I invited these agents to sit on a special SEPG Core support group. The Core support group meets twice a month to review change requests. They answer the question "Can we support the requested process change?" If yes, the change request moves on to the Change Council.
Selected senior managers sit on the Change Council. (Jack was one of the first to support the Council and attend regularly; his high-profile support helped make the Council viable.) This group meets twice a month and answers the question "Should this process change be implemented?" If yes, the change is rolled out across the company. The Change Council assures that each change has management support and makes good sense for the corporation. Change Council also approves TWG charters.
The SEPG full-time staff manages these groups day-to-day. SEPG staff now include a variety of individuals, each of whom brings a key skill and unique perspective to our operation. We have a talented, ambitious young engineer with audit experience; a wily ex-diplomat with a rich background in sales, management, and strategic planning; a soft-spoken Bostonian with ten years in Software Quality Assurance; a warm, caring earth mother with lots of good sense; and a competent, compulsively organized, sometimes manic lady who can always make us laugh. We operate like a creative team.
Now comes the tough part. We had made a splash, and everyone was looking our way. So what's next? This is the part I call "staying alive." We were strangers in a strange land. The locals needed to accept our message and to accept us or the movement would be doomed. We did survive, but only just barely.
We knew that at that point we should be modeling CMM Level 2 behavior and "Walking the Talk." But that required documenting SEPG policies and procedures. We had to build a project plan. We needed staff meetings and monthly reports. We had to do intergroup coordination with the Quality Division and with Methodology and Tools, with Tech Doc and with Training. We had to direct the TWGs. We had to organize the local SEPGs. We had to lead groups who were defining roles and responsibilities.
Most importantly, we had to respond to numerous scrimmages as the old informal power structure within the empire was reshaped. The former Policies and Planning Review Committee was disbanded. Several advisory groups were relieved of their duties, and new TWGs were chartered. We organized the SEPG Change Council and began coordinating all software process improvements company-wide.
Reinforcing Command and Control
Meanwhile, our small staff was stretched to the breaking point. We missed phone calls. We took weeks to do what we should have done in days. We were juggling a dozen plates in the air. Something was bound to come crashing down-and it did.
The old process structure did not die quietly. Mac's immediate staff were confused and uncertain what was happening. They were, like Jack, senior executives in their own right, managing multi-million-dollar departments. They could see our small, bedraggled staff being tossed on a sea of change, and sent word back to Mac that the CMM initiative was out of control.
Mac called me into his office. Saying the CMM needed help he didn't have time to give, he told me that Martha, one of his immediate staff, would be my new manager. I was not pleased, but Mac was right. We needed help. Furthermore, Martha was my harshest critic; had we not found a way to bring her onboard, the movement would have been doomed. And with budget season upon us, someone had to fight for resources and funding. Martha was that fighter.
As summer dawned, Martha set about getting more resources for CMM. She seized on Mac's idea to have some people step out of their regular jobs for six months to do process improvement. Martha herself stepped out to work full-time on CMM. She selected six other volunteers and appointed each of them to lead a TWG to work on process improvements related to one of the Level 2 Key Process Areas.
We now had a TWG for Requirements Management, Project Planning, Project Tracking and Oversight, Software Quality Assurance, and Configuration Management. We also had a half dozen non-CMM TWGs in progress; I assigned one of our SEPG staff to work with each TWG to assure coordination. We also brought the TWG leaders into the Leadership group to meet weekly with chairpersons of the local SEPGs.
Martha also picked up the banner of the CMM in public forums. She and Mac spoke about CMM before the annual meeting of all Technology Services-nearly two thousand people. Imagine my surprise to walk into that meeting to see all of Mac's immediate staff wearing shirts with "CMM" emblazoned beneath the corporate logo. Clearly, the initiative was going to live. It had grown beyond my dreams and beyond my control. My eyes welled with tears. This change, this maturing of our capability to produce quality software on time within budget, was inevitable-and possible.
Lights, Camera, Action!
With hundreds of people energized, we needed to give them meaningful ways to progress. I kept hearing "They should do this." Or "You should do that." Our response was, "Hey guys, take a look at your own backyard-can't you find something to improve there?"
We divided the empire into sixteen "backyards," one for each of Mac's immediate staff. We developed a series of meetings designed to introduce each backyard to the CMM processes of self-assessment, gap analysis, and self-improvement. Remember Jack, who had implemented CMM in the Air Force? Who jointly sponsored CMM while maintaining his role on Mac's staff? Jack's backyard SEPG was the first to take off and make real progress. Jack's agents conducted interviews and recorded data comparing their practice with the CMM. They led the way, and others are now following with enthusiasm.
Our SEPG staff is still busy, but we have more sense of direction. Along the way we have built a two-day course, mandatory for directors and above in Technology Services. This course emphasizes how the CMM fits with our culture. By building the course ourselves, we saved in consulting fees, and we delivered a class that uses our vernacular. It brings the CMM into our context and culture.
We have now given half-day CMM overviews to over a thousand people. We have arranged two-day CMM classes for nearly two hundred. We have over a hundred active SEPG change agents. The Change Council has approved dozens of small process improvements and chartered many others.
In each backyard across the empire, the historic pattern is followed. Small creative teams are inventing ways to work better, smarter, and with less risk. Those small creative teams are making big changes in culture and practice.
We have only just begun: we've passed a one-year milestone on a five- or ten-year journey. The CMM has sold itself-with a little help from its friends.