ISO/IEC TR 16326:1999

TECHNICAL ISO/IEC
REPORT TR
First edition
1999-12-01
Software engineering — Guide for the
application of ISO/IEC 12207 to project
management
Ingénierie du logiciel — Guide pour l'application de l'ISO/CEI 12207 à
la gestion de projet
Reference number
©
ISO/IEC 1999
PDF disclaimer
This PDF file may contain embedded typefaces. In accordance with Adobe's licensing policy, this file may be printed or viewed but shall not
be edited unless the typefaces which are embedded are licensed to and installed on the computer performing the editing. In downloading this
file, parties accept therein the responsibility of not infringing Adobe's licensing policy. The ISO Central Secretariat accepts no liability in this
area.
Adobe is a trademark of Adobe Systems Incorporated.
Details of the software products used to create this PDF file can be found in the General Info relative to the file; the PDF-creation parameters
were optimized for printing. Every care has been taken to ensure that the file is suitable for use by ISO member bodies. In the unlikely event
that a problem relating to it is found, please inform the Central Secretariat at the address given below.
© ISO/IEC 1999
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 microfilm, without permission in writing from either ISO at the address below or ISO's member body
in the country of the requester.
ISO copyright office
Case postale 56 � CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 734 10 79
E-mail copyright@iso.ch
Web www.iso.ch
Printed in Switzerland
ii © ISO/IEC 1999 – All rights reserved

Contents Page
1 Scope .1
1.1 Audience.1
1.2 Prerequisites .2
2 Conformance.2
3 Normative references .2
4 Terms and definitions .3
5 Symbols and abbreviated terms .3
6 Guidance.3
6.1 Introduction to software project management .3
6.2 Management process .4
6.2.1 Initiation and scope definition.5
6.2.2 Planning.6
6.2.3 Execution and control .9
6.2.4 Review and evaluation .10
6.2.5 Closure.12
Annex A (informative) Support of the ISO/IEC 12207 Management Process.14
Annex B (informative) SPM activities mapped to the Management Process activities .16
Annex C (informative) Project Management Processes mapped to the ISO/IEC 12207 Management
Process activities.17
Annex D (informative) Supporting information .18
Annex E (informative) Bibliography .29
© ISO/IEC 1999 – All rights reserved iii

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.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 3.
In the field of information technology, ISO and IEC have established a joint technical committee, ISO/IEC JTC 1.
Draft International Standards adopted by the joint technical committee are circulated to national bodies for voting.
Publication as an International Standard requires approval by at least 75 % of the national bodies casting a vote.
In exceptional circumstances, 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), it may decide by a simple majority
vote of its participating members to publish a Technical Report. A Technical Report is entirely informative in nature
and does not have to be reviewed until the data it provides are considered to be no longer valid or useful.
Attention is drawn to the possibility that some of the elements of this Technical Report may be the subject of patent
rights. ISO and IEC shall not be held responsible for identifying any or all such patent rights.
ISO/IEC TR 16326 was prepared by Joint Technical Committee ISO/IEC JTC 1, Information technology,
Subcommittee SC 7, Software engineering.
Annexes A to E of this Technical Report are for information only.
iv © ISO/IEC 1999 – All rights reserved

Introduction
Software is an integral part of information technology and conventional systems, e.g., transportation, military,
medical care and finance. There is a proliferation of standards, procedures, methods, tools and environments for
developing and managing software. This proliferation has created difficulties in software project management and
engineering, especially in integrating products and services. The software discipline needs to migrate from this
proliferation to a common framework for software practitioners to “speak the same language” to create and manage
software. ISO/IEC 12207, Information technology — Software life cycle processes, provides a common framework.
The ISO/IEC 12207 framework covers the software life cycle from conceptualization of ideas through
retirement/closure and consists of processes for acquiring and supplying software products and services. This
framework also provides for controlling and improving these processes.
ISO/IEC 12207 provides a comprehensive set of software life cycle processes. An organization, depending on its
purpose, can select an appropriate ISO/IEC 12207 subset to fulfil that purpose. ISO/IEC 12207 is designed to be
tailored for an individual organization, project or application. It is also designed to be used when software is a
standalone entity, or an embedded or integral part of a total system.
This Technical Report provides guidance for the Management Process as introduced by ISO/IEC 12207,
subclause 7.1. Most of the guidance is provided based on Project Management Institute’s (PMI’s) A Guide to the
Project Management Body of Knowledge (PMBOK™ Guide) [11], ISO 10006, Quality management — Guidelines
to quality in project management [5] and experience of people who have been successful software project
managers.
It is not the intent of this Technical Report to suggest any organizational role or responsibility.
It is recognized that identified processes, activities and tasks have an iterative “life” and they may occur in any
order or frequency. These processes, activities and tasks must be coordinated with other processes, activities and
tasks not emphasized in this Technical Report, e.g., ISO/IEC 12207’s Supporting and Organizational Life Cycle
Processes.
This Software Project Management Technical Report is organized as follows:
� Section 1 provides the document’s scope.
� Section 2 identifies the conformance requirements.
� Section 3 identifies the normative references.
� Section 4 provides the definitions used in this Technical Report.
� Section 5 provides the symbols and abbreviations used in this Technical Report.
� Section 6 has guidance on the ISO/IEC 12207 Management Process.
� Annex A maps ISO/IEC 12207 Management Process activities to the ISO/IEC 12207 Primary Processes.
� Annex B maps ISO/IEC 12207 Management Process activities to [11]’s project management knowledge areas.
� Annex C maps ISO/IEC 12207 Management Process activities to [5]’s project management processes.
� Annex D maps ISO/IEC 12207 to [5]’s process levels and to [11]’s project management knowledge area major
processes.
� Annex E provides a bibliography of some reference material. This list is not inclusive, nor an endorsement of
any reference.
© ISO/IEC 1999 – All rights reserved v

TECHNICAL REPORT ISO/IEC TR 16326:1999(E)
Software engineering — Guide for the application of ISO/IEC 12207
to project management
1 Scope
This Technical Report supplements International Standard ISO/IEC 12207, Information technology — Software life
cycle processes, in the area of Management Process (hereafter referred to as “software project management” or
SPM. Thus, in this Technical Report, SPM is not a person, but a process). This Technical Report was developed by
(see Figure 1):
� Applying the Management Process in ISO/IEC 12207 to SPM.
TM TM
� Using A Guide to the Project Management Body of Knowledge (PMBOK ) [11] to define and describe
management knowledge areas applicable to SPM.
� Using ISO 10006, Quality management – Guidelines to quality in project management [5].
This Technical Report provides guidance to people responsible for managing the performance of ISO/IEC 12207
software life cycle Primary Processes: Acquisition, Supply, Development, Operation and Maintenance. The
guidance addresses:
� General guidance for SPM regarding ISO/IEC 12207, subclause 7.1, management activities as they are
supported in each Primary Process.
� SPM applicability for each Primary Process.
� Key areas applicable across the spectrum of SPM.
� Expanded guidance for software Project Managers (PMs) regarding the management tasks from:
TM
� [11] — Identifies and describes generally that subset of the PMBOK which is generally accepted.
Generally accepted means that the knowledge and practices described are applicable to most projects
most of the time, and there is widespread consensus about their value and usefulness.
� [5] — Gives guidance on quality system elements, concepts and practices for which the implementation is
important to and has an impact on the practice of project management.
This Technical Report addresses aspects of project management that are either “software specific” or are known to
cause problems in software projects in any of the ISO/IEC 12207 Primary Processes. For example, it is well known
that software projects are often late and/or over budget, or are unable to meet an acquirer’s requirements or
expectations. While this is not peculiar to software, there are a number of software specific attributes causing this to
happen.
Figure 1 illustrates the relationship of ISO/IEC 12207, [11] and [5] in the development of this Technical Report.
1.1 Audience
This Technical Report is written for those who use or plan to use ISO/IEC 12207 on software projects regardless of
project scope, product, methodology, size or complexity. This Technical Report is written primarily to aid software
PMs in ensuring management processes conform to ISO/IEC 12207, specifically:
© ISO/IEC 1999 – All rights reserved 1

� Managers responsible for establishing and continuously improving ISO/IEC 12207 software life cycle
processes.
� Managers responsible for executing any ISO/IEC 12207 software life cycle process at a project level.
� Organizations or individuals subcontracting an SPM effort.
Consideration is given to people who have:
� Worked on software projects, but not as a software PM.
� Been non-software PMs, but are transitioning to be software PMs.
This Technical Report presents the primary ISO/IEC 12207 life cycle processes from the perspective of a software
PM and provides advice (based on experience, lessons learned, etc.) about best practices and recommendations
to be applied to management tasks by the practitioners. Lastly, this Technical Report enables engineering,
technical and other support staffs to see how their efforts integrate within a total, software life cycle.
1.2 Prerequisites
The prerequisites to use this Technical Report are:
� Availability of and familiarity with ISO/IEC 12207.
� Familiarity with the relevant organizational policies and procedures.
� Knowledge of stakeholder and contract requirements (needs and expectations).
TM
ISO/IEC 12207 – Software
ISO/IEC 10006 – Guidelines to PMBOK Guide – Project
life cycle processes
quality in project management management knowledge areas
ISO/IEC TR 16326 – Guide for the application of ISO/IEC 12207 to project management
Best practices, lessons learned, etc.
TM
Figure 1 — Use of ISO/IEC 12207, PMBOK Guide and ISO 10006 to create this Technical Report
2 Conformance
Since this is a Technical Report, there are no conformance requirements.
3 Normative references
Since this is a Technical Report, normative references are not required. See the Bibliography (Annex E) for some
informative references.
2 © ISO/IEC 1999 – All rights reserved

4 Terms and definitions
For the purpose of this Technical Report, the definitions given in ISO/IEC 12207, [11] and [5] apply, in that
hierarchial order.
5 Symbols and abbreviated terms
The following symbols and abbreviations are used in this Technical Report:
CCB* Configuration/Change Control Board
ICWG* Interface Control Working Group
IEC International Electrotechnical Commission
ISO International Organization for Standardization
PM Project Manager
SEE Software Engineering Environment
SPM Software Project Management
WBS Work Breakdown Structure
* Depending on the size and complexity of a project, can be a group of people, a single person or a function.
6 Guidance
6.1 Introduction to software project management
A project is a temporary endeavour undertaken to create a unique product or service [11]. As such, a project
involves a group of people, resources and events with the following common characteristics:
� The main objectives are to create products, services and results.
� A project has a known beginning and end, i.e., a project is temporary.
� A project is not part of the normal, ongoing operation of most organizations, i.e., it usually has a unique
requirement. Some organizations (e.g., Research and Development) exist only to perform projects.
A software project is a project emphasizing software as its product, service or result. So, how does software differ
from other project products, services and results? As stated by Watts Humphrey [17]:
� Software is generally more complex.
� Software changes appear relatively easy to make.
� Many late-discovered hardware problems are addressed through software changes.
� Because of its low reproduction cost, software does not have the natural discipline of release to manufacturing.
� Software discipline is not grounded in natural science and it lacks ready techniques for feasibility testing and
design modelling.
© ISO/IEC 1999 – All rights reserved 3

� Software is often the element integrating an entire system, thus adding to its complexity and creating
exposures to late change.
� Software is generally most visible, thus most exposed to requirements changes and most subject to user
complaint.
Because software is different from non-software products, services and results, the management of software
projects is also different. This is not to say SPM is totally different from the management of non-software projects.
The key item is that there are unique areas of SPM and general project management that management must be
aware of to achieve project goals, as well as prevent problems.
[11] provides important information about managing projects. ISO/IEC 12207 provides important information about
software projects within ISO/IEC 12207, subclause 5.2 (Supply Process) and describes many activities and tasks to
be performed. [5] provides information on how to improve the quality of project management. The main purpose of
this Technical Report is to highlight how the differences described above impact a software PM, to show how these
three documents complement each other and to help PMs manage software projects to a successful conclusion.
Rapidly changing technology in the software discipline is outpacing management and process techniques. This is
compounded by the incompleteness of the range of project management tools and techniques available to software
engineers as compared to other engineering disciplines.
SPM methodology implementation is determined by many factors, e.g., personnel, organizational and contractual
requirements, and project complexity.
A software PM determines the methodology and technology for undertaking a project and should be required to:
� Anticipate and thus prevent or minimize the adverse impact of problems.
� Make timely and firm decisions.
� Resolve problems when they occur.
� Take responsibility for a project’s actions, processes, activities, resources, products and results.
As an iterative endeavour, a software PM must consider any systemic impact when undertaking an action, e.g., an
action, or failure to act, in an area can affect other areas.
6.2 Management process
This clause examines ISO/IEC 12207’s (subclause 7.1) Management Process. ISO/IEC 12207 defines a generic
management process (rather than SPM) that may be employed by any party managing its processes. This clause
discusses the ISO/IEC 12207 Management Process as it applies to the management of software projects (SPM).
It is recognized that identified processes, activities and tasks may require a reiterative action to accomplish the
requirements/goals of a project. For instance, based upon the software life cycle model being used, processes,
activities and tasks may be employed at the same time; they may be interdependent; or they may be coordinated in
an organized series of Work Breakdown Structure (WBS) dependencies throughout a software project life cycle.
ISO/IEC 12207
7.1 Management process. The Management Process contains the generic activities and tasks, which may
be employed by any party that has to manage its respective process(es). The manager is responsible for
product management, project management, and task management of the applicable process(es), such as
the acquisition, supply, development, operation, maintenance, or supporting process.
4 © ISO/IEC 1999 – All rights reserved

ISO/IEC 12207 (subclause 7.1) states “of the applicable process(es)” since a project may not involve all of the
Primary Processes. For instance, a project may be only involved with the development or maintenance of a
product, rather than product operation.
SPM should define (and the software PM control) the activities needed to ensure products are delivered as
specified in a contract, i.e., ensure a software project includes all the work required, and only the work required, to
complete the project and product successfully.
6.2.1 Initiation and scope definition
ISO/IEC 12207
7.1.1 Initiation and scope definition. This activity consists of the following tasks:
7.1.1.1 The management process shall be initiated by establishing the requirements of the process to be
undertaken.
7.1.1.2 Once the requirements are established, the manager shall establish the feasibility of the process by
checking that the resources (personnel, materials, technology and environment) required to execute and
manage the process are available, adequate, and appropriate and that the time-scales to completion are
achievable.
7.1.1.3 As necessary, and by agreement of all parties concerned, the requirements of the process may be
modified at this point to achieve the completion criteria.
Initiation and scope definition is the determination of the feasibility of a process to ensure personnel, materials,
facilities, Software Engineering Environment (SEE) and technology required to execute and manage a project are
available, adequate and appropriate; and the predetermined times for completion are achievable, timely and
economical. This involves choosing a software development strategy (e.g., a project may consist of off-the-shelf
software, in-house software, out-sourced software or a combination of these).
Scope (e.g., description of a project product, product characteristics and how the characteristics are to be
measured or assessed) related items aim to:
� Document the reason for the project, its goals and its objectives.
� Translate stakeholder requirements into project deliverables and activities to be carried out to achieve and
organize a project.
� Ensure people work within the scope.
� Evaluate the results of activities to facilitate the results meeting scope requirements.
In the best case scenario, a new software project has many similarities to a project previously managed by an
organization. This provides a high level of assurance that an organization has the capability to perform a software
project successfully.
Initiation and scope definition may be difficult to perform when a new project is unprecedented (i.e., has not
previously been performed by an organization). For an unprecedented project, special care should be taken to
ensure it is properly scoped and monitored. This should be accomplished by having frequent reviews and
evaluations, reviewing best practices and lessons learned from somewhat related projects, and by seeking advice
from experts.
The key to initiation and scope definition is to establish and document the comprehensive scope and requirements
of a software project. This involves identifying and understanding stakeholder requirements, and evaluating and
negotiating comprehensive requirements. Special care should be taken to manage change to the scope and
requirements throughout a software project’s life cycle. All changes in scope and requirements should be carefully
© ISO/IEC 1999 – All rights reserved 5

evaluated for the impact on cost, schedule, risk and performance. All stakeholders should be involved in the
requirements definition of a software project.
Special care should be applied to defining and documenting quality characteristics [19]; for example, when software
is to be embedded in a higher-level system, or functions are to be distributed between software and hardware, or
between software and external interfacing software or systems.
Responsibility for obtaining stakeholder agreement on project requirements should be determined. Agreement is
the result of an iterative process to be employed throughout a software project life cycle. Risks, changes in
stakeholder requirements, environment, project budget and schedule, and an evolving design make it necessary to
continually reassess and reaffirm agreements and commitments, and make appropriate changes to the project
scope, as required.
Establishing completion criteria is very important. The intent, as supported by [11], is to determine if a project,
activity or task has been completed successfully.
A business requirement, often ignored by software PMs, is the handling of copyrights, patents, etc. For instance,
when does an acquirer own a developing product or what does an acquirer own when a supplier goes out of
business prior to final product delivery?
Software specific advice:
� Requirements for software replication, distribution, installation and testing should be carefully determined.
� Traceability between system and software requirements, between software requirements and design, and
between software requirements and tests should be established and maintained.
� Interfaces should be specified and controlled as an integral part of software specification and interface
description documents.
� Due to the complexity of software development, it is difficult to prove software products meet all user
requirements (needs and expections).
� Workload projection depends on the type of project: a new development, embedding in or integration to a
system, modification of off-the-shelf software product, porting to different operating systems, etc.
6.2.2 Planning
ISO/IEC 12207
7.1.2 Planning. This activity consists of the following task:
7.1.2.1 The manager shall prepare the plans for execution of the process. The plans associated with the execution
of the process shall contain descriptions of the associated activities and tasks and identification of the
software products that will be provided. These plans shall include, but are not limited to, the following:
a) Schedules for the timely completion of tasks;
b) Estimation of effort;
c) Adequate resources needed to execute the tasks;
d) Allocation of tasks;
e) Assignment of responsibilities;
f) Quantification of risks associated with the tasks or the process itself;
g) Quality control measures to be employed throughout the process;
h) Costs associated with the process execution;
i) Provision of environment and infrastructure.
6 © ISO/IEC 1999 – All rights reserved

The responsibility for preparing and approving plans should be defined.
Plans should identify the software life cycle model, task, task assignments, commitments and resources. A
software project should have one master schedule and all subordinate schedules should be integrated and
consistent with the master schedule. A WBS can effectively measure software project progress and provides
visibility into processes and products. A WBS technique is strongly encouraged because it organizes and defines
the total scope of the project [11]. The WBS should be constructed to allow a software project to be managed at the
appropriate level of granularity consistent with the size, complexity, criticality and risk of the software project;
familiarity is needed on the technology to be used.
Project estimates used in planning should include:
� Costs associated with process execution.
� Infrastructure.
� Need for resources, including related management and control.
� Quality assurance and control.
� Risk management.
� SEE provisions.
� Work to be performed in each process and/or activity.
Software PMs should make every attempt to use existing organizational infrastructure whenever possible. If
existing infrastructure is insufficient to support a project, then adaptation or additions to existing infrastructure
should be handled judiciously. This may require the use of subcontracting to satisfy infrastructure deficiencies.
Consultants may help bringing agreement on various matters.
Planning is an iterative activity in which a software project is assessed, refined and revised (as necessary) as
project execution progresses. Software PMs should have processes in place to facilitate re-planning and
refinement of estimates throughout a software project life cycle. There are many interdependencies on every
software project and several iterations of planning are usually required to obtain even an initial SPM plan. For
information needed by an SPM plan, but provided in other plans, an SPM plan may reference the other plans.
Plans should be updated and at least contain:
� Roles and Responsibilities.
� Activities and tasks to be performed.
� All project deliverables identified in a WBS.
� Completion criteria.
� Completion reporting.
� Cost and schedule reporting.
� Means of initiation - by direction, product or time-based.
� Frequency and means of reporting progress.
� Problem or exception reporting.
� Resource requirements and status.
© ISO/IEC 1999 – All rights reserved 7

Supporting Process managers should develop documented plans since Supporting Processes (e.g., Configuration
Management, Documentation, Quality Assurance) are normally part of a project. Supporting Process plans should
be aligned with and support the SPM plan, and may be separate plans or may be included in a SPM plan. These
documented plans should be approved by the software PM and placed under project change control.
Activity reporting related to Supporting Processes should be given to the software PM either directly or through
organizational management. Problem or exception reports should be brought to the attention of the software PM for
impact analysis on a project’s cost, schedule, scope and quality. There should exist a mechanism for conflict
resolution or escalation so an appropriately authorized level of organizational management may resolve
disagreements between the software PM and Supporting Process management.
Where milestones are in place and achievement of milestones is dependent upon one or more reports and/or
outcomes from any Supporting Process, it is important that these achievements are reported in an accurate and
timely manner in accordance with approved plans. Since it is common for milestones to be contractually linked to
performance of Supporting Processes (for example achievement of a particular baseline), it is essential the plans
be synchronized and the software PM be made aware (as soon as possible) of any difficulties experienced by
Supporting Processes in completing assigned tasks.
Whenever Supporting Processes are performed by organizations outside the direct organizational control of the
software PM, it is important to realize the existence of two sets of relationships between: 1) the software PM and
the Supporting Process management, and 2) the supported and supporting organizational management. The
software PM should recognize this when considering aspects of planning, implementation, control and reporting
through clearly defined technical and management reporting, information flow and dispute resolution.
Synchronization of plans may be more difficult under subcontract agreements and tasking, but can be aided by
having one master plan.
Historical project data are the main source for analysing and understanding organizational process capability and
efficiency, historical project performance and lessons learned. These historical data form a global database an
organization should use to continuously improve Organizational Life Cycle Processes. The same database should
support the execution of the Management Process for individual software projects. Every organization should
establish a formal system to collect, analyse, summarize, archive and retrieve historical project data.
Software specific advice:
� Since an effective configuration management strategy is critical to software projects, the following strategies
may be used as part of a change control process to manage changes:
� A change threshold should be established allowing incorporation of any software change costing less than
a specified amount without requiring a modification to a contract.
� A batch-for-change grouping of changes should be used for easy incorporation of changes to minimize
schedule impacts on development and to maximize stability.
� Agreement on interfaces should be obtained at project commitment and throughout a project to deal with
chronic problems of vague, inaccurate, changing or un-testable requirements and specifications.
� Most cost models are based on estimated software volume. The real problem is determining the volume and
calibrating the model for a specific project. To do this well, the following should be considered:
� Data collected from previous projects.
� The use of an expert to operate and interpret the model.
� If not calibrated to a project’s organizational experience, a cost model may be in error by up to an order of
magnitude.
� Under no circumstances should one cost model be relied on to produce the final cost estimate.
8 © ISO/IEC 1999 – All rights reserved

� Software systems are difficult to visualize, thus making the effect of change difficult to predict and
manage.
� Software needs to be “packaged” to facilitate its efficient and effective replication, distribution, installation,
testing and operation.
� Software plans should be closely tied to those for hardware and must be managed together,
notwithstanding the fact they may be executed by different organizations. In particular, milestones must be
linked and decided upon with full consultation between hardware and software developers to limit
possibilities of one area causing a project delay.
� Plans for software need to be closely tied to the plans of the customer, host hardware and environment.
� When procuring software resources determine:
� If maintenance and version upgrades are free.
� Ownership rights, e.g., warranty, intellectual rights, patents and copyrights.
6.2.3 Execution and control
ISO/IEC 12207
7.1.3 Execution and control. This activity consists of the following tasks:
7.1.3.1 The manager shall initiate the implementation of the plan to satisfy the objectives and criteria set,
exercising control over the process.
7.1.3.2 The manager shall monitor the execution of the process, providing both internal reporting of the
process progress and external reporting to the acquirer as defined in the contract.
7.1.3.3 The manager shall investigate, analyse, and resolve the problems discovered during the execution of
the process. The resolution of problems may result in changes to plans. It is the manager’s
responsibility to ensure the impact of any changes is determined, controlled, and monitored. Problems
and their resolution shall be documented.
7.1.3.4 The manager shall report, at agreed points, the progress of the process, declaring adherence to the
plans and resolving instances of the lack of progress. These include internal and external reporting as
required by the organizational procedures and the contract.
This activity normally begins when the software PM authorizes expenditure (or the additional expenditure) of funds.
The software PM should be responsible for monitoring the effort in the control portion of this activity to ensure any
deviation from documented planned performance is identified and analysed promptly, and suitable corrective action
is undertaken to bring the process back under control. The software PM should use the control portion of this
activity to take corrective action to resolve emerging problems and to take preventive action to thwart anticipated
problems with process execution. Software measurement (e.g., metrics), the change control process, and software
product and process evaluations and audits are instrumental in monitoring and controlling project execution.
Software measurements can be used to validate the expected software product functions versus the service to be
done.
NOTE Interface Control Working Groups (ICWGs), for example, are essential for successful execution, evaluation of
interface constraints and control of software projects. ICWGs should consist of a representative from each organization affected
by an interface. ICWGs provide a forum to discuss software and system interfaces, explore options and reach agreement on the
best approach for implementing interfaces. ICWG recommendations requiring project changes should be presented to a
Configuration Control Board (CCB) for approval prior to implementation.
© ISO/IEC 1999 – All rights reserved 9

The software PM should be responsible for satisfying communication requirements, including timely progress
reporting to stakeholders, promulgation of revisions to plans and work authorization, and deviation reporting and
documenting, as necessary. Centralized, up-to-date databases are useful to facilitate exchanges between people.
The software PM should ensure software projects are completed within the agreed time limits to satisfy stakeholder
requirements. The software PM should determine, in conjunction with stakeholders, the overriding objective of a
software project. A project’s ultimate objective may not result in the option of ensuring the least time or cost to
complete a project, e.g., safety critical systems require intense testing.
Risk-related processes (management of project risk) deal with uncertainties in planning throughout a project and
requires a structured approach. The aim of risk-related processes is to minimize the impact of potential negative
events and to take full advantage of opportunities for improvement. Risks are related either to the project processes
or tools, or to the compliance of the product with project objectives.
Software specific advice:
� Recovery from a schedule slip needs to be carefully assessed and should not be expected without a negative
impact on performance, cost or risk.
� Adding more personnel to a late software project could make it later, depending on the capability of the new
personnel.
� To mitigate risk, demonstrations permit acquirers and customers to experience the capabilities of a software
product prior to selection of a supplier.
� Use prototyping to develop a portion of the software functionality to demonstrate the functionality executes
properly.
� Critical system engineering efforts should not be conducted without sufficient software engineering expertise.
� In cooperation with stakeholders, review the software requirements baseline regularly throughout a project to
ensure compliance with or adjustment to the objectives (cost, time and performance).
� The number of people and teams on a project should be linked to the budget and schedule, and normal spans
of control should not be exceeded.
� As a result of software being difficult to visualize, there are many difficulties with the evaluation of progress.
Managers should define and refine techniques to determine progress, so as to allow early detection of cost or
schedule overruns.
� Since software development and maintenance activities are often dependent on individual skills and
experience, managers should try to prevent unneccessary substitution of staff on in-progress work items.
� Constant communications with stakeholders is essential to minimize surprises in performance, cost and
schedule.
6.2.4 Review and evaluation
ISO/IEC 12207
7.1.4 Review and evaluation. This activity consists of the following tasks:
7.1.4.1 The manager shall ensure that the software products and plans are evaluated for satisfaction of
requirements.
7.1.4.2 The manager shall assess the evaluation results of the software products, activities, and tasks completed
during the execution of the process for achievement of the objectives and completion of the plans.
10 © ISO/IEC 1999 – All rights reserved

ISO/IEC 12207’s Supporting Processes (e.g., Joint Review and Audit Processes) supplements the Review and
Evaluation activity.
The software PM should be responsible for ensuring software products and plans are evaluated for:
� Assessing the review results of software products, activities and tasks.
� Complying with SPM plans, philosophy, methodology and technology.
� Documenting plans and commitments.
� Satisfying requirements.
� Readiness for advancement to the next process, activity or task.
The software PM should participate in critical reviews. SPM plans should be the basis for tracking software project
processes and activities. A combination of event- and schedule-driven criteria may be used to manage review
activities.
Periodic review and evaluation of work-in-progress and work-to-be-completed is an essential element for
successful software projects. The software PM should validate the expected software product functions versus the
service to be performed. The software PM should select a set of software measurements to provide meaningful
insight into the progress throughout a software life cycle. Progress should be determined primarily by comparing
actual measurements of software work product size, effort, cost, schedule, units completed, or build content with
estimates documented in a SPM plan and to the amount of work to be completed. The software PM should direct
performance reviews of software project teams and should provide periodic progress reviews to provide status for
stakeholders. Use of proper tools can be of great assistance to a review and evaluation activity.
Evaluation of work-in-progress is best performed by personnel familiar with the project requirements, technologies
involved, product, requirements, and processes and infrastructure being used. Management reviews should cover
project activities in support of a software life cycle. Top-level reviews should rely heavily on functional/technical
level reviews and should be used to form an overall software project assessment.
Management review of schedule performance, especially software package progress, should be structured and
performed to provide realistic assessments. Use of software measurements; earned value analysis; and results
from inspections, walkthroughs, and joint and peer reviews are essential for meaningful software package
assessments to support an accurate project assessment.
Documenting significant issues, action items and decisions resulting from reviews and evaluations should be
required. Action items and significant issues should be tracked to closure and problems identified should be
entered into a project corrective action system.
Software measurements and change controls are instrumental in managing and controlling software project
execution. The software PM should institute a software measurement program to provide a framework for risk
identification, quantification and assessment. The software PM should choose appropriate software risk
measurements to provide meaningful insight into software project risks throughout a software life cycle. In general,
reviews and evaluations should be performed to determine technical and business risk areas.
Guidance on quality system elements, concepts and practices is important to, and has an impact on, the practice of
project management. Projects consist of processes and an action in a process usually affects other processes.
Overall management of interdependencies among project processes is the responsibility of software PMs.
Software specific advice:
� Any schedule slippage prior to commencement of testing, without a corresponding slippage in delivery date,
may result in a project being unable to complete testing according to plans.
� Establish a comprehensive test plan early in the software project life cycle.
© ISO/IEC 1999 – All rights reserved 11

ISO/IE
...