Organizational Implications of the CMMI Model

1. Organizational Implications of the CMMI Model Software Process Improvement Network January 9, 2004 Jim Pederson Boeing IDS

2. Characterizing the Business • In deploying CMMI based processes and in approaching an assessment, a business must characterize itself in terms of its program/project population and organizational definition. • The CMMI model, although flexible to different organizational scenarios, is built around some common, but by no means, universal assumptions about how an organization develops and functions. • By not understanding organization and program structure in relation to the model, CMMI deployment and certification will become cumbersome and ultimately risky. It will also impose a recurring cost burden that will be difficult to maintain. • By understanding the implications of a company’s organizational structure and program/project population, on the other hand, a CMMI based process can be efficiently deployed and maintained.

3. Key Concepts • An organization differs from a program or project in that it is ongoing. • The primary definition for a project in the CMMI model is synonymous with that of program. • Typically in conducting an appraisal, a business will select a sample of programs/projects that is representative of the core business. • Differing ways to assess and defend selection • Does not have to address the entire program/project population • Because process is frequently “bulky”, smaller programs/projects are generally excluded from appraisal activity. • To be useable, a program/project must meet certain minimal criteria: • Defined life cycle with fixed start and complete date • Tasks segregated, planned, and managed (multiple control accounts) • Tangible product scope definition (quantity, size, % change) • Programs can have multiple projects. In this case, the life cycle will belong primarily to the project as the program will tend to be ongoing.

4. Organizational Development and Definition • Level II • Relatively autonomous programs practicing basic project management • Organizational functions are minimal (may indirectly imply functional homerooms or matrix arrangement) • Level III • Organizational management of process established • Organization supports programs/projects • Programs/projects provide feedback to the organization • Level IV • Organization and programs/projects jointly manage process using quantitative methods. • Foundation established for parametric management of programs/ projects using tailored organizational process capability • Level V • Centralized (organizational) strategic management of process and technology to support organizational goals and objectives.

5. Ideal CMMI Organizational Definition • Program centric matrix organization • Organizational management functionally integrated – no functional stovepipes • Programs are primarily new development (full scale engineering development) • Programs do not have technical interdependencies • Programs are large enough and long enough to absorb process related overhead (minimizes the importance of having an agile process) • Definition of organization is clear and singular (single tier, single business unit, clear distinction between prime and suppliers)

6. Alternative Organizational Scenarios • There are a variety of other organizational scenarios that may exist, all of which can impact deployment. • Multi-layered organizational structure • Mature Program performing Upgrades • Research and Development projects • Production and/or Field Support • Single or Dominant Customer • General Commercial Development • A single organization or business can take on any or all of these characteristics at once depending on organizational breadth. • Each of these has significant impact on how an organization characterizes itself in relation to the model that can either streamline of greatly hinder CMMI deployment and certification.

7. Multi-layer Organization • The scope of CMMI requires re-thinking of the legacy SEPG concept even in a simple organizational structure. • Larger companies (I.e. all aerospace companies) will have multiple levels of organizational management that, at a minimum, will include the corporation and the individual sites. • Additionally, multiple business units or segments may exist at the same organizational site which may have somewhat different processes. • Supplier teaming relationships or lead system integrator relationships may create layers of organizational management that even extend beyond the corporation. • Despite practical ambiguities in defining the organization, the best approach to CMMI is group all organizational activity above the program leveltogether. • In approaching levels 4 and 5, having organizational breadth is generally advantageous.

8. Mature Program performing Upgrades • On a mature program, upgrades will usually be done cyclically and it is not uncommon for more than one upgrade to be active at the same time (phase in life cycle would be different). • The program will, in effect, be ongoing until the point of disposal or obsolescence and the individual upgrades will have separate life cycles. • The program will have a very general life cycle that may last for many years or even decades while the technical implementation will be represented in the upgrade life cycles. • The processes and even the life cycle definition will tend to be common for each upgrade cycle with only minor variation. • For CMMI purposes, the program would be represented by a representative sample of the upgrade projects. • This implies at least three levels of tailoring (org., program, project) although the tailoring from program to project would be minor.

9. Research and Development Projects • Including R&D type projects in an organization’s project portfolio for CMMI presents some specific challenges due to the nature of this type of project. • Short project life cycle • Deliverables and customer expectations • Contract value • Process scaling and flexibility in tailoring approach is required and the organizational process must be structured to facilitate this. • Corporate infrastructure may make it difficult for these types of projects to address certain CMMI requirements using common means. • Contracts and Estimating • Scheduling • Control Account Definition • Site or Business Unit ownership may be ambiguous effecting organizational process linkage.

10. Production and/or Field Support • This type of work is typically associated with an ongoing program and is represented in numerous small, short duration projects. • These types of projects have many of the same issues in relating to the CMMI model as do R&D projects due to their size / scope. • Stakeholder definition will be broad, extending well outside of engineering and product development related functions, making some of the IPPD requirements somewhat more difficult to address. • Requirements development and management are frequently issues because the customer/stakeholders will tend to specify the solution instead of the need. • Verification and Validation are also common problems because they are, to some extent, performed by the users or customers.

11. Single or Dominant Customer • Customer will frequently become (in a de facto sense) part of the organization and will have a major say in process activity. • This can be either good or bad depending on level of customer’s understanding and focus. • Ideally customer will be willing to fund some portion of infrastructure and/or specific process improvements. • Alternatively, they may demand process or technology enhancements (process infrastructure) at company’s expense. • Large customers will tend to have “many faces” and can seem to present conflicting direction. • As with a technical product, the customer’s expectations generally need interpretation before becoming requirements. • If an organization’s strategic direction is not well founded, a single or dominant customer will drive the direction of process activity.

12. General Commercial Development • Specific customers will not be identifiable in team or stakeholder definition and will tend to be replaced by marketing or other business entities that represent the customer. • Increased role of non-technical (business) functions will significantly impact CMMI deployment and these groups will need to understand the model to a much larger extent than would be the case in contracted development. • Major retailers or representatives will also become major project team players. • Role definition differences will effect both project composition and organizational process management. • Continuous trading of requirements to delivery data (schedule) becomes a strategy the has to be recognized from a process perspective.

13. Managing a Hybrid Organization • Most businesses will be comprised of a variety of different types of programs/projects and have options or ambiguities in defining the organizational infrastructure. • Adaptability is the key to success: • Agile Tailoring • Flexible Organizational Infrastructure • Agile Systems • Make maximum use of the organization – If something can be done commonly at an organization level and/or automated, then it should be. This minimizes costs, variability, and project pushback.

14. Agile Tailoring • Historically, tailoring has been a labor intensive activity that has been very difficult to apply to small programs/projects. • Tailoring does not have to be clumsy, inefficient, or take a long time to complete. • Streamline and simplify the organizational process documentation so people will actually read it. • Avoid “exclusion based” tailoring. Look at tailoring as an adaptation of the org. process as opposed to a process for taking exception to it. • Recognize that not all process are equally likely to require tailoring. Engineering process are the most likely to require significant tailoring while support processes will frequently not require tailoring. • Tailor only those process which have to be adapted from the organization standard process and be flexible on method of documentation. • Use project characterization to tailor similar efforts. Don’t re-invent the same thing over and over.

15. Flexible Organizational Infrastructure • Due to breadth of CMMI, process management will tend to be somewhat dispersed and have many stakeholders. • In transitioning from the software CMM to CMMI, organizational management of process has to be elevated or expanded. Multiple legacy groups may claim some degree of ownership. • Establishing an umbrella horizontal organization that ties legacy functions/activities together is a good interim approach. • Having one group that does everything may never be practical because low level process may become lost. • Process integration is the objective and any approach that accomplishes this is acceptable. Avoid “turf wars”. • Involve the right people • Use process experts who are motivated to support this activity • Don’t default to management unless appropriate expertise is also present

16. Agile Systems • Most material on CMMI shies away from specifically addressing automation but CMMI capable processes cannot be effectively deployed and maintained without it. • Relying solely on manual data management (metrics, quantitative management) will not work in an organization of any size. • Use of automation has many obstacles • Knowledge of process and data are rarely found in the same place • Interacting with core IT groups is frequently difficult and costly • Commercial tools facilitate tasks but don’t effectively manage information from a process management perspective. • Potential data sources are rarely integrated • Regardless of challenges, without effectively using automation, CMMI deployment will be costly and risky and process will impose significant recurring cost burden to maintain. • Savings are not limited to doing tasks quicker but extend to capturing knowledge to avoid recursive learning curves.

17. Conclusions • Relate your organization to the model instead of trying reshape the model around your organization. • Arrive at an implementation and maintenance approach that minimizes recurring and recursive cost. If you can do something once, don’t keep re-doing it. • “Right size” processes and question common legacy interpretations from the software CMM. • Stress implementation on an equal basis with documentation and the organization on an equal basis with the programs. • Include automation as an integral part of any CMMI deployment effort and bring the right people into the team to support this. • Focus on the intent of the model and avoid legalism. If you do this, the model will be adaptable to any organization