The subject organization used in this article¹, Jacobs Sverdrup's Advanced Systems Group², may be a lot like yours: It employs about 400 people throughout seven states and provides a wide range of engineering services and products to all four military services and to NASA.

Each office has its own field office manager, representing an important operational layer between the senior manager and projects. As a group, services and products are delivered in several technical domains, from office and weapons system software to hardware development and validation of major weapons simulations.

Each of seven major field offices differs from the other in terms of customer culture, and all projects differ in size, complexity, and duration. Forty-person, three-year projects exist alongside two-person, 12-month efforts. Since the Capability Maturity Model® (CMM®) Integration^SM (CMMI^SM) adoption effort had to be accomplished with bottom-line dollars (from profit), the pressure to invest resources wisely and carefully was intense from the start.

The improvement effort began by chartering a software engineering process group (SEPG) in February 1999. The decision was made to adopt the CMMI for Software Engineering (CMMI-SW) as the reference model (then published as Version 0.1), as opposed to the CMM. What was the rationale for this decision? Since the organization had yet to adopt any type of process model, it seemed to make little sense to adopt an older model, and then have to upgrade to the newer standard almost immediately.

Because the organization was geographically distributed, the new SEPG went about forming and training distributed Process Action Teams (PAT) to begin the task of adopting the process areas within the CMMI. The idea was that a distributed development of the standard process would make a buy-in much easier. Each PAT was made up of personnel from at least two of the seven major offices. All of the PATs then met with the SEPG lead as the organizational SEPG on a quarterly basis. It was supported by a Web site that provided workspaces for each PAT, information and references concerning the overall effort, and a viable means of communicating among the PATs.

Unfortunately, the distributed PAT approach was fraught with participation and buy-in issues from the start (see Organizational Culture). Several solutions to the non-participation problem were tried, including tying individuals' performance evaluations to support for the PATs, positive feedback systems, a newsletter, and intense training for the SEPG and PAT members. By the time CMMI Version 0.2 was published in August 1999, it was clear that the fully distributed approach was not going to work.

Then when it was introduced, the single process structure of the CMMI for Systems Engineering and Software Engineering (CMMI-SE/SW) Version 0.2 came as a surprise. We took advantage of this by making three important decisions. First, due to the nature of the organization's business base, adopting the systems engineering model in conjunction with the software engineering model offered a major advantage because the organization now had the potential to develop a true single process for engineering from the start. Second, we decided to reorganize the distributed SEPG into an Engineering Performance Improvement Center (EPIC) with a core team of two people and field office leads from each of the seven major offices. Third, we decided to petition the Software Engineering Institute (SEI) to join the CMMI Version 1.0 product development team, primarily to avoid future surprises in the evolution of the CMMI family of models.

With a core team of process engineers and the support of field office leads from all the major offices, EPIC began the task of standard process definition in earnest. The first step EPIC took was to translate the CMMI-SE/SW process areas into core processes that were meaningful to business operations, thus adopting a core process architecture (see Figure 1). This was done for two reasons. First, the CMMI was still evolving in terms of the number and definition of process areas. Second, we wanted to focus on things that were important to the company.

Figure 1: Organizational Subsystems
(Click on image above to show full-size version in pop-up window.)

Among other things, we wanted a clear focus on product engineering, which was missing from the CMMI. We included infrastructure as a core process, i.e., a recognition that adoption of the CMMI will affect processes and technologies used by business development, human resources, training, information systems, and financial management. We ultimately found a life-cycle framework in ISO/IEC 12207 [1] that served as a starting point for our core process architecture. In addition to focusing our thinking, the core process architecture insulated us from all but the most severe changes to the CMMI-SE/SW as it evolved from Version 0.2.

During the next two years, the organization defined the standard process in six major work products, each with its own primary focus and internal customers. These included the following:

• An integrated engineering handbook for project managers, engineers, and management.
• An engineering performance improvement program plan for the EPIC.
• A process and product quality assurance plan for quality assurance.
• A measurement and analysis plan for the entire organization.
• A purchasing manual for contract managers and project managers.
• A knowledge management plan.

For our purposes, we defined knowledge management as containing five specific stages in the learning process: knowledge needs assessment, knowledge assimilation or creation, knowledge codification, knowledge transfer, and assessment of both assimilation and the knowledge-management process itself. The concept and practice of knowledge management creates alternative training solutions, and allows us to start activities like identification of knowledge domains and development of knowledge base experts.

The organization also adopted several mechanisms and (at least to us) innovations that have proven or are starting to prove their value. Among these are the following:

• A life cycle that is both flexible and recursive, allowing tailoring to support the needs of the project and the customer.
• A repeatable tailoring approach that accommodates services, systems, and hardware and software development for small to large project sizes.
• The use of principal managers and leaders in the organization to teach critical courses.
• The early development of an automated measurement database.
• The development (later than we wanted) of a distributed work environment to support process engineering and information sharing.

Several of these innovations and mechanisms have been the subject of conference panels and the SEI's working group efforts [2, 3, 4].

We understood and have reaffirmed the value of frequent external assessments as a means of refreshing our approach, clarifying issues, and evolving the process culture. We had an external SEI-authorized lead assessor conduct four profiles, or low-end assessment requirements for CMMI (ARC) Class B assessments. We have also conducted one ARC Class B assessment that was nearly a full Level 3 Standard CMMI Assessment Method for Process Improvement.

The results of our ARC Class B were that our standard process was nearly complete, but project buy-in and institutionalization was found to be lacking. The assessment caused us to refocus our knowledge management program, and to add activities to gain buy-in at the project and organizational-unit manager level. We also had an epiphany as a direct result of the assessment: Our services thread in the standard process was not as complete as it needed to be.

In all cases, we have found clarifying realizations that catapulted our understanding and insight rapidly forward. The opportunity for organizational delusion (potentially humorous when seen in other organizations, but not very funny when found in your own) is too great to not rely on frequent outside counsel. We found that frequent profiles combined with less frequent full assessments provided the right balance of value vs. cost.

The process engineering team went to great lengths to share all information openly throughout the organization. A continuous and proactive effort was mounted to get buy-in from all levels of the organization, including frequent reviews and decisions made by the EPIC field office leads, intermediate and senior management reviews through an engineering management council, and quality reviews of process documents. Most importantly, the initial version of standard process documentation was completed and refined through the full participation of four pilot projects, which represented small to large software efforts and one systems engineering effort. A significant number of changes and lessons learned from the pilot projects were integrated into the standard process.

During most of the two years, the organization also worked closely with the SEI to better understand the content and intent of the CMMI-SE/SW and associated assessment and evaluation methods. In May 2002, the organization successfully passed the CMMI-SE/SW Level 2 appraisal.

In some aspects, Jacobs Sverdrup's organizational culture was like most in the industry, yet markedly different in other respects to the industry average. There were pockets of well-developed, process-literate software development projects. These offices understood software life-cycle engineering, the value of configuration management, metrics, and quality assurance. They went about project planning in a repeatable, meticulous manner. At the same time, other projects at other locations might have difficulty in understanding the value of clearly specified requirements, or in understanding the difference between requirements analysis and requirements management.

A significant segment of the organization conducted engineering services that did not produce a typical hardware system or software product. Some efforts provided acquisition support services; some provided detailed validation of weapons systems simulations. These services projects were staffed with competent to excellent technical personnel and excellent project managers, but they did not reflect elements of a life-cycle engineering culture.

In general, no organization-wide measures were being collected or analyzed on a routine basis, except for customer satisfaction ratings and certain financial performance measures.

There also existed a set of organizational core values that were propagated and institutionalized through leadership example, training, and evaluation of office and personal performance. These core values were assimilated throughout the organization, and provided a foundational starting point for process improvement. These core values were comprised of the following statements: "We are relationship- based," "People are our greatest asset," and "Growth is an imperative."

The values were adhered to and considered in normal operations at each level of the organization. This resulted in a common culture that exhibited a consistent focus. The underlying message was that commonly held values (processes), if strictly adhered to, offered real potential for organizational and personal success. This core value system, shared by everyone from business and technical leaders to project, intermediate, and senior managers, provided the cultural foundation for process improvement.

Lastly, the organization enjoyed a strong culture of enlightened leadership. Real and consistent effort was routinely invested in defining, evolving, and improving leadership principles and practices among senior, intermediate, and project leaders. Distinctions were commonly made between management and leadership principles and practices.

Strong ethical principles were commonly exercised, illustrated by such practices as commitment to the long-term employment of proven technical personnel, the stewardship of customer resources, and a real dedication to the realization of core values. Managers were required to value the relationship with the customer over the transactional value of the effort. For example, managers routinely cared for customer resources entrusted to the organization in a way that conserved their use and provided visibility into the way they were expended on behalf of the customer. Why? Customers who are treated this way will ultimately turn over more of their resources to manage. During the time frame under consideration, the concept of operational excellence was added as an ancillary core value.

The challenges to organizational leadership proved to be manyfold, ranging from developing a trusted relationship with the organizational change agent, EPIC, to supporting the many initiatives needed to obtain buy-in from all levels of the organization.

It is important to consider these challenges carefully. In organizations that are not yet organizationally mature, leaders may attain their positions through CMM Level 1 skills. That is, it is possible to attain leadership positions with stovepipe organizational skills. If this is the case in the organization, the prospect for successful adoption of a rigorous and widely scoped model like the CMMI is much less likely. As an organization, we were extremely fortunate that our leadership was dedicated to the underlying principles of improvement.

The challenges to organizational leadership were real, and came from two sources. First, leaders were faced with having to change the way they did business, sometimes in fairly uncomfortable ways. They were asked to alter or even abandon tried-and-true concepts, attitudes, and practices that were, for all they knew, the very things that got them where they were. Then, in this changing and somewhat uncomfortable environment, leaders were asked to deal with push back (or resistance) from the organization.

Push back comes from all levels of the organization but at different times and for different reasons. It is a natural and expected part of process implementation and institutionalization. The need to respond positively and proactively to objections or criticisms of the evolving standard process is extremely important to buy-in.

Well-meaning engineers and managers sought out our senior leaders to discuss problems and difficulties with the evolving standard process and supporting technologies. This problem was exacerbated by the nature of the CMMI, as the model is intrusive on the processes used by organizational infrastructure, including information technology. It was important to rely on the leadership's knowledge of the CMMI, of the principles of process improvement, and trust in the seminal abilities of the change manager in dealing with such issues.

The change manager (EPIC technical director) developed a close and continuous relationship with the senior leadership. An early effort was made to understand how the business environment would evolve, that information would be shared across all levels of the organization, and that standard processes would normally have to be followed, even by the leadership. The problem is, these words just did not mean much to an organization that was just starting down its quality path.

So our leadership was pretty much left to discover for itself how real the CMMI is. The discovery process had several layers, each rising into view as the one before was successfully negotiated. Discovery levels included the following:

• The CMMI really does change the way every part of the organization operates.
• The costs associated with adoption of the CMMI are real and cannot be avoided.
• Routine actions have to be conducted in accordance with the standard process, as well as corrective and near-crisis actions.
• A CMMI process improvement effort is not just another project, where the work products are the most important output.
• Some of the people you have worked with and trusted for years will resist the improvement effort for various well-intentioned reasons.
• Assessments cannot be used to provide feedback and evaluate the performance of individual elements of the organization.
• The CMMI process improvement effort must be carefully aligned with the goals of the organization to make it worthwhile.
• The management and leadership style that has served to bring leaders this far in the organization now must be negotiated with the unseen authors of a complex model they are just beginning to appreciate.

The business instincts, trust, and core values of the leadership are challenged in this environment, and rightfully so.

So what combination of elements does it take to succeed in adopting the CMMI? Competent process improvement stratagems and activities are certainly necessary, but not sufficient. Innovation may provide considerable additional value to the organization, but not if the process improvement effort is terminated while the process group is busy innovating. Organizational culture and core values have a considerable effect on the probability of success of the CMMI effort. And, because the CMMI intrudes on the infrastructure of an organization, the potential impact of culture on the process improvement effort is magnified.

There will be bumps in the road. Some heroes in the organization will probably leave. It will take longer and cost more than anyone wants. Management and leadership will be exposed to a series of discoveries that will be somewhat uncomfortable, and even be asked to continuously re-examine the values, beliefs, and management/leadership techniques with which they have succeeded so well in the past. New management techniques will have to be adopted, and the discipline with which engineers conduct business will be made significantly more rigorous. The amount and detail of continuous information sharing will increase considerably at all levels of the organization.

The substantive issues that threaten the success of a CMMI process improvement effort stem from a single source: the need for every engineer, manager, and leader in the organization to evolve in a very prescribed manner of conducting business. The professional, hard-working people who make up the organization have to be led to believe that the new way will work. They need to believe it will not threaten their careers, will not ultimately make their jobs more difficult, and will allow them to succeed within a new framework that they are just beginning to understand. This task, while difficult, is critical to success. It requires business leaders who are committed to the fundamental improvement of their organization, who know and trust their people, and who have the skills and character to lead people through change.

1. Grey, Lewis. Guidebook to IEEE/EIA 12207: Standard for Information Technology, Software Life-Cycle Processes. Abelia Corporation, Mar. 2000.
2. Dutton, Jeffrey L. " IMPACTS 2000." Presentation at the 2000 Software Technology Conference. Salt Lake City, May 2000.
3. Dutton, Jeffrey L. "The Road to CMMI: What Works, What's Needed?" Technology Transition Workshop Series. Software Engineering Institute, May 2001.
4. Dutton, Jeffrey L. "The CMMI as a Framework for High Performance Organizations." 1st CMMI Technology Conference and User Group. Denver, Nov. 2001.

1. This article is a follow-up to the example in the book by Ahern, Dennis, et. al. CMMI Distilled. Addison-Wesley, 2001: Chapter 2.
2. Jacobs Sverdrup Inc. is a wholly owned subsidiary of Jacobs Engineering.

Jeffrey L. Dutton is the technical director of the Engineering Performance Improvement Center (EPIC) at Jacobs Sverdrup. He provides leadership solutions and management of process and technology improvements to the business of conducting and managing engineering programs. EPIC's principal focus is on adoption and institutionalization of the Capability Maturity Model® Integration^SM for Systems and Software Engineering (CMMI^SM-SE/SW). Dutton was a member of the Software Engineering Institute's Product Development Team for Version 1.0 of the CMMI-SE/SW. He has led systems engineering and software process improvement efforts for more than six years. Previously, he was an authorized software capability evaluator. He was also assigned to the Office of the Secretary of the Air Force (Research and Development), and Headquarters Air Force Operational Test and Evaluation Center. He has a bachelor's of science degree in aerospace engineering from the University of Arizona and a master's of science degree in operations research from the Air Force Institute of Technology.

Jacobs Sverdrup
Advanced Systems Group Engineering Performance Improvement Center
6703 Odyssey Drive, Suite 303
Huntsville,AL 35805
Phone: (256) 971-5527
Fax: (256) 971-0190
E-mail: duttonjl@sverdrup.com