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 companys
  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
  level together.
• 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 RD type projects in an organizations
  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 RD
  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/stakeholder
  s 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 customers 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 companys expense.
• Large customers will tend to have many faces
  and can seem to present conflicting direction.
• As with a technical product, the customers
  expectations generally need interpretation before
  becoming requirements.
• If an organizations 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. Dont 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
• Dont 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 dont
  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, dont 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