BPL Guidance V1.1.1

Base Process Library –
Guidance
TickITplus
Version 1.1.0
Dave Wynn and Peter Lawrence

Reviewed by JTISC
First published in the UK in 2012
by
BSI Standards Limited
389 Chiswick High Road
London W4 4AL
© The British Standards Institution 2012
All rights reserved. Except as permitted under the Copyright, Designs and Patents Act 1988,
no part of this publication may be reproduced, stored in a retrieval system or transmitted in
any form or by any means – electronic, photocopying, recording or otherwise – without prior
permission in writing from the publisher.
While every care has been taken in developing and compiling this publication, BSI accepts no
liability for any loss or damage caused, arising directly or indirectly in connection with reliance
on its contents except to the extent that such liability may not be excluded in law.
While every effort has been made to trace all copyright holders, anyone claiming copyright
should get in touch with the BSI at the above address.
BSI has no responsibility for the persistence or accuracy of URLs for external or third-party
internet websites referred to in this book, and does not guarantee that any content on such
websites is, or will remain, accurate or appropriate.
Typeset in Calibri by Helius
British Library Cataloguing in Publication Data

A catalogue record for this book is available from the British Library
ISBN 978 0 580 78381 4
© BSI 2012 Version 1.1.0

Contents
Acknowledgements 8
Introduction 9
The purpose of this guide 12
The structure of the Base Process Library 12
Process descriptions 14
Human Resource Management 15

BP.1 Establish Human Resource Policies and Procedures 16
BP.2 Identify the Required Human Resources 17
BP.3 Satisfy Human Resources Requirements 17
BP.4 Allocate Human Resources 18
BP.5 Induct Human Resources 19
BP.6 Assess Human Resource Performance 19
BP.7 Develop Human Resources 20
BP.8 Benefit from the Subject Matter Expert 20
Management Framework 21
BP.1 Establish Management Framework Policies 23
BP.2 Establish an IMS 24
BP.3 Audit IMS Compliance 25
BP.4 Collect, Analyse and Use Measures 26
BP.5 Schedule and Hold Reviews 26
Corporate Management and Legal 27

BP.1 Identify Business Needs and Objectives 29
BP.2 Establish Business Plan 30
BP.3 Establish Management Framework 31
BP.4 Manage the Organization 31
BP.5 Manage Business Performance 32
© BSI 2012 Version 1.1.0 3

TickITplus – Base Process Library – Guidance
Infrastructure and Work Environment Management 33

BP.1 Establish Infrastructure and Working Environment
Policies 34
BP.2 Identify Infrastructure and Work Environment
Needs 34
BP.3 Establish and Manage Infrastructure 35
BP.4 Disposal of Infrastructure 36
Improvement 36
BP.1 Establish Policies and Procedures for Improvement 38
BP.2 Analyse Improvement Opportunities 39
BP.3 Implement the Improvement 40
BP.4 Monitor and Review 41
Measurement and Analysis 41

BP.1 Define Measurement and Analysis Policy and
Procedures 43
BP.2 Identify Measurement Objectives and Data 44
BP.3 Collect and Analyse Measurement Data 45
BP.4 Use Measurement Information 46
Customer Focus 47
BP.1 Establish Business Relationship Framework 48
BP.2 Establish Customer Focused Procedures 50
BP.3 Collect and Analyse Customer Feedback 52
BP.4 Review Relationship 53
Risk Management 54
BP.1 Define Risk Management Procedure 56
BP.2 Establish Risk Management Plan 57
BP.3 Identify and Analyse Risks 57
BP.4 Track Risks 58
BP.5 Report Status and Escalate 58
BP.6 Analyse Risk Management Performance 59
4 © BSI 2012 Version 1.1.0

Contents
Lifecycle Model Management 59

BP.1 Establish Lifecycle Model Management Policy
and Procedures 61
BP.2 Identify the Need for a Lifecycle Model 62
BP.3 Define the Lifecycle Model 63
BP.4 Pilot 64
BP.5 Review the Lifecycle Model 65
Project Management 65
BP.1 Establish Project Management Policies and
Procedures 67
BP.2 Scope the Project 68
BP.3 Plan the Project 69
BP.4 Initiate the Project 71
BP.5 Monitor and Control the Project 72
BP.6 Manage Risks and Issues 73
BP.7 Manage Changes to the Project 74
BP.8 Close the Project 75
Configuration and Change Management 75

BP.1 Establish a Configuration and Change
Management Policy and Procedures 77
BP.2 Plan Configuration and Change Activities 78
BP.3 Establish Configuration and Change Management
System 79
BP.4 Manage Configuration Items 80
BP.5 Manage Baselines 80
BP.6 Manage Changes 81
Problem and Incident Management 83

BP.1 Define Problem and Incident Management
Policies and Procedures 84
BP.2 Record and Manage Incidents 85
BP.3 Avoid and Resolve Problems 86
BP.4 Escalate Incidents and Problems 87
© BSI 2012 Version 1.1.0 5

Data and Record Management 88

BP.1 Establish Data Policies and Procedures 90
BP.2 Identify Data 90
BP.3 Review Data 91
BP.4 Approve and Store Data 92
BP.5 Control Data Changes 93
BP.6 Archive and Dispose of Data 93
BP.7 Establish Record Management Policies and
Procedures 94
BP.8 Identify Records 94
BP.9 Manage Records 95
BP.10 Record Disposal 95
Integration Management 96
BP.1 Define Integration Plan 97
BP.2 Establish Integration Environment 99
BP.3 Assemble Product 100
BP.4 Verify the Product 101
Verification 102
BP.1 Establish Verification Procedure 103
BP.2 Plan Verification Activities 104
BP.3 Conduct Verification Activities 105
BP.4 Review the Effectiveness of the Verification 105
Validation 106
BP.1 Establish Validation Procedure 108
BP.2 Plan Validation Activities 108
BP.3 Conduct Validation Activities 109
BP.4 Review Validation Effectiveness 110
Transition and Release Management 111

BP.1 Establish the Transition and Release Policy
and Procedures 112
6 © BSI 2012 Version 1.1.0

Contents
BP.2 Plan for Release 113

BP.3 Verify Operational Environment 114
BP.4 Validate the Product 114
BP.5 Release the Product for Use 116
Maintenance Management 117

BP.1 Define the Maintenance Policy and Procedures 119
BP.2 Plan the Maintenance 120
BP.3 Undertake the Maintenance 122
BP.4 Deploy the Maintained Product 124
Stakeholder Requirements Definition 124

BP.1 Engage Requirements Stakeholders 126
BP.2 Develop Stakeholder Requirements 127
BP.3 Validate Stakeholder Requirements 128
BP.4 Manage Changes to Stakeholder Requirements 129
Requirements Analysis 130

BP.1 Develop System Requirements 131
BP.2 Estimate System Requirements Size 132
BP.3 Manage System Requirements 132
BP.4 Manage Changes to Requirements 133
Architectural Design 133

BP.1 Establish Development Approach 135
BP.2 Create Architectural Design 136
BP.3 Review Architectural Design 137
BP.4 Manage Architecture Changes 138
Development Implementation 138

BP.1 Establish the Development Environment 140
BP.2 Identify Component Sources 141
BP.3 Design Components 142
BP.4 Implement Components 143
BP.5 Manage Design and Implementation Changes 144
© BSI 2012 Version 1.1.0 7

Acknowledgements
The authors would like to thank Irene Dovey (Nexor), Phil Willoughby (LRQA) and John
Davenport (Tata) for their contributions to the development of this book and the many
hours we’ve spent together reviewing the content. Thanks also go to members of the JTISC
committee, who provided insightful and constructive feedback.
8 © BSI 2012 Version 1.1.0

Introduction
Introduction
The TickIT project was establish in 1991 with the goal of introducing more effective quality
management practices in the software development industry. The project also provided
a defined framework and supporting guidelines for managing software development
quality, along with more formal and specific certification procedures. These were intended
to help organizations interpret the requirements of ISO 9001 (Quality management) in a
software development context. A major achievement of the project was to establish formal
accreditation of certification bodies in the software sector, supported by formal standards
for training, competency and registration of IT auditors. The TickIT scheme has brought
real benefits to the IT sector, with many IT and software development organizations
achieving certification to ISO 9001 through the scheme. This allows them to use the TickIT
accreditation markings as part of their ISO 9001 approval, providing a tangible statement of
their commitment to software quality.
While the TickIT scheme has certainly helped to establish more formal quality management
approaches within the software sector, the industry has moved on. For example, the internet
is now a major influence in both the business and public sectors and affects many aspects
of almost everyone’s daily life, providing unprecedented opportunities for commerce,
education, technology and so on. These advances will continue to have a profound influence
on business, as well as public service, and the home environment.
Computer systems no longer operate as independent stand-alone units, but will work
together as a global network where a vast number and wide variety of systems are
simultaneously connected and exchanging information. Many systems, including home
computers, now have a permanent connection to the internet via broadband communication
networks. As a result, systems are engaged in continuous and complex dialogue with all
other systems connected to the information superhighway. In the home, software agents
work transparently, downloading media, such as videos, music files and information,
specifically selected and tailored to suit the tastes of the user. Agents and other software
modules, automatically supplied across the network, adjust and optimize the behaviour of
our home computer systems and other domestic equipment they control.
Controllers governing the supply of water, gas and electricity are also ‘getting connected’,
allowing suppliers to monitor the status of equipment for efficiency and faults, as well
as recording usage for billing purposes. In business, computer and communication
technologies continue to develop, providing improved efficiency through ‘electronic
commerce’ (e-commerce), and thereby simplifying supply chain processes while providing
a more effective and open market for products and services.
© BSI 2012 Version 1.1.0 9

The accelerating demand for computer technology has placed an increasing strain on
the software industry. Software developers are now required to operate in much shorter
development cycles, with suppliers compelled to look for new software development
methods that will enable them to keep pace with the market and ahead of competitors.
The proliferation of computer systems and the pressure to maintain competitive advantage
through the application of new technologies means that we are becoming increasingly
dependent on the quality of the software that is at the centre of the information revolution.
The need for effective software development processes, bringing advantages in terms of
cost, productivity and quality, has, therefore, never been greater.
The IT market has also changed, with many businesses choosing to outsource their IT
services to gain greater value and opportunity from their IT investment. IT standards have
also evolved to keep pace with the changes in the industry. Management of software
quality is still vital, but continued growth in the power and complexity of computer systems
means a broader series of practices, covering areas such as IT services, and security, are
necessary to ensure effective and reliable services. Perceptions of the role and value of
IT certification schemes has also developed in recent years. Organizations typically regard
certification to ISO 9001 as the minimum standard for IT providers. Customers are now
seeking broader assurances from their service providers that they are able to meet their
needs, while IT suppliers are looking for opportunities to differentiate their services and
capabilities. Attention has therefore moved towards effective process management and,
more particularly, objective demonstration of capabilities.
The new TickITplus scheme was launched in early 2011. The new scheme has been
developed by members of the Joint TickIT Industry Steering Committee (JTISC). The
committee, comprising representatives from the IT industry and other IT interest groups, was
established in 2006 under the British Standards Institution’s Standards Policy and Strategy
Committee; with prime responsibility for standardization, international harmonization,
certification and accreditation for the IT industry. The changing IT landscape has been a
major influence in the development of the new scheme, with the publication of a range of
IT standards such as ISO/IEC 20000 (Information technology – Service management) for IT
services and ISO/IEC 27001 (Information technology – Security techniques – Information
security management systems – Requirements) for information security. While there are
significant variations between these standards, there are also common themes and a key
objective of the TickITplus scheme is to provide an integrated framework to combine the
latest IT standards, while simplifying assessment and certification.
The TickITplus scheme also addresses the changing needs of IT certification by providing
tools, techniques and methods to undertake capability assessment, within a common
10 © BSI 2012 Version 1.1.0

Introduction
certification framework, leading to formal recognition of an organization’s process

capability and maturity. This, it is hoped, will encourage IT providers to seek best value and
performance from their management systems and processes. While ISO 9001 has always
encouraged definition, implementation and improvement of a company’s core processes,
the TickITplus scheme builds on this foundation – providing additional formality and rigour
in formally assessing both the effectiveness and maturity of an organization’s processes. So,
as a certified organization matures, emphasis changes from assessing ‘compliance’ towards
measurement, process control and formal improvement. In essence, the company moves
from ‘conformance’ to ‘performance’.
Organizations adopting the TickITplus scheme are assessed and rated on a maturity scale
comprising five discrete levels. The five maturity levels are consistent with the requirements
specified in ISO/IEC 15504 (Software process improvement and capability determination),
also known as SPICE, which provides a comprehensive framework for the assessment
of processes. In ascending order, the ratings are classified as Foundation, Bronze, Silver,
Gold and Platinum. Foundation, the lowest rating, is determined through compliance with
base practices and conventional audit, whereas the Bronze through Platinum ratings are
gained through evaluation of process capability and demonstration of systematic process
improvement. The Foundation level provides a straightforward opportunity for existing
TickIT-certified IT organizations to transfer to the TickITplus scheme. Higher grades of
maturity encourage the organization to drive towards improved capability, while formally
acknowledging their commitment to quality and performance. The five maturity levels are
illustrated in Figure 1.
Foundaon Bronze Silver Gold Planum

Entry point for The first level of The second level The third level of The highest level of
organizaons rated process of rated process rated process rated process
transioning capability capability capability capability
from exing
TickIT approvals Compliant Process Process Processes are
processes are standardizaon measurement and opmizing
established is achieved control is achieved
e
rmanc
Perfo
e
rmanc
Confo
Connual improvement achieved through standardizaon, measurement and analysis
Figure 1: Overview of the TickITplus maturity levels
© BSI 2012 Version 1.1.0 11

The purpose of this guide
The heart of the TickITplus scheme comprises a process model called the Base Process
Library (BPL). The BPL comprises a series of process definitions, around 40 in all, which
are intended to unify the requirements of the most common certification standards into a
single framework. The BPL has been developed from the structures within ISO/IEC 12207
(Systems and software engineering – Software life cycle processes) and ISO/IEC 15288
(Systems and software engineering – System life cycle processes) and is heavily influenced
by ISO/IEC 15504-4 (Information technology – Process assessment – Guidance on use for
process improvement and process capability). However, the structure has been extensively
re-modelled to accommodate the requirements of current certification standards.
The requirements of the BPL are specified in a separate document. This guide is intended to
explain the objectives and requirements of each process in more detail and provide guidance
on how each practice within the processes should be implemented. This guide should,
therefore, be read in conjunction with the BPL. It is stressed, however, that this document
is provided as guidance only. The structure and implementation of any organization’s
management system must be driven, first and foremost, by the business needs, rather
than the reference standards that are being used for assessment. It is likely, therefore, that
individual requirements in the BPL and corresponding explanations within this guide may
be addressed through a range of possible processes, procedures, standards, etc., within
any given organization. Indeed, a key step in the assessment process is to prepare a Process
Reference Model (PRM) that maps the organization’s processes and practices against the
BPL. This allows compliance to be demonstrated irrespective of the nature and structure of
the organization’s management system.
The structure of the Base Process Library
The 40 processes contained within the BPL are arranged into six process categories, where
each category comprises a group of related processes. The groups include:
• Organizational process (ORG) – focusing on level – and organization-wide activities

• Project processes (PRJ) – covering activities relating to setting-up and running projects
• Technical processes (TEC) – addressing technical activities
• IT Specific processes (ITS) – covering specific IT activities
• Agreement processes (AGR) – dealing with contractual, procurement and supply-related
activities
12 © BSI 2012 Version 1.1.0

Introduction
• Maturity processes (MAT) – which address the measurement and improvement activities
relating to other processes as part of maturity evaluation.
The groups are intended to provide a systematic structure to the BPL, and do not have a
direct bearing on assessment. However, an important feature of the BPL is the way in which
each process is classified. Processes are mapped to one of four classes according to their
alignment with the source standards. The four classifications are as follows:
• Type A includes all the processes required to meet the basic requirements of ISO 9001.
So, for example, this would include Management Framework, Human Resource
Management, Improvement, etc. – that are not necessarily IT related, but core to an
effective management system.
• Type B includes all the processes that are required to address the scope – and as such
will meet the requirements of any additional standards covered by the certification,
including the scope-related ISO 9001 requirements.
• Type C are the supporting processes, which are not directly defined in the scope, but are
nevertheless important to its successful outcome – these would include, for example,
processes supporting an IT network that may not necessarily appear as part of the scope,
but should still be formalized.
• Type M is the final category and accommodates the two processes that describe the
measurement and quantitative techniques that need to be applied at the higher grades
(Gold and Platinum) of TickITplus assessment.
In practice, the BPL combines B/C processes into a single grouping. Final classification
of the B/C processes as either Type B or Type C is determined by the certification scope.
An organization assessed within the TickITplus scheme would, as a minimum, have to
demonstrate compliance to all Type A processes – as these are mandatory – along with
compliance with any additional Type B processes that are applicable to the scope of the
organization’s approval. In practice, this changes very little from current certification
approaches. However, the BPL and the supporting predefined Scope Profiles (included in
the scheme) provide an opportunity for much greater consistency in the application of
standards across the IT sector. Type M processes are only applied at the highest levels of
maturity, where an organization is able to demonstrate use of statistical methods to achieve
optimizing processes.
Another important feature of the BPL is the way in which the defined processes map to the
scope of certification. The TickITplus scheme defines eight Scope Profiles that have been
designed to cover a wide spectrum of IT-related organizational activities. These range from
© BSI 2012 Version 1.1.0 13

the development and maintenance of IT systems and software, to providing an IT-related

service and ensuring security in IT systems. The Scope Profiles are predefined templates
that specify the group of interrelated processes within the BPL that are relevant to the
TickITplus scope chosen by the organization. The eight predetermined Scope Profiles cover:
• Information Management and Security

• Service Management
• Systems and Software Development and Support
• Project and Programme Management
• Corporate Strategy Planning and Management
• Legal and Compliance
• Product Validation, Quality and Measurement
• IT Systems Engineering and Infrastructure.
It is anticipated that these eight Scope Profiles address all but the most specialized services
undertaken by IT organizations.1
Process descriptions
The requirements for each process are contained within the main body of the BPL. Each
process description includes an identification reference, the process name, its category,
type and overall purpose. The description then provides one or more process outcomes,
along with a series of related requirements that are intended to achieve each outcome.
Each requirement also lists typical inputs and outputs and a cross reference to applicable
base standards, such as ISO 9001.
Process outcomes are considered to be the ‘stretch objectives’ that the process is intended
to address. As such, they are intended to establish a goal to which the organization should
aspire, thereby stimulating ongoing process improvement, rather than being a check-box
that marks compliance. In practice, for example, an organization may demonstrate that
its working practices comply with each requirement for a given process, but there is still
1
Important note: Issue 1 of the BPL and guidance material cover the Systems and Software Development and
Support Scope Profile only. This corresponds with the scope of the existing TickIT scheme and provides a sufficient
definition for organizations to transfer their current TickIT approvals to the TickITplus scheme at Foundation level.
Further processes and Scope Profiles will be provided in subsequent releases of the BPL.
14 © BSI 2012 Version 1.1.0

Human Resource Management
opportunity to drive systematic improvement to achieve better performance with respect

to the process outcomes. This structure is intended to encourage organizations to formalize
their process improvement programmes and demonstrate tangible improvement leading
to high levels of process maturity. This guide therefore provides a brief explanation of
each process and its outcomes, along with guidance on how each requirement can be
implemented.
The purpose of the Human Resource Management process is to ensure that the
organization has the appropriate level of staff needed to implement the strategies and
objectives identified in the business plan. It also ensures that staff have the right skills to
carry out their role and that regular performance reviews are undertaken. Where there
is a shortfall in performance, the Human Resource Management process ensures there is
a mechanism in place that will support the organization in carrying out corrective action
and helps the individual achieve a satisfactory level of performance. Within the Human
Resource Management process there should be assurance that statutory and regulatory
requirements are adhered to.
The process for identifying appropriate resources should be conducted in an open and clear
manner. In most cases it will be necessary to consider the resource planning some time
ahead to ensure that the right resource is in place when required. For this to be performed
successfully, future workload, or sales pipeline information needs to be available in
the business and to be made available to the group or groups seeking to fulfil resource
requirements.
While many organizations have a defined group for managing human resources, for example
the personnel department or the human resource department, the practices defined
within the TickITplus Human Resource Management process will invariably involve many
organizational groups, including specifically senior management, sales and marketing,
future business development, projects and service delivery groups, etc.
Measurements and metrics have a vital part to play in aiding the organization to ensure that
it is optimizing its resources in terms of areas of, for example, attendance and performance
levels. These types of reporting may be done on a department by department basis, but an
effective organization would also be looking at a company-wide basis over a period of time.
© BSI 2012 Version 1.1.0 15

When Human Resource Management is implemented to a satisfactory level the organization

will have staff who are appropriately skilled and who understand the requirements of their
role, while overall the outcome is that the organization is able to deliver against its business
plan. There should be no evidence of shortfall in resourcing, which could have a detrimental
impact on the organization’s capability to ensure that business needs, and customer and
stakeholder satisfaction, are met. While the defined outcome specifically states that there
should be ‘no evidence of shortfall in resourcing’, like other outcomes in TickITplus, this
is a goal, not a mandated requirement. It is recognized that resourcing issues will arise,
for example, through unexpected resignations, illnesses or unexpected work requests, but
with appropriate practices the impact of these will be small.
There are eight base practices defined in the BPL Human Resource Management process
that provide the framework for the identification, allocation and development of human
resources. These are:
BP.1 Establish Human Resource Policies and Procedures

BP.2 Identify the Required Human Resources
BP.3 Satisfy Human Resources Requirements
BP.4 Allocate Human Resources
BP.5 Induct Human Resources
BP.6 Assess Human Resource Performance
BP.7 Develop Human Resources
BP.8 Benefit from the Subject Ma er Expert.
BP.1 Establish Human Resource Policies and Procedures
To ensure that the organization has the right level of resource with the necessary skill
sets, there must be an understanding of what is required to meet current and future
organization needs. The organization should ensure that clear policies for managing human
resources are set by top management to provide the framework to ensure that human
resources practices are fully and adequately deployed. Examples of policies could include
those covering recruitment, absence, travel and expense, and disciplinary, etc. While in
some cases the existence of well-defined and well-communicated policies may be all that
is necessary, in other cases there will be a need to support the policies with clearly defined
procedures. The policies typically define the acceptable boundaries in which people can
work, whereas procedures, with associated work instructions, provide standard approaches
to implementing the polices.
16 © BSI 2012 Version 1.1.0

While developing Human Resource Management policies and procedures, consideration

should be given to statutory, regulatory and security aspects that may impact the business.
For example, statutory aspects will include disciplinary, grievance and redundancy
legislation, maternity and paternity entitlements, etc. Regulatory aspects may include, for
example, legal restrictions or industry self-regulation. Security requirements may include
physical security or aspects of confidentiality, integrity and availability of information.
Policies and procedures should be reviewed regularly to take into account any changes
either within the organization or to statutory, regulatory and security requirements.
BP.2 Identify the Required Human Resources
The key to providing adequate levels of skilled resource is to consider what is needed to
deliver the required current and, more importantly, future business performance goals.
This will require information being sought from all stakeholders, such as top management,
management involved directly in delivering the business objectives and supporting
functions, such as finance, sales and marketing, IT, and the human resource group itself.
Once the resourcing needs have been established they should be reviewed and approved
by the relevant stakeholders and authorities, which may include gaining financial approval
to proceed. Approved resourcing needs should then be communicated to those who have
responsibilities for ensuring that the needs are satisfied, typically, although not always,
overseen by a central group such as the human resources department.
To achieve the desired resource needs, various approaches may have to be considered,
including recruitment, either full-time, part-time or contracted, and role change,
development or redundancy.
BP.3 Satisfy Human Resources Requirements
The organization should initially consider if development of current staff may be used to fulfil
resourcing requirements. Development activities may include, for example, formal training,
computer-based training, mentoring, and allowing work time to study. Development
objectives should be identified before the activity takes place and evaluated afterwards
(see BP.6 Assess Human Resource Performance). Individual development plans should be
put in place and records maintained.
© BSI 2012 Version 1.1.0 17

If additional resourcing is required, there may be a need to undertake a recruitment

programme. This should include advertising, interviewing, screening, assessment and
selection, with formal communication of the results to both candidates and appropriate
staff. New members of staff agree and sign terms and conditions of their employment,
which should include, for example, both their and the organization’s responsibilities for
information security.
If a redundancy programme is required, applicable legislation must be considered to ensure

the appropriate level of consultation, with fair and equitable selection criteria, is being used.
When, as part of satisfying the human resource needs, staff leave the organization, the
organization should ensure that all appropriate statutory aspects are covered, that
organizational assets are returned and security implications are addressed in a timely
manner, e.g. all access rights are revoked.
BP.4 Allocate Human Resources
The organization should operate with the level of resource required in order for business
needs and objectives to be met in a timely manner. Where the organization identifies a
need that cannot be fully satisfied, for example, due to lack of available staff or missing
skills, the gap is identified and managed either through development or recruitment (see
previous practices in this process).
Once the human resource requirements have been satisfied, it is necessary to ensure that
the resources are adequately allocated against the identified need. This involves ensuring
that staff roles, responsibilities and objectives are clearly established, documented and
agreed.
There are a number of approaches used to define and document staff roles, responsibilities
and objectives. For example, the classic ‘job description’ or ‘terms of reference’ are often
used to define the role and responsibilities of individuals, although in some cases these can
be assigned through a more general approach such as through a project plan. Whichever
approach is adopted, the important aspect is to ensure that the staff involved have a clear,
consistent and unambiguous understanding of what it is they are expected to do.
Staff objectives can be specific to the individual and/or generic to the business. Personal
objectives are often set through some form of routine appraisal process, whereas the generic
18 © BSI 2012 Version 1.1.0

objectives are established through the particular project, team or function objectives.
While sometimes it is seen that personal objectives include specific work, or task-related
objectives, this does often incur some additional overhead in ensuring that they remain
current and appropriate. Ideally, personal objectives should relate to developing the
individual or supporting the overall improvement to the business, but not include specific
work-related tasks, which should be left defined at the work level.
BP.5 Induct Human Resources
Relevant induction activities should be undertaken as early as possible to enable the

individual to become effective in their new role within the shortest possible time. Induction
may include, for example, a general introduction to the organization, housekeeping,
department overviews and security measures. Induction is also essential when staff move
to a new role, and could, depending on the nature of the move, e.g. from one location
to another, involve those items previously mentioned. However, consideration should also
be given to the specifics of the new role, even if it is in the same organizational areas as
the previous role. This may include on-the-job training, mentoring, coaching or general
monitoring by more senior personnel.
Staff should be made aware of any specific area of responsibility in which they may be
directly involved or on which they may need to monitor and report. This may include, for
example, security responsibilities, equipment issued, quality awareness, and clear desk
polices.
Induction records should be securely maintained, and individual feedback gathered to

provide information for human resource assessment, quality management and to identify
ongoing improvements to the induction programme.
BP.6 Assess Human Resource Performance
The organization should regularly review human resource performance to ensure that
there is early identification of potential issues. The review may be triggered by an event,
e.g. performance or competency issues, a role change or during a probationary period. The
review may also be a regular business event, as directed by a human resource policy.
© BSI 2012 Version 1.1.0 19

Assessment criteria pertinent to the organization should be identified and implemented as

the basis for assessment. Assessment criteria are often taken from the defined objectives,
and supported by the assigned role and responsibility, i.e. have the objectives been achieved
taking into account the role and responsibility of the person? However, assessment criteria
may also include other aspects, such as expected behaviours (e.g. ethics, time-keeping,
dress-code, team working or, less objectively, peer feedback, and 360 review).
Assessment records are mutually agreed and confidentially maintained. Assessment

information is used for staff management purposes, e.g. career development, role change
or performance monitoring.
BP.7 Develop Human Resources
Human resources should have individual development plans identified to enable them to
fulfil their role, support career development or address performance issues.
The plan should define the development approach, timescale and the achievement criteria
for each identified need. The progress being made to achieve the plans should be periodically
reviewed with records being maintained. Where issues emerge with performance, the
organization should take timely and appropriate actions that are in accordance with planned
arrangements.
The effectiveness of development activities should also be evaluated on a periodic basis,

taking into consideration direct feedback and subsequent levels of performance.
BP.8 Benefit from the Subject Matter Expert
A subject matter expert is a known resource within the organization who is recognized to
have an in-depth knowledge of a product, service or process. A subject matter expert can
be used to maximize the breadth and depth of knowledge within the organization. The
organization should have processes that identify subject matter experts and to ensure that
their knowledge is effectively utilized within the organization.
An important aspect of benefiting from a subject matter expert is that their skills and
knowledge is allowed to develop in order for them to maintain their benefit to the
20 © BSI 2012 Version 1.1.0

Management Framework
organization. This will often mean that the organization should facilitate, promote and
capture knowledge-sharing through the subject matter expert, both internally and
externally.
The subject matter expert should be encouraged to take part in activities that would
further develop their skills and knowledge, such as through participating in state-of-
the-art or leading-edge projects or other work activities. Other activities that should be
encouraged could include participation in internal or external subject matter conferences,
submitting articles and papers for publication and involvement in steering committees or
standardization working groups.
The purpose of the Management Framework process is to establish the architecture and
govern the implementation of the management system supporting the policy, processes
and supporting documentation, including development and service lifecycle models for
use within the organization. These organizational assets should be formally maintained
within an Integrated Management System (IMS) covering all aspects of the organization’s
processes and practice.
The benefits of maintaining an IMS are widely acknowledged. Indeed, the implementation
of a comprehensive IMS is regarded as a prerequisite to enable an organization to achieve,
sustain and improve delivery performance, and an organization is unlikely to thrive without
an IMS. Establishing an IMS is necessary to ensure that formal attention is given to internal
operations, leading to fewer mistakes and conflicts, improved quality, reduced cycle times,
etc. An organization can achieve real benefits through empowerment, by enriching work
and making it more meaningful and challenging for employees, but this is not a simple
process. The whole organization must be engaged in the implementation of the IMS for it
to be successful.
Business leaders have a vital role in achieving the successful implementation of the IMS, and
real benefits can only be achieved if leadership is actually put into practice through effective
deployment within an organization by translating the corporate vision into practice through
the company’s processes. To be successful, the IMS must be an integrated part of running
the business rather than an add-on initiative. The IMS must also be customer focused,
ensuring that the needs of the customer are fully addressed through business objectives
© BSI 2012 Version 1.1.0 21

that cascade through all levels in the business. Senior leaders should demonstrate a clear
vision and understanding of the value of and necessity for effective process management
when establishing the IMS architecture and its governance.
While there may be some temptation to leverage perceived ‘best practice’, this strategy
should only be adopted where the intended processes truly align with the needs and
aspirations of the business. It is usually more effective to baseline existing processes than
to adopt an ‘off-the-shelf’ solution that does not align with current practices. Indeed,
organizations should avoid the temptation to throw away existing processes and working
practices in favour of new systems that may bring a whole new set of problems. Clearly, any
IMS built on these principles will quickly fall into disrepute and disuse. The IMS architecture
should also not be based on, or directly aligned with, external reference standards and
process models, including those contained within the TickITplus framework, as these are
unlikely to align with the specific needs of the business.
The management system can take a variety of forms and be documented in various
media. No particular expectation is set, or requirements specified, as to the architecture,
implementation or depth to which processes are documented within the organization. The
overriding consideration is that the Management Framework be fit-for-purpose and fulfil
the needs of the business. Similarly, there is no universal standard or format for procedures,
working instructions or other IMS documentation. However, whatever formats are adopted
should be common to all process assets. In addition, the definition of process and the
preparation of supporting procedures should involve employees from a cross section of
the organization. Here, employees should be encouraged to contribute to the development
of process assets that relate to their work. This type of involvement will encourage staff
to ‘own’ the procedures, rather than see them as being ‘imposed from above’. Procedures
that are not ‘owned’ will not be followed.
Quality assurance and audit plays an essential part in the ongoing effective implementation
of an IMS. Audit provides top management with visibility into how and where processes are
being applied. Audits must be prioritized and be formally planned according to the needs of
the business. The internal audit process should be regarded as one of the most important
organizational processes, as it provides a mechanism for measuring the progress of the
IMS and should be the source for future enhancements to the IMS. Internal audit should,
therefore, be an integral part of the management review process, providing essential
information to ensure the continued suitability and effectiveness of the IMS.
22 © BSI 2012 Version 1.1.0

Once an IMS is implemented, measurements and controls necessary to obtain consistent

results should be established. An effective measurement programme is essential to
any organizational improvement programme. Actions should then be taken to develop
performance and achieve lasting and ongoing improvement.
Senior leaders and other management stakeholders should monitor the ongoing
performance of the IMS. Reviews should consider the status of the IMS, in relation to
business and performance objectives. Consideration should not only be given to the
perceived adequacies and inadequacies of process and procedures, but also to their actual
effectiveness and performance as reported through performance metrics.
There are five base practices defined in the BPL Management Framework process that
collectively provide the activities necessary to achieve the process outcome. These are:
BP.1 Establish Management Framework Policies

BP.2 Establish an IMS
BP.3 Audit IMS Compliance
BP.4 Collect, Analyse and Use Measures
BP.5 Schedule and Hold Reviews.
BP.1 Establish Management Framework Policies
The commitment of senior management to any process and quality programme is essential.
Such a programme must be organization-wide and must start at the top with the chief
executive or equivalent. This commitment should be reflected in organizational policies in
which they really believe.
It is typical for policies to be approved by the highest authority within the company. They
should then be communicated to all members of staff, irrespective of grade or position
within the company. The policies should be explained to all staff, who should be made
aware of the goals of the IMS and their likely impact on the organization.
Policies should also promote the identification of measurable objectives that align with the
principles laid down in the IMS. There is nothing to aim for without formal objectives – and
in this situation the IMS will most likely become stagnant, with no improvement and no
indication of how well the organization is performing.
© BSI 2012 Version 1.1.0 23

Policies should be maintained in line with the current needs of the business. Policies should,
therefore, be reviewed and, as necessary, updated on a regular and planned basis. Changes
in policy should be formally communicated to staff along with details of any corresponding
changes in process and procedures.
Policies should be formally maintained as an integrated and key component of the IMS.
BP.2 Establish an IMS
The first and easiest step in developing an IMS is typically to document what is currently
being done. Care should be taken to ensure that all processes and practices are aligned to
and support the needs of the business and articulated goals. Thus, to successfully build
and implement an IMS, the organization must consider what benefits are expected to be
gained from the IMS and then determine how to quantify and measure both the current
situation and progress towards final goals. Implementation of an IMS should be pursued
as an operational plan, which should be tied to the organization’s strategic plans, because
the closer the IMS relates to the overall goals of the organization, the better the chances
of success.
IMS assets, including policies, procedures, standards, templates and any associated
collateral, should be maintained under appropriate configuration and change controls.
Facilities should be established to ensure that up-to-date IMS assets are available to all staff.
Variations in the implementation of the IMS should be managed through the use of
appropriately tailored guidelines. Tailored guidelines should show how the organization’s
standard process assets are selected and configured to create a defined process for a given
function, service, project, etc. However, the IMS should clearly define the mandatory
requirements that must be satisfied by the defined processes. It is typical for the
implementation of processes to be defined within a quality plan or equivalent.
Communication and training should be provided to all staff to ensure they understand the
sequence of operation and interrelationships of processes. Training may take a number of
forms including instructor-led sessions, computer-based training, on-the-job training, etc.
However, records should be established and maintained to demonstrate the competencies
of individuals (see ORG.1 Human Resource Management).
24 © BSI 2012 Version 1.1.0

BP.3 Audit IMS Compliance
Internal audits should be systematic investigations by trained auditors into the operation
of the organization. IMS audits should provide objective evidence that documented
procedures are being fully implemented throughout the organization and that the IMS is
effective in producing ‘quality assured’ products and services.
The planning of the audit programme must take into account factors such as:
• the importance or criticality of the activities being undertaken

• any likely risks arising from a specific process
• process measurement reports, including unexpected deviations from expected
performance
• process maturity
• the results of previous audits, along with any outstanding audit actions.
Adequate preparations should be made prior to commencing an internal audit. Preparations

should ensure that auditors are familiarized with the areas under inspection and that
adequate notice is provided for the stakeholders. Details of the audit should be agreed (e.g.
scope, time, locations, duration), along with any special arrangements that may be required.
The audit should obtain and review all documentation and records relevant to the area
being audited, including specifically the work objectives (i.e. what is it that is trying to be
achieved). Other aspects that should be reviewed include procedures and work instructions,
review records, inspection and test plans, specifications, etc., as well as reports from
previous audits, which should be used to prepare appropriate audit checklists if necessary.
However, extreme care must be taken to avoid the check-in-the-box trap, where audits
simply become mechanical exercises that add little value.
To be effective, audits should be carried out by trained personnel who are in a position
to independently and objectively assess compliance with the IMS and report status. An
auditor should also have the appropriate personal attributes and sufficient authority and
freedom within the organization to carry out meaningful and effective audits.
In all cases, audit practices must be established to obtain an objective view of status,
which is supported by factual evidence. Accurate records of completed checks should be
maintained, along with formal notifications of any matters arising. The results of audits
should be reported to stakeholders, along with notification of any non-compliances and
© BSI 2012 Version 1.1.0 25

recommendations. Non-compliances should be formally documented as part of any audit

reports. Corresponding corrective actions should be reviewed with stakeholders and should
include the agreed completion date to correct the specific non-compliance, along with
any further actions required to prevent reoccurrence. Actions should be formally tracked
to closure, including appropriate checks to ensure that appropriate action has indeed
been taken.
An escalation process should also be established to ensure that overdue actions receive
appropriate management attention.
BP.4 Collect, Analyse and Use Measures
Measurement is fundamental for the effective implementation of the IMS. Measurements

provide information on the ability of underlying processes to meet expected and necessary
performance, highlight unexpected deviations and provide opportunities for process
improvement. Processes cannot be controlled effectively without a suitable measurement,
analysis and reporting programme.
Measurements and metrics used to support the IMS should be formally defined, along
with the necessary data collection process, analysis methods and performance targets (see
ORG.6 Measurement and Analysis), allowing the effectiveness, capability and performance
of processes to be monitored.
Unacceptable performance, unexpected deviations and adverse trends should be identified

and reported, along with root cause analysis to identify appropriate corrective action.
Measurement reports should be reviewed on a regular and planned basis. It is typical for
this to be done as part of the normal management review cycle.
Performance should be baselined and actions determined to facilitate ongoing process

improvement. Here efforts should be made to stabilize processes by reducing variability,
while seeking opportunities to improve underlying performance.
BP.5 Schedule and Hold Reviews
Review of the IMS should take place on a regular and planned basis. The review should
involve top management, along with other stakeholders, and should consider the ongoing
26 © BSI 2012 Version 1.1.0

Corporate Management and Legal
effectiveness and performance of the IMS in meeting business objectives. This should
include an evaluation of the performance of the system, based on both qualitative (i.e.
audit, quality assurance status, etc.) and quantitative (i.e. process measurement and
metrics) data.
The frequency and extent of each review will depend on a wide range of factors, including
the nature, scope and size of the business, the maturity of processes, etc. However, it is
unlikely that a single annual review would bring significant gains. More frequent reviews
would, therefore, be expected. Operational reviews of the IMS may be divided appropriately
between the stakeholder groups associated with specific processes. Nevertheless, overall
IMS reviews should also be conducted by senior leaders on a periodic basis to ensure that
strategic objectives and expectations have been met.
Corrective and preventive actions should certainly be taken where poor performance is
observed, but close attention should also be given to opportunities to drive underlying
performance and capabilities. In all cases, actions should be logged and tracked to ensure
that they achieve the expected results.
The Corporate Management and Legal process is intended to provide a framework for
the strategic management that is necessary for the organization to achieve and exceed
its business targets in a legal and corporately responsible manner. The process deals with
the formulation and deployment of organizational strategies and initiatives, established
by business leaders, to enhance the performance of the business. The process comprises
activities to formalize the organization’s mission, vision and objectives, which then leads
to the formulation of polices, processes and procedures – along with appropriate strategic
projects – to fulfil business strategies.
The Corporate Management and Legal process typically operates at the highest level in a
company, although it may also be replicated at lower levels within an organization, especially
where the business is large or diversified, with a number of separate operating divisions,
for example. When there is more than one level of strategic management it is important to
ensure that lower levels align with the top-level principles and objectives.
The outcome from the Corporate Management and Legal process is that senior management
are fully engaged in the operation of the business and overall performance is improving.
© BSI 2012 Version 1.1.0 27

Here, the role of senior leaders should be to set the goals and overall direction of the
enterprise, while empowering managers and staff to develop and implement the more
detailed tactical strategies and plans to meet the overall business aims. It is typical for
strategic plans to have the longest cycle time. For example, top leaders should consider the
long-term strategic direction of the business, perhaps over a five-year timescale, whereas
tactical plans are more likely to have an annual cycle. However, business leaders should
ensure that they are fully aware of operational performance, problems and limitations
affecting the business, and factor such knowledge into their strategic leadership activities,
while making appropriate adjustments in their plans.
Some consider the principle of continuous improvement of performance to be impracticable

or unattainable. However, to have a business philosophy of anything less is near-sighted
and will ultimately lead to the demise of the business. An organization that fails to remain
competitive, while keeping customers satisfied, will provide other businesses – perhaps
with more efficient processes – with opportunities to gain market share. Similarly, an
organization that fails to give good returns to shareholders or maintain a strong corporate
reputation will become vulnerable. The support of other stakeholders is also vital. For
example, organizations recognize that keeping their employees motivated and committed
to the vision and objectives of the business is fundamental to success. A clear corporate
mission, combined with a commitment to ongoing performance improvement is, therefore,
the only sensible business philosophy.
Corporate management is usually performed within the context of a strategic management

process. Strategic process management creates the link between the overall vision and
operational management. A range of strategic management techniques are available.
For example, some organizations favour an inclusive approach, where all employees are
encouraged to be proactive and participate in formulating strategic direction, by suggesting
possible changes and innovations to bring benefits to the organization, while other
organizations adopt a top-down strategy, where the senior management team decides on
the overall direction that the business should take. It is likely that a combination of these
techniques will be applied in practice.
There are five base practices defined in the BPL Corporate Management and Legal process
that collectively provide the activities necessary to achieve the process outcome. These are:
BP.1 Identify Business Needs and Objectives

BP.2 Establish Business Plan
28 © BSI 2012 Version 1.1.0

BP.3 Establish Management Framework

BP.4 Manage the Organization
BP.5 Manage Business Performance.
While normally there is no implied sequence to the base practices in the BPL processes,
in this case there is a natural order to the activities necessary to achieve a well-managed
organization. The first three practices provide a platform on which the organization operates
and tend to be conducted in sequence, albeit with a lot of feedback and iteration.
BP.1 Identify Business Needs and Objectives
Strategic management is a business process that enables senior management to set short-
and long-term action plans for continuous business improvement and development. It
consists of developing a future business profile that will ensure success, and implementing
strategic plans through engagement with the business.
Strategic management is not operational management. Operational management is the

difficult task of ensuring business objectives are met despite changes and setbacks in the
business environment. Strategic management should result in the formulation of a clear
mission and vision for the enterprise that is worth pursuing, and one that employees will
gladly put their energy, passion and imagination into. Corporate management, when it is
working well, surveys the business environment, analyses events, identifies opportunities
and threats, and develops strategies to maximize the effectiveness of the organization.
Business needs and objectives should be formally established through this activity, taking
account of the business imperatives, and the statutory and legal requirements that the
organization is subject to.
The business environment is not solely a commercial one. Political, economic, social and
technological considerations must all be taken into account, as well as legal, environmental
and possible demographic influences that may affect the long-term performance of the
business.
Business needs and objectives should be formally defined and communicated to all levels of
the organization. While overall needs and objectives can take a number of forms, it is typical
for these to be defined in a mission statement – setting out the overall corporate vision and
direction, supported by definitions of company values and critical success factors.
© BSI 2012 Version 1.1.0 29

In this way, identifying business needs and objectives leads to the development of a vision
for the future, while providing the strategies to produce the changes needed to achieve
that vision.
BP.2 Establish Business Plan
Creating a strategic vision for the future does not guarantee an organization’s survival. To be
successful, the overall business strategy must be validated, and then implemented through
a business plan that sets out how the business needs and objectives are to be achieved.
The business plan (or plans) should address all stakeholder needs – be they external, such
as investors and customers, or internal, including management and employees at all levels
of the organization. The business plan should also set out performance objectives and
improvements to be achieved through implementation of the company’s management
systems, as well as setting out plans for investment over the next trading period. This may
cover, for example:
• the implementation of new services

• purchase of additional or refresh of IT infrastructure
• expansion into new premises or refurbishment of existing facilities
• restructuring in response to market conditions.
Creating the business plan is only the first part in establishing business strategies. The plan
needs to be communicated to all stakeholders, and should be formalized through critical
success factors and key performance indicators, expressed in a clear and simple form, that
reflect the corporate vision. These should be recognized and understood by all employees,
irrespective of their role and seniority within the organization. This should not be a simple
‘speak and tell’ activity, but must provide the opportunity for employees to assimilate the
vision and future direction of the business and understand its full depth and impact on
them, their colleagues and the organization as a whole. It must allow people the space
and time to make a full and passionate commitment to the future vision – for without full
commitment the vision will not be achieved.
Aligning employees to the future vision and direction of the business is a constant and
demanding activity, and one that corporate management ignores at its peril. Gaining buy-in
is a strategic imperative.
30 © BSI 2012 Version 1.1.0

BP.3 Establish Management Framework
The management framework should comprise policies, processes, procedures, standards

and supporting documentation that enables the organization to put its business plan into
operation. The framework should also be supported by formal measurement and analysis
processes to monitor the performance of the management system in meeting the needs
and objectives of the business, expressed as key performance indicators in the business
plan.
In the past, organizations have implemented various collections of policies, processes

and procedures addressing different aspects of business operations, such as a Quality
Management System to define quality management practices, and a Security Risk
Management System to formalize security management, etc. However, there is an increasing
trend for organizations to bring these various systems together, forming an Integrated
Management System (IMS), which is aligned to the business plan. Although not essential,
TickITplus also encourages the use of an IMS as it provides an assessment framework that
is intended to integrate a number of IT standards.
The format of the IMS is immaterial to its effectiveness, but the increasing use of web-
enabled systems, wikis and corporate knowledge databases are making the development,
use and update of the IMS more efficient.
BP.4 Manage the Organization
At an operational level, activities are undertaken according to the processes and procedures
laid down in the IMS. Data is gathered and measurements made, interpreted and acted
on to ensure the achievement of operational targets. To do this the organization needs
the right conditions and approach. Here, for example, the provision of financial, material,
service and human resources is the responsibility of corporate management.
Vital practices, such as recruitment, appraisal, development and reward, should be

integrated in and aligned with the business needs and objectives, and then expertly
delivered through corporate communications, such as town hall meetings and brown bag
lunches. It is a truism that people do what corporate management does, not what it says.
Only when those within the organization see corporate management living and breathing
the vision will they begin to believe in it too.
© BSI 2012 Version 1.1.0 31

Communication – along with a consistent and focused emphasis on the vision, business
model, company values and critical success factors – serves to establish these factors not just
in the consciousness of the organization’s workforce, but also in the subconscious culture of
the enterprise. This stimulates the commitment, passion and energy that distinguishes an
excellent organization from a mundane one.
BP.5 Manage Business Performance
In a similar way to which line management monitors operational performance against

operational criteria, corporate management should monitor performance against strategic
goals and objectives.
One way of looking at this is to say that line management is responsible for ensuring that
the organization does things right (i.e. according to the processes and procedures laid down
in the IMS) while corporate management is responsible for ensuring that the organization
does the right thing (i.e. according to a vision that takes them to improved performance).
Corporate management does this by gathering and analysing organizational performance

data to ensure the achievement of strategic goals and objectives. This should be done on a
regular and planned basis as part of the strategic planning process. Here, key performance
indicators should be used as the measure of progress towards strategic goals. These should
be reviewed by senior leaders, typically using dashboards, scorecards, etc., as part of a
formal management review process. Corporate management should take action where
performance deviates from the business plan. In the same way, line management should
take action when performance deviates from operational plans.
Meeting business and operational plans shows the organization to be effective. In addition,
corporate management can also review operational experience and determine how to
operate more efficiently. This is the so-called ‘double-loop’ learning, which is essential to
an organization looking to continuously improve performance.
An organization needs to learn from experience – good and bad. Simply holding ‘lessons
learnt’ reviews merely identifies the lessons. The organization must consider its past
performance, and change its strategies to reflect its experiences. Here, the organization
needs to update the affected policies, processes, procedures, templates and standards,
inform all those involved with the process or practice, train those who execute the practice,
32 © BSI 2012 Version 1.1.0

Infrastructure and Work Environment Management
and reset the performance baseline so that the effect of the improvement can be seen in
the performance data.
Increasingly, organizations are using a knowledge base to capture and drive such knowledge
improvements.
An organization should consider the need for an infrastructure and work environment that
will support the activities necessary to meet the requirements of the business plan, including
legal requirements. Infrastructure and work environment are very closely linked, with
one affecting the other. ‘Infrastructure’ typically includes premises, equipment (including
hardware and software) and supporting services (e.g. utilities and transport), whereas ‘work
environment’ typically means how the infrastructure is used to affect working conditions.
For example, the provision of a room heater is covered under ‘infrastructure’, whereas
ensuring adequate heating is covered by ‘work environment’. The work environment in this
context is different to environmental management, although clearly there is a large overlap,
especially where there are possibilities that inappropriate control of infrastructure or the
work environment can affect ‘the environment’.
Managing the infrastructure effectively should ensure that the work environment is suitable
for the safe and effective operation of the business. This may include, for example, ensuring
that internet access is sufficient to allow staff to perform their work effectively, or ensuring
that there is an uninterrupted power supply for critical business systems.
In establishing the infrastructure the organization should take into consideration what is
needed for business activities to be conducted in a managed, safe and secure manner. For
example, this should ensure that staff can operate in a safe working environment, and that
the integrity of information and other work products is not compromised. Establishing the
infrastructure should also take into consideration all applicable statutory, regulatory and
security requirements. Statutory requirements include aspects such as health and safety
and fire regulations. Regulatory requirements include self-regulation, such as a commitment
to adhere to industry standards, including, for example, ISO 9001 and TickITplus, a relevant
trade association’s regulations, etc. Security requirements may include a required level of
password complexity or a need for physical controls to be in place to control entry to the
premises.
© BSI 2012 Version 1.1.0 33

There are four base practices defined in the BPL Infrastructure and Work Environment
Management process that provide the framework to support organizational activities.
These are:
BP.1 Establish Infrastructure and Working Environment Policies

BP.2 Identify Infrastructure and Work Environment Needs
BP.3 Establish and Manage Infrastructure
BP.4 Disposal of Infrastructure.
There is no implied sequence to the base practices in this process area.
BP.1 Establish Infrastructure and Working Environment Policies
Infrastructure and work environment policies should be established to ensure that business
activities can be carried out in a suitable environment. Infrastructure policies could include
the safe operation of equipment, use of third-party software, use of organizational
equipment and facilities, access controls, etc. Work environment policies could address
minimum temperature, clean desk, use of extension leads, and other health and safety
related issues. These should be considered against the general business environment and
expected behaviours, which are aligned to the business plan and objectives. It is important
that the organization’s staff are made fully aware of these policies and, where possible,
provide feedback on the level of understanding and compliance, which should be routinely
sought by senior management.
Policies and procedures should be reviewed regularly and take into account any changes
within the organization, along with any new or revised statutory, regulatory, security, etc.
requirements.
BP.2 Identify Infrastructure and Work Environment Needs
The organization should engage with all stakeholders, to understand the full requirements
for the infrastructure and work environment. Stakeholders may include representatives from
organizational groups, customer groups and both direct (suppliers) and indirect (visitors,
legal bodies, government agencies) third parties. The input from these groups, along with
the business objectives, should establish a series of requirements for the organizational
infrastructure and work environment.
34 © BSI 2012 Version 1.1.0

The organization should ensure that all stakeholders, including employees, contractors,
visitors or other third parties, are well informed about relevant working practices. This
often involves the organization conducting random tests, questionnaires and surveys and
audits of its staff to gain an understanding of the level of knowledge and compliance.
While the infrastructure and work environment needs should be established at the
organizational level, there will also be a need to identify specific infrastructure and work
environment requirements within projects, functions and subgroups. It is important here
that these lower level requirements do not conflict with the organizational needs (e.g. the
organization has set certain expectations for security, but the project identifies significantly
different needs). In practice, if this occurs, a review involving all stakeholders should be held
to understand the implications and to propose a way forward. Among the possible options
that might be available, one solution might be to accept that the differences have to exist
and allow a concession against the organizational requirements. However, no matter what
the circumstances, the concession cannot be allowed to infringe legal, including safety and,
where appropriate, security, requirements.
BP.3 Establish and Manage Infrastructure
The infrastructure should be established and monitored to ensure that it continues to

meet the needs of the business and provides the required work environment. For example,
physical infrastructure, such as air-conditioning or fume-extraction equipment, can wear
out or become faulty, and non-physical infrastructure, such as software tools, may become
obsolete and unsupported, or just incapable of supporting the business operations over
time. Furthermore, infrastructure can be influenced by internal and external factors.
Internal influences can include changes to working practice, either by design or through
undesired behaviour changes, while external influences can be the implementation of new
legislation or environmental standards.
In most instances, it is important to establish a clear register or index of infrastructure assets.

This serves various purposes. The most common need is for insurance and depreciation
purposes, but other uses can include licensing (for software assets) and disaster recovery
purposes. Ideally, a single master list should be created and maintained; alternatively
individual lists can exist for different types of infrastructure.
The organization should also establish plans that detail how infrastructure can be recovered
following a loss in order to ensure business continuity.
© BSI 2012 Version 1.1.0 35

BP.4 Disposal of Infrastructure
The organization should ensure that procedures are in place to safely and, where necessary,
securely dispose of organizational infrastructure, including equipment, data, software
and other key business assets, according to defined policies. Disposal should take into
consideration business needs and all applicable legislation, including relevant environmental
regulations. Arrangements should be made to ensure that staff fully understand and adhere
to these requirements.
Disposal requirements can range from those occurring in daily activities, such as the secure
disposal of sensitive data and documents, through actions necessary at the completion of a
project, to major events such as the closure of a facility or location.
In addition to general business needs, disposal requirements must address safety, security or
environmental aspects. Infrastructure may need to be disposed of in a manner that ensures
it cannot cause any safety-related incidents, e.g. high-voltage electrical test equipment,
equipment with hazardous or harmful components, or items that can cause physical injury.
Other infrastructure items may need to be disposed of in such a way as to preserve security.
For example, faulty hard drives that have contained sensitive information may need to be
erased and physically destroyed. Documents containing sensitive information may also
require secure physical destruction. Other infrastructure items, irrespective of the safety
and security requirements, may need to be disposed of in such a way as to ensure no
harmful effect on the environment and meet recycling regulations.
Appropriate records of disposal are retained for legal compliance and security requirements,
and internal audit checks.
Improvement
The principles of continual improvement are at the heart of the TickITplus scheme. The
purpose of the ‘improvement process’ is, therefore, to establish the infrastructure to
support process improvement across the organization.
Senior management’s responsibility for leading an organizational improvement effort is

well documented. Indeed, most commentators suggest the success of any improvement
programme is totally dependent on the active participation of business leaders and their
management teams.
36 © BSI 2012 Version 1.1.0

Improvement
Truly successful improvement programmes also encourage participation from the whole
organization – as improving processes is the only way to achieve business improvement,
and the best people to improve a process are those who apply it every day. While some
specialists, such as Six Sigma experts, may be necessary to support improvement activities,
the overall programme must be inclusive, promoting input from all staff. Improvement
programmes that rely on an exclusive quality or business improvement team are usually
unsuccessful, because they fail to get the necessary buy-in and participation from the rest
of the workforce. The improvement effort should therefore be regarded as an integrated
part of running the business, rather than as an add-on initiative.
Improvements must also be closely aligned to measurement and analysis practices, as

performance metrics provide the means to determine progress and motivate the necessary
change to achieve higher levels of process maturity. Top management naturally focuses on
the financial performance of the business and strives to achieve ever increasing market share,
but it can sometimes lose sight of the processes that underline business performance. This
is particularly true in the IT industry, as the vital performance measurements that are the
foundation for effective process improvement are often as intangible as the programming
within the complex systems that operate today. Careful consideration should therefore be
given to the selection of meaningful and achievable targets, based on business needs that
bring tangible value to the organization. These should be prioritized, taking into account
the impact of weak or ineffective processes within the business, along with opportunities
to enhance performance and gain competitive advantage.
Performance targets, along with the improvement methods applied by the organization,
should be reviewed and revised as operational processes mature. At low levels of process
maturity, performance and improvement are typically dependent on compliance with
processes and procedures – as there is little point in improving a process that is not actually
applied. Apart from the cost that this wasted effort will involve, the absence of any lasting
benefit will likely bring the whole improvement programme into disrepute.
Once the improvement process has been standardized and implemented consistently,
increased focus should be placed on measurement and performance metrics. At this point,
analysis, including appropriate statistical techniques, should be used to characterize the
performance of the processes, and thereby to identify opportunities for improvement,
while attention should switch to the sources of variation that influence the process. At
higher levels of performance, ongoing improvement is achieved by careful and systematic
analysis of the underlying capability. This can only be achieved through the application of
statistical process and quality control techniques.
© BSI 2012 Version 1.1.0 37

An organization must formalize its improvement approach as part of the process

infrastructure. Of course, the improvement approach will be cyclical, and at the highest
level almost all improvement strategies follow Deming’s well-documented plan–do–check–
act cycle. Many acceptable adaptations of this model exist, including several specific
examples for IT, which include additional decomposition of the basic steps. However, the
main feature of all these cycles is that they include steps to:
• select, prioritize and characterize the problem or opportunity for improvement

• establish expected benefits and plans to address the problem, including the specific
actions to be taken
• implement the plans and take the intended actions
• evaluate the effects of the change to see if intended benefits have been achieved
• repeat the cycle.
Assessment frameworks, such as TickITplus, can be used as an aid to an improvement

programme. They can be used to benchmark the management system, as well as to
identify potential weaknesses in specific practices. However, the organization must
structure its management system, and its contents, on the needs of the business, and not
on the assessment framework being applied. Similarly, the priority and attention of the
Improvement process should be given to business goals and objectives, rather than to
arbitrary certifications or ratings.
There are four base practices defined in the BPL Improvement process that collectively
provide the activities necessary to achieve the process outcome. These are:
BP.1 Establish Policies and Procedures for Improvement

BP.2 Analyse Improvement Opportunities
BP.3 Implement the Improvement
BP.4 Monitor and Review.
BP.1 Establish Policies and Procedures for Improvement
Proactive and visible management participation is essential in driving ongoing improvement.

Senior management’s commitment to improvement should be defined within appropriate
policies explaining the overall principles and objectives of the organizational improvement
programme.
38 © BSI 2012 Version 1.1.0

Improvement
Improvement policies should be communicated throughout the organization, so that all

staff are aware of the commitment to process improvement and, in particular, understand
their expected involvement in the improvement programme.
A framework for improvement should be established to ensure that there is clear direction
and that appropriate methods are available to show that processes are demonstrably
improved, in the light of problems and measurements, to meet business objectives.
Procedures supporting the improvement framework should be defined and communicated
to staff.
Improvement policies and procedures should be reviewed regularly and, where necessary,
enhanced to take into account any changes within the organization. Attention should be
given to the maturity and underlying performance of processes, as more sophisticated
analytical methods should be applied as process maturity and capability improves.
BP.2 Analyse Improvement Opportunities
Care must be taken in selecting and prioritizing the specific improvements to be implemented.
An organization must not fall into the trap of trying to solve too many problems in too short
a period of time, with too few resources. Instead, the organization should establish and
implement formal mechanisms for reviewing and prioritizing the improvements that will
bring best value and advantage at any given time.
The improvement programme must be aligned to business needs, and so any improvement
strategy or improvement cycle must begin with an examination of the organization’s needs
and business goals. Overall improvement targets should then be formalized that aligned
with these goals. Subsequent reviews of possible improvements can then be mapped to
the business goals.
Opportunities to drive improvement come in many forms but, while process and performance
metrics (i.e. ‘the voice of the process’) are an essential foundation for improvement, other
factors should be taken into consideration. For example, it is essential for the improvement
strategy and supporting processes take account of customer needs and feedback (i.e.
‘the voice of the customer’). Here, customers can be internal to the organization, taking
output from internal processes, or the final (external) client. Client feedback for motivating
improvement should include performance against service or delivery specifications,
© BSI 2012 Version 1.1.0 39

customer complaints, etc. Employee roles should also be formally declared as part of
the improvement programme. Employees should be encouraged to suggest possible
improvements and certainly to propose actions to be taken where opportunities to improve
have been identified.
All recommendations for improvements should be formally documented. Improvement

opportunities should be expressed in measureable terms, including, where possible and
appropriate, a cost–benefit, or return on investment (ROI) analysis.
Improvement opportunities and recommendations should be formally reviewed by

appropriate stakeholders. Reviews should take account of the contributing factors and
root cause of problems or underlying performance issues. Close attention should be
given to the analysis and review of process measurements and metrics. Improvement
opportunities should then be selected for implementation on the basis of feasibility, cost
and benefit. Selected opportunities should then be prioritized and aligned against the
overall improvement strategy.
BP.3 Implement the Improvement
A formal plan of action should be established once improvement priorities have been set.
The plan sets out the scope of the improvement programme, milestones to be achieved,
the approach to be adopted and actions to be taken, along with the role and responsibilities
of key stakeholders, including top management. The improvement plan, as with any other
plan, should also include an analysis of the issues and risks that could hamper progress.
In some cases, where the improvement is substantial, the improvement could be run as a
formal project, with an associated full management plan.
A relevant performance baseline should be established and used as a datum point to

measure the progress of the improvement efforts. The baseline can make use of qualitative
assessment frameworks, such as TickITplus, but should preferably comprise relevant process
metrics, or a combination of both.
Planned activities should be undertaken and further performance data gathered to allow
progress to be monitored.
40 © BSI 2012 Version 1.1.0

Measurement and Analysis
BP.4 Monitor and Review
Progress against individual improvement plans should be formally reviewed on a planned

and regular basis. These reviews should consider the success of the changes being made,
against predicted results, as well as monitor the progress of activities against plans.
The overall status of improvement activities should also be monitored on a planned and
regular basis. This should include reviews by top management, which typically include an
overview of current status, along with more detailed reviews at operational levels within
the business.
Records of the reviews should be maintained in all cases. Records should include the
performance reports, along with details of the review and any actions arising from the
review. Actions arising from reviews should be formally logged and tracked to closure.
It is generally accepted that effective process measurement is key to any organizational

improvement effort. Similarly, the practices associated with process management and
continual improvement have been widely recognized by the IT industry. These principles
are reflected in a way of thinking and understanding that encourages the use of process
data to drive actions resulting in improvements in quality and performance. A process
must be managed effectively to be able to stimulate improvement. A process cannot be
managed effectively if it cannot be controlled – and a process cannot be controlled unless
it is measured. In other words – ‘what gets measured gets managed’.
The purpose of the Measurement and Analysis process is therefore to establish a quantitative
management framework to monitor products and processes, and to stimulate continual
improvement. Measurement and analysis involves the identification of key process
measurements in support of business objectives, along with the supporting practices used
to collect, analyse and report status.
Applying the process requires the organization to establish a measurement framework

that is linked to business objectives and drivers, while deploying measurement practices
through the definition of policy and procedure, along with supporting documentation.
© BSI 2012 Version 1.1.0 41

Thus, an ordered measurement framework becomes the foundation for an effective

process and quality improvement programme, where measurements become the basis for
detecting deviations from acceptable performance, while providing the basis for identifying
opportunities for process improvement. This approach embodies four key principles,
namely:
• understanding – where data may be gathered as part of a study to learn about a particular
output or process
• evaluation – using data to determine if a process, product or activity meets accepted
criteria
• control – analysing data to set limits and goals for activities
• prediction – using data to develop rate and trend parameters for planning.
The ultimate goal of measuring the software process is to reach the point of statistically
verifiable control similar to that already performed in some manufacturing industries. IT
organizations sometimes consider the use of statistical methods, such as control charts,
as tools that are unique to manufacturing or highly repetitive processes, while many IT
processes are regarded as highly human-centric where such techniques cannot be applied.
However, there are many examples where these methods have been successfully used in
IT, providing an invaluable source of empirical evidence to support decision-making, while
driving towards optimizing performance. However, the selection and application of specific
measurements will clearly depend on the maturity of the processes within the organization.
Measurements, along with their corresponding analysis and reporting methods, should
therefore be reviewed and refined as the organization continues to drive improvements in
performance and capability. Thus, an organization is encouraged to develop a broader and
more accurate series of process measurements and metrics as it matures, rather than being
overwhelmed by detail at an early stage in maturity.
As with other processes, careful and systematic planning is critical to the implementation
of an effective Measurement and Analysis process. In this case, however, a high degree of
consistency in the approach must be established to ensure that the use and conclusions
drawn from any analysis undertaken is based on normalized data.
Formal planning encourages the organization to clarify its business goals and understand
how these relate to its development and delivery processes. The organization should
give particular attention to its critical processes and ensure that the objectives for these
processes are formalized. Measurements and metrics supporting these processes should
42 © BSI 2012 Version 1.1.0

then be identified, along with corresponding analysis and reporting methods to monitor
progress towards the defined goals.
There are four base practices defined in the BPL Measurement and Analysis process that
BP.1 Define Measurement and Analysis Policy and Procedures

BP.2 Identify Measurement Objectives and Data
BP.3 Collect and Analyse Measurement Data
BP.4 Use Measurement Informa on.
As with other processes in the BPL, there is no formal sequence to the base practices;
however, there are obvious steps that the organization must follow to establish its
measurement framework. Fundamentally, the measurement framework should be closely
coupled with the needs, objectives and priorities of the organization.
BP.1 Define Measurement and Analysis Policy and Procedures
A top-level policy, which sets out the organization’s overall strategies for its measurement,
analysis and reporting framework, should be defined and communicated. This policy
typically defines why the measurement framework is important and the overall approach
for aligning measurement activities with the needs and objectives of the organization. The
policy will usually be set by senior management and will be endorsed by top management
within the organization.
The policy should be implemented through procedures and supporting standard

measurement definitions that define how the organizational policy for measurement
and analysis is put into practice. These definitions are critical, as they are used to explain
how each measure is obtained so that measurements can be collected and interpreted
consistently and correctly. Procedures should also define how and when measurements
and metrics are to be reviewed and action taken to address unacceptable performance,
while driving continual improvement.
As with all organizational processes, the measurement and analysis policy, along with
supporting procedures and definitions, should be maintained under the quality management
arrangements with a periodic review for suitability and effectiveness.
© BSI 2012 Version 1.1.0 43

BP.2 Identify Measurement Objectives and Data
The organization should determine measurement and process objectives that are aligned
to overall business objectives. Here, the organization should identify operational or delivery
issues, along with those associated with critical processes that are to be addressed through
improved performance. A useful starting point is to review the measurements that are
currently being collected by the organization to establish how well the organization is
currently performing and to determine if the current measurements align with the goals
derived from the business plan. This analysis will help to highlight the adjustments in
using current data to align better with business goals and, where necessary, to determine
additional data requirements where any gaps have been identified.
Selected measurements should have high information content and should be aligned with
the variations in processes that need to be monitored, because there is little point investing
in measurements that are irrelevant or do not reflect the performance of the processes
in question. Selected measurements should also permit consistent collection from well-
defined data sources. Above all, selected measurements should be informative – having
a diagnostic value allowing the organization to identify underlying issues or concerns,
characterize process capability and, ultimately, establish the causes of variation and
unacceptable performance.
Here, processes generally have a number of measurement characteristics in common.

These typically include:
• size – service capacity, product size, etc.

• product quality – characterizing conformance to specification, tolerances, action limits,
defects, etc.
• cycle time – describing the elapsed time of the process and associated activities
• delivery – characterized by the timeliness of delivery and performance against
expectations or commitments
• cost – including the cost of execution of the process, along with the resources supporting
the process.
Other reporting metrics are typically derived from these base measurements.
In all cases it is important to ensure that stakeholders acknowledge and support the defined
measurement strategy. Here, stakeholders include top management and other senior
staff responsible for making changes in business strategies and organizational processes,
44 © BSI 2012 Version 1.1.0

along with the groups and individuals responsible for implementing process measurement
practices. It is expected that stakeholders are not only aware of the measurement strategy,
but are also proactive advocates of measurement and analysis in driving performance
improvement.
BP.3 Collect and Analyse Measurement Data
Operational implementation of the measurement programme is dependent on data

collection. Data collection must, necessarily, be integrated into other operational processes.
Procedures must ensure that the right tools and practices for data collection and analysis are
applied by the right people at the right time. Formal arrangements should be established to
store the data for use in analysis and reporting performance.
Here, processes are typically measured in two ways: by monitoring the attributes of the
products that the process produces (output measures), and by measuring characteristics of
the process itself (internal measures). When stable, these measurements provide a history
of how the process has performed in the past, while also providing insight into how the
process is likely to perform in the future. Thus, when collecting data it is important to record
both the timing of and the context in which the data is collected. For example, knowledge
of the collection data in relation to process events is crucial to the identification of sources
of variation within the process.
Collected data should be reviewed and verified to ensure that it meets its specification
and is accurate. Verification can include checks on the appropriateness of the data, such as
range, format and completeness checks on data sets. Here, a useful validity check is to check
the data against predicted results determined from past performance. When discrepancies
occur, it is important to determine if the variation is attributable to weaknesses in data
collection practices or to a fundamental breakdown in the measurement strategy. Either
way, appropriate action should be taken to address the discrepancy. It is also worth noting
that, even if the data looks invalid, it may actually be validly indicating a serious change in
the underlying process.
Raw data should be analysed to highlight the patterns, trends and relationships that are
important to the organization and to aid decision-making. Analysis, including the application
of appropriate analytical methods, has two principal purposes. Techniques should be
applied that highlight process problems, but these should be combined with methods to
© BSI 2012 Version 1.1.0 45

analyse any problems leading to the identification of root causes and the characterization
of potential solutions.
A variety of tools, methods and presentational techniques can be applied. For example, basic
histograms and bar charts can be used to display trends and current performance; methods
such as run charts and control charts can be used to show the statistical characteristics
of a process; while scatter diagrams can highlight relationships and correlations between
two process characteristics. Clearly, the selection and application of analytical techniques
should be appropriate to the specific measurements, their purpose and the corresponding
performance goals.
While initial attention may be focused on bringing stability and control to processes (i.e.
addressing assignable causes of variation), analytical techniques should also be directed
towards underlying process improvement. At this point, attention switches to the
identification, characterization and elimination of common-cause variation. Here, the
application of statistical techniques is necessary to establish underlying process capability
and to determine appropriate actions to drive improvement.
BP.4 Use Measurement Information
Stakeholders, including top management, should review performance measurements on a

planned and regular basis. A number of different reviews may take place, depending on the
size of the organization, along with the nature and scope of the work that the organization
undertakes. Similarly, different reports may be reviewed by a variety of stakeholder groups.
Here, for example, it is likely that operational managers may focus at some level of detail,
while senior managers take an overview of performance using aggregated data, drilling into
more detail as necessary.
The purpose of reviews is to monitor progress towards defined process goals, while taking
action to eliminate poor performance and stabilize processes. Bringing stability to processes
is fundamental to an organization’s ability to supply services and products according to plans.
Establishing stability in processes also provides the necessary foundation for improving
processes, thereby producing better and more competitive products and services.
Reviews should be formally documented, along with agreed actions. Actions should be
prioritized to reflect business needs, including any remedial actions necessary to address
failures or critical issues. Actions arising from a review of measurements and metrics should
46 © BSI 2012 Version 1.1.0

Customer Focus
instigate planned and systematic changes in processes to improve underlying capability, as

well as address unacceptable performance (see ORG.5 Improvement). All actions should
formally be tracked to closure, making sure that the actions actually do yield the expected
benefits.
Customer Focus
Customer focus is probably one of the most important aspects of delivering a successful
business, yet in some ways is the hardest to define through formal processes. Customer
focus depends equally on attitudes, commitment and approach, as on ensuring that
processes are defined with the customer in mind.
Customer focus can be explicitly covered by processes that, for example, address
complaints, gather customer feedback or establish customer satisfaction levels. Customer
focus is also more implicitly involved in processes that interact directly with the customers,
e.g. Stakeholder Requirements Definition, Problem and Incident Management, Validation,
Transition and Release Management and, to a slightly lesser extent, Project Management.
In a much less tangible way, customer focus is important in many internally operated
processes, such as corporate management, where the needs and objectives of the business
must be tightly coupled with the customers’ needs and expectations. It should also be
covered within the Human Resource Management process to ensure that staff recruitment,
assessment and development includes appropriate attention to customer focus aspects,
especially, for staff directly interfacing with customers or their representatives. In addition,
the Customer Focus process should be inherent in the Improvement process to ensure that
improvements are not just made solely for the benefit of the business but also take into
account customer desires and expectations.
The level and nature of an organization’s approach to providing adequate customer focus
should be identified against the activities of the organization. Some organizations may have
large amounts of technical interaction with customer specialists. For example, an outsourcing
organization interfacing with the customer’s retained IT staff. Other organizations may have
other arrangements where, for example, there is a large degree of user interaction, say in a
support or service desk. Other organizations may have equal amounts of both.
Some development organizations may have limited direct interaction with the users of their
products (e.g. where there is a significant supply chain involved, such as with embedded
© BSI 2012 Version 1.1.0 47

technology in the automotive sector), although clearly even here there are still customers.
Other development organizations may have quite a bit of user interaction, especially these
days where, for example, software products are developed and sold directly to customers
(users) via the internet.
The outcome defined for this process in TickITplus requires organizations to demonstrate
that customers have a positive view of the approach taken to business relationships. To
measure the effect of customer focus effectively is not easy, and can involve many facets
of an organization. However, organizations should strive to establish some appropriate,
repeatable and reliable indicator of the approach taken to customer focus. Measures can
be around customer complaints, although a far more beneficial and proactive approach is
to establish effective customer feedback and satisfaction measures.
There are four base practices defined in the BPL Customer Focus process. These are:
BP.1 Establish Business Relationship Framework

BP.2 Establish Customer Focused Procedures
BP.3 Collect and Analyse Customer Feedback
BP.4 Review Rela onship.
BP.1 Establish Business Relationship Framework
The key to successful customer focus is in the definition of a good business relationship
framework. The framework should include appropriate policies set by top management
around the behaviours and expectation of how the organization should interact with
customers. Processes and procedures should be defined to ensure that appropriate
customer focus practices are established. Communications, awareness sessions and
training should be provided to staff stressing the importance of customer focus. As with all
business activities, appropriate reviews should be in place to assess the effectiveness of the
customer focus approach, and ideally this should be based on associated measures.
In determining the business relationship framework, the organization should take into
account:
• the needs, objectives and goals of the organization

• the market sector in which the organization operates, including normal accepted
practices
48 © BSI 2012 Version 1.1.0

Customer Focus
• the nature and type of the work undertaken by the organization, i.e. product development
or service provision
• the level and amount of interaction with customer groups (e.g. senior management,
technical specialist, users)
• other stakeholders, including suppliers and third parties
• legislative, statutory and security requirements (e.g. legislation on fraud, money
laundering and export controls)
• local cultures in terms of both implicit and expected behaviours
• methods and associated difficulties in communications and interaction with customers
(e.g. language, distances, time zones, technology).
Customer focus should be engrained in the values and working practices of the
organization. However, the framework should be described and documented in some
form. The description may be self-contained (i.e. cover all aspects of how customer focus
is addressed), or may simply describe the characteristics and considerations that must be
built into other processes and procedures, while making reference to other organizational
work products that address aspects of customer focus. These other references may exist
at various levels in the organization, and include such examples as quality plans, project
plans, terms of reference, and service delivery plans. One of the main benefits of having
a top-level overview or description of the approach to address customer focus is to allow
the approach and, more importantly, the reasoning behind the approach to be periodically
reviewed in an effective way.
Invariably, there may be many roles within an organization that have various levels of
customer focus involvement, but it is often necessary to explicitly define roles for named
individuals who are involved with specific customer-related activities. For example, this
includes staff that are directly involved in handling customer complaints, managing specific
customer accounts, and addressing the escalation of issues and problems.
Interaction with the customer can be at many levels and for many different reasons. These
should all be identified, documented and understood. For example, there may be senior
management interaction at the strategic level to address partnering arrangements, longer
term business relationship planning and problem escalation. There may also be more
regular tactical-level interaction between the organization and the customer at the project
or service delivery level. Furthermore, there may be very frequent operational interaction
at the development, technical or incident-reporting level.
© BSI 2012 Version 1.1.0 49

The level and degree of customer involvement, rather than just interaction, in the
operational aspects of the business may also vary quite considerably. Involvement in the
operational aspects differs from customer interaction, and has a potentially greater impact
on the performance, effectiveness and even, sometimes, efficiency of the organizational
processes. For example, in the classic waterfall development approach, the customer
should be actively involved in the Stakeholder Requirements Definition process, and
then be involved during the development through to the progress reviews and change
processing, before becoming involved again during acceptance. On the other hand, in the
agile model, the customer is expected to be much more actively involved throughout the
entire development cycle, including participation in SPRINT workshops or demonstrations
at the end of the lifecycle. The level and nature of customer involvement and interaction
should be fully identified, with any potential risks fully understood on the delivery of the
work. Policies may exist that indicate when and to what extent interaction and involvement
is desirable or essential, and for which type of work undertaken by the organization.
BP.2 Establish Customer Focused Procedures
As previously discussed, there will potentially be many processes and procedures within
an organization that in some way or other involve customer interaction or involvement.
Procedures around establishing customer requirements, reviewing progress, technical issues
or changes, development activities such as agile modelling, validation during acceptance,
transition and release procedures, and problem and incident handling would all fall into this
category. Given that these procedures are often written in a technical way, and often by
technical staff, organizations should ensure that the relevant levels of customer focus have
been addressed. This may be done through review by groups or individuals who are directly
involved with customers or have received specific training in customer focus.
Some organizations will provide specific training on customer focus aspects for certain
groups, especially for those who interface directly with the customer, such as helpdesk staff
and sales staff. This training can range from telephone manner, dealing with disgruntled
customers and selling techniques to negotiating skills, etc., all of which have an impact on
customer focus. The most important consideration is to ensure that, wherever possible, the
operational processes and procedures are defined in such a way as to improve customer
interaction and reduce the risk of problems and issues resulting from poor customer focus.
While a customer may be prepared to accept, or live with, the knowledge that product
and service problems do occur as a matter of course, they would be far more disgruntled if
50 © BSI 2012 Version 1.1.0

Customer Focus
there is a lack of communication over actions being taken. Proactive communication with
the customer in the event of a problem can, therefore, often circumvent escalation into a
complaint.
While it is important to look at all processes and procedures, there are a few specific
procedures that address customer focus within an organization, i.e. those covering:
• customer reviews
• feedback
• complaints
• escalation.
An organization should have general procedures for ensuring that customer reviews,
whatever form they take, comply with or address the policies on achieving adequate
customer focus. For example, the procedures should cover the following topics:
• ensuring that adequate notification is provided to the customer for planned and
unplanned reviews
• identifying the right attendees and ensuring that they are provided with an adequate
agenda
• ensuring that all logistics for the review are in place (e.g. meeting rooms, conference call
numbers, refreshments)
• ensuring that adequate confidentiality arrangements are in place to protect both
parties, especially if the customer is visiting the organization (e.g. information on other
customers is not left lying around in meeting rooms, clean desk policies)
• notification to supporting groups such as security and reception about the arrival of
customers or ensuring that the correct and expected number of people are on conference
calls
• being prepared to take adequate, and to the agreed format, records of the review
• ensuring the safety and security of the customer while at the organization
• ensuring that actions are recorded accurately and are completed in a timely manner.
Clearly, many of these aspects are not just restricted to customers, but apply to any third-
party interaction. Typically, this sort of procedure is often limited to handling the logistics,
security and safety of visitors while at an organization. However, extending them to cover
all the aspects can help to ensure a more consistent approach for all groups who may hold
reviews with the customer or their representative.
© BSI 2012 Version 1.1.0 51

Organizations should develop procedures for instigating, capturing, analysing and reporting
customer feedback, including indications of customer satisfaction. Complaint handling is
certainly one form of feedback (covered later), but in practice this is very much after the fact
and often too late to avoid loss of customer focus. There are many approaches to obtaining
customer feedback, but whichever approach is used the procedures should ensure that as
much information is extracted as possible – preferably in analytical form. The procedures
should ensure that the information is analysed and considered in terms of trends over time
and, where concerns or anomalies exist, further analysis is performed to understand the
underlying issues. Finally, the results should be reported and, if necessary, corrective action
taken or improvements put in place.
Customer complaints do happen. The complaint handling procedure should include a very
clear and well-communicated definition of what the organization deems to be a complaint.
For example, a complaint could be defined as ‘received a formally written letter to the
Managing Director which explicitly mentions “complaint”’, or it could be defined as ‘received
an incident on the help desk’. However, the definition should be balanced against the likely
or expected (through historical data) number of complaints to be received.
Similar to complaints, escalation procedures should also exist to ensure that, when things do
go wrong, the customer always feels that there is a route they can take to state their position
and to progress resolution. A definition should exist as to when escalation is necessary
and under what conditions. Not everything can, or should, be escalated. The escalation
procedure should also ensure that members of top management are not surprised when
things are escalated to them.
The most important aspects with these procedures involved in customer feedback is that
the business appropriately addresses the feedback, improves the underlying processes and
keeps the customer fully involved as to what is being done.
BP.3 Collect and Analyse Customer Feedback
The success of the organization’s approach to customer focus ultimately depends on the
views of the customer. Organizations can believe that they are delivering a good level of
customer focus, while the external perception is that they do not. If an organization does
not receive complaints it may, mistakenly, believe that everything is running along smoothly,
when in fact customers are simply not complaining, but are also not intending to return for
repeat business. Even constant levels of customer feedback may indicate problems when
52 © BSI 2012 Version 1.1.0

Customer Focus
compared, if possible, with the same indicators with competitors, where their trends in
customer satisfaction may be growing much more rapidly. The collection of good customer
feedback information is one of the most essential aspects of running a successful business.
Irrespective of the approach or approaches, the feedback should be fully analysed and,
wherever possible, compared to existing indicators. Feedback information should ideally be
expressed in some form of measurable format, although textual or conversational feedback
is also very useful. Feedback data should not just be viewed in isolation but, wherever
possible, correlated with other organizational and feedback data. For example, observing
an increase in adverse comments or a decline in some feedback score may correlate with an
increase in product distribution or service delivery. While clearly undesirable, the level may
fall within tolerable limits given the circumstances experienced. Similarly, a steady trend in
customer feedback may actually be indicating problems if some significant organizational,
product or service improvement has just been implemented.
The results of the feedback analysis should be adequately reported and, when necessary,
linked into the corrective action and process improvement systems. While not always
possible, consideration should always be given to providing the customer with some
response, even if the feedback did not result from any adverse or negative feedback. If
the customer has taken the time to provide useful feedback, be it good, bad or neutral,
some form of follow-up would be beneficial and would indicate that the feedback has been
used to help improve their supplier’s performance. Submitting feedback on a regular basis
without seeing any visible signs of it being used will eventually taint the customer’s opinion
on providing feedback.
BP.4 Review Relationship
Reviewing the relationships with customers occurs in many ways and at various levels
within the organization. For example, project progress reviews will almost certainly involve
customers or their representatives, as do service reviews during the delivery of a service.
However, such reviews often have very specific purposes and, although the relationships
play a very important part in the success of these events, they rarely focus specifically on
the ongoing relationship, unless of course related issues are evident.
In addition to the regular reviews, an organization should endeavour to hold periodic reviews
with the customer to examine the way in which the relationship is working. Clearly, this may
not be practical or feasible in all cases (e.g. an organization developing commercial-off-the-
© BSI 2012 Version 1.1.0 53

shelf (COTS) products for the mass market through online distribution). But, where a longer
term customer engagement is in place, this type of ‘stepped-back’ approach can be highly
beneficial to both parties. For example, while reviewing the business relationship, further
business opportunities may well arise that were not originally considered.
Even when the customer base is extensive and reviewing individual relationships would
be impractical, selecting or targeting focus groups (e.g. user groups) and reviewing the
general relationship may prove beneficial. For example, the review could be on how well
the organization keeps the customer community up to date with product development,
how well it deals with support and service calls, how well it adapts to changes in the
customers’ needs, etc. If no such direct contact is possible, attention to customer feedback
data becomes much more important.
Reviews may make use of the detailed feedback received, or simply consider the trends in
feedback and customer satisfaction. As indicated, a variety of reviews may be undertaken by
many people within the organization. For example, project managers will typically perform
progress reviews, service delivery managers will hold service reviews, etc. But, ideally,
any specific business relationship review should be co-ordinated and chaired by staff who
interact directly with the customers (e.g. senior management, service desk management,
sales) or have specific skills in this area, or ideally both.
The reviews should be documented, communicated back to the customer, and any necessary
actions taken to address issues or to improve the approach taken to customer focus.
Risk Management
The purpose of the Risk Management process is to provide an effective framework for
managing potential events that would adversely affect service or project performance
provided by the organization. It is important to understand the significant difference between
a ‘risk’ and an ‘issue’, as organizations sometimes use these terms interchangeably. For the
purposes of TickITplus, a ‘risk’ is considered a possible event that would adversely affect
performance, whereas an ‘issue’ is an event or situation that has actually occurred and
which requires attention. However, a risk can clearly become an issue if it should change
from a possible event to an actual incident.
Effective management of risks is essential for any business. Unpredictable or uncontrolled

events can still occur in conditions where processes are mature and operate within
54 © BSI 2012 Version 1.1.0

Risk Management
determined statistical limits. For example, normally reliable systems may be subject to
power loss, natural disaster, human error and even deliberate sabotage, resulting in
catastrophic failure. In these circumstances, it is important to appreciate the possibility
of failures occurring, understand their impact and take appropriate mitigating action. This
allows the organization to anticipate and prepare for adverse events and select alternative
strategies to maintain performance.
An organization that manages risks well may still experience undesired events, but when
risks are well managed they lead to less disruption and loss. There may be emergencies, but
there are fewer crises. By comparison, if a business ignores risk, additional consequential
risks are likely to materialize, because actions have not been taken to prevent them, and
their impact is likely to be great because mitigating actions have not been taken. The
business will be reacting, rather than acting.
Strategies for managing risk can include minimizing the possibility of the risk occurring,
transferring or sharing the risk with another party, or reducing the potential impact of the
risk. The business may also choose to accept some, or even all, of the consequences of a
particular risk.
A robust Risk Management process should include activities to formally identify and
characterize specific risks, ranking each of the possible events according to their impact
and probability. This enables the organization to prioritize the necessary mitigating actions.
Of course, risks with the greatest impact and highest impact should be handled first, while
risks with low probability and low impact should be treated as a lower priority. In reality, a
wide range of possible combinations of probability and impact are likely. Some risks may
have an extremely high impact combined with a very low probability, while others may
have a very low impact, but are very likely to occur.
The economic balance of risk management is therefore a significant factor for any
organization. It is typical for many possible options to be available to reduce the probability
of a threat, along with its impact. However, some options may be mutually exclusive, while
others are simply uneconomical. For example, any system could certainly be made more
robust by introducing multiple redundant pathways. In practice, however, this approach
is normally confined to ‘critical’ systems, being a too costly option for other less-critical
applications. The organization must, therefore, strike a balance between the negative
effects of risk and the corresponding costs of any contingency.
© BSI 2012 Version 1.1.0 55

There are six base practices defined in the BPL Risk Management process that collectively
provide the activities necessary to achieve the process outcome. These are:
BP.1 Define Risk Management Procedure

BP.2 Establish Risk Management Plan
BP.3 Identify and Analyse Risks
BP.4 Track Risks
BP.5 Report Status and Escalate
BP.6 Analyse Risk Management Performance.
BP.1 Define Risk Management Procedure
The organization should establish procedures documenting its risk management practices.
Procedures should define the arrangements for documenting risks, along with the methods
used to classify and analyse risks. This should include details of any measurement strategies
to be used to characterize risks, evaluate their impact and report status. Procedures should
also explain the required practices for establishing mitigating actions, along with the
arrangements for tracking status.
Procedures, or supporting guidelines, should also identify the possible sources of risk –
both internal and external – and provide corresponding recommendations to prevent the
risk or minimize its potential impact. Examples of sources of internal risks include:
• shortage of appropriately skilled resources

• lack of support and commitment from stakeholders
• inadequate facilities or infrastructure.
Possible sources of external risks include:
• changes in laws and regulations

• changes in technology
• downturn in economic conditions and customer business performance.
Risk management procedures should not be confined to the management of service and
project risks, but should address broader exposures within the organization, such as the
impact of severe weather conditions, fire, sabotage, or other disastrous conditions.
56 © BSI 2012 Version 1.1.0

Risk Management
Procedures should also include escalation arrangements, ensuring appropriate risks and
their status are understood by all stakeholders, including senior management.
BP.2 Establish Risk Management Plan
Risk management activities should be formally planned. Risk management plans should
be established for operational services and as part of project planning activities. Plans
should include an explanation of the risk management practices to be applied, along with
arrangements for monitoring and reporting status. As with other processes, specific risk
management practices should be tailored from the standard organizational risk management
procedures.
Risk management plans should also identify the stakeholders involved in risk management
activities, along with a description of the roles and responsibilities of the stakeholders with
respect to the risk management processes.
Risk management plans should also include a schedule of specific risk management
activities, including the resources required to complete the activity. Scheduled activities
should include regular reporting and reviews of risk status, along with the corresponding
mitigating actions, identified as part of the initial planning. Plans and schedules should
be maintained in line with progress, and should be updated with any additional tasks to
address any new risks that are identified.
BP.3 Identify and Analyse Risks
Risks should be formally identifying and catalogued. Initial identification should certainly
be undertaken as a new service or project is established. Reviews of risks should also be
undertaken on a regular and planned basis. Reviews should typically address any changes
in scope, infrastructure, organization, etc. that may have introduced additional exposures.
Reviews of risks can either be undertaken as part of status and tracking reviews (see below)
or can be planned as specific events.
Identified risks should be analysed according to their potential impact, or cost, to the
business – should the risk be realized – and to the probability of occurring. The results of this
analysis should be used to prioritize the risks. Appropriate actions should then be identified
to reduce the probability of each risk occurring and to minimize the potential impact on the
© BSI 2012 Version 1.1.0 57

organization. Consideration should be given to the economic balance of mitigating actions

against the probability and impact of the risk. Clearly, particular focus should be given to
risks of high probability with high impact.
Parameters indicating the increased possibility of a risk turning into an event should be
identified for each risk. Parameters can be quantitative or qualitative, but should include
threshold values that trigger actions to mitigate the risk or minimize the impact of the
corresponding event.
Risk parameters, including probability, impact, threshold values, etc., should be formally
documented along with mitigating actions. Corresponding tasks should be formally planned
as part of risk management planning activities.
BP.4 Track Risks
The status of risks should be reviewed on a regular basis. Reviews should consider the
progress of planned mitigating actions to ensure that they are progressing according to the
schedule, while taking account of specified thresholds. Specified actions should be taken
where threshold values have been exceeded.
Reviews should also examine any circumstances that could indicate, or lead to, an increased
probability of the risk turning into an actual event. Additional risks may also emerge, which
should be analysed and accommodated in updated plans. Where necessary, further actions
may be appropriate to mitigate new risks or to address the increased probability of an
existing risk. Conversely, changes may occur that lessen the probability or impact of a risk,
suggesting that some planned mitigations are no longer necessary.
Plans and schedules should be updated to reflect progress, changes in risk status and the
addition or deletion of mitigating actions.
BP.5 Report Status and Escalate
The status of risks should be reported according to planned arrangements. Reports should
typically be circulated to higher levels of management, depending on the status of the risks
and the potential impact on the business.
58 © BSI 2012 Version 1.1.0

Lifecycle Model Management
Escalation paths should also be formally identified, such that appropriate management,
including senior leaders, can be kept informed of the status of serious risks, particularly
where the probability of the risk becoming an actual disruptive event is increasing or
specified threshold values have been exceeded.
A variety of reports is possible, ranging from detailed numerical analysis of risks and their
status, to simple traffic light or red/amber/green (RAG) ratings.
BP.6 Analyse Risk Management Performance
Appropriate metrics should be established to monitor the effective operation of the Risk
Management process. These should be collected and analysed in order to baseline the
capability of the process and to identify trends, both positive and negative.
The performance of the risk management process should be reviewed periodically.

Performance reviews should assess the effectiveness of the process in handling risk, while
avoiding disruption or loss. Action should be taken to drive ongoing improvements in the
Risk Management process, while also addressing any adverse trends.
The purpose of the Lifecycle Model Management process is to define, develop and ensure
the availability of development lifecycle models for use within the organization. A complete
lifecycle model consists of:
• supporting policies that set the organizational bounds, desires, restrictions and use of
the defined activities within the model
• processes that are necessary to support and implement the model
• procedures for specific activities that need to be conducted
• other assets such as templates, forms, training materials and standards.
Well-defined lifecycle models are key to the successful delivery of development projects
and other programmes of work where a cycle of development is involved. By defining a set
of organizational lifecycle models, the organization will have a good understanding of the
© BSI 2012 Version 1.1.0 59

performance, implications and achievements expected from the models and, in so doing,
will significantly reduce the risks involved in the development activities on projects and other
programmes of work. It is recognized that, in order to create appropriate organizational
lifecycle models, there may be a need to pilot new or revised models on live projects or
other programmes of work. In this situation, the organization should understand the risks
involved and, where possible, mitigate against undesirable project outcomes (e.g. through
extended timescales or increased monitoring).
Successfully undertaking the Lifecycle Model Management process will result in a set of
well-defined lifecycle models that are used by projects and other programmes of work,
without the need for any non-standard tailoring. Standard tailoring guidelines may be
defined within the individual lifecycle model definitions, but non-standard tailoring may
still be necessary in certain circumstances, such as where a customer has very specific
expectations. However, it is worth noting that a minimal lifecycle model supported by
extensive tailoring options could be as ineffective as no model at all. It is very likely that
some non-standard tailoring will be required, although, as the lifecycle models have been
developed based on the organization’s business needs, the level of non-standard tailoring
should be minimal. New models should be developed or existing models refined to address
any advances in technology or changes in the business.
Metrics collected from projects or other programmes of work using the lifecycle models
and the amount of non-standard tailoring that is being performed is a good source of
information for management review. Metrics can trigger the need for revised or new
models, and demonstrate that the Lifecycle Model Management process is effective.
Organizations may need additional investment to develop organizational lifecycle models,

but the return on this investment should be seen in reduced risks, less unexpected issues
and better performance in their use.
There are many common, well-defined lifecycle models already existing in industry. However,
these models typically require significant tailoring or adapting to suit specific organizational
needs before they can be used effectively. Organizations may need to develop their own
development approaches to suit specific circumstances, driven by product requirements,
development technology and customer requirements. For example, when the customer is
actively involved in the development or where joint teams are engaged, the organization
should examine the specific needs of the stakeholders and tailor a lifecycle model that
meets these needs.
60 © BSI 2012 Version 1.1.0

There are five base practices defined in the BPL Lifecycle Model Management process that
BP.1 Establish Lifecycle Model Management Policy and Procedures

BP.2 Identify the Need for a Lifecycle Model
BP.3 Define the Lifecycle Model
BP.4 Pilot
BP.5 Review the Lifecycle Model.
Normally there is no implied sequence to the base practices in the BPL processes, but in
this case there would be a natural order to the activities to achieve a set of organizational
lifecycle models. Although the first two base practices would usually be done once, or very
infrequently, there could be multiple iterations of the other base practices catering for
different models in different stages of development and use.
BP.1 Establish Lifecycle Model Management Policy and Procedures
A top-level policy that sets out how the organization undertakes the management of
lifecycle models should be defined and communicated to appropriate staff. Typically this
policy defines:
• why the management of lifecycle models is important to the organization

• who is responsible for ensuring that the process is undertaken
• when or under what conditions it is performed
• what specific conditions or requirements must be enforced
• how it is reviewed by management.
Probably only a small group within the organization develop lifecycle models, but it is still
very important that all appropriate staff are aware of the policy and how to adopt, tailor,
use and provide feedback on the lifecycle model performance.
The lifecycle management policy should be maintained within the Integrated Management
System (IMS), with a periodic review for suitability and effectiveness.
The organization should define an organizational approach, with appropriate procedures,

work instructions, templates, forms and other associated assets, for undertaking lifecycle
model management in accordance with the defined policy. These should all be managed
within the IMS.
© BSI 2012 Version 1.1.0 61

The approach should provide the details to support the policy so that it is clear who is
responsible for all the activities involved. This includes identifying the needs, developing
the models, approving them for use and the maintenance of the models. The approach
should also provide a clear indication of the competencies required, any associated training
necessary and the mechanisms for reviewing their effectiveness, which are typically based
on associated performance and quality measures (see ORG.6 Measurement and Analysis).
If the policy and defined approach are not enough to show how the process is undertaken,
supporting procedures may be used to provide specific instruction on activities, e.g. a
procedure that addresses the review of the effectiveness of the lifecycle model following
its use on a development project or other programme of work. The need for supporting
procedures should be governed by the familiarity and competency of the staff in the
component activities. For example, the personnel creating the lifecycle models should
typically be competent to undertake their activities unaided, but the project staff may need
additional instructions built into the project management processes and procedures to
explain how to review the effectiveness of the lifecycle they have adopted.
Standards covering the lifecycle activities should be established to ensure that the products
being developed can be fully maintained in the future, or, where necessary, be reused on
other development projects or other programmes of work.
BP.2 Identify the Need for a Lifecycle Model
The need for a lifecycle model can be triggered from multiple sources and at various
times, including the review of the effectiveness of the lifecycle in use (see BP.5 Review the
Lifecycle Model). Once an organization starts undertaking repeated development activities,
it will soon identify that having a defined, well-understood and appropriate lifecycle model
reduces the development of risks and maintains consistency.
Non-standard tailoring of the selected lifecycle model may be needed, although this should
be minimal if the models have been appropriately defined. As business needs evolve and
technology changes, the amount of non-standard tailoring would, if no action is taken,
start to increase to such a point that the use of the model would be ineffective. Regular
monitoring of the amount of non-standard model tailoring being undertaken provides an
important trigger to consider whether revising an existing model or creating a new one
is necessary. While this can be done through reviews of project documentation, a more
effective approach is to review associated metrics. Here, metrics help to highlight trends
that may not be evident from individual reviews.
62 © BSI 2012 Version 1.1.0

External sources, such as customer needs and industry developments, can also trigger
a need to revise or create a new lifecycle model. Relying on non-standard tailoring to
handle the exceptions may be acceptable initially, but, over time, would increase the risk
of inconsistencies and omissions, resulting in more planning effort with potentially less
effective results.
BP.3 Define the Lifecycle Model
The stakeholders and resources identified in the lifecycle model management approach
should investigate how to define the lifecycle model. Typically, this will involve listing
and reviewing what needs to be addressed by the lifecycle model. Any existing internal
practices or models, as well as the models already commonly defined within industry,
should be considered against the list of requirements. A suitable lifecycle model is defined
in accordance with the lifecycle model management approach. The use of a formal decision-
making process such as the one defined in the Decision Management process (PRJ.2) should
be used to control the process.
The definition of the lifecycle models should be formally documented and provide a clear
indication of the purpose, policies, development stages, decision points, input and output
data and information needs, specific roles and responsibilities, associated tools, templates,
forms and any necessary training needs and assets. The definition may exist in multiple
formats. For example:
• the purpose and policies may be combined in a single document

• the development stages and decision points could be inbuilt in an appropriate workflow
management tool
• the roles and responsibility could be specific or generic, and hence already exist in
common documentation
• templates and forms could be online or intranet based
• the training material could be through computer-based training or simply by the
identification of external course providers.
While there are no specific requirements for how the lifecycle models are defined and
made available, a consistent approach should be used to allow easier adoption, greater
familiarization and simpler maintenance over time.
© BSI 2012 Version 1.1.0 63

In defining multiple lifecycle models it is necessary to make clear when it would be

appropriate to use a particular model. The critical factors that make the model work should
be defined, such as relationship and interaction with the customer and suppliers, timescales,
requirements stability, availability of data, etc.
As described previously, there may be standard and non-standard tailoring for a defined
lifecycle model. While the former is acceptable as part of the model and can be effective
in allowing a single model to be used for a number of different situations, the latter needs
careful monitoring. The standard for authorized tailoring may range from none being
allowed (e.g. in the case of safety critical developments), through to providing a range of
acceptable adaptations for a particular model.
The defined lifecycle model should cover the following lifecycle phases:
• Stakeholder Requirements Definition

• Requirements Analysis
• Architectural Design
• Development Implementation
• Integration Management.
The lifecycle model should be documented and should specify the purpose, stages, decision
points, data, roles and responsibilities, relevant tools, templates, forms and training needs.
BP.4 Pilot
In many cases the new lifecycle may have already been used in some form or may have been
applied as part of satisfying previous needs for lifecycle models. In other cases a new model
may have to be defined based on multiple sources. Whichever the case, the new model
should be piloted within the organization to ensure that it fulfils the needs, as described
through the list of requirements.
Piloting a new lifecycle model may be done on an internal project or a live customer project.
Ideally, a project that has the lowest risks should be used, but this may not always be
possible. Therefore, piloting a new model should be considered alongside other potential
risks that exist on the project. The risks could be shared with the project customer, especially
if the need for the new model originated from the customer, or may have to be accepted
64 © BSI 2012 Version 1.1.0

Project Management
wholly internally by the organization. In either case, appropriate risk management should
be applied and suitable mitigation put in place (see ORG.8 Risk Management).
The pilot activities should follow those defined in the lifecycle model management approach,
but should include additional activities to provide clear awareness to the pilot participants
of the nature of the pilot, the specifics of the model and any associated training. Models
could fail to deliver, not because there are any inherent problems, but because people are
not familiar with what is required.
The result of the pilot should be fully reviewed and any necessary adjustment made to the
defined model before finalizing the lifecycle model for approval and use.
BP.5 Review the Lifecycle Model
The final activity in the cycle is to review the effectiveness of the lifecycle and, if necessary,
trigger a revision to the lifecycle model or create a new one. Typically, this is done at the end
of the development project or other programme of work through some form of lessons-
learnt or feedback session. However, periodic reviews of how well the models are working
as development progresses can take place and, if necessary, improvement actions to the
group responsible for lifecycle model management be proposed.
Project Management
The purpose of the Project Management process is to provide a formal framework for
planning, organizing and managing resources to achieve successful completion of a project.
The actual definition and characterization of a project typically vary from one organization to
another. However, the term ‘project’ generally refers to significant undertakings, with well-
defined start and end points, which are established to achieve a specific set of objectives.
A project is therefore likely to involve multiple resources, while being constrained by
scope, time and budget. The aim of any project should therefore be to achieve a successful
outcome within these three constraints.
Some organizations may also choose to run continuous services as an annualized project.
In this case, the plan for the service is again constrained by scope, time and budget – but
in this case:
© BSI 2012 Version 1.1.0 65

• scope is the capacity for the service for the year

• time is the annual schedule
• budget is the cost of the service over the year.
Thereafter, the same principles for project planning and control can be applied.
Formal project management disciplines should therefore be applied whenever a significant

activity is undertaken. This includes, but is not limited to:
• the development of a new IT service

• the introduction, refresh or refurbishment of facilities
• the development of bespoke application software
• the implementation of a packaged-based solution
• a significant change to or maintenance of a system
• an internal business initiative, such as to establish a new process.
While the context, resources, skills, etc. of each of these activities may vary significantly, the
basic disciplines of project management should remain the same. An organization should
therefore establish a standard Project Management process that can then be formally
tailored to meet the particular needs of any project that may be undertaken. This has to
be done with some care, and rules and guidance for tailoring should be formally defined
to enable the project management approach to be adapted for a range of projects, while
ensuring the core disciplines are observed.
Likewise, projects rarely work in isolation. Instead, projects typically have a number of
related stakeholder groups. These are likely to include the client (or clients), management
and the staff supporting the project work. Additional stakeholders may include third-party
suppliers, infrastructure teams, training groups, etc. To be successful, it is essential for the
roles and responsibilities of all stakeholders to be understood and their participation on the
project monitored.
Project management accommodates a number of practices. For example:
• projects will generate work products and deliverables that must be maintained under
configuration management
• quality assurance should be formally managed throughout a project’s life
• specific training may need to be provided to staff
• effective communication will need to be established among stakeholders, etc.
66 © BSI 2012 Version 1.1.0

Project Management
All these processes must therefore be accommodated within the project management
discipline. In larger projects, this may require the preparation of separate plans, schedules
and controls covering each process. On smaller projects, these activities may be combined
into a single plan and schedule, with common reporting and controls.
The use of common project management reporting methods, with unified measurements
and metrics, should also be established. This allows an organization to monitor the overall
performance of its Project Management process, while providing objective indications of
where opportunities exist to bring improvements to subsequent projects. While common
project management and data collection tools would certainly aid this approach, it is quite
possible to collect the metrics and complete the analysis manually.
Project management activities can be complex and challenging to operate, as projects

may very well cut across organizational groups, requiring careful co-ordination of a variety
of resources and disparate activities to achieve a successful outcome. Here, for example,
larger projects may comprise a number of sub-projects that must be integrated through
an overall programme of work. An organization undertaking larger programmes of work
should therefore ensure that its Project Management processes can also accommodate the
management and integration of any subordinate projects.
There are eight base practices defined in the BPL Project Management process that
BP.1 Establish Project Management Policies and Procedures

BP.2 Scope the Project
BP.3 Plan the Project
BP.4 Initiate the Project
BP.5 Monitor and Control the Project
BP.6 Manage Risks and Issues
BP.7 Manage Changes to the Project
BP.8 Close the Project.
BP.1 Establish Project Management Policies and Procedures
Project management policies should be established by management to provide the

overall framework for project management activities, along with the governing rules to
© BSI 2012 Version 1.1.0 67

be mandated across the organization. Project management policies should be aligned to

business needs, but should also reflect stakeholder expectations.
The organization should also establish procedures to support the Project Management
process. Procedures should explain how project management practices are to be
implemented by the organization and should be supported by standards or templates that
define the content of project management work products.
Procedures and standards should be sufficient to cover the range of projects, in terms
of size, complexity, scope, etc., that the organization is likely to undertake. The project
management approach should also be flexible, in order to allow the process to be tailored
to fit the specific needs of a given project. Tailoring instructions and guidelines should be
available to explain how the procedures can be adjusted to support any project, while
maintaining the overall integrity of the process.
As with all organizational processes, the project management policy, along with supporting
procedure and standards, should be maintained within the Integrated Management System
(IMS) arrangements, with a periodic review for suitability and effectiveness.
BP.2 Scope the Project
A formal definition of project scope should be established and agreed prior to project
commencement. The scope statement should describe the overall objective of the project,
along with key outcomes and corresponding deliverables. The scope statement should also
include a description of the overall schedule, with an outline of delivery milestones and
intended completion dates.
Even at this early stage, consideration should be given to the availability of resources
needed to support the project, including the associated infrastructure, tools, etc., together
with the personnel and their required competencies. Formal estimates of effort and cost
may also be prepared at this point (see BP.3 Plan the Project), provided a clear definition of
requirements is available. However, if this is not the case, any estimates should be confined
to rough-order estimates, which can be validated once a good baseline of requirements has
been established, together with a high-level work breakdown structure.
An initial analysis of assumptions, risks and issues should also be undertaken at this
point. These should be formally documented as part of the scope statement. Appropriate
68 © BSI 2012 Version 1.1.0

Project Management
contingencies should also be identified, taking these factors into account. Clearly, it would
be prudent to allocate higher levels of contingency for high-risk projects.
BP.3 Plan the Project
Effective project planning is fundamentally dependent on a clear and adequate definition

of requirements for the project and its outcomes. Planning involves the identification
and specification of the work products needed to meet the requirements, and the tasks,
including effort, facilities, costs, etc. required to produce these work products. The
planning process results in the preparation of plans and project schedules. Although the
terms are often considered to be synonymous, there are significant differences between
a ‘plan’ and a ‘project’ schedule. Here, TickITplus expects plans to be the formal managed
documents that define the approaches to be applied on the project, whereas the project
schedule comprises the work breakdown and network of tasks to be undertaken to fulfil
the project.
Plans should be prepared that address the specific needs of the project, based on the project
scope and requirements. Plans should detail the specific approaches to be taken during the
execution of the project, which should be tailored from the organizational standard. Plans
typically document, or refer to, the:
• scope of project
• requirements of the project
• technical approach and lifecycle to be adopted
• work products to be produced, along with their size, complexity, etc.
• estimates and the estimating methods applied
• tasks to be undertaken, both technical and management, to complete the project
• methods to be applied for overall project management, configuration management,
quality management, communications, etc.
• specialist training that may be required for staff
• tools and infrastructure to be used to support the project
• project work breakdown and schedule.
Plans should also identify the assumptions and constraints that influence the project, along
with the effect that these have on the planning and execution of the project, such that
stakeholders can be made fully aware of these conditions.
© BSI 2012 Version 1.1.0 69

On larger projects it is usually appropriate and necessary to divide plans into a number
of separate documents, such as an overall plan with supporting plans for configuration
management, quality management, communication, training, integration and test, etc.
Particular attention should be given to the skills and competencies of the project team at
this stage. Project resources should be assigned on their ability to contribute effectively to
the project. However, additional training may be required for inexperienced staff or where
new or specialized tools are being applied for the first time. Again, any required training
should be accommodated as part of the formal planning activities. Training can take many
forms and certainly does not mean that individuals must attend specific off-the-job training
courses. Here, alternatives can include on-the-job training, mentoring and computer-based
training modules. Irrespective of the training methods applied, arrangements must ensure
that the team members are equipped with appropriate skills and competencies, and that
records of their development, as part of the project, are maintained.
A work breakdown structure should be prepared for every project. The work breakdown
structure should itemize the tasks that are to be undertaken and should be derived from
the objectives, scope and specified requirements for the project. In larger projects, the
work breakdown structure is likely to include a hierarchy of work, where major work
components or activities are subdivided into their subordinate tasks. The work breakdown
should result in a series of individual tasks representing the smallest unit activity that the
project manager can schedule and control. Each task in the work breakdown should then be
formally assigned an ‘owner’, who is responsible for completing the task.
Key milestones should also be determined, which can be used to gauge the overall progress
of the project. Milestones are typically defined at a high level, and represent key points in
a schedule such as an interim achievement. Milestones usually signify the completion or
delivery of key work products.
Estimates for each activity should then be prepared using a formal and systematic approach.
Estimates should be based on an appropriate ‘sizing’ method, using historical data to
determine the duration and cost of each activity in the work breakdown, while also taking
the complexity of the work into account. Examples of measures for size include:
• function points
• lines of code
• number of requirements
70 © BSI 2012 Version 1.1.0

Project Management
• number of objects
• number of pages.
While is it appropriate to validate estimates through expert judgement using experienced

subject matter experts, estimates of cost and duration should not be guessed, but should
be based on suitable sizing methods.
Tasks in the work breakdown structure and corresponding milestones should be re-
integrated using an appropriate ‘network’ planning method, such as the program evaluation
and review technique (PERT) or critical path method (CPM). These techniques allow
the project manager to schedule activities and allocate resources effectively, while also
highlighting the key tasks and critical path that are crucial to completing the project on
schedule. (Computer-based project management tools generally have these facilities that
automate network-based planning as standard). The project schedule should also clearly
indicate when milestones are to be achieved.
The final stage of this activity is to formally baseline the plans and schedule for the project.
At this point, plans should include a comprehensive description of the project management
approach, which is supported by a project schedule with delivery dates, milestones, etc.,
along with the costs and projected budget for the project. The plans should be reviewed and
formally approved by key stakeholders prior to commencing the project. Once baselined,
the plans, schedule and any supporting documentation should be maintained under formal
change and configuration control.
BP.4 Initiate the Project
The initiation phase of a project is necessary to engage the project team and other
stakeholders, gain their commitment to the project and mark the formal commencement
of the project.
Formal launch of a project may take various forms, including formal walk-through meetings
to communicate the project’s scope, objectives, project management approaches, etc.
These kick-off sessions may include the customer and management representatives, but
are intended to ensure that all stakeholders, including the project team, fully understand
their roles and responsibilities with respect to the project. Records of any reviews should be
maintained, particularly where agreements and understanding of requirements are ratified.
© BSI 2012 Version 1.1.0 71

The initiation phase also provides a further opportunity to ensure that the requirements
for the project are fully understood, along with planned arrangements to fulfil the project.
However, any amendments to be made to requirements descriptions, plans, specifications,
etc. arising from reviews during the initiation phase should be managed under formal
change control.
Special instructions, such as precautions necessary to address security restrictions, access

controls, use of tools, time keeping, etc., should also be communicated at this point.
BP.5 Monitor and Control the Project
The project plans and schedule are the basis for executing the project. Status against
planned activities should be regularly and formally monitored throughout the life of the
project to understand how the project is progressing and to take appropriate corrective
action where the project deviates from plans.
The status of the project should be analysed to objectively determine the actual progress
being made. Analysis of progress can take many forms. For example, some organizations
use ‘earned value’ methods to plot the achievements of their projects.
The results of this analysis, and the corresponding status, should be reported to stakeholders,
including the client, senior management and other project participants, on a regular and
planned basis. Reports should indicate the overall progress of the project, its achievements
and planned activities. Reports should also highlight any emerging risks and issues, and
report the status of any existing risks and issues.
Regular and planned progress reviews should also be established with key stakeholders to
formally review the status of work in progress, as well as completed tasks. Other factors
reflecting the status of the project should also be formally reviewed. These include, for
example, the status of any actions arising from previous reviews, and the status of risk
and issues. Records of status reviews should be maintained, along with any actions, which
should be tracked to closure.
Corrective actions should be taken where actual progress deviates significantly from
plans. Corrective actions may be simple adjustments, mitigating activities or may require
realignment of the overall plan. Any required changes to plans and schedules should be
formally recorded and managed through formal change control. Corrective actions should
72 © BSI 2012 Version 1.1.0

Project Management
be formally recorded and should be assigned to an owner responsible for implementing the
action. Corrective actions should be tracked to closure.
Formal milestone reviews should also be established. These should be scheduled at key
stages in the project and should be used to provide an overall indication of the achievements
of the project. As with other regular reviews, formal records of milestone reviews should be
maintained, along with records of any actions arising, which should be tracked to closure.
BP.6 Manage Risks and Issues
The purpose of the Risk Management process is to provide an effective strategy for
managing potential events that would adversely affect project performance (see ORG.8 Risk
Management). It is important to understand the significant difference between a ‘risk’ and
an ‘issue’, as organizations sometimes use these terms interchangeably. For the purposes of
TickITplus, a ‘risk’ is a possible event that would adversely affect the project performance,
whereas an ‘issue’ is an event or situation that has actually occurred and which requires
attention. However, a risk can clearly become an issue if it should change from a possible
event to an actual incident.
Effective management of risks and issues is essential for any project. Unpredictable or
uncontrolled events can still occur on a project, despite rigorous planning and preparation.
Thus, it is important to appreciate the possibility of failures occurring, understand their
impact and know how to take appropriate mitigating action. This allows the organization
to anticipate and prepare for adverse events and select alternative strategies to minimize
disruption to the project.
Risk and issue management activities should be formally planned as part of the overall
project plan and schedule. Plans should include an explanation of the risk and issues
management practices to be applied, along with arrangements for monitoring and reporting
status. As with other processes, specific risk management practices should be tailored from
the standard organizational risk management procedures.
Project risks and issues should be formally identified, analysed and catalogued according
to their impact on the project. Initial identification should be undertaken as the project is
established, but this should be refined as plans are developed, providing a comprehensive
baseline as part of the project plan.
© BSI 2012 Version 1.1.0 73

Reviews of risks and issues should be undertaken on a regular and planned basis. Reviews
should consider the status of existing risks and issues, but should also address any changes
in scope, infrastructure, organization, etc. that may have introduced additional exposures to
the project. Reviews of risk can either be undertaken as part of status and tracking reviews
(see above), or can be planned as specific events. Actions to address project issues or
mitigate risks should be formally recorded. Where necessary, these may give rise to formal
changes to the project in order to integrate actions into the overall plans and schedules. All
actions should be tracked to closure.
BP.7 Manage Changes to the Project
All but the most trivial projects tend to operate on an iterative basis. Despite the best
efforts of the most experienced project team, requirements develop and often become
clearer as a project proceeds. Similarly, risks and constraints may become more significant
as progress is made. Change is therefore inevitable, and effective change control is essential
if the overall objectives of the project are to be achieved.
Changes typically fall into two categories – those required to correct omissions or deviations
in the project, and those required to add or remove functionality in some way or change
the way in which functionality is implemented. In order to be successful, it essential that a
project is supported by a formal and effective change management discipline. All requested
changes should be formally logged and should identify the scope of the potential change,
along with details of requirements, be they functional or general.
All change requests should be formally reviewed. Reviews should consider the impact on
the project, including costs, delivery, timescales, etc. Recommended actions should then
be documented indicating how the change would be incorporated in the project. Changes
should be subject to formal review and approved by authorized stakeholders, prior to
implementation. Details of approved changes should be communicated to all other relevant
stakeholders.
Minor changes may require only small adjustments to plans, schedules, etc. However,
major changes would be likely to require significant revision of plans, schedules and work
products. In these instances, the same planning disciplines should be applied as are used to
establish the initial plan and schedule. Modified plans should be updated and re-baselined
to reflect the intended change.
74 © BSI 2012 Version 1.1.0

Configuration and Change Management
All documentation and work products affected by the change should be annotated within a
change history, or similar, to provide traceability of the change. Corresponding configuration
records should also be updated to record changes to work products (see PRJ.3 Configuration
and Change Management).
BP.8 Close the Project
Formal closure of a project is necessary to complete a number of important activities.

Foremost is to identify lessons learned from the project. Here, stakeholders should be
invited to comment on activities and work that went well, together with a critique of tasks
that did not perform satisfactorily. This activity is important, even if the overall performance
of the project was sound. Poor performance should be analysed to identify the root cause
of the problem, and formal actions should be taken to avoid reoccurrence in subsequent
projects. This may, for example, require change to the overall procedures governing project
management activities. Actions arising from lessons learned should be logged and tracked
to closure.
Work products generated by the project, along with supporting documentation, records,
etc., should be protected against loss or damage following closure of the project. Some work
products may be used as part of operational systems and should be managed under normal
operational configuration and change control; while other, project-specific, material may
be archived. Retention periods for documentation, records, data, etc. should be managed
according to formal organizational procedures.
Any final project metrics should also be submitted at this point. This may include, for
example, actual performance against estimates, allowing historical data to be used to
estimate subsequent projects to be updated, while also providing metrics to monitor the
overall performance of the Project Management process.
The purpose of the Configuration and Change Management process is to establish the
methods necessary to control the identification, recording and reporting of the components
that make up an IT system, while tracking the relationship between the constituent
components. In practice, this means that both the physical and the logical associations
© BSI 2012 Version 1.1.0 75

between system components should be tracked, including the relationships between

applications, mainframes, servers, networks, project work products, documentation, etc.
Much is written about configuration and change management and, while the principles are
straightforward, commentators suggest that organizations struggle to implement these vital
processes fully and effectively. Given the increasing complexity of and interrelationships
between information systems, coupled with the unprecedented opportunities to integrate
systems, in real time, across the globe, it is easy to see why this can be a significant challenge
for anything but the most simple systems. But, of course, the risks and impact of poor
configuration and change management practices can be serious and, in some cases, life-
threatening. For example, consider the threats of such a lack of control in a medical or other
safety critical application.
While it is possible to implement a ‘manual’, or even paper-based, configuration and

change management system, a wide range of sophisticated tools is available to support the
process, and it is likely that organizations will apply one or more of these tools. While there
are obvious benefits in automating the process, care must be taken to ensure that the tools
are implemented in a manner that adequately addresses the complexities of the systems
and the demands of the process, along with stakeholder needs – including the client and
end-users.
Effective configuration and change management must be applied as an integrated process

within any software development or systems integration project. Here, the process must
establish the controls necessary to track status, system components, work products, data,
etc. at each stage of the development lifecycle, while providing systematic and rigorous
control of both functional and non-functional changes. The process should also address
formal traceability through the development lifecycle, ensuring that system requirements,
performance and functionality are traceable to related subsystems and components.
Configuration and change management must also be applied to operational services,

providing formal records of all the components and supporting assets within operational
systems, including supporting documentation.
The outcome of the Configuration and Change Management process is that the status,
version and relationship of all products, work products and associated components are
known at all times. The Configuration and Change Management process should also provide
adequate control of non-conforming products or services.
76 © BSI 2012 Version 1.1.0

The complexity of modern products and systems makes any attempt to record and fix the
configuration at the end of a development very difficult, if even possible. By managing the
configuration throughout the project, the effort is kept relatively low and the task more
manageable.
There are six base practices defined in the BPL Configuration and Change Management
process that collectively provide the activities necessary to achieve the process outcome.
These are:
BP.1 Establish a Configuration and Change Management Policy and Procedures

BP.2 Plan Configuration and Change Activities
BP.3 Establish Configuration and Change Management System
BP.4 Manage Configuration Items
BP.5 Manage Baselines
BP.6 Manage Changes.
BP.1 Establish a Configuration and Change Management Policy and

Procedures
As with other processes, proactive and visible commitment of top management to the
Configuration and Change Management process is essential. This commitment should
be reflected in an organizational policy that sets out the organizational requirements and
expectations for configuration and change management.
The configuration and change management policy should be approved by the highest
authority within the organization. It should be communicated and explained to all members
of staff, irrespective of grade or position within the organization.
The configuration and change management policy should be maintained in line with the
current needs of the business. The policy should be reviewed and, as necessary, updated
on a regular and planned basis. Changes in policy should be formally communicated to staff,
along with details of any corresponding changes in process and procedures.
The policy for configuration and change management should be implemented through
procedures and supporting standards that define how the policy is put into practice. The
definition of configuration and change management procedures and standards is critical, as
© BSI 2012 Version 1.1.0 77

these are used to explain how the configuration of systems, both hardware and software,
is to be effectively maintained.
BP.2 Plan Configuration and Change Activities
A configuration management plan should be established that describes how configuration

management procedures and standards are tailored to a specific system (hardware,
software or both) during development, implementation and operational use. Configuration
management plans may take many forms. For example, they can be established as an
integrated part of development project plans, or be stand-alone documents covering the
management of operational systems, etc.
The configuration management plan should describe arrangements for establishing and
managing baseline(s), along with the methods for controlling changes to the baselines –
where these are specific to the system in question. The configuration management plan
should also identify the configurable items, including hardware, software, data and
documentation to be placed under configuration control – including any designated
development work products, support tools, etc. that are related to a project.
The configuration management plan provides the foundation for managing configuration
management functions, including arrangements to be applied throughout a project lifecycle
or delivery of a service. The plan should describe specific arrangements and describe, or
refer to, appropriate standards for:
• configuration identification
• configuration control
• configuration status accounting
• configuration audit.
The configuration management plan should explicitly assign responsibilities for each
configuration management activity, including responsibilities for managing configuration
items, components and related work products. In most instances it is also appropriate to
assign a configuration manager for each area of work. This can be a dedicated full-time role
or an assigned responsibility as part of an employee’s broader work.
Configuration management plans should describe arrangements for managing changes

during development and system integration, as well as operational use of systems. Again,
78 © BSI 2012 Version 1.1.0

change control extends to hardware, software, data, documentation and other relevant
work products.
Arrangements should be established to ensure that configuration management activities

are supported by adequate funding and resources.
BP.3 Establish Configuration and Change Management System
Fundamental to the implementation of an effective configuration and change management

system is the identification and management of the components, or configuration items,
that make up a system (or intended system).
The configuration management system comprises the controlled repository for storing ‘soft’
configurable items – along with the mechanisms to track the components, i.e. hardware,
software, data, etc., that comprise a system at each stage of its development. The system,
or systems (as development and operational configuration management systems can be
distinct), should have appropriate mechanisms to maintain the integrity of the configurable
items. Supporting configuration records should be kept throughout the development and
operational life of a product or service. The configuration management system should also
include appropriate access controls to prevent unauthorized or inadvertent changes to
configurable items.
Many sophisticated tools are available to support configuration management and change
management. These typically provide a wide range of facilities and extensive functionality,
but it is equally valid to establish a manual configuration management system, with controlled
areas of storage and formal practices for checking-in and checking-out configuration items,
along with records for tracking baselines, maintaining traceability, etc. However, care must
be taken to ensure that the configuration and change management system is appropriate
and is compatible with the size and complexity of the systems it is intended to support.
As well as supporting the necessary configuration and change controls, the configuration
management system should accommodate appropriate back-up and recovery facilities to
ensure that configuration items are protected from potential loss, damage or corruption.
Supporting procedures and standards should be established to define the practices for using
the configuration management system. These should be appropriate to the sophistication
© BSI 2012 Version 1.1.0 79

of the configuration management system and the complexity of the products and systems
being managed.
BP.4 Manage Configuration Items
Configuration items come in a variety of forms. For software, a configurable item is certainly
the code that makes up a module within a system. However, many other work products
that support the development and operational use of the code should also be treated as
configurable items. These include, for example, specifications (covering requirements,
design, verification, validation, etc.), data, system documentation, and so on. Hardware
configurable items include mainframe equipment, services, networks, desktop equipment,
development environments, etc.
In all cases, appropriate controls should be established to ensure that configurable items can
be uniquely identified and tracked (i.e. through version control), along with the ‘build’ (or
configuration) of the system at each stage of its life from development, through operation,
to eventual retirement.
The controls should support the necessary traceability, audit and tracking activities intended
to maintain the integrity of the configurable items and the systems they support.
BP.5 Manage Baselines
Effective management of baselines is the foundation of the Configuration and Change

Management process. The configuration baseline is used to show the relationship between
configuration items at a particular point in time, providing a formal datum for monitoring
configuration status and applying change control. It would be impossible to determine and
track the impact of change without a clear definition of an initial state.
Baselines are typically established at key points through development and in use, and should
be formally authorized in some way. In development, for example, baselines may reflect the
agreement of requirements, authorization of design, release of code from one environment
to another, delivery, etc. Baselines mark the point at which configurable items are brought
under formal configuration control, denoting the point from where formal change control
is applied. Formal records of baselines should therefore be maintained. These should detail
80 © BSI 2012 Version 1.1.0

the identity and version of each component (or configurable item) that is included in the
baseline, along with the relationship between the configurable items. The configuration
records should also be maintained under formal control.
Configuration verification and audit should also be linked to the baseline controls. Here,
checks should be applied to ensure that the actual configurable items including hardware,
software, documentation, data, etc. that make up the baseline address the specifications
and expectations (i.e. a functional configuration audit) and are accurately reflected in
baseline and configuration records (a physical configuration audit). While this may include
review of compliance of working practices to the configuration management procedures,
the focus of configuration verification and audit is to ensure the validity and integrity of
declared baselines. A configuration management audit, i.e. checking the integrity of
configuration items and corresponding baselines, is not the same as an audit of configuration
management, i.e. checking the effectiveness of the configuration management process,
although there is clearly significant overlap in these practices.
Procedures for conducting configuration verification and audits should be defined and should
include the sampling and inspection methods to be applied. Configuration verification and
audits should also be formally planned, and records of the outcome should be maintained.
Any defects or discrepancies identified through verification and audit should be logged,
along with appropriate corrective action, which should be tracked to closure.
BP.6 Manage Changes
Effective management of changes is vital in any organization. Change management practices

should include methods to:
• document requested changes and their associated requirements

• evaluate the impact of requested changes
• review and approve changes
• implement approved changes
• verify implementation of the change.
Change requests should be formally documented and logged, and should include, or refer
to, an adequate specification of requirements, such that the impact of the change can
© BSI 2012 Version 1.1.0 81

be determined and evaluated. Further information and/or clarification should be sought

where change requirements are unclear, ambiguous or insufficient.
The impact of requested changes should be formally evaluated. This should include an
analysis of the effects on specific configurable items, as well as the potential impact on
performance, security, costs, contract, etc., along with the determination of the feasibility
of the change.
All changes should be subject to formal approval by appropriate authorities, taking the
conclusion of the impact analysis into account. Changes may require multiple approvals
from stakeholders prior to implementation. The authorities required to approve changes
will often vary according to the nature of the requested change and its impact. The
approval process should be formally defined, along with identification of the authorities
able to approve change requests. Changes to the baselines should only be implemented
after required approvals have been obtained.
In many organizations a formal change (or sometimes configuration) control board (CCB) and
release control board (RCB) are established to manage changes and releases. These boards
usually comprise representatives from stakeholder groups involved in the development
or service provision processes (e.g. project management, development, configuration
management, test, release, support). The boards usually meet on a periodic or event-driven
basis, and can be undertaken in person or virtually, through electronic means. Whatever
the approach, the main emphasis of these forums is for stakeholders to understand and
approve, or reject, the requested change and subsequent release.
Approved changes should be implemented and affected configurable items revised as

necessary. Bidirectional traceability should be maintained between change requests and
the configurable items that are affected by the change. Appropriate versioning methods
should be applied to track modified configurable items, which should be re-established
under formal configuration control.
Changes should be formally verified and signed off to ensure that the revised product, or
service, addresses specified requirements, while ensuring that only authorized changes are
implemented. Any defects arising from test and verification should be logged, along with
corresponding corrective actions, which should be tracked to closure. Records of verification
and acceptance should be maintained.
82 © BSI 2012 Version 1.1.0

Problem and Incident Management
Problems and incidents are different, but very closely linked. A ‘problem’ typically relates
to a state of difficulty that requires resolving, whereas an ‘incident’ typically relates to an
individual issue or concern. Problems can arise from many situations, including the existence
of multiple related incidents. Incident management is concerned with rectifying particular
incidents, whereas problem management is aimed at understanding the causes of incidents
in order to prevent their reoccurrence.
TickITplus covers many IT activities where problems and incidents can arise from multiple
sources. The Problem and Incident Management process is therefore intended to cater
for all the situations that could exist within organizations. For example, within software
development, reported bugs or defects could be considered incidents, each one of which
would require resolution under incident management. If, through understanding the cause
of similar defects, a theme is identified (e.g. that they all relate to a design inadequacy), then
there could be a problem in the design process that needs to be addressed. Incidents and
problems can also occur in other disciplines, including service provision. Here, an incident
would be considered the loss or degradation of a service, and problems would represent
the underlying causes of incidents.
Problems and incidents exist within such disciplines as project management, although often
grouped under the common term ‘issues’. While, the distinction between ‘problem’ and
‘incident’ in project management is not often applied, benefits can be gained by applying
the classifications for resolution purposes. Here, for example, missing a scheduled milestone
or receiving an audit finding could be classed as an ‘incident’, which requires corrective
action. Whereas missing multiple milestones or constantly receiving audit findings could
indicate a ’problem’ exists that needs further work (e.g. in the project planning, estimating
or definition processes). In many cases, these problems are only identified at the end of the
project through a closure review or lessons-learnt workshop. However, earlier identification
of such problems can lead to timelier implementation of organizational improvements for
the benefit of other existing, or new, projects.
The resolution of incidents can involve many techniques, and in some cases certain other
TickITplus processes apply. For example, the resolution of specific defects may invoke the
need for software maintenance, as described in TEC.8 Maintenance Management.
The outcome for the Problem and Incident Management process, as with other TickITplus
processes, requires the process to be implemented effectively within the organization. By
© BSI 2012 Version 1.1.0 83

definition, incidents cannot be prevented, and therefore the outcome is for incidents to
be identified and rectified appropriately (e.g. to correct the bug or defect, re-establish the
service or resolve the project issue).
Similarly, and by virtue of having incidents, problems cannot always be prevented, but the
reoccurrence of the same problem would be a major concern for an organization. This
would suggest that the Problem and Incident Management process is not being effective,
and therefore is not as expected by TickITplus. Clearly, drawing this conclusion is predicated
on there being a very clear, distinguishing and appropriate definition of an ‘incident’ and a
‘problem’.
As discussed, problems cannot totally be avoided, but the organization is expected to

proactively address the potential causes of incidents, and therefore problems. This is
generally achieved through effective risk management (see ORG.8 Risk Management).
The BPL Problem and Incident Management process consists of four base practices. These
are:
BP.1 Define Problem and Incident Management Policies and Procedures

BP.2 Record and Manage Incidents
BP.3 Avoid and Resolve Problems
BP.4 Escalate Incidents and Problems.
BP.1 Define Problem and Incident Management Policies and

Procedures
Because problems and incidents may exist in multiple ways within an organization, it is
important that policies exist to ensure that organizational staff have a clear understanding
of what is expected in dealing with problems and incidents. This understanding extends to
a clear definition of what is considered a ‘problem’ and an ‘incident’, clarification on the
expected resolution and analysis processes, the roles and responsibilities of staff involved,
the timescales required, and the records to be maintained.
As with all other policies in TickITplus, the problem and incident management policy should
be defined, reviewed, approved by top management and communicated throughout the
organization.
84 © BSI 2012 Version 1.1.0

Problem and incident management activities, particularly problem management, can be

complex and involve a number of organizational groups. For example, within systems and
software development and maintenance activities, bugs or defects (incidents) may be
handled by the test team, installation team or support team, yet any underlying problem
resolution would likely be undertaken by the development groups.
Procedures should specify arrangements for the recording, resolution, monitoring,

reporting and escalation of problems and incidents. Depending on the particular nature of
the incidents and problems within an organization, other factors that should be considered
include appropriate prioritization, classification, business impact, importance and cost.
The policies and procedures are maintained through the Integrated Management System
(IMS).
BP.2 Record and Manage Incidents
As incidents arise they should be formally recorded, as specified by the procedures. The
recording of incidents can be through a simple paper-based log, although in practice some
form of online system is preferable. This could range from a simple online version of the log,
through to a sophisticated system that handles all aspects of managing incidents. There are
many systems available today that are expressly designed for the management of helpdesk
incidents. In many cases these systems are flexible enough to be used to manage any type
of incident (e.g. bugs, defects or even project management issues).
It is important that the organization has a clear understanding of how any online tool or
system is to be actually used within the organization. Many organizations introduce online
tools to improve particular manual operations or procedures, but fail to adequately address
the system–human interface. The results, or lack of them, can become quite visible after
a period of time. For example, not clearly communicating the roles and responsibilities of
resolver groups can lead to incidents being overlooked. Similarly, failing to establish clear
escalation routes can result in management ‘surprises’ and potentially significant customer
complaints.
Incident resolution can result in a number of different actions, from full corrective and
immediate action and resolution, to a temporary workaround or resolution with customer
agreement, or acceptance of the impact of the incident for a period of time – ‘It’s broken
but we don’t need it for a while.’
© BSI 2012 Version 1.1.0 85

Often, incident resolution cannot be achieved as quickly as the stakeholders would desire,
even if good progress is being made. What often makes situations worse, or appear worse
to stakeholders, is a lack of formal and regular communications about the progress being
made on the resolution. Many people would be prepared to accept a less than ideal situation
if they were kept fully and regularly informed on the progress being made. This would allow
them to accommodate the effects in the planning of their arrangements.
The completion, retention and maintenance of incident records is very important, for a
number of reasons. Firstly, they provide evidence of the incident management processes for
internal audits and external evaluations. Secondly, they provide the essential background
information necessary for effective problem management to be undertaken and
improvements to be made. Finally, in the event of subsequent unexpected issues related
to the development, service or management being provided, they provide clear indications
of the nature of prior incidents and the actions taken to address them. For example, if a
development product is delivered and issues are subsequently experienced, the incident
records provide invaluable data on the nature of the development and previous issues that
might be related.
BP.3 Avoid and Resolve Problems
The third base practice covers both the proactive avoidance of incidents and problems,
and the prevention of repeating problems and related incidents. While risk management
can address preventive actions, this practice specifically requires that the results, trends
and performance of the incident management system are monitored and, if necessary,
improvements identified to prevent incidents. Incident management systems usually also
provide large amounts of useful performance and improvement metrics and these are often
closely aligned with the management of service levels.
The problem management process should not only consider the analysis of recorded
incidents, but should also take account of anomalies that may have been identified but have
not been classed as ‘incidents’. While there is an argument to classify customer complaints
as ‘problems’ when received, additional customer feedback should also be reviewed for
any underlying or potential problems, whether or not they are logged as incidents or raised
as comments received during formal or informal meetings.
As with incidents, identified problems should be recorded and analysed, but, unlike
incident management, problem management should result in a satisfactory and effective
86 © BSI 2012 Version 1.1.0

resolution. Given the definition of a problem, a workaround solution, for example, would
not demonstrate effective problem management.
The techniques involved in problem resolution can be very varied, ranging from brain-
storming sessions, lateral thinking workshops and cause-and-effect identification, to more
technical approaches such as analogy mapping, hypothesis testing and means–end analysis.
Whichever approach is taken, the result will invariably require an improvement to some
aspect of the organization. This could result in changes to its policies, procedures, products
or services. These changes should be addressed through improvement management. As
part of this, it is important that all actions taken or improvements made should be reviewed
to ensure that they effectively address the underlying incidents, anomalies or issues arising
from customer feedback.
Again, like incident management, the status of problem management involving the progress
of corrective actions should be routinely communicated to stakeholders. In this case, the
stakeholders are more likely, although not exclusively, to be internal to the organization
(e.g. top management, quality assurance).
Finally, records of the problem management, including the analysis undertaken and the
resulting actions, should be retained for quality management and process improvement
purposes.
BP.4 Escalate Incidents and Problems
Problem and incident escalation is different from problem and incident status reporting,
which is predominantly concerned with informing stakeholders about the status of the
process and the actions being taken. Escalation can occur for two main reasons: firstly,
if planned actions have not been completed; and, secondly, when there is a significant
incident.
Escalation should be invoked when identified and planned actions are not being progressed
due to adverse influences outside the direct control of the groups involved in addressing
the problem or incident. The trigger for escalation can come directly from the group or
management involved: for example, when a resource is not being made available or when
external milestones are not being satisfied. Escalations can also be triggered indirectly by
other organizational groups, such as by quality assurance resulting from an audit or external
groups following progress or review meetings.
© BSI 2012 Version 1.1.0 87

Escalation should also be invoked when a major or significant problem or incident is

identified. While the same activities may very well be initiated to address the problem or
incident (i.e. analysis, action planning, action resolution, etc.), the purpose of escalation
here is primarily to ensure that senior management is made fully aware and has the
necessary information to address any required communications regarding the event, as
well as taking potential action to accelerate resolution.
The problem and incident policies should clearly state when escalations should be considered
and who should be involved. The escalation route and any associated activities should be
documented in procedures, preferably the associated problem and incident management
procedures.
Records of escalation should be retained for quality assurance purposes.
Data and Record Management
The purpose of the Data and Record Management process is to establish the controls
necessary to identify, maintain and effectively manage the data and records that support
the business.
Every business, from the smallest to the largest, uses data and records to support its day-to-
day operations. This information must be accurate, up to date and accessible to appropriate
users. It must also be secured and protected to prevent unauthorized or inappropriate use.
At best, failures in data management are likely to introduce errors in processes, leading to
delays, defects and rework. However, the impact of poor data management could be much
worse, leading to substantial loss and, in extreme cases, bankruptcy. Similarly, poor data
management in public services wastes public money, while failures in data management in
sectors such as pharmaceutical, health care, defence and policing – to name but a few – can
easily place lives at risk.
Of course, the consequences and risks of poor information management are exacerbated by
the increasing use of IT, because the function and operation of computer systems are only
as good as the data on which they depend. It is also too easy for organizations to overlook
the ‘I’ or ‘information’ part of IT, while concentrating on the ‘T’ or ‘technology’ element.
Modern information systems combine complex analysis and synthesis of information, with
unprecedented levels of integration, allowing any misinformation to be replicated across
88 © BSI 2012 Version 1.1.0

multiple platforms at lightning speeds, thus amplifying any risks, disruption and potential
loss.
Data and records take many forms. Data is typically encoded within an information system,
requiring some level of processing to translate the raw data into meaningful information.
However, data may take other forms, such as the documentation, work products and
records supporting the organization’s processes. Appropriate controls must be applied in
all cases to ensure that the integrity, configuration, storage and preservation of data are
appropriate and effective.
The organization should provide controls to ensure that data and records are reviewed
for accuracy and completeness, while providing suitable storage facilities. Changes to data
should be formally managed and controlled through appropriate configuration management
systems. Archived data should be secured in such a way to ensure that it can be retrieved
if required. Obsolete data and records should be destroyed in order to prevent potential
misuse.
Records provide evidence of organizational activities. The effective management of records

is essential, not only to provide regulatory bodies and customers with evidence that
requirements and expectations have been met, but also to underpin effective management
of the organization, as the records provide essential information about the activities taking
place within the organization, along with its performance.
The definition and management of appropriate process records is also critical to any
performance improvement programme. Without data and records there can be no
performance baseline as a starting point for improvement, and no measure of the progress
being made. In this situation, any improvements that are achieved will be informal and ad
hoc, and will be unlikely to be sustained.
There are ten base practices defined in the BPL Data and Record Management process that
collectively provide the activities necessary to achieve two process outcomes. These are:
BP.1 Establish Data Policies and Procedures

BP.2 Identify Data
BP.3 Review Data
BP.4 Approve and Store Data
BP.5 Control Data Changes
BP.6 Archive and Dispose of Data
© BSI 2012 Version 1.1.0 89

BP.7 Establish Record Management Policies and Procedures

BP.8 Identify Records
BP.9 Manage Records
BP.10 Record Disposal.
BP.1 Establish Data Policies and Procedures
As with other processes, proactive and visible commitment of top management to the data
management process is essential. This commitment should be reflected in an organizational
policy that sets out the requirements and expectations for data management. The data
management policy should be approved by the highest authority within the organization.
It should be communicated and explained to all members of staff, irrespective of grade or
position within the organization.
The data management policy should be maintained in line with the current needs of the
business. The policy should be reviewed and, as necessary, updated on a regular and planned
basis. Changes in policy should be formally communicated to staff, along with details of any
corresponding changes in process and procedures.
The policy for data management should be implemented through procedures and
supporting standards that define how the policy is put into practice. The definition of data
management procedures and standards is critical, as these are used to explain how data is
collected and managed to ensure its integrity and availability, while controlling storage and
preservation and preventing loss or misuse.
As with all processes, the data management policy, along with supporting procedures and
standards, should be maintained under the management framework arrangements, with a
periodic review for suitability and effectiveness.
BP.2 Identify Data
The organization should determine its data needs, with careful consideration of the needs
of its clients and any corresponding regulatory requirements. Data used by the organization
must be aligned to the business objectives, and should be formally defined. An appropriate
starting point for any organization lacking formal definition of its data needs is to review the
existing data being used by the business and to document the data relationships and data
90 © BSI 2012 Version 1.1.0

flows through the business. Investing in this activity alone will likely bring benefits, as it will
highlight potential exposures, redundancies and opportunities for improvement.
In its very simplest form, the definition may be a listing(s) of the data used within the
organization. However, a more robust definition is likely to be a formal data model for the
business, showing data flows and processes within an overall process architecture.
Formal identification of the data needs of the organization should include definition of
the controls to be applied to the data. Definition of controls should include, but is not
limited to:
• how data is to be reviewed

• how and where the data is to be stored
• the required circulation and access controls
• back-up arrangements
• retention periods and disposal arrangements.
BP.3 Review Data
Data should be subject to appropriate review to assure its suitability and integrity. This is
clearly necessary where the data represents a physical work product, specification, design,
etc. However, other forms of data, along with the information it represents, may also be
subject to formal review to provide necessary assurance (see also TEC.4 Verification).
Reviews can take several forms, including peer review, walkthroughs, stakeholder reviews,
etc. Appropriate review methods should be adopted that reflect the data in question and
the needs of key stakeholders – be they internal or external to the organization. Review
methods should be specified, along with the records to be generated by the review process.
Reviews should be conducted according to specified and planned arrangements that are
appropriate to the data in question.
Output from the review should include a record to demonstrate that the review has taken
place, along with details on any adjustments and/or rework that is necessary following
the review. Major revisions to data are likely to require further review prior to approval
and release of data. Minor changes may be applied without further review. However, the
criteria for final acceptance should be specified as part of the review process.
© BSI 2012 Version 1.1.0 91

It is also typical for measurements of defects identified through review to be recorded. This
provides valuable information regarding the performance of organizational processes, and
may reveal opportunities to drive ongoing process improvement.
BP.4 Approve and Store Data
Data should also be subject to appropriate approval, providing authorization for release
and use. Again, this is clearly necessary where the data take the form of a physical work
product, specification, design, etc. However, other forms of data may also be subject to
approval prior to release.
Requirements for approval should be specified as part of the review process, along with
arrangements to bring approved data under appropriate configuration and change control.
Records of approval should be maintained. While these may take a number of forms,
including, for example, physical sign-off of documentation, other forms of approval may
be acceptable, such as electronic approval, provided the integrity of these approvals is
ensured.
Controlled data, including plans, technical specifications, documentation, etc., should not
be released for use as a draft or without specified approvals. In essence, the purpose of
changing from a draft status to an issued status does not necessarily mean that the data
is completed. It does, however, mean that it has been reviewed and is adequate for use.
For example, a design specification may only be 20 per cent complete, but has been issued
and, therefore, the users of the specification will know that what is available is usable. In
far too many cases data is left in a draft status for long periods of time because ‘it might
change’. ‘Draft’ and ‘issued’ statuses should relate to readiness for use, and not necessarily
completeness.
Data should be stored appropriately and in accordance with arrangements in procedures,

plans, etc. Storage requirements should take account of the needs of the business, along
with key stakeholders – including the client. Storage facilities should ensure the data is
secure and protected from loss, damage or corruption. This includes the implementation of
environmental controls to prevent loss or deterioration of the data.
Appropriate back-up and recovery arrangements should be established to ensure that

data can be recovered in the event of an incident or accidental loss. This may include the
92 © BSI 2012 Version 1.1.0

duplication and storage of physical documentation, as well as back-up of computer storage

media.
BP.5 Control Data Changes
Approved data should be brought under formal control. Controls should include
arrangements for requesting and documenting required changes to data, along with the
necessary approvals to permit changes to be made to data items. Change controls should
be formally specified as part of operational procedures.
Revised data should be subject to the same controls for review and authorization as the
original data, including the preparation and management of review and authorization
records.
All data should be identified uniquely, according to arrangements specified in procedures,

plans, etc. Controls should include methods to identify each successive version of data,
with changes made in such a way that bidirectional traceability can be achieved. Controls
should also ensure that earlier versions of data are withdrawn from use or are prevented
from inadvertent use.
BP.6 Archive and Dispose of Data
Retention periods for data, whatever form it takes, should be formally defined. Data should
be formally disposed of once it exceeds the defined retention period. Disposal arrangements
may, but do not necessarily, mean destruction of the data. Disposal can include removal
to long-term archive. In all cases, disposal practices must follow defined arrangements,
including any security requirements, while complying with any necessary contractual and
statutory requirements.
Care must obviously be taken to ensure that critical data is not inadvertently disclosed through
the disposal process. For example, organizations should use incineration or shredding to
dispose of sensitive paper-based data, and may go so far as physically destroying computer
media carrying electronic records. In all cases, appropriate methods of disposal should be
defined according to the classification of data being used (see ORG.4 Infrastructure and
Work Environment Management).
© BSI 2012 Version 1.1.0 93

Records of disposal of data should be maintained in all cases. These provide evidence that
the archiving or disposal process has been undertaken, along with an appropriate audit
trail should any queries regarding the data arise following disposal. Where necessary, this
should include formal certification that data has been destroyed. Data, whatever its form,
should never generally be disposed of as refuse.
BP.7 Establish Record Management Policies and Procedures
The commitment to effective record management disciplines should be expressed within

an organizational policy that sets out the organizational requirements and expectations for
record management. The record management policy should be approved by the highest
authority within the company. It should be communicated and explained to all members of
staff, irrespective of grade or position within the company.
The record management policy should be maintained in line with the current needs of
the business and other stakeholders, and should reflect any contractual and regulatory
requirements that must be addressed by the record management controls.
The policy should be reviewed and, as necessary, updated on a regular and planned basis.
Changes in policy should be formally communicated to staff, along with details of any
corresponding changes in process and procedures.
The policy for record management should be implemented through procedures and
supporting standards that define how the policy is put into practice.
As with all processes, the record management policy, along with supporting procedures and
standards, should be maintained under the management framework, with periodic review
for suitability and effectiveness.
BP.8 Identify Records
The organization should determine the records needed to support the business, with careful
consideration of the needs of its clients and any corresponding regulatory requirements. As
with other data, records used by the organization must be aligned to the business objectives
and should be formally defined. An appropriate starting point for any organization lacking
formal definition of its records is to review the existing records that are being used.
94 © BSI 2012 Version 1.1.0

In its very simplest form, the definition may be a listing(s) of the records used within the
organization. A more robust method, formally linking records to other data and information
flows, is appropriate in many cases.
Formal identification of the records maintained by the organization should include definition
of the controls to be applied, including, but not limited to:
• how and where the records are to be stored

• the required access controls
• back-up arrangements
• the necessary retention periods and disposal arrangements.
BP.9 Manage Records
Records should be managed according to the arrangements defined within the operating
procedures. Particular attention should be given to the implementation of a systematic
approach to record management to ensure that information is effectively routed and is
accessible when it is required.
While paper-based records are acceptable, many organizations are moving towards
electronic systems for collecting and storing the records. As with other data, controls
should be applied to ensure that records are securely and effectively managed in order
that integrity is maintained. This includes the provision of necessary back-up and recovery
arrangements.
BP.10 Record Disposal
Retention periods for records, whatever form they take, should be formally defined.
Records should be formally disposed of once they exceed the defined retention period.
Disposal arrangements may, but do not necessarily, mean the destruction of the records.
Disposal can include removal to a long-term archive. In all cases, disposal practices must
follow defined arrangements, including security requirements, while complying with any
necessary contractual and statutory requirements.
Care must be taken to ensure that critical or sensitive records are not inadvertently
disclosed to unauthorized parties through the disposal process. For example, organizations
© BSI 2012 Version 1.1.0 95

should use incineration or shredding to dispose of sensitive paper-based records, and may
go so far as physically destroying computer media carrying electronic records. In all cases,
appropriate methods of disposal should be defined according to the classification of the
records being used.
Details of the disposal of records should be maintained in all cases. These provide evidence
that the archive or disposal process has been undertaken. Where necessary, this should
include formal certification that records have been destroyed. Records, whatever their
form, should never generally be disposed of as refuse.
Integration Management
The purpose of the Integration Management process is to assemble and verify a product. In
practice, this means ensuring that the components required to achieve a final objective are
brought together in a co-ordinated manner and are checked for correct operation. Here,
‘product’ may be taken to mean a complete product or service, or a product or service
component.
While the integration of products and product components is fairly well understood, the
concept of integrating services may be less clear. A service rarely, if ever, operates in complete
isolation, with many having to work alongside or in co-operation with other services. For
example, the provision of network services may interact significantly with desktop services,
break/fix services, mainframe services and helpdesk support services.
In product development, integration often involves moving components from a development

environment to an integration environment, and so represents a key milestone in the
development of the product. This may also include the transfer of authority from the
development team to the integration or test team.
Integration management practices may vary in size and complexity, depending on the nature
of the work being performed. In some cases, integration management may actually appear
non-existent, such as when a small development or enhancement is being implemented.
However, in practice, integration is still being undertaken, albeit masked by the testing
activities, which are managed through the normal project management activities.
In other cases, integration may be much more substantial and involve a much greater
need for a specific Integration Management process. In developing complex, large IT
96 © BSI 2012 Version 1.1.0

systems, which invariably involve many components and subcomponents, the integration
of the complete system cannot be effectively accomplished simply by bringing everything
together in one event. Firstly, it would be ineffective to wait for all the components to
be available, especially if they were being developed and provided by multiple sources.
Secondly, it would be virtually impossible to track down the cause of any observable defects
or problems that could come about through the myriad of possible component interactions
and combinations. Finally, it would be questionable whether the full system has actually
been sufficiently verified to ensure that all aspects have been covered such that defects can
be exposed.
The outcome of an effective Integration Management process would clearly be to minimize

or eliminate the defects detected in the later stages of development or use. It is good
practice – from both a project management and a business point of view – to eliminate
defects wherever possible. In practice, achieving zero defects during any phase is virtually
impossible, if for no other reason than that the cost would be prohibitively high. The
outcome, therefore, represents a desired goal that organizations should strive to achieve
by continual process improvement in integration management.
There are four base practices defined in the BPL Integration Management process that work
collectively to achieve the process outcome. These are:
BP.1 Define Integration Plan

BP.2 Establish Integration Environment
BP.3 Assemble Product
BP.4 Verify the Product.
There is no implied sequence to these activities, except that the product needs to be created
and assembled before it is tested and verified, and this is best done in an established
integration environment. This does not, of course, prevent partial product integration,
allowing verification to commence before full assembly is complete. Even the smallest
component, a code module, needs to be constructed (or assembled) before being unit
tested or verified.
BP.1 Define Integration Plan
Integrating the product, as an activity, may vary from simply moving a few files into the
integration environment, to a major project in its own right. The level of integration planning
© BSI 2012 Version 1.1.0 97

should, therefore, correspond to the nature and complexity of the work being undertaken. In
the first case, a paragraph in the project plan, identifying dates and authorities, may suffice.
In the latter case, there may be multiple integration plans covering different components,
sub-assemblies, geographical locations, etc.
Integration is made more difficult if any of the following conditions exist, and therefore
consideration of these aspects in the planning activities will greatly reduce the potential
risk of failure:
• Product complexity: the more complex a product, the more components and associated
elements (specifications, designs, test specifications, scripts, data, etc.) there are to
control.
• Changing components: any complex problems are magnified when the components
themselves are changing, whether from late customer changes or defects.
• Component quality problems: often as a result of time pressures, problems with
components lead to more complexity, unplanned work and increased time pressures – a
vicious circle.
• Mismatch between components: similar to quality problems with components, only
where the problems lie on the interfaces between components.
• Time pressures, the one constant of any project: the more constraints placed on a piece
of work, the more errors are likely to be made, leading to extra work and exacerbated
time pressures.
If any of these conditions exist, it is usually better to address the issues raised before starting
to integrate unreliable components.
The integration plan should cover:
• Preparation for integration: acceptance criteria for components and sub-assemblies and
what to do in the case of substandard or non-conforming elements.
• Scope: in-scope components, out-of-scope components, and any exceptions or exception
criteria.
• The integration sequence: identify different possible sequences and select the one
providing the best performance (e.g. against quality, time and cost criteria). Formal
decision techniques are helpful in complex or high-risk situations.
• Procedures for the integration of the product components: effort, test cases, scripts and
data, test schedule, test deliverables and risk management.
98 © BSI 2012 Version 1.1.0

• Teams, roles and responsibilities: identify teams, people, roles and responsibilities.
Where there are separate teams (e.g. a separate integration team), then procedures for
passing material between the teams will be needed.
• Managing the integration: progress monitoring, capturing data, defect management and
escalation.
• Integration completion: completion criteria, reporting and approval.
The procedures required to integrate the product can be part of the overall integration
plan or should be referenced from it. Some of these may already exist (e.g. verification),
but others may need to be provided (e.g. procedures to build or configure the integration
environment). However, specific requirements and acceptance criteria for the product
should be defined.
BP.2 Establish Integration Environment
The integration environment is typically a separate environment where developed code

is gathered and assembled, often along with library and legacy data and applications.
‘Separate’ may mean just a different folder or area on a machine, different machines
(client or server) on the same network, or even totally separate networked infrastructure.
It depends on the product being developed or enhanced. The larger and more complex the
integration environment, the more effort that may be needed to plan and set it up ready
for integration.
The technical environment includes the machines, servers, networks, communications

equipment, applications, data and any specialist equipment required. Where non-standard
equipment is required, it is important to specify the equipment characteristics carefully.
If the equipment is shared, then definition of the dates over which it will be required is
critical.
In specifying the technical environment it is important to define the size, performance

characteristics and support required to effectively operate the environment. In particular, it
is critical to define the interfaces between the environment and the rest of the organization.
Consideration should be given to the extent to which automation can reduce the effort and
time required to perform the integration.
In addition to the technical environment, it is important to specify the requirements for

accommodation, tools, tool support, people and any training that may be needed. For a
© BSI 2012 Version 1.1.0 99

small maintenance environment, all of this may be no more than the normal existing working
conditions. For a major cross-location project, separate provision, even separate buildings,
may be required. It is important to ensure that the level of definition of the environment is
commensurate with the size and complexity of the product being developed.
As even the smallest environment contains a number of elements, any one of which can
change over time, it is important to ensure that the full specification of the environment
is created (e.g. including versions of support tools) and maintained under configuration
management. Even changing a single support tool can alter the environment and prevent
successful integration.
It is important to compare the integration environment with the operational environment.

If the operational environment lacks one or more elements that the product requires for
transition, release or operation, then a change request needs to be sent to the operational
management group.
Once the integration environment has been established, it is important to verify it. This can
avoid many lost hours searching for product defects that are, in fact, environment problems.
Typically this is done by using a small, well-known application that exercises all elements of
the environment and its interfaces.
BP.3 Assemble Product
The product is assembled according to the release requirements, integration sequence and
established procedures. There are different types of release. The most obvious one is the
release of a product version to production. Other possibilities include the release of a test
version to an independent test team, and the release of a tested system for acceptance
testing. The types of releases that a project will use should be defined under the project
planning for transition and release.
Assembly will be more straightforward if:
• the basic product components meet their requirements, including customer,

performance, operational and security requirements (e.g. virus-free);
• the interfaces between product components and with the integration environment and
the external world are defined and met; and
• the integration environment is established and verified.
100 © BSI 2012 Version 1.1.0

Typically these conditions are specified as the prerequisite to product assembly.
Product assembly may require the creation of sub-assemblies. As assembly progresses,

checks or confidence tests are usually executed to verify the sub-assembly. In the same
way that assembly is easier if the product components meet the requirements, then it
is easier if the sub-assemblies also meet their requirements. The integration plan should
define whether sub-assemblies are stored as separate configuration items or re-assembled
for each integration cycle.
The assembled product, along with any relevant sub-assemblies, library units and other
items, should be labelled and stored under controlled conditions. Typically this is still under
the project’s responsibility, although it may have moved into a separate integration team
within the organization.
A build record should be created to identify which input components and tools were
used, and to record the version of the product created. Traceability records should also
be updated at this stage to record the connection between the system design and the
assembled product. For small enhancements this may be done in the build record, but for
new products or larger updates this is typically a separate traceability matrix or record.
The build record, traceability matrix and any check or confidence test records for
sub-assemblies should be stored under formal control along with the assembled product.
BP.4 Verify the Product
To confirm the correct assembly of the product, it should be verified against its acceptance
criteria. The scope and rigour of the verification depends on the type of release being
assembled. Typically, a full product release requires greater effort and control than an
internal release. The verification requirements, procedures and acceptance criteria should
be defined in, or be referenced by, the integration plan.
The integration test cases, scripts and data are typically developed in conjunction with the
product and may, in some development approaches, drive the development of the product –
as in test-driven development. Test cases may include tests of functionality, performance,
usability, compatibility, security, and any other defined product characteristics at the
component, sub-assembly, interface or product level. Test cases should be stored under
controlled conditions.
© BSI 2012 Version 1.1.0 101

Defects should be logged, analysed, resolved and closed. Details of each defect should be
kept, including information on the source and type of the defect. At the end of the product
integration the defect data can be reviewed to identify any process-based problems that
could be eliminated (e.g. due to the integration sequence or approach). This helps future
integrations on both the current project and subsequent projects too.
Test results should be reviewed to ensure that the acceptance criteria are met. Where the
criteria are not met a decision should be taken as to what action should be taken next.
Typically, the decision is taken at the same level as that used for identifying the release in
the first place. The decision may be to return the product for rework and reintegration, to
accept the product with reduced functionality and/or performance, to accept the product
temporarily but with an action plan to resolve the issues, or even to abandon the product
entirely. The decision will depend on many factors, but will include mainly the technical and
commercial circumstances existing at the time.
The test results record is stored under controlled conditions along with the verified product.
The verified product may then be made available for use.
Verification
Verification is an important part of many other processes and provides confidence that the
work products are being created to satisfy their specification and are of the desired quality.
Verification activities also ensure that appropriate rework is undertaken and, as necessary,
the work product is re-verified. The purposes of the BPL Verification process are, therefore,
to ensure that work products are objectively evaluated and any rework is completed so that
the work product meets agreed specifications.
There are many different types of work products that require verification, along with many
different verification approaches. Work products include technical artefacts, documentation
and support aspects. Technical artefacts include output generated from design tools,
graphic design such as that resulting from visual development tools, architecture diagrams,
code, test data and test results. Documentation covers legal and commercial (e.g. contracts
and marketing leaflets), technical (e.g. requirement specifications, design specifications,
test strategies plans, scripts), operational (covering policies, procedures, work instructions,
standards) and delivery (including specifically project plans, schedules, service level
agreements, etc.). Support outputs include infrastructure and network diagrams,
102 © BSI 2012 Version 1.1.0

Verification
environment specifications (e.g. required for a test environment) and, to a degree, physical
equipment (e.g. calibrated items using in testing).
Verification approaches include reviewing, inspecting, testing, evaluations and formal

demonstrations. Reviews can range from informal desktop reviews (e.g. code inspections),
through documentation reviews (involving multiple reviews), to formal inspections (e.g. the
Fagan inspection). Testing covers various levels such as unit or module testing, integration
testing and system testing. Other forms of verification include evaluations based on
mathematical modelling or demonstrations of prototype products.
The expected outcomes of this process are that work products are shown to meet their
intended specifications and, following the verification, no additional rework is necessary.
While these are ideal goals, in practice there may always be a need to undertake further
rework on a product, but the aim of implementing an effective Verification process is that
subsequent rework is not necessary.
There are four base practices that ensure the effectiveness of the BPL Verification process.
These are:
BP.1 Establish Verification Procedure

BP.2 Plan Verification Activities
BP.3 Conduct Verification Activities
BP.4 Review the Effec veness of the Verifica on.
The first two practices address the preparation and planning for conducting the verification
activities.
BP.1 Establish Verification Procedure
The verification procedures typically provide the details on how to conduct the verification
activities. For example, they may provide the steps involved in conducting a documentation
review or formal Fagan-style inspection, or they might describe the various levels and
sequence of testing. While the practice refers to establishing procedures, other types of
document could exist in practice, such as a testing strategy, or even test scripts for very
low-level procedures.
© BSI 2012 Version 1.1.0 103

The procedures are also expected to specify the verification environment necessary to
undertake verification activities effectively, and may also address training needs. The
verification environment typically addresses the testing activities (e.g. equipment, facilities)
needed to conduct the tests, but could also address the facilities needed to conduct formal
inspections (e.g. rooms, conferencing or presentation facilities).
BP.2 Plan Verification Activities
The second practice addresses planning the verification activities. This will invariably be
undertaken, at least in part, with the first practice. Planning includes establishing how
the verification is to be undertaken, also what should be verified, who will be involved
and when verification is to be conducted. Some of these aspects could be built into the
verification procedure if they are relative or static in nature. For example, if the quality
assurance group always has to review procedural documents when they are created, this
could simply be specified in the associated procedure. However, it would be more likely
that verification needs to be specifically planned for particular activities, especially when
considering testing, but in simple cases this too could also be simply described by procedure
(e.g. when testing is always done by a particular test team).
More commonly, the planning for verification is undertaken as part of overall project
planning. Typically, the project management plan will identify the approach to be adopted,
including any tailoring of the organizational processes, while identifying the items to be
verified. The project schedule usually includes details of the verification activities, such as
when verification will be undertaken and who will conduct it. Then, at the lower levels, the
test strategies, plans and scripts would be produced in line with project or work plans and
schedules.
It is desirable to see specific scheduled line items for conducting the verification activities
(this is essential for the testing activities) and also provision for any rework necessary, as
this provides better data on the verification approaches. However, this is not mandatory,
especially considering less formal document reviews, and the necessary verification
or review and any rework necessary can be built into the overall task of producing a
document. However, this approach must be clearly stated in the associated procedures
and/or plans.
104 © BSI 2012 Version 1.1.0

Verification
BP.3 Conduct Verification Activities
Planned verification activities are completed as the project or work progresses. Records
of verification activities and results should be retained for the purpose of assessing the
effectiveness of the verification process, providing audit and assessment information, and
to allow investigations to be undertaken in the event of subsequent issues.
Records of verification may take a number of forms. These could range from retaining
all documentation associated with the verification, including, for example, all marked-up
draft documents, test output, and comment forms, to just some form of summary record
containing key items of information. The important aspect is to ensure that the records
demonstrate that the verification was undertaken, on what and by whom, and that they
can allow the verification activities to be evaluated.
BP.4 Review the Effectiveness of the Verification
The final practice requires the effectiveness of the verification activities to be reviewed
and, if necessary, any corrective action or improvements to be made. Ideally, it would
be good not to have to undertake verification because other development processes are
ensuring that work products are produced correctly first time. However, while there have
been examples of verification tasks being dropped as processes improve, this is still a very
unlikely situation. Verification should therefore be implemented in the most effective and
efficient manner possible.
The effectiveness of verification can only really be judged after the verification activity has
been completed, usually by establishing whether any subsequent problems or issues could
or should have been detected earlier. Counting the number of verification findings (e.g.
test failures or document comments) can be useful, but can also be a little misleading when
the counts are low. For example, if few test failures were logged, then either the product
was good and the effectiveness of the testing was irrelevant, or the product was bad and
had many problems but the testing was not good enough to detect them. Often, other
parameters, such as the time taken to conduct the verification or the size of item being
verified (e.g. lines of code, document pages) can provide more information to judge not
only the effectiveness, but also the efficiency, of the verification activities.
© BSI 2012 Version 1.1.0 105

The causes of defects and issues should be considered as part of the verification rework
and action should be taken to prevent reoccurrence. If the resulting improvement in the
development processes are effective, there should be fewer problems in subsequent work
products being developed.
Validation
Validation is similar to, and often confused with, verification but achieves a very different
purpose. While verification is typically used throughout the lifecycle to ensure that a work
product satisfies its requirement, validation is used primarily to ensure that the product
satisfies its intended purpose and, importantly, in its intended environment. A commonly
quoted way to remember this distinction is that verification answers the question ‘Are we
building it right?’ and validation answers the question ‘Was it the right thing to build?’
In practice, to answer the validation question the customer requiring the product must be
involved in the validation activity in some way. This might suggest that off-the-shelf, COTS
or consumer products cannot be validated as there would be far too many people involved.
However, in these cases the product is often required by an internal organizational group
such as the marketing department, the new business group, or even the executive team.
Therefore, initially the validation should include these groups, to accept that the developed
product does satisfy their needs, requirements or expectations. While these groups are
involved initially, further validation is often undertaken once the product is in use with the
end-users, or customers, through product feedback, surveys, enhancement requests and
product defects.
While validation is certainly performed on the final product, this is not the only time when
validation can be performed. Verification is aimed at ensuring that the product is being built
correctly (i.e. that the architecture design meets the requirement specification, that the
detailed design meets the architecture design, etc.), and it would not be possible to verify
the requirement specification without involving the stakeholders (e.g. the customer) that
set the requirements. Therefore, by involving the customer in this activity it could be said
that the requirements are being validated, i.e. being checked back with the customer to
ensure that what is described is what the customer is actually wanting. It should be noted
that it would not be appropriate to just do a requirements validation without completing a
final product validation as well. This is because it is not until the final product has been built
that it can be fully confirmed as satisfying its intended purpose, or the question ‘Was it the
right thing to build?’ can be answered.
106 © BSI 2012 Version 1.1.0

Validation
In lifecycle models where the customer (or their representative) is encouraged to

participate during the development, such as rapid application development, prototyping
or agile modelling, validation could be happening more frequently. For example, in agile
modelling the customer is encouraged to become involved in the end of SPRINT workshops
or demonstrations to confirm that what has been developed during the SPRINT exercise
is progressing towards their desired product, and this could also be considered a form of
validation. Again, however, no matter how many in-development validations are performed,
there will always be a need to conduct the final validation of the product in its intended
environment.
So far, this guide on validation has focused primarily on the involvement of the organization,
group or body requiring the product, and little on the techniques involved in actually
conducting validation activities. This is simply because, in virtually all cases, the approaches
to validation would be the same as those used in verification. For example, a customer
would typically conduct their validation of requirements in much the same way as the
development organization would verify the architecture design against the requirement
specification, i.e. through a peer-review approach. Also, validation of the final product
would typically be performed through testing. In the same way, verification of code would
also be performed through testing by the development organization. In this latter example,
the main difference between product verification and product validation, other than the
involvement of the customer, is the need to conduct the product testing in its intended user
environment.
The expected outcome of this process is that products meet their intended purpose without
any rework following the validation activities, which by definition includes necessary rework
to address issues identified during validation. In a similar way to the verification objectives,
the outcome represents an ideal goal, but in practice it is recognized that further rework
may be required following completion of the validation activities. However, it is the aim
of an organization implementing an effective Validation process to ensure that it does not
incur unnecessary or inappropriate rework once validation has been complete.
The structure of the BPL Validation process is very similar to that of the BPL Verification
process, and involves four base practices. These are:
BP.1 Establish Validation Procedure

BP.2 Plan Validation Activities
BP.3 Conduct Validation Activities
BP.4 Review Valida on Effec veness.
© BSI 2012 Version 1.1.0 107

The first two base practices address the preparation and planning for conducting the
validation activities, and can often be tightly coupled.
BP.1 Establish Validation Procedure
The validation procedures, in a similar way to the verification procedures, provide details on
how to set up and conduct the validation activities – although in many cases the procedures
may be the same as the verification procedures. This would typically be the case for non-
product validation activities, e.g. for validating the requirements or conducting end of
SPRINT workshops or demonstrations. Where differences often exist, however, is in the
validation of the final product, where the verification approach of the product may not be
suitable or appropriate to use during validation.
By using the examples of product system testing and product acceptance testing, the
difference between product verification and product validation can be shown in a simplified
manner. The procedures for conducting system testing will often include significant detail
on proving that all logical and functional aspects of the product are working correctly. That
is, not only does the functionality perform as specified, but also, for example, that all error
handling conditions work correctly. In contrast, the procedures for conducting acceptance
testing will usually be a subset of the system testing that concentrates on demonstrating
the overall operation of the product. That is, that the product functions in its intended
environment and that performance aspects have been satisfied. This is just a simplification
and, in practice, there can be varying amounts of overlap between system testing and
acceptance testing. For example, there may well be much more emphasis placed on setting
up the environment for acceptance testing than there would be for system testing, which
might be undertaken only on a dedicated test facility.
BP.2 Plan Validation Activities
Whereas the first base practice concentrates on the procedures for conducting validation,
this base practice addresses what is validated, when the validation is undertaken and who
is involved. However, and again similar to the verification process, all these aspects could be
covered in a combined validation procedure and plan, or by other project work products,
such as the project plan and schedule.
108 © BSI 2012 Version 1.1.0

Validation
The amount of detail necessary for planning the validation activities would depend very
much on the nature of the development, its complexity, size and the number of organizations
and organizational groups involved. In its simplest form, it could consist of a line item on the
project schedule, indicating when validation will be undertaken and who will be involved,
along with references in the project management plan to the standard procedure to be
used. Conversely, for very large programmes, where multiple developments come together
or where multiple systems are being integrated, there may well be a need for a separate
plan and associated schedule.
Again, it is desirable to include separate line items for conducting the initial validation
activity, undertaking any rework as a result, and then performing any final validation.
However, this is not mandatory and would clearly depend on the factors mentioned in the
previous paragraph.
BP.3 Conduct Validation Activities
Validation activities should be undertaken in accordance with the validation plans and
procedures, with rework and further revalidation as required. Records of the validation
activities and results should be retained, as specified by the validation procedures. The
records should be maintained for the purpose of evaluating the effectiveness of the
Validation process, while also providing information for quality assurance – and to allow
investigations to be completed in the event of subsequent issues being discovered during
the validation activities.
The process does not mandate the form of the records or results, although this should be
specified by the organization in the validation procedures. However, records and results
should be sufficient to identify who performed the validation, when it was conducted, how
much effort was involved, the environment in which it was performed and what was actually
validated (e.g. the version of the product would be sufficient to allow the components to
be identified if necessary). However, records must certainly demonstrate that requirements
have been satisfied (see TEC.10 Stakeholder Requirements Definition, and, in particular, the
discussion on requirements traceability in BP.2 of that process).
© BSI 2012 Version 1.1.0 109

BP.4 Review Validation Effectiveness
The final base practice requires that the effectiveness of the validation activities be reviewed
and, if necessary, corrective action or revision be made to the process to improve its
performance. In a perfect world, where all the customer requirements are fully defined in a
clear and unambiguous manner, the requirement specification could be generated without
any recourse to the customer, and the verification activities ensure that the product is built
correctly, there could be an argument for not needing to undertake validation. However,
this level of clarity on customer requirements is rarely seen, for very many reasons, and
final product validation is usually always necessary.
Therefore, given the need to conduct validation it is essential that it is being undertaken
in an effective and efficient manner. Essentially, this means that it is undertaken using
the minimum amount of resource and without having to unnecessarily repeat validation
activities – in essence, this what the process outcome requires.
Again, like the Verification process, the effectiveness and efficiency of the Validation
process can only really be judged once it has been completed. Over time, and as processes
mature, there will be opportunities to judge the efficiency of the validation using statistical
techniques. Counting defects identified during the validation activities and monitoring
the correction rate can provide some information on what the process is doing, but does
not really say anything about how effective it is in achieving its outcome. For example, if
validation defects are being closed at a rate of 10 per day and over 5 days all identified
defects have been corrected, it might be said that the validation has been quite successful.
However, if the validation activity also reveals 200 additional defects, it could then be
said that the validation activity has not been very effective. Here, the defect closure rate
is actually an indication of the effectiveness of the corrective action process (see PRJ.5
Problem and Incident Management), not the Validation process.
A more useful indicator of the effectiveness of the Validation process requires some
measurement of the size of the product and ideally some insight into historical validation
activities. By comparing the size of the product with the number of defects found during
validation against previous validation data, it is possible to gain a view on the effectiveness of
the validation process. Similarly, comparisons involving size and effort can provide additional
indicators on efficiency. This will allow decisions to be taken on whether corrective action
or improvement of the Validation process is required.
110 © BSI 2012 Version 1.1.0

Transition and Release Management
The purpose of the Transition and Release Management process is to move a product into
the operational environment and make it available to customers. Only when the product is
being used does it produce the value intended, and so transition and release must include
the support mechanisms to ensure customers can effectively use the product.
The word ‘product’ here may be taken to mean a complete product, a product component,
a service or a service component. The word ‘release’ may be taken to mean any type of
project release, from a small internal release of the project to a full external release of a
product.
Most organizations have some form of release criteria that indicate when the product
has been accepted and is now in a support and maintenance phase. In many cases this is
indicated by some form of customer acceptance, indicating that the customer is satisfied
with the product. However, while this is acceptable, organizations should aim to provide
more objective criteria for judging acceptance, e.g. in terms of acceptable levels of non-
critical defects, performance levels, and operational use characteristics.
The outcome of the Transition and Release Management process is that a product is released
into the operational environment to the satisfaction of the customer. This requires the
active solicitation and monitoring of customer satisfaction as part of the release process,
along with the resolution of any issues that prevent full use of the product by the customer.
There are five base practices defined in the BPL Transition and Release Management process
that collectively provide the activities necessary to achieve the process outcome. These are:
BP.1 Establish the Transition and Release Policy and Procedures

BP.2 Plan for Release
BP.3 Verify Operational Environment
BP.4 Validate the Product
BP.5 Release the Product for Use.
While normally there is no implied sequence to the base practices in the BPL processes, it
is critical that the product is validated in a fully verified operational environment before the
product is finally deemed ‘released’. Failure to observe this requirement casts doubt on the
quality of the product, and therefore on its ability to satisfy the customer’s needs.
© BSI 2012 Version 1.1.0 111

BP.1 Establish the Transition and Release Policy and Procedures
A transition and release policy should be established to define the way in which the
organization wishes to release products. The policy typically requires the following aspects
to be considered as part of the release planning:
• Acceptance criteria for releases: typically releases are not permitted with any critical or
serious defects, unless accepted by the customer. There are usually also some thresholds
for minor and cosmetic defects.
• Handover criteria between development and support teams: for example, criteria might
specify that handover to the support and maintenance team cannot be undertaken until
predefined threshold values of customer satisfaction have been reached.
• Criteria for a post-implementation review: for example, policies may define the conditions
under which a post-implementation review should be held, how long this should be after
release, and who should manage and be involved in the review.
• Final project review, also known as a ‘retrospective’ or ‘lessons-learnt’ review: the
policy should typically require that a final project review be held to capture the data,
experience and lessons of the project. The conditions under which a final project report
is not required should also be clear.
The policies should be reviewed and approved by senior management. The policy should
be communicated throughout the organization, but particularly to those staff directly
involved in undertaking release and maintenance activities (e.g. project managers, support
managers).
Supporting procedures can be defined at the organizational level, particularly in small

organizations or where the same approach to transition and release is undertaken on each
occasion. Alternatively, supporting procedures may have to be produced specifically for a
given development. For example, specific transition and release procedures and supporting
documentation would be required in the case of a large or complex development project. In
some cases, transition and release practices can be integrated with product development.
Procedures supporting transition and release can therefore also be defined as part of, or be
referenced by, development processes.
Once established, the policy and associated organizational procedures are maintained
under controlled conditions, through the management framework.
112 © BSI 2012 Version 1.1.0

BP.2 Plan for Release
Plans for releasing or deploying the product should be drawn up by the project manager
in conjunction with operations and maintenance staff. These plans should cover installing
the system, training users, bringing IT production and maintenance staff on board, and
establishing the incident reporting system. A release schedule should also be produced
during planning for the release.
For a small update or patch to an existing system, this may be simply an email, or similar
communication, from the project manager to the release or operations manager. For the
global release of a new product, it will likely be a series of interrelated release plans.
Often, release activities are tied into the planned system or application downtime, and
may therefore occur during anti-social and time-boxed maintenance periods. Given the
time pressures usually encountered when completing a release, the schedule must contain
checkpoints and the plan must contain effective fallback, or back-out, procedures.
While plans for releasing the product are being made, consideration should also be given to
developing the documentation required to install, use and maintain the product. Typically
these deliverables will have already been started during earlier phases of the development.
Key deliverables may include installation guides, user guides, maintenance guides, etc.
Training material should be developed for both users and operational staff. Delivery of the
training is not necessarily tied to the release schedule, but should be undertaken when
users are expected to be able to use the product. Any sooner than this and people may
forget some of the training, thus reducing its effectiveness. Feedback on the training
should be collected, and any issues or problems associated with the training or the product
appropriately addressed.
As required by policy, the post-implementation review should be scheduled early in the

development planning to ensure that the resource and other stakeholders involved in the
development remain available to participate in the review (see PRJ.1 Project Management).
Here, the review should objectively examine the plans, schedules, procedures, incidents,
problems and customer feedback associated with the transition and release activities.
© BSI 2012 Version 1.1.0 113

BP.3 Verify Operational Environment
Prior to installing the product it is necessary to check that the operational environment is
the one for which the product was developed. Most issues in this area will have arisen – and
been resolved – during the previous validation and verification activities. However, things
do change. In its simplest form, a check should be made to ensure that the operational
environment matches the one used for going live or the final stages of testing. Any changes
will most likely to be minor ones, as any major issues should have been identified and
addressed during product development and integration. If, however, major changes are
identified, there could be considerable risk to the release schedule; thus, early and continual
monitoring of the operational environment is essential.
If differences are discovered, a formal decision involving all stakeholders, including the
customer, should be made as to the actions to be taken. The decision could typically be
to allow the transition and release to go ahead, with or without certain concessions, or to
postpone the transition and release until further development testing has been performed.
BP.4 Validate the Product
The product should be validated against its user acceptance criteria to confirm that the
product meets the customer’s requirements (see TEC.5 Validation). The product version
(sometimes called the ‘release candidate’) will often be the one that successfully completed
the last set of verification activities (see TEC.4 Verification).
The scope and rigour of the validation depends on the type of product being transitioned
and released. Typically, a full product release will require greater effort and control than will
a small maintenance update. Here, the validation requirements, procedure and acceptance
criteria will have been defined in the validation plan for the product.
The validation test cases, scripts and data are typically developed in conjunction with
the product – or may even drive the development of the product, as in feature-driven
development. Whereas verification activities cover the full set of product requirements,
including performance and other operational considerations, validation is usually, but not
exclusively, driven by the view of the user, i.e. does the product provide what was originally
required by the customer? Here, key issues include product stability and user confidence.
114 © BSI 2012 Version 1.1.0

The validation environment will be as close as possible to the live operational environment,
and in some cases may be the actual live environment itself. The more differences there
are between the real and the validation environments, the lower the confidence that the
validated product will actually perform as intended when released. Defects and issues
should be logged as they occur, analysed and resolved.
At the end of the testing, consideration should be given to gathering feedback from the users
who have been involved in the testing. This helps the development and maintenance teams
to understand better the user point of view and gives early warning of potential problems
or enhancement requests once the product is released. Analysis of the user feedback can
form part of the customer acceptance. Validation test cases, scripts and data should also be
stored under controlled change and configuration control.
Test results should be reviewed to ensure that the acceptance criteria are met. Where the
criteria are not met, there will need to be a decision made regarding the action to be taken.
Typically, the decision is taken at the same level as that used to authorize the release. The
decision could be to return the product for rework and reintegration, to accept it with
reduced functionality and/or performance, to accept it temporarily but with an action
plan to resolve the issues, or even to abandon the product entirely. The decision will often
depend on both technical and commercial circumstances.
A formal record of customer acceptance should be obtained. This can be as simple as

an email approving a small update, or may be as rigorous as a full meeting of a product
steering committee (or similar) with a formal record of agreement. The level of formality
should be matched to the level of the release, as well as the complexity and risk inherent
in the release.
Formal authorization should be gained for the product to be released to the final live
environment. The purpose of a go-live approval is to decide whether and under what
conditions to go live. If there is a shortfall in functionality or performance, or there are still
defects in the product, these will have to be weighed against the customer accepting what
is available. A decision to go live may include conditions on the development team in terms
of fixing defects or improving performance over a certain period.
The validation record and customer acceptance record should be stored under controlled
conditions, along with the validated product.
© BSI 2012 Version 1.1.0 115

BP.5 Release the Product for Use
The release sequence for a product may involve any combination of building, shipping,
installing and deploying the product.
Building a product is also associated with COTS or packaged products, as well as systems
and services. This involves preparing the product in a form that can be delivered or shipped
to the customer. Traditionally, this has been achieved physically, but more often today
this is through online distribution methods. Either way, building the final product involves
bringing together various components such as the product, delivery notes, user manuals,
and warranty information leaflets.
A delivery note should be produced every time that a release is made. The basic contents
should include sufficient information to establish the version of the product, changes
and enhancements made, problems, issues and defects resolved, any outstanding known
problems and issues or defects remaining.
The product should be shipped or made available for shipping using the agreed method,
e.g. physically as a packaged product or electronically as a download from a known location.
The delivered package should consist of the validated product and all the relevant
documentation, such as installation procedures, operations manuals, training materials,
feedback forms, and the service level agreement. The actual documentation produced will
depend on the type of release.
Some organizations may differentiate between installing a product and deploying it.
Installation is seen as the act of loading the product into the live environment, and deploying
it is the process of making it available to customers. The distinction may be unnecessary
where a small enhancement is being made on a single site, but is very useful when a large
upgrade or new product release is being undertaken, possibly on many worldwide sites
simultaneously.
If the product requires installation, system confidence tests should be performed and an
installation report produced that identifies the results of the installation (e.g. issues and
problems encountered). In the case of failure it is important to have a fallback or back-
out plan, which would be developed as part of the release planning. Typically this allows
rollback to the previous version of the product.
116 © BSI 2012 Version 1.1.0

Maintenance Management
Training for IT operations staff and users, which may have started earlier, should now
be completed, and the incident reporting system initiated and tested, as necessary, for
example, if some new procedure or reporting elements have been introduced. In addition,
organizational changes may be necessary as part of the installation. For example, a new
complex product may require enhanced operational support, or the geographical reach of
a product may be extended, requiring local support desks to be established.
The product is usually deployed into operation by formally announcing its implementation,
making it available to the user population and starting the operational infrastructure
(organization and incident reporting system). If there is a warranty period provided by the
development team, the team will usually be responsible for managing and acting on initial
incident reports.
Once the release criteria for the development team, i.e. levels of incidents, customer
satisfaction, etc., have been achieved, the product is usually handed over to the support
team, along with the relevant documentation, including supporting information from the
transition and release process.
The aim of the Maintenance Management process is to provide a framework by which

changes to the operational product or live service can be undertaken effectively. Changes
can result for many different reasons, including correction of a product defect, resolution
of an ongoing problem, customer requirement, enhancement request, etc. In this context,
therefore, ‘maintenance’ does not have the more commonly understood meaning whereby
something is replenished or replaced due to wear and tear. However, activities such as data
purging, disk defragmentation and tape cleaning, would more typically be covered under
‘operational management’, although the provision of these actions would be considered a
service, and therefore subject to maintenance.
Any operational work product, including service elements, may be subject to maintenance.
For example, in addition to the product itself, supporting documentation, such as a user
manual, might require maintenance if found to be inaccurate, confusing or ambiguous. If the
product is accompanied by associated user training, the training material could be subject
to maintenance as a result of delegate feedback, changes in the product operation or use,
or external influences such as legislative changes. Services, such as help desks, desktop
© BSI 2012 Version 1.1.0 117

support, and operation, may also require maintenance for many of the same reasons that a
product may require maintenance.
In essence, the maintenance framework should identify a lifecycle that ensures the
maintenance activities are understood and formally planned, developed, tested,
implemented and deployed into operational or live use. The extent of the activities
required will depend on the nature and complexities of the business environment, the
product or service being delivered, customer requirements, etc. These could range from
the maintenance requirement being logged, addressed, verified and implemented within
a small dedicated support team using one of the many online support tools, through
to a more extensive analysis, development, test, pilot and deployment by a number of
organizational groups. Notwithstanding the options available, it is important that the
organization has a clear understanding of the differences between ‘true development’ and
‘maintenance’. Undertaking major development work via the maintenance processes could
increase risk and impact on quality, cost and the schedule. Undertaking maintenance using
the full development approach would be inefficient, introducing unnecessary overheads
and costs. Typically, the distinction between and use of the two approaches is clarified in
the supporting policy and procedures.
The Maintenance Management process works closely with a number of other processes,
including PRJ.5 Problem and Incident Management, PRJ.3 Configuration and Change
Management, PRJ.1 Project Management, TEC.4 Verification and TEC.5 Validation. Problems
and incidents will be assessed as they arise, with some requiring a product or service change,
which are handled through the Configuration and Change Management process before
being addressed by the Maintenance Management process. Other problems and incidents
may not require a change to the product or service, e.g. an incident may merely require
some advice being provided to the customer or user raising the incident. An identified
problem may require a change to a development lifecycle procedure and, typically, this
is not considered maintenance, although the owners of the internal procedures may well
consider this to be maintenance.
Project Management processes may be used to plan and monitor maintenance work,
although less formal approaches based on a transaction-based task or work management
approach may well be used. Similarly, the Verification and Validation processes could be
used to test maintained products and gain acceptance from the customer of the updated
product or service.
118 © BSI 2012 Version 1.1.0

As with other TickITplus processes, the process outcome is used to illustrate the result of
effective practices. For maintenance this would be demonstrated when the maintenance
process does not result in any rework as a result of the maintenance activities undertaken.
However, and again similar to other TickITplus processes, this is seen as a stretch objective,
rather than an absolute requirement. In practice, rework may be necessary, but organizations
should strive towards this goal through process monitoring, auditing customer feedback
and continual improvement.
The BPL Maintenance Management process consists of four base practices. These are:
BP.1 Define the Maintenance Policy and Procedures

BP.2 Plan the Maintenance
BP.3 Undertake the Maintenance
BP.4 Deploy the Maintained Product.
In many cases there is no implied order to the base practices, but clearly an obvious order
is implicit in this case. The maintenance needs to be understood and planned before being
developed and tested, and before being deployed. In some rare cases, the maintenance
may be quite extensive and require some element of phased work, but again the order of
each individual phase would be implicit. If this is the case, consideration should be given to
using the standard development processes when extensive work is involved rather than the
maintenance processes.
BP.1 Define the Maintenance Policy and Procedures
A maintenance policy should be prepared that ensures a clear understanding of when

maintenance rather than development processes should be used, what activities are
required, who should be involved and what records should be retained. The policy should take
into account the business objectives, and statutory, regulatory and security requirements.
The policy should provide the framework for developing specific maintenance procedures.
The policy should be reviewed and approved by top management, and maintained under
the management framework.
Supporting procedures should be developed to implement the defined policy. Procedures

may define a stand-alone approach to the maintenance activities (i.e. provide instruction on
each base practice), or may provide structure to the maintenance activities, with referencing
to other organizational processes, e.g. the Verification process (TEC.4) for testing the change.
© BSI 2012 Version 1.1.0 119

Procedures should accommodate the various levels of importance of maintenance tasks.

In particular, arrangements for emergency or critical maintenance changes and releases
should be specified. In this case, certain desired activities may have to be delayed in
order to ensure, for example, that a critical system is quickly patched and restored in the
event of a major incident or failure. The scope of these exceptions should be covered in
the policy and clearly described in the procedures. While some activities may be allowed
to be postponed, others, such as verification, should always be undertaken. It would be
unacceptable for all stakeholders to release a maintenance fix that would go on to cause
major problems or issues either at the time of the release or at some future point. Care
should therefore be taken to ensure that, for any emergency maintenance work, where the
full set of procedures has initially not been comprehensively followed, rework is undertaken
to ensure the integrity of the maintained product by reapplying standard procedures.
In addition to providing instruction on the maintenance activities, the procedures should

include measurement parameters that help provide management with an insight into the
effectiveness of the maintenance process. For example, this might include:
• the number of change requests being processed and normalized against the size of the
product or service being maintained
• the number of changes being applied to individual products or services
• the duration and effort required to undertake the change
• the nature of the changes, i.e. critical, routine, enhancement, bug fix, etc.
• status measures, such as the number of issues that are open, closed, on hold, etc.
• customer acceptance or satisfaction measures.
The procedures should be reviewed, approved, communicated and maintained under the
management framework.
The policy and procedures should be reviewed regularly to take into account any changes
either within the organization or to statutory, regulatory and security requirements.
BP.2 Plan the Maintenance
Changes should typically be identified, analysed and recorded through the Problem and
Incident Management processes, along with the Configuration and Change Management
processes. However, implementation of the change should be formally planned.
120 © BSI 2012 Version 1.1.0

Planning should include both resourcing and scheduling, and is typically undertaken
in one of three ways. One approach is to simply base the planning on the nature of the
maintenance and, in particular, whether it is addressing an emergency or critical problem.
Here, prioritization should place the required changes at the highest level, and should
invoke emergency maintenance and release procedures. This can override existing plans
and maintenance work, to ensure that resources can be applied as needed to address the
issues.
In the second case, the maintenance resource, i.e. the maintenance team, is fixed. In
this case, work is prioritized against customer needs and priorities. Change requests are
initially queued and are then subject to regular review and prioritization, to be allocated
for implementation as resources become available. The plan is typically driven around
resource availability. This approach tends to be used for the more routine, less extensive
type of maintenance, and relies more extensively on the effective implementation of a
change control board to review change requests and agree priorities.
In the third case, which applies more often when larger more extensive maintenance is
being undertaken, the resource needed is identified, allocated and scheduled against the
maintenance work. The plan is more in line with a standard development plan, where
scheduling is aligned to delivery dates.
Plans should be reviewed and approved by stakeholders. For smaller tasks, this may be
understood by the team through the work allocation and change control processes. For
larger maintenance tasks, where a more comprehensive plan must be prepared, involving
different organizational groups and stakeholders, a more formal review should be
undertaken.
The planning of the overall maintenance activities is at a higher level than the planning for
specific maintenance tasks. Maintenance can be managed through a defined continuous
service approach or use project management principles. In either case, organizations
should identify the arrangements for reviewing the plans and performance of maintenance
activities. For example, the service may be reviewed on an annual basis to ensure that
sufficient resources are available for the anticipated workload. In the case of the maintenance
being managed using project management principles, an annualized project approach is
often seen, where the project ‘artificially’ goes through a close and replanning cycle at the
end of each annual cycle. This often coincides with the organization’s financial year and
budget cycle.
© BSI 2012 Version 1.1.0 121

BP.3 Undertake the Maintenance
Maintenance work should be undertaken in accordance with the defined procedures.

Existing product or service documentation, in particular design documentation, should
be used to support and record the changes being made. Depending on the nature of the
maintenance request, and the amount of analysis that was undertaken when the change
was raised, the maintenance activities could include various degrees of requirements
analysis, design, development and testing.
Where the maintenance is fairly straightforward, changes to the product or service may
simply be implemented and verified. However, where the change is extensive or not fully
defined, further analysis of the maintenance requirement may be necessary. This may
involve various levels of contact with the group making the request, to understand further
the nature of the requirement. If additional analysis is required, the final nature of the
change to be implemented should be documented and reviewed with the group requesting
the maintenance. Any additional requirement documentation should also be identified and
maintained under formal configuration control.
Detailed levels of design may be necessary where significant or complex changes are
required. Existing design documentation should be updated to reflect any changes in
the design being made. Revised documents should be reviewed and placed back under
formal configuration control. This will ensure that future maintenance has an accurate and
complete baseline to work from. Traceability to the maintenance requirements should also
be provided to ensure that all the maintenance requirements have been addressed and can
be comprehensively verified.
Changes should only be made to the known live product or service baseline, which should be
maintained under the configuration management system. However, sometimes maintenance
is required on a product or service that itself is currently being updated for other reasons.
For example, a particular product may be being developed through a phased approach and,
while the second phase is being developed, changes are required to the first-phase release.
Clearly in this case, changing the first-phase baseline would not be sufficient, as the change
may or may not also have to be reflected in the second-phase development. One factor
influencing where and how the change is made would be the urgency of the maintenance.
In some cases the first-phase release may need to be updated and released into live use,
while the maintenance is also passed through to the second-phase development team. In
other cases, for example, if the second phase is nearing release, the maintenance may only
122 © BSI 2012 Version 1.1.0

be reflected in the second-phase development, or potentially deferred to a subsequent

phase. In more rare cases, a decision may be made to incorporate a patch into the live
system, but this should be considered very carefully, as it has many potential risks.
It is also important that original design and coding standards are applied wherever possible to
ensure that the final baseline remains consistent. However, in some cases the maintenance
is undertaken on products that were created some time previously when no design and
coding standards were in use. While not ideal, care should still be taken to ensure that the
resulting baseline remains consistent, unless, for example, the organization decides that
components of the product are completely redesigned as part of the maintenance. However,
in this case consideration should be given to applying the full development approach.
Changes should be verified once they have been undertaken. Again, this may range from a
simple verification of the changes (e.g. that a screen layout has been adjusted or a report
changed) to verification of a complex change through more extensive unit, integration and
system testing. An important factor to consider in verifying any maintenance change is the
extent of regression testing undertaken. In some cases it would be virtually impossible or
impractical to undertake a complete retest of the original product, but it is equally important
to ensure that it is not just the change that is verified, as even simple changes can have
dramatic side effects. The amount of regression testing undertaken will impact on effort
and schedule, so it should be considered during the planning of the maintenance. What to
test will invariably depend on the nature of the maintenance, the approach taken to the
original development, and the risks involved.
The final step should involve some form of validation or acceptance by the group requesting
the maintenance. This can range from a simple written acknowledgement to a more
extensive and formal validation exercise. Again, whatever level of acceptance or validation
is applied, it should be defined as part of the planning activities for the maintenance.
Validation should ensure that the maintenance work satisfies the original intention of the
request, with traceability back to requirements and confirmation from the group requesting
the maintenance that the requirements have been addressed. Records of the results of
validation or acceptance should be retained.
Finally, the resulting baseline should be placed back under configuration management.
© BSI 2012 Version 1.1.0 123

BP.4 Deploy the Maintained Product
In most cases maintenance will be undertaken on products, systems or services that are
in live use (i.e. they are being used by customers and users). Unless the maintenance is
to address an emergency or critical problem, such as in a production-halted situation,
the deployment of the maintenance release will need to be scheduled to fit in with the
user’s needs. Clearly, for an emergency or critical situation the aim would be to release the
maintenance as soon as possible, but for other types of maintenance the release should be
prioritized. This should be done as part of a change control board or equivalent. The change
control board may be established as a specific meeting or be integrated with other routine
meetings. Either way, the meetings should include representation from all appropriate
stakeholders, including the customers and/or user community.
Factors influencing the deployment of maintained products include access to the hosting
infrastructure, availability of customer and/or user representatives, customers’ operating
models, the agreed maintenance strategy, etc. The maintenance release will need to be
deployed, at some point, into the live environment, and this will invariably mean some
form of downtime in which to load and test the product. This should be scheduled for a
time when it will have least impact on the customer’s business, for example in the evening
or at weekends. As part of the deployment, the customer or representatives from their
user community will need to be available either to participate in any installation testing or
confirm successful operation. Closely related to the availability of the hosting infrastructure
would be the customer’s business model, which may infer specific times when it would
be inappropriate to deploy new releases (e.g. bank holidays for the leisure industry, major
sporting events, major shopping days). The maintenance strategy would also influence the
deployment of maintenance changes when, for example, release-based maintenance is
being applied. In this case, and apart from emergency releases, maintenance releases may
well be scheduled on a periodic basis in advance, with agreement from the customer.
Stakeholder Requirements Definition
The primary purpose of the Stakeholder Requirements Definition process is for the
development organization to establish a clear, complete and unambiguous set of
requirements from which the product development can be undertaken. While this is a
primary goal, it is recognized that this may not, for many reasons, always be achievable
in practice. Consequently, the process also encourages the involvement of stakeholders –
124 © BSI 2012 Version 1.1.0

primarily the customer or its representatives – to be actively involved during the whole
development process.
The involvement of stakeholders can vary considerably from one situation to another. In
some situations, the stakeholder’s involvement may just require availability to address
issues or to review various project documents. In other situations, the stakeholder’s
involvement might be much more active in one or more development processes, such as
attending workshops, demonstrations or participating in testing.
In identifying requirements for the product, this process refers to stakeholders rather
than just the customer, as it is recognized that in some situations there may be multiple
groups, organizations and third parties who have an interest or influence on the product
development.
Apart from the customer, the range of stakeholders is quite large and includes both
stakeholders directly involved in the product requirements (e.g. buyers, users, integrators,
support engineers) and indirect stakeholders (e.g. legal, regulatory or statutory bodies). For
example, in developing database systems that involve processing of personal data, the UK
data protection legislation will have to be accommodated, even if it is not explicitly required
or mentioned by the customer.
Stakeholders can be internal as well as external. For example, in the case where a core
product is going to be customized for an external customer, the development team might
also have to consider the needs of the core product development group, and hence this
group could also be considered a stakeholder. Stakeholders can also be completely internal
to the development organization, for example where a COTS product is being developed.
Here, the customer could be the marketing group and the stakeholders could include the
executive team, the service department and the sales team.
A successful outcome of the Stakeholder Requirements Definition process reflects the

importance of identifying all stakeholders and ensuring that they are actively involved, as
agreed, throughout the development project. However, it is recognized that it is sometimes
hard to regulate the activities and involvement of stakeholders and customers. Nevertheless,
development organizations are expected to take all reasonable proactive actions to minimize
the potential risks that might be incurred with less-involved stakeholders.
© BSI 2012 Version 1.1.0 125

Active involvement by the stakeholders should be evident and be supported by proactive

actions by the development organization. If appropriate levels of involvement are not being
seen, this should be considered an issue and escalated to higher management for resolution.
The BPL Stakeholder Requirements Definition process involves four base practices. These
are:
BP.1 Engage Requirements Stakeholders

BP.2 Develop Stakeholder Requirements
BP.3 Validate Stakeholder Requirements
BP.4 Manage Changes to Stakeholder Requirements.
BP.1 Engage Requirements Stakeholders
There have been many examples of IT development failures where the cause has been
attributed to either a lack of identifying or understanding who the stakeholders were or,
where identified, a lack of the required involvement. As an early activity of any development,
the identification of stakeholders, their involvement and the communications necessary
is essential. This is particularly important during the requirements capture phase, which
can be an independent activity undertaken prior to the actual start of the development
process, or even as part of a completely separate project.
There are many and varied methods for identifying the stakeholders, ranging from the
less formal approaches such as historical knowledge, prior engagements and standard
arrangements, to the more formal approaches such as workshops, lessons-learnt databases
and knowledge-based systems.
As a minimum, the stakeholders involved in establishing the requirements should be

identified and documented along with their role and responsibilities. This involvement
should exist throughout development lifecycle and, where appropriate, into support and
maintenance activities.
Of all possible activities where the customer and other stakeholders should be actively
involved, their involvement in establishing the stakeholder requirements is essential. It
is also important that this involvement should continue throughout the development to
address issues, concerns or changes to the requirements.
126 © BSI 2012 Version 1.1.0

BP.2 Develop Stakeholder Requirements
The identification of clear, complete and unambiguous requirements is one of the more
difficult activities to achieve successfully, yet contributes most significantly to the overall
success of the development.
In aiming for success, a good starting point is to establish who the ultimate customer is and
all the potential stakeholders. Once the stakeholders have been identified and their roles
clarified, the stakeholder requirements can start to be formally captured. The starting point
will usually be through some form of initial customer correspondence, possibly a request
for a quote, a formal order or purchase order, or through a tender specification as part of a
formal tendering process. Internally, this correspondence could be an instruction from the
executive team or a specification from the marketing department.
A formal review of the initial correspondence provides a good starting point for establishing
the full set of stakeholder requirements. Indeed, it may be all that is necessary. However, in
many cases, further work on capturing the full requirements will be needed, and the review
of the initial correspondence can help identify subsequent actions that need to be taken. It
may also identify additional stakeholders that were not initially considered.
Typically, the subsequent actions necessary involve gaining a better understanding of

what is required, why it is needed and what business objectives are being addressed by
the customer. This type of information helps greatly in developing a product that satisfies
its intended purpose and expectations, rather than simply being built to order. Again,
there are many approaches to this, including discussions, workshops, demonstrations,
prototyping and modelling, but whichever method is used the final results should be
formally documented and reviewed (see TEC.4 Verification).
Even after taking all appropriate actions, in some cases it might not be possible to achieve
the level of understanding that is desirable (e.g. where the customer acknowledges that they
are not fully clear on what they require). This does not mean that the exercise has failed,
but, in fact, can actually help greatly in ensuring a more successful product by allowing a
more appropriate lifecycle model to be selected for this type of situation. Conversely, care
should be taken to watch out for the situation where it is believed that the stakeholder
requirements are fully complete but, in practice, deficiencies exist. This is more likely to be
the case when not all the stakeholders or inappropriate stakeholders have been identified
or involved.
© BSI 2012 Version 1.1.0 127

Even if a good set of requirements has been established initially, it is very important to
continually monitor the requirements as they are developed. This is to ensure that any
identified gaps or ambiguities are addressed as soon as possible, and that the development
does not suffer from uncontrolled requirements (or scope) creep.
The stakeholder requirement definition, in whatever form it takes, should be managed

under the configuration and change management system. This is particularly important for
the set of requirements, as it ensures that appropriate baselines are identified from which
all further development activities will follow.
One additional aspect should be implemented at this stage to help towards a successful
development. This involves ensuring that the requirements can be traced throughout the
chosen lifecycle to the final validation activity. Requirement traceability can be achieved
in a number of ways, ranging from the use of specific requirement management tools, to
the careful structuring and numbering of the requirements. Large textual blocks are not
conducive to enabling such traceability, and such situations should be avoided.
BP.3 Validate Stakeholder Requirements
As part of the process, the stakeholder requirements should be validated with the customer
to ensure that they continue to fulfil the customer’s needs and objectives. In some situations
this will be occurring in parallel with establishing the requirements through discussions,
workshops, etc. that involve the customer. In other cases it may be necessary to submit
the documented stakeholder requirements to the customer for review and approval. In
either case, but more importantly in the latter case, care should be taken to ensure that the
stakeholder requirements are expressed in such a way that the customer can reasonably be
expected to understand what is being presented.
As part of the validation activity, any issues or concerns should be addressed before final
agreement is sought from all stakeholders identified to approve the requirements. Even if
the stakeholders have been actively involved in preparing the requirements, there should
be some formal point in time where the requirements are approved for use and placed
under formal configuration and change management. Any unknowns or concerns at this
point should be considered as risks and tracked through risk management.
It should be noted that, while this is an initial validation activity aimed at mitigating risks
to the development process, the final validation of the requirements cannot be considered
128 © BSI 2012 Version 1.1.0

complete until the product is available for test in its intended environment. Nevertheless,
effective validation here will contribute greatly to a more successful development activity.
With some lifecycle models, validation activities actually continue through the lifecycle
phases, especially when the Stakeholder Requirements Definition process has identified that
the requirements are not as complete as needed. Even in these cases, formal requirement
validation should still be undertaken to ensure that what does exist is correct – so that
subsequent development is not misdirected.
BP.4 Manage Changes to Stakeholder Requirements
The final base practice addresses changes to the baselined requirements that might occur
throughout the development process. Again, this is an area where many organizations have
difficulties. Changes have been uncontrolled, and the development has become impossible
to manage to the agreed schedule or budget through the resulting creep in requirements.
The prerequisite for handling changes effectively is that the stakeholder requirements are
under appropriate configuration and change management. The need for identified changes
can then be managed through the formal change management process.
In some cases, organizations set up a formal change control board that involves the customer
and appropriate stakeholders. This approach can address all the requirements set out in
this base practice, and may involve a formal stakeholder meeting held on a periodic basis, a
virtual change control board using electronic tools, etc. Irrespective of how the changes are
managed, it is important that appropriate levels of stakeholder representation are involved
in the process. In many cases, where stakeholder requirements need to be changed there
will invariably be an impact on the schedule, budget and functionality. For example, where
the customer is requesting a reduction in the budget or schedule, the effect will probably
be on what can be developed in the time available. Here, the functionality may have to be
reduced or be phased, or the cost may have to increase because extra resources are needed
to maintain the development in a shorter timescale. Similarly, if additional functionality
is required, this will almost certainly affect either the budget or the schedule, or both.
Therefore, participants in the stakeholder change process should have appropriate authority
to make the necessary decisions and agreements.
In many cases, not all the stakeholders will need to participate or, for various reasons,
will not be able to participate, in the formal change process. Therefore, it is essential that
© BSI 2012 Version 1.1.0 129

following the change process all necessary stakeholders are made aware of the result and
the implication of the changes that have been approved, and in some cases also of those
that have been rejected.
Requirements Analysis
There is a close link between the Requirements Analysis process and the Stakeholder
Requirements Definition process, which precedes it, and the Architecture Design process,
which follows it. However, these processes are rarely truly sequential, and, in many cases,
there will be a fair degree of overlap and iteration through the initial stages of a project.
The output of the Stakeholder Requirements Definition process is typically customer focused
around the functionality, objectives and needs of the product development, whereas the
input to the Architectural Design needs to be system or engineering focused. Therefore, the
purpose of the Requirements Analysis process is to transform the stakeholder requirements
into a set of structured system requirements that form the basis of the product development.
Clearly, the amount of requirements analysis that will be needed is dependent on many
factors, but is influenced mostly by the nature of the stakeholder requirements. In some
situations the stakeholder requirements may already be sufficiently engineering orientated
that little additional analysis is required. For example, in very large development projects,
where multiple suppliers are involved in developing subsystems, the prime supplier may
well provide subcontract suppliers with very detailed engineering requirements. Similarly,
in very small enhancement projects, the customer requirements may be sufficiently
straightforward and understood by the supplier that no, or very little, further analysis is
necessary.
In other situations, the stakeholder requirements may be very high level and focused
virtually entirely on the business or operational needs of the customer. For example, the
prime supplier in the example above may well have received an operationally specified
requirement for the product, such as is often seen in the public sector. Even in small
developments or enhancements, the stakeholder requirements can appear system focused
on the surface, but on further consideration may not actually be what the customer really
needs.
Irrespective of how much requirements analysis is necessary, as a minimum the stakeholder

requirements need to be evaluated in terms of their suitability for continuing with the
130 © BSI 2012 Version 1.1.0

Requirements Analysis
architecture design. It is at this point that the development organization will get its first real
idea of the size of the development project. Product sizing is probably the most important
attribute of any development project, as it:
• provides one of the key inputs to the estimating process

• offers a unique mechanism for monitoring potential requirement creep
• enables the ability to normalize data over multiple projects
• forms the basis of many high maturity practices.
As with many other process outcomes in TickITplus, the outcome for the Requirements
Analysis process aims at a high standard, but in practice the limitations do need to be
recognized. The outcome clearly expects a set of system requirements to exist, but also
that they are produced in such a way that there is no subsequent unnecessary rework to
them. Reworking the system requirements can happen for many valid reasons, such as
following approved changes to the stakeholder requirement, but every effort should be
taken to ensure that errors and mistakes later in the development are not attributed back
to a weak Requirements Analysis process.
There are four base practices that make up the BPL Requirements Analysis process. These
are:
BP.1 Develop System Requirements

BP.2 Estimate System Requirements Size
BP.3 Manage System Requirements
BP.4 Manage Changes to Requirements.
BP.1 Develop System Requirements
As indicated, the amount of requirements analysis and when it is performed depends largely
on the process for defining the stakeholder requirements and the nature of the resulting
output. If stakeholder requirements are very high level and focused virtually entirely on the
business or operational needs of the customer, the requirements analysis activity could be
quite extensive.
There are a number of different approaches to performing a satisfactory requirements

analysis activity, but in the main they all tend to rely on the use of appropriately skilled
resources and strong review techniques.
© BSI 2012 Version 1.1.0 131

If not already done during the Stakeholder Requirements Definition process, due
consideration should be given to any internal developments and any underlying core
product development strategies. For example, in analysing the stakeholder requirements
some system requirements could be identified that may need to take into account certain
organizational constraints or goals, for example relating to performance. This typically is the
case when the customer development involves customizing a core product.
Finally, the system requirements are formally reviewed (see TEC.4 Verification), and
placed under formal configuration management (see PRJ.3 Configuration and Change
Management).
BP.2 Estimate System Requirements Size
At some point during the Requirements Analysis process, typically towards the end or,
alternatively, throughout, an estimate of the product size should be generated, reviewed
and documented. The size estimate is not given in hours or effort, as these would typically
result from the size estimates. Size can be expressed in many ways, ranging from the classic
lines of code and function points, to use cases, interfaces or simple requirement counts.
The important aspect here is that the approach to sizing does not have to be scientifically
accurate, as it is only intended to provide additional estimating information.
Size estimates provide or support the estimates of cost, scheduling and resourcing. Given
a common size parameter that is used across projects, and the collection of actual project
performance data such as costs, estimating can be based as much on historical data as on
the specifics of the individual project. While this practice is covered in the Requirements
Analysis process, which is most often undertaken by the engineering discipline, the
estimating of costs, schedules amid resources is more commonly performed by the project
management group. However, TickITplus base practices do not infer any particular order or
any particular implementation group.
BP.3 Manage System Requirements
An important characteristic of the system requirements is that they are structured to show
the sequencing, prioritization, functional, non-functional and interface requirements. In
addition to driving the architectural design, the system requirements will form the key
input to the system testing activities.
132 © BSI 2012 Version 1.1.0

Architectural Design
In a similar way to the stakeholder requirements, the system requirements should be

identified in such a way as to facilitate traceability back to the stakeholder requirements,
and forward through the development, integration acceptance and final release.
As well as placing system requirements under configuration management, agreed

requirements should be formally baselined. In essence, the distinction is that placing the
requirements under configuration management will ensure that changes are formally
undertaken, whereas creating a formal baseline at a specific point in time provides a
snapshot of the requirement set. In many cases where the requirements are textually based
in a single requirement specification, these will occur naturally together but, if requirement
management tools are used, this may not always be the case. For example, each requirement
could be individually version controlled, or there could be multiple versioned requirement
specifications that collectively make up the requirements baseline.
BP.4 Manage Changes to Requirements
The final base practice, as with many of the TickITplus processes, addresses the management
of change. The prerequisite for handling changes effectively is that the system requirements
are under appropriate configuration and change management. Identified changes can then
be managed through the defined Configuration and Change Management process.
Whereas changes to the stakeholder requirements more often originate from the
stakeholders, changes to the system requirements can originate from either change to
the stakeholder requirements or internally from the organization or development project.
Some internally required changes can be managed completely internally, while others may
need to go through the same mechanism as for changes to the stakeholder requirements.
In either case, it is essential that, following the change process, all necessary stakeholders
are made aware of the result and implication of the changes that have been approved or
rejected.
The purpose of the Architectural Design process is to produce a top-level design that
identifies the major components and interfaces of the product. The word ‘product’ here
may be taken to mean a complete product, a product component, a service or a service
component.
© BSI 2012 Version 1.1.0 133

Architectural design usually occurs on a product development project or programme

of change within the organization. Depending on the lifecycle model used, it can be
undertaken as a separate stage or as an inherently iterative process working intimately
with the Development Implementation process. In the latter case, it is usual for both to be
repeated, as the solution is developed in the best way to meet the system requirements. A
top-level design may need to be modified after one or more of the components have been
designed.
Many stakeholders are often involved in the Architectural Design process. However, there
is usually a single technical authority on the project (e.g. a senior designer), who has the
responsibility to ensure that the system design is adequately performed, and that the system
requirements are met. Where there are multiple internal groups involved in a project, the
project will usually establish appropriate controls to co-ordinate intergroup issues. This is
often achieved through a group consisting of technical team leaders, from the disciplines
involved, who have the responsibility for analysing and accepting the system requirements.
The successful completion of the Architectural Design process usually results in a top-level
or system design for the product, which has been reviewed, approved and maintained
under controlled conditions (see PRJ.3 Configuration and Change Management).
As with other lifecycle processes identified within TickITplus, the outcome of the Architectural
Design process states that there should be zero defects identified in the subsequent phase
that were introduced as a result of architectural design activities. However, in practice this
would rarely be seen, especially given the complex nature of products being developed these
days, but nevertheless the organization should be proactive in trying to reduce such defects.
In order to aim for zero architectural design defect leakage, the organization should establish
clear verification criteria for designing and reviewing top-level designs. In addition, it should
capture and record all downstream defects found, analyse them for root causes and put in
place actions to remove them from the Architectural Design process.
There are four base practices defined in the BPL Architectural Design process that work
collectively to achieve the process outcome. These are:
BP.1 Establish Development Approach

BP.2 Create Architectural Design
BP.3 Review Architectural Design
BP.4 Manage Architecture Changes.
134 © BSI 2012 Version 1.1.0

BP.1 Establish Development Approach
The starting point for establishing the development approach will normally be through
the selected development lifecycle chosen. However, this will only provide a standard
organization lifecycle, and it is therefore important to consider it in light of the particular
customer needs and development requirements.
Make, buy or reuse analysis begins early in the project, when requirements are being
developed, continues during the system design, when different design options are being
considered (at both high and detailed levels), and completes with the decision(s) to make,
buy or reuse products or product components. The decision whether to make, buy or reuse
is usually a trade-off between technical requirements and cost/time considerations.
Bought-in items are rarely a zero-effort solution for the project. If the functionality is not
exactly what is required, or the interface works differently, then effort will be required to
deal with this and possibly constraints will be imposed on the system design. These factors,
and the effort and cost they impose on the project, should be taken into account when
considering the approach to be taken.
Also to be considered is the cost and effort required to maintain the bought-in item over
the lifetime of the product or product family. This may require the production of a buy-
in strategy detailing who will support the item and the timescales and responsibilities for
support.
Factors affecting the make, buy or reuse decision should include the following:
• the functions the products or services will provide and how these functions will fit into
the project objectives
• available project resources and skills, and the impact on core organizational competencies
• the costs of acquiring versus developing internally
• critical delivery and integration dates
• strategic business alliances, including high-level business requirements
• market research of available products, including COTS products
• the functionality and quality of available products
• the skills and capabilities of potential suppliers
• licences, warranties, responsibilities and limitations associated with products being
acquired
• product availability
© BSI 2012 Version 1.1.0 135

• proprietary issues
• risk reduction.
The selection decision and supporting rationale should be documented, reviewed and
approved. Where the decision is strategic or complex, decision grids can be used to help
guide the decision.
BP.2 Create Architectural Design
The system requirements are analysed to identify the major system components (e.g. logical
groupings, services). In doing this the analysis should note any interface requirements
between the major components and the external environment, along with any design
constraints (e.g. interface standards, communications protocols) that may arise. The
analysis should also consider key non-functional requirements, such as the need for reuse,
information policies, security arrangements and performance requirements.
The design should also consider the target operational environment that is likely to be in
use at the time of product release. Changes to the operational environment typically have a
long response time due to the sensitivity and complexity of most operational environments.
If any changes are to be made, then the sooner they are initiated, the better.
Identifying clear design criteria that are used to improve the quality of the design also
reduces the time taken to produce the design and ensures better efficiency of the review.
Often these criteria will be expressed as internal design standards. An example of such
criteria is that modules should exhibit internal integrity and minimal external coupling. If
two components are identified with a large number of interactions between them, this
would be a good indication that they should be grouped, or that the functionality should
be split along different lines. Conversely, if the system design has little (but key) interaction
between a minimum number of components, this can be taken as an indication of good
system design and a good (stable and robust) architecture. In general, components should
be grouped by their interactions rather according to any preconceived ideas about how the
functionality should be split.
As the design becomes clear, the requirements can be mapped onto design elements
to ensure that all system requirements are addressed by the design. Where system
requirements are split between more than one component, there will be a need to note
136 © BSI 2012 Version 1.1.0

the dual mapping of the requirement, or to develop derived requirements showing which
part of the requirement each component is responsible for.
The output of the Architectural Design process should be descriptions of a set of components
that can be developed in relative isolation from the other components, and of the
interactions between them. Techniques such as ‘use cases’ or ‘operational scenarios’ are
helpful in clarifying the architectural design and providing consistency in its communication.
BP.3 Review Architectural Design
The purpose of reviewing the top-level design is to identify and remove any defects that
might have occurred during its development. Defects cost dearly – costs incurred in making
them in the first place, cost involved in trying to find them, costs to remove them once
found and, not forgetting, the opportunity costs of what could be being done with the extra
effort being expended. In addition, the greater the gap between the introduction and the
removal of the defect, the more it costs to remove it. It is no surprise that defect removal
is one of the primary quality improvement strategies in use today. Ensuring the top-level
design is defect-free is one of the most powerful ways of ensuring that a project meets its
cost and time forecasts.
The effectiveness of reviews is raised massively by the involvement of independent

experienced staff who can provide a ‘fresh’ view on the design. Free of the developing
mindset of the design architects, and unencumbered by the restrictions of the project
timescale, they will often find defects that the author or author team cannot. If the purpose
of reviewing is to find defects, review by one or more experienced peers is the most effective
way of doing it.
The efficiency of the review process is raised by having a standard process, with trained
and skilled people who know the process well and have used it many times. In particular,
having a review leader who keeps the review moving forward and prevents any attempt
to solve the defects immediately greatly shortens the time required for the review. The
defects should simply be identified in the review, and solved later.
By selecting other stakeholders in the development, such as those from support and
maintenance, to act as peer reviewers, the reviews can also contribute to efficient two-way
communication. The peer reviewers learn about the system being designed. The author
team learns generally from the experience of the peer reviewers, and especially about
© BSI 2012 Version 1.1.0 137

the sort of mistakes that they make. This builds their ability to avoid such mistakes in the
future, and provides the peer reviewers with an excellent early insight into the product and
requirements.
The formality of the review process is best adjusted to the circumstances of the project
or organizational area. In all cases, however, it is the rigour of the review process that
determines its effectiveness in identifying defects. The effort in defining, implementing
and maintaining a rigorous review process is more than repaid by the effort saved in fixing
defects, particularly those found late in the product lifecycle (see TEC.4 Verification).
BP.4 Manage Architecture Changes
Changes are a fact of life, and in some lifecycles are actively encouraged. Changes can come
from outside the organization (e.g. a change in legal requirements), outside the project or
organizational area (e.g. a change in business requirements) or from within the project or
organizational area (e.g. from discovering a defect).
Once the system requirements have been approved and work has started on the top-level
design, changes to any of the key configuration items (e.g. customer requirements, system
requirements, code) may occur. Such changes must be carefully managed. The mechanism
for this may vary from a discussion and agreement as part of an agile team, for example, to
a formal process involving multiple stakeholders.
Development Implementation
The purpose of the Development Implementation process is to transform the system

requirements and architectural design into a product. The word ‘product’ here may be
taken to mean a complete product, a product component, a service or a service component.
It is taken as axiomatic that there are requirements of some sort, although often these may
not be of sufficient detail or accuracy to create a product. If the requirements are felt to be
inadequate, it is better to spend time creating a suitable set of requirements than hoping
to just ‘get through it’. However, it is possible to illuminate areas where the requirements
are deficient by moving forward with the design. In the case of, for example, an agile team,
or a team with regular and easy access to a customer or customer representative, this can
be a most efficient way of working. If this approach is taken, care must be exercised to
138 © BSI 2012 Version 1.1.0

ensure the integrity of the system requirements with the design. A mechanism such as a
traceability matrix is very helpful in such situations, although requirements traceability is
always useful.
What makes a set of requirements suitable will depend on the product being created.
Typically, the set includes not just the functional and non-functional requirements, but
also some measure of the quality of these requirements. Various models such as ISO 9126
or functionality, usability, reliability, performance and supportability (FURPS) exist to help
here, but each organization should define its own standards for defining requirements and
then use inspections and peer reviews to ensure that they are effective and used.
Although it may also be obvious that the architecture has also been defined, this is not
necessarily the case. With development approaches that avoid the ‘big design up front’
approach, the architecture will be seen to emerge as development implementation
proceeds. Clearly, the emerging architecture would eventually meet the requirements of
architectural design.
The outcome of the Development Implementation process is a product that requires no

unexpected rework. Therefore, organizations will aim to ensure that the product meets
its requirements and, in addition, aim for there to be no unexpected defects or rework
required. Failure to achieve either of these aims may give the organization additional effort
and cost in the realization of the product.
The organization should have in place mechanisms for ensuring that the requirements
are met and for dealing with defects and rework. In addition to ensuring that the right
product is delivered, these mechanisms should also provide useful information about the
performance of the management system, and should be used periodically to help identify
improvement opportunities (see ORG.5 Improvement).
There are five base practices defined in the BPL Development Implementation process that
work collectively to achieve the process outcome. These are:
BP.1 Establish the Development Environment

BP.2 Identify Component Sources
BP.3 Design Components
BP.4 Implement Components
BP.5 Manage Design and Implementa on Changes.
© BSI 2012 Version 1.1.0 139

While normally there is no implied sequence to the base practices in the BPL processes,
some of the practices clearly work better after others have been completed. For example,
without the development environment, no development is possible, and it is usual to design
components before implementing them. Changes, however, can occur at any time, and are
usually dealt with as they arise.
BP.1 Establish the Development Environment
The development environment should be defined and established in line with the
requirements of the project. This may be a standard environment, which is therefore
constantly established and needs no special effort, or it may be a specific environment for a
particular project, in which case specific care and attention needs to be given to its design.
In establishing the development environment, various aspects should be considered,

such as design support tools, development tools, source code control and configuration
management (document and code), group development environment, test tools and tools
to support the release process.
If the environment is being set up especially for the project, then the activity should be
managed as a key work package, including specifying the environment, planning and
tracking its creation, and testing that the created environment is the one required.
Where the development environment is a standard one, its configuration still needs
recording as part of the configuration management activities, although this may be done
once only at the organizational level.
Where the project team is distributed, consideration should be given to the use of
collaboration tools, such as conferencing tools, community repositories and project rooms.
Part of setting up the environment is ensuring that the people who are going to use it are
trained and capable of using it effectively. Typically, a technical lead will just check that
everyone has used the tools required on the project and arrange any training needed for
those who have not or who need a refresher. They will also check that people have login
information and the correct levels of access and privilege as required.
If any special resources are needed (e.g. a particular piece of test equipment, an expert in
the particular technology), it is important that they are identified and secured, especially
140 © BSI 2012 Version 1.1.0

where a resource is shared. Project delays due to the unavailability of shared resources are
quite common, and very frustrating.
BP.2 Identify Component Sources
There are three basic component sources resulting from buying, making or reusing. While
a decision may have been made on the overall development approach at a high level, there
can be further make, buy or reuse decisions at a component level.
Within the basic three choices there are further options. For example, possible reuse
options are to:
• reuse a component that has been designed for reuse (low effort);
• take an existing component not designed for reuse and use it, but on this product only
(more effort); and
• take an existing component not designed for reuse, make it generally reusable and then
reuse it for this product (most effort).
Such choices would require suitable business justification. Similar gradations exist with
regard to make and buy, and the project team needs to analyse these with regard to the
effect they have on the system requirements, especially on the delivery time and budget.
When choosing the component source, consideration must be given to the full lifetime of
the product or product family. Sourcing a component externally may look initially favourable,
but when support for existing and changing versions is factored in, and perhaps extended
to cover the lifetime of a family of products, the initial analysis may not be so clear.
Consideration should also be given to support costs beyond initial acquisition for the full
lifetime of the product or product family. How will product components be supported in
production, and in the field? This is as true for an internally sourced component (e.g. from
another project team or product team) as it is for one sourced externally.
Externally sourced components or capabilities may give rise to the option to adjust the
architecture to achieve time or cost savings. Such changes are handled through the change
management process and lead, of course, to changes to the architecture and all derivative
downstream products.
© BSI 2012 Version 1.1.0 141

BP.3 Design Components
Design transforms the requirements for the component to statements that can be
implemented. It marks a key transition of the description of the solution from the language
of the problem space to that of the implementation space.
The design of each component should describe how it operates, and include full details of
its interfaces with the rest of the system and external world. It also includes details on which
system requirements are being satisfied by the component, although such information
may be controlled separately (e.g. through a traceability matrix). A combination of all the
requirements detailed in the component descriptions and the interactions between the
components should cover each one of the system requirements.
Where components are being sourced externally, the design should cover the interfaces
between the component and the rest of the system, how they will be handled in the
configuration management system, and how changes to the bought-in components will be
transmitted through to the product. If architectural changes are considered necessary, the
cost-effectiveness of the bought-in component may need to be reassessed.
The use of design methods, covering activities, diagramming techniques and support tools
helps to improve the consistency and quality of designs produced, by ensuring that the
same type of information is produced for all design components, and making it easier to
cross-check information between different components.
If design standards have not already been defined, it is useful to consider them before
starting design work. Consideration should be given to items such as performance, security,
user interfaces, internationalization, navigation, help facilities, reuse and portability (e.g.
support of multiple hardware platforms).
Similarly, establishment of a defined approach to design will promote greater consistency

of design, thus reducing design errors and oversights, and making the subsequent system
building much easier and more trouble-free. Consideration should be given to items such
as:
• design method (e.g. procedural, object-oriented)

• concurrency (locking strategies)
• architectural layering
• type of database (e.g. object orientated, relational, flat file) and persistence strategy
142 © BSI 2012 Version 1.1.0

• processing distribution (e.g. client–server, use of stored procedures)

• data availability, persistence and security
• resilience (error handling, communications and database recovery)
• messaging and interface communication
• data distribution (location, integrity, volumetrics).
Prior to commencement of any coding, the design should establish the following:
• external interfaces (e.g. graphical user interface (GUI), report layouts, file formats,
remote calls)
• storage requirements (e.g. data model)
• links between the GUI, business process and database
• interfaces to existing infrastructure within the project.
These items may be captured informally (e.g. in existing code), or more formally in a design
description, but in either case it should promote questions, discussions and improvement.
A formal technical review of the system design will help to minimize the defects passed
through to subsequent phases. The review should check that every system requirement has
been captured, that organizational standards with regard to architecture, communications
and security have been met, and that there are no identifiable design defects (see TEC.4
Verification).
Organizations should review component designs and remove any defects found, and further
analyse the causes of the defects in order to propose any necessary change in the process
to prevent their future reoccurrence (see ORG.5 Improvement). However, the formality of
the review process is best adjusted to the circumstances of the project or organizational
area.
BP.4 Implement Components
Components are implemented in the manner appropriate for the type of component (e.g.
coding software, documenting services). In line with the approach to minimize defect
leakage, the organization should include a check on the quality of the implemented unit
(e.g. code inspections and unit testing for software, peer review for service descriptions).
© BSI 2012 Version 1.1.0 143

The organization should also analyse the nature of defects found and work to remove their
influence from future developments. The use of organizational implementation standards
(e.g. coding standards) helps to prevent known errors from occurring during implementation,
as does the use of coding support tools.
Where there are multiple development teams implementing components, the control of
different versions of components and their integration into a stable configuration assumes
greater importance than for co-located teams. This is why organizations strive to create
‘four-wall’ teams but are often influenced by desires to use more cost-effective ‘off-shore’
resources.
Acquiring components externally is not just a case of receiving them. The following items
should be considered:
• the activities that should exist to ensure that the acquired component is defect-free
• the design information that should be acquired
• the maintenance and support information should also be acquired
• how the components will be managed under control conditions
• how changes to the components will be handled
• how problems with and defects in the acquired components will be handled.
BP.5 Manage Design and Implementation Changes
Changes are a fact of life, and in some lifecycles are actively encouraged. Changes can come
from outside the organization (e.g. a change in legal requirements), outside the project or
organizational area (e.g. a change in business requirements) or from within the project or
organizational area (e.g. from discovering a defect).
Once top-level design is approved and development work has started, changes to any of
the key configuration items (e.g. customer requirements, system requirements, top-level
design) may occur. Such changes must be carefully managed. The mechanism for this may
vary from a discussion and agreement in, for example, an agile team, to a formal change
management system (see PRJ.3 Configuration and Change Management).
144 © BSI 2012 Version 1.1.0

BPL Guidance V1.1.1

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

BPL Guidance V1.1.1

Uploaded by

Copyright:

Available Formats

Base Process Library –

Dave Wynn and Peter Lawrence

© The British Standards Institution 2012

Typeset in Calibri by Helius

British Library Cataloguing in Publication Data

ISBN 978 0 580 78381 4

© BSI 2012 Version 1.1.0

Human Resource Management 15

Corporate Management and Legal 27

© BSI 2012 Version 1.1.0 3

Infrastructure and Work Environment Management 33

Measurement and Analysis 41

4 © BSI 2012 Version 1.1.0

Lifecycle Model Management 59

Configuration and Change Management 75

Problem and Incident Management 83

© BSI 2012 Version 1.1.0 5

Data and Record Management 88

Transition and Release Management 111

6 © BSI 2012 Version 1.1.0

BP.2 Plan for Release 113

Maintenance Management 117

Stakeholder Requirements Definition 124

Requirements Analysis 130

Architectural Design 133

Development Implementation 138

© BSI 2012 Version 1.1.0 7

8 © BSI 2012 Version 1.1.0

© BSI 2012 Version 1.1.0 9

10 © BSI 2012 Version 1.1.0

certification framework, leading to formal recognition of an organization’s process

Foundaon Bronze Silver Gold Planum

Figure 1: Overview of the TickITplus maturity levels

© BSI 2012 Version 1.1.0 11

The purpose of this guide

The structure of the Base Process Library

• Organizational process (ORG) – focusing on level – and organization-wide activities

12 © BSI 2012 Version 1.1.0

© BSI 2012 Version 1.1.0 13

the development and maintenance of IT systems and software, to providing an IT-related

• Information Management and Security

14 © BSI 2012 Version 1.1.0

opportunity to drive systematic improvement to achieve better performance with respect

Human Resource Management

© BSI 2012 Version 1.1.0 15

When Human Resource Management is implemented to a satisfactory level the organization

BP.1 Establish Human Resource Policies and Procedures

BP.1 Establish Human Resource Policies and Procedures

16 © BSI 2012 Version 1.1.0

While developing Human Resource Management policies and procedures, consideration

BP.2 Identify the Required Human Resources

BP.3 Satisfy Human Resources Requirements

© BSI 2012 Version 1.1.0 17

If additional resourcing is required, there may be a need to undertake a recruitment

If a redundancy programme is required, applicable legislation must be considered to ensure

BP.4 Allocate Human Resources

18 © BSI 2012 Version 1.1.0

BP.5 Induct Human Resources

Relevant induction activities should be undertaken as early as possible to enable the

Induction records should be securely maintained, and individual feedback gathered to

BP.6 Assess Human Resource Performance

© BSI 2012 Version 1.1.0 19

Assessment criteria pertinent to the organization should be identified and implemented as

Assessment records are mutually agreed and confidentially maintained. Assessment