ISO/IEC TR 15504-7:1998

Information technology - Software process assessment - Part 7: Guide for use in process improvement

Technologies de l'information — Évaluation des procédés du logiciel — Partie 7: Guide pour l'utilisation dans l'amélioration de processus

General Information

• Status: Withdrawn
• Publication Date: 19-Aug-1998
• Withdrawal Date: 19-Aug-1998
• ICS: 35.080 - Software
• Technical Committee: ISO/IEC JTC 1/SC 7 - Software and systems engineering
• Drafting Committee: ISO/IEC JTC 1/SC 7/WG 10 - Process assessment
• Current Stage: 9599 - Withdrawal of International Standard
• Start Date: 02-Jul-2004
• Completion Date: 30-Oct-2025

Relations

• Revised: ISO/IEC 15504-4:2004 - Information technology - Process assessment - Part 4: Guidance on use for process improvement and process capability determination
• Effective Date: 15-Apr-2008

Standards Content (Sample)

TECHNICAL ISO/IEC
REPORT TR 15504-7
First edition
1998-08-15
Information technology — Software process
assessment —
Part 7:
Guide for use in process improvement
Technologies de l’information — Évaluation des procédés du logiciel —
Partie 7: Guide pour l’utilisation dans l’amélioration de procédé
Reference number
B C
Contents
1 Scope .1
2 Normative reference .1
3 Terms and definitions.2
4 Overview of process improvement .2
4.1 Drivers.2
4.2 Process improvement basics .2
4.3 General principles.2
4.4 Process improvement context.3
5 Guidelines for software process improvement.4
5.1 Examine the organization's needs and business goals.5
5.2 Initiate process improvement .6
5.3 Prepare for and conduct a process assessment .6
5.3.1 Prepare assessment input .6
5.3.2 Conduct a process assessment .8
5.4 Analyse assessment output and derive action plan .8
5.4.1 Identify and prioritize improvement areas.9
5.4.2 Define specific improvement goals and set targets.11
5.4.3 Derive action plan .11
5.5 Implement improvements .12
5.5.1 Operational approach to implementation.12
5.5.2 Detailed implementation planning .12
5.5.3 Implementing improvement actions .13
5.5.4 Monitoring the process improvement project.13
© ISO/IEC 1998
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or
utilized in any form or by any means, electronic or mechanical, including photocopying and micro-
film, without permission in writing from the publisher.
ISO/IEC Copyright Office • Case postale 56 • CH-1211 Genève 20 • Switzerland
Printed in Switzerland
ii
© ISO/IEC
5.6 Confirm improvements. 14
5.6.1 Improvement targets . 14
5.6.2 Organizational culture. 14
5.6.3 Re-evaluate risks . 14
5.6.4 Re-evaluate cost-benefit . 14
5.7 Sustain improvement gains. 14
5.8 Monitor performance. 15
5.8.1 Monitoring performance of the software process. 15
5.8.2 Reviewing the process improvement programme . 15
6 Cultural issues . 16
6.1 Management responsibility and leadership .16
6.2 Values, attitudes and behaviour. 16
6.3 Process improvement goals and motivation . 17
6.4 Communication and teamwork . 17
6.5 Recognition . 17
6.6 Education and training. 17
7 Management . 18
7.1 Organizing for process improvement. 18
7.1.1 Senior management. 18
7.1.2 Process improvement programme management . 19
7.1.3 Process improvement project management . 19
7.1.4 Responsibilities of the process owners . 20
7.1.5 Role of the organizational unit . 20
7.2 Planning for process improvement. 20
7.2.1 Business plan. 21
7.2.2 Process improvement programme plan . 21
7.2.3 Process improvement project plan. 22
7.3 Measuring process improvement. 22
7.3.1 Process attribute and capability level ratings. 22
7.3.2 Effectiveness measures . 23
iii
© ISO/IEC
7.3.3 How to use process attribute ratings and effectiveness measures .23
7.3.4 Framework for measuring processes .23
7.4 Reviewing process improvement activities .25
Annex A (informative) Application of the process measurement framework .27
Annex B (informative) Application of the improvement methodology .28
Annex C (informative) Mapping to ISO 9004-4.35
Bibliography.36
iv
© ISO/IEC
Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical Commission)
form the specialized system for worldwide standardization. National bodies that are members of ISO or IEC
participate in the development of International Standards through technical committees established by the
respective organization to deal with particular fields of technical activity. ISO and IEC technical committees
collaborate in fields of mutual interest. Other international organizations, governmental and non-governmental, in
liaison with ISO and IEC, also take part in the work.
In the field of information technology, ISO and IEC have established a joint technical committee, ISO/IEC JTC 1.
The main task of technical committees is to prepare International Standards, but in exceptional circumstances a
technical committee may propose the publication of a Technical Report of one of the following types:
— type 1, when the required support cannot be obtained for the publication of an International Standard, despite
repeated efforts;
— type 2, when the subject is still under technical development or where for any other reason there is the future
but not immediate possibility of an agreement on an International Standard;
— type 3, when a technical committee has collected data of a different kind from that which is normally published
as an International Standard (“state of the art”, for example).
Technical Reports of types 1 and 2 are subject to review within three years of publication, to decide whether they
can be transformed into International Standards. Technical Reports of type 3 do not necessarily have to be
reviewed until the data they provide are considered to be no longer valid or useful.
ISO/IEC TR 15504-7, which is a Technical Report of type 2, was prepared by Joint Technical Committee ISO/IEC
JTC 1, Information technology, Subcommittee SC 7, Software engineering.
ISO/IEC TR 15504 consists of the following parts, under the general title Information technology — Software
process assessment :
 Part 1: Concepts and introductory guide
 Part 2: A reference model for processes and process capability
 Part 3: Performing an assessment

Part 4: Guide to performing assessments
 Part 5: An assessment model and indicator guidance
 Part 6: Guide to competency of assessors
 Part 7: Guide for use in process improvement
 Part 8: Guide for use in determining supplier process capability
 Part 9: Vocabulary
Annexes A to C of this part of ISO/IEC TR 15504 are for information only.
v
© ISO/IEC
Introduction
The needs and business goals of an organization are often centred around achieving enhanced customer
satisfaction and greater competitiveness. For organizations with a dependence on software, these key
management concerns become drivers that initiate software process improvement throughout the organization with
goals of higher software quality, lower development and maintenance costs, shorter time to market, and increased
predictability and controllability of software products and processes.
Software process improvement is best considered as a continuous process, where an organization moves
continually around an improvement cycle. Within this cycle improvement is accomplished in a series of steps or
specific improvement actions such as introducing new or changed practices into software processes or removing
old ones. An important step in the improvement cycle, however, is the execution of some form of data gathering to
establish the initial state, and subsequently to confirm the improvements.
This part of ISO/IEC TR 15504 provides guidance on using software process assessment as the primary means of
understanding the current state of an organization’s software processes, and on using the results of the assessment
to formulate and prioritize improvement plans. This guidance is embodied within a general framework for the use of
process metrics in software process improvement.
The improvement framework is built on the framework for quality improvement embodied in ISO 9004-4.
This part of ISO/IEC TR 15504 is primarily aimed at the management of an organization considering or undertaking
a software process improvement programme, possibly as a result of a process capability determination; members
of improvement teams, particularly leaders and facilitators; software engineers; and external consultants helping
organizations to undertake software process improvement.
This process improvement guide addresses the following topics:
an overview of process improvement – the factors which drive software process improvement and general

principles which underpin it;
 a methodology for process improvement – an eight step model for improving software processes within a
continuous improvement cycle;
 cultural issues – aspects of organizational culture that are critical for successful process improvement;
 management – software process improvement from a management perspective including an overall framework
for process measurement.
Annexes provide supplementary information including examples of the use of the process measurement framework;
an illustrative case study of application of this part of ISO/IEC TR 15504; and mappings between the steps in the
model described in this part of ISO/IEC TR 15504 and ISO 9004-4.
vi
TECHNICAL REPORT  © ISO/IEC ISO/IEC TR 15504-7:1998(E)
Information technology — Software process assessment —
Part 7:
Guide for use in process improvement
1 Scope
This part of ISO/IEC TR 15504 provides guidance on using software process assessment as part of a framework
and method for performing software process improvement in a continuous manner. The guidance covers:
a) invoking a software process assessment;
b) using the results of a software process assessment;
c) measuring software process effectiveness and improvement effectiveness;
d) identifying improvement actions aligned to business goals;
e) using a process model compatible with the reference model defined in ISO/IEC TR 15504-2 as a framework for
improvement;
f) issues related to organisational culture in the context of software process improvement;
g) dealing with management issues for software process improvement.
The guidance provided does not presume specific organizational structures, management philosophies, software
life cycle models or software development methods. The concepts and principles are appropriate for the full range
of different business needs, application domains and sizes of organization, so that they may be used by all types of
software organizations to guide their improvement activities.
An organization may select all or any subset of the software processes from the reference model, for assessment
and improvement in the light of its particular circumstances and needs. The guidance provided can also be used
with other process models.
The guidance provides a framework for implementing improvements in a continuous manner. However, there is no
reason why the organization could not employ the guidance for a single cycle of improvement activity.
2 Normative reference
The following normative documents contain provisions which, through reference in this text, constitute provisions of
this part of ISO/IEC TR 15504. For dated references, subsequent amendments to, or revisions of, any of these
publications do not apply. However, parties to agreements based on this part of ISO/IEC TR 15504 are encouraged
to investigate the possibility of applying the most recent editions of the normative documents indicated below. For
undated references, the latest edition of the normative document referred to applies. Members of ISO and IEC
maintain registers of currently valid International Standards.
ISO/IEC TR 15504-9:1998, Information technology — Software process assessment — Part 9: Vocabulary.
© ISO/IEC
3 Terms and definitions
For the purposes of this part of ISO/IEC TR 15504, the terms and definitions given in ISO/IEC TR 15504-9 apply.
4 Overview of process improvement
4.1 Drivers
The needs and business goals of an organization are often centred around achieving enhanced customer
satisfaction, greater competitiveness and improved business value associated with delivery of software or
information systems. For organizations with a dependence on software, these key management concerns become
drivers that initiate software process improvement throughout the organization with goals of higher software quality,
lower development and maintenance costs, shorter time to market, and increased predictability and controllability of
software products and processes.
4.2 Process improvement basics
Improvements to the software process may start at any level in the organization. However, senior management
leadership is required to launch and sustain a change effort and to provide continuing resources and impetus,
although ultimately, everyone in the organization is involved.
In summary:
 software process improvement demands investment, planning, dedicated people, management time and capital
investment;
 software process improvement is a team effort;
 effective change requires an understanding of the current process and clear goals for improvement;
 software process improvement is continuous – it involves continual learning and evolution;
 software process changes will not be sustained without conscious effort and periodic reinforcement.
4.3 General principles
The needs and business goals of the organization determine the software process improvement goals that help to
identify improvement actions and their priorities. Software process improvement is accomplished in a series of
steps or specific improvement actions such as introducing new or changed practices into software processes or
removing old ones. A process model may be used to identify practices to be included to improve the capability of
each process. Achievement of process improvement goals should be measured quantitatively.
The general principles of software process improvement are:
 software process improvement is based on process assessment results and process effectiveness measures;
 software process assessment produces a current process capability profile which may be compared with a
target profile based on the organization's needs and business goals;
 process effectiveness measures help identify and prioritize improvement actions that support organizations in
meeting their needs and business goals, and in achieving software process goals;
 software process improvement is a continuous process. Improvement goals identified and agreed within the
organization are realized through a process improvement programme that continues through multiple cycles of
planning, implementing and monitoring activities;
© ISO/IEC
 improvement actions identified within a process improvement programme are implemented as process
improvement projects;
 metrics are used for monitoring the improvement process in order to indicate progress and to make necessary
adjustments;
 software process assessment may be repeated in order to confirm that the improvements have been achieved;
 mitigation of risk is a component of process improvement and should be addressed from two viewpoints:
 the risk inherent in the current situation;
 the risk of failure in the improvement initiative.
Software process improvement plans and records may be used to support process capability determination, when
the proposed process capability needed to meet a contractual requirement exceeds the currently assessed profile
(see ISO/IEC TR 15504-8).
4.4 Process improvement context
The context for software process improvement and its major interfaces are shown in figure 1. The interfaces are as
follows:
 the organization's needs and business goals which are main stimuli for process improvement;
 industry norms and benchmarks providing reference information for improvement planning;
 improvements in the organizational unit's (OU's) software processes as a result.
Software process Improvement plans and records
improvement request
Improvements in organisationzal
Organization’s needs unit’s software process
and business goals
Target capability profiles
from process capability
determination
Industry norms
and benchmarks
PROCESS
IMPROVEMENT
Assessment output
• process profile
Process assessment request
• assessment record
Practices from compatible
process model
Figure 1 — Process improvement context
© ISO/IEC
Process improvement uses other components of ISO/IEC TR 15504 as follows:
 process assessment (as described in ISO/IEC TR 15504-3 and ISO/IEC TR 15504-4) is performed to establish
the current capability;
 the assessment results consist of process profiles and all the contextual information held in the assessment
record;
 the process model compatible with the reference model in ISO/IEC TR 15504-2 is used as a framework to
define processes to be improved, set priorities and identify improvement actions;
 existing improvement initiatives may need to be adjusted to support a new target capability resulting from a
process capability determination (see ISO/IEC TR 15504-8);
 improvement plans and records may assist in establishing customer confidence during process capability
determination (see ISO/IEC TR 15504-8).
5 Guidelines for software process improvement
When an organization is well motivated and managed for software process improvement (see clauses 6 and 7), it
undertakes and implements a number of process improvement activities. Software process improvement benefits
accumulate permanently when an organization pursues process improvement activities in a consistent and
disciplined series of steps based on data collection and analysis.
Figure 2 illustrates the steps for continuous software process improvement using the components of
ISO/IEC TR 15504.
Improvements in
organisational unit’s
software process
1.
Examine
Organisation’s needs
organisation’s
needs
Software process
improvement request
Validated
Institutionalised
improvement
7.
improvements
results
Sustain
improvement
Identified
scope and
gains
priorities
8. 6.
Monitor Confirm
performance improvements
Re-assessment
request
Improvement
initiation
Implemented
improvements
2.
Analyzed
Initiate process
re-assessment
results
improvement
5.
Preliminary process
Implement
improvement
4.
improvements
programme
Approved
Analyze results
plan
3.
action plan
Assessment
and derive
Prepare and
results
action plan
conduct process
assessment
• Process improvement programme plan for
For capability determination.
Assessment
request
(Parts 3 and 4)
• Target capability profiles from capability determination
• Industrial benchmarks
(Part 8)
current assessed
• Practice descriptions from the assessment
capability
model in Part 5 or another assessment
model compatible with Part 2 (Part 2)
Figure 2 — Software process improvement steps
© ISO/IEC
A comprehensive process improvement programme may identify improvement goals to be attained over several
iterations of the improvement cycle. It may contain several process improvement projects, concerned with
implementing improvement actions.
The steps in the improvement cycle are described in detail below in terms of their activities and tasks.
5.1 Examine the organization's needs and business goals
A process improvement programme starts with the recognition of the organization's needs and business goals,
usually based on one of the main drivers identified in 4.1. This recognition could be derived from any of the following:
 formulation of a mission statement or a long-term vision (see 7.1);
 analysis of organization's business goals;
 analysis of the organization's current shared values (see 6.2);
 the organization's readiness to undertake a process improvement programme;
 data on quality costs;
 other internal or external stimuli.
External stimuli that may trigger a process improvement programme include:
 declining market share;
 marketing analysis;
 feedback from customers;
 competitiveness changes in the market;
 requirements to meet specific industry benchmarks;
 new requirements from society.
Internal stimuli that may trigger a process improvement programme include:
 declining or unsatisfactory profitability;
 declining staff satisfaction;
 senior management/ownership change.
From an analysis of the organization’s needs and existing stimuli for improvement, the objectives of process
improvement may be identified and described in terms of quality, time to market, cost and customer satisfaction,
and business value with information services, along with predictability and control of the delivery of information
services and related risks.
The final stage of the preliminary definition of the goals for the improvement programme is setting the priorities of
the process improvement objectives.
The improvement goals direct the choice of the processes to be assessed, the definition of improvement targets
and ultimately the identification of the most effective improvement actions.
After the analysis of the organization’s needs and business goals, it is essential to build executive awareness of the
necessity for a process improvement programme. This requires both managerial and financial commitments. The
objectives of such a process improvement programme should be clearly stated and understood, and expressed
using measurable process goals. The process improvement programme should form part of the organization’s
overall strategic business plan.
© ISO/IEC
The executive decision to undertake improvement, together with the identification of a preliminary process
improvement programme budget and the main process improvement priorities, enable the improvement process to
progress through the following steps:
a) initiate process improvement (see 5.2);
b) carry out a software process assessment in the sectors where improvement is believed to be beneficial (see
5.3);
c) complete the process improvement programme plan with the action plan resulting from analysis of assessment
results (see 5.4);
d) implement improvements according to process improvement project plans (see 5.5);
e) confirm the improvements (see 5.6);
f) sustain the improvement gains by maintaining the new, improved level of performance until stability has been
reached (see 5.7);
g) monitor performance to continue the process improvement programme (see 5.8) comparing results against the
measurable goals of the process improvement programme plan developed in 5.2 and 5.4.
5.2 Initiate process improvement
The process improvement programme should be considered as a project in its own right, and planned, resourced
and managed accordingly (see process MAN.2 Project Management in ISO/IEC TR 15504-2). A process
improvement programme plan should be produced at the beginning of the programme and subsequently used to
monitor progress. The plan should include the relevant background and history and the current status, if possible
expressed in specific, numerical terms. The improvement goals derived from the organization’s needs and business
goals provide the main requirements for the plan. The plan should include a preliminary identification of the
improvement scope in terms of both the organizational boundaries for the improvement programme and the
processes to be improved.
The plan should cover all the process improvement steps, although initially the plan may only give outline
indications of the later stages. It is important to ensure that key roles are clearly identified, that adequate resources
are allocated, that appropriate milestones and review points are established, and that all risks associated with the
plan are identified and documented in the plan. The plan should also include activities to keep all those affected by
the improvement informed of progress.
5.3 Prepare for and conduct a process assessment
5.3.1 Prepare assessment input
This step gives guidance on how to define the assessment inputs needed to carry out a software process
assessment as described in ISO/IEC TR 15504-3.
5.3.1.1 Sponsor
Preparation for an assessment begins with the identification of a sponsor for the assessment. The sponsor is a
senior manager, who is committed to the process improvement programme, requires the assessment to be
performed, and provides resources for it. The sponsor ensures that the process assessment inputs (purpose,
scope, constraints and responsibilities) are adequately defined so as to meet the needs of the process improvement
programme. It is likely that the assistance and advice of a competent assessor will be of help to the sponsor in
formulating these inputs.
The sponsor has the authority to ensure that the assessment can be carried out effectively, and takes ownership of
the assessment output. The sponsor must be committed to the concepts of process improvement through process
assessment.
© ISO/IEC
5.3.1.2 Competent assessor
The responsibility for ensuring that an assessment is conducted in accordance with the provisions of
ISO/IEC TR 15504 is vested in the competent assessor who leads, or is part of, the assessment team. A key factor
in selecting an assessment team, and particularly the competent assessor, is credibility with the management and
staff of the organizational unit. Depending on the local circumstances, a competent assessor drawn from outside
the organizational unit may appear to be more credible on account of a more independent viewpoint.
5.3.1.3 Assessment purpose
The overall purpose of the assessment is to provide information about the process capability of the organizational
unit in the form of the assessment results. The statement of assessment purpose will guide the assessment team
during the conduct of the assessment, particularly with regard to the amount, nature and content of the information
they should capture during the assessment to aid improvement. The purpose statement should make clear that the
assessment is being done as part of a process improvement programme, and should contain clear descriptions of
quality improvement goals (see 7.3.4 and 5.1) and specifically the goals whose attainment is expected to be
dependent on the assessment results. All the information on the improvement background defined in the previous
steps 5.1 and 5.2 should be made available.
5.3.1.4 Assessment scope
The assessment scope defines the boundaries for the assessment, both organizationally and in terms of the
processes to be included.
From an improvement point of view the process improvement programme may address an entire organization, part
of an organization, a single project, or even a part of a project. A process assessment, however, addresses an
organizational unit with a coherent process context, particularly the application domain, size, criticality and
complexity, and quality characteristics of its products and/or services. If the process improvement programme
spans different organizational units with different types of operation, then each of them should be assessed
separately.
The broader the scope of an assessment, the greater the assessment effort needed to arrive at a representative
result. Therefore, the sponsor may wish to limit the scope to those processes that are expected to have the greatest
potential for improvement. Priority should be given to the processes or process categories that initially appear to
affect achievement of improvement goals derived from the organization’s needs and business goals. This initial
evaluation may change after an assessment is performed and the data is analysed. The scope statement should
include any assumptions or expectations in the process improvement programme plan about the strengths and
weaknesses of process categories, single processes, or practices.
The sampling of the implemented processes should be done by picking out representative selections that provide a
reliable picture of the current status of the software process. Therefore, it is useful to assess projects that are
considered both as the worst examples and as the best examples of the organization's current process
performance. In this way the variability between the worst and the best cases of the organization can be found and
taken into account in the improvement.
The scope is defined initially in terms of the processes operated and understood by the organizational unit.
Ultimately, however, the organizational processes need to be mapped to the processes in the process model
compatible with the reference model, to enable the assessment team to conduct the assessment. The mapping
may be undertaken by the assessment sponsor, or by the assessment team. If an organizational process cannot
be mapped on one of the processes in the process model, it should be defined as an extended process.
In addition to specifying the processes to be assessed, the scope should clearly identify the sampling strategy, the
organizational unit and its characteristics, and the product or service characteristics (process context). The product
or service characteristics, in particular, provide the context within which the assessment team will judge the
adequacy of the implemented practices and affect the validity of comparisons with other industry benchmarks.
© ISO/IEC
5.3.1.5 Assessment Constraints
The sponsor may wish to restrict the freedom of choice of the assessment team in defining the sampling strategy for
the assessment, in selecting individuals for interview, and in how information may be used. Any restrictions, which
may be positive or negative (for example, to include or exclude specific instances of the process) are documented
as the assessment constraints.
Similarly, the sponsor may wish to place constraints on which individuals are to be interviewed by the assessment
team. For process improvement, the process owners of each assessed process should always be involved in the
assessment.
Ownership of results and confidentiality of information may be an issue in many organizations. Whatever the
situation, the assessment constraints should include a clear statement about how the information and assessment
results may be used, and hence the confidentiality arrangements that apply.
5.3.2 Conduct a process assessment
A process assessment, as described in ISO/IEC TR 15504-3, is initiated using the assessment input prepared as
described in 5.3.1. The assessment delivers its results as the assessment output which consists of:
a) the current process profile;
b) the assessment record (i.e. any information which is pertinent to reviewing the results of the assessment
including, in particular, reference to supporting evidence for the process attribute ratings);
c) additional information for process improvement (for definition of goals, metrics and targets, see clause 7.3 and
practical examples in Annex A).
The additional information may include :
a) existing best practice that could be adopted and institutionalized in the organization;
b) experiences about the previous adoption of specific methods or tools in the organization;
c) cultural issues that might either foster or jeopardize improvement initiatives;
d) organizational issues that might affect the potential benefits of process improvement;
e) training needs.
The assessment output will show not only which processes are at a relatively low capability level, but also the
degree of variability across the organizational unit. Both aspects are useful in determining priorities for an
improvement programme.
The assessment record should be retained with the results, both as an aid to subsequent understanding, and in
case there is a later need to verify that the assessment was carried out in accordance with the provisions of
ISO/IEC TR 15504.
5.4 Analyse assessment output and derive action plan
Information collected during the assessment, in particular the capability level and process attribute ratings, is
analysed in the light of the organization's needs to:
 identify areas for improvement;
 set qualitative software process goals, and quantitative improvement targets;
 derive an action plan, and integrate it with the process improvement programme plan.
© ISO/IEC
Management should approve the areas for improvement, the goals and targets, and the updated process
improvement programme plan, thereby committing the organization to undertake the planned improvements. The
decision should be communicated clearly to all affected staff.
5.4.1 Identify and prioritize improvement areas
Improvement areas should be identified and prioritized based on a number of factors as outlined in figure 3. The
factors in detail are:
the assessment output, which shows weak and strong areas of the assessed processes;

 the organization's needs, which provide general improvement goals (see 5.1) to be achieved through the
improvement programme;
 effectiveness measures (see 7.3), which, if already in place, identify improvement priorities for the organization
generally related to the improvement drivers described in 4.1;
 industry norms and benchmarks that provide a basic comparison framework for assessment results;
 risks related to either not achieving the stated improvement goals or failure of improvement actions.
Effectiveness
measurements
Organization's
needs and
business goals
Identify and prioritize
Prioritized
Assessment
improvement
improvement areas
results
areas
Risks
Industry norms
and
benchmarks
Figure 3 — Identifying and prioritizing the improvement areas
5.4.1.1 Analyse assessment results
Analysis of the assessment results provides information about the current strengths and weaknesses of the process
and indicates opportunities for improvement. The analysis may be performed using process capability level ratings
and process attribute ratings together with the assessment context information.
The strong points are identified as the processes with the highest process capability level ratings. Strengths may
support process improvement as follows:
a) strong processes may provide experience of good practices that could be adopted and institutionalized in the
organization;
© ISO/IEC
b) processes with the highest process capability level rating within a process category or a set of interrelated
processes may show an opportunity for improving the effectiveness of the rest of the process category or set of
interrelated processes.
The weaknesses may be:
a) processes with low process capability level ratings;
b) processes with missing practices that are needed to enable the process to achieve a process purpose aligned
with a specific need of the organization;
c) unbalanced process attribute ratings within capability levels that are necessary to achieve a specific need;
d) low process attribute ratings across assessed processes that may indicate weakness in specific process
categories (for example low scores at process capability level 2 may show weaknesses in the Management
and Support process categories).
The variability of process capability ratings across the organizational unit should be evaluated in the light of the
process context to identify specific improvement actions.
Similarly, the process capability level ratings of related processes should be compared. Improvement actions may
be identified to correct any imbalance.
5.4.1.2 Analyse the organization's needs and improvement goals
The processes and their relationships should be analysed in order to evaluate which processes have direct impact
on the improvement goals identified in the process improvement programme plan. Specific relationships between
single processes should be considered in order to identify processes which should be addressed together to fulfil
certain improvement goals. In this way, a priority list of processes to be improved may be derived. The processes in
this list with low process capability level ratings may provide the best opportunity for improvement.
5.4.1.3 Analyse effectiveness measurements
Organizations with previous experience in process improvement may already have effectiveness measurement in
place. Where these are related to the existing organization's needs and derived improvement goals, it may be worth
analysing the current measurements to get a better understanding of what improvement is needed (see 7.3).
5.4.1.4 Analyse the risks in not achieving improvement goals
The impact on the organization's needs and business goals of failing to achieve improvement goals should be
evaluated in order to understand the urgency and to set the priority of improvement initiatives. The risk analysis will
provide hints on prioritizing improvement areas and will help to gain commitment and funding to carry out the
improvement actions as needed.
5.4.1.5 Analyse risks of improvement action failure
The potential risks of failure of an improvement action should be analysed in order to support the definition of
improvement priorities and to assure the proper commitment and organizational support. These risks may be
related to specific organizational issues, to specific time frames, to cultural issues, to commitment or to funding
issues. More precisely the risks may derive from:
 existing schedule constraints;
 existing psychological or cultural barriers, possibly derived from previous experiences;
 organizational issues preventing the successful execution of improvement actions.
The risk mitigation strategy may be influenced by hints from the assessment on where to find the main improvement
potential. This potential may be:
© ISO/IEC
 in organizational areas or processes with positive capability to change;
 synergistic with existing contractual commitments or well-understood customer expectations.
5.4.1.6 List improvement areas
A prioritized list of improvement areas may be provided as a combined result of analysing all the factors listed
above. The selected improvement areas define the scope of the improvement actions to be identified. The scope
could include:
 processes to be included;
 organizational boundaries for improvement;
 processes or projects to be either included or excluded in the improvement initiative.
5.4.2 Define specific improvement goals and set targets
Targets for improvement should be quantified for each priority area. These may be either target values for process
effectiveness, or target capability profiles, or combinations of the two. They should be
...