See discussions, stats, and author profiles for this publication at: https://www.researchgate.net/publication/270163046
The Use of ISO/IEC 15288 to Understand the Principal Responsibilities for
Project Delivery
Conference Paper · August 2011
CITATIONS
READS
0
22,358
2 authors:
Bronwyn Jones
Mike Ryan
UNSW Sydney
Capability Associates
7 PUBLICATIONS 6 CITATIONS
400 PUBLICATIONS 6,342 CITATIONS
SEE PROFILE
All content following this page was uploaded by Mike Ryan on 30 December 2014.
The user has requested enhancement of the downloaded file.
SEE PROFILE
The Use of ISO/IEC 15288 to Understand the Principal Responsibilities for
Project Delivery
Bronwyn L. Jones & Michael J. Ryan, School of Engineering & Information Technology,
University of New South Wales at the Defence Force Academy (UNSW@ADFA)
Northcott Drive, CANBERRA, ACT, 2600
B.Jones@adfa.edu.au & M.Ryan@adfa.edu.au
Abstract
Although the rapid increase in communications
connectivity between project, program and
portfolio decision makers will bring many
advantages, the full benefit of such connectivity
will not be realised until there is seamless
connectivity between all those responsible for the
delivery of a project. The seamless integration of
effort is seriously hampered by the lack of a
universally agreed set of responsibilities for all
those involved in project delivery, particularly the
domains of business management, project
management, systems engineering, and operations.
This paper proposes that ISO/IEC 15288:2008(E)
(ISO/IEC 15288) [1] provides a very useful
framework within which to examine the principal
responsibilities of each of the domains for the
various activities involved in project delivery. The
paper provides a visualisation of ISO/IEC 15288
that assists in illustrating the various
responsibilities—in particular, the knowledge areas
of the Guide to the Project Management Body of
Knowledge (PMBOK® Guide) [2] are mapped on
to standard’s processes.
Domains Responsible for Delivering
Projects
Delivery of a project is not the responsibility of
only project management—there are a number of
domains responsible for the various activities in the
project life cycle. The major domains are:

business management;

project management;

systems engineering; and

operations.
Unfortunately, there is no general agreement about
how these different domains should contribute to a
project and much discussion on where that effort is
actually applied. A very general view of how each
domain might contribute is shown in Figure
1Figure 1, suggesting that all domains are involved
in each phase of a project, but each has principal
responsibilities at various times.
Figure 1 is useful in a very generic sense in that it
shows broad involvement by each of the domains,
and illustrates the point that it is a cooperative
effort that requires considerable communication at
all times throughout a project. Failure to consider
other domains creates significant issues for the
project management domain. A more useful view
is required.
This paper proposes that ISO/IEC 15288 provides
a very useful framework within which to examine
the principal responsibilities of each of the
domains for the various activities involved in
project delivery. The paper provides a visualisation
of ISO/IEC 15288:2008(E) that assists in
illustrating the various responsibilities—in
particular, the knowledge areas of the Project
Management Body of Knowledge (PMBOK®) [2]
are mapped on to the standard’s processes.
The Role of ISO/IEC 15288:2008(E)
ISO/IEC 15288 [1] proposes a common process
framework covering the life cycle of man-made
systems in order to address a need for a common
framework that will improve communication and
cooperation among the parties that create, utilise,
and manage modern systems. This is in response to
the ever-increasing complexity of man-made
systems, which results in opportunities and
challenges for those involved in their creation and
use.
The generic structure of ISO/IEC 15288 includes
six main sections plus eight supporting annexes.
The six main sections cover:

Section 1 – Overview.

Section 2 – Conformance.

Section 3 – Normative references.

Section 4 – Terms and definitions.

Section 5 – Key concepts and applications
of this standard.

Section 6 – System life cycle processes.
Business
Management
Project
Management
Pre-acquisition Phase
Systems
Engineering
Acquisition Phase
Operations
Utilization Phase
Retirement Phase
Figure 1 - Contribution of domains to a project over time
Sections 1 – 4 provide supporting information,
while Section 5 introduces the key concepts that
provide the foundation for the application of the
system life cycle processes in Section 6. These
system life cycle processes are the key focus of this
paper.

The general relationship between each
process group, or within process groups, is
indicated by directional-flow arrows and
supplementary text.

The general shape of the systems
engineering ‘vee’ diagram is used in the
Technical process groups. This vee shape
and supplementary text represent the
systems engineering top-down and
bottom-up approach to systems definition
and systems integration respectively. A
system then enters into its ‘useful’ life for
the remaining processes of operation,
maintenance and disposal.

A nominal ‘system of interest’ is shown in
order to provide context for the
application of the processes identified
above. The ‘system of interest’ is generic
and in reality could be any type of project
deliverable (for instance, it might be a
business strategy).
ISO/IEC 15288 identifies four process groups, each
of which includes between two to five processes.
The process groups cover:

Agreement processes,

Organisational Project-Enabling
processes,

Project processes, and

Technical processes.
ISO/IEC 15288:2008(E) relies very heavily on a
structured text-based approach to describe each of
the system life cycle processes, within their process
groups. First, the intent of each process group is
outlined, and then each process is described in
terms of a number of attributes including [1]:

Title – to convey the scope of the process.

Purpose – describes the goals of the
performing the process.

Outcomes – expresses the observable
results expected from the successful
performance of the process.

Activities – sets of cohesive tasks of a
process.

Tasks – requirements, recommendations
or permissible actions intended to support
the achievement of the outcomes.
The limited visual aids in ISO/IEC 15288 do have
some utility and probably support reasonable
transfer of knowledge to experienced practitioners,
but the standard is largely text-based which means
that it is very hard to visualise how the processes
are related to each other. Figure 2 [3] shows a
diagram that draws upon the content of ISO/IEC
15288 and supplements it with additional
information.
Figure 2 firstly reflects the four process groups
from ISO/IEC 15288 identified earlier and their
subordinate processes. The following features are
also noted:
This diagram provides a first-level ‘map’ of the
system life cycle processes that acts as a framework
or key to develop further understanding. The
diagram therefore acts as a summary of how,
generically, the system life cycle processes might
interact and be applied.
Next, note the colour coding applied to individual
processes within Figure 2. Different colours are
attributed to each of the four domains identified
earlier (namely business management, project
management, systems engineering, and operations).
This allocation represents the principal
responsibilities of each domain, identified through
comparison of their relevant bodies of knowledge
with ISO/IEC 15288 processes. The fact that this
allocation is possible reflects the strong relationship
between ISO/IEC 15288 and the domains. This is
particularly true for the systems engineering
domain, which has recently aligned the INCOSE
Systems Engineering Handbook explicitly with
ISO/IEC 15288 [4].
In this paper we are interested principally in the
relationship between the project management
domain and ISO/IEC 15288. To do so we use the
PMBOK® Guide as an example of standard
processes in the project management domain [2].
Agreement
Processes
Acquisition
Process
Deliverables
that satisfy
an
agreement
Organisational Project-Enabling Processes
Project Portfolio Management Process
Used to
establish
requirements
Human
Resource
Management
Process
Supply
Process
Infrastructure
Management
Process
Quality
Management
Process
Assess
quality &
progress
Provide enabling resources & infrastructure; create,
support & monitor projects; assess effectiveness
Used to
arrive at &
satisfy an
agreement
Project Processes
Information Mgt Process
Risk Mgt Process
Process
Assessment &
Control
Process
SYSTEM OF
INTEREST
Life Cycle
Model
Management
Process
Ensure adequate planning, assessment & control activities are
performed to manage processes and life cycle stages.
Stakeholder
Requirements
Definition Process
Technical Processes
Validation
Process
Transition
Process
Requirements
Analysis
Process
Architectural
Design Process
Operation
Process
Disposal
Process
Maintenance
Process
Operation & Support
Verification
Process
Used to create
products and
services of life cycle
stage that meet
requirements
Decision Mgt
Measurement
Process
Planning Process
Manage
life cycle
stages
Outcomes
used to
assess
progress
Configuration Mgt Process
Integration
Process
Implementation
Process
Legend:
Business
Project Management
Systems Engineering
Bus/Proj Mgt/Sys Eng
Operations
Figure 2 - Top-Level Diagram for ISO 15288:2008 - Principal Domain Responsibilities
The Guide to the Project Management
Body of Knowledge (PMBOK® Guide)

Project Time Management,

Project Cost Management,
The PMBOK® Guide describes established norms,
methods, processes and practices, and is
acknowledged as evolving from the recognised
good practices of project management practitioners
who contributed to its development [2].

Project Quality Management,

Project Human Resource Management,

Project Communications Management,

Project Risk Management, and

Project Procurement Management.
The PMBOK® Guide’s structure comprises four
main sections plus seven supporting appendices.
The four main sections are:

Section 1 – Introduction

Section 2 – The Standard for Project
Management of a Project;

Section 3 – The Project Management
Knowledge Areas; and

Section 4 – Appendices and Glossary.
The focus of this paper is on Section 3, the Project
Management Knowledge Areas which are:

Project Integration Management,

Project Scope Management,
At this level of detail, meaningful relationships can
be identified between the content of the PMBOK®
Project Management Knowledge areas and the
content of the ISO/IEC 12588 life cycle processes.
Figure 2Figure 2 shows how the PMBOK® Project
Management Knowledge areas (yellow-coloured
boxes) map onto the ISO/IEC 15288 life cycle
processes at a summary or top-level. The next
section explains the basis of this mapping, that is,
how the individual PMBOK® Project Management
Knowledge areas map onto the individual life cycle
processes of ISO/IEC 15288.
Mapping the PMBOK® Guide to
ISO/IEC 15288
project milestones, competent staff,
ownership, clear vision and objectives,
and hard-working focused staff. Almost
all of these success criteria are arguably
the responsibility of business
management, not project management.
The principal causes of failure of a project
are therefore largely outside the control of
the project manager (as defined by the
PMBOK®). The interface between
business management and project
management is therefore particularly
important.
Figure 1Figure 1 shows generically that a number
of domains contribute to the development of a
project over time. ISO/IEC 15288 refines this idea
by identifying the system life cycle processes
required to deliver a system and implying a
relationship between particular domains and
processes groups.
Figure 2Figure 2 shows an explicit mapping
between processes and domains. The relationship
between the project management domain and
ISO/IEC 15288 is indicated by the yellow boxes in
Figure 2Figure 2.
Table 1Table 1 now shows the direct relationship
between individual PMBOK® Knowledge Areas (at
level 2 detail) and individual ISO/IEC 15288 life
cycle processes. This relationship is identified
through examining and comparing the content of
the PMBOK® Knowledge Areas and the ISO/IEC
15288 life cycle processes at lower levels of detail.
Table 1Table 1 identifies that there is a relationship
between three of the four ISO/IEC 15288 process
groups and the PMBOK® knowledge areas, namely
in: Agreement Processes, Project Processes, and
Technical Processes. There is no overlap with the
Organisational Project-Enabling Processes.
The strong relationships between the PMBOK®
Knowledge Areas and the two ISO/IEC 15288
process groups of Project Processes and Agreement
Processes are not surprising, given the focus of the
PMBOK® Guide. Interestingly, the PMBOK®
Guide refers to both ‘sellers’ and ‘buyers’ in terms
of acquisition but focuses only on the ‘buyer’,
stating that ‘this chapter assumes that the buyer of
items for the project is assigned to the project team
and that the sellers are organisationally external to
the project team [2]; in effect this ignores the
‘supply agreements’ component of the ISO/IEC
15288 Agreement Processes, but with a little
additional effort this could be included in the
PMBOK® Guide. It is useful, however, to
examine the other relationships a little further.

That there is no mapping between
Organisational-Enabling Project-Enabling
Processes and the PMBOK® Knowledge
Areas seems at first glance to be logical
given the ongoing nature of the
Organisational Project-Enabling
Processes, which are the responsibility of
business management, not project
management. However, a recent Chaos
report [5] identified the top ten project
success factors as: user involvement,
executive management support and buy in,
clear statement of requirements, proper
planning, realistic expectations, smaller

There is an overlap between the project
management and systems engineering
domains in regard to the ‘identify
stakeholder requirements’ within
Technical Processes. This overlap makes
sense in that both must be involved, as
must business management. A clear
statement of requirements is arguably the
most essential task in achieving success. If
there are three domains responsible, clear
description of detailed responsibilities is
essential (but not evident in the bodies of
knowledge of any of the domains):
o
The systems engineering domain
acknowledges, as part of the
‘stakeholder requirements
definition process’, the need to
support program and project
management in defining what
must be done and gathering the
information, personnel, and
analysis tools to define the
mission or program objectives.
Eliciting and capturing
requirements is seen to be a
significant effort on the part of
the systems engineer. [4].
o
The Business Analysis Body of
Knowledge [6] covers much the
same areas as systems
engineering and project
management in regard to
identifying stakeholder
requirements but also defines a
business analyst as any person
who performs business analysis
activities, which includes but is
not limited to systems analysts,
requirements engineers, and
project management. [6]. It
therefore does not specifically
allocate the responsibility for
requirements elicitation to any
particular domain.
o
The PMBOK® Guide specifically
includes the collection of
requirements as part of its scope
management knowledge area.
Systems engineering is
mentioned only in passing as a
tool to help conduct product
analysis as part of the scope
management knowledge area,
albeit product analysis is limited
to those projects that have a
product as a deliverable, versus a
service or result [2]. This view of
the minimal contribution of
systems engineering to the
delivery of complex technical
systems is not aligned with the
detailed and comprehensive
perspective outlined in the
INCOSE Systems Engineering
Handbook [4].
Table 1 ‐ Mapping of PM Processes to ISO/IEC 15288:2008
Technical
Processes
Clause 6.3.7
Clause 6.4.1
Measurement Process
Stakeholder
Requirements
Definition Process
Clause 6.3.6
Clause 6.3.5
Clause 6.3.4
Clause 6.3.2
Project Assessment &
Control Process
Clause 6.3.3
Clause 6.3.1
Project Planning
Process
Decision Management
Process
Risk Management
Process
Configuration
Management Process
Information
Management Process
Clause 6.1.2
Supply Process
Project Processes
Clause 6.1.1
PMBOK® Knowledge Areas
Agreement
Processes
Acquisition Process
ISO/IEC Life Cycle Processes
4 Project Integration
Management
4.1 Develop project charter
4.2 Develop project management
plan
4.3 Direct &manage project
execution
1
1
1
4.4 Monitor & control work
4.5 Perform integrated change
control
1
4.6 Close project or phase
1
1
1
5 Project Scope Management
5.1 Collect requirements
1
5.2 Define scope
1
5.3 Create WBS
1
5.4 Verify scope
1
5.5 Control scope
1
6 Project Time Management
6.1 Define activities
1
6.2 Sequence activities
1
6.3 Estimate activity resources
1
6.4 Estimate activity durations
1
6.5 Develop schedule
1
Technical
Processes
Clause 6.3.7
Clause 6.4.1
Measurement Process
Stakeholder
Requirements
Definition Process
Clause 6.3.6
Clause 6.3.5
Clause 6.3.4
Clause 6.3.2
Project Assessment &
Control Process
Clause 6.3.3
Clause 6.3.1
Project Planning
Process
6.6 Control schedule
Decision Management
Process
Risk Management
Process
Configuration
Management Process
Information
Management Process
Clause 6.1.2
Supply Process
Project Processes
Clause 6.1.1
PMBOK® Knowledge Areas
Agreement
Processes
Acquisition Process
ISO/IEC Life Cycle Processes
1
7 Project Cost Management
7.1 Estimate costs
1
7.2 Determine budget
1
7.3 Control costs
1
8 Project Quality Management
8.1 Plan quality
1
8.2 Perform quality assurance
1
8.3 Perform quality control
9 Project Human Resource
Management
1
9.1 Develop human resource plan
1
9.2 Acquire project team
1
9.3 Develop project team
1
9.4 Manage project team
10 Project Communications
Management
1
10.1 Identify stakeholders
1
10.2 Plan communications
1
10.3 Distribute information
10.4 Manage stakeholder
expectations
1
1
10.5 Report performance
1
11 Project Risk Management
11.1 Plan risk management
1
11.2 Identify risks
11.3 Perform qualitative risk
analysis
11.4 Perform quantitative risk
analysis
1
1.5 Plan risk responses
1
11.6 Monitor & control risks
12 Project Procurement
Management
1
1
1
1
12.3 Administer procurement
1
12.4 Close procurements
1
Alignment of the PMBOK® Guide to
ISO/IEC 15288
The result of increased utility of the PMBOK®
might then be characterised by a number of
desirable features, including the following:

The international nature of the ISO/IEC
15288 standard, and the alignment by
other domains such as systems
engineering, suggests that there would be
a wider spread of the potential users of
both the standard, and the PMBOK®
Guide. More importantly, the project
management profession could contribute
Clause 6.3.7
Clause 6.4.1
Measurement Process
Stakeholder
Requirements
Definition Process
Clause 6.3.6
Clause 6.3.5
to and influence the future development of
ISO/IEC 15288.

A wider type of potential users could also
benefit from the alignment of the
PMBOK® Guide to ISO/IEC 15288, that
is, the PMBOK® Guide could meet an
objective of being able to ‘facilitate
communication among acquirers,
suppliers and other stakeholders’ [1], thus
appealing to a broader user community.
This broader community could include
non-project management domains such as
systems engineering, engineering,
operations and business analysis.

The project management profession would
also be contributing to a major goal of
ISO/IEC 15288 which is, in part, to
‘enable [the] user community to evolve
towards fully harmonized standards’ [1].
ISO/IEC 15288 is a higher-level broad guidance
document, and already the systems engineering
domain has aligned its body of knowledge with
ISO/IEC 15288. This paper has shown that there is
a clear and strong relationship between ISO/IEC
and the PMBOK® Knowledge Areas, so alignment
to ISO/IEC 15288 could be incorporated into future
development of the PMBOK® Guide. There are a
number of reasons why such alignment might be
worth pursuing.
The systems engineering domain identifies a
number of drivers for its alignment to ISO/IEC
15288, the principal rationale being to ensure its
usefulness across a wide range of application
domains – man‐made systems and products, as well
as business and services [1]. This rationale seems
consistent with the intent of the PMBOK® Guide,
and a reasonable basis for its future development.
Clause 6.3.4
Clause 6.3.2
Project Assessment &
Control Process
12.2 Conduct procurements
Clause 6.3.3
Clause 6.3.1
Project Planning
Process
1
Decision Management
Process
Risk Management
Process
Configuration
Management Process
Information
Management Process
Clause 6.1.2
Supply Process
12.1 Plan procurements
Technical
Processes
Project Processes
Clause 6.1.1
PMBOK® Knowledge Areas
Agreement
Processes
Acquisition Process
ISO/IEC Life Cycle Processes
At a lower-level of significance perhaps, but
nonetheless valuable, alignment of the PMBOK®
Guide to ISO/IEC 15288 provides a pathway to
improving project communication. Much confusion
is caused through the use of inconsistent
terminology between different domains, guides and
standards. Alignment could support an aim of
reducing confusion through adoption of more
consistent terminology between the documents.
Conclusion
The full benefit of rapid communications
connectivity will not be realised until there is
seamless connectivity between all those responsible
for the delivery of a project. The seamless
integration of effort is seriously hampered by the
lack of a universally agreed set of responsibilities
for all those involved in project delivery,
particularly the domains of business management,
project management, systems engineering, and
operations. The ISO/IEC 15288 standard provides a
useful framework within which the various
responsibilities can be illustrated.
In the case of project management, the visualisation
of ISO/IEC 15288 can be used to illustrate how the
knowledge areas of project management (as
outlined in the PMBOK® Guide) map on to the
standard and to show how the principal
responsibilities of the project management domain
differ from those of business management, systems
engineering, and operations.
References
[1] ISO/IEC 15288:2008(E), IEEE Std 152882008, Systems and software engineering—System
life cycle processes.
[2] ANSI/PMI 99-001-2008. A Guide to the Project
Management Body of Knowledge (PMBOK®
Guide). PMI Global Standard.
[3] B.L. Jones and M.J. Ryan, “ISO/IEC
15288(E)—Visual Enhancement for Effective
Communication”, Systems Engineering, Test and
Evaluation Conference, SETE2010, Canberra, 2–4
May 2010.
[4] INCOSE Systems Engineering Handbook, A
guide for system life cycle processes and activities,
INCOSE-TP-2003-002-03.2, January 2010.
[5] Chaos Summary 2009, The Standish Group.
[6] A Guide to the Business Analysis Body of
Knowledge® (BABOK® Guide) Version 2.0.
International Institute of Business Analysis,
Toronto, Ontario, Canada, 2009.
View publication stats