Transcript Organizational Implications of the CMMI Model

Organizational Implications of the
CMMI Model
Software Process Improvement Network
January 9, 2004
Jim Pederson
Boeing IDS
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.
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.
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.
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)
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
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.
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