Delhi Business Review ? Vol. 3, No.

1, January - June 2002

CAPABILITY MATURITY MODEL

A HUMAN PERSPECTIVE

Gita A. Kumta
Mitul D. Shah

W
ORLDWIDE, Information Technology has become a driving force in evolving a business strategy.
Software manages business information to provide the competitive edge, it provides the means to
acquire information in all its forms and provides a gateway to worldwide networks & repositories of
information. The growth has resulted in a significant increase in software development activity. There have
been dramatic enhancements in hardware performance and system architectures, which in turn, have resulted
in highly complex multi layered computer-based systems. These systems are no more supported by a single
programmer but require a team working on various facets of the software. This has resulted in cost & schedule
overruns resulting in poor quality software and customer dissatisfaction.

These concerns were voiced both by customers and developers and were manifested in the following questions:

? Why does it take so long to complete a software project?

? Why are the efforts so high? This in turn increases the cost.
? Why can’t we ensure error-free software?

There was a need for a more disciplined effort in developing software. The software engineering practices
provided a framework for building high quality software.

Building quality software is a process supported by methodology and tools and involves people working over a
fairly long period of time. Software projects therefore need to be managed well throughout this lifecycle.
Acknowledging this need the Software Engineering Institute (SEI) at Carnegie Mellon University developed a
Capability Maturity Model (CMM), which defined key performance areas from an initial level of maturity to a
level of optimisation.

The model focuses on the management at each level. Effective software project management focuses on people,
process and the product. At every level of CMM it is important to consider the people issues as the success or
failure depends largely on the people capabilities both managerial and engineering. The SEI has therefore
developed a People CMM, which provides a roadmap for implementing workforce practices that continuously
improve the capability of an organization’s workforce.

CMM requires a total change in the mindset of the Project Managers. In level 2 in which most organisations are
initially, project managers follow their own models and get the credit for success. Moving on to level 3 requires
the project managers and software engineers to follow organisation level processes, which are not to his credit.
His methods, though were best practices at one time, have now got embedded into the Organisational Standard
Software Processes. Level 4 & 5 focus on metrics and the effective use of this poses a challenge.

CMM also requires the measurement of the efforts taken for each activity so as to define the baselines.
Experience of organisations indicates that recording time spent is viewed as being monitored individually and
Gita A. Kumta & Mitul D. Shah

hence does not provide the right picture. This affects the baselines and more reliable efforts estimation. CMM
focuses on clear documentation and therefore any quality management initiative is viewed as additional work.
In the absence of adequate tools for use of latest technology, the processes create a feeling of additional workload.

Level 3 focuses on organisational focus and a framework to support organisational processes so as to ensure
that these are implemented. This necessitates the setup of two critical groups – SEPG and SQA. Getting the
right people here again is a challenge.

“As other sources of competitive success have become less important, what remains as a crucial differentiating
factor is the organization, its employees, and how it works”. [Pfeffer 94]

Introduction
A software project is characterized by cost, schedule and quality. A project is said to be successful if it meets or
exceeds the expectations on all the three fronts. Failure of most software projects can be attributed to the
following critical factors:

? Improper estimation
? Slack requirements management
? Weak project management
? Improper risk management
? Poorly engineered solutions.

“These can be combined in one category called ‘Process Failure’. That is, a software project often fails because
the process followed in the project was not suitable”. (Alexander, 1991) There has therefore been an increasing
focus on ‘process maturity’ in software development, which aims at enhancing productivity, improving quality
and enabling predictability.

Productivity of an organization is the productivity of its people who are part of the processes. Process encapsulates
the collective experience of the employees and the organization, enabling the organization to leverage this
experience in future projects thereby enhancing productivity. Quality can be defined as the satisfaction of a
customer through the product, which highly depends on the management of user requirements and reviews at
every stage of the development lifecycle.

In the knowledge-based industry, where performance cannot be solely measured by the number of hours one
puts in, the conventional scheduling is not effective. Predictability is the precision with which organization
improves its bottom line through accurate scheduling and costing.

A mature process is consistent with the way work actually gets done, defined, documented, and continuously
improved. It is supported visibly by the management and the software engineering group. A mature process is
a controlled process where compliance to a process is audited and enforced. The measurement of product quality
and process maturity is used constructively to evolve the quality culture in the organization. The use of technology
is disciplined through the key performance areas.

When an organization builds an infrastructure that contains effective, usable and consistently applied processes,
the culture develops gradually. Organizational culture conveys the process, management nurtures the culture
and the culture is conveyed through role models and reward / punishment strategies. With all these in place, the
processes are institutionalized.

One of the most comprehensive software process improvement and assessment framework is the Capability
Maturity Model (CMM) developed by the Software Engineering Institute (SEI) at Carnegie Mellon University.
The Capability Maturity Model categorises software process maturity into five levels, starting from an initial
level to an optimised level. The Model specifies key process areas (KPAs) for each level, which determine the
process maturity in the organisation in respect of software development. The model is discussed briefly in the
next section before we go on to discuss the human perspective of the model.
 Delhi Business Review ? Vol. 3, No. 1, January - June 2002

Capability Maturity Model (CMM)

Capability Maturity Model for the software development is a framework, which describes the key elements of
an effective software development process. The CMM describes an evolutionary improvement path from an ad
hoc, immature process to a mature disciplined process. It covers the practices for planning, engineering and
managing software development and maintenance. These key practices improve the ability of the organization
to meet the goals for cost, schedule, functionality and product quality.

The CMM establishes a yard stick against which it is possible to judge in a repeatable way, the maturity of an
organization software process and compare it to the state of the practice of the industry. (EIA 731, 1998) The
CMM framework is depicted in the following figure 1.

CMM

Initial
Initial Repeatable
Repeatabl Defined
Defined Managed
Managed Optimizing
Optimizing
Level
Level e Level
Level Level
Level Level
Level Level

• Software Quality
• Requirements Management Management
• Software Project Planning • Quantitative
• Software Project Tracking and Process
Oversight
• Software Subcontract
Management • Process Change
• Software Quality Assurance Management
• Technology Change
• Organization Process Focus
Management
• Organization Process
Definition
• Training Program
• Integrated Software
Management

Figure 1: CMM Framework

Level 1 : Initial Maturity Level

In the first level of CMM, performance of an organization is driven by the competence and heroics of the
people doing the work. High quality and exceptional performance is possible so long as the best people can
be hired. Unpredictablity exists everywhere, for good or ill. The major problems faced by software
organizations are managerial, not technical.

Level 2 : Repeatable Maturity Level

At this stage, the critical need is to establish effective software project management. Software project
management processes are documented and followed. Organizational policies merely guide the projects in
establishing management processes which are more project specific. Thus top management involvement is
Gita A. Kumta & Mitul D. Shah

partial and does not drive the initiative. To be able to repeat best practices of the earlier successful projects
requires these to be documented adequately. At this level , the focus is primarily on projects.

Level 3 : Defined Maturity Level

At level 3, the emphasis shifts to the organization. Best practices are gathered across the organization and
Organization Standard Software Processes are defined and tailored to projects if required. The organization
now supports the projects by establishing common processes for software engineering and management,
measurements and training.

The process capability is based on a common, organization wide understanding of the activities, roles and
responsibilities. At this level, measurements have been defined and collected systematically.

Level 4 : Managed Maturity Level

At level 4, decisions are made based on data collected. The organization sets quantitative goals for both
software products and processes. The process performance and the project progress is controlled
quantitatively. At this level, all organizational processes are mapped to a common measurement and
assessed using a base line.

Level 5 : Optimizing Maturity Level

At level 5, continuous process improvement is a way of life. The focus is on preventing the occurrence of
defects and inducing innovations. In immature organizations, no one may be responsible for process
improvement. Mature organizations usually have 70-80% participation in improvement activities at any
given point in time- every one is involved. Continuous process improvement means controlled change and a
measured improvement in process capability.

Discussion on any model is never complete without a discussion on the issues in implementation of the
model. The key factors affecting the implementation of the CMM can be summarised as follows.

Management of Change
Since the management of change is a key element of a successful process improvement program, the
following mechanisms should be put in place in order to facilitate the development, implementation, and
adoption of processes, methods, and tools. (Kitson, 1992)

? Setting up priorities in accordance with the company vision and business strategy.
? Coordination of the Organizational Process

Implementing these processes would need organizational coordination and direction with a steering
committee to monitor the entire process. The Software Engineering Process Group (SEPG) to define
and maintain the organizational processes and the Software Quality Assurance group (SQA) to ensure
the implementation of the processes providing support to the teams are two critical groups that need
to be established.

? Establishment of time-to-market, quality, costs, and product performance

Objectives and baselines to be supported by organizational processes.

? Support for process performance improvement through :

– Charter of technical area working groups
– Fixing resources budget for process groups
– Review of assessments and audits results
– Monitoring of process performance regularly with plan of action for improvement.
 Delhi Business Review ? Vol. 3, No. 1, January - June 2002

Process Ownership
A process owner i.e. the SEPG is responsible for the processes’ effectiveness and efficiency, methods, and
tools. Knowing that a project manager and a process owner may have conflicting views about the tailoring
of a process, a policy should be written to handle such conflicts. In the event of a deadlock between a project
manager and the process owner, both would present a risk analysis to a Executive Committee for the final
approval of the tailored process.

Awareness
An important aspect in implemetation of the model is to make the whole organization aware of the
initiative and processes. This could be achieved through seminars and workshops.

Meeting Guidelines
In order to facilitate the conduct of working group activities, a number of meetings are required to be
conducted which require guidelines to be established. (Laporte, 1997) Facilitators in such meeting play a
very improtant role so as to bring about a result at the end of the meeting. Eventually, a group can manage
the “soft issues” without an outside facilitator.

Decision Making
A participative method of decision making with reference to process improvement will be helpful in capturing
the best practices of various groups thereby enriching the organizational processes and the quality of the
product and reducing the time to market. (Paulk, 1993)

Team Evaluation
Periodic surveys to evaluate the team’s efficiency would be an effective tool to improve the capabilities. The
survey (Pfeffer, 1998) can address the following issues:

? goals and objectives

? utilization of resources
? trust and conflict resolution
? control and compliance to procedures
? interpersonal communications
? problem solving
? experimentation and creativity.

This would help in providing the necessary inputs at the right time to enhance the capabilities of the
organization.

Knowledge Management
Knowledge is the most critical factor in enhancing the productivity, quality and predictability of software
development. Although software tools can help record and manage knowledge, they do not create and apply
it. Perhaps no industry in history has been as knowledge intensive as software development, an industry
whose only product is proceduralized knowledge. Not surprisingly, the level of talent on a software project
is often the strongest predictor of its results [Boehm 81], and personnel shortfalls are one of the most
severe project risks [Boehm 87].

As seen from the above discussion the success of software projects requires significant people orientation.
It is necessary to understand the human perspective in implementing the model as it is critical for the
success of the model.
Gita A. Kumta & Mitul D. Shah

Human Perspective of the Capability Maturity Model

The Capability Maturity Model provides a framework indicating ‘what’ should be done to improve software
development process with little or no emphasis on ‘how’ it should be done. It does not give implementation
details for technical and management processes employed in the organization to achieve higher productivity,
quality and predictability. As a consequence, the need has emerged for maintaining a comprehensive account of
successful CMM implementations, which are primarily a combination of process, technology and people as
depicted in the following figure 2.

Technology
Technology
People use technology
People use technology

Synchronization
Synchronizati
People on
People

Processes
Processes
People work, execute and
People work, execute
contribute to the processes
and contribute to the
processes
Figure 2: Relationship between People, Processes and Technology

Processes are effective with the optimum use of technology. Evolution of technology and changing processes are
to be synchronized at every level of CMM. Skill levels should be continuously upgraded to cope up with changing
technology.

People work, execute and contribute to the processes. Organization would learn about new practices, implement
and deploy these through increased maturity and skill of people involved in these processes.

People use and absorb technology. Lack of knowledge creates stress, resulting in lack of planning eroding the
capability of the organization. With newly invented technology, customer’s awareness and demand increases
which needs to be satisfied. Training and upgradation of skills becomes essential.

Apart from the size of the product, capability, attitudes and work culture have the strongest influence in
determining the amount of effort required to develop a software product. Although the presence of an extraordinary
individual on a project can have dramatic impact, there are not enough “wizards” to staff more than a handful
of the projects in most organizations [Curtis 88].

Much of a professional software developer’s time is spent learning through such activities as reading manuals,
discussing design issues with colleagues, building prototypes to test ideas, and attending organized learning
experiences such as seminars and conferences. The pace of technical change and the depth of knowledge required
to implement complex systems require extensive investment in personal learning, both on the part of the
organization and the individual.

“Personnel attributes and human resource activities provide by far the largest source of opportunity for
improving software development productivity”. [Boehm 81]

People Issues in Implementation of CMM

Organisations generally take up an initiative in implementing the Capability Maturity Model based on the
recommendations of the consultants or on the initiative of senior management who hear about the benefits to
 Delhi Business Review ? Vol. 3, No. 1, January - June 2002

the organisation on attaining a maturity level. Many a times it is the customers who prompt these organisations
to take up the certification as it ensures the quality of the product. These objectives are perceived as easily
attainable as the managers down the line do not bring out the issues for fear of displeasing the senior
management.

Senior management therefore mandates middle managers to attain this objective in an unreasonably short
time. A formal process assessment highlights a number of countless findings that developers had known about
for a long time. These were never projected to the senior management as middle managers were busy fire
fighting and ignored certain long-term issues which have now been brought out by the assessment. The senior
management who had publicly announced its initiatives / objectives suddenly realizes that it will take a lot
more time and resources than initially estimated.

In such a situation the following three reactions are possible.

? Senior management may accept the findings but still confirm that it will continue to support the objectives
announced and provide the necessary resources.
? Senior management may announce discreetly that objectives will be lowered and work at a more feasible
level.
? Senior management will want to adhere to the objectives but will not be in a position to accept the
assessment findings which requires them to put in place an action plan to correct the deficiencies highlighted
by the assessment due to the organisational culture .

It is the third reaction which could have a destructive effect on the morale of the developers, since they know that
the deficiencies they had been experiencing will continue to be ignored and in addition there will be a pressure
to achieve the unattainable target.

The people responsible to bring about these changes are often extremely talented software engineering
practitioners. They are, however, not too well equipped in change management skills. Their academic training
is focused on the technical dimension and not on the human aspect while the major difficulty of an improvement
program is precisely the human dimension.

During the first few months of the introduction of a new process, a new practice, or a new tool, management and
employees must acknowledge that mistakes will be made. Unless the management recognizes this situation,
employees will tend to hide their mistakes. In such a situation neither will the organisation benefit nor will the
employees learn from mistakes. Other employees will continue to make the same mistakes.

A formal inspection/review process will be required to detect and correct errors as soon as possible in the project
life cycle. This will generally be ignored when deadlines are to be met. The conflicting demands of quality versus
scheduled delivery has a tremendous impact on the morale of the team.

In order to understand the people issues encountered as one moves along the capability maturity ladder, it
would be necessry to assess these at each level of maturity. This is elaborated in the following paragraphs.

People issues at Level 1

Organizations at the initial level of maturity are poorly equipped to respond to talent shortages. They
usually have difficulty in retaining talented individuals. Processes in low maturity organizations are often
adhoc and inconsistent. Either they are not well defined or individuals are not adequately acquainted with
the existing processes to enable them to follow them. A skilled engineer tends to assume supremacy and
develops a superiority complex that is detrimental to the organisation.

Organizations at the initial level typically exhibit four characteristics:

? Inconsistency in performing practices,
Gita A. Kumta & Mitul D. Shah

? Displacement of responsibility,
? Ritualistic practices, and
? An emotionally detached workforce.

Organizations at this level implicitly assume that management skill is innate. Generally, managers and
supervisors in low maturity organizations are ill prepared to perform their workforce responsibilities.
Their management training is sparse and, when provided, tends to cover only those workforce practices
with the greatest legal sensitivity.

How people are treated depends largely on personal orientation, previous experience, and the manager’s /
team leader’s ‘people skills’. Very often managers and even senior managers perceive management to be
about producing results, not about developing people who produce results. They accept responsibility
without understanding how to manage the collective performance of those in the unit. Though this
requirement is general, it is more critical in software development where team work is crucial for the
success of the project.

People issues at Level 2

At Maturity Level 2, an organization’s capability for performing work is best characterized by the capability
of project teams to meet commitments. This capability is achieved by ensuring that people have the skills
needed to perform their assigned work and that performance is regularly discussed within the group to
identify actions that can improve it.

The processes implemented at the Managed Level focus on activities at the project level. Project managers
are required to accept personal responsibility for the performance and development of those who perform
the unit’s work. The processes implemented at Maturity Level 2 focus on a manager’s attention on project-
level issues such as staffing, coordinating commitments, providing resources, managing performance and
developing skills required for the project and not on his contribution to the organisation in improving
processes.

Organization-wide improvement programs often fail at this level because they are thrust on an unprepared
management team. Managers at this level are struggling with problems that are not addressed by
organizational changes. They often lack the experience and skill needed to implement sophisticated practices.

The focus is on establishing basic processes within projects that address immediate problems and prepare
managers for implementing more sophisticated processes at higher levels. It is difficult to implement
organization-wide processes if managers are not equiped to perform the basic processes required to manage
individual projects. If people are unable to perform their assigned work, sophisticated processes will be of
little benefit to individuals or the organization.

At this level frequent problems pose a hindrance to people who are unable to perform effectively. Some of
these are:
? Work overload due to rework.
? Unclear performance objectives or feedback
? Lack of relevant knowledge, or skill. It is difficult to have all the skills within a project group. In the
absence of an organisation level policy access to available skills in other projects is difficult. Project
managers tend to retain the team even if it can be reduced for fear of not getting the resources when
required.
? Poor communication channels. There is no organisation level structure to facilitate inter group
communication. It happens only at to the initiative of the project manager.
? Low morale due to lack of an organisational focus.
 Delhi Business Review ? Vol. 3, No. 1, January - June 2002

People issues at Level 3

Organizations at the repeatable level find that, although they are performing basic processes, there is
inconsistency in how these processes are performed across projects and little synergy across the organization.
The organization misses opportunities to standardize unit processes because the common knowledge and
skills needed for conducting its business activities have not been identified.

The challenges which organization goes through in reaching level 3 are more people issues than issues
related to skills because the organizational focus brings into the existence two new entities – the Software
Engineering Process Group (SEPG) and the Software Quality Assurance group (SQA). These two entities
are not in the main line function of the organization but require people with motivation and commitment
and knowledge of what is happening in the organization.

The middle level managers can contribute immensely to the SEPG but are unable to spare time due to
project pressures. Giving 100% commitment to this activity requires a role definition by the top management
with responsibility and authority adequately defined. Contributions from the managers of various groups
help consolidate and define organizational processes. This requires a conviction that “we need to do it”. It
is a collective effort of a motivated group. A demotivated team may not only result in poor process definition,
but will also hinder the progress of the teams adhering to the processes. It is found many times that the
project teams have been doing certain practices, which are similar to what has been defined in OSSP, but
never realized that their processes had so much hidden potential. Its here that ‘ I don’t know what I know’
and ‘I know what I don’t know’ both get addressed.

The mandate for SEPG is to enable the organisation to perform and repeat best practices, incorporate
lessons learned in the processes and continuously evaluate and update the Organisation Standard Software
Processes (OSSP). This group should have the best project managers and software engineers to be able to
evaluate the processes. This poses two problems – to be able to convince the ‘best’ people to undertake this
task and to obtain the acceptability from all the project groups. Interpersonal rivalries and ego clashes
need to be handled effectively to make this a success. Composition of this team is very critical and their
acceptance is most crucial. If unwanted persons are assigned this task the acceptability of the processes
itself is in question.

At the project team level there is a change of practices and any change is always resisted. Teams are
sometimes unable to accept other practices as best practices as they had been convinced that theirs was
the best till now. Some of the reactions to this situation could be best expressed in statements/questions
such as ‘How can someone else define processes for me?’, ‘They don’t understand our difficulty’ ‘ There is so
much more work to be done now which will delay the project’.

To ensure that the processes so defined are adhered to, there is a necessity of a group that takes care of
quality assurance at all levels. The constitution of SQA group is a challenge in most organizations. The
skill intensive system group always looks upon quality assurance as an unwanted activity. They feel that
testing and auditing isn’t their job and look down upon it as a policing activity. There is a feeling of mistrust
mainly because the quality assurance group’s objective is to ensure that there are minimal defects in the
final product. However there is conflict here. The performance of the SQA group is judged on how many
defects he has detected – the more the better; while the performance of a system engineer is judged on how
many less defects his product has – the less the better. But both of them have to work together towards a
common goal! The best way to incorporate this into organizational culture is to have a group that is
motivated to work along side the technical team with a mandate of assisting the project teams. This not
only brings in the synergy required but also eliminates the feeling of mistrust between the two teams.
However, in the recent past the CMM culture has improved the perspective in relation to quality assurance.
People have realized that quality assurance is a supportive group rather than a policing group.

CMM level 3 is a springboard to improve the capability of an organization. As it is from this level that one
needs to start measuring various aspects of the development life cycle to build a baseline for level 4.

The measurement of effort is most basic to control. Measurement of time taken for a particular activity can
Gita A. Kumta & Mitul D. Shah

be best measured only by the data provided by the person working on that activity. So a time sheet or an
activity report becomes the fundamental instrument for measuring effort. Traditionally, this instrument
is treated as a basis to evaluate performance. Hence, the tendency of people to misinterpret the effort
figures is very high because this is viewed as a document which can be used as an appraisal. The problem
here is two fold – the manager is tempted to look at it to know the productivity of a person while software
engineer tries to project his assignment to cover the whole day irrespective of whether it is idle time or
productive time. This does not therefore, give the right picture of effort required to do a particular activity
in the project. It is therefore, necessary here, to indicate to the managers that this is not a tool to measure
the productivity of an individual but should be used to indicate or to consolidate the effort required to
undertake a particular task in the project. The focus is not on the individual but on the task or the activity.
And the software engineer should be assured that this data is not used for the appraisal and is merely to
compute the efforts the organization takes to perform various activities. Institutionalizing the time sheet
is the greatest challenge for any organization and the most important aspect here is the perception of being
monitored on a daily basis. Therefore, a faulty response to this measurement tool creates a wrong starting
point for level 4.

At level 3, the challenges are therefore manifold. Firstly, to change the mindset of the project managers and
the project teams to accept the best practices of the organization in the form of Organization Standard
Software Processes (OSSP) and secondly, to initiate measurement and improve continuously.

It is a paradigm shift in the thinking of the people. It also requires tremendous orientation of the organization
wide processes to make people aware of the OSSP. The assessment of an organization for level 3, therefore
very clearly brings out the necessity for orientation of the organization towards OSSP.

An important aspect here is of building of a project assets database, which is the starting point of a good
knowledge management system. Sharing of knowledge is the basis from this level upwards which is the
most difficult aspect of human behaviour as losing control over some specific information is hurting. The
culture of an organization is reflected in the shared values and resulting patterns of behavior that characterize
interactions among its members. At this stage a cultural change is initiated.

People issues at Level 4

As we move on to level 4, control becomes a very important aspect. Control is primarily based on
measurement and its interpretation. Baselines, which were not extensively used in Software Development
Life Cycle (SDLC), have now become driving force in a CMM level 4 organization. An organization at the
defined level has established an organizational framework for developing its software products. The conflict
occurs at the time of setting up a baseline. One has to ensure that realistic goals are established through
analysis of past data. The project groups who need to achieve these goals need to be properly briefed about
these goals.

At the managed level, the organization manages and exploits the capability created by its organization
wide framework. The organization is able to predict its capability for performing work because it can
quantify the capability of its people and of the competency-based processes they use in performing their
assignments.This requires a changed approach to management and therefore upgradation of managerial
skills. However, it is necessary to remember that while it is necessary to manage quantitatively, managers
should not forget human side of management.

People issues at Level 5

Continuous process improvement means controlled change and measurably improving process capability.
Mature organizations usually have 70-80% participation in improvement activities at any given point in
time- every one is involved. At this level quality is a way of life! It is part of day to day activities and both
the management and the project groups see a common goal.

The organisation needs to sustain the enthusiasm and the commitment of the SEPG, SQA and the Metrics
council so as to be able to maintain the cababilities at this level. The culture that has set in needs to be
 Delhi Business Review ? Vol. 3, No. 1, January - June 2002

nurtured through continuous orientation and upgradation of skills. This means cost to the organisation but
any slippage on this would hurt the credibility of the Model.

Critical Success Factors

Organizations discovered that the improvement of process lacks the ‘People’ factor as most of the improvement
programs were focused on process or technology. Increasing the capability of software developers was necessary
to:

? Meet growing demand for software while faced with a talent shortage,
? Master the accelerating pace of change in technology, programming languages, and business applications,
and
? Increase the reliability of software systems, especially in life-critical and business-critical applications.

Certain lessons learnt by organizations while implementing the CMM with regard to people issues are indicated
below. This would help the other organizations to implement CMM more effictively.

Set Realistic Expectations for Senior Management

Appropriate expectations must be set prior to embarking on process development. The trap, especially for
a low maturity level organization, consists of communicating to management the idea that a process
improvement initiative will be easy, fast, and inexpensive, has to be avoided at all costs. It is better not to
proceed to an assessment if it is not intended to deal with the findings. Once the problems are identified
and publicized within the organization, if the management decides not to act, it sends a very bad message
to practitioners.

Secure Management Support

A lesson for low maturity level organizations consists in realizing that most of the assessment findings
target the deficiencies of management processes. It is necessary to create an environment where the
organization is ready to invest in implementing processes rather than blame its managers; in other words
where the management is ready to fix the process, not the people. This is one of the reasons why it is
necessary to keep senior management informed so it can show understanding and full commitment when
these findings are publicized within the organization.

Besides senior management buy-in, it is essential that middle management and first-line managers
become ‘champions’ of the process improvement program. The strongest signals sent are through the day-
to-day activities of managers. The developers must receive clear signals that the changes announced will be
implemented and new practices will be enforced.

Identify the need and expectations clearly

The involvement of process owners or managers is largely related to their understanding of the situation
i.e. strengths and weaknesses of management and processes. Once convinced that the current situation is
undesirable, they will provide the leadership, direction, and momentum to implement solutions. They can
also keep working groups focused on solving the right problems since it is very easy, after a few meetings,
for a working group to start solving what it perceives to be the problems.

Establish a Process Improvement Working Group before an Assessment

It is the best if a small process group becomes active in process activities several months before the on-site
assessment. The process group should take this time to familiarize itself with the processes (Popick,
1996), methods and tools. Ideally there should be one full-time person in the process group, while the other
members could be assigned on a part-time basis. Beyond their technical competencies, the members of the
process group should be selected based on their enthusiasm for improvement and the respect they have
within the organization.
Gita A. Kumta & Mitul D. Shah

Start Improvement Activities soon after an Assessment

With regard to the development of the action plan, the organization should capitalize on the momentum
gained during the assessment period. The organization does not have to wait for a completed action plan to
begin process improvement activities. The implementation of certain improvements is an important
motivation factor for all members of the organization.

Collect Data to Document Improvements

Before and during the assessment, it is recommended that quantitative and qualitative data be collected.
It will be used later to measure progress. One could obtain project data such as budgets and schedules, or
measure the degree of customer satisfaction regarding product quality level. Since senior management will
have made investments, it is important to be able to demonstrate that these investments have been
profitable.

Train all Users of the Processes, Methods, and Tools

Once processes are defined, it is essential to train all users. Otherwise, process documents will end up
collecting dust on shelves. It is illusory to think that in addition to their workload, developers will study
new processes by themselves. Training sessions also serve as a message that the organization is moving
ahead and will require that its developers use these practices. During the training sessions, it is necessary
to indicate that errors are bound to occur while using new practices. This will help reduce developers’ level
of stress when using these new practices. It would be wise if a resource person is available to help developers
when they face obstacles while implementing new practices.

Manage the Human Dimension of the Process Improvement Effort

While preparing the technical part of the improvement action plan, the change management elements have
to be planned. This implies, among other things: a knowledge of the organization’s history with regards to
any similar efforts, successful or not; the company’s culture; the motivation factors; the degree of emergency
perceived and communicated by (a) the management, (b) the organization’s vision, and (c) the management’s
real support.

Change in Management Style

In an organization that truly wants to make substantial gains in productivity and quality, a cultural shift
will have to be managed. This requires a special set of people skills. The profile of the ideal process
facilitator is someone with a major in social work and a minor in engineering. The implementation of
processes implies that both management and employees will have to change their behavior. With the
implementation of processes, management will need to change from a “command and control” mode to a
more “hands-on” or participatory mode. This implies that management will need to encourage and listen to
new ideas. This also implies that the decision-making process may have to change from the autocratic
style, e.g. “do what you are told” to a participatory style, e.g. “let us talk about this idea”. Similarly,
employees’ behavior should change from being the technical heroes who can solve any problem, to team
members that can collaborate and listen to others’ ideas.

Management has to accept that in order to increase the error’s detection rate, results from individual
inspections will not be made public, only composite results from many inspections will be made public.
When management accepts this rule, employees should feel safe to identify mistakes in front of their peers
instead of hiding them. The added benefit to correcting errors is that those who participate in an inspection
will learn how to avoid these errors in their own work.

Facilitating behavior changes requires skills that are not taught in technical courses. It is highly
recommended that the people responsible for facilitating change be given appropriate training.

People CMM
Acknowledging the importance of people issues in implementing the model the People CMM was evolved.
It is a process-based model which assumes that workforce practices are standard organizational processes
 Delhi Business Review ? Vol. 3, No. 1, January - June 2002

that can be continuously improved through the same methods that have been used to improve other
business processes. The People CMM is constructed from work force practices and process improvement
techniques that have proven effective through application in many organizations. It is derived from
Humphrey’s original maturity framework and integrates principles from three domains.

? Organization adopt best practices in a targeted domain. The CMM for software engineering processes,
while the People CMM targets workforce management processes.
? Processes in the targeted domain are continuously improved to become more effective and predictable
using Total Quality Management concepts pioneered by Deming, Juran, Crosby, and others.
? The CMM constitutes a unique approach to organizational development that introduces these practices
in stages (maturity levels) to create a succession of changes in the organization’s culture.

Changing an organization’s culture through staged improvements to its operating processes is a unique
approach to organizational development. These cultural changes provide much of the CMM’s power for
implementing lasting improvements and distinguish it from other quality and process improvement
standards.

Conclusion
We have seen that the development and deployment of engineering and management processes entail technical
and management competencies. Five elements are necessary for a successful implementation of organizational
changes:

? Management sets a direction and process objectives are linked to business objectives. Without a clear
direction, confusion may mislead people from reaching the desired change.
? People are trained to perform new tasks. Without the proper training, anxiety among the organization’s
staff is likely to slow down the occurrence of change.
? Incentives are provided to facilitate the adoption of changes.
? Resources are estimated and provided. Otherwise, frustration may put an end to the organization’s
willingness to change.
? An action plan is developed and implemented to avoid false starts.

These years of process improvement activities have demonstrated that constant attention to the people issues
is critical to the success of technological changes. Managing those people issues as risk items and to track them
throughout the improvement effort is very important.

Finally, as stated by J. Pfeffer in his book The Human Equation, “It is almost impossible to earn above-normal,
exceptional economic returns by doing what everyone else is doing ... it is also impossible to achieve some
lasting competitive advantage simply by making purchases in the open market — something that anyone can
do.” (Scholtes, 1996)

References
Alexander, M. (1991) “The Encyclopedia of Team-Development Activities”, edited by J. William Pfeiffer, University Associates,
San Diego, Calif.
EIA 731, (1998) Electronic Industry Association, Systems Engineering Capability, EIA Standard EIA/IS 731 Part 1: Model.
Kitson, D.H. and Masters, S. (1992) “An Analysis of SEI software process Assessment Results: 1987-1991”, Software Engineering
Institute, CMU/SEI-92-TR-24, July.
Laporte, C., Papiccio, N. (1997) “Development and Integration of Engineering Processes at Oerlikon Aerospace”, Proceedings
of the Seventh International Symposium of the International Council on Systems Engineering, August 3-7, Los Angeles, Calif.
Paulk, M. et al (1993) Capability Maturity Model for Software, Software Engineering Institute, SEI/CMU-93-TR-24.
Pfeffer, J. (1998) “The Human Equation: Building Profits by Putting People First”, Harvard Business School Press.
Gita A. Kumta & Mitul D. Shah

Popick, P.R., S.A. Shear (1996) “Ten Lessons Learned from Implementing Integrated Product Teams”, Proceedings, International
Council on Systems Engineering 6th Annual International Symposium, Boston, July 7-11.
Scholtes, P. (1996) “The Team Handbook”, Joiner Associates Inc.

Bibliography
A Guide to the Project Management Body of Knowledge, (1996). Project Management Institute.
Block, P. (1981) “Flawless Consulting”, Pfeiffer & Co.
Bridges, W. (1991) “Managing Transitions”, Addison Wesley.
Capability Maturity Model –TR 25.
Humphrey, W. (1989) “Managing the software Process”, Addison-Wesley.
Jalote, Pankaj (2000) “CMM in Practice”, Addison Wesley.
Laporte, C., A. Guay, J. Tousignant (1998) “The Application of a Systems Engineering Process to the Re- Engineering of an Air
Defense System”, Proceedings of the 8th International Symposium of the International Council on Systems Engineering, July
26-30, Vancouver, Canada.
Pressman, Roger. S. (2001) “Software Engineering – A Practitioner’s Approach”, McGraw Hill.