PONTIFICIA UNIVERSIDAD CATOLICA DE CHILE

ESCUELA DE INGENIERIA

FROM SW-CMM MATURITY LEVEL 2

TO MATURITY LEVEL 5 IN TWO AND
A HALF YEARS: A PROJECT-
CENTERED APPROACH USING A
CENTRALIZED TOOL

ÁLVARO RODRIGO VILLALÓN INOSTROZA

Memoria para optar al título de

Ingeniero Civil de Industrias, Diploma en Ingeniería de
Computación

Profesor Supervisor:
YADRAN ETEROVIC S.

Santiago de Chile, Agosto 2007

PONTIFICIA UNIVERSIDAD CATOLICA DE CHILE
ESCUELA DE INGENIERIA
DEPARTAMENTO DE CIENCIA DE LA COMPUTACION

FROM SW-CMM MATURITY LEVEL 2

TO MATURITY LEVEL 5 IN TWO AND
A HALF YEARS: A PROJECT-
CENTERED APPROACH USING A
CENTRALIZED TOOL

ÁLVARO RODRIGO VILLALÓN INOSTROZA

Memoria presentada a la Comisión integrada por los profesores:

YADRAN ETEROVIC S.

ROSA ALARCÓN C.

FELIPE GUERRERO V.

Para completar las exigencias del título de

Ingeniero Civil de Industrias, Diploma en Ingeniería de
Computación
Santiago de Chile, Agosto 2007
To my parents, Lorenzo and Carmen.
It would have been impossible to get
here without their support and love.

ii
 ACKNOWLEDGMENT

My thanks goes to all the people at Link, specially the core Project
Management Tool development team –Rodrigo Mansilla, Patricio Pardo, César
Rodríguez and Patricio Valdés– which I was proud to lead.

Also, to Gustavo Arancibia and Carlos Fuenzalida; their constant support

and commitment to process improvement was fundamental for having a history to
tell. To Felipe Guerrero, for showing me that process improvement was real beyond
academics.

Likewise, I would like to thank Yadran Eterovic, for taking me as his

student, and for helping me in processing all the ideas and concepts, so an
understandable work was possible to make.

Finally, I would like to thank my present-time boss, for letting me spend

several hours completing this work at office.

iii
 TABLE OF CONTENTS
Pág.

DEDICATION............................................................................................................. ii

ACKNOWLEDGMENT ............................................................................................ iii

LIST OF TABLES...................................................................................................... vi

LIST OF FIGURES ................................................................................................... vii

ABSTRACT.............................................................................................................. viii

I. PREFACE...............................................................................................................1

II. MODELS FOR PROCESS IMPROVEMENT.....................................................3

2.1 The Capability Maturity Model for Software (SW-CMM) ........................3
2.1.1 Why SW-CMM? ..............................................................................6
2.2 The IDEAL model for software process improvement...............................7
2.3 The CBA-IPI method for assessments........................................................9

III. IMPLEMENTING SW-CMM IN SMALL COMPANIES ...............................12

3.1 Link’s background ....................................................................................15

IV. A PROJECT-CENTERED APPROACH TO SPI USING A

CENTRALIZED TOOL....................................................................................17
4.1 Approaching all activities as projects .......................................................17
4.2 The project management tool....................................................................18
4.2.1 Control Panel ..................................................................................20

V. ACHIEVING MATURITY LEVEL 3................................................................22

5.1 The strategy...............................................................................................22
5.2 Implementing Peer-Reviews.....................................................................23
5.3 Effort costs and duration...........................................................................24

VI. ACHIEVING MATURITY LEVEL 5 ..............................................................26

 6.1 How can a small company achieve level 5 in fourteen months? ..............29
6.2 Implementing levels 4 and 5 KPAs. .........................................................30

VII. CONCLUSIONS ...............................................................................................33

REFERENCES ...........................................................................................................36

A P P E N D I X E S ...................................................................................................38

APPENDIX A: PEER REVIEWS AT LINK .............................................................39

A.1 Peer Reviews Policy .................................................................................39
A.2 General Aspects ........................................................................................39
A.3 Roles .........................................................................................................40
A.4 Inputs.........................................................................................................40
A.5 Activities ...................................................................................................41
A.6 Related Processes......................................................................................43
A.7 Outputs......................................................................................................43
A.8 Revisions...................................................................................................43
A.9 Metrics ......................................................................................................44

APPENDIX B: GUERRERO’S SPI CRITICAL SUCCESS FACTORS ..................45

B.1 Business factors ........................................................................................45
B.2 Cultural factors..........................................................................................45
B.3 External factors .........................................................................................46
B.4 Internal factors ..........................................................................................47
B.5 SPI Project factors.....................................................................................47
B.6 Technical factors .......................................................................................48
 LIST OF TABLES
Pág.

Table 3.1 : SPI’s success factors categorization .........................................................14

Table 6.1: Costs comparison.......................................................................................29

vi
 LIST OF FIGURES
Pág.

Figure 2.1: SW-CMM maturity level structure ............................................................4

Figure 2.2: The SW-CMM and their KPAs ..................................................................5

Figure 2.3: Number of SW-CMM appraisals reported to the SEI by year ...................6

Figure 2.4: The IDEAL cycle .......................................................................................8

Figure 2.5: CBA-IPI pre-onsite activities ...................................................................10

Figure 2.6: CBA-IPI on-site activities ........................................................................11

Figure 2.7: Number of assessment days on-site .........................................................11

Figure 3.1: Appraised organizations grouped by its size............................................12

Figure 3.2: Link’s organizational chart.......................................................................15

Figure 4.1: The requirements workflow .....................................................................19

Figure 4.2: The control panel......................................................................................20

Figure 4.3: Task reporting ..........................................................................................21

Figure 5.1: Link’s time for moving from level 2 to level 3 ........................................25

Figure 6.1: SW-CMM assessments distribution .........................................................27

Figure 6.2: Link’s time for moving from level 3 to level 5 ........................................27

Figure 6.3: SEI’s statistics on time to move up ..........................................................28

vii
 ABSTRACT

This work explains how a 35-people organizational unit was able to

achieve the Capability Maturity Model for Software (SW-CMM) level five in record
time, how it is possible to implement process improvement practices with a relatively
small budget in a small setting, and how this new way of doing things makes a real
difference, specially in a country like Chile, with very little tradition in using
standards.

We focus on the strategy guiding that effort, in how to approach both the
SW-CMM Key Practices and the regular activities in a software development
company, and also the importance of a centralized requirements/project management
tool for achieve such goal.

Likewise, it’s relevant to take under consideration the distinctive factors

for succeeding in the software process improvement effort that are not commonly
known in the software process community or described in other papers or articles in
the available literature.

These factors are, in first place, taking the upper level Key Process Areas
(KPA) as projects, and making a project-centered approach to every activity
conducted by the company. In second place and to support that, is the use of a
centralized tool, which makes easier for the project manager to manage the project,
while allowing senior management to feel in control of every undergoing project.

viii
 1

I. PREFACE

When I first joined Link as a Java programmer, I found some sort of

extraterrestrial people, talking about SQA, SCM, peer reviews and a lot of other stuff
that surely I had heard about in college, but I thought only applicable at NASA or
Microsoft/Oracle size companies.

Okay, maybe SQA or SCM were not that strange to me, but “peer
reviews”? Well, really the most amazing thing I saw was having a full project
management tool in place, that allows clients to place their requirements and then
follow requirements’ complete life cycle, including their approval by their own
bosses, the project creation and management, testing, and finally –only by client–
requirement closing; that was really something.

A few months before, the company had been assessed and become SW-
CMM maturity level 2, and by the time of my arrival, they were working to achieve
SW-CMM maturity level 3 using the IDEAL model.

As a new employee, part of my duties at Link were to understand and use

Link’s process in my everyday developer tasks, so in a short time, I had to become
familiar with this SW-CMM thing. Then I began to study the previous process
improvement effort and observed the new one in progress. In time, I became a
Software Engineering Process Group (SEPG) member and also the project manager
of the continuous development of the project management tool.

Today, two and a half years from then, when a new programmer arrives
at Link, he or she possibly thinks I am an extraterrestrial, talking about SEPG, CPI,
SPI and causal analysis.

This document explains how a 35-people organizational unit was able to

achieve the SW-CMM maturity level 5 in record time, how it is possible to
implement process improvement practices with a relatively small budget, and how
this new way of doing things makes a real difference, specially in a country like
Chile, with very little tradition in using standards.
 2

In chapter 2, general context is delivered by introducing two

improvement models and an assessment method. A brief look at the Capability
Maturity Model for Software, the IDEAL model for process improvement and the
CBA-IPI method for assessments are given.

Chapter 3 shows the critical success factors for implementing process

improvement on small companies and introduces Link, the company being studied.
For establishing a success factor’s categorization, a cross-reference between three
papers is presented. Together with Link’s description, a brief reference to the SW-
CMM maturity level 2 assessment conducted at Link previously to this work is
presented.

In chapter 4, the main results are presented. By using a project-centered

approach for planning Link’s daily activities, the visibility and commitment
improves strongly. To support all that, it’s necessary to have a centralized tool,
which in Link’s case helped the process institutionalization notably.

That tool continuous use, enabled better control over the projects, and
availability of real-time online project's performance data. Having an in-house
developed software that smoothly maps with the SW-CMM model, were
fundamental on Link’s software process improvement success.

Chapter 5 is about the level 3 assessments, the strategy followed by Link

to achieve that level and the costs associated to such effort. Also in that chapter, a
SW-CMM key practice is introduced by showing an example on how that KPA was
implemented at Link.

Chapter 6 is about getting to level 5, which also includes level 4

achievement. The chapter describes how was possible to get to that level in a very
short period, and how the level 5 KPAs where addressed, by creating strategic
projects for those practices management.

Finally in Chapter 7, conclusions are presented. By realizing that chapter

3 critical success factors could be founded in Link’s case, two approaches for easily
implementing those factors were defined. They are the ones described on chapter 4.
 3

II. MODELS FOR PROCESS IMPROVEMENT

2.1 The Capability Maturity Model for Software (SW-CMM)

CMM is a capability maturity model, developed by the Software

Engineering Institute at Carnegie Mellon University. In particular, the CMM for
software (SW-CMM) proposes five maturity levels for a software development
organizational unit, where each maturity level builds incrementally on the preceding
ones.

Basically, the model says that the software developed in a company

whose processes are under control (mature), will probably be a better product than
the software produced by a company living in chaos (immature).

The model proposes five hierarchical maturity levels, where each upper
level supposes that its lower levels are completed and institutionalized along the
company.

Each maturity level (indication of process capability) contains Key

Process Areas (goals to be achieved) organized by Common Features (that addresing
implementation or institutionalization) containing Key Practices (that describing
infrastructure or activities).
 4

Figure 2.1: SW-CMM maturity level structure.

The five maturity levels are the following:

Initial (level 1), where no formal process for software development is

established. There is no planning at all, and the project’s success is usually based
commonly on personal abilities. The project’s outcome is unpredictable.

Repeatable (level 2), where basic project management is used to track

cost and schedule, and also practices such as software configuration management and
subcontract management are implemented.

Defined (level 3), where a more robust process is defined. There are
practices in place about training, group coordination, detailed engineering
techniques, and more sophisticated metrics and project management.
 5

Quantitatively Managed (level 4), where metrics are systematically

used to manage projects, using process and product quality indicators. These metrics
are used to undertake the project risks and the whole project portfolio management.

Optimizing (level 5), where the whole organization is devoted to

continuous improvement of the process. Research and development are managed and
causal analysis is conducted for improving project after project.

Figure 2.2 shows a SW-CMM graphical representation of SW-CMM’s

levels and their key process areas:

Figure 2.2: The SW-CMM and their KPAs

Several sources describe this model in greater detail. If you want to

scrutinize into SW-CMM and all of its practices, please read the official guide
[Paul95], or, if you just want to look out about this model, please refer to [Cole05].
 6

2.1.1 Why SW-CMM?

Today, the SEI has replaced CMM with CMMI, the model’s natural
evolution after almost 20 years of use and feedback. The SW-CMM model was
supported by the SEI until December 2005; nevertheless, the success factors and the
experience on continuous improvement based on CMM are still valid for CMMI.

Until December 2005, 3,952 SW-CMM appraisals were conducted in

3,049 organizations, based on 16,500 development projects [Carn06]. If you look at
Figure 2.2, there is an ascending curve until 2003, where CMMI took off and slowly,
the companies are moving to that model.

Between April 2002 and December 2006, 1,946 CMMI appraisals were
conducted (in 1,712 organizations) [Carn07], so we can say that SPI initiatives are
becoming more and more popular both in the United States and the rest of the world.
Two thirds of the appraisals were conducted outside the United States.

Figure 2.3: Number of SW-CMM appraisals reported to the SEI by year.

 7

2.2 The IDEAL model for software process improvement

SW-CMM is a capability maturity model. It has levels of maturity, goals

and key practices to achieve those levels. But SW-CMM doesn’t provide us with a
strategy for continuous improvement. Compared to a car race, SW-CMM shows us
the end of the road, the race regulations and some advice, but doesn’t show us
different car models, driving techniques, highways or street directions.

IDEAL is a model for software process improvement (SPI), also

developed by Carnegie Mellon University’s SEI. It provides a strategic path for
doing continuous improvement, complementing SW-CMM. IDEAL consists in
regular improvement cycles: an initial stage and four phases in every cycle. The
length of time necessary for each cycle completion depends on the organization, the
infrastructure and the resources assigned to the SPI initiative.

According to the SEI, IDEAL supports all the phases required for
performing SPI, and when you complete the cycle, immediately a new one starts, and
this is repeated over and over. The phases are as follows:

- Initiating. SPI starts. it is planned (at least its next two

phases), and roles are defined and initial resources are
assigned

- Diagnosing. The current status is established, creating an

organization’s baseline.

- Establishing. The main strategy for conducting the

improvement is defined. Also, goals are quantitatively
defined, and the action plan is developed.

- Acting The company creates, pilots and deploys all work

products previously defined.

- Learning. All the information obtained in the previous

phases is placed together and analyzed, to create enough
organized information for the next cycle.
 8

In Figure 2.4, you can visualize the IDEAL model, as a never-ending

wheel.

Figure 2.4: The IDEAL cycle

For further information on the IDEAL model, please read [Mcfe96]

 9

2.3 The CBA-IPI method for assessments

The CMM Based Appraisal for Internal Process Improvement (CBA-IPI)

is a “diagnostic method tool that enables an organization to gain insight into its
software development capability by identifying strengths and weaknesses of its
current processes, to relate these strengths and weaknesses to the CMM, to prioritize
software improvement plans, and to focus on software improvements that are most
beneficial, given its current level of maturity and the business goals”. [Duna01]

The CBA-IPI method is composed by several activities which have to be

accomplished to conduct a formal assessment, but basically, it consists on
interviewing company’s personnel, crossing data obtained from those interviews,
looking at the SW-CMM model for goals fulfillment and reporting those activities’
results to both the sponsor and the company.

Formally, the method has three phases:

- Planning. First, it’s necessary to plan and prepare the

assessment and conducting pre-on-site activities as well
(scope definition, training, etc);

- On-Site activities. It’s necessary to conduct the on-site

activities (interviews, information consolidation, etc);

- Report Results. It’s necessary to report results, where the

final findings are presented (informing if there are
improvement opportunities and of course, the maturity level
achieved) and an executive session is conducted.

The assessment is conducted by an assessment team (AT), led by an

authorized (registered at the SEI Appraiser Program) lead assessor, and formed by no
less that 3 and no more than 9 other members. The team as a whole must have the
collective knowledge, skills, and ability to conduct a CBA-IPI assessment, so team
members are selected taking that under consideration. Other participants in the
assessment are the sponsor, usually the senior manager of the company, and the site
coordinator, who is responsible for handling assessment’s logistics.
 10

As it was said previously, there are pre-onsite activities and there are on-
site activities. Figures 2.5 and 2.6 show those activities schematically:

Figure 2.5: CBA-IPI pre-onsite activities.

 11

Figure 2.6: CBA-IPI on-site activities.

Pre-on-site activities last a few months, during which both the lead
assessor and the company start planning the assessment. This isn’t a full time
activity. On-site activities may last anywhere between 2 and 14 days, but they
usually take 5 to 10 days, as it’s shown in Figure 2.7:

Figure 2.7: Number of assessment days on-site.

 12

III. IMPLEMENTING SW-CMM IN SMALL COMPANIES

Available literature state that although this model was created

considering large-scale companies, the number of small size companies being
assessed has been growing over time [Guer04]. Figure 3.1 shows SEI’s data about
appraisal distribution grouped by company’s size.

Figure 3.1: Appraised organizations grouped by its size.

Lumsden [Lumn07] and Strigel [Stri07] present a fine discussion

regarding whether the company’s size matters or not for the case of software
processes. Lumsden argues for the business goals relevance over organization’s size,
while Strigel argues that small company’s processes are far different from a large-
scale multinational’s processes, even when both have similar business goals (e.g.
Wal-Mart versus a corner store).
 13

It’s no accidental that the SEI began supporting initiatives related to

small settings and their model’s implementations. For example, the SEI sponsored a
project called “Improving Processes in Small Settings” (IPSS), which researched
effective practices in that kind of settings.

From IPSS’s work, [Sanf06] lists fifteen critical success factors, focused
on top-risks. Still, the work needs more detail, but presents a preliminary view of
several factors well known in the industry. The factors, in no particular order, are:
Sponsorship, SPI action plan, assessment, deployment, support, consulting, skills,
work practices, reward system, participation, communicate, change management,
learning, values and history.

More detailed studies about critical success factors in all kind of

companies are available [Jalo02, Guer03]. Maybe, the main success factors found in
every SW-CMM implementations are applicable to small companies as well, but the
challenge is to find out which ones are specially related to these companies.

In [Jalo02] there are three factors mentioned as critical; for making the
classification easier, in bold we added a key word to summarize each:

a) Human Resources: Having a dedicated group responsible for the

SPI initiative with some full-time members.

b) Information: Having a suitable delivery system in place for

deploying processes

c) Commitment: Senior management involvement and commitment

In [Guer03], forty-three success factors are listed (see Appendix B for the
full list). Guerrero classifies those factors in six categories, and ranks them according
to their frequency of appearance in the literature available at the time. The two most
frequent factors for each category were identified, defining a twelve-success factor
list, which is presented in Table 3.1.
 14

Table 3.1: SPI’s success factors categorization

Factor Most frequent Second most frequent

Category

Business Focus on improving, not Whole organization focus

on process and involvement

Cultural Management commitment Culture and environment

External Customer support and External consultant

involvement involvement

Internal Practitioners involvement Communications and

maintaining momentum

SPI Project Separated process-product Resources for SPI

responsibilities

Technical Size of improvement Agile design of processes

effort and visibility

While none of these factors refers directly to company’s size, the “Size
of improvement effort and visibility” can be considered related to the company’s
size, in a proportional way. The five most frequently cited factors (in order) are:

a) Size of improvement effort and visibility.

b) Management commitment.

c) Practitioner’s commitment.

d) Focus on improving, not on process.

e) Culture and environment.

Now, crossing reference among the three sources [Guer03], [Jalo02], and
[Sanf06], you could say that the most critical success factors in SPI initiatives are:
 15

a) Ensure senior management commitment.

b) Involve all the practitioners.

c) Communicate the SPI among the whole organization.

This work will explore these factors in the context of Link’s case, but
mainly we’ll try to discover if there are others particular to Link’s case.

3.1 Link’s background

Link is an IT company created inside of AD Retail, a Chilean retail

company with over 170 stores in the country, selling electronics and home-related
products through the “Din” and “ABC” brands. Link’s purpose is to serve AD Retail
as an IT department and, in a lesser grade, to develop software for outside clients.

Link’s organizational structure includes senior management, a Software

Projects area, a Technology area, and four functional areas dedicated to specific
applications managed by Link. The Software Projects area –the one this work is
focused on– is led by a Software Project Director, a five-person quality area
(including testing, SCM and SQA), six Project Managers, and a group of twenty-
three analysts and programmers for a total count of 35 people.

Link's Organizational Structure

Senior Management

Technology Software Projects Functional Areas

SEPG

Project Managers Quality Department

Analysts and Developers SQA SCM Testing

Figure 3.2: Link’s organizational chart

 16

Link obtained the SW-CMM maturity level 5 approximately four years

after the SPI begun. This was achieved through several process improvement
initiatives, and the continuous development of a specific centralized tool, which
supports Link’s software development process.

The rest of this document is mainly related to the efforts for achieving
maturity levels 3, 4 and 5. The path from level 1 to level 2 is described in [Guer04],
which served as a foundational stone for the subsequent developments.

Two objective benefits identified at the time, which have lasted over the
years and served as a key factor for keeping sponsorship are the following. First, the
mean response time to requirements remained close to the committed time (once a
requirement is approved by the client’s boss, Link has 48 hours to provide rough cost
and effort estimates), giving Link an organizational credibility in this matter.
Possibly, some work still needs to be done in approval response time, but for the
time of the present work, this approval served as an effective filter for avoiding non-
software requirements input. Second, the rework rate is approximately 5%, a figure
frequently used for getting funds for process improvement or even for Link’s sales
support.
 17

IV. A PROJECT-CENTERED APPROACH TO SPI USING A

CENTRALIZED TOOL

4.1 Approaching all activities as projects

At Link, every single task is conducted inside a project. That includes

work-specific tasks, holydays, special permissions, days off, training, etc. By doing
this, Link maintains an overall view over its current capability all the time,
leveraging the timely resource assignment. Link’s projects are divided in three types:
Software Development Projects, Administrative Projects and Strategic Projects.

Link's main business is software development; therefore, almost every

project managed by Link is a software development project. Link's development
projects are divided in four types: Projects, Maintenances, Critical Projects, and
Critical Maintenances. A Maintenance-type project is a project that requires less
than 40 man-hour; the "Critical" adjective is added to a project when the requirement
that triggered it demands immediate attention.

Link's development projects cover all requirements by considering

project's size and/or criticality, affecting resource assignment and project's
documentation. For critical projects and critical maintenances, documentation is
minimal but resource availability is given top priority. The criticality of a
project/maintenance is determined by the Software Projects Director, who enters a
password into the system to allow the corresponding Project Manager to label the
project as "critical", releasing some constraints.

Administrative projects involve vacations, days off, and tasks related to

any support activity, such as training, seminars, keynotes, etc.

There are three strategic projects running continuously: The process

improvement project, which has a full time project manager, the causal analysis and
the technology research projects, which has a part time project manager each. The
SW-CMM practices for process improvement, causal analysis and technology
research are covered by these strategic projects, and the Software Project’s Director
is this projects’ client.
 18

By conducting these activities as projects, they are subject to the

quantitative metrics defined at level 4 and the organizational control panel
supervised by senior management. This also means that process improvement, causal
analysis and technology research are well known processes, in which easily everyone
can be involved.

It is a critical success factor in a small company keeping its employees

committed. Approaching the level 5 KPAs as projects creates this effect, involving
everyone in the company’s commitment for improvement.

4.2 The project management tool

To be able to approach all activities as projects, it was necessary to have

specialized software. The project management tool allows a company to manage
their software requirements and projects through a common tool. It supports several
of the typical activities of the software development process according to one
primary workflow (the requirements life cycle) (See Figure 4.1) and one secondary
workflow (the project life cycle).

Figure 4.1 shows the requirements workflow, where a client can enter
and close a requirement. The workflow allows the different roles to approve o reject
the requirements and the initial estimations. There are several roles that interact with
the tool: the client, the client’s boss, the project manager, the senior manager, the
developers (analysts, programmers, architects, etc), and the software quality staff.
 19

Figure 4.1: The requirements workflow.

When a client enters a requirement into the system, his or her boss has to
approve or reject it. Every time a requirement is approved, the company’s board of
project managers assigns the requirement to one of them; this project manager makes
a fast initial estimate of cost and development time.

Then, the client’s boss decides whether to carry on with that requirement
or not. If the initial estimate is accepted, the project manager creates a project and
begins an initial stage where the analyst work is required. When the analysis is done,
a formal document with the plan is delivered and a presentation of the solution to the
client is conducted.

If the client wants to continue with the project, the project manager
inputs the project plan into the project management tool, scheduling every task
known at the time and estimating a closing date, according to the duration of the
tasks and the availability of resources.

During the project life cycle, there can be some schedule or cost-related
changes, but all of them are negotiated and agreed between the project manager and
the client, changing either the closing date or the project cost.

Finally, when the project ends, it’s only possible to close it when the
client himself has closed the original requirement. If he or she is not happy with the
 20

result, the project remains open and it is the project manager’s job to make things
happen and get the project to a successful end.

The project management tool also has several reporting facilities,

oriented to some of the roles described earlier. You can generate and print the reports
that are oriented to your role or, according to the case, receive a daily and/or monthly
email with reports, including the status of current projects, requirements approved or
waiting for approval, man-hours available, etc.

4.2.1 Control Panel

For the project manager, together with the regular features already
described, there is a control panel, visible every time he or she enters the system. The
control panel shows for each current project three leds, one for each metric used to
control the project status: Cost Performance Index (CPI), Schedule Performance
Index (SPI) and Defect Density (DD). Each led can turn green, yellow or red,
according to whether the metric is under control, not applicable, or out of control
(See Figure 4.2). Next to every led there is a link, which when pressed shows a full
color control chart, indicating the metric’s current and historic values and its upper
and lower limits.

Figure 4.2: The Control Panel.

The daily record of the project team’s work generates these metrics. Each
person involved in the project is assigned to one or more tasks, and specific time
 21

slots to work in each task are scheduled as well. Then, once a day (or once every two
days), he or she must enter into the project management tool the actual number of
hours dedicated to each assigned task.

In this way, the database is filled with all the information required for the
CPI and SPI metrics. By task reporting, the employee enters in one day the number
of hours dedicated to one particular task. He or she can also report any scheduled
task and mark it as finished. (See Figure 4.3)

Figure 4.3: Task reporting.

 22

V. ACHIEVING MATURITY LEVEL 3

After the SW-CMM maturity level 2 assessment, the company became a

“process improvement” fan, primarily because of the high participation level
achieved by all the employees in the first cycle, and also, the training and
institutionalization processes that took place during the whole cycle. Thus, it was
relatively easy to motivate the employees for the implementation of the level 3
practices.

5.1 The strategy

For this iteration, the strategy was first of all to create mini teams that
studied and became “experts” in one particular process area. Each employee was a
member of at least one mini team, keeping in mind the goal of involving everyone in
the SPI initiative. According with the IDEAL model, a diagnosis phase began. In this
phase, each team studied whether each practice of the corresponding Key Process
Area (KPA) was used in the company and which was the level of implementation
and institutionalization, as well as whether each goal was being achieved.

In Link’s approach, the mini teams could meet for at most one hour every
day, so not a single employee was ever required to work for more than an hour a day.
In this way the real trick for the project manager was to schedule and coordinate the
meetings satisfying this constraint, so the management decide to “reserve” one hour
daily for each employee.

The idea behind this strategy was in first place, that this is a small
organization, where individuals are very important so you can’t separate them from
their everyday work. Also, it was a way to test the process generated during the
preparation for the level 2 assessments, using it to generate the project plan and
supervision.

Once the diagnostic was complete, the implementation phase began.

Again each mini team defined what should be done in order to achieve the KPA
goals, generating the Process Improvement Proposals (PIP’s) that were required to be
implemented; after that, each PIP was analyzed and approved or rejected by the
 23

SEPG. This generates new work to be done, such as changes in the project
management tool, new checklists, etc. The mini teams, or the company developers in
the case of the project management tool, developed all that.

Then, once all the changes were implemented, an independent informal

assessment was conducted. As a result, some minor gaps between the KPAs goals
and the software development process were found. After the assessment, we made
the necessary corrections to the software development process or the project
management tool, and continued the training and institutionalization processes.

The next step was obviously the formal CBA-IPI, where no improvement
opportunities were found and where Link achieved level 3. Once the assessment was
completed, the IDEAL’s learning phase began, where we analyzed and discussed the
SPI cycle that was ending and the software development process strengths and
weaknesses, and implemented some minor changes. Then, we were ready to begin a
new iteration.

As an example, the strategy for peer reviews process definition is

presented. Peer Review is a key process area in SW-CMM maturity level 3.

5.2 Implementing Peer-Reviews

There was no peer review experience inside the company, so in this case,
it’s easy to describe the whole process for implementing that practice.

Peer Reviews, refers basically to the process in which other person than
the one who created some work product, but with similar skills, reviews some piece
of code or another product. It’s expected that conducting a fresh review of some
product, in the eyes of an expert, could help find some hidden defects faster than
using testing techniques.

However, this is a extremely expensive practice for reviewing the 100%

of the work products in a software project, so it’s necessary to choose; first, what
kind of products will be reviewed, and second, which ones. Link’s peer review was
implemented taking that under consideration.
 24

A three-people mini team carried the diagnosis. They studied peer

review’s sub practices during four meetings and realize that none of the practices
were institutionalized in the company. By studying the practices, they became Link’s
experts on peer review, and after another four meetings, they proposed some PIP’s to
the SEPG, covering the practices required to fulfill the model’s goals.

In the meantime, SPI’s project manager was organizing the ideas and
keeping the consistence between all the changes proposed by all the mini teams
working in all the practices of the SW-CMM maturity level 3.

Later, the SEPG approved those PIP’s and released a new process (a new
chapter on Link’s methodology), named (of course) Peer Reviews, where all the
activities that a project needs to carry out for doing peer reviews are described.

After that, a training program was developed, so everybody was trained

in this new activity and, in about two months from the diagnosis, 100% of the
projects where conducted using peer reviews.

Appendix A shows the full Link’s peer review process description.

5.3 Effort costs and duration

This SPI initiative took 5,309 man-hour, which at an estimated cost of

USD 12 per hour, means that the project total cost was about USD 65,000 in 15
months, or USD 4,300 monthly.

Furthermore, the industry average time to go from level 2 to level 3 is 20

months, and according to the CBA-IPI findings report, Link is in the fastest 25
percent (See Figure 5.1).
 25

Figure 5.1: Link’s time for moving from level 2 to level 3.

Regarding the cost of the project management tool development, there

were two projects related to the improvement of that software during the 15 months.
The effort involved in the first one was 3,636 man-hour and in the second one was
4,960 man-hour.

The cost of the assessments was about USD 20,000 for both, the informal
and formal approaches. Thus, the total cost for getting from level 2 to level 3 in
fifteen months was about USD 185,000, a figure we think more than affordable for a
small size software development company in a country like Chile, considering that
the main cost (89%) was absorbed by internal employees in their regular labor days.

Even if this cycle looks more expensive than the first one (US$185,000
over US$121,000), it was possible to keep all the time the support of senior
management, whom received monthly updates and reports with the status of the
process improvement project.

The main reason for such support is due to continuous improvement

measure, so senior management were able to continuously gauge the SPI effect
inside the organization.
 26

VI. ACHIEVING MATURITY LEVEL 5

At this point, every single employee was very enthusiast about the SW-
CMM model and was very motivated to continue the process improvement effort. It
can be acknowledged that the continuous involvement of the people and the frequent
delivery of results (the formal assessments) are vital factors to succeed in every
process improvement initiative.

As a result, when the next cycle started, the first question was, “Where
do we go from here?” Obviously, the IDEAL’s diagnosis phase begun, a new SPI
project was created, new mini teams were formed, and so on…

After 14 months of hard work, Link was formally assessed and achieved
the level 5 with the following strengths:

- No improvement opportunities, which means that every goal in every

KPA was achieved and there were no weaknesses in the way each KPA was
interpreted and implemented.

- A solid, committed and happy 35-employees staff, where everyone

usually works eight hours a day.

This is a major achievement in a country like Chile and especially in an

IT environment, where working late and working on weekends are very common
practices.

According to [Carn06], Link is in the 9.8% companies worldwide

assessed at maturity level 5 at that time. This is even more relevant in Link’s case,
because the company was assessed in all of their processes types, including small,
medium and large projects.
 27

Figure 6.1: SW-CMM assessments distribution for all the companies assessed
to September 2005.

The average time for moving from level 3 to level 5 is 38 months, and
the “smallest observed value that is not an outlier” is 18 months, so Link is one of the
fastest companies in the world for moving from level 3 to level 5 (14 months).

Figure 6.2: Link’s time for moving from level 3 to level 5.

 28

Next figure shows all the registered data about the time to move up from
maturity level to the next one. Note that the 38-month for moving from level 3 to 5 is
obtained by adding the medians for moving from level 3 to 4 (25 months) and
moving from level 4 to 5 (13 months).

Figure 6.3: SEI’s statistics on time to move up.

Talking about costs, the SPI project took 4,330 man-hour or USD
52,000. Including the development of the project management tool (USD 22,000),
and both the informal and formal assessments (USD 20,000), the effort’s total cost
was about USD 94,000.

As you can see in Table 6.1, getting from level 3 to 5 was cheaper than
moving from level 2 to level 3, and still cheaper than moving from level 1 to level 2.
 29

That difference was mainly in the project management tool development

item, because in the level 5 effort, the development was primarily associated to the
control panel, and the remainder of the job required, was already done.

Table 6.1: Costs comparison (all costs in US Dollars)

Item Level 1 Level 2 Level 3 Total

to 2 to 3 to 5

SPI Project 50,000 65,000 52,000 167,000

Software 51,000 100,000 22,000 173,000

Development

Assessments 20,000 20,000 20,000 60,000

Total Cost 121,000 185,000 94,000 400,000

Internal / Total 83% 89% 79% 82%

Cost

6.1 How can a small company achieve level 5 in fourteen months?

When Link started its process improvement effort, the project

management tool was already developed. Over time, this tool grew, allowing the
project managers to lead their projects, and granting real clients to write their own
requirements, establishing an approval/denial mechanism for those requirements.

This tool allows the project manager to create projects, manage

associated documentation, assign an approved requirement to a project, create stages,
create tasks and finally assign and schedule every person involved in the project; i.e.,
like any other project management tool.

However, the most relevant feature of the project management tool is a

very simple one: It allows the employees (programmers, designers, testers, etc)
themselves to input their progress for each task, in hours. That is, every day or two,
 30

an employee must enter into the system the number of hours worked in the task
previously assigned to he or she by the project manager.

As it is well known (e.g., the increasing popularity of iterative

incremental development), when you divide a project into short tasks it is easier to
track the project’s status. When we talk about 2-, 4-, or 8-hour tasks, there are only
two possibilities at the time of entering the task progress: it’s done or it’s not,
avoiding developers or even project managers informing something like 15%, 75%
or even worse, 95% or 99%, which is one of the project management’s common
flaws.

The project management tool solves this issue in a very elegant and
simple way. This is a major strength of the tool and of course, one of the most
relevant factors to keep projects under control and eventually to achieve some of the
goals required by SW-CMM.

Once a tool like the project management tool is available, you need to
develop a strategy to make the employees to use it and to report about their work. In
Link’s case, there is a monetary incentive for reporting the number of hours worked
using the project management tool.

In the same direction, by getting the entire project planning and tracking
inside the software, it wasn’t necessary to maintain a lot of documents. Instead, Link
actually used only one main document (and several secondary small documents) for
each project, avoiding a lot of bureaucracy and, among the “each resource reporting
task completion”, give time to the project manager to actually lead the project instead
of spending several hours doing paperwork.

6.2 Implementing levels 4 and 5 KPAs.

Level 4 KPAs are about statistical process control. A maturity level 4

company, after conducting a statistical analysis about their process, should be able to
establish product (the software) and process (the plan and their tracking) indicators
for getting project’s current status in real time, enabling the timely action taking for
preventing out of control situations.
 31

From the time of the project management tool deployment to the time of
the level 5 assessments, around 1,400 projects had been conducted using this tool.
This generated a considerable amount of data that were useful to statistically
determine which metrics should be used.

After studying process statistic control, validating what type of analysis

was right for the data available and, if this was able to use with the earned value
method, three metrics were chosen.

For the Quantitative Process Management KPA, the “Cost Performance

Index” and the “Schedule Performance Index” (CPI and SPI) were chosen. Both
metrics were already available in the project management tool data, because of the
hour’s task assignment and reporting policy.

For the Software Quality Management KPA, the process mini-team

chose the “Defect Density” (DD) rate, which also was available because the testing
people recorded tests results using the same tool.

Because of all that, it was only necessary to develop within the project
management tool a control panel (see chapter 4.2.1), where the project managers and
senior management could see at any time the historic and current values of those
three metrics, and graphically analyze them.

Obviously, some corrections to the software development process where

made, but they were really marginal. It’s right to say that level 4 was already there
and the process mini-team just “discovered” it.

Level 5 KPAs are:

- Process Change Management

- Technology Change Management

- Defect Prevention

For working in these three KPAs, two process mini-teams were formed
(as usual in Link’s strategy, using the IDEAL approach). The first one, studied
 32

“Process Change Management” and “Technology Change Management”, and the

second one, studied “Defect Prevention”. The mini-teams studied each practice and
created a process for each one.

The common factor was that the created processes, defined that the three
KPAs will be satisfied by keeping three strategic projects; each one with its own
particular activities, but projects at last.

Because of the expertise gained in the previous SPI projects, it was

natural to consider the Process Change Management KPA as the new SPI project and
to keep conducting it like it was conducted at that time.

The other two KPAs were also implemented by creating projects derived
from internal requirements (the Software Projects Manager was the client). Both
projects had a part-time project manager, who manages his project according to the
process definition developed by each mini-team.
 33

VII. CONCLUSIONS

The SW-CMM model contains 5 levels, 18 key process areas, 52 goals

and 316 key practices. For each piece of software being developed, it’s necessary to
take all this under consideration. It looks huge, doesn’t it?

Well, it looks even bigger for a 35-employee company, but thinking

about Link’s experience, to work in an ordered way, moving aside some prejudices
like the SW-CMM is all about documents and bureaucracy, it really makes a change.

It’s important to understand that every company can interpret the model
in a way that works for the company. Rather than moving the whole company to a
rigid and bizarre model, you need to write their own software process in the way it
makes sense for itself.

The main strategy followed by Link was to take the IDEAL model and
develop an accordingly methodology, and to use a tool for supporting such
methodology

From this experience some lessons can be pulled out. Some of these
lessons are well known in many software development process implementation
efforts, but some of them are clearly unique. In our opinion, these unique lessons
made the difference for having succeeded and still being successful in the projects
that Link undertakes.

Recalling the three success factors identified at this work’s beginning, we

can visualize all of them in Link’s methodology or particular culture.

First, there is the great vision and support from the top of the
organization (management commitment). Maybe this is the obvious one, but the
secret to maintain that support is basically to manage the process improvement like
any other project.

In particular, the project must include a realistic but aggressive plan and
should follow it as it was “sold” to management. Also, you should be able to show
 34

results at any given time during the project. If you can summarize the spirit under
SW-CMM it is that it allows you to establish and meet compromises.

It is also important to involve the whole company (involve the

practitioners), not just a few “experts” or “gurus” who make decisions and write the
laws in stone. By involving all the employees, it is easier to receive approval by the
final users themselves, and no one can say something like, “I didn’t have the chance
to” or “nobody asked me”. When you try to establish the way people are going to
work, this is invaluable.

For achieving this, it’s of primary importance not to disturb the

employee’s regular tasks. Therefore, the limit of one hour a day for working in the
process improvement project is a significant success factor.

The continuous training and coaching (communicate) were fundamental

in Link’s case. In each IDEAL cycle, there were a great effort in this subject, and
because practitioner’s high involvement and senior management’s commitment, the
continuous improvement were always on the spotlight.

Based on the above, you can realize that the critical success factors
covered by known literature were full accomplished in Link’s case, but looking at the
figures, Link’s time to move from one level to he next one were always in the fastest
group.

As described in section 5.3, the yearly cost of SPI per software engineer
at Link is pretty close to the industry average, so the main difference was the time
spent on each SPI initiative. Each SPI cycle was by far faster that the industry
average, resulting also in a lower final cost. The question now is, “what makes
Link’s case that fast”?

Keeping projects under control, keeping senior management commitment

and involving and communicating the SPI to the practitioners, requires that all the
activities conducted inside Link were able to be measured. It’s important showing
where the organization were before and where is now.
 35

By managing all activities as projects, they were subjects to company’s

metrics and the hour-by-hour results about these projects were visible to the whole
organization.

That allowed a high level of transparency and information availability, so

introducing changes into the development process was easier, and therefore, faster.

To support all that, the project management tool was vital. That tool
avoids a lot of bureaucracy and allows project’s managers to be in control of their
projects at all time, without having to spend several hours writing reports (task
completions, % of advance hour by hour, etc.).

The use of this tool was a critical success factor, as this tool heavily
reduced the bureaucracy and made work really flow.

Because process improvement was managed as a project, another factor

to consider was having one person committed 100% to the task (the coordinator or
SPI’s project manager). This person should become the project facilitator and his or
her mission is to know very well both the model and the peculiarities of the company
where this model is going to be implemented.
 36

REFERENCES

[Paul95] PAULK M., WEBER C., CURTIS B. AND CHRISSIS M. The

Capability Maturity Model: Guidelines for Improving the Software
Process, Addison-Wesley Professional, 1st edition, June 1995

[Mcfe96] McFEELEY, R. IDEAL: A User’s Guide for Software Process

Improvement, Handbook CMU/SEI-96-HB-0001, 1996

[Duna01] DUNAWAY D. and MASTERS S. CMM-Based Appraisal for Internal

Process Improvement (CBA-IPI) Version 1.2 Method Description,
Technical Report CMU/SEI-2001-TR-033, 2001

[Jalo02] JALOTE, P. Lessons learned in Framework-Based Software Process

Improvement, Proceedings of the ninth Asia-Pacific Software
Engineering Conference (APSEC’02), 2002

[Guer03] GUERRERO F., ETEROVIC Y., A Simple Categorization of Critical

Factors for Software Process Improvement, 7th IASTED Intl. Conf. on
Software Engineering and Applications, Marina del Rey, CA, USA, Nov.
3-5, 2003, pp. 681-686

[Guer04] GUERRERO F., ETEROVIC Y., Adopting the SW-CMM in a Small IT

Organization, IEEE Software Magazine, Volume 21 Number 4, 2004,
pp. 29-35

[Cole05] COLEMAN K., LARSEN P. and SHAW M., Software Process

Improvement in Small Organizations: A Case Study, CMM sidebar,
IEEE Software Magazine, Volume 22 Number 6, 2005, pp. 68-75

[Sanf06] SAN FELIU T., GARCIA S. and GRAETTINGER C., Critical Success
Factors (CSF) in SPI Bibliography, Proceedings of the First
International Research Workshop for Process Improvement in Small
Settings, 2006
 37

[Carn06] CARNEGIE MELLON UNIVERSITY, SOFTWARE ENGINEERING

INSTITUTE, Process Maturity Profile, Software CMM 2005 End-Year
Update, March 2006

[Carn07] CARNEGIE MELLON UNIVERSITY, SOFTWARE ENGINEERING

INSTITUTE, Process Maturity Profile, CMM v1.1 SCAMPI v1.1 Class
A Appraisal Results 2006 End-Year Update, March 2007

[Lumn07] LUMNSDEN LARRY, Business Goals Count, Not Organization Size,

IEEE Software Magazine, Volume 24 Number 1, 2007,pp. 54,56

[Stri07] STRIGEL WOLFGANG, In Software Processes, Organization Size

Matters, IEEE Software Magazine, Volume 24 Number 1, 2007, pp.
55,57
 38

APPENDIXES
 39

APPENDIX A: PEER REVIEWS AT LINK

Below, is an example of Link’s methodology chapter; each one has the

same structure, beginning with the organizational policy, general aspects of the
chapter itself, activity’s general description, inputs, outputs, roles and metrics.

In this case, Peer Review is presented.

A.1 Peer Reviews Policy

a) The Project Manager is responsible for leading him project’s peer reviews.

b) Peer Reviews are conducted for defect finding in work products and opportunely
correcting them

c) Peer Reviews doesn’t attempts to measure practitioner’s performance

A.2 General Aspects

A.2.1 General Description

Peer review is an effective mechanism for defect detection in work

product developed for our clients. This chapter defines techniques, procedures,
standards and activities for a project’s peer review at Software Project Department

A.2.2 Goals

a) Work product’s defect identification and removal

b) Work product’s error rate reduction

A.2.3 Definitions

Review: Non-functional checking action, conducted for defect finding.

Defect: Work product’s feature, which is in non-compliance with

requirements or standards.
 40

Error: A defect, found by a client.

Peer: Individual, which role is considered equivalent with some other

individual.

A.3 Roles

A.3.1 Responsible

Project Manager: The PM is responsible for peer review’s coordination

and should lead peer review’s activities

A.3.2 Other actors

Reviewer: The reviewer is responsible for work product’s actual review.

There is a list of authorized reviewers at section 9.9.4

Reviewed: The reviewed is responsible for work product’s elaboration,

and eventually, for it’s correction.

Quality Assurance Manager: Is responsible for assurance process and

product standards, procedures and rules following.

Software Project Manager: Provides resources for software projects

execution, involving training, equipment, work place, human resource, and etcetera.

A.3.3 Training

Practitioner’s training is conducted according the Organization’s

Training Program.

A.4 Inputs

A.4.1 Work products

a) Matrix: Pre-workability

b) Matrix: Peer Review Report

 41

c) Checklist: Design’s Peer Review

d) Checklist: Code’s Peer Review

e) Rule: Authorized Reviewer List

f) Rule: Products who requires peer review

A.4.2 Infrastructure

a) The minimum infrastructure described in section 1.4.4 for all Links’

personnel.

b) Meetings Room

c) Data Show

d) Proper software for correctly viewing the product been reviewed

e) Project Management System, for registering peer review’s data

A.5 Activities

A.5.1 Peer Review Planning

Responsible: Project Manager

Inputs: Pre-workability Draft

Description: Peer Review plan is completed in the Pre-workability document.

From the moment Pre-workability is approved, those data is
registered into the Project Management System.

Outputs: Updated Pre-workability Draft

 42

A.5.2 Peer Review

Responsible: Project Manager

Inputs: Approved Pre-workability

Peer Review Checklist
Work Product been reviewed

Description: a) Review leader is identified. The project manager (pm)

b) The pm plans the review into the Project Management System
and defines what work products will be reviewed according to
the methodology
c) Review materials are delivered.
d) Reviewer and reviewed are identified
e) Review is conducted using the checklist and recording all
defects and observations
f) An action list for correcting defects are generated
g) The review ends when the pm decides the checklist is
completed and tags the task’s end.
h) Following actions are planned
i) Data obtained is delivered to Quality Assurance Department,
who will demand it for project closing.

Outputs: Fulfilled checklist

Work product reviewed
 43

A.5.3 Defect Correction

Responsible: Reviewed

Inputs: Peer review checklist

Work product to be corrected

Description: The reviewed removes all defects identified during peer review,
which the project manager determines.
The pm must verify that this activity is accomplished.

Outputs: Corrected work product.

A.6 Related Processes

Before conducting peer review, the work product been reviewed must
been finished inside the scope of a project and configured into the Configuration
Management System

A.7 Outputs

a) Reviewed work products

b) Peer review report completed

A.8 Revisions

Software Projects’ Director: The SPD gets a periodical report from the
Project Managers, generated from the Project Management System’s binnacle.

Project Manager: Project planning activities are revised with:

- Project Team

- Stakeholders
 44

It’s important that the project manager is aware of the following factors
during the peer review:

- Peer Review Plan fulfillment

- Complete register of the peer review man-hours in the

Project Management System.

- Effective defect correction

- Peer Review standards and procedures adherence.

Quality Assurance: The QA manager, should review project’s activities

and work products, according to the review procedure described in section 11.5.2
and the section 11.9.2 checklist

A.9 Metrics

A.9.1 Peer Review Effort

Goal This metric establish peer review’s activities status

Unit Hours

Definition The effort is the sum of the hour tagged “RP” in the Project
Management System

Procedure The Project Management System automatically calculates Peer

Review’s effort.

Location Project Management System.

 45

APPENDIX B: GUERRERO’S SPI CRITICAL SUCCESS FACTORS

In this appendix, Guerrero’s [Guer03] full critical success factor list is

presented. The data is grouped by categories and the frequency of occurrence is
showed on each table’s left column.

B.1 Business factors

This category includes the factors affecting the whole organization, like
organization’s size, business goals, mission, etc. Changing these factors involves
changes in the general direction of the organization, which is usually driven by a
strategic plan, dictated for several years. The main managerial level affected by these
factors is senior management, because this level dictates organization’s strategy.

Freq Success Factor

17 Focus on improving, not on process

12 Whole organization focus and involvement

8 Alignment with business goals

4 Organizational structure

3 Application diversity

2 Project size

2 Organization size

1 Number of customers

1 Personnel rotation

B.2 Cultural factors

This category includes the factors inherent to personnel, like educational

level, commitment to work, group view of SPI, etc. Changing these factors may
involve a lot of effort and time to obtain. Cultural factors affect primarily project
 46

teams, as they are the target for SPI. These factors cover all the managerial levels,
because there are cultural issues for each of the levels.

Freq Success Factor

18 Management commitment

17 Culture and environment

12 Training and education

11 Medium management and stakeholder involvement

8 Group focus and buy-in of SPI

6 Climate of change

2 Change agents

1 Assume honesty and competency from personnel

1 Success of Previous Experiences

B.3 External factors

This category includes the factors related to entities external to the

software organization, like customers, stakeholders and consultants. Changing these
factors involves affecting entities over which the software organization may not have
direct influence. These factors affect mainly the senior management level, which has
the appropriate power to deal with external entities.

Freq Success Factor

5 Customer support and involvement

4 External consultant involvement

2 Competitors and market pressure

1 Being a subcontractor
 47

B.4 Internal factors

This category includes the non-technical factors directly manageable by

the process team, like level of involvement of practitioners, channels of
communication, internal marketing, etc. Managing these factors would be the most
time and effort consuming task for the process team. Internal factors affect the whole
software project team: both software project management and software practitioners.

Freq Success Factor

18 Practitioners involvement

9 Communications and maintaining momentum

5 SPI incentives

2 Champions

B.5 SPI Project factors

This category includes factors under direct control of the process team
about the management of the SPI project itself: Number of people involved, time to
devote to the effort, resources, etc. These factors affect the process team—it’s their
responsibility to manage them. The factors included in this category are assigned at
the project management level where decisions affecting the factors will be adopted.

Freq Success Factor

16 Separated process-product responsibilities

11 Resources for SPI

9 Manage SPI as a project

9 Process change expertise

6 Organizational change expertise

4 Define goals and measurements for SPI

 48

B.6 Technical factors

This category includes low-level SPI details like the design and the
deployment of the improvements. These factors are the technical core of a SPI
initiative. These factors affect the process team, because they are the most likely to
manage them, and are assigned at the project management level where decisions
affecting the factors are adopted.

Freq Success Factor

26 Size of improvement effort and visibility

12 Agile Design of Processes

5 Assessment

4 Improve where the process is failing

4 Manage lessons learned

4 Improvement sequence

3 Automation and process tools

2 Process improvement focus vs. product improvement focus

1 Use common sense

1 Focus on new projects

1 Improvement time distribution