The Technology Procurement Handbook

i
PRAISE FOR THE TECHNOLOGY

PROCUREMENT HANDBOOK
‘The Technology Procurement Handbook is a useful and practical

guide. Sergii Dovgalenko’s experience of guiding inexperienced team
members and upskilling mature professionals in IT procurement means
I have no hesitation in recommending this book.’
Adil Al Mulla, Vice President, Etihad Aviation Group Procurement & Supply
Management
‘As we become firmly embedded in the Industry 4.0 era, it is good to

see a book that addresses the changing needs of stakeholders and the
refined tools required by procurement professionals to procure and
engage with technology. The Technology Procurement Handbook
provides practical tools for procuring IT and related services as well
as bridging the gap between traditional methods and the additional
considerations and requirements specific to IT.’
Sam Achampong, Head of Chartered Institute of Procurement & Supply (MENA)
‘The Technology Procurement Handbook should be in the library not

only of procurement experts, but also executives whose enterprise
efficiency is affected by procurement. The systematic presentation,
supported by the extensive practical experience of the author, ensures
that the book will become invaluable for procurement specialists.’
Vladimir Kolomoets, Client Partner and Country Manager for Ukraine,
Pedersen & Partners
ii
‘The impact of Technology 4.0 on the procurement profession

should not be underestimated. Practitioners face a rapidly changing
global business environment and are expected to make sound and
justified decisions as they procure technology and develop relation-
ships with technological developers and suppliers, all whilst adding
value and ensuring business success. The Technology Procurement
Handbook captures these key challenges and offers practical advice
on how procurement professionals can address the impact of
Technology 4.0, providing an essential tool for current and future
members of the profession.’
Gary Ramsden, Associate Professor in Logistics and Operations Management,
University of Lincoln
‘What a read! Regardless which corporate function you call home,

this is a must read if you are dealing with technology or procurement
alike. It covers the past, present and future of the craft. It gives a
masterful and in depth structure to everything you need to under-
stand in technology procurement, and provides you with real-life
examples. Required reading for beginners and executives alike.’
Andreas Raubach, former VP Corporate Procurement, Air Berlin
iii
The Technology
Procurement Handbook
A practical guide to digital buying
Sergii Dovgalenko
iv
Publisher’s note
Every possible effort has been made to ensure that the information contained in this book is
accurate at the time of going to press, and the publishers and author cannot accept
responsibility for any errors or omissions, however caused. No responsibility for loss or
damage occasioned to any person acting, or refraining from action, as a result of the material
in this publication can be accepted by the editor, the publisher or the author.
First published in Great Britain and the United States in 2020 by Kogan Page Limited
Apart from any fair dealing for the purposes of research or private study, or criticism or review, as
permitted under the Copyright, Designs and Patents Act 1988, this publication may only be
reproduced, stored or transmitted, in any form or by any means, with the prior permission in
writing of the publishers, or in the case of reprographic reproduction in accordance with the terms
and licences issued by the CLA. Enquiries concerning reproduction outside these terms should be
sent to the publishers at the undermentioned addresses:
2nd Floor, 45 Gee Street 122 W 27th St, 10th Floor 4737/23 Ansari Road
London New York, NY 10001 Daryaganj
EC1V 3RS USA New Delhi 110002
United Kingdom India
www.koganpage.com
Kogan Page books are printed on paper from sustainable forests.
© Sergii Dovgalenko, 2020
The right of Sergii Dovgalenko to be identified as the author of this work has been asserted by him
in accordance with the Copyright, Designs and Patents Act 1988.
ISBNs
Hardback 978 1 78966 212 2

Paperback 978 1 78966 210 8
Ebook 978 1 78966 211 5
British Library Cataloguing-in-Publication Data
A CIP record for this book is available from the British Library.
Library of Congress Cataloging-in-Publication Data

Names: Dovgalenko, Sergii, author.
Title: The technology procurement handbook : a practical guide to digital
buying / Sergii Dovgalenko.
Description: London, United Kingdom ; New York, NY : Kogan Page Limited,
2020. | Includes bibliographical references and index.
Identifiers: LCCN 2019047599 (print) | LCCN 2019047600 (ebook) | ISBN
9781789662122 (hardback) | ISBN 9781789662108 (paperback) | ISBN
9781789662115 (ebook)
Subjects: LCSH: Information technology–Purchasing–Handbooks, manuals,
etc. | Electronic commerce–Handbooks, manuals, etc.
Classification: LCC HC79.I55 D68 2020 (print) | LCC HC79.I55 (ebook) |
DDC 658.7/2–dc23
LC record available at https://lccn.loc.gov/2019047599
LC ebook record available at https://lccn.loc.gov/2019047600
Typeset by Integra Software Services, Pondicherry

Print production managed by Jellyfish
Printed and bound by CPI Group (UK) Ltd, Croydon, CR0 4YY
v
CONTENTS
About the author ix

Acknowledgements xi
List of figures and tables xiii
List of abbreviations xv
Preface xxi
01 Setting the scene for the next-generation technology

procurement 1
Technology is at the heart of Procurement 4.0 2
Evolution of the procurement organizational model 6
Procurement battle plan 9
Changes in technology departments and their perception
of the new procurement 12
References 16
02 Four pillars of technology procurement 19

ITIL service lifecycle 21
Project management lifecycle 23
Strategic procurement process 26
TCO of a technology service 42
Four pillars mapped together: integrated planning
in technology procurement 49
References 52
03 Technology basics for procurement professionals 55

Cloud computing model 56
Software development: build or buy? 71
Software licensing basics 81
Software support and maintenance 92
vi Contents
Summary view of technological options and

associated costs 96
References 96
04 Relationship management in procurement 99

Management of relationships with technology suppliers 99
Stakeholder relationship management 114
Relationship management in negotiations 128
Corporate social responsibility and relationships
with community 132
Conflict resolution 135
References 137
05 Deep dive into the procurement process 139

Step 1: Initiate a sourcing project 139
Step 2: Identify business needs and study the market 139
Step 3: Specify requirements 148
Step 4: Define a sourcing strategy 149
Step 5: Select a supplier and award a contract 151
Step 6: Manage a contract and supplier relationship 192
Step 7: Review results and close 193
Source-to-contract process 193
References 195
06 Practical advice and case studies on technology

procurement 197
SaaS commercial checklist 199
Success factors for technology projects 200
Case studies 205
References 221
07 US legislation and regulation on agile deployment and

contracting and performance-based management 223
Attributes of Agile by GAO 223
Flexibility permitted by the Federal Acquisition
Regulation (FAR) 226
Contents vii
Modular contracting 228
Performance-based management of technology projects 236
References 241
08 Procurement 3.1: Agile, lean, and value delivery today 243

The path to procurement agility 244
Lean management 263
Procurement digitalization 270
Value generation 273
Change management and communication 283
References 287
09 Conclusion 291
References 293
Index 295
viii
THIS PAGE IS INTENTIONALLY LEFT BLANK

ix
ABOUT THE AUTHOR
Sergii Dovgalenko (Fellow and Licensed Tutor of the Chartered

Institute of Procurement and Supply, UK) is the CPO at Ukrainian
Railways, with 22 years of experience in multiple industries and
different geographies. He is particularly interested in technology,
transformation, and cooperative procurement, on which he has
published a number of articles in CIPS Supply Management maga-
zine. Sergii has contributed to some significant global procurement
alliances and transformation projects and was a part of the Middle
East Procurement Team of the Year in 2015 and 2017. With an MSc
in mathematics, Sergii tries to find solid structure and consistent logic
in the ever-transforming role of procurement and further elevate the
value of this fascinating profession.
x

xi
ACKNOWLEDGEMENTS
I would like to send love to my family for being an endless source of

inspiration and support. Their belief in my creative capabilities was
so much stronger than my own. They have always encouraged me to
become what I am and what I will be.
I’m grateful to Etihad Airways for giving me the opportunity to
acquire unique experiences and reference cases I’ve been able to use
in this book to make it so realistic and practical. Despite ongoing
business turbulence, the company has never stopped changing and
innovating and giving me endless chances to absorb new knowledge
and its practical applications.
I thank CIPS for giving me the self-confidence that allowed me to
start even thinking about writing this book and then actually do it
without fear of being labelled a semi-professional. I share their desire
to promote our profession and contribute to that as much as I can –
with this book, in particular.
Finally, thanks to Heyam Al Maskati, head of network strategy in
Bahrain Telecommunications Company (Batelco), and Alexis Indenge,
managing director in Global Broadband Solution SARL, for their
interview contributions in Chapter 1.
xii

xiii
LIST OF FIGURES AND TABLES
Figure 1.1 Industrial revolutions 3

Figure 1.2 Procurement organizational models 7
Figure 1.3 Levels of procurement centralization with maturity 8
Figure 1.4 Procurement battle plan 10
Figure 2.1 Digital transformation 20
Figure 2.2 ITIL Service Lifecycle 22
Figure 2.3 Project management lifecycle 24
Figure 2.4 Category management framework 28
Figure 2.5 Purchasing vs strategic sourcing 33
Figure 2.6 Procurement value levers 35
Figure 2.7 Sample business case with TCO calculations 48
Figure 2.8 Integrated planning in technology procurement 50
Figure 3.1 NIST cloud computing reference architecture 59
Figure 3.2 Types of cloud deployment 61
Figure 3.3 Types of cloud services 63
Figure 3.4 Cloud computing value chain 68
Figure 3.5 Software development lifecycle 73
Figure 3.6 Project management triangle 74
Figure 3.7 Waterfall model 74
Figure 3.8 Incremental model 75
Figure 3.9 Agile delivery model 77
Figure 3.10 Waterfall vs Agile 82
Figure 3.11 Support operational model 93
Figure 3.12 Technology building blocks and associated costs 95
Figure 4.1 Supplier engagement lifecycle 101
Figure 4.2 SRM framework 103
Figure 4.3 Supplier segmentation by tiers 105
Figure 4.4 Supplier preference model 106
Figure 4.5 Example of a RACI matrix for an IT VMO 113
Figure 4.6 Stakeholder map 115
xiv List of figures and tables
Figure 5.1 Step 1: Initiate a sourcing project 140

Figure 5.2 Step 2: Identify business needs and study the
market 148
Figure 5.3 Step 3: Specify requirements 149
Figure 5.4 Step 4: Define a sourcing strategy 150
Figure 5.5 Fit and gap analysis example 152
Figure 5.6 Implementation project workflow 159
Figure 5.7 Step 5: Select a supplier and award a contract 190
Figure 5.8 Graphical presentation of a negotiation plan 191
Figure 5.9 Step 6: Manage a contract and supplier
relationship 192
Figure 5.10 Source-to-contract process 194
Figure 8.1 IT resourcing model 251
Figure 8.2 Product-based operating model of the supplier
account team 253
Figure 8.3 S2P cycle 259
Figure 8.4 Agile operational model 260
Figure 8.5 Typical change management process 284
Table 5.1 Detailed financial breakdown 181

Table 8.1 Sample comparison of licence count vs price list vs
actual billing 275
xv
LIST OF ABBREVIATIONS
3PL Third-Party Logistics

AC Actual Cost
AI Artificial Intelligence
AMO Agile Management Office
APC Actual Percentage Complete
ARB Architectural Review Board
AWS Amazon Web Services
B2B Business-to-Business
BA Business Analyst
BAC Budget at Completion
BAFO Best and Final Offer
BIC Best in Class
BPO Business Process Outsourcing
BRD Business Requirement Document
BU Buying Unit
BYOD Bring Your Own Device
Capex Capital Expenditure
CEO Chief Executive Officer
CIO Chief Information Officer
CIPS Chartered Institute of Procurement and Supply (UK)
CoE Centre of Excellence
COLA Cost of Living Allowance
COTS Commercial Off-the-Shelf Software
CPAF Cost Plus Award Fee
CPI Cost Performance Index or Consumer Price Index
CPIF Cost Plus Incentive Fee
CPO Chief Procurement Officer
CPS Cyber-Physical Systems
CPU Central Processing Unit
CR Change Request
xvi List of abbreviations
CSCT Cloud Solutions Category Team

CSR Corporate Social Responsibility
CUG Closed User Group
CV Cost Variance
DDP Delivery Duty Paid
DIKW Data, Information, Knowledge, Wisdom
DR Data Recovery
EAC Estimate at Completion
EPA US Environmental Protection Agency
EPC Expected Percentage Complete
ERP Enterprise Resource Planning system
EV Earned Value
EVM Earned Value Management
EVMS Earned Value Management System
EXW Ex-Works
FAR Federal Acquisition Regulation
FASA Federal Acquisition Streamlining Act
FFP Firm-Fixed-Price
FM Facility Maintenance
FMCG Fast-Moving Consumer Goods
FPAF Fixed-Price Award Fee
FPEPA Fixed-Price Economic Price Adjustment
FPIF Fixed-Price Incentive Firm
FTE Full-Time Employee
GAO US Government Accountability Office
GDPR General Data Protection Regulation
GRN Goods Receipt Notice
GSA US Government Service Administration
GWAC Government-Wide Acquisition Contract
HHS US Department of Health and Human Services
HLD High-Level Design
HR Human Resources
HUD US Department of Housing and Urban Development
HW Hardware
IaaS Infrastructure as a Service
IBR Integrated Baseline Review
List of abbreviations xvii
IDIQ Indefinite Delivery Indefinite Quality

IFRS International Financial Reporting Standards
IP Intellectual Property
IoT Internet of Things
IS Information System
ISO International Organization for Standardization
IT Information Technology
ITC Information Technology and Computing
ITIL Information Technology Infrastructure Library
ITSM Information Technology Service Management
KPI Key Performance Indicator
L1, L2, L3 Level 1, Level 2, Level 3 of technical support
M2M Machine-to-Machine
M&A Merger and Acquisition
MDM Master Data Management
MOA Manual of Authority
MRP Material Resource Planning system
MVP Minimum Viable Product
NCI Number of Completed Iterrations
NCS Number of Completed Story Points
NIST National Institute of Standards and Technology
NPI Number of Planned Iterations
NPS Number of Planned Story Points
NPV Net Present Value
OEM Original Equipment Manufacturer
OMB Office of Management and Budget
Opex Operating Expenditure
OSS Operation Support System
P2P Procure-to-Pay
P&L Profit and Loss
P-card Procurement Card
PaaS Platform as a Service
PDCA Plan, Do, Check, Act
PID Project Initiation Document
PM Project Manager
PMB Project Management Baseline
xviii List of abbreviations
PMBOK Project Management Body of Knowledge

PMI Project Management Institute
PMO Project Management Office
PMP Project Management Plan
PO Purchase Order
POC Proof of Concept
PR Purchase Requisition
PSL Preferred Supplier List
PSM Procurement and Supply Management
PSS Passenger Service System
PV Planned Value
PWS Performance Work Statement
QA Quality Assurance
R2P Requisition-to-Pay
RACI Responsible, Accountable, Consulted, Informed
RFI Request for Information
RFP Request for Proposal
RFQ Request for Quotation
RFx RFI, RFP or RFQ
ROI Return on Investment
S2C Source-to-Contract
S2P Source-to-Pay
S&OP Sales and Operation Planning
SA Service Architect
SaaS Software as a Service
SAM Software Asset Management
SDLC Software Development Lifecycle
SDP Service Design Package
SEWP Solutions for Enterprise-Wide Procurement
SKMS Service Knowledge Management System
SKU Stock-Keeping Unit
SLA Service Level Agreement
SLP Service Level Package
SMB Small and Medium Business
SME Subject Matter Expert
SOO Statement of Objectives
List of abbreviations xix
SOP Standard Operating Practice

SOW Scope of Work
SPI Schedule Performance Index
SRM Supplier Relationship Management
SRO Senior Requirement Owner
SRS Software Requirement Specification
SV Schedule Variance
T&I Technology and Innovation
T&M Time-and-Material
TCO Total Cost of Ownership
TNA Training Needs Analysis
TOM Target Operating Model
TOR Terms of Reference
TPB Total Planned Budget
UAT User Acceptance Testing
ULA Unlimited License Agreement
USG US Government
VAC Variance at Completion
vCPU Virtual Central Processing Unit
VM Virtual Machine
VMI Vendor-Managed Inventory
VMO Vendor Management Office
VOIP Voice Over Internet Protocol
VP Vice President
WBS Work Breakdown Structure
XaaS Anything-as-a-Service
XML eXtensive Markup Language
YoY Year on Year
xx

xxi
PREFACE
Why would we dedicate the entire book to technology procurement?

Not only because it is exciting, challenging and futuristic. Leading
industry experts believe that by 2021, indirect spend will be managed
by technology procurement leaders in 60 per cent of large enterprises
(Pettey, 2018). The reason for this is the continuing increase in tech-
nology spending by non-IT business units due to the accelerating
digital transformation of many industries. From this perspective, our
book effectively becomes the guide for indirect procurement leaders
of the future.
In modern times, the purpose of procurement is not questioned
anymore. The dilemma instead is, ‘does the company need procure-
ment skills or a procurement organization?’ Some mature companies
have evolved their procurement into a fully centralized model and are
now looking into returning some categories to the business or
outsourcing them. Whichever path is chosen, procurement skills will
always be required to manage core categories, deliver value and
support the competitiveness and agility of the company. These skills
are not necessarily contained within the walls of the procurement
department – Business, IT, and Finance experts can contribute to
cross-functional sourcing teams or even run some categories under a
centrally led operational model. Low-end transactional tasks can be
automated or outsourced, leaving us more time to deliver value,
strengthen relationships, and innovate.
Besides business transformation, companies are undergoing ‘auto-
mation’, ‘digital transformation’, ‘cloudization’, etc. The hunger for
new technologies is not only in IT – it’s growing throughout the busi-
ness. Non-IT end users have started accumulating and operating
technology budgets and playing a pivotal role in the procurement
process, if not taking it over. They then discover that their impressive
negotiation skills are necessary, but not sufficient, because 99 per cent
xxii PREFACE
of procurement’s job is accomplished before or after negotiations. In

this book, we will uncover what lies beneath the surface of tradi-
tional price debates – technical complexities, costing assumptions,
licensing ambiguities, project management dependencies – and how
to prepare and equip yourself to eventually leave a negotiation table
aut cum scuto (‘on the shield’).
For a broad audience of young and mature specialists from different
industries and backgrounds, this book provides a practical approach
to technology procurement, by applying skills and techniques that
differentiate true professionals from hagglers.
We will map procurement and cost artefacts to the ITIL Service
Lifecycle and project management process, navigate through the
complexities of cloud deployment and services, prepare a robust nego-
tiation plan based on the full assortment of value levers, select an
appropriate contract model and terms, and support all of that with
practical advice and extensive real-life examples. We have developed
some custom tools not available from any other source – checklists,
schemes, workflows and other useful visuals – which you can put in
practice straight away.
We have worked extensively on studying the experience of state
procurement, regulators and auditors, because governments are the
biggest spenders of IT budgets. They are also subjected to public scrutiny
and mandated to transparency, hence the volume of useful information
on technology procurement from open government sources is
overwhelming.
We also intended to demystify modern procurement buzzwords –
‘agile’, ‘lean’, ‘value’, ‘demand’ and ‘digitalization’ – by making simple
definitions and providing real-life examples and practical advice for
how to head towards Procurement 4.0. As much as we respect analysts
and advisors, we have tried not to step in their playground of broad
terms and generalized prescriptions, and have remained simple and
practical.
This book is not for geeks; it’s for practitioners, no matter where
they sit – Procurement, IT, Finance or Business. It will organize multi-
ple arrays of information that you already have in your possession but
just haven’t had time to inventory, analyse, and implement consistently.
PREFACE xxiii
It is made to provide a concise, memorable and practical guide for a

community of stakeholders in technology procurement, setting them-
selves up for a future leading role across all indirect categories.
Reference
Pettey, C (2018) Top trends for the future of IT Procurement, Smarter with
Gartner [online] https://www.gartner.com/smarterwithgartner/top-trends-for-
the-future-of-it-procurement/ (archived at https://perma.cc/HJ7N-LSU9)
[accessed 12 May 2019]
xxiv

1
01
Setting the scene for

the next-generation technology
procurement
Before we dive into theories, let’s analyse the external and internal
factors that are shaping our profession.
On the macro level, the new industrial revolution is driving funda-
mental changes in business that directly affect procurement. The
factory model adopted in the early 2000s and characterized by
consolidation, compliance and process efficiency is expected to evolve
further towards delivering value, quality or competitive advantage.
At the same time, the unprecedented pace of technology development
is eliminating human labour or pushing it offshore. The boundaries
between functions are eroding, making business logic prevail over
processes and innovation, driving top-line growth.
Inside the company, similar shifts affect every internal stakeholder,
and all of them must reassess their role in the company, reprioritize
tasks, and change their perceptions of what procurement is expected
to deliver for them – the commercial and operational advice, data-
driven business intelligence, change management, innovation
enablement, and new value streams.
Technology procurement has been through critical changes as well.
Now we must source value-generating services, which means that old
commodity-based concepts are no longer applicable. The five tradi-
tional procurement ‘rights’ (goods or services, quality, place, time,
2 THE TECHNOLOGY PROCUREMENT HANDBOOK
price) have increased by at least three – from the right source, for the
right customer, with the right technology. We are responsible for the
value chain that goes all the way to our consumers.
Adopting these changes is a matter of survival for the procurement
profession. If it is not going to deliver the value, mitigate risks and
nurture relationships, then it’s likely to be ground by the millstones
of automation, outsourcing, and offshoring, as business becomes
increasingly demanding and far less forgiving.
Technology is at the heart of Procurement 4.0

Some people tend to perceive global changes as divine acts, which are
hard to predict and impossible to manage. However, even these
macro-economic and geopolitical shifts have the logic and follow
certain patterns. More than 30 years ago, the famous futurist John
Naisbitt introduced the term ‘megatrends’ and urged, ‘Without an
appreciation of the larger shifts that are restructuring our society, we
act on assumptions that are out of date. Out of touch with the present,
we are doomed to fail in the unfolding future’ (Naisbitt, 1982).
Everyone knows about the increasing world population and
climate change, but the list of current megatrends is slightly more
extensive:
●●
rapid urbanization;
●●
climate change and resource scarcity;
●●
shift in global economic power;
●●
demographic and social change;
●●
technological breakthroughs (Modly, 2016).
Each of these megatrends alone and all of them collectively have a

huge impact on any business. For example, changing demographics
have introduced ‘generation Y’, which will reach 2.5 billion in number
by 2020 – working remotely or part-time, less inclined to social insti-
tutions, settlements and borrowing, technology savvy and increasingly
influenced by the internet. This dominant consumer power needs
SETTING THE SCENE 3
tailored products and services, different standards of customer

service, digital sales channels, etc. New industries are being created –
fintech, electric car building, sustainable power, and bio-fuel. As the
global population ages, the cost structure in the medical industry is
shifting from treatment to early diagnosis and prevention.
Furthermore, technological breakthroughs have triggered the new
industrial revolution, Industry 4.0, which is characterized by cyber-
physical systems (CPS) – integrations of computation, networking
and physical processes – freely exchanging data and taking autono-
mous decisions.
Industry 4.0 could be explained by the 1965 prediction by Gordon
Moore (Moore’s Law) that the number of transistors per silicon chip
doubles every year. Now the same applies to the processing power of
computers, which grows exponentially and drives the unprecedented
emergence of disruptive technologies. Due to this exponential growth,
Industry 5.0 – a collaboration between human and machine or
Artificial Intelligence – is already on the horizon.
It is relatively easy to understand the giant leap between the first
and second industrial revolutions with the development of mass
production and the growth of capitalism. The difference between
third and fourth revolutions is not that noticeable, as both are based
on computers and automation. We can suggest a simple example of
the internet refrigerator, which was introduced in 1999, and offered
FIGURE 1.1 Industrial revolutions
Industry 1.0 Industry 2.0 Industry 3.0 Industry 4.0

Mechanization, steam Mass production and Electronic and IT Cyber physical
and water power electricity systems, automation systems
SOURCE Shutterstock
web access, emails, online ordering, and a few more simple tricks
(Electrolux, 1999). But only in 2018 did Amazon Dash Replenishment
provide the technology for refrigerators to reorder water and air
filters without any human intervention (Kenmore, 2018).
On a personal level, CPS bring us smart homes and assisted living,
smart mobility applications and other instances of human–machine
interfaces. It will further automate and integrate supply chains, eg
incoming logistics, where an automated fulfilment ensures a sufficient
inflow of production materials and precursors. The optimum order
quantity is automatically calculated with real-time data from produc-
tion, warehousing, and incoming orders. Market trends, price
developments and other company external data can be integrated to
improve the forecasting quality and risk management. With strategic
suppliers and subcontractors, an integrated supply chain can be estab-
lished based on CPS, so interwoven production processes from several
companies can be linked virtually to a strategic production network
(Oks, Fritzsche and Moeslein, 2018). This resonates with the CIPS vision
of the future, where smaller companies will form common ecosystems
(networks,) and procurement professionals will elaborate on network
coordination and strategizing (Alder, Knight and Meehan, 2018).
Naturally, Industry 4.0 requires a new procurement. The factors
driving the change are the hyper-competition, globalization, supply
chain risks, resource scarcity and many more. But the most important
one is the technology – big data, digital processes, and automation.
Data integration will improve supply chain visibility and relation-
ship management. Analytics will enable a better understanding of
suppliers and markets, prediction of trends, and analysis of failures.
Digital processes and tools will free up highly qualified resources to
deliver value to the business.
As expected, the new digital and data-enabled procurement has
been given a release 4.0. Its framework includes six main themes:
●●
procurement as a service provider to internal stakeholders and a
profit centre;
●●
digital category expertise;
●●
digital supply chain management and SRM;
SETTING THE SCENE 5
●●
data-enabled procurement strategy, operations and performance;
●●
digital processes and tools;
●●
skills and capabilities 4.0 (Geissbauer, Weissbarth and Wetzstein,
2016).
Not rocket science, huh? In the second decade of the 21st century,
most of these attributes come by default. Aren’t we the digital cate-
gory experts already? Haven’t we automated our source-to-pay (S2P)
cycle? However, there’s still a long way to go from our current release
3.x to full-fledged 4.0.
Let’s analyse what is required from the procurement of today to
upgrade to 4.0. Being a service provider and a profit centre simply
means delivering more value to the business; stop being compliance
watchdogs and start protecting and enhancing the revenue flow. With
a service provider mindset, commit to treating customers – internal
and external – well and improving service standards.
Data-enabled procurement reflects the essence of Industry 4.0.
Computers became connected, and their data represents the priceless
raw material that needs to be processed, ordered and consumed.
Once we become the masters of our data, we will boost our value to
the company immensely. In this respect, we may recall a nice little
DIKW model (Henry, 1974). It explains the evolutionary path from
Data to Information, then to Knowledge, and finally to Wisdom.
Data is an unstructured collection of facts and figures. To become the
information, it needs to be arranged and ordered. Fragments of infor-
mation interconnected by logical relations become the knowledge,
which needs to be applied in practice to obtain an expected result to
become the wisdom. Our current state of procurement data mastery
hardly reaches the knowledge level, while to make it to the Industry
4.0 we will have to achieve wisdom.
Digital category expertise and new skills and capabilities come
together quite naturally. We will need to become familiar with cloud
computing, Big Data, finance models, project management, risk miti-
gation, even psychology to be able to manage our stakeholders and
suppliers. Knowledge of the procurement manual and an ability to
raise a PO are no longer sufficient even for a junior role.
At last, digital supply chain management will unite the clusters of

procurement and SCM/logistics/material management that are still
disconnected in some companies. Essentially, we are all links to one
network, which is now visible and manageable thanks to the internet
and data technologies.
If procurement adopts the fruits of the fourth industrial revolu-
tion, analysts promise a substantial increase in value delivery,
meaningful resource utilization, respect and recognition across the
business: ‘platinum’ SLAs. Technology gives us the vehicle to reach
this utopian future, but first we need to master our driving skills,
which is why this book has been created!
Evolution of the procurement organizational model

Inter alia, the evolution of procurement reflects upon its organiza-
tional models.
In recent decades, there has been a trend to centralize purchasing
powers under one roof, so one set of governance rules applied, generic
category management approach employed, and maverick expense
minimized. Still, the resistance of subject matter experts to surrender-
ing their spend to procurement was always there, as product,
commercial and engineering managers possessed unique competen-
cies, reacted faster to market changes and had close ties with strategic
suppliers. Accordingly, companies were shaping up their organiza-
tional models to marry procurement with multiple stakeholders.
Industry experts observed how the level of procurement centrali-
zation was associated with the organizational maturity of the
company, as such (Kochersperger et al, 2017b).
At first, procurement resources are centralized into the nascent

procurement function. From there, successive steps need to be taken
to increase the value delivered and to help the function mature. As the
procurement function makes its way up the maturity curve, it engages
in more advanced, sophisticated and cross-functional activities, while
its ROI increases. In the ultimate stages, once procurement is truly
embedded in the organization’s culture, resources and processes are
SETTING THE SCENE 7
FIGURE 1.2 Procurement organizational models

CENTRALIZED MODEL MATRIX MODEL
BU1 BU2 Group BU1 BU2 Group

CPO CPO
BU1 BU2
CPO CPO
Buyers Buyers Buyers Buyers
• Buyers report to group procurement dept, • All buyers report to group, which
which makes decisions over all co-arbitrates with BUs
procurement strategy • Some buyers are hosted by BUs; some
are transversal
COORDINATED MODEL DECENTRALIZED MODEL
BU1 BU2 Group BU1 BU2

CPO
BU1 BU2 BU1 BU2

CPO CPO CPO CPO
Buyers Buyers Buyers Buyers
• Buyers report into BU procurement • Buyers report to BUs

structures (no group procurement dept)
• Group procurement provides • Coordinated initiatives may exist between
coordination, guidance the BUs
SOURCE Reproduced with permission of Oliver Wyman (Kochersperger et al, 2017b)
once more disseminated into the business so they may lie closer to
the pulse of the organization. Procurement, then, is still embodied by
a function – but has transformed into a truly cross-functional system
involved upstream in key strategic decisions, allowing it to realize
significant savings and generate sustainable value. (Kochersperger
et al, 2017a)
FIGURE 1.3 Levels of procurement centralization with maturity
Level of procurement
centralization
Greenfield Developed Mature

Organizational maturity
SOURCE Reproduced with permission of Oliver Wyman (Kochersperger et al, 2017b)
Mature organizations evolved their procurement models to become

matrix or coordinated ones. Most of the market leaders established
global shared service centres, some of them organized global hubs in the
form of procurement companies operating as per the ‘buy–sell’ model.
For our topic, this means that some categories where centralization
makes sense (ie web development or global connectivity) stay with
procurement, while other uncommon ones (eg marketing monitoring
tools or domestic IT infrastructure and operations) attach to the busi-
ness or local subsidiaries. There may be multiple further options of
divesting procurement of certain (sub) categories or job roles. For
example, the category management could be separated from sourc-
ing, and the actual execution of category strategies – the field
work – could be assigned to local companies. SRM quite frequently
stays with the business or IT, as they maintain closer operational rela-
tionships with vendors. Requisition-to-pay jobs are extensively
automated or outsourced to third parties. Lastly, procurement compa-
nies could absorb the full cycle of procure-to-pay activities.
The retained procurement organization is likely to sustain the
centre of excellence for strategy, policies, systems, and competence. It
could still be sourcing strategic commodities (keep this in mind until
the next section). There is likely to be a dotted-line reporting of
business-driven categories into the centre of excellence, while support
functions (eg contract administration, source-to-pay) will be shared
across all categories.
SETTING THE SCENE 9
With this approach, IT departments, business units, local operat-

ing companies or shared service centres may find themselves managing
pockets of the technology spend. Once that stage is reached, the busi-
ness starts looking at procurement differently – it’s no longer a
showstopper but a peer. Furthermore, procurement responsibilities
become those of the business.
The changing organizational model is not a panacea for every
company, but an option to attach procurement to the business and
subordinate it to the overarching task of the value delivery.
Procurement battle plan

To those who fear decentralization (ie the return of procurement cate-
gories and jobs to the business), the next section is going to be even
scarier. Procurement outsourcing began as low-end transactional
tasks, but now is growing by 12 per cent year on year, covering nearly
every aspect of operations (Everest Group, 2018). Technology further
enhances this trend by automating non-value-adding activities. Lower-
cost and higher-efficiency labour from one side and digital procurement
tools from the other side are eating up our traditional zones of comfort.
The cream of the cream of procurement activities is what we earlier
called the centre of excellence. It deals with strategy and planning,
policies and procedures, business intelligence, scorecards, automation
and process improvement, personnel competencies, functional budget,
and communications. If you are working there, then you can live a
worry-free life until AI becomes sufficiently humanized.
Contract-to-pay roles (contract administration, requisition-to-
pay) and MDM (Master Data Management) have already become
increasingly outsourced or offshored.
For those who are working in the source-to-contract domain (stra-
tegic sourcing, spend analysis and SRM), the only ‘outsource-free’
haven is the core spend. Now you may recall the earlier notion of the
‘strategic commodities’. Core or strategic spend can be recognized by
any of the following attributes:
●●
key ingredients to final products/services (eg rubber sourcing by
Bridgestone);
●●
source of competitive advantage (eg design and development of
Apple products);
●●
critical quality enabler (eg yeast for brewing companies);
●●
distinct source of value generation (eg airport charges for airlines,
as this category involves a variety of incentives, discounts, lobbying
opportunities, government stimulus to travel industry, co-marketing
etc – all of these generate revenue, develop the brand, promote the
country, ie enable full-fledged value delivery).
Figure 1.4 shows what we called the ‘procurement battle plan’. Three
horsemen of Apocalypse – decentralization, automation and outsourc-
ing – entered the realms of procurement and conquered the transactional
and presentational layer. They are further aiming at category manage-
ment, reporting and operational SRM; the closer you are to the centre,
the safer your job is.
FIGURE 1.4 Procurement battle plan
tion
to ma Pr
Au es
en
ta
Reporting tio
n
Spend
analysis
acti ctional
s
Business
vitie
sa
intelligence
Tran
An
aly
tic
s
Cat mgm
CoE
M
SR
t
revi ance
Core Supplier
categories innovation
ews
Value Strategic
orm
Generic categories suppliers

Ou
Operational
Perf
categories
tso
SRM
ur
cin
g
n
alizatio
Decentr
SETTING THE SCENE 11
The good news is that technology procurement ticks nearly every box
as a core category if the professionals running it would let go of the
‘IT commodity’ mindset. Keep on buying hardware and software at
the lowest price and watch yourself become outsourced. Think about
value-generating services, supplier innovation, business resilience
and time-to-market – and live a happy life in the unicorn strategic
category.
There is, however, a more radical view of the procurement operat-
ing model in 2025. The world-leading ERP provider SAP divides it
into three layers:
●●
Corporate procurement will manage risk, sustainability and brand,
value management and reporting, strategic partner development,
and supplier performance management.
●●
Business unit procurement, implanted or connected via business
partners, will manage categories, operational SRM, contract,
innovation, and sourcing.
●●
Expectedly, highly automated shared service centres will cover
transactional activities, MDM, analytics, and support (Vollmer,
Brimm and Eberhard, 2018).
This scenario is a harsher realization of tendencies we discussed

before – complete de-centralization of category management and
sourcing (with no remorse for the core spend) and automation of
transactional activities. Interestingly, SAP dropped spend analysis to
the bottom of the food chain, while Everest Group positions it along-
side category management.
If this prediction comes true, what options does it leave us? Still, it
makes sense to develop the skills and knowledge suggested in this
book – simply because value generation, risk mitigation and perfor-
mance management require a deep and comprehensive understanding
of underlying elements of technology procurement. You might have
been doing less field work, but the corporate procurement cannot be
category-agnostic. You will have to speak the language of your busi-
ness and suppliers – the language of technology, value and
performance.
Changes in technology departments and their perception

of the new procurement
So, we have looked outside our companies on industrial, technologi-
cal, and operational trends. Then we entered the inner space to look
at ourselves and analyse the changes to procurement operational
models. Now let’s see what happens inside our fellow IT departments
(who have rebranded themselves as Technology and Innovation for
the reasons we will now explain).
Since technology is the backbone of most business functions, its
strategy is expected to align with that of the business. Technology
investments need to fulfill business goals, new services must provide
value to end clients, and resilience should be dictated not by internal
IT standards but by the importance of revenue generation.
Furthermore, there has been a fundamental shift in operating models
and cost structures. Technology jobs are extensively outsourced or
offshored. Back-end systems and infrastructure are moving to the cloud
and freeing up capital expenditures, for change and innovation. In
general, technology money flows into three main buckets – business
operation support, process change, and innovation. Every dollar is dedi-
cated either to protecting existing revenue or to contributing to the top
or bottom line (new income or savings).
Overall, our colleagues going through a similar transformation as
procurement – their strategy subordinated to the business, their work
measured by the effect on P&L – need to fight ‘shadow IT’ (unau-
thorized implementation of technology by end users), and have to
develop internal financial capabilities to plan, allocate, and analyse
the efficiency of investments.
Their legacy operating model demonstrated the following attributes:
●●
system operations-centric with processes based on ITIL;
●●
based on an internal IT function with outsourced execution
capabilities; geographically optimized data centres provide service
per region;
●●
favours a consistent code change rate and code deployments;
●●
provides risk-free continuation of services under rigid change
control;
●●
no internal development resources (all outsourced);
●●
applications are minor, and major releases managed and not code-
enhanced by internal development teams;
●●
operations teams are not integrated with application developers;
●●
system and operations processes standardized across the
organization;
●●
hybrid cloud services supported with limited on-premises automa
tion and no cloud orchestration or management platforms;
●●
Information Technology Service Management (ITSM), operations
execution, workplace services partly or fully outsourced;
●●
no transparent chargeback mechanism is available, therefore IT
cannot allocate costs back to business units for existing or addit
ional IT services;
●●
SLA performance managed per system without a holistic view of
the overall performance; therefore, no OSS dashboard with a
common view of all systems/services covering availability, perfor
mance, cost, etc;
●●
limited self-service, predictive and cognitive capabilities result in
resource-intensive process and support execution.
This model needs to transform into the new Target Operating Model
(TOM):
●●
from IT focused to business-centric;
●●
from ITIL focused to a combination of Agile and ITIL to support
bimodal IT;
●●
from ‘client vs supplier’ model to ‘collaborative one team’;
●●
joint responsibility, clear accountability and decision making;
improved customer alignment and focus;
●●
based on a combination of distributed and self-organized squads;
●●
data and insights driven supported by tools;
●●
increasingly automated;
●●
from process based to outcome based;
●●
from reactive to proactive support;
●●
technology driven with highly skilled personnel; infusion of new skills;
●●
culture of continuous improvement;
●●
bimodal IT delivery – focused on stability and agility;
●●
agile and flexible account team aligned to the new TOM with a
focus on continuous improvement and innovation;
●●
agile governance that is metric driven.
Bimodal IT is the practice of managing two separate but coherent

styles of work: one focused on predictability, the other on explora-
tion. Mode 1 is optimized for traditional areas (eg IT infrastructure
operations). It assumes gradually renovating the legacy environment
into a state that is fit for a digital world. Mode 2 is exploratory to
solve new problems with innovation. These initiatives often begin
with a hypothesis that is tested and adapted in an agile manner – by
short iterations leading to the minimum viable product (MVP).
Carefully blending a more predictable evolution of products and
technologies (Mode 1) with the new and innovative (Mode 2) is the
essence of an enterprise’s bimodal capability. Both play an essential
role in the digital transformation (Altimetrik, 2016).
In this manner, IT becomes T&I (Technology and Innovation), as
they are both adopting commercial technologies to gradually build
up their infrastructure, networks and legacy systems, and innovating
to create bespoke solutions fit for the specific business requirements
of their companies.
INTERVIEWS
Opinion 1: Heyam Al Maskati, head of network strategy at Bahrain
Telecommunications Company
The procurement function in the telecom industry is a strategic

differentiator. Telco is always competing in an increasingly fast-paced,
complex economy. To stay competitive, they need to identify and source
external resources quickly and efficiently. The effective procurement
function must be able to fully understand and actively participate in the
complete product development cycle. To achieve that, procurement needs
to demonstrate the right skills to complement those of their colleagues
and stakeholders from other business functions. Besides the usual sense of
direction and purpose, procurement must show the managerial talent and
specialist skills required to ensure the company can navigate through the
fast-changing, complex telecom sector.
An excellent way to start is by asking business leaders what capabilities
they believe the procurement team should bring to the table:
The right mix, so strong negotiators well suited to winning keen prices
team up with adepts of building long-term, mutually rewarding
relationships with strategic suppliers and internal stakeholders.
Real credibility by understanding industry and supplier specifics and
implementing sophisticated cost and performance metrics, instead
of an average cost per user or gigabyte.
Savings to the bottom line that are reflected in the company’s
financial statement and not just reinvested indiscriminately.
Alignment with project managers by developing a sourcing
strategy and preparing tender documentation based on the best
practice of contractor management, service delivery and
customer service. Procurement must have procedures for risk
mitigation, problem response and change management.
Opinion 2: Alexis Indenge, managing director at Global Broadband

Solution SARL
Procurement and CIO relations have transformed due to the evolution of

products and services in the industry. The procurement process used to be
primarily cost based (the lowest bid), but now it has evolved towards TCO
and ROI management.
The disruption has impacted the IT technology products offering – IT-as-
a-Service, IoT, digital transformation. Consequently, the procurement
function must understand the CIO’s technology and business evolution.
There is therefore also disruption to the collaboration between the CIO
and Procurement. The CIO is no longer a technology-driven head, but
rather a business-driven executive who uses technology to enhance and
support the company performance.
Procurement must be involved at the very early stage of the CIO’s
strategy definition. They need to become more strategic, collaborative and
technology proficient to help improve efficiency and become a trusted
partner to the CIO and a contributor to the bottom line.
Based on the above, we can make a few essential observations to

further elaborate on in this book. Our industries, functions, and roles
transform at the speed of light. We need to develop new skills, tools,
and relationships to embrace the change. CIOs are no longer driven
by technology; they are business executives. Procurement needs to
abandon the ‘lowest bid’ game – now it’s about TCO, ROI, and
contribution to the bottom line.
Buzzwords like ‘paradigm shift’, ‘disruption’ and ‘megatrend’ are
actually happening to us. Procurement must deliver the new value
proposition to become fit for Industry 4.0. IT must transform into
T&I to carefully strengthen its base and innovate to pave the way for
the company towards the digital future. Both functions need to
subordinate ambitions and interests to those of the business and
customers and no longer build for the sake of capital plans or delay
the process to exercise controls.
We will have to rebuild our operational models to be able to
support the new business offering – predictive marketing, personal-
ized, made-to-order products and everything-as-a-service. Rigid
capex models, outdated governance frameworks and planned
commodity economy have to give way to agile development, procure-
ment, resourcing and budgeting.
Please return to this chapter once you have reached the end of the
book, and you will see how consistently we are trying to find logical
and practical ways to integrate ourselves into Industry 4.0.
References
Alder, H, Knight, L and Meehan, J (2018) The future of procurement and supply
management, CIPS [online] https://www.cips.org/en-me/knowledge/procurement-
topics-and-skills/innovation-and-technology-/future-of-procurement--supply-chain/
(archived at https://perma.cc/TZJ4-WXMC) [accessed 12 May 2019]
Altimetrik (2016) Achieving enterprise agility with bimodal transformation [online]
https://www.gartner.com/imagesrv/media-products/pdf/ALTIMETRIK/
Altimetrik-1-354WZ5A.pdf (archived at https://perma.cc/HN8W-RE9Q)
Electrolux (1999) A refrigerator that ‘thinks’ – intelligent refrigerator will simplify

homes, Electrolux, 13 March [online] https://www.electroluxgroup.com/
en/a-refrigerator-that-thinks-intelligent-refrigerator-will-simplify-homes-4349/
(archived at https://perma.cc/M2WF-GVDQ) [accessed 12 May 2019]
Everest Group (2018) Procurement Outsourcing (PO) BPO – Service Provider
Landscape with Services PeakTM Matrix Assessment 2018 [online] https://
www2.everestgrp.com/Files/previews/Everest%20Group%20-%20PO%20
Service%20Provider%20Landscape%20with%20Services%20PEAK%20
Matrix%E2%84%A2%20Assessment%202018%20-%20CA.pdf
(archived at https://perma.cc/P6R7-FY5J) [accessed 12 May 2019]
Geissbauer, R, Weissbarth, R and Wetzstein, J (2016) Procurement 4.0: are you
ready for the digital revolution? Strategy&, 4 May [online] https://www.
strategyand.pwc.com/report/procurement-4-digital-revolution (archived at
https://perma.cc/HW4D-HVND) [accessed 12 May 2019]
Henry, N L (1974) Knowledge management: a new concern for public
administration, Public Administration Review, 34 (3), May [online] https://
www.researchgate.net/publication/271814301_Knowledge_Management_A_
New_Concern_for_Public_Administration (archived at https://perma.cc/
YGC7-FRYD) [accessed 12 May 2019]
Kenmore (2018) The Kenmore brand integrates Amazon Dash Replenishment into
smart refrigerators to simplify kitchen maintenance, PRNewswire, 1 November
[online] https://www.prnewswire.com/news-releases/the-kenmore-brand-
integrates-amazon-dash-replenishment-into-smart-refrigerators-to-simplify-
kitchen-maintenance-300741829.html (archived at https://perma.cc/
LKA6-MH28) [Accessed 12 May 2019]
Kochersperger, G et al (2017a) Strategic collaboration in procurement, Oliver
Wyman [online] https://www.oliverwyman.com/content/dam/oliver-wyman/
v2/publications/2017/mar/strategic-collaboration-in-procurement-final2.pdf
(archived at https://perma.cc/8B3R-R6BM) [accessed 12 May 2019]
Kochersperger, G et al (2017b) Designing the perfect procurement operating model,
Oliver Wyman [online] https://www.oliverwyman.com/content/dam/oliver-
wyman/v2/publications/2017/mar/designing-the-perfect-procurement-model-
final2.pdf (archived at https://perma.cc/6A24-6RPB) [accessed 12 May 2019]
Modly, T (2016) Five megatrends and their implications for global defense
& security, PWC [online] https://www.pwc.com/gx/en/government-public-services/
assets/five-megatrends-implications.pdf (archived at https://perma.cc/ASB6-
4XHR) [accessed 12 May 2019]
Naisbitt, J (1982) Megatrends, Warner Books, New York
Oks, S J, Fritzsche, A and Moeslein, K (2018) Industrial cyber-physical systems

from a stakeholder perspective, Conference paper [online] https://www.
researchgate.net/publication/326464540_Industrial_cyber-physical_systems_
from_a_stakeholder_perspective (archived at https://perma.cc/AG97-EC3M)
Vollmer, M, Brimm, R and Eberhard, M (2018) Procurement 2025, SAP,
January [online] a https://www.ariba.com/-/media/aribacom/assets/pdf-assets/
procurement-2025.pdf (archived at https://perma.cc/J6V6-C2FG) [Accessed 12
May 2019]
19
02
Four pillars of technology

procurement
We are about to discover what people used to call ‘IT procurement’.

This category (a grouping of similar goods and services with univer-
sal demand and supply characteristics and a supplier base) dealt with
the following commodities (products with standard traits):
●●
software applications and operating systems;
●●
web-based internet and intranet information and applications;
●●
telecommunication products and services;
●●
multimedia products and services;
●●
computers and peripherals;
●●
end-user devices (phones and tablets).
Common terms for all the above were ‘hardware’, ‘software’, and
‘services’.
In the last two decades, information technology has been wholly
transformed, which we can see in every aspect of our lives through
mobility, networking, automation, etc.
Behind these unprecedented user experiences, there is a whole new
universe of products and services, including:
●●
cloud computing;
●●
software-defined infrastructure;
●●
Big Data;
FIGURE 2.1 Digital transformation
DIGITAL TRANSFORMATION
TECHNOLOGY COMMUNICATION DATA IOT AUTOMATION NETWORKING
SOURCE Shutterstock
●●
5G technology;
●●
open source networks;
●●
digital customer channels.
Technological changes are enormous. In 1998, the first Software-as-

a-Service (SaaS) company Concur went public. In 2018, 80 per cent
of software applications in the world were sold over the internet, and
the SaaS market exceeded US $72 billion annually (Gartner, 2018).
Open standards increasingly define today’s networks. Customers are
not attached to locations, providers or vendors; Industry 4.0 is
entirely data driven.
In technology procurement, we are no longer talking about
commodities that one buys, employing a routine process day in, day
out. We are sourcing prepackaged services or developing custom ones
to meet the specific business requirements in given market conditions.
Now our spend flows into cloud services, data transport, IT outsourc-
ing and consulting, software applications and IT security.
Digital technology powering products and services does not imply
ownership by the IT department. Therefore, it is getting increasingly
difficult to define the boundaries of IT procurement. Effectively, most
of the indirect categories have an IT element to them, and the same
applies to IT procurement competencies, which don’t belong to a
single category team.
For example, when a company wants to automate back-office
processes to optimize the headcount and improve the quality of inter-
nal services, they need to know what specific transactions to address,
what technologies to use and how to integrate them into the existing
FOUR PILLARS OF TECHNOLOGY PROCUREMENT 21
IT environment, what budget to provision, and much more. Then the

need arises for the collective brain of multiple stakeholders. Usually,
Procurement, Business (requestors), IT (execution) and Finance
(control) will form a cross-functional team to review demand, trans-
late it into technical terms, evaluate the deployment and integration,
define success criteria, assess a budget, and study a supply market.
This team will decide on issuing a request for proposal (RFP), or
approaching a specific vendor, or outsourcing an end-to-end process
to a specialist provider, or even scrapping a sourcing request because
there’s no budget, it’s not the right time, there’s not a compelling busi-
ness case or some other reason.
Technology procurement becomes a team effort. It is a blend of
business analysis, IT solution design, financial modelling, business
planning, project management, and strategic sourcing – ie much more
than good old IT procurement.
To create order from the chaos of technical complexities and cross-
functional inter-dependencies, we must try to anchor to a solid
foundation. For that, we suggest employing what we called the four
pillars of technology procurement:
●●
ITIL service lifecycle;
●●
project management lifecycle;
●●
strategic procurement process;
●●
TCO (total cost of ownership).
These pillars effectively represent all key stakeholders and allow us to

look at technology procurement from different, yet collaborative
perspectives.
ITIL service lifecycle

Cloud computing and the consumerization of IT are accelerating the
transformation of the enterprise IT from the capital investor and
operator of technology into the internal provider of services to the
business. The role of IT is transforming from building applications
and operating infrastructure towards delivering value-generating

services to the business while ensuring requisite service levels.
Therefore, service management is crucial to establishing the logic,
consistency and governance of the service delivery process. ITIL
(Information Technology Infrastructure Library) contains the stand-
ardized best-practice framework of selection, planning, delivery, and
maintenance of IT services. This framework is called the ITIL Service
Lifecycle and consists of five stages: Service Design, Service Strategy,
Service Transition, Service Operation, and Continual Service Impro
vement (Axelos, 2019).
Importantly, ITIL is initiated from business requirements and
evolves until operational services are delivered to customers. These
requirements are identified and agreed in the Service Strategy stage as
a Service Level Package (SLP) and a set of business outcomes. It is the
stage of business and technology alignment that procurement could
expect to understand the demand, the strategy to satisfy it, budget
estimates and high-level requirements.
In the Service Design stage, a solution is produced together with a
Service Design Package (SDP) containing everything necessary to
take this service through the remaining steps of the lifecycle. In this
FIGURE 2.2 ITIL Service Lifecycle

Service
Strategy
Continual Service Service

Improvement Design
ITIL
Service
Service
Transition
Operation
SOURCE Shutterstock
stage, the demand transforms into a solution, hence procurement

obtains a scope of work.
The SDP flows into the Service Transition stage, where the service
is evaluated, tested and validated, and updates are applied to the
Service Knowledge Management System (SKMS) – a set of databases
and tools that are used to manage information and knowledge (all
assets, components, services, databases, documentation, applications,
etc). Procurement will prepare the sourcing strategy for how to trans-
form the scope into contract deliverables.
Finally, the service enters the live environment and the Service
Operation stage begins. The bulk of service lifecycle costs are gener-
ated at this stage – an immediate capital expenditure (capex) and
recurring operating expenditure (opex) – all in line with the earlier
signed contract.
Why is ITIL Service Lifecycle relevant to this book? Because it is not
just a collection of processes, but the evolution of an idea into the fully
functioning service that delivers the business value. We highlighted this
earlier when discussing the new paradigm of non-commodity-based
technology procurement.
Following this lifecycle, we will be able to identify the critical mile-
stones and outputs of IT service management to align with the
procurement process and allocate respective cost elements to both.
Project management lifecycle

While ITIL elaborates on the lifecycle of a new technology service,
we also need to look at how to implement a controlled environment
to plan and deploy that service, meaning cost, time and resource
controls. So, we’re talking about project management now, where
PMI sets global standards. They developed PMBOK (Project
Management Body of Knowledge), which represents processes, best
practice, terminologies, and guidelines for the industry. It defines the
following generic project management lifecycle (PMI, 2017).
FIGURE 2.3 Project management lifecycle
Pla
nn
on
in
iat
g
Init
Project
management
life cycle
n
io
Cl
ut
su ec
o
re Ex
SOURCE Shutterstock
While you may refer to PMBOK for more detail, we will provide a simplistic
view of deliverables in each project lifecycle stage:
●●
Initiation:
–– define and justify the need for the project;
–– specify, quantify and agree desired outcome and benefits;
–– appoint a project manager and if appropriate set up a project board;
–– ensure the reasons for the project and its TOR (terms of reference)
are defined in a project brief;
–– ensure it is aligned with the strategic/business plan;
–– document the understanding of the project and how it will be
managed in a PID (project initiation document).
●●
Planning:
–– plan how to deliver the required outcomes and benefits;
–– decide how to manage relationships with key stakeholders;
–– decide how to project manage the delivery process;
–– determine resource requirements and ensure they can be made
available when required;
–– develop a business case to enable the SRO (senior requirement
owner)/project board to decide whether a project is cost and risk

justified.
●●
Execution:
–– mobilize the staff and other resources needed to build the products
and deliverables that will enable the required outcome;
–– plan, monitor and control the work and resources of the project;
–– manage risks and issues as they occur;
–– maintain communications with those impacted by the project and its
outcome and report progress and issues to SRO/project board/
stakeholders;
–– decide ongoing viability in the light of experience and any changes in
requirements;
–– ensure deliverables are fit for purpose and will enable benefits to be
realized.
●●
Closure:
–– have plans in place for a post-project review to measure to what
degree the benefits have been achieved in practice;
–– determine the need for any improvements or modifications;
–– ensure that the project is handed over to a person who will deliver
the outcomes;
–– carry out post-project reviews to measure the degree to which
benefits have been achieved;
–– update the business case to reflect operational reality;
–– identify potential improvements/changes/opportunities in the
reviews fed into the strategic planning process for consideration
(Department of Business, Innovation and Skills, 2010).
The Project Management Lifecycle can be easily mapped to the ITIL

Service Lifecycle together with the outputs identified in each stage.
Technology and project managers working alongside each other must
synchronize their core processes, otherwise the project is destined for
failure.
The ITIL Service Lifecycle does not provide an explicit definition

of the procurement process, while Chapter 12 of PMBOK clearly
defines the ‘procurement management’ and differentiates its integral
processes:
●●
Planning stage (plan procurement management) – the process of
documenting project procurement requirements, specifying the
market approach and identifying potential suppliers.
●●
Execution stage (conduct procurements) – the process of bidding
(solicitation), selecting a supplier and awarding a contract.
●●
Monitoring and control stage (control procurements) – the process
of managing supplier relationships, monitoring performance and
conducting the change management and corrective actions.
●●
Completion stage (close procurements) – the process of closing
project procurement contracts (PMI, 2017).
The inputs and outputs of each process help stakeholders to under-

stand the view of project managers, align each other’s processes and
leverage important artefacts – scope statement, budget estimate,
project plan, etc.
Strategic procurement process

Our typical strategic procurement process consists of seven steps and
follows similar logic to the technology service (ITIL) and project
management lifecycles – we also need to plan, execute, control, and
close sourcing projects:
1 initiate a sourcing project;

2 identify business needs and study the market;
3 specify requirements;
4 define a sourcing strategy;
5 select a supplier and award a contract;
6 manage a contract and supplier relationship;
7 review results and close.
Understanding the procurement process is essential for technology

and project managers. While procurement is an area into which they
will give input, in most companies, it’s an area they don’t own. A
manual of authority would not give them the right to sign and admin-
ister contracts; therefore, a healthy symbiosis between Technology,
PMO, and Procurement needs to be maintained to ensure that all
stakeholders consciously follow the same process.
While the procurement process is standardized, its applications
could differ substantially. We will now explain how conventional
purchasing transforms into category management and strategic
sourcing by elaborating on demand management, contract manage-
ment and supplier relationship.
Category management
CIPS defines category management as organizing the resources of the
procurement team in such a way as to focus externally onto the
supply markets of an organization (as opposed to having a focus on
the internal customers or on internal procurement departmental
functions) in order to fully leverage purchasing decisions.
Let’s try to explain. Category management suggests grouping
goods or services (commodities) by similar characteristics, instead of
the budget being owned by business departments which may have
similar requirements (eg stationery or travel). The purpose is to lever-
age the full purchasing power of a company.
Category management is a cyclical process and as such should not
be considered as a one-off initiative. It is developed on the following
foundations:
●●
Company and procurement strategy. Your category strategy cannot
exist in isolation; it has to reside in business priorities and require
ments. For example, if the business strategy of your company is to
deliver premium products to the most demanding and wealthy
clientele, then you won’t be building your category on low-cost
suppliers. You should also align with the departmental strategy to
deliver functional KPIs, develop stakeholder relationships, imple
ment centralized SRM initiatives, etc.
28
FIGURE 2.4 Category management framework
3
2 Identification, validation and agreement on
Collect and analyse information category opportunities
relating to the category
1. Understand category opportunities
1. Understand category requirements 2. Prioritize and target opportunities
2. Identify sources of information 3. Evaluate
3. Extract key data prioriti and
d z
an lysis opportun e
a itie
extern nal
s
an
4
er
al
2. Int
g ory pla n
Creation of a plan to target
velo p
identified opportunities
Category
Management
4. D e
Draw on information from previous
cate
1. St a g e
steps to inform and create plan
eng
ake m
ho
l nd
1 en d er ra
Identify and engage people t t o
5. M o ni te n
a a
involved in the category u p d y pl
r
c ate g o
1. Identify key stakeholders through 5 Management of the category
stakeholder mapping A structured approach to the monitoring
2. Prioritize and manage interaction and updating of the category plan
●●
Stakeholder analysis is the critical element of your category
strategy, as you will have to build long-term relationships with
business requestors, finance controllers, executive sponsors, etc.
Each of them has their own priorities, incentives, and expectations,
which a category manager needs to understand and manage to
achieve cross-functional cooperation and top management support.
●●
Business requirements have certain patterns that need to be
analysed and accounted for. For example, the marketing depart
ment usually demands quick responses to generic and sometimes
subjective requirements, while IT provides an extensive well-
defined scope and allows ample time for a thorough analysis.
Category strategy needs to account for these specifics with tailored
sourcing processes, smart resource allocation, and appropriate
demand management techniques.
●●
Supply market dynamics could result in a temporary shortage or
oversupply of certain resources (eg hardware components),
improvement or degradation of the competitive environment in
some market segments (eg mergers and acquisitions between
leading market players), or a tendency to push certain products/
solutions (eg forced cloud adoption). Supply chain risks need to be
analysed and rated. Such analysis can be obtained from industry
analytics and incorporated into the category strategy.
●●
Suppliers form the critical part of the category strategy – supply
base analysis and segmentation, SRM initiatives, performance
management, strategic partnership opportunities, supplier innova
tion, preferential procurement, etc.
●●
Budget must be analysed as to generic and business-specific
indicators – total revenue and expenditure dynamics, category-
specific business drivers (eg sales targets, customer additions) and
capex/opex projections, critical projects and initiatives (eg cost-
cutting or revenue acceleration).
●●
Spend profile provides the distribution per sub-categories, supp
liers, geographies, along with important dynamics such as increased
spend with certain suppliers or for certain products.
●●
Benefits and KPIs for the category will be developed based on
historical performance, spend analysis, budget trends, and signifi
cant initiatives on savings, revenue generation and SRM.
Category strategy is the most important document of the year for a

category lead to structure operational activities and measure perfor-
mance. It must be agreed with business and finance stakeholders to
share category targets and exercise a cross-functional approach to
achieving them.
As an example of the category management implementation, we discuss

here the experience of US Government and the OMB (Office of
Management and Budget) memorandum ‘Category Management: Making
smarter use of common contract solutions and practices’.
We will start with the problem statement made in March 2019, which
resonates with our earlier definition of the category management.
The lack of mechanisms to support agency collaboration on common
contract solutions has resulted in billions of dollars in lost cost
avoidance, inappropriate contract duplication, and missed opportunities
to adopt Government and industry best practices.
Before going further, we need to give some explanation. Government
agencies are encouraged to conduct acquisitions under GWACs
(Government-Wide Acquisition Contracts) to enjoy consolidated volumes
and consistent pricing. The OMB named some of GWACs the BIC – Best in
Class. Essentially, these are the preferred (but not mandatory) sources for
respective categories on the national level.
To qualify for BIC, the GWAC’s agency must complete documented
evaluation, which includes a cross-category or cross-agency subject matter
expert evaluation and a Category Management Leadership Council review.
In addition, the BIC GWAC must satisfy five OMB criteria:
●●
rigorous requirements definitions and planning processes;
●●
appropriate pricing strategies;
●●
data-driven strategies to change buying and consumption behaviour (ie
demand management);
●●
implementation of category and performance management strategies;
and
●●
independently validated reviews.
The OMB established the following spend tiers:
Tier 0 – unaligned spending by the agency, which involves purchasing in a

decentralized manner and not conforming to category management
principles, including strategic oversight and disciplined consideration of
performance data to understand prices paid by other federal customers
or metrics to improve results.
Tier 1 – spending managed at the agency-wide level with supporting
mandatory-use policies and strong contract management practices,
including data analysis, information sharing across the agency, and use
of metrics that are defined, tracked and publicized.
Tier 2 – spending managed at a government-wide level through multi-
agency or government-wide solutions that are not BIC solutions but
reflect strong contract management practices, including data and
information sharing across agencies, and use of cross-agency metrics.
Tier 3 – spending managed at the government-wide level through the use
of BIC solutions that have been identified through a collaborative
inter-agency process by acquisition category experts within the
government as offering the best pricing and terms and conditions
within the federal marketplace and reflecting the strongest contract
management practices.
Now we can get to the actual guidelines:

Agencies shall undertake the following five key category management
actions to better position themselves to bring spending under
management and leverage common contract solutions and practices:
1 Annually establish plans to reduce unaligned spend and increase the

use of BIC solutions for common goods and services, consistent with
small business and other statutory socioeconomic responsibilities.
2 Develop effective vendor management strategies to improve
communications with contractors, especially those that support
mission-critical functions.
3 Implement demand management strategies to eliminate inefficient

purchasing and consumption behaviours.
4 Share data across the Federal Government to differentiate the quality
and value of products and services in making buying decisions.
5 Train and develop the workforce in category management principles
and practices (Office of Management and Budget, 2019).
The first point of the guideline assumes establishing a plan with agency
procurement executives to reduce unaligned spend (ie Tier 0) by increasing
the use of multi-agency contracts and GWACs (ie Tiers 1, 2 and 3) and
increase the use of BIC solutions (ie Tier 3). We will cover other points in
different sections of this book, as all of those are simple yet logical steps
required in any category strategy.
Basically, the OMB approached category management by applying
pressure on agencies through the set of measures and KPIs to buy jointly
from preferred and rigorously selected sources, otherwise having to justify
the selection of an alternative. You would find a similar approach in most of
group procurement organizations trying to align local operating companies
to global framework agreements that leverage the consolidated buying
power and introduce standardized products and solutions.
Strategic sourcing
There is a widespread perception of procurement as an old-school
bureaucratic function mostly required to maintain governance. At
the same time, some companies cherish their procurement for s trategic
mindset, partnership, agility and value generation. A key differentia-
tor between these two ‘procurements’ is strategic sourcing, which
follows the same seven-step process, but with a specific activity level
and value output in certain stages, as shown in Figure 2.5.
Conventional purchasing will dedicate most of its effort to an RFP
and negotiations. It will maintain a cumbersome tender process with
an extensive document trail and multiple checkpoints, and then tire-
lessly fight suppliers for discounts. Upon a contract award, its activity
will perish until the next RFP. It will measure success with savings
and pray to the Gods of Governance.
FIGURE 2.5 Purchasing vs strategic sourcing
Value
generation
Strategic sourcing Purchasing
Activity
Strategic sourcing
level
Purchasing
Identify Select a Manage a

Initiate a Define a Review
business needs Specify supplier and contract and
sourcing sourcing results
and study the requirements award a supplier
project strategy and close
market contract relationship
7-step process
SOURCE Adapted from New Zealand Government, 2011
33
Strategic sourcing professionals will be there at the cradle of a require-

ment. They will form a cross-functional team of key stakeholders to
analyse, challenge and optimize the very nature of demand. Most
savings are usually achieved in internal negotiations when stakehold-
ers eventually agree to let go of wasteful demands and spend the
company money on something purposeful, value generating and
cost-effective. No doubt the tender process is going to run smoothly,
and suppliers will make offers to the satisfaction of a budget owner,
but strategic sourcing professionals will know that the fat of excess
requirements, inflated ambitions, and false security must be separated
as early in the procurement process as possible.
They will also rigorously monitor SLAs, timelines and quality to
establish contract performance reviews with suppliers and rectify
problems. They will manage supplier relationships to ensure their
constant focus on the company as a remarkable account and create a
rewarding environment for long-term partnership and innovation.
Project procurement as discussed earlier in this chapter is similar
to conventional purchasing because it plans, executes and monitors
the results of a single project. Strategic sourcing resides in a category
strategy and keeps in mind the bigger picture – market developments,
supplier management strategy, and make/buy/outsource options – to
achieve a sustainable value across the entire category of spend.
How would we define strategic sourcing then? Possibly as the
value-generating mindset applied to every aspect of the procurement
process. If we complement that with precision business planning,
waste-free demand management, clock-working supply chain, sophis-
ticated risk management, and gold standard SRM, then we will get
Unilever, Cisco or Apple, who shape the future of our profession.
Procurement value levers

Particular activities in different stages of the procurement process are
called value levers – sets of actions that enable procurement to extract
the value (eg managing cost, meeting timelines, ensuring quality and
delivering benefits). Levers of conventional purchasing are usually
FIGURE 2.6 Procurement value levers
Comply levers Demand levers Process levers Source levers Fulfil levers Manage levers
Spend Eliminate Type of Bundle/ Demand/supply P2P control

governance demand sourcing event unbundle balancing
Policy Review Cycle time Supplier Ordering Variations
compliance quantity rationalization
Budget Reduce Prioritize Volume or time Physical Risk

compliance frequency projects commitment delivery
Procurement
value levers Standardize Buying Pricing Storage and Performance
specs channels mechanism distribution
Reduce Source from Performance or Contract Value delivery

portfolio OEM benefit incentives compliance
Consider Risk Repair and
alternatives allocation replacement
Encourage Payment Transaction
reuse terms cost
Additional
benefits (revenue,
marketing, etc)
Identify Select a Review

Initiate a business Specify Define a Manage a contract and
sourcing sourcing supplier supplier results
needs and requirements and award a and
project study the strategy relationship
contact close
market
7-step process
35
limited to sourcing – pricing, delivery, and payment term negotia-

tions. However, this toolkit is much more sophisticated, and you
don’t have to wait until negotiations to start using it.
The inventory of value levers differs from one author to another
(eg Costelloe, 2016). We selected 35 of those based exclusively on our
practical experience and mapped each to its respective stage of the
procurement process, to show not only what steps to follow, but also
what tools to use in each step.
COMPLY LEVERS
Comply levers allow you to eliminate the non-compliant demand as
early in the sourcing process as possible, and avoid the diversion of
resources from value-generating initiatives:
●●
Spend governance. PR (purchase requisition) rejected for out-of-
governance spend (eg high-value customer entertainment prohibited
by the code of conduct) or routed into different fulfilment channels
(eg state-regulated services or commodities not requiring the
competitive procurement process will be routed to direct PR-to-PO
workflow).
●●
Policy compliance. PR rejected or sent for an extra level of
approvals for non-compliant spend (eg out-of-bundle mobile
services).
●●
Budget compliance. PR rejected due to lack of budget or routed to
finance control to top up a cost centre.
DEMAND LEVERS
Demand levers allow you to start saving without even knowing who
your preferred supplier is. It is used to eliminate wasteful demand
and optimize useful demand (we will explain this process in more
detail in Chapter 5). It is particularly important to ensure that new
requirements are leveraging existing resources (eg material stocks):
●●
Eliminate demand. PR rejected due to demand fulfilment by
existing resources (eg inventories) or proven wastefulness of it (eg
out-of-policy staff entertainment or giveaways at a company cost).
●●
Review quantity. PR returned for modification due to decreased
quantity (eg to stay within the budget limits or partially defer some
spend until the next fiscal year to ease the immediate cash flow).
●●
Reduce frequency. PR returned for aggregation at a later stage (eg
to increase the PO volume for additional discounts or avoid
incremental orders that incur individual freight and import costs).
●●
Standardize specs. PR rejected for non-standard products or services
(eg laptop or smartphone models, configurations and accessories
not complying with corporate IT standards).
●●
Reduce portfolio. PR rejected due to the revision of default product
or service offering (eg no more blankets provided to air passengers
on short-haul flights).
●●
Consider alternatives. PR sent for modification to use less expensive
alternative products (eg Alpine spring water for executive meetings
replaced with local artesian water).
●●
Encourage reuse. PR rejected to consider the use of aged stocks (eg
despite re-branding, the business will inject small batches of
merchandise with an old brand into the retail network).
PROCESS LEVERS
Process levers relate to the speed, efficiency and prioritization of sourc
ing projects. Buying channels will help you to segregate requests that
do not require a full-blown sourcing project.
●●
Type of sourcing event. Depending on time-to-market plans, impor
tance, dependencies of/to other projects and many other specific
factors, the procurement officer in charge of a sourcing event could
decide to opt for an accelerated procedure (provided the procure
ment manual allows for one), issue an offline RFx (via email, which
is usually quicker) or find other ways to optimize the sourcing
process as permitted by governance (eg reuse the results of the
recent RFx conducted for a similar scope, instead of running a new
process from scratch).
●●
Cycle time. This lever assumes the presence of advanced controls
and SLAs in the sourcing process. Any delay beyond the standard
duration of a process step will result in the escalation of a respective

action one executive level up, or auto-completion of that step (eg
no approval or denial of a sourcing strategy within X days results
in an auto-approval).
●●
Prioritize projects. This lever is managed by the category lead or
the head of procurement, as they orchestrate the pool of resources
and dynamically allocate it to incoming tasks. She/he can assign
the most experienced buyer to the important project or power up
the sourcing team with extra resources.
●●
Buying channels. This is one of the most process-effective value
levers. Buying channels are the variations of the generic S2P
(Source-to-Pay) process, and their primary aim is to offload the
tail-spend (PRs accounting for 10–20 per cent of the category
spend but generating 70–80 per cent of transactions, ie high-
volume, low-value PRs). However, they can be adjusted to any
spend to balance controls and efficiency. There are five main types
of buying channels:
–– Hands-free (no procurement involvement) – call-off orders from
existing contracts, punch-out catalogues, direct orders of stock
items from MRP system.
–– No-PO – P-cards (corporate charge cards), out-of-pocket expen
ses, petty cash purchases.
–– Category-specific – travel management portal, outsourced
payroll and expense system, IT fulfilment portal.
–– Vendor-managed – managed service provider portal, consign
ment/VMI.
–– Buyer-assisted (PRs routed by buyers to specific suppliers) –
mandatory or preferred suppliers.
●●
Source from an OEM. Procurement can decide to source directly
from an OEM (original equipment manufacturer) or their recom
mended partners, as opposed to running an RFx between multiple
partners of the same OEM (eg Microsoft do not sell licences to end
users, but they regulate the pricing, hence it is more effective to
appoint their recommended channel partner upon negotiating terms
directly with Microsoft).
SOURCE LEVERS
Source levers cover different aspects of negotiations and address so
much more than just discounts and payment terms:
●●
(Un)-bundle. Increase the order volume by bundling to achieve a
better discount or unbundle to ease the cash flow.
●●
Supplier rationalization. Aggregate the related spend with one
supplier (eg let facility maintenance company supply kitchen and
cleaning products, source the paper from a managed print service
provider, etc).
●●
Volume or time commitment. Consider committing to achieve a
certain volume of sales during the contract period to secure the
special pricing. Place an order by the fiscal year/quarter end to
qualify for the limited time discount.
●●
Pricing mechanism. There are more or less six standard pricing
models:
–– Cost-plus – production cost plus margin or sales channel incoming
cost plus a mark-up.
–– Market-based – a price based on the market average among
major players.
–– Value-based – a price regulated not by the production cost, but
by the perceived customer value (eg quality, reliability, status
etc).
–– Time and material – when customer requirements are unclear
or dynamic, a price becomes the product of rate and time plus
residual cost (eg travel expenses, consumables).
–– Fixed – a price covers the full scope and any change to that is to
be priced additionally.
–– Risk-and-reward sharing – a price linked to the project success
criteria with a pay deduction for under-achievement and a
premium for over-achievement. For example, if a project expected
to deliver the opex saving of X, then the actual delivery of X-10
per cent or more results in the additional discount, while X+10
per cent or more triggers a premium. This model especially fits
SaaS contracts, where penalties or premiums could be paid along

with regular subscription payments, eg, on a monthly basis. There
can be variations of pricing models for individual contracts, such
as tiered pricing, minimum value plus overage, dynamic/demand
pricing (eg, airlines and hotels), retainer (creative and marketing
services) etc.
●●
Performance incentives. This is similar to the risk-and-reward
sharing pricing mechanism; however, the incentive could be
provided in the form of a contract extension.
●●
Risk allocation. Indemnification, liquidated damages, performance
bonds.
●●
Payment terms. Deferring some payment milestones will enable
cost-of-capital savings. This lever could be highly sophisticated, eg
by engaging the export trade credit line from an appropriate
supplier’s government body.
●●
Additional benefits. Once the price is sufficiently negotiated, a
buyer can seek additional benefits, for example:
–– Revenue commitment from a supplier (reciprocal buying).
Especially useful when your company offers some mass-market
goods or services (eg mobile communication, air travel, FMCG
products, insurance and similar) that are being consumed by
your suppliers in their daily operations.
–– Marketing partnership (advertising on marketing assets of
another party to negotiations, event sponsorship, co-branding,
targeted customer campaigns etc).
–– Free unrelated items (eg business consultancy on finding new
revenue opportunities).
–– Kickback on the sale of proprietary features developed for your
company to the first or all consecutive customers of the supplier.
–– Special pricing on supplier’s products or services for the staff of
your company (eg special Microsoft Office licence pricing for
home use, bank offers for salary account holders).
FULFIL LEVERS
Fulfil levers are used by procurement professionals who understand
the complexity of supply chain management and can balance demand
and supply, reduce delivery, storage and distribution cost, and control
lead time and quality:
●●
Demand/supply balancing. Managing the demand profile to avoid
spikes of over-ordering and protect from material shortages.
●●
Ordering. Placing orders in alignment with the production schedule
and lead times (eg to avoid ordering in the peak season at a
premium price and/or longer lead times).
●●
Physical delivery. Negotiating favourable incoterm delivery terms
or consciously opting for own freight and insurance to save cost
versus supplier’s fulfilment.
●●
Storage and distribution. Keeping the stock at the supplier’s
warehouses and distributing to the network from there.
●●
Contract compliance. Continuously managing the contract to
enforce applicable terms in case of supplier’s failure to perform.
●●
Repair and replacement. Negotiating a longer warranty term or
defining the best logistical solution for after-warranty repair and
incorporating it into a contract.
●●
Transaction cost. Analysing routine activities related to the contract
execution and commercial operations and seeking transactional
cost savings (eg automate or outsource the clerical work).
MANAGE LEVERS
Finally, manage levers are applied to ensure contract compliance,
monitor performance, mitigate risks, and control the delivery of
projected benefits and efficiencies:
●●
P2P control. Control timely and accurate invoicing, consider
negotiating a discount for shorter payment terms, if accepted by
accounts payable.
●●
Variations. Control all variations to the initial contract scope.
●●
Risk. Manage the risk register throughout the entire contract
execution.
●●
Performance. Monitor and document supplier’s performance to
conduct regular SRM activities.
●●
Value delivery. Monitor the actual delivery of the projected value
(eg additional revenues or savings as per the business case).
Arguably, mastery in applying these levers differentiates a true

procurement professional from any other competitor – internal or
external. It is tough, if not impossible, to outsource or automate all
35 levers, because using them implies an advanced level of under-
standing of the company business, carefully constructed relationships
with stakeholders and suppliers, multi-discipline knowledge, and a
strategic mindset allowing the employment of the right tools at the
right time.
TCO of a technology service

Before we map the ITIL Service Lifecycle to project management and
the strategic procurement process, there is still a critical element we
need to elaborate upon – THE COST!
Usually, the introduction of a new service requires a budget, unless
your company sets aside pockets of funds for the ‘new stuff’. Finance
control will want to conduct the cost–benefit analysis of any new
requirement, and for that they need a costing model. On the other
hand, procurement needs a method to evaluate offers not just based
on the lowest price.
Both Finance and Procurement will employ the TCO (Total Cost
of Ownership) concept – an estimate of all the direct and indirect
costs involved in acquiring and operating a system or a service over
its lifetime. In technology terms, this means that a cost model will
include not only software, hardware, deployment and support, but
also discovery, hosting, connectivity, programme management, train-
ing, travel, extra resources, etc.
Ideally, the TCO calculation should include benefits generated by
the system/service, plus the resale or disposal value at the end of life,
so the model effectively becomes the cost-and-benefit assessment.
TCO allows departments to look at both the short- and long-term

costs of any particular solution. Although full life costs are often
calculated for business cases, this is seldom the same thing as TCO.
Traditionally cost has been associated with the purchase price alone
or purchase price plus support costs; however, the initial procure-
ment cost is typically only a relatively small percentage of the total
cost of owning and operating most IT products.
It is often difficult to predict accurately what the lifetime costs of a
solution will be, particularly in relation to change, so carrying out a
TCO assessment provides an opportunity to identify, explore and
challenge any assumptions and biases. Calculating TCO is necessary
to quantify and compare the costs of all software options and applies
equally to proprietary and open source. A TCO assessment of open
source software suitability should be no more complex than the
assessment of commercial software.
Typical composition of the TCO includes:
●●
Acquisition and procurement:
–– selection;
–– upfront evaluation;
–– purchase price;
–– licences;
–– hardware;
–– integration.
●●
Operation and management:
–– migration (data and users);
–– use;
–– maintenance;
–– upgrades;
–– support services;
–– training;
–– software modifications (scaling);
–– cost of customization;
–– development, modification;
–– carbon footprint.
●●
End of life management
–– retirement;
–– disposal;
–– migration (data and users).
However, as discussed earlier, the ultimate goal of a technology

project is to deliver not just software, but a comprehensive service
which fulfils business requirements. Hence the ITIL Service Lifecycle
would be suitable to align TCO elements to it (please note that your
TCO model should not always be that sophisticated, as the following
concept intends to serve as a possible solution to the most compli-
cated high-value and long-term technology projects).
For the Service Lifecycle-based TCO model, we suggest 23
elements, as follows.

Service Strategy
–– Cost of discovery (BA and SA).

Service Design
–– Cost of service design.
–– Cost of evaluation (including POC).
–– Cost of contract development.

Service Transition
–– Cost of setup (eg a cloud-hosting setup or additional servers and
storage in a corporate data centre).
–– Cost of perpetual software licences.
–– Cost of hardware and end-user devices.
–– Cost of deployment (including travel).
–– Cost of cloud services.
–– Cost of integration.
–– Cost of migration (eg data and users).
–– Cost of testing.
–– Cost of legacy platform decommissioning.

–– Cost of project management.
–– Cost of knowledge management.
–– Cost of change management (process, documentation, organization,
communication).

Service Operations
–– Cost of software rental.
–– Cost of change requests.
–– Cost of support (L1–L3, in-house and/or third party).
–– Cost of maintenance and upgrades.
–– Cost of asset management.
–– End of life cost.
–– Cost of retirement or replacement.
Cost of service strategy

In the Service Strategy stage, there will be a so-called discovery. The
IT business analyst (BA) will work with the requestor of a new service
to undertake a detailed, comprehensive analysis of requirements, to
prepare a detailed business requirement document (BRD), and to
prepare a requirement traceability matrix (that establishes links
between business requirements, RFP and final contract deliverables).
Next, a software architect (SA) will work on a design document to
explain a proposed solution and its integration to the existing IT
infrastructure. Discovery findings will have to be aligned with the IT
strategy and incorporated into the service portfolio.
The BA and SA costs of discovery will become the first contribu-
tors to a TCO model.
Cost of service design

The Service Design stage is expected to produce multiple artefacts, eg
High-Level Design (HLD), Service Catalogue, Service Level Agreement
(SLA), Capacity Plan, Availability Plan, Security Policies, etc. We will
incorporate all that into the Cost of Service Design.
Naturally, the procurement process requires technology experts to
prepare technical sections of an RFP document, define scoring crite-
ria and conduct the technical evaluation of bids, perform POC (Proof
of Concept) and issue a report. All these activities contribute to the
Cost of Evaluation.
Finally, a contracting process requires technology resources to take
part in the preparation of appropriate amendments (eg the scope of
the agreement, project plan, SLAs, IT security, data protection, etc).
The cost of resources involved is the Cost of Contract Development.
Cost of service transition

All TCO elements in the Service Transition stage identify what’s
required for successful end-to-end project deployment. Most of these
cost elements are not recurring and are likely to be capitalized.
A bulk of the project management cost will be generated at this
stage, hence we’re mapping it here. However, the project manage-
ment usually starts from the service design, since all resources
involved need to be charged to a project and managed under one
roof. The final elements of project management will reach the Service
Operations stage, mainly to allocate costs and trace benefits commit-
ted in a business case.
The cost of cloud services will also be generated at this stage, as an
environment needs to be created for deployment and testing. It will
then extend onto the operation stage.
The difference between change management and change requests
is that the former covers modifications of existing operational
processes and documentation, along with internal communications
for stakeholder awareness, while the latter relates to scope changes
that appear in the course of deployment and then operations
(eg software functional changes, additional works, extra licences

and so on).
It is essential to understand when the cost of software rental starts
to generate. Ideally, this should happen only upon go-live of a new
service, so you start paying upon the service becoming operational
and delivering revenues and efficiencies. However, a supplier could be
insisting on applying these charges earlier, for example because this
software will be used in the process of testing. That needs to be
considered in the negotiation plan, which we will cover later.
Cost of service operations

These are mainly operational expenditure (opex) parts of the TCO,
apart from change requests that could be either capex (setup of an
additional hosting environment, new perpetual licences or deploy-
ment services) or opex (changes to software rentals, cloud services or
maintenance).
We will map the cost of change requests (CRs) to this stage due to
the higher magnitude of spend generated during operations; however,
first CRs could appear during the Service Transition.
By the Cost of Asset Management, we mean resources and tools to
manage software licences, and we will later explain why this is essential.
Example of the TCO calculation for a technology project

Figure 2.7 is a practical example of the business case for a travel sales
acceleration system for an airline. It includes the existing revenue
from an incumbent Vendor 1 and a projected one from the rival
Vendor 2. The system is meant to stimulate both air and non-air
(hotel, airport transfer) revenue.
The TCO calculation developed by Procurement became part of
the very complex business case (please note the number of linked
worksheets). As you can see, the TCO detail could go as far as the
depreciation. The earlier proposed ITIL Service Lifecycle-based TCO
model was not required for this project due to the low technical
complexity.
FIGURE 2.7 Sample business case with TCO calculations

Vendor 1 Vendor 2
P and L Jul18 YTD Aug–Dec18 FY 2018 FY 2019 FY 2020
Total revenue
Revenue
Gross profit
Margin
Non-air revenue
Non-air gross profit
Margin
Customer share
Vendor share
Customer share (x%)
Vendor share (100–x%)
Customer share (Y%)
Vendor share (100–Y%)
Manpower
Marketing
Implementation cost
Other G and A
Depreciation
Net result
Capex
Vendor 1
YTD 2018 2019 2020
Vendor 1 Vendor 2
P and L Jul18 YTD Aug–Dec18 FY 2018 FY 2019 FY 2020
Revenue
Gross profit
Customer share
Vendor share
Manpower
Marketing
Other opex
Net result
This business case also represents a true example of cross-functional

teamwork, as it includes the sales forecast developed by Commercial,
TCO by Procurement and the overall financial model prepared by
Finance. It has been used during negotiations to plug in immediately
offered revenue share tiers and percentages and obtain revenue,
margins and scenario comparisons.
Four pillars mapped together: integrated planning

in technology procurement
Finally, we can assemble all the different moving parts of the puzzle
to understand how technology procurement stands on its four pillars.
The ITIL Service Lifecycle, project management lifecycle in general,
project procurement management in particular, and the seven-step
procurement process are mapped to each other in Figure 2.8. The
dotted, grey and white cells identify which procurement artefacts to
expect at each stage of the process, and from which domain (pillar).
The procurement team deliverables are specified in the dotted cells,
technology ones in white cells, and grey cells result from the project
management work stream. Lastly, TCO elements are aligned to three
other ‘pillar’ processes to indicate which components of cost are
generated at each stage of the process.
This mapping is intended to provide a holistic view of the inte-
grated planning that needs to be achieved in the technology
procurement process. Whenever key functions act in isolation, the
sourcing project is destined for failure. Business, Technology, Procure
ment, and Finance stakeholders must perform as an orchestra
conducted by the project manager and ensure synchronization of
individual processes and subordination to the common goal of the
successful service delivery to end users.
As we have provided the solid framework to technology procure-
ment, standing on its four pillars, we will have to keep the following
notions in mind:
50
FIGURE 2.8 Integrated planning in technology procurement
Continual
ITIL Service Service
Service strategy Service design Service transition Service
Lifecycle operations
Improvement
PMBOK Solicitation Source Contract

Procurement planning Solicitation Contract administration
Chapter 12 planning selection close-out
Project manage-
Initiation Planning Execution Closure
ment lifecycle
Identify
Define
Strategic Initiate need Specify Select a supplier
sourcing Manage a contract and supplier relationship
sourcing process project and study requirements and award a contract
strategy
the market
Stake
Scope Statement of Approach to Supplier
holder POC report Change requests
statement work market selection
register
Project
Project Market List of
manage- Contract Performance reviews
charter analysis suppliers
ment plan
Historical
spend Evaluation
Evaluation Budget and benefit tracking
and methodology
suppliers
Key Approach
procurement Source-2- Contract
to Negotiation
artefacts contract management
market plan
timelines plan
strategy
Business Sourcing
requirements strategy
Architecture
requirements
Cost/benefit estimate
Business case
Service Design Package (SDP)
Cost of
retirement
Cost of project management
or replace-
ment
Cost of discovery Cost of service design Cost of change requests
Cost of
contract Cost of
Cost of evaluation Cost of cloud services
develop- setup
ment
Cost of
Cost Cost of
perpetual Cost of
of sofware
software deployment
testing rental
licenses
Cost of
hardware
Cost of Cost of
and
TCO integration support
end-user
devices
Cost of
Cost of
maintenance
migration
and upgrades
Cost of
legacy Cost of
platform asset
decommis- management
sioning
Cost of knowledge management
Cost of change management
procurement team deliverables technology team deliverables project management team deliverables
51
●●
Technology procurement participates in the delivery of compre
hensive value-generating services to the business and hence needs
to follow the ITIL Service Lifecycle.
●●
Cross-functional collaboration and alignment is the critical enabler
for the success of both the technology and sourcing projects.
●●
Indirect procurement professionals of the future need to demon
strate the mix of inter-disciplinary skills to be able to follow the
technology service lifecycle, align with the project management
process, develop TCO models and operate business cases – in
addition to the mastery of the strategic procurement process and
value levers.
●●
Procurement possesses an extensive toolkit of strategic sourcing
and value levers, and the outcome of a sourcing project is only
limited by the (lack of) capabilities, skills and stakeholder/supplier
management.
References
Axelos (2019) ITIL® Foundation, ITIL 4th edition [online] https://www.axelos.
com/store/book/itil-foundation-itil-4-edition (archived at https://perma.cc/
YGU2-6NCY) [accessed 13 May 2019]
Costelloe, N (2016) Five things: getting the basics right in procurement, Ernst and
Young [online] https://www.ey.com/Publication/vwLUAssets/EY-best-practice-
guide-five-things-in-procurement/$File/EY-best-practice-guide-five-things-
in-procurement.pdf (archived at https://perma.cc/ZNX8-AZJN) [accessed 13
May 2019]
Department of Business, Innovation and Skills (2010) Guidelines for managing
projects: how to organise, plan and control projects [online] https://assets.
publishing.service.gov.uk/government/uploads/system/uploads/attachment_data/
file/31979/10-1257-guidelines-for-managing-projects.pdf (archived at https://
perma.cc/D68N-PWNV) [accessed 13 May 2019]
Gartner (2018) Gartner Forecasts worldwide public cloud revenue to grow 17.3
percent in 2019 [online] https://www.gartner.com/en/newsroom/press-
releases/2018-09-12-gartner-forecasts-worldwide-public-cloud-revenue-to-grow-
17-percent-in-2019 (archived at https://perma.cc/5KKV-TGYH) [accessed 13
May 2019]
New Zealand Government (2011) Mastering procurement: a structured approach

to strategic procurement [online] https://www.procurement.govt.nz/assets/
procurement-property/documents/guide-mastering-procurement.pdf (archived at
https://perma.cc/3CHF-VHXH) [accessed 13 May 2019]
Office of Management and Budget (2019) Memorandum M-19-13: Category
management: making smarter use of common contract solutions and practices
[online] https://www.whitehouse.gov/wp-content/uploads/2019/03/M-19-13.pdf
(archived at https://perma.cc/D8FN-H7WK) [accessed 13 May 2019]
PMI (2017) PMBOK® Guide – 6th edn [online] https://www.pmi.org/pmbok-
guide-standards/foundational/pmbok (archived at https://perma.cc/
H2K2-LMMN) [accessed 13 May 2019]
54

55
03
Technology basics for procurement

professionals
You don’t need to be a software architect to conduct technology

procurement, but you should have a conceptual understanding of
modern IT solutions. For example, ‘VMWare Cloud on AWS’ repre-
sents the mix of advanced technologies – Software-Defined Data
Centre (VMWare) hosted in the public cloud (AWS – Amazon Web
Services) with the management layer retailed in a private cloud, ie all
together forming a hybrid cloud.
This is how far virtualization and cloud computing have brought
us in just a decade. Companies used to build their own data centres
and host software applications there. Then third-party data centres
appeared, and you were no longer required to own hardware. Then
physical machines have been used to create virtual data centres to get
more computing power for less money. At the same time, Amazon,
Microsoft, and Google established their global public clouds, and so
you can now create a virtual datacentre in Amazon cloud, retaining
the management of it and hosting critical data (eg customer records)
in-house.
As a procurement professional, you don’t have to get much deeper
into the IT architecture than this, but you need to understand the
basics.
Cloud computing model

We will refer to definitions of NIST – the National Institute of
Standards and Technology – a unit of the US Commerce Department,
formerly known as the National Bureau of Standards. NIST promotes
and maintains measurement standards and has active programmes
for encouraging and assisting industry and science in developing and
using these standards.
Cloud computing is a model for enabling convenient, on-demand
network access to a shared pool of configurable computing resources
(eg networks, servers, storage, applications and services) that can be
rapidly provisioned and released with minimal management effort or
service provider interaction. This cloud model is composed of five essen-
tial characteristics, three service models, and four deployment models:
●●
Essential characteristics:
–– On-demand self-service. A consumer can unilaterally provision
computing capabilities, such as server time and network storage,
as needed automatically without requiring human interaction
with each service’s provider.
–– Broad network access. Capabilities are available over the network
and accessed through standard mechanisms that promote use by
heterogeneous thin or thick client platforms (eg mobile phones,
tablets, laptops, and workstations).
–– Resource pooling. The provider’s computing resources are pooled
to serve multiple consumers using a multi-tenant model, with
different physical and virtual resources dynamically assigned
and reassigned according to consumer demand. There is a sense
of location independence in that the customer generally has no
control or knowledge over the exact location of the provided
resources but may be able to specify location at a higher level
of abstraction (eg country, state, or data centre). Examples of
resources include storage, processing, memory, and network
bandwidth.
–– Rapid elasticity. Capabilities can be rapidly and elastically provis
ioned, in some cases automatically, to scale rapidly outward
TECHNOLOGY BASICS FOR PROCUREMENT PROFESSIONALS 57
and inward commensurate with demand. To the consumer, the

capabilities available for provisioning often appear to be unlimited
and can be appropriated in any quantity at any time.
–– Measured service. Cloud systems automatically control and
optimize resource use by leveraging a metering capability at
some level of abstraction appropriate to the type of service
(eg storage, processing, bandwidth, and active user accounts).
Resource usage can be monitored, controlled, and reported,
providing transparency for both the provider and consumer of
the utilized service.
●●
Service models:
–– Cloud Software as a Service (SaaS). The capability provided to
the consumer is to use the provider’s applications running on a
cloud infrastructure. The applications are accessible from various
client devices through a thin client interface such as a web browser
(eg web-based email), or a program interface. The consumer
does not manage or control the underlying cloud infrastructure
including network, servers, operating systems, storage, or even
individual application capabilities, with the possible exception
of limited user-specific application configuration settings.
–– Cloud Platform as a Service (PaaS). The capability provided
to the consumer is to deploy onto the cloud infrastructure
consumer-created or acquired applications created using pro
gramming languages and tools supported by the provider. The
consumer does not manage or control the underlying cloud
infrastructure including network, servers, operating systems,
or storage, but has control over the deployed applications and
possibly application-hosting environment configurations.
–– Cloud Infrastructure as a Service (IaaS). The capability provided
to the consumer is to provision processing, storage, networks,
and other fundamental computing resources where the consumer
is able to deploy and run arbitrary software, which can include
operating systems and applications. The consumer does not
manage or control the underlying cloud infrastructure but has
control over operating systems, storage, deployed applications,
and possibly limited control of select networking components

(eg host firewalls).
●●
Deployment models:
–– Private cloud. The cloud infrastructure is provisioned for exclu
sive use by a single organization comprising multiple consumers
(business units). It may be owned, managed and operated by the
organization, a third party, or some combination of them, and it
may exist on or off premises.
–– Community cloud. The cloud infrastructure is provisioned
for exclusive use by a specific community of consumers from
organizations that have shared concerns (eg mission, security
requirements, policy, and compliance considerations). It may
be owned, managed and operated by one or more of the organi
zations in the community, a third party, or some combination
of them, and it may exist on or off premises.
–– Public cloud. The cloud infrastructure is provisioned for open use
by the general public. It may be owned, managed and operated
by a business, academic, or government organization, or some
combination of them. It exists on the premises of the cloud
provider.
–– Hybrid cloud. The cloud infrastructure is a composition of two
or more distinct cloud infrastructures (private, community or
public) that remain unique entities, but are bound together by
standardized or proprietary technology that enables data and
application portability (eg cloud bursting for load balancing
between clouds) (Mell and Grance, 2011).
The NIST cloud computing reference architecture defines five key

actors: cloud consumer, cloud provider, cloud auditor, cloud broker,
and cloud carrier. Each actor is an entity (a person or an organization)
that participates in a transaction or process and/or performs tasks in
cloud computing:
●●
Cloud consumer – a person or organization that maintains a
business relationship with, and uses service from, cloud providers.
FIGURE 3.1 NIST cloud computing reference architecture
Cloud Cloud provider Cloud

consumer broker
Service orchestration Cloud service
management
Service layer Service
SaaS intermediation
Cloud
PaaS Business
auditor Service
laaS support
Security
Privacy
aggregation
Security Resource abstraction Provisioning Service
audit and control layer configuration arbitrage
Privacy
impact audit Physical resource layer Portability
Hardware interoperability
Performance
Facility
audit
Cloud carrier
Reprinted courtesy of the National Institute of Standards and Technology, US Department of Commerce.
Not copyrightable in the United States.
●●
Cloud provider – a person or organization responsible for making
a service available to cloud consumers.
●●
Cloud auditor – a party that can conduct an independent assessment
of cloud services, information system operations, performance,
and security of the cloud implementation.
●●
Cloud broker – an entity that manages the use, performance, and
delivery of cloud services and negotiates relationships between
cloud providers and cloud consumers.
●●
Cloud carrier – the intermediary that provides connectivity and
transport of cloud services from cloud providers to cloud consumers
(Hogan et al, 2011).
It is useful to understand that the relationships in the cloud computing

domain are different from the traditional B2B.
Essential benefits of cloud computing

Five essential benefits have enabled the global adoption of cloud
computing – no upfront capex investment, freedom of access (from
corporate network or personal device), flexibility to ramp up and
down (from infrastructure to software licences), better security, and

data recovery (cloud providers’ investments in physical and data
security and recovery are unprecedented). It is so much more than
just virtualization. It’s really about utilizing technology ‘as a service’.
We only need to remember that the cloud is not a panacea, it has a
darker side – higher long-term costs (vs in-house capex model), loss
of control, lack of commercial and service flexibility by cloud provid-
ers, total dependence of critical IT assets on internet connection and
bandwidth – which needs to be considered in the corporate cloud
strategy to maximize benefits and mitigate risks.
Clearly, the sum of all advantages outweighs the sum of all fears,
and so Gartner predicts that:
●●
By 2020, anything other than a cloud-only strategy for new IT
initiatives will require justification at more than 30 per cent of
large-enterprise organizations.
●●
Through 2020, 95 per cent of cloud security failures will be the
customer’s fault.
●●
By 2025, 55 per cent of large enterprises will successfully implement
an all-in cloud SaaS strategy (Smith, 2017).
Cloud deployment
An on-premises private cloud will incur an internal data centre cost.
A hosted private cloud will drive the cost of a third-party data centre,
where your IT department rents a wholesale capacity for all the
computing needs of the company. In any case, your IT department
will apportion and cross-charge the respective cost to internal end
users based on a capacity allocation, usage of applications or simply
quantity of personnel. Therefore, if your sourcing project assumes
private cloud deployment, then you need to obtain a respective cost
from your IT department.
A public cloud will drive an external cost: a one-time capex to set
up the hosting environment, and a recurring opex to pay to a hosting
provider, plus a connectivity opex to rent data channels between your
IT hub and an external data centre.
FIGURE 3.2 Types of cloud deployment
PRIVATE COMMUNITY
CLOUD CLOUD
CUSTOMER CUSTOMER CUSTOMER
CUSTOMER
DATA CENTRE SHARED
DATA CENTRE
PUBLIC HYBRID
CLOUD CLOUD
INTERNET
DATA CENTRE
CUSTOMER
CUSTOMER
Naturally, a hybrid cloud generates a mixture of private and public

cloud costs. There is an additional degree of cost complexity for
public clouds:
●●
data location;
●●
redundancy or DR (disaster recovery);
●●
sandboxes.
The domicile of a public cloud needs to be clarified because there

might be some external regulatory or internal IT security guidelines
for hosting specific confidential data (eg customer or employee
records, financial transactions) inside the country of your company
operations. On the contrary, your suppliers might prefer to host
their clouds in the global data centres of Google, Amazon, IBM,
Equinix, etc, where an enormous capacity drives the cost down.
Thus, your requirement for providing local hosting is likely to result
in an extra charge.
Your critical applications may require geographical redundancy, ie

hosting in two different locations, so whenever one data centre or
connecting data channel goes down, there will be a seamless switch
over to another site (DR) with no effect on operations or loss of data.
No doubt an additional DR environment comes at a premium.
A sandbox is a test environment where IT and business end users
will test any new functionality without affecting live operations
(production environment). There might be multiple sandboxes (eg
development, test, pre-production) or at least one – UAT (User
Acceptance Testing). Naturally, sandboxes incur an incremental setup
and hosting cost that you need to clarify as a part of your TCO
model. In case of a private cloud, all this needs to be clarified with the
IT department to calculate TCO increments, if applicable.
To summarize the above, a choice of cloud deployment is the
foundation of your TCO model. Imagine yourself running an airline.
The cloud deployment is like aircraft ownership – leased or owned.
The choice of cloud services discussed later in this chapter is like
‘wet lease’ (an aircraft with crew, maintenance, and insurance) or
‘dry lease’ (just an aircraft itself). Finally, having a fleet of aircraft,
you will be able to develop your business offering and start deliver-
ing traditional or new services.
Cloud services
In simple terms, IaaS provides your company with the infrastructure
so you don’t need to undertake the heavy upfront capex investment
in your own data centre. PaaS works best for software developers, as
they obtain a ready environment to host their bespoke apps. SaaS
suits small and home offices, remote workers, BYOD (Bring Your
Own Device) users and individual consumers. It works well for
massively deployed commoditized apps that don’t require any
customization and are easy to use.
If you have acquired an SaaS service, then your TCO elements
related to cloud deployment and services, and software rental and
support, are clear up front and billed all at once. However, if you
opted for IaaS or PaaS services, then you need to amend the cost of
FIGURE 3.3 Types of cloud services

SaaS
PaaS
IaaS
HOSTED DEV TOOLS, OPERATING SERVERS NETWORKING DATA

APPLICATIONS DATABASE SYSTEM AND AND CENTRE
MANAGEMENT, STORAGE SECURITY PREMISES
ANALYTICS
the software with, for example, PaaS rental fee, or IaaS fee plus
operating system, middleware, and tools.
Typically, software vendors will provide SaaS services in their
private cloud, which, by the way, will be a public one from your
company’s perspective. Otherwise, they will host their software in
your private cloud and charge you a licence rental fee (sometimes
called a ‘subscription fee’) – more detail on that later in the chapter.
US Government best practice for cloud adoption

The highly detailed and constantly updated set of regulations, instruc-
tions and guidelines for US Government agencies preparing to adopt
cloud services is a very useful source of information for technology
procurement professionals.
As per GSA (Government Service Administration), once it is deter-
mined that it appears to be advantageous to migrate to the cloud, an
evaluation needs to be conducted to include:
●●
cost–benefit analysis;
●●
comparative performance analysis; and
●●
metrics established for expected performance advantages.
Contingency, technical and security analyses need to be completed to

determine expectations and scenario planning once the applications
or systems are hosted in the cloud (GSA, 2016).
In 2010, the Federal Government created the ‘Cloud First’ strategy to

encourage its agencies to embrace cloud technologies and their associ-
ated benefits. Recently, in October 2018, this strategy has been
transformed into ‘Cloud Smart’, which focuses on equipping agencies
with the tools needed to make informed technology decisions and lever-
age private sector solutions. To achieve that, the emphasis is on three key
components of IT modernization – security, procurement, and workforce.
Cloud security is a matter of the highest concern for any company
or organization, especially a government administration. The breadth
of questions related to data security in the cloud is overwhelming,
and most of these should be asked by any procurement professional
while preparing a cloud service contract:
●●
Is there a clear statement in the contract for cloud services that all
data is owned by the agency?
●●
Can the cloud provider access or use the agency’s information in
the cloud?
●●
How is the agency’s data handled both at rest and in motion in the
cloud?
●●
Who has access to the agency’s data, both in its live and backup
state?
●●
In the cloud, what geographic boundaries apply to data at rest and
what boundaries are traversed by data in motion?
●●
Where are the cloud servers that will store agency data physically
located?
●●
Can the provider certify where the data is located at any one point
in time?
●●
What is the potential termination liability that would result from
the application of the contract clauses associated with FAR Part 49
Termination of Contracts?
●●
How is the migration of agency data upon contract termination or
completion addressed?
●●
How is agency data destroyed? (Upon request? Periodically?)
What methodology is used (eg remove data pointer or overwritten
in accordance with USG security standards)?
●●
What happens when US Government (USG) data is stored or
transported in non-bannered environments and devices, particularly
if those environments also contain data not belonging to the USG?
●●
What security guidelines apply to operations of various cloud
components and how are they measured for compliance?
●●
Was there an assessment by the agency or cloud provider of how
server and telephony locations may impact access and security of
the data?
●●
Does the cloud provider allow the agency to destroy (truly delete)
all copies or renditions of records from the cloud when appropriate?
●●
If the agreement is for infrastructure as a service, has the agency
considered the kind of record material which may be lost if the
cloud provider were to change?
●●
Did the agency consider if there were special substantive categories
of records, such as vital records, being moved to the cloud for
which increased records management attention is needed? (CIO
Council and Chief Acquisition Officers Council, 2012)
Some of these questions may seem excessive for a commercial

company, but the topics requiring clarification with the cloud service
provider are quite standard – data ownership, access to data, the
geographical location of data, migration or destruction of data upon
contract termination, additional security for vital data.
Cloud Smart strategy actions related to procurement resonate with
many topics in this book:
●●
The General Services Administration Cloud Solutions Category Team
will implement supplier relationship management through active
engagement with industry partners. Key practices for successful
category management include effective supplier–relationship manage-
ment, managing supplier behaviour beyond contract mechanics, and
improved performance. It strives for two-way communication for
proactive engagement to get ahead of supplier issues before they arise
and focus on performance improvement opportunities. This
collaborative process also drives innovation in the federal marketplace.
●●
To ensure that all agencies have an opportunity to collaborate, share
best practices, and apply cloud solutions consistently across the
government, the government-wide Information Technology Category
Manager at the General Services Administration will establish
a government-wide Cloud Solutions Category Team (CSCT). This
interagency team will comprise acquisition and technology professionals
experienced in procuring cloud-based solutions. The team will apply
the principles of category management to develop government-wide
standards and approaches to cloud implementation.
●●
The Cloud Solutions Category Team will evaluate and recommend
a set of government-wide contract vehicles for cloud services based
on a thorough evaluation of each contract. Agencies need access to
qualified contractors through well-managed contracts that have
demonstrated value. Once identified, these solution holders will
collaborate to meet the needs of the government and drive the best
value. Once approved by the Office of Management and Budget
and the Information Technology Category Manager, agencies will
be encouraged to leverage these contracts to meet their cloud
requirements. The wide adoption of these solutions will maximize
the government’s purchasing power, help agencies operate more
efficiently, and expand collection and sharing of government-wide
buying data. Implementation of these solutions will lead to better-
informed business decisions
●●
The Office of Management and Budget and the General Services
Administration will create, or leverage existing cross-government
working groups to identify agency Service-Level Agreements not
addressed by existing commercial industry offerings specific to
unique government requirements. Furthermore, they will standardize
key indicators and create guidance in line with more modern prac-
tices, such as the use of ‘failure budgets’ and cloud architecture
principles so that agencies are more aware of how to design and
measure the resiliency of their services, and other best practices that
are related to cloud management practices.
●●
The Office of Management and Budget will provide direction to
agencies to improve the security and visibility for information
systems and data managed in the cloud, beginning with the
incorporation of requirements set forth in the updated High-Value

Asset policy (Office of Management and Budget, 2018).
There is not much to add here, as all these actions are aligned with
the best practices we are discussing – SRM, category management,
SLAs for the effective contract and performance management, and
the highest attention to cloud security aspects.
Generally, US Government information resources are very useful
to obtain detailed process guidelines for any aspect of technology
procurement. We will use these sources again in further sections to
obtain advice on agile contracting and performance management.
Cloud computing business models

Besides the technology side of cloud computing, we need to under-
stand what drives business value in this market.
The traditional linear value chain for IT services, extending from
consulting, design, implementation, and operation of solutions and
IT infrastructures to the maintenance of the application and ITC
landscape, is changing as a result of cloud computing concepts.
The following changes can be observed:
●●
SaaS vendors are extending their reach beyond software applications
towards service delivery, customer support, and integration.
●●
System integrators are providing value-adding services for service
delivery and support, as well as IT consultancy.
●●
Market leaders are developing some extremely complex business
models:
–– Accenture, being a consultancy powerhouse, is the major player
for IT integration and outsourced service delivery and support;
–– SAP is becoming very active in the integration domain;
–– IBM, Oracle and Microsoft are developing towards the end-to-
end value chain providers.
All these trends need to be considered by technology procurement

professionals, as supplier consolidation opportunities are increasing
and dominant vendors are aggressively pursuing new lines of b usiness.
68
FIGURE 3.4 Cloud computing value chain
Network Infrastructure Service delivery

Application Application System IT
connectivity, and Platform and customer
software management integration consultancy
HW, virtualization hosting support
Telco/ IaaS SaaS

ISP HW/ provider provider
virtua-
lization
vendors PaaS Consultant/System integrator
provider
Modified from ( Jaekel and Luhn, 2010)

The overall business paradigm is shifting towards ‘everything-as-a-

service’, so individual vendors or conglomerates are aiming to provide
a complete service ecosystem.
Another interesting differentiation is between vertical, horizontal
and ‘on top’ SaaS business models.
The horizontal model is the most established, based on the purpose
of an application – CRM (Salesforce), ERP (SAP) or Taleo (recruit-
ment). It aims to serve any given market where there is a need for a
certain functionality. Such companies are very active in marketing, as
they must address multiple markets, sometimes with a set of parallel
messages tailored to each segment of the professional audience.
Vertical SaaS is targeted to a specific industry. This is a more recent
trend in SaaS, so is not as mature as the horizontal market. Examples
could be Swiss AS producing the market-leading airline MRO plat-
form, or GuideWire targeting only the insurance market.
Lastly, the new model identified by industry analysts is ‘on top’ –
industry-neutral software that is made to integrate with existing
solutions. It delivers a distinct functionality leveraging an existing
ecosystem (eg Salesforce) and could be found on their marketplace.
An example of this is Kimble – professional service automation soft-
ware for Salesforce (Erlich, 2019).
Each of these models represents considerable differences in terms
of commercial and operational relationships. Horizontal SaaS compa-
nies are usually mature and heavyweight businesses fitting the
strategic supplier profile. Sometimes they are easier to manage if you
represent the market where they want to gain traction. Their customer
account management and support are quite generic and impersonal,
and they tend to believe that one size fits all.
Vertical model companies are critical (or bottleneck) suppliers due
to their niche applications. They respond better to customer require-
ments but are very hard to negotiate with, as they appreciate their
own unique positioning and competitive advantage.
On-top businesses could be managed via the master platform
OEM, eg Kimble via Salesforce.
The business models of our suppliers represent an important
dimension of the strategic analysis if we see them as our long-term
partners and want to understand their incentives.
Virtualization
Virtualization is one of the fundamental technologies that make
cloud computing work. In enterprise networks, virtualization and
cloud computing are often used together to build a private cloud
infrastructure with the view to optimize hardware investment.
Virtualization software allows one physical server to run several
individual computing environments, ie getting multiple servers for
each physical server you buy. This technology is fundamental to cloud
computing. Cloud providers have large data centres full of servers
but allocating a single server to each customer is not economical.
Thus, they virtually partition the data on the server, enabling each
client to work with a separate ‘virtual’ instance of the same software
(Beckham, 2011).
Virtualization and cloud computing are not interchangeable.
Virtualization is software that makes computing environments inde-
pendent of physical infrastructure, while cloud computing is a service
that delivers shared software and/or data on demand via the internet.
As complementary solutions, organizations can begin by virtualizing
their servers and then moving to cloud computing for even greater
benefits. There are different types of virtualization:
●●
Server virtualization enables multiple operating systems to run on
a single physical server as highly efficient virtual machines.
●●
Network virtualization allows applications to run on a virtual
network as if they were running on a physical network – but with
greater operational benefits and all the hardware independencies
of virtualization (VMWare, 2019).
●●
Application and desktop virtualization allows the IT department
to deploy hundreds of simulated apps and desktops residing on a
central server to remote users instead of having to install them on
each computer. Another instance of desktop virtualization is
running applications for different operating systems on a single
machine (eg MacOS and Windows).
Thanks to virtualization, you can optimize hardware investments

(servers, storage), offer faster provision resources to new users, enable
remote working and seamless rollout of new applications, improve

disaster recovery capabilities, and overall enjoy better flexibility and
agility of the IT infrastructure.
Software development: build or buy?

Let’s assume that your company has subscribed to the PaaS cloud
service. With regards to software applications to host on that plat-
form, you would also have multiple options:
●●
COTS (commercial off-the-shelf software);
●●
third-party software development;
●●
in-house software development.
COTS is what’s readily available in the market and requires nothing

more than moderate customization to your requirements and busi-
ness specifics.
Both software development options assume the creation of a new
application from scratch. The difference will be the cost allocation –
through capitalized external labour or as an internal staff cost (that
could be capitalized as well). Let’s call both options a ‘custom software’.
The ‘build or buy’ argument is endless, and proponents of each
scenario are very convincing. One CEO stated: ‘You shouldn’t build
anything that’s available off the shelf that’s not the source of compet-
itive advantage.’ It makes sense to build if you’re a software company,
or your requirements are unique, or your processes are so rigid that
you cannot adjust them to industry standards used in COTS.
A simple method of deciding between COTS and custom solutions
will be asking yourselves a few basic questions:
●●
How large and flexible is your budget? Naturally, COTS is less
expensive than the custom app, as it is standardized and does not
require much extra effort/cost to implement. Furthermore, custom
solutions involve material risks of delays, technical deviations,
problematic integrations and many more. If your budget is
stretched, do not opt for the bespoke development.
●●
How much time do you have? Just as with the budgetary
considerations discussed above, your time limitations inevitably
lead you to the COTS option. Any custom development poses a
high risk of delay.
●●
Are there any measurable benefits attached to the custom developed
features that were committed to by the business? Your business will
always want to be unique and not follow the mainstream. However,
in that case, it is necessary to justify an extra effort and risk with the
dollar value attached to it. Fluffy ‘nice to have’ arguments do not
work in a competitive and challenging business environment. The
business case for a custom app should have tangible committed
benefits to add to the TCO of bespoke development.
●●
Is the new functionality going to create a unique selling point? If the
required functionality is intended to provide a unique customer
proposition, enhance the brand identity and become a distinct
competitive advantage, then you may opt for the custom development.
In that case, a budget allocated to the task would be sizable and
reasonably flexible, as well as considering timing – usually, companies
are prepared to wait and spend more money, if necessary, to achieve a
killer offer. Plus, you may retain the patent rights for that unique feature.
Lastly, do not fall into the trap of heavily customized COTS. The
required functionality, which is extra to the standard set of features,
should be achieved by reconfiguration and light touches to the code.
Otherwise, you are going to experience the worst of both worlds –
the cost, the risks, the vendor dependency, and the lack of control and
ownership of the final product.
Software development lifecycle

The software development lifecycle (SDLC) provides a generic struc-
ture for custom software projects.
First, all the relevant information is collected from the requestor by
the IT business analysis and project manager to understand the require-
ment and create the SRS (software requirement specification). Then the
SRS document serves an input to the software architecture develop-
ment, which results in the design document. Implementation (coding)
FIGURE 3.5 Software development lifecycle
PLAN
DEPLOY DEFINE
SDLC
...
TEST DESIGN
BUILD
translates software design into the source code. All the components of
the software are implemented in this phase. Once the coding is
complete, the modules are released for testing. Regression testing is
done until the point at which the software fully meets the customer’s
expectations. Then the product has passed the UAT (user acceptance
testing) in the sandbox and is deployed in the production environment.
SDLC models
If you are to source the software development, then you need to compare
project management models, which have three dimensions – budget,
time, and scope. Just like in the old saying, ‘fast, good, cheap – pick
two’, you need to prioritize.
Another difficulty resides in the variety of these models – Waterfall,
V-Shape, Spiral, Incremental, Agile, etc. We will differentiate only a
few that matter most from a procurement perspective.
WATERFALL MODEL
In this model, phases are processed and completed one at a time, and
they do not overlap.
FIGURE 3.6 Project management triangle

BUDGET
QUALITY
TIME SCOPE
FIGURE 3.7 Waterfall model

FEASIBILITY
STUDY
REQUIREMENT
ANALYSIS AND
SPECIFICATION
DESIGN
CODING AND
UNIT TESTING
INTEGRATION
AND SYSTEM
TESTING
MAINTENANCE
The traditional waterfall methodology is a sequential and linear

process characterized by highly detailed specifications and stringent
work plans. The product is delivered to the end user in one ‘big bang’
deployment.
The waterfall model works well for smaller projects where require-
ments are very well understood. This model is not recommended for
large projects for many reasons:
●●
value delivery is deferred until the very end of the project;
●●
new technologies emerging in the course of the project would not
be employed, since they were not planned;
●●
investment risk increases, since long-term, complex projects are
likely to incur delays, cost overruns, and technical issues; furthermore,
the result is only visible when most of the budget has been used;
●●
supplier performance is harder to manage until evaluating the final
effect at the end of a project.
Waterfall is a classical model for procurement since it generates

sequential deliverables, to which you can anchor payment milestones
and sign a fixed scope and time contract.
INCREMENTAL PROCESS MODEL

First, a simple working system with only a few basic features is deliv-
ered to the customer. After that, many successive iterations/versions
are implemented and delivered to the customer until the desired
system is realized.
FIGURE 3.8 Incremental model

C
B
B
A A A
A, B, C are modules of software product that are incrementally devel-

oped and delivered. Each incremental version is usually developed
using an iterative waterfall model. From a procurement perspective,
this model is slightly more complicated, as it means following multi-
ple processes, which are not necessarily consecutive; for example,
iteration A could be the prototype functionality, and iterations B and
C would be parallel developments of it. Nevertheless, deliverables are
staged and usually clear upfront, hence a contract isn’t going to be
over-complicated.
AGILE MODEL
The Agile model is based on iterative and incremental development,
where requirements and solutions evolve through collaboration
between cross-functional teams.
The agile development lifecycle starts with the product vision that
describes at a high level the desired functionality. Then it’s broken
down into functional elements, so the agile team conducts preliminary
planning to determine how many releases of working software will be
required. The result of that planning is called the Product Roadmap.
Each release is delivered in increments (‘sprints’). Upon the comple-
tion of each sprint, there should be a valuable piece of software so the
final release will be achieved through multiple sprints.
The traditional supplier selection approach – lowest price, techni-
cally acceptable solution – is not recommended. The agile delivery
could be fine-tuned by staffing and project management levers, as
well as by smart trade-offs and incentives for timely or on-budget
fulfilment. The aim of the agile project is not to deliver working soft-
ware at the lowest possible cost, but to provide the highest degree of
working software within the constraints of time and budget.
In agile development, requirements are not clear upfront, and the
product roadmap evolves sprint-by-sprint. Therefore, you should not
use the traditional fixed-price and scope contracts, but modular ones
that allow placing short-term (90–180 days) development orders
with one of multiple suppliers.
In order to put the theory of Agile methodology in practice, the
following is a standard contract clause that describes the agile devel-
opment project in practical detail.
FIGURE 3.9 Agile delivery model

DAILY SCRUM
1
DAY
2–4
PLANNING WEEKS
PRODUCT SPRINT SPRINT VALUABLE FINAL

BACKLOG BACKLOG PRODUCT RELEASE
PRODUCT ROADMAP
DESCRIPTION OF THE AGILE PROCESS FROM AN EXISTING

CONTRACT
6. AGILE PROCESS
6.1 For clarity, the parties acknowledge and agree that the Product
Owner:
(a) may as it sees fit, from time to time during the Project Term,
change the priority of the Requirements included in the Product
Backlog and delete Requirements from the Product Backlog;
(b) must follow the Agile Change Control Process if it wishes to
include any new Requirement in the Product Backlog; and
(c) may not amend the number of Resource Points determined for
specific Requirements (but it may dispute any such determination
under the Expert Resolution Procedure).
6.2 The parties acknowledge and agree that the Sprint Points will be
allocated as follows:
(a) not more than [PERCENTAGE]% to the Requirements to be met
during the current Sprint (Sprint Maximum); and
(b) not less than [PERCENTAGE]% to contingency and ongoing
activities, such as attending Sprint Meetings, estimation,
supporting build creation and integrations, possible maintenance
and defect fixes, participation in design activities, status reporting
and development process improvements.
6.3 The parties shall hold a Sprint Planning Meeting before the relevant
Sprint commences.
6.4 At the Sprint Planning Meeting for each Sprint:

(a) the Product Owner shall select Requirements from the Product
Backlog it wishes to be included in the current Sprint;
(b) the Product Owner shall notify the Development Team of the
selected Requirements, their respective Acceptance Criteria, and
other relevant information;
(c) the Development Team shall determine how many of the selected
Requirements can be developed during the current Sprint without
exceeding the Sprint Maximum and notify the Product Owner
accordingly; and
(d) the Product Owner and the Development Team may agree to
replace a higher-priority Requirement with a lower-priority
Requirement bearing equal or fewer Resource Points if it is
technically expedient to do so.
The Product Owner and the Development Team shall use all
6.5
reasonable endeavours to agree on the selection of Requirements to
be included in the current Sprint Backlog.
Once the Requirements to be included in the Sprint Backlog (Sprint
Requirements) have been agreed under Clause 6.5:
(a) no alterations or additions may be made to those Sprint
Requirements;
(b) the Product Owner and the Development Team shall review and, if
necessary, amend the Definition of Done in relation to each Sprint
Requirement; and
(c) the Development Team shall prepare the Sprint Backlog which
shall include:
(i) the Sprint Requirements;
(ii) the Resource Points for each Sprint Requirement;
(iii) the Definition of Done and Acceptance Criteria for each

Sprint Requirement; and
(iv) a breakdown of each Sprint Requirement into specific tasks
and allocation of these tasks to specific Development Team
members.
The Development Team shall maintain the Sprint Backlog and update
6.6
it daily to reflect any changes in the Resource Points for any Sprint
Requirement.
6.7 During each Sprint the Development Team shall:
(a) develop the Software in accordance with the Sprint Backlog and
this agreement; and
(b) hold Daily Scrum Meetings.
6.8 The Development Team and the Scrum Master shall:
(a) use all reasonable endeavours to achieve the Sprint Goal during
the relevant Sprint; and
(b) from time to time review the Resource Points for any Sprint
Requirement and determine whether and, if so, what change in
the Resource Points is appropriate.
Within [five] Business Days of the end of each Sprint, the
6.9
Development Team, Scrum Master and Product Owner shall hold:
(a) a Sprint Review Meeting in conjunction with any Stakeholders that
wish to attend;
(b) a Sprint Retrospective Meeting; and
(c) a Sprint Planning Meeting for the next Sprint.
6.10 At the Sprint Review Meeting:
(a) the Development Team and Scrum Master shall determine which
of the current Sprint’s Results meet their respective Definitions of
Done and notify the Product Owner accordingly; and
(b) the Customer shall determine which of these Results meet their
respective Acceptance Criteria in all material respects in
accordance with the procedure set out in Schedule 4.
6.11 At each Sprint Retrospective Meeting, the Product Owner, Scrum
Master, and the Development Team shall discuss and agree on
potential improvements to their practices, teamwork, environment,
or organization for implementation in future Sprints and review
their appropriateness and efficacy at the next Sprint Retrospective
Meeting.
6.12 The Product Owner shall include in the Product Backlog any Sprint
Requirement that has not been developed during the current Sprint
and any Result that has not been Delivered (both of which shall be
deemed to be an outstanding Requirement) and reset all priorities for
all outstanding Requirements.
6.13 [The Development Team, Scrum Master and Product Owner shall hold
Release Planning Sessions at the times and frequency and in
accordance with the procedure set out in Schedule 5.]
6.14 Subject to Clause 24, the Project Participants shall promptly
commence the next Sprint and Clause 6.1 to Clause 6.14 shall apply
to them as if they were set out in full and each reference to the Sprint
is deemed to refer to the next Sprint.
6.15 Subject to Clause 24, the parties shall repeat the Agile Process and
continue to do so until the end of the Project Term.
6.16 The Project shall be complete once all Requirements in the Product
Backlog have been Delivered and the Product Owner has notified the
Supplier accordingly.
6.17 Within [five] Business Days of the notice given under Clause 6.17, the
Supplier shall provide the Customer with the Deliverables.
6.18 Any Source Code to be provided under this agreement shall be
provided [on CD-ROM, in duplicate, accompanied by a printout on
paper of an index that allows access to each program or sub-program
OR [WAY IN WHICH SOURCE CODE IS TO BE PROVIDED].
6.19 The Supplier shall provide the Customer with the Software Description
for its review and approval in accordance with the procedure set out
in Schedule 6.
7. AGILE CHANGE CONTROL PROCESS
7.1 If the Product Owner requests that a new Requirement be added to
the Product Backlog:
(a) the Development Team shall determine the number of Resource
Points for that Requirement;
(b) the Product Owner may, at its option, then:
(i) remove from the Product Backlog an existing Requirement or

multiple Requirements whose Resource Points or cumulative
Resource Points equal or exceed the Resource Points
determined under Clause 7(a), provided that the Development
Team confirms that the existing Requirement or Requirements
have not already been selected for a Sprint and the proposed
change is technically viable; or:
(ii) request that the Supplier delivers such new Requirement as an
additional Requirement in accordance with the Supplier’s Rates.
WATERFALL VS AGILE
Since Waterfall model is the legacy method, while Agile is its most
powerful rival, these two are usually compared face to face.
Figure 3.10 provides a simple presentation of the critical difference
between Waterfall and Agile – speed of value delivery – which is one
of the most sensible arguments from the financial and business
perspective.
BUY AND BUILD

Even if you opted for the COTS scenario, you might not avoid the soft-
ware development hassle. Usually, COTS provide you with the core
functionality, while some ‘bells and whistles’ desired by your business or
engineers are not there and need to be developed additionally. Then you
will have to follow an incremental SDLC process, where your Module
A is the COTS, and Modules B and C are to fulfil your custom require-
ments and could be delivered using iterative Waterfall or Agile processes.
Software licensing basics

Licences define setting specific terms on which software may be used,
modified, or distributed. Based on the copyright protection, a soft-
ware licence – a set of formal permissions from the copyright
holder – may include specific ‘conditions’ of use, and are an impor-
tant part of the legally binding contract between program author (or
rights owner) and end user (Morin, Urban and Sliz, 2012).
82
FIGURE 3.10 Waterfall vs Agile
Waterfall
Value
created
Plan Define Design Build Test Deploy Run

Agile
Value created
Sprint Sprint Sprint Sprint Sprint

P D Run
1 2 3 4 5
Product to customers
Software licences can be proprietary, open source or hybrid.

Proprietary licences are restrictive and forbid copying, redistribution
and modification. Open source licences grant free, open, and non-
discriminatory access and rights to modify licensed software and
associated source code. Hybrid licences combine the terms of propri-
etary and open, and the right owner decides which one to apply on a
case-by-case basis.
Next, there are different business models for granting the right to
use a proprietary licence – term and perpetual. Term licence means a
limited-time use with periodic renewals that you can also buy in three
forms – licence only, subscription (or rental) and SaaS. We have already
discussed what SaaS is – an all-inclusive blend of the licence, hosting,
and maintenance cost delivered to end users via a web browser. Two
other types of term licences are delivered on-premises, with (licence
only) or without (subscription) support and maintenance.
Perpetual licensing assumes the acquisition of licences as physical
objects. This is when you pay the cost upfront and capitalize it, so an
application lands on your balance sheet and depreciates over 7–10
years. In this case, you own licences, but you also have to buy support
and maintenance and pay close attention to how upgrades and
updates are made to that app (sometimes a major upgrade can result
in a change of firmware or extension of hardware, and is carried out
as a full-fledged deployment project).
It is important to know the financial side of software licensing and service

contracts, because the revenue recognition from the perpetual, term and
SaaS contract happens differently.
The fundamental differentiation by new accounting standards (eg
IFRS15) is the provision of the ‘right to use’ and ‘right to access’.
‘Right to access’ the supplier’s intellectual property (IP) is satisfied over
time because the customer will simultaneously receive and consume the
benefit from the company’s performance of providing access to its IP as the
performance occurs. And so, the revenue will be recognized over time. The
interesting point here is that even if the cash is received upfront, the
revenue will be posted gradually – prorated to the duration of the contract.
The ‘right to use’ the supplier’s IP is satisfied at a point in time. As a

result, revenue is recognized at the point in time at which the licence is
transferred.
Here are some relevant examples:
●●
IP with no standalone functionality (eg a brand) is treated as the right to
access and revenue is recognized ratably over the duration of the
contract period.
●●
IP having standalone functionality and the software is fully usable upon
delivery; right to use and revenue are recognized at the time of delivery.
This is generally applicable to term and perpetual licences.
●●
SaaS agreements in which the customer is granted access to the
software for a period are treated as the right to access and revenue is
recognized ratably over the duration of the contract period.
Software contracts often include other cost elements as part of the

contract, such as support and maintenance, hosting, training, etc.
Companies must identify the separate performance obligations and
recognize revenue appropriately as or when performance obligations are
satisfied. This is not very difficult when a company sells products and
services separately with individual price tags. However, there is a common
practice of bundling software licences with related services into one price.
In this case, the transaction price must be reasonably allocated across the
different performance obligations, and then the different elements of
revenue are recognized at various times (Boatsman, 2018).
For example, implementation and hosting setup services will be
recognized at the time of acceptance. Maintenance and support, as well as
hosting services, will be prorated over the duration of a contract.
Software licensing metrics

To further add to this spaghetti bowl of software licence attributes,
we need to identify chargeable metrics – the number of users or
machines, consumption limits or others.
We propose one of many possible classifications of licence metrics,
which includes seven categories.
User
●●
The number of users/clients/instances, where ‘client’ means device and
‘instance’ means an installation or use of the software.
●●
Named user.
Concurrent
●●
Concurrent users/instances.
●●
Floating users, ie X floating licences for Y users, where X < Y.
User role (guest, general user, power user, admin)
Capacity/hardware
●●
Type of machine (desktop, thin client, physical or virtual server).
●●
Size of machine (cores, processors, sockets).
Consumption
●●
Pay-as-you-go (per use, per transaction or other).
●●
Hard/soft capped (eg up to X transactions during a licence period and
then a hard stop or paying an overage rate).
Company metrics
●●
Employees/transactions/locations.
●●
Revenue (self-declared or from an annual report).
Unlimited
●●
Unlimited everything (ULA – Unlimited Licence Agreement).
●●
Unlimited users/capacity/consumption, where unlimited users are
capped on transactions, and so on.
Unlicensed deployments, licence audits, and SAM

Naturally, having a variety of licensing models and metrics raises a
concern. Vendors created this mess for a reason, this being incremen-
tal revenue generation.
To make you pay extra, many vendors do not hard cap the usage
of their licences to what you have paid for. They say they don’t want
to make it hard for you to acquire new licences every time a new
employee joins or an extra machine is added to the corporate network.
So they suggest you self-declare the actual usage at the end of each
year of a contract, and they bill you for additional licences accord-
ingly (so-called ‘true-up’). The flipside to this ‘trusting’ approach is
that a vendor has the right to audit an actual usage of licences to
reconfirm your declarations and associated billing.
This is where your company is going to pay for the lack of
processes, data and controls. Imagine that you’re using Oracle data-
base licences (capacity-based), Oracle Financials and HR (company
metrics), Microsoft Office (user), Docusign (soft-capped transactions)
and 100 more apps, many of which require you to declare usage. To
do so accurately, you need to have an up-to-date inventory of all
licences for each vendor, all internal change requests for the activa-
tion of additional licences, a hardware inventory, an employee roster
mapped to licence usage, and much more. This information might
not be necessarily available, could be in the wrong order, or frag-
mented between different departments – and then a vendor comes to
audit, discovers deficiencies and raises million-dollar invoices for
‘unlicensed deployments’. In order to avoid penalties, some of them
will upsell excessive new licences or a new solution – for example,
there was a trend to force perpetual licence customers into the cloud,
otherwise threatening them with a licence audit.
Licence overuse is only one of many possible reasons for non-
compliance. Another popular reason is the use of virtualized
environments (eg VMWare). By virtualizing software, you can run
multiple operating systems and multiple applications on one phys-
ical machine and across multiple processors and cores, hence
improving the utilization of a physical machine. However, the
licensing rules differ from one vendor to another, and some of them
may have forced you to license all hardware where virtual machines
(VMs) are running. This is the most expensive scenario, as you
may have different clusters of VMs running different types of soft-
ware on one physical machine. Otherwise, you can be charged per
virtual CPU (vCPU), but then there should be an explicit definition
of that so you do not discover at the time of audit that vCPU =

physical machine.
Let’s take a popular example of Oracle. They only recognize hard
partitioning, ie taking a single large server and separating it into
distinct smaller systems. Each separated system acts as a physically
independent, self-contained server, typically with its own CPUs, oper-
ating system, separate boot area, memory, input/output subsystem,
and network resources. Soft partitioning, which does not do any
physical separation and allocates CPU resources to applications
within the same operating system, ‘is not permitted as a means to
determine or limit the number of software licences required for any
given server or cluster of servers’ (Oracle, 2017).
Interestingly, the industry-leading virtualization technology by
VMWare is not recognized by Oracle due to falling under ‘soft partition-
ing’. Therefore, the chances are high that your company has only used
some part of the physical cores in a server to host vCPUs running Oracle
databases, while it should have been declaring all cores; hence the audit
findings are going to be painful. For example, for a vCPU with six cores
running Oracle Database Enterprise Edition within a cluster of four
servers with eight cores each, the difference between Oracle and VMWare
versions of the licence count and associated annual cost will be:
Oracle: 32 cores × 0.5 processor core factor = 16 processor licences ×

$47,500 list price + 23% support and maintenance = $934,800.
VMWare: six cores × 0.5 processor core factor = three processor
licences × $47,500 list price + 23% support and maintenance =
$175,275 (Couesbot, 2019).
Now imagine the magnitude of a claim across a large enterprise

network with hundreds of processors!
We are not done with Oracle, yet… Many people mistakenly
believe that they do not have to license their disaster recovery systems
running Oracle products. Although Oracle does not require a licence
for a backup file copy of an Oracle Database, a user cannot upload
an Oracle script onto a disaster recovery server without requiring
additional licensing.
Oracle generally allows its customers to test physical copies of
backups for Oracle products on an unlicensed computer for up to
eight testing cycles of two days each per year. If your company tests
the switchover to the DR environment once a month, a DR server
will require the full licensing (Pinson, 2019).
Oracle is not alone in developing highly complicated licensing terms.
Their biggest rivals SAP are also known for enforcing licence non-
compliance findings, eg in the case of indirect access terms violation.
SAP has identified three types of access to use SAP ERP systems:
1 Direct Human Access occurs when humans log on to use the ERP
system and is licensed based on users.
2 Indirect Access occurs when humans or any device or systems
indirectly use the ERP system via a non-SAP intermediary software
between the users and the SAP ERP system, such as a non-SAP
front-end, a custom solution, or a third-party application. Indirect
Access is primarily licensed based on users.
3 SAP Application Access occurs when humans or any device or
systems indirectly use the SAP ERP system via another licensed SAP
application. No additional ERP user licence is required in this respect.
Examples of indirect access given by SAP could be unsurprising and

logical, such as access to ERP in the backend via a third-party front-
end system. But what about when a ‘customer’s employee views a
report (eg financial statements, forecasts, etc) in a non-SAP system,
where such data was retrieved/transmitted from SAP BW’ (SAP,
2018)? In simple terms, this means that if you exported a report in
Excel and sent it to someone in an email, that other person would
have to possess the SAP Named User licence.
Of course, those are non-exhaustive examples of vendor-specific
licensing terms that have to be known and accounted for in the agree-
ment. Generally, to mitigate the risk of licence non-compliance, your
company will need:
a Centralized procurement team for software licences, as this is the

core category (see above). End users being able to buy licences
directly would lead to a total loss of control.
b Corporate policy not allowing any acquisition of licences for end
users outside IT, ie centralized licence management.
c Solid contract with all appropriate terms and definitions understood

and operationalized by IT and Procurement.
d SAM (Software Asset Management) function and IT platform that
monitors:
–– vendors (eg their specific definition of licence metrics);
–– licence use (to adhere to the licence terms);
–– inventories;
–– utilization;
–– configuration/deployment (eg environments – production, test,
QA, where licence terms applied differently);
–– compliance;
–– lifecycle.
SAM will be the closest ally of technology procurement since they

will manage demand, monitor utilization to switch off idle licences
and fight ‘shadow’ software acquired directly by the business, evalu-
ate risks around licence over-deployment, and participate in
negotiations with their niche expertise.
SAM could be the part of technology procurement, the IT vendor
management office or a stand-alone IT function.
US Government best practice of managing software licences

In various sections of this book, we will be referring to US Government
best practice, as they are the world’s biggest spenders in the technol-
ogy category and have therefore developed an extensive and
sophisticated knowledge base that can be useful to analyse and adopt
(at least, in selected parts).
The US Government Accountability Office (GAO) – the state
auditor – conducted an audit of federal software licences and

produced a report, which we will be referring to. They were able to
attract the best industry analysts and advisors to the expert panel to
analyse the findings and instruct agencies on the best practice
approach to managing software licences.
The expert panel defined seven key elements that efficient software
licence policies should contain:
●●
‘identify clear roles, responsibilities, and central oversight authority
within the department for managing enterprise software licence
agreements and commercial software licences;
●●
e stablish a comprehensive inventory (80 per cent of software licence
spending and/or enterprise licences in the department) by identifying
and collecting information about software licence agreements using
automated discovery and inventory tools;
●●
r egularly track and maintain software licences to assist the agency in
implementing decisions throughout the software licence management
lifecycle;
●●
analyse software usage and other data to make cost-effective decisions;
●●
provide training relevant to software licence management;
●●
e stablish the goals and objectives of the software licence management
programme; and
●●
c onsider the software licence management lifecycle phases (ie
requisition, reception, deployment and maintenance, retirement, and
disposal phases) to implement effective decision making and
incorporate existing standards, processes, and metrics’ (GAO, 2014).
The GAO then analysed the current state of software licence manage-
ment in government agencies according to the seven principles above,
and, quite expectedly, many agencies underscored on critical processes
and controls. Here are just a few sample statements for you to digest
and think about in relation to the state of the software licence
management in your company:
‘According to Commerce officials, the department has not developed

comprehensive policies for management of software licences at the
department level. Commerce officials stated individual components are
responsible for managing software licences at the bureau level, but this
responsibility has not been formally documented. In addition, according
to Commerce officials, individual components may have issued relevant
software licence management policies.’
‘Interior’s management of licences is decentralized. Interior officials said

that while the IT programme itself is undergoing some centralization of
duties and responsibilities, this will not include centralized management
of software licences.’
‘EPA does not regularly track and maintain comprehensive inventories

of software licences using automated tools and metrics. Officials
said the Office of Technology and Operations uses spreadsheets to
manually manage enterprise software licences, but the inventory was
incomplete.’
‘While HHS officials stated it has a limited inventory, the department

did not provide supporting documentation of this inventory. In addition,
according to HHS officials, outside of a limited amount of information
on software such as Windows and Microsoft Office, HHS manages its
software licences in a decentralized manner. HHS officials explained that
the department’s operating divisions manage their own needs and HHS
does not have insight into the management of the majority of software
or inventories. However, the department plans to fully staff a vendor
management office to centralize the management of software licences.’
‘HUD has not analysed department-wide data, such as costs, benefits,

usage, and trending data, to inform investment decisions to identify
opportunities to reduce costs. According to HUD officials, the
department’s contractors provide enterprise infrastructure managed
service requirements for supporting HUD’s business and do not
identify specific software licensing requirements. Accordingly, these
officials stated that the department could not associate specific costs
with software licences provided by its contractors since contractors
are providing a service at a fixed price. In addition, while HUD could
provide cost information for software acquired outside of those
contracts, it could not provide any related analysis of software data to
inform its investment decisions.’ (GAO, 2014)
You may observe that suboptimal licence management practices are

not unusual even for highly developed and thoroughly controlled US
Government agencies. It is never too late to start implementing
the suggested best practice and avoid high risks, enormous cost
exposure, and even reputational damage. Technology procurement
should understand the level of risk and potential cost impact and
therefore drive the adoption of licence management practices, and
perhaps consider taking over this responsibility.
Software support and maintenance

First, let us specify the difference between support and maintenance:
support is an ad-hoc reactive work to restore operations, while main-
tenance is a scheduled activity to provide systematic bug fixes,
performance improvements, and new features.
Second, another principal difference is that some elements (levels)
of support could be managed in-house or outsourced, while mainte-
nance is only conducted by an OEM (original equipment manu
facturer). Therefore, we separated the cost of support and maintenance
in the TCO model.
Support
We will differentiate three levels of support:
1 Level 1 (L1): Answering questions on processes and operations via

a dedicated response line and email; this is typically done by the
internal team (power users, process champions, administrators).
2 Level 2 (L2): Restoring service and fixing production problems
with the application. This may include minor modification to
scripts or configuration parameters. L2 is not involved in changes
of the source code; hence it could be outsourced to a partner, not
necessarily an OEM.
3 Level 3 (L3): Focuses on corrective modification through code
changes. This is an essential OEM role, usually performed on a
global scale for all customers.
It is important to account for all levels of support in the appropriate

TCO model that could be the blend of internal (L1), third-party (L2),
and OEM (L3) cost. Sometimes, business cases tend to consider L1
cost only for the first-line technical helpdesk. However, this cost
FIGURE 3.11 Support operational model
L3 OEM global support
L2 Partner maintenance services

(Application services and middleware services)
Business operations team Tech. operations team

• Business process consulting • Improving and implementing business
L1 • Business requirements process improvements
• Streamlining business processes • Ensuring compliance to SLAs
• Master data management • Program mgmt, release mgmt
• Enterprise integration QA
? End user team

• Power users/Administrators
Problem • Internal helpdesk
• New user training
93
could be highly material. Let’s take an e-procurement on-premise

platform that requires:
●●
process and documentation helpdesk for new procurement users
(full P2P cycle) and stakeholders (fragmental cycles, eg PR
creation);
●●
MDM (master data management) resources to maintain databases
of users, suppliers, commodities, stock items;
●●
small configuration updates (fine-tuning workflows, adjusting
approval hierarchies, creating new reports and screen views);
●●
system development (formulating business requirements for new
features and updates, approving HLDs, supporting implementation
from the customer side, performing UAT);
●●
change management and communications.
Altogether, we could be talking dozens of full- and part-time roles

that will sit on the user department payroll instead of adding to the
TCO of the IT platform.
Maintenance
Software maintenance is an integral part of the ITIL Service Lifecycle
(Service Operations). It stands for all the modifications and updates
done after the delivery of software product.
In the software lifetime, type of maintenance may vary based on its
nature. It may be just a routine maintenance task as some bug is
discovered by some user, or it may be a significant event (eg a major
release upgrade). There are four types of maintenance:
●●
Corrective maintenance – fixing problems discovered by users or
identified from error reports.
●●
Adaptive maintenance – keeping the software up to date.
●●
Perfective maintenance – new features, new user requirements for
refining the software and improving its reliability and performance.
●●
Preventive maintenance – attending to problems that are not
significant at the moment but may cause severe issues in the
future.
FIGURE 3.12 Technology building blocks and associated costs
Cloud deployment Cloud service Software applications Support and maintenance
SaaS
Support
PaaS and
Public
cloud COTS maintenance
IaaS
Private Custom
cloud software
Internal IT Internal IT
Middleware Software support and
infrastructure development
cost and OS maintenance
cost
cost
Annual
Extras: Hosting Software support and
Location fee rental free maintenance
DR
cost
Sandboxes
95
Sometimes, perfective maintenance comes at an incremental charge,

if new features and requirements are specific to your company, and
hence need to be custom developed. Your TCO model needs to
account for this cost, as changes to user interfaces, modification of
reports, even branding updates are not considered to be part of stand-
ard maintenance.
Summary view of technological options and associated costs

We prepared Figure 3.12 to summarize the chapter and visualize
the process of technical considerations that affect your TCO. You
will have to follow dotted lines to see functional relations between
technology building blocks and solid lines to identify an associated
cost.
This chapter provided a simple view of what procurement experts
need to know about the technology basics. Without all the above, it
is impossible to negotiate favourable commercial terms consciously,
as most of those depend on cloud deployment and services, licensing
types and metrics, and the operational model of support and mainte-
nance.
References
Beckham, J (2011) Cloud computing vs. virtualization: the differences and benefits
[blog] Cisco, 4 October [online] https://blogs.cisco.com/smallbusiness/cloud-
computing-vs-virtualization-the-differences-and-benefits (archived at https://
perma.cc/SAS4-82R6) [accessed 14 May 2019]
Boatsman, A (2018) New revenue recognition rules particularly impact technology
and software companies [blog] BGW CPA, 3 October [online] https://www.
trustbgw.com/blog/2018/10/03/new-revenue-recognition-rules-software-
technology/ (archived at https://perma.cc/5VED-BZTS) [accessed 14 May 2019]
CIO Council/Chief Acquisition Officers Council (2012) Creating effective cloud
computing contracts for the federal government: best practices for acquiring IT
as a service [online] https://s3.amazonaws.com/sitesusa/wp-content/uploads/
sites/1151/2016/10/cloudbestpractices.pdf (archived at https://perma.cc/
G3KF-RVQU) [accessed 14 May 2019]
Couesbot, E (2019) Using VMWare? Oracle customers hate this licensing pitfall
[blog] Upper Edge, 17 October [online] https://upperedge.com/oracle/using-
vmware-oracle-customers-hate-licensing-pitfall/ (archived at https://perma.cc/
Z7U4-ZQM2) [accessed 8 November 2019]
Erlich, S (2019) What are vertical and horizontal SaaS? [blog] Koombea, 4
February [online] https://www.koombea.com/blog/vertical-horizontal-saas/
(archived at https://perma.cc/V4XL-4U7X) [accessed 14 May 2019]
GAO (2014) Report to the Chairman, Committee on Homeland Security and
Governmental Affairs, U.S. Senate. Federal software licenses: better management
needed to achieve significant savings government-wide, GAO [online] https://
www.gao.gov/assets/670/663560.pdf (archived at https://perma.cc/NE5Z-NKEJ)
GSA (2016) Best business practices for USG cloud adoption [online] https://www.
gsa.gov/cdnstatic/GSACloudBestBusinessPractices.pdf (archived at https://
perma.cc/3AC8-K9DN) [accessed 26 August 2019]
Hogan, M et al (2011) Special Publication 500-291: NIST cloud computing
standards roadmap, NIST [online] https://ws680.nist.gov/publication/get_pdf.
cfm?pub_id=909024 (archived at https://perma.cc/BE94-GRVG) [accessed
14 May 2019]
Jaekel, M and Luhn, A (2010) Cloud computing: business models, value creation
dynamics and advantages for customers, Siemens IT Solutions and Services
[online] https://www.cloud-finder.ch/uploads/media/Siemens_Cloud_
Computing_Whitepaper_PDF_e.pdf (archived at https://perma.cc/XPK8-2YE6)
Mell, P and Grance, T (2011) Special Publication 800-145: The NIST definition of
cloud computing, NIST [online] https://nvlpubs.nist.gov/nistpubs/Legacy/SP/
nistspecialpublication800-145.pdf (archived at https://perma.cc/ELU9-PC49)
Morin, A, Urban, J and Sliz, P (2012) Quick guide to software licensing for the
scientist-programmer, PLoS Computational Biology, 26 July [online] https://
www.ncbi.nlm.nih.gov/pmc/articles/PMC3406002/ (archived at https://perma.
cc/RTJ6-NA5C) [accessed 14 May 2019]
Office of Management and Budget (2018) Federal cloud computing strategy: from
cloud first to cloud smart [online] https://cloud.cio.gov/strategy/ (archived at
https://perma.cc/69EH-ARWG) [accessed 14 May 2019]
Oracle (2017) Oracle partitioning policy, 13 April [online] https://www.oracle.com/
assets/partitioning-070609.pdf (archived at https://perma.cc/5RF2-9J2R)
Pinson, S (2019) Oracle licensing: hard partitioning and disaster recovery [blog]
Scott and Scott, 29 March [online] https://scottandscottllp.com/oracle-licensing-
hard-partitioning-and-disaster-recovery/ (archived at https://perma.cc/
TC7D-WSTH) [accessed 14 May 2019]
SAP (2018) Indirect access guide for SAP installed base customers [online] https://
news.sap.com/wp-content/blogs.dir/1/files/Indirect_Access_Guide_for_SAP_
Installed_Base.pdf (archived at https://perma.cc/FD8Z-2BAK) [accessed 14 May
2019]
Smith, D M (2017) Cloud strategy leadership: Gartner Insights on how and why
leaders must implement cloud computing, Gartner [online] https://www.gartner.
com/imagesrv/books/cloud/cloud_strategy_leadership.pdf (archived at https://
perma.cc/K7ZM-7HBJ) [accessed 14 May 2019]
VMWare (2019) Virtualization [online] https://www.vmware.com/solutions/
virtualization.html (archived at https://perma.cc/8DXK-6ELB) [accessed 14 May
2019]
99
04
Relationship management
in procurement
This chapter is dedicated to nurturing, managing, and sustaining

relationships with our suppliers, internal stakeholders, and the
general public. It is not easy to even decide whom to start with, as all
groups have an equally critical influence on procurement. So, we
flipped a coin and started with our suppliers.
Management of relationships with technology suppliers

It is nearly as important to understand your suppliers as it is to under-
stand underlying technologies. The supply base of the technology
market is extremely complex. On the one hand, it is highly monopo-
lized – Microsoft, Oracle, Google, Salesforce, Cisco, et al have formed
a cohort of ‘mandatory’ suppliers you cannot avoid dealing with. On
the other hand, the competition is enormous for custom solutions to
suit the needs of any business, plus a company may consider develop-
ing its own solution. Procurement will have to navigate through these
complexities to achieve the right mix of suppliers – not so diverse
that it falls out of control, and not so condensed that big guys will
charge you a premium buck for any small need.
Supplier lifecycle management

As we intend to structure our relationships with suppliers, maximize
value, and empower innovation, we need to formulate the cradle-to-
grave process that takes a supplier from stranger to strategic partner.
We will differentiate three stages of the supplier engagement life-

cycle:
●●
engagement (pre-contract);
●●
contract;
●●
SRM (post-contract).
The first experience of our interaction with a supplier is the prequal-

ification when we define if a supplier meets our legal, financial and
business requirements. As a minimum, we would want to know:
●●
specialization (technologies, products, services, partners);
●●
business licence and ownership data;
●●
financial indicators (audited annual statements or specialized
business reports, eg Dunn and Bradstreet);
●●
staffing, professional licensing and qualifications;
●●
insurance and bonding;
●●
customer references.
Prequalification criteria need to be open and fair to avoid ambiguities

and conflicts with unsuccessful suppliers. Successful ones will be regis-
tered in all relevant systems – e-procurement (to participate in sourcing
events), ERP (to enable contract-to-pay cycle), and SRM. It is impor-
tant to give new suppliers regular opportunities to bid, so they maintain
the interest and composure to compete for your account.
Successful bidders will complete the source-to-contract cycle and
pass to the contract stage (negotiations will be extensively covered in
Chapter 5). As a supplier already proven to conform to basic qualifi-
cation requirements, the pre-contract risk assessment stage will
address scope-specific clarifications, eg reference customer calls and
visits, structure of sub-contractors and their risk indemnification,
third-party dependencies.
One important aspect of the supplier experience is onboarding, ie
security checks, entrance permits, office and site facilities. Suboptimal
onboarding processes may result in a lengthy and expensive (for
time-and-material contracts) delay of project implementation and a
damaged relationship with a supplier.
FIGURE 4.1 Supplier engagement lifecycle
Engagement Contract SRM Monitoring Engagement closure
Target state functions
Supplier contract Supplier contract

Supplier engagement Supplier relationship management
management management
• Pre-qualification • Contract negotiations • Segmentation, collaboration, innovation, development • Contract closure

• Registration • Pre-award risk • Supplier risk management, governance • Benefit management
• Source-to-contract assessment • Post-award contract and change request administration
• Onboarding • Performance scorecard monitoring and reporting
• Contract execution
SRM Support
Services Activities • Supplier information management
• Performance analytics support
101
The contract stage includes contract management (control of supplier

contractual obligations and SLAs, scope modifications, validity
extensions, dispute resolution), operational monitoring (eg periodic
progress review meetings), and risk management.
SRM stage of the supplier engagement lifecycle

Supplier relationship management (SRM) is an important element of
procurement’s ambition to be a strategic function. CIPS, in their vision
of the future of Procurement and Supply Management (PSM), stated,
‘PSM experts will focus on connecting end-to-end services and sustain-
ing collaborative relations with the network’ (Alder, Knight and
Meehan, 2018). As we have already discussed the importance of deliv-
ering value-adding services to the business, another important element
of procurement preparedness for Industry 4.0 is relationship manage-
ment – with suppliers, stakeholders, customers, and employees.
SRM particularly focuses on fulfilling the following objectives:
●●
becoming the customer of choice for strategic suppliers;
●●
delivering value through collaboration, innovation and risk
management:
–– additional cost savings through process efficiencies, demand
reduction, and total cost of ownership reduction;
–– estimated revenue growth through speed to market, product
innovation, and new market access;
–– higher asset utilization of through inventory and capital budget
reduction;
–– equity prices are impacted by risk exposure reduction through
mitigating price volatility, supply disruption, and reputational
damage.
●●
sharing growth, benefits, risks and investments through healthy
relationships and strategic alignment (PWC, 2013).
Two-thirds of companies show few signs of SRM development, mainly

due to legacy short-term thinking of savings as the main procurement
deliverable. Many companies find it hard to plan strategically and
RELATIONSHIP MANAGEMENT IN PROCUREMENT 103
implement measures that are not necessarily related to negotiations,

despite a sensible cost and revenue tag attached to SRM activities.
The short- to medium-term target state should expose at least the
following attributes of the moderate maturity of the SRM function:
●●
overall SRM strategy developed, supported by all stakeholders;
●●
generic approach for different supplier segments defined;
●●
SRM through cross-functional teams from Business and Procurement;
●●
key SRM stakeholders have strong competencies supported by
appropriate training;
●●
integrated systems with suppliers for sharing and reporting
information;
●●
critical performance measures developed and periodically reported;
●●
full visibility on relevant risks, approach to mitigate risks developed
internally.
SRM Framework
The SRM Framework comprises three processes: Performance
Management, Risk Management, and Relationship Management.
FIGURE 4.2 SRM Framework
How does Etihad monitor

and develop suppliers
to ensure good service
at the optimum total cost
of ownership?
Supplier How does Etihad mitigate
performance risk with suppliers?
management
Supplier
segmentation
Relationship Supplier risk

management management
How does Etihad build

and sustain relationships
with the most important Supplier segmentation sets strategy for risk,
suppliers? performance and relationship management.
SUPPLIER SEGMENTATION
It is suggested that you start with extracting the database of your
active suppliers, ie, those with at least one purchase order placed in
the last 12–18 months. With this database, you will have to do the
supplier segmentation to determine the extent to which suppliers
contribute to the core competence and competitive advantage of the
buying organization.
Figure 4.3 contains a sample segmentation along with the criteria
for each tier of suppliers. It can be used for relationship, performance
and risk management. For example, strategic suppliers will enjoy
dedicated executive meetings, individual performance scorecards,
and risk registers (or even supplier account managers in the procure-
ment department). Critical suppliers will regularly meet the procure-
ment executives, participate in contract management initiatives and
will be monitored for key risks (eg financial resilience and CSR).
Low-tier suppliers will only be managed in the course of routine
operational interactions and contract administration.
To achieve the proposed segmentation or similar, procurement
needs to apply the following set of selection criteria:
●●
Strategic: is the category/sub-category considered strategically
important to the company?
●●
Potential: does the supplier have the capacity and potential to
grow with the company?
●●
Dependency: is organizational success mutually dependent (is the
company material to the supplier’s own success)?
●●
Commitment: is there a perceived commitment to the company
from the supplier?
●●
Innovation: does the supplier have the potential to contribute to
the company’s innovation agenda and to work collaboratively?
●●
Performance: does the supplier have a proven capability and track
record of good performance with the company?
●●
Market leader: is the supplier recognized as a high performer in the
industry?
●●
Local/preferred: is the supplier locally based? Do they possess any
preferential status – SME, Veteran, Minority, etc?
FIGURE 4.3 Supplier segmentation by tiers
Supplier Attributes
• Critical to core processes; day-to-day operations stop if issues arise

• Highest volume/highest expenditure and complexity (top 1% of suppliers by spend)
• Business goals and strategy of the Company and supplier converge
• Supplier offers potential for the Company to access new markets/opportunities
• The group is a significant customer to the supplier and supplier values the relationship
STRATEGIC • High transitional and replacement costs
eg 20–30 • Supplier has a unique or differentiating product/service/geographical location
suppliers • Long history of relationship
• Major impact on core processes

• High volume/expenditure (top 2–5% of suppliers by spend) with moderate complexity
• High dependence on supplier
CRITICAL • Supplier has significant market power and is a category/commodity/industry leader
eg 50–100 suppliers • Few alternative suppliers with capability
• Cost to switch suppliers would be high
• Quality, reliability and geographical location are key in supplier selection
• Potential to provide competitive advantage
• Failure of supply would cause disruption to the Company

• High to medium spend (top 5–10% of suppliers by spend)
OPERATIONAL
• High to medium dependence on supplier
eg 300–500 suppliers
• Alternative suppliers available, switching costs would be high
• Geographical location likely to be a factor in selection
• Commodity services/materials
• Supplier of products/services has limited impact on day-to-day operations

TRANSACTIONAL • Medium to low spend (all other suppliers with regular or significant call-offs)
eg 5000+ suppliers • There are many alternative suppliers in the market and switching would be relatively
easy for the Company
• Supplier selection driven primarily by price
105
●●
Competitive market: are there competitive market dynamics (is
there a choice in supplier for the company)?
●●
Spend: is there a material level of engagement (spend per annum)?
Supplier segmentation will not address all the complexities of tech-

nology supply base management but it will help you to concentrate
your limited resources and occasional executive attention on the
most meaningful supplier relationships.
SUPPLIER PREFERENCE MODEL

Now, as you’re going to pay closer attention to your Strategic and
Critical suppliers, we advise analysing your company’s place in their
customer account ranking. Depending on the blend of the sales reve-
nue, company profile, and future business outlook, suppliers will
either develop or exploit your account. A simple tool to identify a
supplier’s perception of your company as a customer is the Supplier
Preference Model. Your aim in developing relationships with a
supplier is to move to the Critical or Strategic quadrants of this
model – by consolidating contracts to increase sales revenue, signing
long-term agreements, being willing to introduce new products and
solutions, exercising good payment discipline and so on.
FIGURE 4.4 Supplier preference model
Customer Attractiveness
Core: High
Suppliers Develop: Low revenue with Suppliers
revenue with high attraction
H high attraction
Customer attractiveness
Operational
Transactional
Nuisance: Low Exploitable: High
L revenue with revenue with
low attraction low attraction
L Revenue H
Suppliers Suppliers
SUPPLIER PERFORMANCE MANAGEMENT

Supplier performance management is the set of practices by which
procurement manages the performance of its suppliers to ensure that
agreed service levels are being delivered, issues are flagged and
resolved, and improvement opportunities realized to maximize the
value for the company.
This process is conducted to achieve the following outcomes:
●●
benefits delivered through best-practice procurement methods and
realized through service, quality and price compliance;
●●
improvements in performance and creating opportunities to
increase value within the relationship;
●●
two-way communication channel to allow suppliers to voice issues
and share opportunities and ideas;
●●
closer engagement between procurement and business stakeholders;
●●
consistent approach to measuring and comparing supplier
performance across the business;
●●
consistent, professional approach to the supply market that will
encourage suppliers to invest in relationships with the company.
The supplier performance management process includes the follow-

ing set of activities:
●●
Supplier positioning – a complex view of the supplier by your
company (segmentation) and their view of your account (prefer
encing) along with the performance management approach.
●●
KPIs and governance – metrics, roles and responsibilities, fre
quency and intensity of interactions.
●●
Data collection and analysis – sources of performance data,
standard report, and scorecards.
●●
Performance reviews – participants, minutes, actions, escalations.
●●
Performance improvement plans – systematic actions with measur
able and time-bound outcomes.
A dashboard can be created for reporting overall performance, or

one per key supplier to the leadership. Performance management will
be embedded in the SRM programme and relationship governance.

In the periodic meetings across all levels, it will be a standard item on
the agenda.
SUPPLIER RISK MANAGEMENT

Supplier risk management (SRM) is a set of practices by which
procurement manages its exposure to supplier risk through one-off
or ongoing assessment in agreed areas (CSR, supply chain, financial
viability, etc). In most cases, this is likely to be proactive rather than
reactive through periodic monitoring. The level of resource will be
based on supplier segmentation.
●●
the company is only working with professional organizations that
share its ethics and values;
●●
reduced risk of quality or supply failures impacting the company’s
operations;
●●
reduced risk of reputational damage to the company through legal,
ethical or environmental issues in the supply chain;
●●
long-term, sustainable partnerships;
●●
increased supply market awareness and informed category
planning.
Supplier risk management process includes the following set of

activities:
●●
Supplier positioning – the company’s risk appetite depending on
the supplier segmentation.
●●
Qualify new supplier – an individual risk profile, (non)-acceptance
of immediate risks, remediation plan.
●●
Define monitoring approach – planning of supplier audits/
requalification, roles and responsibilities.
●●
Ongoing risk monitoring – periodic audits/assessments, monitoring
sources of risk information.
●●
Manage and mitigate risks – maintaining risk register and
management plan.
Risk classification and monitoring can be segmented into four classes:

company and CSR, supply chain, financial, and corruption.
RELATIONSHIP MANAGEMENT
Relationship management is the set of practices by which procure-
ment will adopt the right level of engagement to maximize value
from supplier relationships. Although it covers suppliers from
Strategic to Operational, efforts will be focused on suppliers identi-
fied as Strategic and Critical to the business. It will require a
co-ordinated approach across procurement and the business.
●●
resources deployed efficiently to manage the company’s supply base;
●●
opportunity to realize incremental value through improved
collaboration, sharing of information and mutual efficiencies and
commercial opportunities;
●●
locking critical suppliers to the company, reducing the risk of the
company’s dependence on the supplier’s products/services;
●●
improved process efficiency through supply chain integration;
●●
alignment of strategies, goals and plans to enable mutual support
and reduced risk around dependencies;
●●
quality and service improvements;
●●
competitive advantage through access to product innovation,
increased speed to market, supplier investment, and partnering.
Relationship management process includes the following set of
activities:
●●
Supplier positioning – different levels of SRM activities per supplier
segment.
●●
Relationship governance – stakeholder map, roles and respon
sibilities, governance model, high-level goals.
●●
Relationship plan – initiatives and deadlines.
●●
Relationship resourcing – execution teams and SRM programme
management in place.
●●
Progress monitoring and management – periodic progress reviews
and updates to the relationship plan.
It is important to understand the difference between contract and

relationship management. Low-tier supplier relationships will occur
through contract administration and management activities (primar-
ily focused on contracts). Strategic and Critical suppliers will be
subject to relationship management, which is focused on a supplier
itself and goes well beyond the execution of contractual obligations.
Balanced supply base management strategy

The supply base management strategy is intended to find the right
balance between improving cooperation with key suppliers and keep-
ing the competition alive.
Working with top suppliers is a safe bet on quality, performance,
and product development. However, this safety comes at a premium
cost. Furthermore, if you send too much revenue to big players, then
you will not have enough resources to encourage competition and
may end up with a handful of monopolistic suppliers twisting your
arms at their first convenience. Good examples are the ERP providers
for any large company, PSS (Passenger Service Systems) for airlines or
OSS (Operation Support System) for telecom operators. It takes
millions of dollars and a few years to implement these platforms, and
many more millions to maintain and develop them. A switchover
from one system to another is extremely difficult, costly and risky,
and hence, unlikely to happen. These suppliers become monopolistic
and extremely hard to manage – they are rarely satisfied with what
they have and usually dedicate most of their efforts to upselling new
licences and services, forcing adoption of new technologies, and
conducting software licence audits.
Therefore, you should have a balanced strategy for managing your
pool of suppliers. Some of them will have to be treated exclusively to
maintain and improve business-critical relationships, while others
shouldn’t lose interest in bidding for new business. You will also need
to develop local SMBs as a part of your company’s social agenda. For
any competitive procurement process, you will have to give due consid-
eration to the supplier (bidder) list keeping the wider strategy in mind.
The art of balancing that many tasks is the essence of Supplier

Relationship Management. In simple terms, SRM is the differentia-
tion process that recognizes that not all suppliers are the same, and
therefore, not all customer–supplier relationships should be dealt
with through a single strategy. It is also the art of balancing between
powerhouses and their rivals and distributing limited resources in an
optimal way from the risk and reward perspective.
The next thing is to understand business priorities. Are we treating
our suppliers only as cash cows for savings, or do we want them to
advise, innovate, and partner? There should be a mix of strategies for
different tiers, eg a ‘partner and innovate’ approach to Strategic and
Critical suppliers, and ‘cut the cost’ with Operational ones.
SRM requires the involvement of the whole company, from the
executive level down. Meetings, workshops, innovation labs and
global supplier events need to be managed and attended by all rele-
vant stakeholders because your suppliers will not be able to innovate
without Business, plan without Finance and improve without
Technology.
The effective supplier management process must demonstrate the
following attributes to deliver value to both parties:
●●
Clearly defined business aims of the partnership – not just the cost
reduction, as this could discourage a supplier from a long-term
commitment. The partnership could be driven by the innovative
product development and service offering (eg Tesla), premium
products (eg Bang & Olufsen), affordable quality (eg Android
devices), etc. Then a supplier understands its place in your company
value chain and contributes accordingly.
●●
Alignment between Business, Technology, and Procurement – joint
relationship development as opposed to power games and
conflicting agendas.
●●
Fair and consistent SLAs – standard and achievable metrics meant
to encourage performance.
●●
Risk and reward sharing – a supplier should experience both a
carrot and a stick and not only be accused and penalized.
●●
Fact-/data-based performance management – once again, your
judgement of suppliers’ performance needs to be objective, factual
and emotionless.
●●
Openness to feedback – be prepared to hear objective critics from
the other side of the table and take corrective actions.
●●
Regular interaction – SRM should be systematic! Random efforts
do not bring sustainable results.
SRM responsibility within the company

In some companies, the argument is still ongoing regarding the place
and subordination of the SRM function. Business and Technology
departments rightfully indicate that their subject matter expertise is
much more advanced than that of Procurement, and hence they need
to be assessing and managing supplier performance.
Most often, among all company functions, IT departments estab-
lish a VMO – vendor management office – to retain the responsibility
for vendor relationships and performance management. It is not good
or bad for us, just one of the possible organizational models with
some degree of decentralization. However, the company-wide SRM
responsibility should stay with Procurement, as they are the best-
positioned function for driving the programme across all categories
of spend in an unbiased and systematic manner. The IT VMO would
feed their inputs into the corporate SRM.
Figure 4.5 shows an actual example of a RACI prepared by a Big
4 advisory for the newly established IT VMO.
This is where Procurement needs to stay alert to disallow funda-
mental changes undermining their role. You may notice how it was
suggested that Procurement disengage from the Requirements stage.
By doing so, the entire purpose of strategic sourcing was going to be
defeated. In addition to that, the SRM elements of the process were
stripped from any Procurement involvement, making it impossible to
integrate VMO into the wider SRM programme.
It is highly advisable to watch such tendencies for disintegration,
as they could appear from within different initiatives in various
FIGURE 4.5 Example of a RACI matrix for an IT VMO
Engagement Contract Vendor onboarding Monitoring Closing the engagement
Require- Sourcing RFI and Contract Risk Contract Vendor Contract Commercial Performance Contract Benefit
Activities
Supplier
ments strategy RFP negotiation assessment execution governance onboarding review review review (KPIs) closure realization
End user RA
Procure- RA RA A A RA A A
ment
IT VMO C C C C R C RA RA I RA RA C C
Finance I C C C C C C C
Legal R C C R R
PMO I I I I I I I RA
R - Responsible, A – Accountable, C – Consulted, I - Informed
113
company functions. Unfortunately, we cannot set ourselves free from

power games and need to watch the perimeter of procurement
responsibilities, since there might be random or systematic attempts
to rearrange it, but not in our favour.
Stakeholder relationship management

Stakeholders are those who (a) influence, (b) are affected by or (c) are
involved in a particular activity. The default longlist will include the
executive management, internal requestors, other functions in the
value chain (eg Finance), procurement staff, suppliers, internal and
external auditors, and even shareholders, as they are usually concerned
with procurement governance, compliance, and integrity.
We have already covered the supplier relationship management
concepts and techniques; therefore, in this section, we will be looking
primarily inside the company.
Stakeholder management starts with mapping. Procurement
should identify all internal stakeholders and consider the potential
influence and interest of each particular one. Based on these drivers,
procurement should adopt the right level of engagement and commu-
nication with each segment of stakeholders.
First, procurement populates the stakeholder analysis tool, which
provides a summary of the key stakeholder groups who have an
interest, ie in the category plan. Stakeholder’s level of commitment,
change impact, and influence over the change receive scores from 0
(low) to 5 (high), all of which are plotted on the stakeholder map.
The stakeholder map visually compares the stakeholder groups
and assists procurement in designing the stakeholder engagement
approach and assessing its effectiveness.
For each of the segments, procurement creates the engagement
plan that forms the basis of a work contract between procurement
and their stakeholders. The plan summarizes the engagement scope,
objectives, approach, team composition, and provides a framework
for the team activities.
FIGURE 4.6 Stakeholder map
High
Minor blockers Impacted advocated (communication champions)
For this quadrant the project team need to make sure they: For this quadrant the project team need to make sure they:
– Monitor – Fully engage
– Keep communicating and selling the benefits – Manage closely
Moderate
– Only provide minimum effort – Act as champions

– Do not inundate with excessive and unneccessary communication – Are change agents to ‘pull’ others through
– Reward with positive feedback to build morale and motivation
Change impact
Key blockers Advocates

Minimal
For this quadrant the project team need to make sure they: For this quadrant the project team need to make sure they:
– Manage pro-actively and identify actions and next steps – Keep adequately informed
– Sell benefits with a clear vision to create a shared sense of purpose – Communicate often to ensure no major issues eventuate
– Communicate early and often with collaborative approach
– Monitor feedback
Not impacted
– Support through transition with adequate training

– Are involved in risk planning and issue management
– Identify egos, reluctant players and other personnel problems
– Confront those who undercut needed change
Awareness Understanding Benefit recognition Adoption Embedded Internalization
115
The engagement plan must be reviewed regularly by all stakeholders

to ensure it reflects what the team is doing or is going to do in the
future.
Another critical element of stakeholder management is the commu-
nication plan. It sets out to provide a framework of clear and
consistent communications that recognizes the different needs of all
parties with an interest in specific procurement activity. It identifies
the parties to whom information must be delivered, by what means
and provides dates for when key communications will be issued to
the various stakeholder groups.
To summarize all of the above, your stakeholder management
strategy should differentiate segments of stakeholders and ensure
that each segment is sufficiently (but not overwhelmingly) involved in
appropriate stages of the procurement process and receives timely
and purposeful information. In global companies, the responsibility
for stakeholder relationship management is assigned to dedicated
resources – Procurement Business Partners – who facilitate all inter-
actions with individual business units or geographical clusters.
Stakeholder relationship management pursues the following key
aims:
●●
Keep the right level of regular interaction to avoid the loss of sight,
comprehension, and control over internal stakeholders.
●●
Collect early signals from the business on upcoming initiatives,
high-profile projects, and changing concepts and priorities.
●●
Gather and aggregate feedback from internal customers to
maintain continuous performance improvement.
●●
Feed the business with procurement data and information to
facilitate informed and aligned decision making.
●●
Improve the quality of the working relationship by gradually
building confidence and a positive attitude to procurement.
●●
Achieve the desired level of stakeholder satisfaction.
Our mastery of stakeholder management skills is the critical enabler

to the success of the entire procurement function within the company.
Just like in service-oriented businesses, where the customer s atisfaction

prevails above all (despite some customers being hard or even unrea-
sonable), we need to manage the expectations of our stakeholders
and maintain an acceptable level of relationship. Many of them
would not appreciate us for restricting their freedom to buy what and
from whom they want, but we must stay impartial, responsive, and
constructive.
Procurement audit
Auditors are an important part of the stakeholder community, not
only because of their frequent interaction with procurement for
controlling purposes but also because they directly represent the
interests of the shareholders.
With the great power to negotiate and spend money, you assume
a diverse set of responsibilities. You will have to maintain the integ-
rity of the procurement process, eliminate a conflict of interest, buy
sustainably, and enhance the company’s profitability. A promise to
do so is not enough, so expect to be controlled by various parties –
internal auditors (annually or bi-annually depending on the
company audit plan), external auditors (most likely Big Six for
medium to large enterprises) and government auditors for state-
owned enterprises.
ISO defines an audit as a ‘systematic, independent and documented
process for obtaining audit evidence and evaluating it objectively to
determine the extent to which audit criteria are fulfilled’ (Biswas,
2019).
TYPES OF AUDIT
There are many types of audits that could directly or indirectly result
in the full or partial audit of procurement activities (Accounting-
simplified.com, 2010–2013):
●●
External audit, or financial audit, is statutory and involves the
examination of the truth and fairness of financial statements by an
external auditor. This audit is usually conducted in accordance
with the IFRS reporting framework and mandated by law for

companies of a certain size or ownership. This audit is required by
shareholders to control nominated directors running the business.
Once directors report on the financial performance and position of
the company, shareholders require assurance over the accuracy of
the financial statements.
●●
Internal audit, also called an operational audit, is a voluntary
appraisal activity undertaken by an organization to reconfirm the
effectiveness of internal controls, risk management, and governance.
Internal audit is performed by employees of the organization, who
report to the audit committee of the board of directors as opposed
to external audit, which is carried out by hired independent
professionals reporting to the shareholders via audit report. The
scope of work of an internal audit is very broad and can encompass
any matters which can affect the achievement of organizational
objectives.
●●
Public-sector audit. State-owned companies and institutions are
required by law to have their operations examined by a public-
sector auditor. In many countries, public-sector audits are
conducted under the supervision of the auditor general – an insti-
tution for strengthening public-sector accountability and govern-
ance and promoting transparency. Public-sector audit assumes
the examination of the financial affairs of state-owned enter-
prises to ensure they have been operated in the best interest of
the public and in accordance with the requirements on transpar-
ency and good governance (eg public-sector procurement regula-
tions). This audit, therefore, goes a step further than financial
audits of private organizations, which primarily focus on finan-
cial statements.
●●
Tax audits are conducted to assess the accuracy of the tax returns
filed by a company and determine the amount of any over- or
under-assessment of tax liability towards the state tax authorities.
In some countries, companies above a certain size are required to
have tax audits regularly, while in other countries random
companies are selected for tax audits by a balloting system.
●●
Forensic audit involves the auditing and investigation of events that
may result in legal implications, ie fraud investigations involving
the inappropriate use of funds, money laundering, tax evasion and
insider trading, quantification of loss in case of insurance claims,
determination of the profit share of business partners in case of a
dispute, or determination of claims of professional negligence.
●●
Information system audit means the verification of the controls
relevant to the IT infrastructure of an organization. It may be
performed as part of the internal control assessment during the
internal or external audit. This audit usually includes an IT system
audit (assessment of IT system management, its alignment to corporate
management, vision, mission and organizational goals), IT risk
management (measuring, managing and controlling IT-related risks,
thus enhancing the reliability of processes and the entire information
system), and IT due diligence (a comprehensive analysis of the
organization’s IT sector to ascertain its alignment with business goals
and the extent to which it supports other parts of the organization. It
is commonly performed when a potential investor/partner wishes to
gain insight into the level of IT support to business and IT resources).
●●
Environmental and social audits involve the assessment of the
environmental and social footprints that an organization leaves as a
consequence of its economic activities. An increasing number of
companies are providing environmental and sustainability statements
in their annual report, describing the impact of their business activities
on the environment and society and the initiatives taken by them to
reduce any adverse consequences. Environmental auditing provides
assurance on the accuracy of the statements and claims made in such
reports. For example, if a company discloses the level of CO2
emissions in its sustainability report, then an environment auditor
would verify the statement by gathering relevant audit evidence.
●●
Value-for-money audit involves the assessment of the efficiency,
effectiveness, and economy of an organization’s use of resources.
Value-for-money audits are increasingly relevant to charity sectors
and usually performed as part of an internal audit or public-sector
audit.
●●
Construction audit is an analysis of the costs incurred for a specific
construction project. Activities may include an analysis of the
contracts granted to contractors, prices paid, overhead costs
allowed for reimbursement, change orders, and the timeliness of
completion. The intent is to ensure that the costs incurred for a
project were reasonable.
Regular (planned) internal and public-sector audits usually cover the

full procurement process. The external (financial) audit will review
certain aspects assumed in the IFRS framework, eg intangible assets
(IAS38), and property, plant and equipment (IAS16) (PWC, 2019).
The other types of audit could start from their primary scope (eg IT
systems) and lead to certain observations on the procurement process
involved.
PROCUREMENT RISKS
Unfortunately for those working in procurement, it is perceived as a
high-risk area subject to fraud and abuse. Auditors write books about
risks associated with procurement, and we would agree that its vari-
ety, complexity, and potential exposure of the company explains the
constant attention of controlling and executive bodies to our line of
duty. Let’s name just a few potential procurement risks:
●●
Purchase order information may be incorrect – item, quantities, or
other information relating to the order may be incorrectly recorded
on the input document.
●●
Unauthorized purchases may be made – employees may incur the
financial liability of the company for products or services without
appropriate authority to assume such liability.
●●
Procurement systems may be defrauded or abused – employees
may order items for personal use or that are not needed to conduct
business.
●●
Adjustments to vendor accounts may not be properly authorized –
returned goods, changes to orders and other adjustments to the
vendor’s commercial obligations can be made without the proper
supervisory approval.
●●
Goods and services may not be accounted for on a timely basis –
the accounting record keeping could be deferred in the ERP.
●●
Inadequate division of responsibilities between procurement,
supply management, and accounts payable may permit fraud or
abuse of the system.
●●
Duplicate payments for purchases may be made in the absence of
three-way matching controls.
●●
Unauthorized (uncontracted) goods or services may be accepted
by the company and result in financial liability for unwanted items.
●●
The procurement function may not be operated in an efficient,
effective, and economical manner.
●●
The procurement audit trail may be inadequate so that the
department is unable to reconstruct the history of an audited
transaction.
●●
Procurement activity may not deliver value for money to the
company.
●●
Procurement activity may not receive an adequate supervisory
review to ensure its propriety.
In view of the variety of potential risks associated with the procurement

process, audits are necessary to establish a controlled environment for
risk mitigation.
AUDIT PROCESS
In this section, we will provide a brief description of the internal
audit process, as it is the most comprehensive one covering all aspects
of procurement.
Step #1: Scope of audit First, auditors should identify what pro
cesses are going to be audited. Understanding the scope and objec-
tives will help to create an audit schedule. The internal audit should
be conducted based on the risks of the processes. It is also essential to
understand the nature of the business process subject to auditing to
decide the right time to audit the system.
The scope of the audit includes:

●●
establishment of logical and unbiased requirements;
●●
fair evaluation and selection of suppliers;
●●
monitoring of supplier performance and appropriate actions to
rectify deviations;
●●
the efficiency of contract deliverables according to business
requirements and financial assumptions;
●●
the overall presence of mandatory controls;
●●
an independent and impartial review of the existing procurement
capacity with respect to the current and expected volume of
transactions;
●●
procurement best practices and lessons learned and recommended
appropriate and sustainable measures for continuous improvement.
The internal audit programme should consider the following:

●●
input from the audited area and related areas;
●●
key customer-oriented processes;
●●
process and product performance results and expectations;
●●
opportunities for continual improvement;
●●
feedback from customers.
Step #2: Creating an audit schedule Creating an audit schedule

provides departments with advanced notice of the upcoming audit.
The programme will help them to have the necessary documentation
and records available for review and audit and appoint resources
required to support the process. The audit schedule should be shared
in advance to obtain confirmation from the department to be audited.
Step #3: Pre-planning the scheduled audit The procurement

department receives an audit plan that explains:
●●
audit objectives;
●●
the period of auditable transactions;
●●
types of transactions;
●●
limitation of scope;
●●
audit team;
●●
audit methodology, ie proof of compliance with company
procedures and industry standards (ISO 9001, 140001 or other);
●●
rating system that will be used in assessing the level of compliance;
●●
estimated timeline for the completion of the audit;
●●
audit deliverables – the type of reporting to be provided.
All participants of the audit need to be fully aligned as to the scope,

timeline and outcome, as well as everyone’s roles.
It is necessary that the auditor is prepared, with a clear under-
standing of the policies and procedures that will be reviewed. For
example, before auditing a procurement process, the auditor needs to
understand the policies and procedures related and know what kind
of evidence that he/she may review. This will significantly improve
the efficiency of the audit process and will also reduce downtime. For
that purpose, the auditor could conduct a preliminary survey to gain
an understanding of how procurement is governed and executed in
the company.
Step #4: Conducting the audit An internal audit can be conducted

by different methods such as documentation review, interviewing,
data analysis, and sample examination for efficiency and compliance.
Based on the scope and objective of the audit, the auditor shall choose
any methodology or combination of methodologies to carry it out.
The internal auditor shall sight and examine sufficient hard-copy or
electronic records to verify evidence of compliance with the manage-
ment system procedures, and effective implementation of process and
internal control. The audit must be conducted in a fair and unbiased
manner.
Step #5: Record the findings Recording the findings is vital in the
audit process, and the auditor needs to list all the evidence by record
number or record data. The aim of documenting audit findings is to
identify gaps in compliance and look at opportunities to close gaps

and improve the process. Records may also include observations and
notes from the interview process. It is recommended that the auditor
provide a quick snapshot of the findings at the end of the internal
audit to ensure the auditee is aware and also has a chance to respond
with their own interpretation and opinion.
Step #6: Report findings All findings should be provided in an easy-

to-read audit report, which serves as a piece of evidence that an internal
audit was conducted. Such a report should be reviewed and approved
by the department management and audit committee. The report can
also include an improvement/corrective action plan that should be
developed and implemented in the areas where gaps were identified.
SUMMARY OF TYPICAL AUDIT FINDINGS FROM ACTUAL REPORTS
●●
The Procurement Manual should include the following documents:
–– annual Procurement Plan preparation in connection to the approved
budget;
–– separate processes for single source, RFx, and action sourcing;
–– process for RFx or action cancellation;
–– process for negotiations, with relevant supporting documentation;
–– supplier classification procedure (upon registration);
–– supplier prequalification procedure;
–– process for handling supplier communication (during and after RFx).
●●
Any amendment to the Procurement Manual should be approved by the
Board of Directors, not Head of Procurement.
●●
Conflict of Interest declaration should be signed by all approvers in the
procurement process, including C-level.
●●
No mandatory spend allocation or KPI for national SMBs.
●●
Head of Procurement chairing the Tender Committee, which contradicts
the concept of the segregation of duties.
●●
Instances of a signed contract in the absence of a business case approval
and budget allocation.
●●
Instances of services commenced prior to contract signature.
●●
Suppliers have not been prequalified prior to the RFx invitation.
●●
RFx evaluation criteria prepared after the submission of bids.
●●
Instances of direct contacts between business end users and suppliers
during the RFx, in the absence of procurement participation.
●●
High-value contract without any SLAs.
●●
Missing documentation on supplier negotiations.
●●
No evidence of supplier performance evaluation for high-value
contracts.
●●
Instances of procurement process handled outside the e-procurement
platform by end-user departments.
●●
Terminated employees still have access to ERP.
Some readers will recognize many of these typical points. It is very useful to
have these highlighted and escalated to the attention of relevant executives
and feed them into the continuous improvement cycle of the procurement
department.
The ISO recommends using the PDCA (Plan, Do, Check, Act) change
management tool (Deming cycle) to facilitate and carry the improve-
ment process within the business. This approach is somewhat similar to
the Agile methodology. The changes could be implemented incremen-
tally and tested in the controlled environment during the ‘Check’ stage,
as opposed to the usual big-bang company-wide implementation.
COLLECTIVE RESPONSIBILITY AND THE BENEFITS OF PROCUREMENT AUDIT

Any action taken in the course of the procurement process by any
stakeholder needs to be documented and justified. Any member of
the cross-functional team needs to bear in mind a responsibility to
explain their own or collective actions to the auditors, and so avoid
the temptation to shortcut or bypass some required controls, even in
the interest of time, efficiency or business logic. Any deviation from
the standard process needs to be documented and approved. It is no
longer solely a procurement responsibility, but a reflection of the ‘one

team’ approach to jointly follow corporate governance.
Bear in mind that the compromised procurement process may lead
to potential financial and reputational damages that would overrun
any immediate efficiency gain you might have been thinking to
achieve. Eventually, you might have jumped a red light and made it
on time without damaging anyone, but would that explanation be
enough for the traffic police?
Audits are not just a necessary evil made for you to obey and suffer.
Their findings provide a unique perspective on the conventional
processes you used to run without much thought. Audits will help
you to discover deviations and inefficiencies, maintain the discipline
and composure of the entire cross-functional team and protect you
from executive bullies forcing you into trouble by leapfrogging
mandatory controls.
The benefits of procurement audits are multiple and must be used
as an important tool of strategic planning and execution:
Alignment with the business: internal audit can ensure that all teams
adhere to corporate governance. Once the company rules assume
the involvement of procurement in the management of categories,
then business stakeholders will reserve a seat at the table for
procurement members and work with them. This will help you to
cooperate with difficult stakeholders, who tend to usurp category
management.
Catalyst for change: one of the responsibilities of the internal audit is
to ensure the effectiveness of processes or initiatives. If procurement
finds opportunities for improvement, they can team up with
internal audit to make sure the improvement is implemented.
Likewise, internal audit can advise on improvements to procurement
and support their implementation. Procurement should align their
objectives with internal audit to follow a common agenda.
Process unification: business functions tend to develop their own
processes that over a period gain their category- or function-
specific flavour, making each department’s process ‘special and
unique’. You may have experienced constant requests from some

departments for special treatment, eg because they are customer
facing and don’t have time to follow standard processes.
Governance that drives accountability: as the eyes and ears of the
management, internal audit has a strong responsibility for
capturing an accurate and comprehensive view of all activities.
Procurement reports on process deficiencies, lack of governance,
and eroding benefits could trigger internal audit actions and return
deviating business stakeholders back into the governance haven.
Executive recognition: remember that internal audit reports to the
Audit Committee, which is subordinated to the Board of Directors.
Top executives of the company could not be more interested in the
constant improvement of controls, increasing efficiencies, and
additional benefits. Your cooperation with the internal audit can
see your efforts recognized at the highest company ranks and
attract executive support.
Finally, let us discuss one of the most important aspects of the entire
procurement profession. We possess various skills, techniques, and
experiences across multiple areas of business. However, we are not
niche subject matter experts or custodians of sacred knowledge,
which makes us unique and indispensable to the company. We are
known for transparency, famous for exercising unbiased attitudes to
all partners – external and internal – and respected for integrity. Do
not let these traits become compromised even under executive pres-
sure, as you won’t have much more to offer to the business. One
black spot on your professional life could mean as much as a long list
of deceased patients for a surgeon.
On the other hand, you need to find a balance between governance
and business facilitation. Raising hurdles to revenue generation,
customer service, or brand development defeats the entire purpose of
the existence of procurement as a support function. This is where
your true professionalism is going to be exposed – to help the busi-
ness and not to compromise the integrity of your job. No specific
prescription exists to help you do so, other than:
●●
becoming a governance and compliance guru, knowing the variety
of options and tools in your possession, and applying those smartly
and selectively;
●●
collecting practical references to be able to apply the ‘case law’
approach;
●●
consulting internal audit at times of deliberation to seek guidance;
●●
applying for executive support for decisions that are ‘above your
paygrade’;
●●
continuously improving existing processes based on the practical
experience of discovered inefficiencies;
●●
and always leaving a document trail to ensure the transparency
and auditability of your actions!
Relationship management in negotiations

We decided to segregate this topic from the supplier selection stage of
the procurement process, as it is more complex and diverse than just
a commercial negotiation with a preferred supplier. In fact, you will
have to negotiate much harder internally during the second step of
the strategic procurement process, ‘Identify business needs and study
the market’ (see Chapter 5). As soon as you start to eliminate waste-
ful demand, your interest may be at odds with those of powerful
internal stakeholders, who don’t like to be told that their require-
ments could be faulty, excessive or untimely. Would you bet on
yourself in the power game with the CIO? Let’s see how to increase
your chances.
Transactional analysis
We will require some theory to understand what drives our social
interactions with people, and we suggest employing the transactional
analysis of Dr Eric Berne.
The unit of social intercourse is called a transaction. If two or more

people encounter each other… sooner or later one of them will speak or
give some other indication of acknowledging the presence of the others.

(Berne, 1961)
In addition to the analysis of interactions between individuals, trans-

actional analysis also involves the identification of the ego states
behind every transaction. Berne defined an ego state as ‘a consistent
pattern of feeling and experience directly related to a corresponding
consistent pattern of behaviour’ (Berne, 1961) and differentiated
three of these – Parent, Adult, and Child.
Parent represents autocracy, dogmas, codes and rules. Adult is the
voice of our experience, common logic and immediate personality.
Child represents emotions, free will, curiosity and adapted behaviour.
Transactional analysis involves identifying which ego state directed
the stimulus (acknowledgement of the presence of another person)
and which one responded. According to Dr. Berne, the simplest trans-
actions are between Adult ego states (ericberne.com, 2019).
Theory and practice of negotiations

Whether a negotiation concerns a contract, a family quarrel, or a
peace settlement among nations, people routinely engage in positional
bargaining. Each side takes a position, argues for it, and makes
concessions to reach a compromise. (Fisher and Uri, 1981)
There are two types of positional bargaining – soft and hard:

●●
Soft:
–– friendly;
–– the goal is agreement;
–– make concessions to cultivate the relationship;
–– be soft on the people and the problem;
–– trust others;
–– change your position easily;
–– make offers;
–– disclose your bottom line;
–– accept one-sided losses to reach an agreement;
–– try to avoid a contest of will;

–– yield to pressure.
●●
Hard:
–– participants are adversaries;
–– the goal is a victory;
–– demand concessions;
–– be hard on the problem and the people;
–– distrust others;
–– make threats;
–– mislead as to your bottom line;
–– insist on your position;
–– try to win a contest of will;
–– apply pressure.
Fisher and Uri proposed an alternative to both types of positional

bargaining – the principled negotiation, which is defined by four
points:
People: separate the people from the problem.

Interests: focus on interests, not positions.
Options: generate a variety of possibilities before deciding what
to do.
Criteria: insist that the result be based on some objective standard.
This is where transactional analysis comes in handy to compare all

three methods. Hard bargaining represents the style of the Parent, soft
bargaining, the Child, and principled negotiation fits the Adult style.
According to Berne’s theory, effective transaction (and negotia-
tion) must be complementary, ie completing a transit from the
receiving ego state back to the sending ego state. In that respect, we
have only a handful of possible combinations enabling effective nego-
tiation (usually Adult–Adult, Parent–Child, and Child–Parent).
Hard-bargaining Parents on both sides of the table will create a
contest of will and power. Soft-bargaining Children may not be able
to reach an agreement, as both are prepared to bend under pressure,

but are not proficient in offering solutions. Parent–Child negotiation
may end with the total domination of one party and a one-sided
agreement, which might be good for your company only if you play
the Parent. However, this does not happen often, other than in nego-
tiations with small suppliers. Surely Procurement won’t be able to
play the Parent in internal negotiations with Business or IT.
Therefore, in your best scenario, you need to achieve the situation
of principled negotiations between two Adults. This is the normal
state in supplier negotiations, where you need to control yourself to
not fall into the Parent state. You will then negotiate with logic, argu-
ments, goodwill, and respect for the other party, meaning you are
very likely to succeed and build a useful partnership.
Let’s look at another typical situation, where you negotiate with a
Parent – a powerful internal executive or a monopolistic supplier.
The theory suggests that negotiators will focus on sending a
message from the Adult to the Parent and maintaining complemen-
tary transactions. If negotiators receive a reply from the non-expected
ego state they can try to shift the other person’s ego state by inviting
people to move into a different ego state or by acknowledging their
current ego state using the appropriate message or response and then
invite them into another ego state with words and body language. If
negotiators cannot do this, it may be better to stop communication
and try again another time when the person may be in a different ego
state.
Negotiators use the Adult ego state to think about what behaviour
is appropriate. The Adult ego state has the capacity to control the
two sides’ ego states (Zhang and Constantinovits, 2018). In practice,
this means that you need to observe the ego state of your counter-
part, so she or he does not turn into, for example, an uncontrolled
offended Child, and maintain the Adult style of negotiations – imper-
sonal, objective, constructive and loaded with arguments. The key to
success is the ability to understand the true interest of another party
and convert it to the Adult state.
A sales manager of a monopolistic supplier (eg Microsoft or SAP)
wants to grow your account to demonstrate dynamics and meet sales
quotas, book more revenue upfront, showcase new products, receive

publicity through press releases and events, and acquire new custom-
ers. You can help to achieve most of that by entering into longer-term
contracts, being open to the adoption of new products, working with
your executives and PR department to attend supplier or industry
events, arranging a contract signing ceremony, suggesting your
company for reference calls and arranging site visits of prospective
customers. So, you may become useful in fulfilling the supplier’s
agenda and gradually improving relationships.
Your CIO wants reliable and manageable operations, respect,
independence, trust in her/his professional abilities, recognition of
the industry, high-profile relationships with global suppliers, new
knowledge, and best practice sharing. Give her/him solid and reliable
procurement SLAs with Platinum service level for personal e scalations,
help manage supplier performance, share useful data from procure-
ment systems and sources, negotiate free trainings, ensure OEM
certification for engineers, release IT resources from clerical duties
(eg by introducing standard contract templates that will not require
IT stakeholders to contribute to the contract drafting), help to close
off internal audit findings – and your profile will slowly but steadily
gain trust, support, and the respect of the CIO.
Difficult negotiations may not be successful in the first round, but
with a strategy and execution plan, you will prevail in the face of the
most complex opponents.
Corporate social responsibility and relationships with

community
Every purchase has not only economic but environmental and social
impact. Therefore, procurement is expected to contribute to the local
economy and community development, driving the specific relation-
ship agenda. As individuals are already taking conscious decisions to
buy sustainable and ethical products, they expect companies to oper-
ate with a similar mindset.
First, let’s characterize the expectations of procurement – it is
perceived to support community values and build its capital:
●●
economic – community budget;
●●
physical – natural resources and assets;
●●
human – education and training;
●●
social – families and public institutions;
●●
cultural – heritage and personal values.
Corporate social responsibility assumes that helping the community

will multiply its capital, to which procurement can contribute through:
●●
job creation by supporting local crafts, industries (SMBs) and
innovation;
●●
establishing healthy and prosperous work environment for its
workers;
●●
adopting sustainable and ethical buying standards;
●●
running social programmes (eg supporting people in need);
●●
contributing to education, eg through internship opportunities;
●●
promoting cultural standards at work, eg diversity.
Essentially, procurement is expected to add the social element into

the value chain and select suppliers based on price, quality and social
value.
The expectations of society with regards to the procurement social
agenda have been summarized in Canadian Prime Minister Trudeau’s
Mandate letter to his Minister of Public Service and Procurement:
Modernize procurement practices so that they are simpler, less

administratively burdensome, deploy modern comptrollership,
encourage greater competition, and include practices that support our
economic policy goals, including innovation, as well as green and social
procurement. This includes:
●●
developing initiatives to increase the diversity of bidders on government
contracts, in particular businesses owned or led by Canadians from
underrepresented groups, such as women, Indigenous Peoples, persons
with disabilities, and visible minorities, and take measures to increase
the accessibility of the procurement system to such groups while working
to increase the capacity of these groups to participate in the system;
●●
developing better vendor management tools to ensure the Government
is able to hold contractors accountable for poor performance or
unacceptable behaviour, particularly in large-scale procurements;
●●
publishing clear metrics to measure government performance on the
competitiveness, cost, and timeliness of procurements;
●●
making government data more readily available to vendors to encour
age more and better bids; and
●●
ensuring prompt payment of contractors and sub-contractors who do
business with your department. (Trudeau, 2017)
How can procurement implement a social agenda in its daily opera-

tions? A few working examples could be:
●●
implement preferential scoring in vendor evaluations to distinguish
local SMBs;
●●
include social agenda into your SRM policy, eg by encouraging
your strategic vendors to provide sub-contracting opportunities to
local companies;
●●
run social support and disaster relief programmes, eg by distributing
slow-moving inventories;
●●
establish innovation challenges for local SMBs and youth and
source the best products/solutions under a simplified procurement
process;
●●
provide internship and graduate training opportunities to partner
education facilities.
The persistence of your company to drive the social agenda will

determine the success of its relationships with the local community. It
is necessary to treat the community as a critical stakeholder and
manage relationships in a structured way – through an engagement
plan, regular interactions, and bilateral communication. Eventually,
effective and positive relationships with the community will largely
contribute to the success of the company in general.
Conflict resolution
Some of the interactions with various procurement stakeholders
described above could result in a conflict. We provide here a brief
intro to the conflict management theory by K W Thomas and Ralph
Kilmann, famous researchers of the subject.
As opposed to treating conflict as fighting, a more useful definition
of conflict is the condition in which people’s concerns appear to be
incompatible. In an organization, people’s concerns might centre on
such things as deciding how to allocate resources, determining what
facts bear on an issue, and supporting different strategies.
When people find themselves in conflict, their behaviour can be
described in terms of where it lies along two independent dimen-
sions – assertiveness and cooperativeness. Assertiveness is the degree
to which you try to satisfy your own concerns, and cooperativeness
is the degree to which you try to satisfy the other person’s concerns.
Thomas and Kilmann define five conflict-handling modes:
1 Competing is assertive and uncooperative. You fight to win a

conflict.
2 Accommodating is unassertive and cooperative. As opposed to the
competing mode, you are prepared to sacrifice your stand to
resolve the conflict.
3 Compromising is partially assertive and partially cooperative. This
mode assumes that you are looking for a resolution that only
partially satisfies yourself and an opponent.
4 Avoiding is unassertive and uncooperative. You try to escape
conflict without resolving it.
5 Collaborating is assertive and cooperative. You try to problem-
solve to find a solution that completely satisfies both your concerns
and those of the other.
Quite expectedly, the best decisions appear to result from the collabo-
rating mode. It is not the easiest, but it is the most effective style of
resolving essential conflicts. Thomas and Kilmann then explain the
notion of positions, which resonates with the positional bargaining style
of negotiation by Fisher and Uri, as discussed earlier in this chapter:
Concerns are the things people care about in a conflict – what they are
trying to satisfy. In contrast, the positions people take are the solutions
they recommend as a way of satisfying their concern (‘what we should
do’)… When collaborating, then, it is important to begin by identifying
underlying concerns rather than ‘jumping to positions’. (Thomas, 2017)
So, the principled negotiations approach seems to fit well conflict

resolution. Let’s recall four postulates of principled negotiations with
slight adjustments to the subject of a conflict:
People: separate the people from the conflict.

Concerns: focus on concerns, not positions.
Options: generate a variety of possibilities before deciding what
to do.
Criteria: insist that the result be based on some objective standard.
Thomas made an important statement that strongly supports the first

point (People):
Personality conflicts have strong negative consequences in organizations

and should be avoided. Conflicts become personalized when people
focus their energy and attention on what is wrong with each other
rather than on substantive conflict issues… Thus it is important to learn
to avoid discussions of personality and blame… and keep the discussion
focused on substantive issues.
Once again, we can refer to the theory of transactional analysis.

While in conflict, you need to maintain complementary transactions
and attempt to stay in the Adult ego state, which should allow you to
stay firm, objective, and collaborating.
The CIPS vision of the future of our profession defines the role of
procurement as strategizing and collaboration within the network
(common ecosystem) of interconnected organizations, with an
emphasis on relationship work (Alder, Knight and Meehan, 2018).
You need to understand the complexity of procurement relation-
ships, which is not only limited to suppliers. Naturally, we must manage
the expectation of internal stakeholders, executive m anagement,
shareholders, diverse controlling bodies, society, and customers. We

have diverse agendas to pursue and a hefty burden of responsibilities
to fulfil.
Start preparing yourselves for the future, where procurement rela-
tionships with multiple segments of internal and external stakeholders
will constitute a unique asset justifying the very existence of the
profession.
References
Accounting-simplified.com (nd) Types of audit engagements [blog] Accounting-
simplified.com [online] https://accounting-simplified.com/audit/introduction/
types-of-audits.html (archived at https://perma.cc/88LW-4KYK) [accessed
15 May 2019]
Alder, H, Knight, L and Meehan, J (2018) The future of procurement and supply
management, CIPS [online] https://www.cips.org/en-me/knowledge/
procurement-topics-and-skills/innovation-and-technology-/future-of-
procurement–supply-chain/ (archived at https://perma.cc/TA3V-EVAV) [accessed
12 May 2019]
Berne, E (1961) Transactional Analysis in Psychotherapy, Random Books,
New York
Biswas, P (2019) Terms related to Audit in QMS [blog] APB Consultant [online]
http://isoconsultantpune.com/iso-90012008-quality-management-system/
iso-90002005/terms-related-to-audit-in-qms/ (archived at https://perma.
cc/6MU3-TKV3) [accessed 15 May 2019]
Ericberne.com (nd) Transactional Analysis [blog] [online] http://www.ericberne.
com/transactional-analysis/ (archived at https://perma.cc/2EGD-V7WB)
Fisher, R and Uri, W (1981) Getting to Yes: Negotiating an agreement without
giving in, Houghton Mifflin Company, New York
PWC (2013) Supplier relationship management: how key suppliers drive your
company’s competitive advantage [online] https://www.pwc.nl/nl/assets/
documents/pwc-supplier-relationship-management.pdf (archived at https://
perma.cc/TVA3-LXWY) [accessed 15 May 2019]
PWC (2019) IFRS Overview 2019 [online] https://www.pwc.com/gx/en/audit-
services/ifrs/publications/ifrs-19/pwc-ifrs–overview-2019.pdf (archived at
https://perma.cc/WX9T-SKUK) [accessed 15 May 2019]
Thomas, K W (2017) Making conflict management a strategic advantage,

Psychometrics, February [online] https://www.psychometrics.com/wp-content/
uploads/2017/02/Conflict-Whitepaper.pdf (archived at https://perma.cc/
XD9R-ZHP4) [accessed 15 May 2019]
Trudeau, J (2017) Minister of Public Services and Procurement Mandate Letter, 4
October [online] https://pm.gc.ca/eng/minister-public-services-and-procurement-
mandate-letter (archived at https://perma.cc/JF5V-P5JH) [accessed 15 May
2019]
Zhang S and Constantinovits, M (2018) Development of a conceptual model and
questionnaire of principled negotiation, Business Communication Research and
Practice, 1 July [online] https://www.e-bcrp.org/archive/view_article?pid=
bcrp-1-2-70 (archived at https://perma.cc/C4HP-SPXS) [accessed 15 May 2019]
139
05
Deep dive into the

procurement process
Having laid all the appropriate technology foundations and consider-

ing the supply base management strategy, we can fully dedicate
ourselves to studying the procurement process. We will dive deep into
each of the seven steps outlined in Chapter 2 and refer to the mapping
provided for critical roles and artefacts.
Step 1: Initiate a sourcing project

In this stage, the scope and timeline of the project require assessment.
Procurement (PROC), Business (BUS), Finance (FIN), Technology
(TECH) and Project Management (PM) representatives will form a
cross-functional team. The PM member could come from the Business,
Technology, or PMO office, but we will mark her/him as a separate
function.
In the corresponding Project Initiation stage (Project Management
Lifecycle), the PM will start creating the Project Charter and Stakeholder
Register, which will form the basis for sub-processes 1.1 and 1.2.
Step 2: Identify business needs and study the market

Technology takes the leading role in this stage by conducting Service
Strategy (ITIL Service Lifecycle) processes, of which two of the most
important are Demand Management and Financial Management.
FIGURE 5.1 Step 1: Initiate a sourcing project
1.2. Identify internal

1.1. Define project
stakeholders and
scope and develop
sources of
project plan (PM)
information (PM)
Demand Management objectives are to understand, anticipate, and

influence customer demand. In this process, the strategic sourcing
approach demonstrates its true powers. Procurement will comple-
ment the Technology team with its expertise – the market knowledge,
contract and supplier information, experience from other sourcing
projects, and a cost-conscious mindset. The outcome is the separation
of value demand – that exactly meets customer needs – from four
wasteful demand types:
●●
Failure demand – caused by an earlier failure to deliver the required
service or by poor service design in general. Example: the master
IT project is delayed, and so related third-party resource contracts
(eg integration, change management) keep on being extended
indefinitely.
●●
Excess demand – caused by inappropriate or missing controls.
Example: it is common practice to spend the remainder of an annual
budget before the year end – so as not to leave unused funds – for
next year requirements, nice-to-have things or simply anything.
●●
Preventable demand – could be influenced or prevented from
occurring. Example: colour printouts driving the pay-per-page or
cartridge cost, which could be partially avoided by default black-
and-white print settings.
●●
Avoidable demand – caused by wrong behaviours or false
expectations. Example: managers are requesting full entitlement to
IT equipment just because their grade allows them to.
DEEP DIVE INTO THE PROCUREMENT PROCESS 141
The elimination of waste should be achieved by analysing its root

causes, changing behaviours, adjusting policies, and working across
functions and systems (Randle and Kippin, 2014).
We encountered a case of a company mobile communication policy
that allowed the overrunning of individual quotas, lacked spend
controls, and released executive grades from any limitations of usage
and cost. Once the Internal Audit identified the stack of problems,
they developed a new policy in collaboration with Finance and HR,
with hard caps per grade, cost controls (eg any excessive usage
charged to a departmental budget instead of IT), and disciplinary
measures. The IT department, together with the mobile operator,
implemented a web portal for granular cost visibility. Procurement
negotiated a new contract with one bucket of voice and data for the
company, as opposed to previous individual quotas. This team effort
allowed a reduction of addressable spend by 40 per cent, only one-
third of which was due to rate improvement – the bulk of savings
occurred thanks to the elimination of wasteful demand.
The negotiation of mobile communication contracts is a great example of

the application of many different procurement value levers.
The Policy compliance lever will be used to eliminate out-of-policy spend
and charge it to an individual or her/his departmental cost centre. This will
trigger the Budget compliance lever to reject PRs not provided with a sufficient
budget, which is likely to happen sooner or later, due to out-of-policy spend.
Demand levers are also used in full upon deep analysis of:
●●
user groups and their respective quotas;
●●
types of service:
–– national/international voice and data;
–– roaming;
–– additional services, eg mobile parking;
–– M2M.
●●
out-of-bundle charges per user group and type of service;
●●
usage trends by location, subsidiary, seasonality (eg highest-spend
roaming destinations);
●●
spend on interrelated or substituting services (eg fixed voice, Skype for
Business, Webex, etc).
Basically, you need to create a spend cube, from which you will discover
opportunities to use different levers or their combinations, for example:
●●
Implement spend analysis and control tools to enforce personal quotas
and budget discipline.
●●
Enhance mobile policy to use Comply levers effectively:
–– set strict limits per grade;
–– implement service activation procedure that restricts unauthorized
and unrecorded approaches by employees to the mobile operator, as
the bulk of maverick mobile spend relates to unauthorized
activations;
–– encourage BYOD through personal allowances for corporate-standard
devices;
–– analyse the operational need to provide corporate mobile plans to
each segment of employees (eg office workers have different
communication needs to shift servicemen);
–– consider the option of providing a small allowance for personal
mobile plans to employees who do not require a corporate
connection for operational emergencies.
●●
Pool voice and data per department/subsidiary/entire company, which
could save 15–20 per cent on its own compared to using individual
plans.
●●
Consider cancelling or downgrading overlapping services (eg disable
international access on the fixed lines of mobile users, enforce the use
of VOIP applications for international calls to corporate offices).
●●
Restrict all additional mobile services or replace them with a small
allowance (these services usually represent a minor but totally
uncontrollable spend).
●●
Introduce smarter tariffs, eg CUG (Closed User Group) – free calls within
the corporate group, discounted or free calls from/to corporate fixed
numbers.
●●
Enhance the Wi-Fi coverage in the office, including parking lots and
underground levels to minimize the use of mobile data in the office and
its surroundings.
●●
Let mobile operators upsell their plans to employees for their private
use, as the revenue from both corporate and private plans adds to the
same corporate account and improves the negotiation leverage.
Once you have fully exercised Comply and Demand levers, you may activate
Sourcing levers to:
●●
negotiate top-up by bundles of voice and data at wholesale prices (no
overage rates by minute/MB);
●●
negotiate special roaming rates, eg day pass, and country-specific rates
for frequent business travel destinations;
●●
negotiate the monetary value of the tech fund for device refresh during
the duration of a contract;
●●
negotiate the minimum commitment at 60–70 per cent of the projected
spend to protect against seasonal drops of usage or organizational
changes affecting the spend (eg sudden layoffs).
For large companies, you can even consider outsourcing the service
activation and helpdesk to the mobile operator, since to support the
subscriber population of a few thousand, you would require a full-time
employee (FTE).
With this particular example, you may observe how many diverse value
levers are there to be used before the actual negotiations. Eventually, you
may find that the application of the right controls and managed user
behaviour could bring 60–80 per cent of overall savings.
To understand the value demand, the Technology department might

decide to embark on discovery (Chapter 2) by engaging service archi-
tect and business analyst resources. With or without the discovery
finding, we can expect Business and Architecture requirements to
feed into the procurement process.
The Financial Management process naturally covers budgeting,

accounting and charging requirements. Procurement will leverage the
cost/benefit analysis that provides the first trustworthy estimate of
the project spend and perceived value.
With the customer demand formulated, the market analysed,
financial aspects addressed, and keeping the supply base manage-
ment strategy in mind, Procurement will be able to weigh the options
of approaching the market. We will arrange these options into three
groups:
●●
Direct buy:
–– competitive process (RFx);
–– single-source engagement with a strategic or monopolistic
supplier;
–– local supplier development.
●●
Indirect buy:
–– supplier rationalization;
–– spend consolidation (incorporating into another sourcing
project);
–– cooperative buying.
●●
Non-buy:
–– build-it-yourself;
–– full or partial BPO (Business Process Outsourcing);
–– leasing.
Let’s dive into each group of options in more detail.
Direct buy
Many companies make the competitive process mandatory for any
acquisition. However, by operating multi-dimensional strategic
procurement considerations, we understand that there may be exclu-
sions to any common practice. It is imperative that the procurement
policy of your company accounts for options other than a competitive

process, subject to additional reviews, justifications, and approvals.
We already outlined in Chapter 4 that SRM requires a differenti-
ated approach to various segments of your supplier base. For a
specific sourcing project, you may decide that the available solution
is unique to a specific supplier (eg an incremental functionality of an
operational platform), or suitably falls within the scope of an existing
strategic agreement. Then you should be able to justify a single-source
procurement with a monopolistic or a strategic supplier.
Otherwise, you may have a corporate programme for local supplier
development and decide that a sourcing project fits well into it. Your
local partners – an innovation incubator, SMB community, or minor-
ities (military veterans, people with disabilities etc) – could enjoy
some preferences for delivering smaller software developments, chat-
bots, iOS or Android apps that are not critical to the business or
operations. After all, your company might have a social mission to
accomplish.
Indirect buy
One of your SRM dimensions is to maintain an optimal supply base.
This implies increasing the spend with strategic suppliers at the cost
of transactional and operational ones. This process is called supplier
rationalization or densification. Therefore, you may justify pooling
orders of dispersed transactional suppliers into a single strategic
agreement. For example, you may decide to standardize all your end-
user equipment and source it from a single OEM via an internal
e-catalogue or an external web portal.
It is logical and economical to bundle similar orders into one
aggregated requisition. It could be as simple as pooling laptop orders
from different business units into one PR, or as complex as provi-
sionally allocating future sourcing requirements to a strategic supplier
to improve the leverage in an ongoing high-profile negotiation.
One of the forgotten heroes of procurement strategies is coopera-
tive buying. By teaming up with your partners or even competitors,
you can increase joint spend and improve negotiation leverage with
common suppliers. You may also join global alliances, country or
industry associations. Cooperative buying requires massive coordi-
nation but pays off by opening new levels of negotiations due to joint
spending power.
Cooperative buying would hardly work for custom solutions, as
the alignment of requirements between multiple independent
buyers is nearly impossible. However, it’s a proven winner for IT
commodities – telecom services, hardware, peripherals, office

equipment, installation and maintenance services.
As an example, we suggest the US Government’s GWAC BIC
(Chapter 2). They created the SEWP programme – Solutions for
Enterprise-Wide Procurement – that joined over 80 suppliers and
offered over 140 contracts to NASA civil employees, NASA contrac-
tors, federal agencies, and federal agency contractors. The list of
goods and services available to SEWP members is:
●●
telecommunication devices and services;
●●
computer hardware, tablets;
●●
network appliances: routers, modems, VOIP;
●●
storage;
●●
security;
●●
software;
●●
virtualization and cloud computing;
●●
XaaS (Anything-as-a-Service);
●●
scanners, printers, copiers, shredders, associated supplies and
accessories;
●●
sensors;
●●
health IT;
●●
A/V equipment and accessories;
●●
TVs, display monitors, projectors, and screens;
●●
maintenance/warranty;
●●
site planning/installation/cabling;
●●
product-based training;
●●
product-based engineering services (SEWP, 2019).
Basically, in this list, you can see all IT commodities that can be
sourced under collective contract vehicles.
This SEWP programme went as far as online catalogues, reports
on supplier performance, assisted buying, helpdesk, and customer
service – and all of that at only 0.375 per cent of the order value as a
service fee. Imagine how far cooperative buying can go if it’s already
taken SEWP customers to this level.
Non-buy
We already discussed the pros and cons of custom software develop-
ment in Chapter 3. Instead of developing or buying new software, the
cross-functional team may decide to analyse the possibility of
outsourcing the end-to-end business process. For instance, instead of
upgrading printers to the latest, most efficient models that save
consumables and electricity, your company may decide to outsource
the IT infrastructure and acquire printing-as-a-service charged by the
number of printouts.
BPO has many virtues:
●●
leveraging the cost of technology, instead of designing and building
it ourselves;
●●
divesting non-core business activities that distract the company
from its core revenue streams;
●●
risk mitigation by acquiring new services from established specialist
providers;
●●
improvement of cost and resource utilization;
●●
speed to market.
At the same time, there will be multiple risks resulting from BPO,
especially the increased complexity of service delivery management,
FIGURE 5.2 Step 2: Identify business needs and study the market
2.3. Identify the

2.1. Identify 2.2. Collect internal
approach-to-
business needs and external market
market strategy
(TECH) information (PROC)
(PROC)
quality control, and communication. These pros and cons need to be

carefully analysed by a cross-functional team and outlined in a sourc-
ing strategy.
Lastly, tangible technology assets can be leased. The typical exam-
ple is Apple devices that a company could lease to own or refresh
after two or three years. This option requires a simple TCO calcula-
tion of lease vs buy scenarios over the same period.
Step 3: Specify requirements

Project Management takes over during this stage. As per PMBOK
stage 12.1 Procurement Planning (see Chapter 2), the Statement of
Work (SOW) must be developed. The SOW provides enough detail to
allow prospective suppliers to determine if they can provide the
object. ‘Sufficient detail’ may vary based on the nature of the item,
the needs of the buyer, or the expected contract form.
The SOW could undergo revisions as it moves through the procure-
ment process. For example, a prospective supplier may suggest a
more efficient approach or a less costly product than that originally
specified. Multiple products or services may be bundled as one
procurement item with a single SOW.
The statement of work should be as clear, as complete, and as
concise as possible (with the exception of agile projects, which we
FIGURE 5.3 Step 3: Specify requirements
3.1. Develop
the statement
of work (PM)
will cover later). It should include a description of any collateral

services required, such as performance reporting or post-project
operational support for the procured item. In some application areas,
there are specific content and format requirements for an SOW.
Step 4: Define a sourcing strategy

Based on the earlier prepared approach to market strategy,
Procurement will suggest a list of suppliers or a single source, and
stakeholders will agree to it or propose amendments. In some compa-
nies, the list of suppliers requires formal approval to ensure additional
controls of the process integrity.
For an RFP process, Procurement will request that Business and
Technology provide their evaluation criteria, on which the bids are
going to be assessed and compared. Then Procurement will add
commercial criteria and compose a combined evaluation matrix. This
matrix needs to precede the RFP process to avoid manipulation of
scores at a later stage and might also require approval.
Procurement will identify source-to-contract timelines (from the
approach to market to the final contract signature) that will feed into
the Master Project Plan.
FIGURE 5.4 Step 4: Define a sourcing strategy
4.2. Identify 4.3. Evaluate

4.1. Identify 4.4. Develop and
evaluation Source-2-
approach to approve sourcing
methodology Contract
market (PROC) strategy (PROC)
(PROC) timelines (PROC)
With all the deliverables from the earlier stages, Procurement will
develop the critical document – the Sourcing Strategy – which will
define the compelling content of the procurement process:
●●
stakeholder analysis;
●●
specification of requirements;
●●
cost and benefit analysis;
●●
historical spend, contracts and suppliers;
●●
market and supplier analysis;
●●
detailed approach to the market;
●●
list of suppliers;
●●
procurement process timelines;
●●
evaluation methodology;
●●
proposed contract template;
●●
projected benefits and efficiencies resulting from a proposed
sourcing approach (in addition to business case benefits).
This document must be signed off by key stakeholders to ensure

overall alignment and transparency of the process. The sourcing
strategy becomes the first critical artefact for the procurement audit,
which we covered earlier in Chapter 4.
Step 5: Select a supplier and award a contract

In this stage, Procurement initiates an approach to the market,
conducts clarification sessions with suppliers, collects bids, and sends
appropriate technical sections to the evaluation panel. Commercial
terms stay undisclosed with Procurement until the final evaluation.
All communications and interactions with suppliers need to be suffi-
ciently documented to respond to possible claims of unsuccessful
bidders and serve as audit artefacts.
Optionally, Technology might have conducted the Proof of Concept
that will contribute to the supplier selection.
The process of evaluation starts from Technology and Business
scoring to narrow down the list of suppliers to those capable of meet-
ing requirements.
There are two possible approaches to the technical evaluation. The
first is to set a minimum score that qualifies suppliers for commercial
evaluation. The second is to identify a few mandatory pieces of func-
tionality that must be fulfilled by the proposed solution; otherwise, it
is disqualified from any further considerations, even in the event of
not meeting only one requirement. The minimum threshold approach
better suits custom development projects, while the second approach
could be used to shortlist COTS solutions. Not meeting IT Security
or Data Privacy standards should automatically disqualify a supplier
in any scenario.
Fit and gap analysis

This is a useful part of the technical evaluation that gives a view
of how compliant COTS functionality is to the scope of require-
ments. It could be used to assess the rationale of opting for COTS,
as explained in Chapter 3, and to prioritize requirements that
imply customization. Low-priority requirements could be omitted
or deferred to decrease the cost of customization and related
maintenance.
152
FIGURE 5.5 Fit and gap analysis example
RFP Compliance Full 297 Non-compliant

9 30
• 601 remaining requirements after detailed review of Partial Partial
RFP response 127 (1%) Non-compliant 58 226 Full
• 9 requirements dropped due to alternate solution (21%)
Dropped 77
• The product compliance against RFP requirements
310
droppped from 68% to 50% after detailing during RFP
(50%)
review 168 209 75
82
(27%) 20
74 35
27
Phase 1 Phase 2 Phase 3
152
RFP Complexity
33 High High
• Of the partial and non-compliant requirements, (11%)
supplier has categorized 47% as high, 42% as Medium 66 Low
medium and 11% as low in terms of complexity Low 88 Medium
and effort. 138
(47%) 27 13
• Majority of the effort and complexity is focused 124 55
on Phase 2 (42%) 19
73 45
42
9 1
Phase 1 Phase 2 Phase 3

Supplier selection
Traditionally, Procurement should have picked the cheapest supplier
from the shortlist of technically capable ones.
In fact, if your procurement manual mandates that supplier selection

should be based on the lowest price, it is severely outdated. Even the strict
EU public procurement legislation of 2014 allowed the use of best price–
quality ratio or lifecycle costing (ie TCO) and explicitly stated that price is
no longer a sole criterion of supplier selection.
ARTICLE 67 CONTRACT AWARD CRITERIA
1 Without prejudice to national laws, regulations or administrative

provisions concerning the price of certain supplies or the remuneration
of certain services, contracting authorities shall base the award of public
contracts on the most economically advantageous tender.
2 The most economically advantageous tender from the point of view of
the contracting authority shall be identified on the basis of the price or
cost, using a cost-effectiveness approach such as lifecycle costing in
accordance with Article 68, and may include the best price–quality ratio,
which shall be assessed on the basis of criteria, including qualitative,
environmental and/or social aspects, linked to the subject matter of the
public contract in question. Such criteria may comprise, for instance:
a. quality, including technical merit, aesthetic and functional
characteristics, accessibility, design for all users, social, environmental
and innovative characteristics and trading and its conditions;
b. organization, qualification and experience of staff assigned to performing
the contract, where the quality of the staff assigned can have a
significant impact on the level of performance of the contract; or
c. after-sales service and technical assistance, delivery conditions such
as delivery date, delivery process and delivery period or period of
completion.
The cost element may also take the form of a fixed price or cost on the
basis of which economic operators will compete on quality criteria only.
Member States may provide that contracting authorities may not use price
only or cost only as the sole award criterion or restrict their use to
certain categories of contracting authorities or certain types of contracts.
ARTICLE 68 LIFECYCLE COSTING
1 Lifecycle costing shall apply to the extent relevant cover parts or all of
the following costs over the lifecycle of a product, service or works:
a. costs, borne by the contracting authority or other users, such as:
i. costs relating to acquisition;
ii. costs of use, such as consumption of energy and other resources;
iii. maintenance costs;
iv. end-of-life costs, such as collection and recycling costs.
b. costs imputed to environmental externalities linked to the product,
service or works during its lifecycle, provided their monetary value
can be determined and verified; such costs may include the cost of
emissions of greenhouse gases and of other pollutant emissions and
other climate change mitigation costs.
2 Where contracting authorities assess the costs using a lifecycle costing
approach, they shall indicate in the procurement documents the data to
be provided by the tenderers and the method which the contracting
authority will use to determine the lifecycle costs on the basis of those
data (European Parliament, 2014).
There are always additional strategic, political, regulatory and social

or other arguments considered to identify a preferred supplier. The
mix of decision-making criteria for a supplier selection may include:
●●
Value/ROI (don’t start with a price!). First, you need to assess the
value, ie refer to the business case for ROI/NPV calculations.
●●
The total cost of ownership (usually, over five years or as long as
prescribed by a business case).
●●
Company reputation and financial stability, including an assessment
of P&L, cash flow and balance sheet. Another important aspect is
customer concentration – the percentage of revenue from a single

customer, which generally should not exceed 25 per cent. Specialist
sources such as Dun and Bradstreet also provide important
company references in the news to monitor scandals, lawsuits,
M&A opportunities etc.
●●
Long-term corporate vision, so both parties treat each other with
equal importance.
●●
Understanding business requirements, industry or market specifics
(no one-size-fits-all approach).
●●
Openness about issues in legacy contracts and plans for
improvement. If this is not the first contract, then there will always
be some skeletons in a cupboard you need to sort out before
entering into a new agreement.
●●
Project timelines – one of the most ambiguous decision criteria in
technology projects, over 60 per cent of which do not complete on
time, as seen in the CHAOS report in Chapter 6).
●●
Support and maintenance (perceived reliability, availability from
regional centres, working hours).
●●
References (preferably site visits).
●●
Roadmap.
●●
Additional preferences (eg local manufacturer, SMB, minority-
owned, certified for sustainability, etc).
The final evaluation and supplier selection will have to be signed off
by internal governing bodies (ie Tender Board, internal audit, even
Board of Directors depending on the Manual of Authorities) and key
stakeholders. Along with the Sourcing Strategy, it will form an audit
trail of the procurement process.
Business case
Let’s recall that the Financial Management process starts during the
Service Strategy stage. The key considerations of this process are
funding, charge-back, and return on investment.
Ideally, a business case should be ready by the end of the Service

Strategy stage. You won’t need to embark on a complex, lengthy, and
costly procurement process if funding isn’t approved. There are
multiple tools to assess the costing upfront – RFI, market analysis,
historical pricing, benchmark reports, industry business intelligence
(eg Gartner or Forrester).
In practice, a business case usually drags on until the final award,
because Business and Finance will want to use the most accurate pric-
ing from a preferred supplier (possibly BAFO).
The Planning stage of the project management lifecycle starts as
early as the Service Strategy and lasts until the final contract award.
This stage is meant to deliver a business case, which is far more real-
istic regarding timelines. Therefore, we have marked the Business
Case process under PM leadership, as PM bears the responsibility for
delivering a project within the allocated budget.
In the typical Source-to-Contract cycle, a supplier selection is
bundled with a business case. This approach will ensure alignment
with Finance regarding provisional fund availability, and generally
indicate the persistence of end users in cutting a deal with the
preferred supplier.
The first process step, ‘Initiate and approve supplier selection’,
represents some uncertainty to the process. The ideal sequence of
events should be:
business case → supplier selection → contract negotiations → contract

award.
As explained above, the more realistic sequence is this:
supplier selection → business case → contract negotiations → contract

award.
Sometimes, a supplier selection coincides with negotiations to ensure

the maximum accuracy of a business case. We advise avoiding such a
sequence, as it would weaken the final commercial agreement. First,
you cannot negotiate with 100 per cent efficiency if you’re not able
to make the final commitment, which is not possible in the absence of
an approved business case. Second, this sequence will require you to

conduct two negotiations – a powerful commercial one to shape a
business case, and then the final one to agree on contract conditions.
Obviously, two negotiations means more time, effort and risk. Also,
there is no such thing as ‘legal-only’ contract negotiations in isolation
from commercial considerations; therefore, you may discover critical
discrepancies upon the supplier award.
We suggest a firm scenario:
supplier selection (based on the combined evaluation) → business

case → final commercial and contract negotiations → contract award.
In this scenario, a preferred supplier is selected based on the combined

technical and commercial evaluation, but without final negotiations.
The associated pricing is accurate enough for a business case. Upon
finding approvals, the cross-functional team will approach a preferred
supplier for final commercial and contractual negotiations. Any
benefit achieved between a supplier selection and a contract award
will represent the fair value of the budget (cash) saving.
A business case itself will provide a few critical inputs to your
negotiation plan:
●●
the budget ceiling, that is the deal-breaking point;
●●
benefits (revenues, savings, efficiencies etc), which you can integrate
into negotiations to pursue the risk and reward sharing mechanism;
●●
ROI and NPV; negative ROI should alert you to run another round
of internal reviews, before starting to push for discounts.
Importantly, a business case is instrumental in the fair reporting of

procurement savings. You should not calculate savings against the
first, last, or mean offered price but an approved budget.
Prepare and execute final negotiations

Now we’re in the most exciting stage of the negotiation, which many
people imagine when thinking of a career in procurement – a bright
conference room, white-collar armies on different sides of the table,

mind games and charisma fights. Hopefully, all the previous informa-
tion has helped you to understand that negotiation is just a tiny tip of
the iceberg of teamwork, analysis, and preparation. But don’t rush
into a conference room, as we’re not ready yet.
SCOPE FREEZE
Modern technology is continually evolving, and conventional solu-
tions are hard to find. Therefore, your end users could become
overwhelmed and struggle to identify their final requirements. The
more they dive into a solution, their awareness develops, and they
keep on amending their wish list.
For waterfall projects, Procurement needs to ensure that the scope
is well defined and closed to further modifications before starting to
develop a negotiation strategy. The scope flexibility of agile projects
will be sufficiently explained in Chapter 8.
By now, the Project Planning stage is nearly complete, which
means that the Project Management Plan (PMP) is ready. This is the
most crucial document of the entire project management cycle.
PMP aggregates all earlier produced artefacts and defines scope,
schedule, resources, budget, risks, dependencies, change manage-
ment and quality control, and sets everything up for the Execution
stage.
Procurement will have to use a scope definition from the PMP to
align stakeholders and put a halt on further modifications.
PROJECT PLAN
Please refer to Figure 5.6 to visualize the typical implementation
project workflow that will tie together multiple familiar terms (gap,
scoping, UAT).
FIGURE 5.6 Implementation project workflow
Start of project
Customer-specific
requirements Scoping
analysis
Functional and
technical
specifications
Baseline plan
sign-off
Gap development Solution setup Training
Customer test
Gap development
systems
delivery for UAT
ready for UAT
User acceptance
testing
Integration and
User acceptance business Migration
testing sign-off process testing
programme
Production systems Customer business

ready for cutover readiness sign-off
Cutover
Cutover
Post-cutover
The following project plan extracted from an existing contract provides a

live example of previous notions, eg business analysis, solution design,
iterative development. It also follows the ITIL Service Lifecycle. With this
plan, you can see how theory evolves into practice.
1 Stage: Project kick-off meeting

–– Purpose: Confirm requirements, discuss project approach,
requirements walkthrough.
–– Frequency: One-off.
–– Owner: Supplier PM.
–– Attendees: All Project Managers.
–– Location: Onsite at Customer premises.
2 Stage: Project prioritization workshop
–– Purpose: Agree on the priorities of the high-level requirements and

scope items. Define the plan and approach for the delivery of the
solution.
–– Attendees: All Project Managers, Product Owners/SMEs, Business
Analysts.
–– Location: Onsite at Customer premises.
3 Stage: Project planning
–– Purpose: Create initial high-level project/release plans for the delivery

of the scope of the project based on the agreed priorities.
–– Owner: All Project Managers.
–– Attendees: All Project Managers.
–– Location: Onsite at Customer premises/offsite.
4 Stage: Business planning
–– Purpose: Identify/finalize proposed business processes and perform

detailed analysis.
–– Frequency: Multiple ad-hoc based on priorities and scope.
–– Owner: Supplier Business Analyst.

–– Attendees: Supplier PM, Customer PM, Supplier and Customer Product
Owners/BAs, Lead Developer.
–– Location: Initial workshop onsite at Customer premises with further
analysis carried out offsite.
5 Stage: Business rules workshop
–– Purpose: Document the business rules applicable to each set of

requirements.
Owners.
6 Stage: Use case workshop
–– Purpose: Identify each of the use cases for each set of requirements.
Owners.
7 Stage: Scenario workshop
–– Purpose: Establish/confirm the various scenarios within the project

(creation of acceptance criteria).
Owners.
8 Stage: Solution design workshop
–– Purpose: Identify the proposed solution for each of the documented

requirements.
–– Owner: Project managers.
–– Attendees: Supplier PMs, Supplier/Customer Solution Architects,
Supplier/Customer Business Analysts (as required).
9 Stage: Solution design documents
–– Purpose: Document(s) created detailing the proposed solution.

–– Frequency: Multiple documents in line with the requirements.
–– Owner: Solution Architect.
–– Attendees: Supplier PMs, Supplier/Customer Solution Architects,
Supplier/Customer Business Analysts (as required).
10 Stage: Deployment
–– Purpose: Deployment of the base Supplier platform.

–– Frequency: Setup and deployment of the platform.
–– Owner: Supplier PM, Customer PM.
–– Attendees: Supplier Development team, Customer Development team.
–– Location: Offsite at Supplier.
11 Stage: Development
–– Purpose: Development of the solution aligned to the solution design.

This will include project and product development as required.
–– Frequency: Iterative development of the solution.
–– Attendees: Supplier Development team, Customer Development team.
BAs, Product Owner.
–– Location: Offsite at Supplier.
12 Stage: QA Testing
–– Purpose: System integration testing, functional testing, performance,
and volume testing of the solution. Ensure the solution meets the
requirements and acceptance criteria provided.
–– Frequency: Iterative process based on the development cycle.
–– Attendees: Supplier QA Team, Supplier Development Team.
–– Location: Supplier QA team offsite. Development and testing will work
alongside each other, including the build of integration points.
13 Training
–– Purpose: Provision of training as agreed – may be onsite in Customer
premises or webex.
–– Frequency: One-off/multiple sessions as required.
–– Attendees: Supplier Product Expert, Customer End Users, Customer
Product Owner.
–– Location: Onsite at Customer premises, dependent on the training
requirements identified.
14 Stage: User Acceptance Testing
–– Purpose: Delivery of the solution to UAT Testing of the solution to
ensure business requirements have been met, end-to-end business
process testing.
–– Frequency: Iterative process based on the development cycle.
–– Attendees: Supplier Development Team, Customer testing team,
Product Owner.
–– Location: Performed by Customer onsite. Support provided by the
Supplier team offsite.
Testing and go-live process: this process is iterative as it is expected that

there will be a number of releases to implement the full scope of the
project.
15 Stage: Implementation Plan

–– Purpose: Creation of an implementation plan including Customer
steps, migration activities, owners for each activity, dates/times, and
post-implementation checks. A rollback plan will be created should
the implementation not be successful. The implementation plan will
be reviewed and approved by all parties.
–– Frequency: Releases as agreed in the project plans.
–– Attendees: Supplier Development Team, Customer Development
Team, Customer End Users.
–– Location: Supplier offsite and Customer onsite. Reviews will take
place via conference calls/webex.
16 Stage: Change Management
–– Purpose: The change management process to gain approval to
implement the solution. This requires the implementation plan,
documented solutions, monitoring, and post-go-live support to be in
place.
–– Attendees: Supplier PM, Supplier Development Team.
–– Location: Supplier – offsite with the Supplier change authorization
board.
17 Stage: Go-live
–– Purpose: Implementation into the production environment. This
includes any migration activities that may be required – the detail of
these will be defined during the planning stage.
–– Attendees: Supplier Development Team, Customer Development
Team, Customer End Users.
–– Location: Supplier implementation will take place offsite. There is no

requirement from the technical perspective to have resources onsite
at Customer premises. The implementation will require the Supplier
project team to be involved and require significant coordination
between the teams at the Supplier location.
18 Stage: Regular PM calls
–– Purpose: Regular call between Project Managers. To ensure regular
communications take place, issues are raised, and forward-looking
plans agreed.
–– Frequency: Weekly.
–– Attendees: All Project Managers, Product Managers, Lead Developers
as required.
–– Location: Remote via phone or webex.
19 Stage: Workshops
–– Purpose: Calls/meetings as required to review requirements, proposed
solutions, etc.
–– Frequency: Ad-hoc.
–– Owner: Either Project Manager.
–– Attendees: Depending on workshops needs.
–– Location: Depending on workshops needs.
20 Stage: Regular demonstrations of solution
–– Purpose: To demonstrate what has been developed/tested and gain
agreement that it meets expectations. May be performed via webex.
–– Frequency: Ad-hoc.
–– Attendees: Project Managers, Project Teams, Customer Stakeholders,
Product Owners, Customer End Users as required.
–– Location: Remote webex demonstrations or presentation of sprint
results, and progress to date.
SCOPING STUDY
Once you have signed a contract, your preferred supplier will embark
on the detailed analysis of requirements, interview key stakeholders
as to their roles in the project and specific expectations, and analyse
the integration of their own solution with the existing IT infrastruc-
ture and related systems to produce the High-Level Design (HLD)
document. All of this is called ‘scoping study’, and parts 1–9 of the
project plan above are precisely dedicated to this.
Together with end users, Procurement may decide to bring this
stage forward, before final negotiation and a contract award. It is
made to achieve improved visibility of technical requirements, which
the supplier will translate into detailed contract specifications. The
risk of contract variations will be minimized, and a commercial
construct will become way more robust and transparent due to more
evident assumptions and fewer cost buffers for risk mitigation.
Bringing the scoping study forward will not result in a project delay
since this activity would need to happen anyway.
The scoping study contract must contain:
●●
the scope of services (eg workshops, interviews, project manage
ment, solution analysis, documentation development, etc);
●●
time plan;
●●
deliverables;
●●
requirement specification and gap analysis;
●●
HLD;
●●
the detailed master project plan;
●●
resource plan (what supplier resources are going to be involved in
the project delivery and when during the entire project cycle);
●●
training plan;
●●
project organization of Supplier and Customer resources;
●●
risk register;
●●
testing and acceptance procedure(s).
Final commercial offer for the Project (post scoping study):

●●
commercial terms of the scoping study;
●●
price;
●●
special conditions, eg that if the Project is not awarded to the
Supplier in X days from the completion of the scoping study, then
the Customer will reimburse the cost of it. Otherwise, it will
become a part of the Master Agreement for the Project.
The scoping study deliverables will form part of the Master

Agreement, while the final commercial offer for the Project will
provide you with the extensive inputs to a negotiation plan.
While most of the definitions above mostly fit waterfall projects, since we
are talking a well-defined scope and definitive deliverables, a scoping study
is still very useful for agile projects as well. Let’s review the following
example of a scoping study conducted prior to the agile project for COTS
implementation and customization.
SCOPING STUDY DELIVERABLES
●●
Complete requirements specifications in the Supplier’s standard format:
–– Map Supplier’s standard specification capabilities to Customer’s
requirements.
–– Walk through the Supplier’s standard offering specification and
change/add/remove items so that it meets the Customer’s
requirements.
–– Together with Customer, always keep the agreed project goals in
mind and consider if there are areas of functionality that can be
implemented in a second-phase delivery.
–– Review any requirements from RFP where Supplier scored
non-compliant.
●●
Interface requirements specifications in Supplier’s Standard Format:
–– High-level review of interfacing needs identified by the Supplier’s
core project team.
–– Identification of possible additional items to the interfacing scope.
–– Supplier will deliver a detailed description of data feeds required by

the system.
–– Supplier will go through the specification of these feeds in a
workshop with the third-party IT integrator.
–– Supplier and Customer will agree on how system data should be
exported from the Supplier system. The export format should be
agreed and defined.
●●
Summarized recommendation document or equivalent in Supplier’s
format:
–– Review Supplier system gap analysis/design for current and future
processes.
–– Assess and recommend how much of the future process could be
realistically achievable using the Supplier system.
●●
Proof of Concept solution validation report defining KPIs and benefits:
–– Provide Customer’s core project team with inputs and
recommendations for the Business Case.
–– Undertake revalidation of Proof of Concept to identify the tangible/
intangible benefits of the system.
–– Agree together on system gaps to benchmark.
–– Receive data from Customer as required to run the benchmark.
–– Agree on KPIs and what rules to implement.
–– Subsequently, run the benchmark and provide results.
●●
Summary of recommendation of Change Impact Assessment:
–– Lead workshops to see if the current methodology is to remain and
recommend the best rationale to achieve KPIs.
–– Recommend other potential areas of improvement.
–– Identify at a high level significant process changes between current
processes and future processes.
●●
Commercial proposal and high-level schedule for implementation
projects:
–– Summarize the anticipated project activities with milestones
delivered by Supplier in terms of work days and implementation cost.
●●
High-level resource plan:
–– Estimate core project team size based on anticipated project scope.
–– Estimate high-level non-core project team resources for different
project work streams.
●●
High-level schedule for implementation projects:
–– Main project phases and duration.
–– Main project milestones.
–– Main activities per project work stream:
a. project management;
b. system implementation;
c. data migration;
d. interfaces;
e. IT & operation systems;
f. training.
–– Review identified Stakeholders and map them against project

activities using the RACI matrix for the duration of the project.
●●
Training plan:
–– Review anticipated user groups and numbers which require training.
–– Propose different training strategies that have been adopted in past
system implementations.
●●
Testing requirements in supplier format:
–– Review and provide inputs for testing strategy for the project
(Customer, Supplier, and third-party IT integrator project teams to
work together to arrive at the testing strategy).
–– Provide inputs to test planning, resources, indicative timelines, etc.
–– Outline usual testing scope and activities.
●●
Provide input to risk register:
–– Review submitted risk register generated by Customer’s core project
team.
–– Risk identification session with Customer’s core project team to assist
with uncovering and/or clarifying further risks and their appropriate
risk management techniques.
●●
Architecture definition document:
–– Provide explicit architecture requirements for solution delivery.
–– Define governance that will be applied over the delivery.
–– Architecture Review Board (ARB) presentation.
–– A presentation deck created to detail what solution the project is
going to implement.
●●
High-level design:
–– High-level design document details what the solution will look like
and how many transitions this project will take to achieve target
status.
From this example, you can see all the earlier provided definitions – Proof
of Concept, Gap Analysis, High-Level Design. Then you can follow the
process of assessing the existing system functionality (COTS) and its gaps
compared to the Customer’s desired functionality, which we discussed
earlier in Chapter 3, where we also described the process for
implementation.
The implementation process has been planned according to agile
principles. Therefore, in the scoping study above, you can see adjectives
such as ‘anticipated’, ‘estimated’, and ‘possible’. The post-scoping study offer
has been provided in the form of the target price.
NEGOTIATION PLAN
This is possibly the most creative part of the entire procurement
process; a profound negotiation plan is a recipe for success. If you
haven’t got the charisma of the Wolf of Wall Street to persuade people
with bare emotions, then you had better equip yourself with data,
arguments and scenarios. We would also encourage you to employ
the negotiation techniques proposed in Chapter 4.
Getting to know the recipes to win negotiations, you can read
myriad quick reference guides or thick volumes on the secret art of
psychological combat. We will share a few rules that have worked:
●●
Engage your stakeholders – remember, you’re not buying this for
yourself, it’s for Business or Technology to use, and it’s their budget
to spend. Your best-prepared negotiation plan could fail because it
doesn’t account for the expectations of end users. They need to

contribute, advise, and support negotiations so they can co-own
the outcome of it. You can never over-communicate with
stakeholders.
●●
Understand your scope – by the time of negotiation, you need to
know what it is that you’re buying, how it works in principle,
what business requirements it fulfils, and how it is going to be
integrated with the existing environment.
●●
Know your opponent – both as a person and as a title. Which ego
state does he or she match, so you can plan on establishing
complementary transactions? Does she/he represent a monopolist,
market leader, prospect, or a new entrant? What is their strategy –
global brand domination (Apple), price war (ZTE), premium
quality (Bang & Olufsen), cutting-edge innovation (Tesla)? How
intense is their competition? How hungry are they for new
customers? What is their perception of your company as per the
supplier preference model, and what is their position in your
supplier segmentation? How established is their product, and how
important is it to have your company as a reference (eg Microsoft
could be much more accommodating in negotiations for Azure or
Office 365 than for traditional products)? What is there in the
news? For example: ‘Cloud sites expected to open in Dubai, Abu
Dhabi by 2019… Microsoft is competing to expand into new areas
against Amazon, who in September announced plans to open a
cloud-data centre in Bahrain by early 2019’ (Kamel, 2018).
●●
Do your homework – extract your historical spend with a supplier,
analyse the year-on-year spend trends, check what’s in the project
pipeline this supplier is bidding or intending to bid for, obtain
performance reports from IT VMO or feedback from end users.
●●
Pay attention to detail – is it the end of a fiscal year or even a quarter,
when publicly traded companies are looking to pump up their
revenues to impress the market, and salespeople are desperate to top
up their quotas? Is it the first project of a kind in the region, and
which supplier would be eager to be promoted, eg in the regional
industry fair? Are there any M&A announcements to be used to
your benefit, eg when your supplier intends to increase revenues to

sell shares higher?
●●
Leverage your experience – this is the most useful tool in your
negations, so make notes of what worked well and what didn’t.
You will see how your results blossom upon the accumulation of
experience. Negotiations are barely unique, so you need to recollect
what happened in a similar situation and derive a winning strategy.
A negotiation plan is a summary of all your prior efforts in the

procurement process enriched with experience, logic and motivation.
As a bare minimum, it should include:
●●
technical and commercial evaluation;
●●
scope of work and deliverables;
●●
IT architecture;
●●
roles and responsibilities (RACI);
●●
timelines;
●●
supply management considerations;
●●
type of a contract;
●●
payment plan;
●●
present and future pricing;
●●
extra perks (whatever you would want to obtain beyond discounts);
●●
terms and conditions.
It is suggested that you conduct negotiations in a similar order.

Technical and commercial evaluation is the basis of your negotia-
tion plan, as it provides the outcome of an entire sourcing process. It
gives a scent of the price fairness and suggests material gaps in a
supplier’s functionality to trade for concessions. You need to study
this evaluation inside and out before even considering developing a
negotiation plan.
Then you ‘freeze’ the scope and agree to the final definition of it
with stakeholders, so no last-minute requirements should appear to
mess up the negotiation process.
Next, identify deliverables to measure the project outcome and

anchor milestones. You need to clarify the IT architecture to under-
stand the primary construct of a technical solution and its
repercussions on the TCO model (eg as suggested in Chapter 3).
Roles and responsibilities need to be identified (RACI matrix) to
align yourselves and a supplier as to who is doing what. Lack of
alignment could mean a possible change of scope, thus a budget and
timelines (as per the Project Management Triangle in Chapter 3).
A project schedule needs to be agreed upfront, otherwise, you may
need extra resources to compress timelines, hence more money.
Supply management If the project involves any physical deliveries

(something as small as end-user devices or as bulky as telecom shel-
ters or towers), your TCO model will include supply management
cost, ie a combination of:
●●
Delivery, storage, and distribution:
–– internal cost (warehouse, customs broker, local transport);
–– 3PL (third-party logistics) cost to cover all supply management
activities that you don’t perform in-house (from international
freight and brokerage to onsite deliveries);
–– duties and taxes.
●●
Repair and return:
–– extended hardware warranty;
–– repair and return cost.
●●
Lifecycle management:
–– reusable packing (pallets, drums etc);
–– trade-in or disposal upon end-of-life.
Delivery costs largely depend on Incoterms applied. The worst-case

scenario – EXW (ex-works) – will incur cost of collection of goods
from a supplier’s warehouse, loading, delivery of a first carrier, export
formalities, freight, offloading at the destination, import duties and
taxes, and delivery to your warehouse. In the case of DDP (delivery
duty paid), you will incur only the cost of distribution. The choice of
appropriate Incoterms will be based on balancing all the related
expenses depending on project timing, budget, and internal resources.
Besides delivery costs, you will incur warehouse and distribution
costs, as you must store goods and send them to sites.
You should also consider import duties and taxes, which might
form a hefty cost increment. By the way, you will have to pay import
duties on perpetual software, which is considered a physical delivery.
In some countries, you will even have to pay, for example, a with-
holding tax on services provided by non-resident companies.
Hardware warranty and repair is another costly addition to the
project bill. Let’s assume that the hardware warranty covers the
repair at the supplier’s facility, which is usually located in the goods’
country of origin. So, you need to collect, export, deliver to the repair
facility and then cover the reverse logistics of repaired goods. Usually,
it’s more efficient to buy an extended warranty or negotiate that the
entire repair and return cycle is handled by a local partner of the
preferred supplier.
Finally, there will be some lifecycle management cost additions if
you need to return the reusable packaging or dispose of end-of-life
devices.
Type of contract The type of contract you choose for a project

could have a massive impact on your entire negotiation strategy. We
propose you differentiate six main types of contract:
●●
Firm fixed price – a traditional waterfall development contract.
●●
Target price – no hard cap, but a contract could require a review
upon reaching a target price. If a supplier delivers at less than
target price, then there might be an incentive mechanism, while
over-achieving triggers risk sharing, eg a materially discounted
rate.
●●
Risk-and-reward sharing – profit, revenue, or savings share along
with a reduced payment for under-achievement of projected
benefits. Sometimes, the reward could be an extension of the
contract, and the risk – a termination of it.
●●
Cost plus – a supplier’s self-cost plus an agreed profit margin.
●●
Time-and-materials – a rate card with no scope. It is also called
‘staff augmentation’. There might be modifications to this model:
–– Capacity-based – buying work days in bulk at a wholesale price
and additional efforts at a higher rate.
–– Retainer – buying a guaranteed team effort (eg a dedicated
account team with a predefined roster) at a flat monthly rate
and ramping up with extra resources at a higher rate.
●●
Hybrid contract, which usually blends a price or cost with an
incentive, eg fixed price with an award fee on performance, time,
budget, or other.
If you start moving in the proposed order from ‘firm fixed price’ to
‘time-and-materials’, then you will notice how your trust in suppliers
improves. You started trying to fix everything upfront and ended
with a taxi principle, where no matter what happens, the meter keeps
ticking.There is a flipside to trying to assign all risks to a supplier. The
more stringent controls you try to implement in a contract, the more
security buffers the supplier will try to accommodate in the price.
There’s no prescription for what contract is right for what project,
but we will provide some practical observations:
●●
‘Fixed’ contracts usually work better for waterfall projects and/or
new suppliers with unknown capabilities.
●●
A cost–plus approach is generally suggested for dealings with
strategic suppliers, so there’s an appropriate level of trust and
control between parties.
●●
Agile projects provide more freedom to a supplier. The entire Agile
Manifesto (2001) is about trust and collaboration. You should
consider implementing modular contracts (Chapter 3) with robust
SLAs and regular business reviews to ensure that product
development is heading in the right direction.
●●
Risk-and-reward sharing is advised when there is a trustworthy
forecast of benefits that the supplier believes in and is prepared to
achieve and exceed.
●●
Staff augmentation contracts are useful for short-term incremental
development tasks. These contracts require robust controls – time
sheets, work logs, definitive schedules. Don’t use these contracts
for multiple iterations (sprints), since it is expensive and leaves all
risks with you.
A SIMPLE EXAMPLE OF A RISK-AND-REWARD SHARING

AGREEMENT
APPENDIX X, RESULT-BASED RENTAL FEE ADJUSTMENT
The supplier is willing to include an option for the Customer to adjust the
software module rental fees relative to the quantification of achieved
‘added value in optimization’ results during the parallel production
(operation) of new and old systems. The Customer must provide notice to
the Supplier not later than two months prior to parallel production of a
software module in order to activate such a quantification.
In case the option is used (at least one software module quantified), the
Supplier is willing to adjust rental fees according to the following:
●●
per cent of total operational cost reduction <1% relates to 10% reduction
of the software rental fee;
●●
per cent of total operational cost reduction 1–1.5% relates to full
software rental fee;
●●
per cent of operational total cost reduction >1.5% relates to 10%
increase of the software rental fee.
The following pre-requisites apply (details for deliverables and selection of

improvement areas to be decided upon in the implementation project
itself):
A An extra effort for Supplier, typically quite moderate, may apply for
performing the measurements and compiling presentation material or a
report, and the implementation project target hours will be adjusted
accordingly (assume initially 100h per software module and planning
period measured).
B The measurements are to be performed on one or several of the larger
optimization runs and done at the time of parallel production.
Customer and Supplier will together agree on suitable improvement

areas/problems to include to make the measurements as representative
as practically possible.
C A comparison will be made between a Customer-manufactured solution,
produced with the old process, and a solution constructed with the new
process using the Supplier system.
D Customer will need to produce solutions compliant with the same hard
constraints that are imposed upon the Supplier solution using identical
data. Customer is responsible for producing and delivering such
solutions and data in a timely manner for the measurements.
E Measurements will be made on both alternative solutions using the
Customer-tuned objective function in the Supplier system, reflecting the
true priorities of the Customer.
F A selection of not less than five (5) important cost elements in the
objective function will be made by the Customer, including at least one
(1) real-cost element. The relation between the real-cost element(s) and
the other chosen cost elements will be used to compute a ‘total actual
cost’, which will be used for value quantification.
G Supplier reserves the right to include in the measurements the
additional value created by system additional functionality. Customer
will make a ‘best effort’ to evaluate and embrace such changes to the
operations schedule.
H In case the old solution/process has limitations, the Supplier reserves
the right to use the full capabilities of the system in the measurements,
as long as they are aligned with what will or could be used for the
Customer in production.
I It will be assumed that the measured extra value will, on average, be the
same in all other improvement areas (even if not quantified explicitly)
and remain upon the commencement of commercial operations. (This is,
of course, an over-simplification, but shortfalls in added value will be
more than balanced out by other benefits, not quantified here, that
come with the introduction of the System.)
J Created extra value will be added up over all software modules
measured, compared to the overall operational cost, and then any rental
adjustments will be applied equally to all rental fees for the software
modules part of the measurements. (Example: a value increase of 3 per

cent is achieved for Features 1 and 2 but Feature 3 was not measured.
This will result in a rental fee increase for Features 1 and 2 of 10 per
cent, but the Feature 3 rental will stay unaffected).
K Long-term aspects might require, in order to quantify the full effect, a
measurement over more than one planning period.
Payment plan Payment should be in arrears upon acceptance of a

task, deliverable, milestone, or phase. However, keep in mind that
smaller vendors may not have sufficient cash flow to support extended
periods without payment. Increasing the number of deliverables
throughout the project allows vendors to mitigate cash flow issues.
Retain a small percentage (typically 5–15 per cent) of deliverable
payments as holdback until successful contract or stage completion.
You should synchronize deliverables, timelines and payments in
the payment plan. It is essential to agree upon this before getting into
commercials because you can achieve savings prior to starting actual
negotiations.
In a real-life example of a well-negotiated payment plan we observed
some practical implementations of some theoretical statements
provided earlier:
●●
The software deployment was ‘buy and build’ (Chapter 3). An
industry-leading software platform was acquired and then
amended with customer-specific features that were implemented in
an agile manner (therefore the payment timeline indicates sprints).
●●
The scoping study was conducted before final negotiations and a
bulk of its cost carried over to the main contract.
●●
Hosting had two environments – pre-production (testing) and
production. A pre-production environment was organized first,
and hence we paid a setup fee and then recurring hosting fees. By
having the production environment enabled three months later,
just before the final testing (UAT), we avoided paying $90,000 for
running two parallel environments.
●●
All deployment payments were tied to actual deliverables or critical
milestones.
●●
Another important point to mention is that we had two distinct
blocks of functionality, each associated with a rental fee. We
decided to split Block 1 into two releases, each of those delivering
a commercially viable product. Therefore, we started paying a part
of the Block 1 rental fee upon go-live of a respective release (Block
1A). By doing so, we accelerated the delivery of projected benefits
associated with Block 1A functionality and delayed Block 1B
rental fees by over a month ($50,000 saving).
This example can be found as a online resource here: www.koganpage.

com/TPH
PRICING
Upon agreeing on the scope, responsibilities and payment plan, we
have fixed the guiding logic of our project, and now we’re ready to
discuss prices.You need to employ the TCO concept and negotiate
‘whole-of-life’ prices – capex and opex, present and future (eg in the
form of a call-off rate card). Periodic price escalations need to be
negotiated upfront.
Initially, most of the prices are likely to be quoted as bulk numbers
(Software-as-a-Rental fee – $X, deployment – $Y, hosting fee – $Z,
etc) so it will be hard to negotiate without knowing a price struc-
ture and drivers. You need to understand what the key elements to
each bulk price are, and what drives each of them up or down. It is
a good idea to study both the technical and commercial sections of
the winning bid, or clarify with a preferred supplier so you under-
stand:
●●
If it is a resource cost, then what resources (roles) are projected
over what period and at what rate?
●●
Does the effort (work days per task) look realistic to your Technology
experts?
●●
Where are resources based? Did the supplier specify the difference
between on- and offshore rates?
●●
How many people are travelling to the site and hence incurring the
cost of travel, accommodation and per diem? What are travel
standards, ie economy or business flights, five-star hotels, per diem
amounts? Is there a way to push more resources or tasks offshore?
●●
What is the software licensing model and chargeable metrics?
●●
What are the SLAs for support and maintenance?
●●
What is the cloud deployment and cloud services model? What is
the capacity driving hosting fees?
●●
How complex is the integration of a proposed platform/solution,
and what part of it is going to be provided by the supplier? Will the
supplier take overall responsibility for the solution delivery and
integration (including third parties), or are they going to shift all
integration risks and associated costs onto your company?
Detailed cost breakdown should look similar to this:

●●
capex and opex elements separated and detailed;
●●
full TCO calculated, as the cost covers:
–– main Supplier 1 infrastructure and support cost;
–– Supplier 2 data acquisition and ingestion cost (raw data flowing into
Supplier 1 Data Master platform);
–– Azure PaaS cost – production and testing;
–– Linux cost – production and testing;
–– Suppliers 3 and 4 costs per node/seat, as an extension of Supplier 1
nodes drives extra requirements on Suppliers 3 and 4.
●●
forecasted spend details;
●●
Supplier 1 delivery team detailed to roles and onshore/offshore rates.
With such a level of detail, you will be perfectly equipped for factual and
granular cost negotiations.
TABLE 5.1 Detailed financial breakdown
SUPPLIER 1
Year 1 FORECAST PLATFORM

Item (3 Months) Year 2 Year 3 Year 4 Year 5 SPEND
OPEX Item
Data Master subscription Growth (20%)
Support Data Matching Additional Nodes
(Supplier 1)
Data Ingestion (Supplier 2) Data Acquisition & Ingestion
CAPEX Supplier 1 Delivery Team
Data Matching Engine Testing (Functional & NFT)
Data Master
181
182
INFRASTRUCTURE SUPPLIER 1 DELIVERY TEAM
Cost for
Cost per Additional Per Per
Items Node Nodes 1 year 4 year Resource Day Month Per Year
Azure Prod & PPE VM Delivery Manager (Onshore)

Azure Test VM Solution Architect (Onshore)
Red Hat Linux (Prod) Solution Architect (Offshore)
Red Hat Linux (PPE) Module Lead (Onshore)
Supplier 1 Per Node License Senior Engineer (Onshore)
Supplier 3 Prod License Senior Engineer (Offshore)
Supplier 3 Non Prod License Engineer (Offshore)
Supplier 3 (Seats) QA Lead (Offshore)
QA Engineer (Offshore)
Technical Manager (Offshore)
Usually, you will be able to fine-tune the price using a combination of

levers – a cost-effective licensing model, cross-verified licence metrics
and deployment efforts, right-sized hosting capacity, normalized
onsite/offsite resources, reasonable travel standards, adequate SLAs
(eg, no Platinum support for non-critical applications), reasonable
cost and complexity of the solution integration.
We may suggest a few practical takeaways from live negotiations
that may help you to gain some wins:
●●
Don’t rush for unlimited licensing. It is comfy but comes at a hefty
premium, since it’s primarily meant to leverage your lack of planning
and analysis. There should be a robust forecast and trustworthy
assumptions to support the choice of unlimited licensing.
●●
Consumption-based licensing is one of the most effective models
since it’s based on your actual verified needs. It leaves no room for
‘what if’ scenarios that a supplier might use to upsell extra licences.
●●
Make yourself familiar with rate cards – by roles and locations.
Once you have identified the costliest resources, try to weight options
to reduce their cost by balancing on- and offshore time distribution.
Sometimes, a domicile of resources is essential; in one of the projects,
the same resources coming from Sweden appeared to be 15 per cent
more expensive than those from Singapore, just because customers
perceived Swedish resources to be of a higher quality.
●●
Dive into the travel cost. A complex development and deployment
project could last 12–18 months and involve hundreds of air tickets
and thousands of business trip work days. Your supplier would not
make revenue on this travel, but their engineers could end up flying
business class on short-haul flights and living in posh five-star hotels
if a customer allows that and pays. In one of the projects involving
over 120 long-haul flights with a stopover, we discovered that our
company was going to be charged for the resource’s time in transit
at the same rate as for the actual deployment. We negotiated the
‘travel time’ rate card and saved a cost of nearly 150 work days.
●●
For 12-month and longer projects consider hiring term contractors
wherever possible. The supplier’s personnel engaged under the
staff augmentation agreements will be 3–5 times more expensive,
as technology vendors are not body shops.
●●
Annual cost escalation must be explained and justified. Some
suppliers will use COLA (cost-of-living allowance); others apply
an arbitrary value of 3–5 per cent. Firstly, you need to analyse
what elements of TCO COLA applies to. Preferably, it should
apply to labour costs (eg deployment or support) but not licence
fees. Secondly, any increase that is not aligned with an independent
industry or social index should be argued. It’s not up to a supplier
to define the inflation rate.
●●
Technical support working hours could be an essential negotia-
tion point. If your company in the Middle East works Sunday to
Thursday, it is entirely possible that your supplier’s global support
centre works Monday to Friday. By not paying attention to this
point, you may end up with 20 per cent fewer support hours for
the standard price. The same could happen if there’s a material
time zone difference between your location and a global support
centre. You should agree on special concessions in this respect.
●●
Be mindful of integration cost and complexity and try to involve a
supplier as much as possible to deliver the integrated solution.
Even your preferred integrators would be better to be subcontracted
by the system/solution supplier.
●●
Try to reconstruct the value chain between an OEM and your
company and strip off intermediaries with their overheads and
additional levels of risks and complexities. Some OEMs do not sell
directly to end users – find the first link in the chain connecting you
to that OEM. Otherwise, you may end up working via a global
partner, regional distributor and local integrator. As the first option,
try to look for consolidation opportunities and pick an OEM
partner with whom you have some established relations for any
other project or product – it is usually beneficial to leverage an
existing relationship than build a new one from scratch.
EXTRA PERKS
Once your negotiation is nearly complete, and you feel that you have
achieved the best possible pricing, you can still negotiate additional
benefits and incentives that are not necessarily related to the current
project. Some examples are provided below, but the limit to identify-
ing and requesting extra perks is only your understanding of your
company’s and supplier’s business:
●●
Negotiate a supplier’s reciprocal revenue commitment (eg to travel
on your flights, to subscribe to your mobile plans, to provide your
insurance policies to staff).
●●
You can barter the supplier’s products or services for those of your
company to eliminate sales, distribution or marketing overheads,
and, most importantly, save cash. You can also employ barter
facilitators offering, eg, air tickets, hotel rooms, advertising assets,
and so on in exchange for a barter currency.
●●
Any large company has significant marketing assets, for example, a
website and social networks, regional offices or points of sale, even
a fleet of vehicles. The critical component is the clientele, thoroughly
studied and classified. You can offer marketing assets to suppliers for
advertising, brand promotion, and targeted campaigns in exchange
for revenues, discounts, or similar assets to promote your brand.
●●
Once a development or customization of a vendor’s product to suit
your requirements results in new custom features, your company
could obtain kickbacks from sales of those features to any new
customer.
●●
Suppliers could be instrumental to your company’s social
responsibility goals. For example, you can mandate your main
contractor to sub-contract local SMBs, enterprises by veterans or
people with disabilities, national crafts, etc. On the back of your
contract, suppliers could undertake to provide free education/
training/internship to young talent, sponsor social events, support
hackathons, and so on.
●●
Becoming a member of a vendor’s user group could also give your
company an opportunity to influence a roadmap of that vendor’s
new features or products. Teaming up with some influential
vendors could even give you an opportunity to lobby your vision
of the development of industry standards through the representation
of that vendor in global governance bodies.
TERMS AND CONDITIONS

Your negotiation plan will be meaningless without the terms and
conditions of the contract, which embody all the agreements and
commitments you were able to reach. A few essential contract clauses
need to be included in your negotiation plan to avoid last-minute
surprises and price revisions.
Term and termination The term of a cloud service agreement varies

but can be based on a yearly subscription. Some agreements have auto-
matic renewal provisions. Parties should identify when and if they can
terminate for convenience, whether there are cancellation penalties
and whether the provider can increase service fees on a periodic basis.
If your contract assumes some complex software development or
deployment, then you need to clarify the definition of the end of a
contract term. Customers tend to believe that a long-term contract
starts on the date of signature. However, suppliers calculate their deal
profitability estimates based on full years of subscription fees. A
complex deployment could easily take 12–18 months when you
won’t pay a subscription. It is important to discuss this point with a
supplier upfront, otherwise, a deal could fall apart as your business
case assumes, eg, five years of investment including the deployment
period, while your supplier expects five years of subscription fees.
There are two types of contract termination – for cause and for
convenience. Termination for cause takes place if one of the parties
cannot fulfil its contractual obligations or becomes insolvent. Typical
cases for technology projects are related to breach of performance KPIs
or SLAs, eg for multiple failures of acceptance tests, repetitive overruns
of software code error rates or simply delays in implementation.
Such termination is usually disputed and can lead to costly litigation;
therefore, it is advisable to exercise the goodwill mechanism of dispute
settlement through notices, recovery plans, and SRM performance
management. Such termination should be well planned and docu-
mented under legal guidance and used only as a last resort.
Termination for convenience could happen without cause and
usually comes at a cost of cancellation penalties for multi-year
contracts, because suppliers cannot recognize long-term revenue
upfront. Customers may try to insert this clause into a contract in

case of a change in business requirement, scaled-down demand or the
emergence of new technologies or solutions. In the event of termina-
tion for whatever cause, an exit strategy needs to be defined.
Virtualization Many software publishers limit – in one way or

another – their customers’ ability to license software in virtualized
environments. For example, they require that a server or cluster be
licensed to its full processor capacity for a software product – even if
only one virtual machine hosted on the server or cluster is running
that product – unless the company agrees to the technical and proce-
dural requirements for ‘sub-capacity’ licensing, allowing for licence
acquisition at the virtual server level. Please refer to our example of
Oracle Licensing Terms in Chapter 3.
A lack of understanding of the supplier’s licensing policy could
lead to severe under-licensing and hence, huge penalties. This aspect
of licensing requires an explicit definition in the contract.
Breach of licence The supplier’s audit rights provision should include

restraints on audit timing and frequency, limitations on the scope of
potential audits (legal, geographical or product-related) and protec-
tions for information disclosed by the enterprise during the audit.
Resolution terms must be defined, eg licence and backdated mainte-
nance purchases for unlicensed deployments.
SLAs The contract should outline what the supplier will guarantee
regarding uptime or response times. If the supplier fails to meet the
guarantees, then the end user can request a service-level credit.
Additionally, the business should consider including the right to
terminate if the provider consistently fails to meet the service
guarantees.
Data ownership and security Business customers must be mindful

that their data is among the most critical information they own and
ensuring the cloud service provider treats that data appropriately.
Your company must prove that it owns the data, understands how
the service provider can use, aggregate or manipulate the data, and
identify its requirements for the provider to protect the security and
confidentiality of the data.
Insurance Good cloud contracts should always address what insur-

ance the parties must carry. Cloud service providers should maintain
insurance for instances of data loss that cause business interruptions.
Indemnification Indemnification requires one party to pay for

defence costs and any damages awarded when a third party claims
the other party. It is critical for the parties to understand when they
will be required to indemnify the other party and whether the limita-
tions of liability will apply to an indemnification claim. It is vital to
ensure the contract provides indemnification for data and security
breaches as well as intellectual property infringement.
Limitation of liability One of the most important provisions in a

cloud or software agreement is the limitation of liability that applies
to either party in the event of a claim or dispute between the parties.
A reasonable limitation of liability provision will balance between the
potential financial losses the customer can incur and the financial risk
the provider is willing to take given the revenue the project will gener-
ate. In many instances, the parties will negotiate a relatively low limit
of liability, eg one year of services, and then carve out some claims
that are less likely but can be significantly more costly. These carve-
outs include indemnification obligations, confidentiality obligations,
claims covered by insurance, and infringement (Pinson, 2017).
STANDARD TECHNOLOGY CONTRACT CHECKLIST
Basic terms
●●
Contract terms
●●
Payment terms
●●
Definition of chargeable metrics (users, machines, etc)
●●
Price validity and future pricing
●●
Duration and termination (for cause, for convenience)
●●
Features and functionality
●●
True-up/down
Breach of license
●●
Vendor audits
●●
Penalty terms for unlicensed deployments
Data ownership and usage
●●
Data centres and jurisdiction (domicile)
●●
Data ownership
●●
Regular access to data
●●
Data returned at termination
●●
Data usage rights
●●
Data retention
Business continuity
●●
Data recovery
●●
Disaster recovery (DR)
Security
●●
GDPR
●●
Proprietary data protection
●●
Physical and electronic security
Support
●●
Levels of support
●●
Support hours
●●
SLAs (response time by severity, escalation)
●●
KPIs (availability, performance)
●●
Service credits
Price benchmarking
●●
Customer or third-party benchmarking process
Liability and indemnification
●●
Limitation of liability
●●
Indemnification
●●
Insurance
The following workflow will summarize the fifth stage of the procure-
ment process.
FIGURE 5.7 S tep 5 : Select a supplier and award a contract
5.2. 5.4. Initiate

5.1. Initiate 5.3. Conduct
Conduct and approve 5.5. Approve
approach to final
technical supplier business case
market evaluation
evaluation selection (FIN)
(PROC) (PROC)
(TECH) (PROC)
5.8. Debrief
5.6. Prepare and 5.7. Award and
successful and
execute final execute final
unsuccessful
negotiations (PROC) contract (PROC)
suppliers (PROC)
The visual presentation of a negotiation plan

Following is an example representing possible combinations of nego-
tiation plan items with relevant value levers (Chapter 3) and its
application to corresponding TCO elements. You can use this repre-
sentation as a tool to visualize your negotiation plan.
FIGURE 5.8 Graphical presentation of a negotiation plan
Nego- Scope of Roles and
IT Supply Type of a Present and Terms and
tiation work and responsi- Timelines Payment plan Extra perks
Architecture management contract future pricing conditions
plan deliverables bilities
Value Manage
Demand levers Fulfil levers Source levers
levers levers
Cost of
Cost of Cost of Cost of Cost of
Cost of perpetual Cost of Cost of Cost of Cost of
software project knowledge asset
setup software deployment migration testing support
rental management management management
licences
TCO
Cost of Cost of Cost of Cost of
Cost of Cost of
cloud hardware legacy change
integration maintenance
services and end-user platform management

191
Step 6: Manage a contract and supplier relationship

Upon executing the contract, Procurement will prepare the Contract
Management Plan, which includes:
●●
service delivery management, relationship management, contract
administration;
●●
establish and implement relationship management structure and
communications plan;
●●
control changes (scope and cost);
●●
risk management and issues resolution;
●●
asset management.
Procurement will be managing change requests that arise in the

course of deployment and operations, as a part of the contract admin-
istration process.
As Technology will be running their regular supplier performance
review, Procurement will take part and update the Contract
Management Plan.
Performance reviews will feed into the Supplier Relationship
Management framework.
Project Management will carry on with the budget and benefits
tracking according to the business case, where Procurement also
needs to be aligned.
FIGURE 5.9 Step 6: Manage a contract and supplier relationship
6.1. Develop and

6.3. Review
implement 6.2. Manage 6.4. Track budget
supplier
contract change requests and benefits
performance
management (PROC) (PM)
(TECH)
plan (PROC)
Step 7: Review results and close

The procurement project is closed when a contract is completed, or
terminated before the work is completed. Actions that must be
performed during this phase:
●●
Acceptance verification (Technical): ensuring that all appropriate
deliverables are provided, and acceptance certificates signed.
●●
Negotiated settlement (Finance): final settlement of all claims,
invoices, and other issues.
●●
Financial closure (Project Management): involves making final
GRNs of PO and payments.
●●
Procurement process review (Procurement): ensuring that all
forms, correspondence, and other appropriate evidence is in place
to form an audit trail.
●●
Budget and benefit reconciliation (Project Management, Finance,
Procurement): budget closed, top- and bottom-line benefits
reconciled against the business case.
Source-to-contract process
This is a subset of the seven-step process, which is mostly driven by
Procurement. It starts when the scope of requirements is well defined
and ready to be floated to the market and ends upon the contract
award.
Source-to-contract activities usually form 90 per cent of the scope
of procurement audits. This is where Procurement needs to demon-
strate rock-solid governance and a robust audit trail. Critical
approvals are contained here (marked with white stars for Procurement
and a grey for Finance in Figure 5.10).
Source-to-contract process is measured for the cycle time, so
Procurement may finally answer a question: ‘How long does your
process take?’ We proposed some estimates based on personal experi-
ence. Of course, it’s not considering the actual duration of approvals.
FIGURE 5.10 Source-to-contract process
4.3. Evaluate
4.2. Identify
4.1. Identify Source-2- 4.4. Develop and
evaluation Duration:
approach to Contract approve Sourcing
methodology 1–2 weeks
market (PROC) timelines Strategy (PROC)
(PROC)
(PROC)
5.2. 5.3. 5.4. Initiate Duration:

5.1. Initiate
Conduct Conduct and approve 5.5. Approve 6–12 weeks
approach to
technical final supplier business case (1 or 2
market
evaluation evaluation selection (FIN) bidding
(PROC)
(TECH) (PROC) (PROC) stages)
Duration:
5.8. Debrief
5.6. Prepare and 5.7. Agree, award 4–12 weeks
successful
execute negotiations and execute final (2 weeks for a work
and unsuccessful
(PROC) contract (PROC) order, 8 weeks for a
suppliers (PROC)
new contract)
Having reviewed the strategic procurement process in reasonable (yet

not exhaustive) detail, you should have felt the flavour of its overall
complexity and multiple-choice options available in each step. It is
impossible to give you detailed advice on what you should do for any
given sourcing project, supplier, system, deployment, etc. This
complexity will further increase with technology projects extensively
becoming agile, meaning less upfront certainty and more in-progress
modifications.
To master all of the above, you need to better understand the busi-
ness requirements and technical means to accomplish it, get much
closer to your stakeholders and suppliers, don’t hesitate to ask
questions, and eventually gain the most invaluable professional
asset – experience.
References
Agile Manifesto (2001) [online] https://agilemanifesto.org/ (archived at https://
perma.cc/X8VQ-6BFF) [accessed 20 May 2019]
European Parliament (2014) Directive 2014/24/EU of the European Parliament and
of the Council of 26 February 2014 on public procurement and repealing
Directive 2004/18/EC (2014) Official Journal of European Union, 28 March
[online] https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:3201
4L0024&from=EN (archived at https://perma.cc/MW6K-ANWY) [accessed 17
May 2019]
Kamel, D (2018) Microsoft to open first Middle East cloud data centres in UAE,
The National, 14 March [online] https://www.thenational.ae/business/technol-
ogy/microsoft-to-open-first-middle-east-cloud-data-centres-in-uae-1.713023
(archived at https://perma.cc/N6V2-Y2MT) [accessed 17 May 2019]
Pinson, S (2017) Negotiating contracts: 12 key terms to negotiate in a software as
a service or cloud service agreement, Scott & Scott LLP [online] https://www.
lexology.com/library/detail.aspx?g=8ed191ca-f24e-4919-9196-db5d7980b261
(archived at https://perma.cc/DRH5-66J2) [accessed 17 May 2019]
Randle, A and Kippin, H (2014) Managing demand: building future public services,
RSA, 1 February [online] https://www.thersa.org/discover/publications-and-
articles/reports/managing-demand-building-future-public-services (archived at
https://perma.cc/EE9D-NLTE) [accessed 17 May 2019]
SEWP (2019) NASA [online] https://www.sewp.nasa.gov/ (archived at https://
perma.cc/Y9ES-AZZ7) [accessed 17 May 2019]
196

197
06
Practical advice and case studies

on technology procurement
This chapter is intended to share real-life experience and examples

that support some of the earlier theories. First, let’s review some tips
to consider in the procurement process:
●●
Communication is critical for cross-functional teams. There will be
multiple streams of activities that need alignment and document
trails, so it is best to use online collaboration tools – Microsoft
Teams, Trello, Slack, etc.
●●
Flexibility costs money. Any form of variable demand capacity
entails a premium price on unlimited flexibility (eg ULA agree-
ments are most expensive and trickiest to terminate or convert into
regular volume subscription agreements).
●●
Planning must be synchronized between Technology, Project
Management, and Procurement stakeholders, as suggested in
Chapter 2. Otherwise, you will be fighting the clock continuously.
Lack of alignment leads to unrealistic deadlines, especially on the
procurement front, where timelines tend to be given on a residual
basis. As a result, Procurement may be forced to accelerate by
cutting corners and bypassing compliance controls that lead to
cross-functional disputes.
●●
Plan substantial hardware and software procurement around the
manufacturer’s end of quarter or end of year. Global suppliers are
typically willing to offer higher than standard discounts to meet or
beat their quarterly or annual sales numbers. You need to know

the fiscal year-end dates of your strategic suppliers, eg June for
Microsoft, May for Oracle, January for Salesforce, December for
SAP and IBM, and so on.
●●
Provide your negotiation position to a supplier before the face-to-
face meeting to allow them to conduct an internal business case
analysis and secure executive approvals for important concessions
in advance.
●●
Take the driving seat and don’t let the discussion go sideways,
especially if you are negotiating as a team – Technology or Busi-
ness members might want to take over and deviate into their native
grounds. Maintain the rhythm – first things first and topical work-
shops afterwards.
●●
Don’t be afraid of exposing your business case to a supplier, espe-
cially if you’re not reaching the desired negotiation outcome. It is
always helpful to justify your asks with financial values, so your
supplier understands the rationale and can explain it to executive
decision makers. A business case also opens the door to the success
sharing option. Once a supplier agrees to your benefit assump-
tions, you may suggest sharing the risk and reward.
●●
Don’t accept bulk values in an offer, and insist on itemized pricing,
metrics, rate cards, etc. You need to ensure maximum cost trans-
parency for an effective negotiation plan, as well as for the
allocation of cost elements to different budget line items.
●●
If you intend to sign a long-term contract (three years or more), then
it is useful to amend it with your right to conduct price and licence
usage audits every two years. The continuous evolution of technol-
ogy leads to changes of requirements for hardware, computing
power, storage, connectivity, and revision of licensing terms. You
may engage an independent third-party advisor for this commercial
audit so your supplier won’t suspect a biased conclusion.
●●
Target price contracts require an advance scoping study. Without
that, there could be a high level of uncertainty resulting in e xcessive
security buffers within the cost.
PRACTICAL ADVICE AND CASE STUDIES 199
SaaS commercial checklist

The very nature of the SaaS commercial model is the maximum
flexibility for a customer. You’re meant to be able to order any licence
mix over any period, but some suppliers tend to abuse that principle.
These are points to alert you in SaaS negotiations:
●●
Volume-dependent unit pricing. SaaS customers should be able to
true down their licences upon the change of respective metrics (eg,
users, machines, revenues) without the unitary price increase. The
same applies to unwanted products that your end users or Soft-
ware Asset Management might discover sooner or later. A customer
should not be penalized for the cancellation of unused licences.
●●
Minimum contract term. SaaS customers should be able to enter
annual contracts with a simple (but not compulsory) mechanism of
extending the term. No early contract termination penalty should
ever be there. Multi-year contracts should drive additional incen-
tives and provide an early termination with a penalty that will not
overrun the incentive value.
●●
Annual price escalation. This is already discussed in Chapter 5,
sub-section ‘Pricing’.
●●
The extra cost of new features from upgrades. SaaS is a so-called
community model when a supplier develops new functionality
and delivers it to all customers at once via web channels. You
cannot refuse or postpone a new release. Whatever is in the soft-
ware roadmap should come to you with new releases, as a part of
your SaaS fee.
A volume or contract duration commitment could still come in play

if a supplier takes on the full or partial cost of custom developments
of their COTS to meet your company’s specific needs. Once a supplier
indicates an upfront investment in the additional software develop-
ment effort that they absorb, be prepared to make certain concessions.
Just like you, a supplier will have a business case to offset any
additional investment with software revenues.
In that case, you still have options. You can refuse any Supplier
investments and negotiate a fair cost of the full customization, and
then request the maximum flexibility of contract and licensing terms.
Otherwise, you may accept certain concessions in return for the
Supplier’s investments, but demand a share of sales revenues once a
Supplier sells that custom functionality to any new client.
Success factors for technology projects

The CHAOS report by the Standish Group International is the
analogue version of Parkinson’s Law for project management that
studies the nature and influencing factors of failures of software
projects based on years of research and thousands of samples.
It is famous for its revealing facts about IT projects:
●●
only 6 per cent of grand projects and 11 per cent of large ones were
successful;
●●
the average project cost overrun is 189 per cent;
●●
the average time overrun is 222 per cent of the original time estimate;
●●
only 61 per cent of originally specified features were available in
the final projects.
The silver lining of this report is the analysis of success criteria based
on the experiences of IT managers:
●●
executive sponsorship;
●●
emotional maturity;
●●
user involvement;
●●
optimization;
●●
skilled resources;
●●
standard architecture;
●●
agile process (The Standish Group International, 2015).
We have covered most of these already from various perspectives.

Interestingly, the Agile methodology appeared in the CHAOS reports
of 2015, while the most popular failure factor in the report of 2014
was ‘changing requirements and specifications’ (The Standish Group
International, 2014).
One practical observation that comes to mind is that you should
not try to achieve one success factor at the cost of another. Buying
executive support or user involvement by providing unrealistic expec-
tations is counter-productive. The art of project management that
needs to be mastered by the entire cross-functional team is to enable
success factors not by force or manipulation, but by versatile profes-
sionalism and genuine partnership.
Let’s put the same topic into a specific Agile perspective. During the audit
of Agile projects by government agencies, the US Government
Accountability Office (GAO) specified a set of effective practices for
applying Agile methodology. Arguably, this is the most comprehensive list
of success enablers for Agile development.
Six practices align with strategic planning. They are:
●●
Strive to be more Agile, rather than simply following Agile methods and
steps. This approach encourages the adoption of the Agile philosophy, or
mindset, rather than specific steps. This is also referred to as being Agile
or having agility versus using it.
●●
Allow for a gradual migration to Agile appropriate to your readiness.
Migration steps might include combining Agile and existing methods,
conducting pilots, and preparing technical infrastructure.
●●
Observe and communicate with other organizations implementing Agile.
For example, those starting to use Agile can consult with others who
have more experience, including academic, private sector, and federal
practitioners.
●●
Follow organizational change disciplines, such as establishing a sense of
urgency and developing a change vision. A clear vision of change helps
staff understand what the organization is trying to achieve. Another
organizational change discipline is communication strategies.
●●
Be prepared for difficulties, regression, and negative attitudes. This
approach reinforces that Agile is not painless and users may backslide to
entrenched software methods.
●●
Start with Agile guidance and an Agile adoption strategy. This practice
advocates having these elements in place at the start, even if they must
be copied from external sources.
Four practices align with organizational commitment and collaboration:

●●
Ensure all components involved in Agile projects are committed to the
organization’s Agile approach. This practice encourages organizations to
ensure that everyone contributing to a project understands and commits
to the organization’s approach. This includes those working directly on
the project and those with less direct involvement, such as those
providing oversight.
●●
Identify an Agile champion within senior management. This practice
calls for someone with formal authority within the organization to
advocate the approach and resolve impediments at this level.
●●
Ensure all teams include coaches or staff with Agile experience. This
practice stresses the importance of including on each team those with
direct experience in applying Agile. While training is helpful, hands-on
experience helps the team members learn and adjust.
●●
Empower small, cross-functional teams. Empowered teams of 7 to 18
people decide what to deliver and how to produce it. The teams should
not over-rely on one member’s skills.
The following eight practices generally align with the preparation of

people and processes:
●●
Train the entire organization in your Agile approach and mindset, and
train Agile practitioners in your Agile methods. For example, managers
must understand the approach so that they know how it will affect them
and teams need to know the specific steps of an iteration to conduct it
properly.
●●
Ensure that subject matter experts and business team members have
the required knowledge. This practice stresses that staff involved in
fast-paced iterations must truly be experts in the processes being
automated in that iteration in order to reduce delays. For example, a
team member representing financial customers must be fully familiar
with the needs of those customers.
●●
Enhance migration to Agile concepts using Agile terms and examples.
For example, use terms like ‘user stories’ instead of ‘requirements’, and
‘Agile Centre of Excellence’ instead of ‘Project Management Office’.

Provide examples, such as one illustrating the small scope of a user
story, to teams writing these stories.
●●
Create a physical environment conducive to collaboration. A common
practice is to co-locate the team in a single room where they can
continually interact. Other ways to enhance collaboration are to
reorganize office space and use tools to connect remote staff.
●●
Identify measurable outcomes, not outputs, of what you want to achieve
using Agile. An example of this practice is creating a vision statement of
project outcomes (such as a decrease in processing time by a specific
percentage in a set time), rather than outputs (such as the amount of
code produced).
●●
Negotiate to adjust oversight requirements to a more Agile approach.
This practice notes that teams may be able to adjust approach and
oversight requirement by using frequent, tangible demonstrations to
gain the trust of reviewers and investors, potentially reducing the need
for more formal oversight.
●●
Ensure that the definition of how a story will be determined to be done
is comprehensive and objective. Comprehensiveness includes defining
what constitutes a finished product (ie packaged, documented, tested,
and independently verified). Objective means measurable or verifiable
versus subjective judgement.
●●
Make contracts flexible to accommodate your Agile approach. Contracts
requiring waterfall-based artefacts and milestone reviews may not
support frequent changes and product demonstrations in iterations and
may inhibit adoption.
The six identified practices that align with execution are:

●●
Use the same duration for each iteration. An example would be
establishing that iterations will be four weeks each within a release to
establish a uniform pace.
●●
Combine Agile frameworks such as Scrum and XP if appropriate. Disciplines
from different frameworks can be combined. For example, use project
management disciplines from Scrum and technical practices from XP.
●●
Enhance early customer involvement and design using test-driven
development. Test-driven development refers to writing software code
to pass a test. This practice maintains that involving customers in these

tests helps to engage them in the software development process.
●●
Include requirements related to security and progress monitoring in
your queue of unfinished work (backlog). Including activities such as
security reviews and status briefings in the backlog ensures their time
and cost are reflected and that they are addressed concurrent with, and
not after, iteration delivery.
●●
Capture iteration defects in a tool such as a backlog. This practice calls
for queuing issues so that they are resolved in later iterations. For
example, lists of unmet requirements generated at end-of-iteration
demonstrations should be queued in the backlog for correction in a
future iteration.
●●
Expedite delivery using automated tools. For example, tools can track
software modifications, and compliant development sites or ‘sandboxes’
help customers conceptualize the software in an environment that
meets architectural and security standards. Test early and often
throughout the lifecycle. The theme of this practice is that testing during
software code delivery instead of after delivery reduces risk and
remediation costs.
The following seven practices align with evaluation:

●●
Obtain stakeholder/customer feedback frequently and closely. For example,
feedback is obtained during the iteration and at its completion at an
iteration retrospective. This practice was linked to reducing risk, improving
customer commitment, and improving technical staff motivation.
●●
Continuously improve Agile adoption at both project level and
organization level. This practice invokes the discipline of continuous
improvement, meaning always looking for ways to improve. For
example, improvements can be made by adding automated test and
version control tools and enhancing team rooms. These issues can be
tracked in project and organizational-level backlogs.
●●
Seek to identify and address impediments at the organization and
project levels. This practice encourages organizations to be frank about
identifying impediments so that they can be addressed.
●●
Determine project value based on customer perception and return on
investment. This practice recognizes that tracking progress only against
cost or schedule criteria set before the project began could lead to
inaccurate measurement of progress if, for example, major changes in

scope occur. Instead, Agile encourages feedback as one measure of
progress. Comparing solution value to the cost of the solution is also a
gauge of success.
●●
Gain trust by demonstrating value at the end of each iteration. This
practice includes demonstrating key requirements in early iterations and
showing customers that requirements in the backlog are delivered and
not forgotten.
●●
Track progress using tools and metrics such as burn-down charts and
velocity, which can be automated, and success indicators such as
‘customer delight’, and reduced staff stress and overtime.
●●
Track progress daily and visibly. This practice stresses that status is
checked daily and publicly. For example, a progress chart is posted
openly in the team’s workspace, with timely revisions to reflect ongoing
feedback (Powner and Barkakati, 2012).
Case studies
In this section, we suggest a few examples from actual projects and
negotiations, where not everything went as planned, not all targets
were achieved, but where most of the previously explained practices
and tools were applied.
A practical example of Transactional Analysis

We have already discussed Transactional Analysis and its application
to negotiations (Chapter 4); this is an actual example of it in real life.
Customer: In order to help everyone getting prepared for the commercial

negotiation meeting on X, our team has prepared the following list of
requirements. Kindly review it prior to the negotiation meeting, so you’re
not caught by surprise. Please rest assured that all requirements have been
verified with the extended project team inside the company, so it’s not a
pure procurement initiative.
Supplier: Although we appreciate the effort you have made to assist with the
start of the negotiations, your positioning within this email is far from
commercially acceptable. Since we have responded to an RFP and have made
proposals according to that RFP, the starting point for discussions should be
the fees for Option 1 plus the scoping study output as proposed by us. We
look forward to meeting and holding fruitful negotiations towards a position
acceptable by both parties.
Customer: We have intentionally avoided any commercial discussions in the
past, until a scope is finalized, which only happened post scoping study.
Now we would like to express our commercial expectations, and then
discuss in the meeting a mutually acceptable outcome.
All our expectations are based on a certain rationale, and we’re not just
making it up. For example, a man-day rate is something you actually
offered to our partners for a smaller project, and we don’t see a reason to
pay X per cent more. If you expect us to pay a premium price, then please
read our annual report. A project of such magnitude goes through many
levels of scrutiny, and we should be able to explain the logic of any cost
element, and especially its fairness.
Another important point is that our business case for this project, with
current costing inputs, assumes spending of $X million over five years to
buy $Y million worth of benefits. I don’t think it would make sense to
executives unless we find a way to optimize ROI.
I hope our meeting won’t be a ‘take it or leave it’ one. We’re prepared to
negotiate and find consensus, but if you expect us to simply accept your
Option 1 offer, then we won’t be able to.
Supplier: We do not have an expectation of ‘take it or leave it’. We will be

meeting with the express desire to find a negotiated position, fully realizing
you need to find a viable ROI. This may lead us in several directions but to
make headway, we should start with our offer and move from that position
in mutually agreeable directions.
In this email exchange, the Customer applied the logic and argument
from the Adult perspective, but the Supplier responded as a Parent.
Therefore, the Customer had to turn off their own Parent ego state to
snap the Supplier back to the Adult state.
Eventually, the negotiation process took the form of principled
negotiations and ended positively and constructively for both sides.
CASE STUDY 1
We received an offer for an SaaS subscription detailed to the level of functional

modules (five in total, of which we intended to acquire three) and capacity-
based price tiers for each. Our immediate requirements positioned us in Tier 1
of three (lowest cost, lowest capacity). There were some additional transaction-
based charges for one of the modules. The full project was expected to consist of
three phases, of which we were only able to commit to Phase 1. The remaining
phases depended on the commercial success of the initial deployment. The
implementation fee came as a bulk amount.
This plan was shared with the Supplier before the negotiation meeting to
ensure that their team was aware of our position and equipped with the
appropriate authority.
IMPLEMENTATION FEE
a Supplier needs to explain the structure of the implementation fee, eg total

implementation effort by resource type and rate for both onsite and offsite
work as applicable.
b Supplier’s confirmation requires that this cost is inclusive of travel and
lodging for onsite resources (ie local and/or any overseas travel other than if
requested by Supplier for its business, all meals, boarding and lodging,
telephone charges and any other incidentals).
c Rate card by resource type should be provided per each kind of Supplier
expertise (implementation, support, training, and business consultancy, both
onshore and offshore).
d Onsite handholding on the production system post-go-live should be included
in the implementation fee. Please confirm the duration of the warranty period
and if the full project team would be retained?
e Customer should be able to purchase ‘bulk’ hours (in arrays of 500h or more)
with a 25 per cent discount from Supplier list price.
f There’s no mention of training cost in Supplier proposal.
PAYMENT TERMS
a Payment terms for implementation fees should be linked to deliverables.

Customer is prepared to pay the advance of 20 per cent of implementation
fee for Supplier to mobilize resources, and all consecutive instalments should
be assigned to specific deliverables.
b Payment of the software rental fee should start only upon go-live in quarterly
arrears.
c Customer will not accept advance payment of software rental fees during
implementation. However, Customer is prepared to start paying a partial
rental fee upon go-live of any revenue-generating subset of the Phase
functionality. Eg, we can split a Phase into releases and start paying a partial
subscription fee upon the release go-live.
SOFTWARE RENTAL FEES
a Tiers are as per the latest offer by Supplier. The logic of Tier allocation in
Phase 2 would require a dedicated technical clarification session.
b Twenty per cent reduction of proposed Tier prices.
c The further 10 per cent bundled fee discount, from reduced Tier prices, if
Customer orders two modules, and 15 per cent if Customer orders three or
more modules.
d Tier prices and bundle discounts should not be dependent on an overall
commitment of Customer to purchase all three Phases.
e Once Customer decides to increase the capacity of any Supplier module, such
activation of a higher price Tier should be inclusive of implementation
services. Customer will only pay extra for the integration of Supplier modules
to external systems that are not presently detailed in the scope document for
Phases 1 and 2.
f Tier pricing for all five modules to be included in the Master Agreement.
g Supplier needs to explain the process of major upgrades of software modules.
Customer expects upgrades to be covered by a rental fee.
h Software rental fee should be inclusive of a bucket of professional services
hours (eg minor enhancements, remote training, etc – approximately 80
hours per month).
TRANSACTION FEES
a No transaction fees on Direct Sales Channels.

b Transaction fees on Indirect Sales Channels should start at $X and
progressively decrease to $Y depending on the total number of annual
transactions. Customer and Supplier will discuss the price vs volume ladder in
the meeting.
CONTRACT DURATION
a Five years of commercial operations with termination for convenience option

activated at the end of Year 2, with an early exit penalty progressively
decreasing in Years 3 and 4.
b Revenue commitment (travel on Customer network and/or brand partnership)
of $500k per each year of contract based on a corporate travel or marketing
agreement with Customer. Customer will avail discounted rates to Supplier
for corporate and personal travel. Part of revenue commitment could be
realized through Brand Partnership programme.
Following two intensive days of technical clarifications and commercial

discussions onsite, parties produced the following minutes:
TIERS
●●
Tier transitioning is free of charge as long as there is no incremental integration
work or additional requirements above the Supplier standard offering.
●●
Tiers have been assigned based on the scope document agreed with Customer.
●●
Business requirement A will need Customer to upgrade to Tier 3 and
therefore considered out of scope for Phase 1. A subset of this requirement
A1 is part of the scope.
●●
Supplier to get back to Customer on the final and best rental fees offered.
Current proposal offers a 5 per cent bundled discount.
●●
Product roadmap to be shared by Supplier.
●●
Bucket of professional hours is not included in the rental fee at the moment.
●●
Training schedules pending with Supplier.
●●
Supplier is working on all the schedules provided by the procurement team.
HOSTING
●●
Supplier will not be able to provide earlier indicated SLAs applicable to
Supplier cloud, as the platform will be hosted in Customer private cloud.
Instead, SLA for issue resolution would be applicable in this scenario.
●●
Patches and deployments will be Customer’s responsibility if hosting is
carried out by Customer.
●●
Customer Architects have agreed to Supplier hosting to begin with, but we
need contractual language to ensure that a transition of an environment is
flexible at a later point.
●●
If the Customer local law mandates hosting in their country, then would
Supplier hosting provider be able to obey the law? Contractual language to
support this transition will be included.
IMPLEMENTATION
●●
Supplier to provide the milestones associated with the implementation.
●●
Implementation timeline is assumed to be close to 15 months including
Phase 1 and Phase 2 work.
●●
Implementation is inclusive of the travel expenses, training costs and change
management support.
●●
Implementation cost also encapsulates the availability of technical resources
on- and offsite to support the implementation work. Details will be furnished
as a part of the contract schedules.
●●
Supplier is comfortable to adapt to an agile delivery model, for example,
go-live with functionality A and then B. The provisional timeline for
functionality A in September, subject to a detailed plan being laid out in the
Master Agreement.
TRANSACTION COSTS
●●
Parked due to technical clarifications.
CONTRACT DURATION
●●
Customer has communicated that it is a part of their corporate governance
that the exit clause must be included along with early termination provisions.
An updated offer was received a few weeks later following rounds of conference
call and email negotiations.
IMPLEMENTATION FEE
●●
The detailed fee provided by Supplier.
PAYMENT TERMS
●●
Supplier is in agreement to establish project milestones and use these
milestones for payment of the implementation fee.
●●
Supplier is in agreement that subscription fees will be paid upon production
activation of each respective product and a ramping scheme of subscription
fees will be agreed once all project milestones are established. It is expected
this will be completed prior to contract execution.
●●
Regarding payment terms, subscription fees will be paid in monthly
instalments with net 30-day terms. Usually, 1/12 of the annual subscription
fee unless otherwise scheduled, eg, Phase 1 partial scope release.
SOFTWARE RENTAL FEES

Supplier has amended its original proposal as follows:
●●
Supplier will provide Customer with a 5 per cent discount off proposed rental
fees for all products noted in their proposal.
●●
Supplier will provide Customer with an additional progressive discount based
on the number of products licensed:
–– 2 products – 7 per cent effective 12 per cent total discount;
–– 3 products – 10 per cent effective 15 per cent total discount;
–– 4 products – 17 per cent effective 22 per cent total discount.
●●
Supplier will not provide a monthly account of hours for professional services.
TRANSACTION FEES
●●
Supplier has amended its original proposal with a scaling volume ramp as
follows:
–– 0 to 250,000 → $X
–– 250,001 to 500,000 → $Y
–– 500,001 and above → $Z
CONTRACT DURATION
●●
Parties are in agreement. Actual termination fees will be decided during
contracting.
REVENUE COMMITMENT
●●
As discussed, Supplier agrees to engage the appropriate people in addressing
this opportunity further.
By fine-tuning this offer in a few more iterations, we were able to achieve a total
reduction of the five-year TCO of 17 per cent versus the best offer received during
the RFP.
KEY TAKEAWAYS
●●
We consistently worked according to a predefined script that
provided a solid structure to a multilateral and multi-subject discus-
sion. Otherwise, with such complexity and variety of topics, and
numerous stakeholders from both sides, each covering a narrow
domain of expertise, we might have lost sight of the big picture and
deviated into various side conversations.
●●
By moderating the negotiation plan, procurement maintained
control of the overall process.
●●
We were able to achieve a reasonably good discount on software
rental fees. Due to the very specific (niche) application of the system
and disparate licensing models of shortlisted suppliers, we were
only able to guide ourselves towards an acceptable result by plug-
ging any latest edition of the offer into a business case and looking
at changes of payback period, ROI, etc.
●●
It was particularly helpful to split the functionality in commer-
cially viable releases and start obtaining revenues six months
earlier than the go-live of the full platform.
●●
We weren’t able to secure the desired level of visibility of manpower
rates by roles and locations. Many suppliers tend to give you no
more than a blended rate per hour.
●●
The scope wasn’t sufficiently fixed by the time of the face-to-face
negotiation meeting. Hence, we had to spend a full day on reach-
ing an internal agreement between the Business and IT as to the
critical element of a preferred solution.
●●
Solution ownership ambiguity led to side debates between Busi-
ness and IT, as it wasn’t exactly agreed what prevails – technology
requirements or business logic.
CASE STUDY 2
We referred to this project in Chapter 5 when we provided a sample payment

plan. The negotiation plan transformed into the following communication, which
may provide a few useful observations.
Customer: Air travel only on Customer flights in Economy class. Time in transit at
50 per cent of the hourly rate.
Supplier: Air travel based on the economy class between HQ and European
Gateway, with Economy upgradeable to Business Class on Customer flights
between Gateway and Site. Time for air travel to be paid at 75 per cent of the
hourly rate.
Customer: What can be re-used from the Partner Airline’s installation of a similar
platform? Eg blueprints, complete modules/functions, project documentation –
anything useful to offset some project development hours.
Supplier: Acceptable. Supplier can arrange one-day show/tell workshop on
Partner Airline installation at no charge.
Customer: Twenty per cent discount on software rental fees, half of which (10
per cent) could be recouped upon successful delivery of operational benefits of
$X million per annum from a baseline identified in the contract.
Supplier: Supplier agrees to drop rental by 5 per cent. Also, we propose a
mechanism for success sharing that results in rental fee differences by –10 per
cent /0 per cent /+10 per cent from the discounted level. Supplier to provide a
separate document to describe the methodology proposed.
Customer: Parties to review software rental fees on an annual basis to reflect
changes (scale up/down) of usage metrics at year end.
Supplier: Agreed.
Customer: Any software rental payment to trigger only upon going live. Phased
(partial) payments permitted, where applicable.
Supplier: Agreed. Twenty-five per cent of rental to be allocated as an initial
portion of the payment, the remaining is relevant to an actual user count upon
acceptance.
Customer: Project man-day rate to be reduced to US $X. This assessment is
based on benchmarking with Partners, and similar providers of critical solutions.
Supplier: We have reduced hourly rates for the implementation to $Y, plus a 15
per cent reduction for less qualified staff.
Customer: Target price of implementation should be capped at 10 per cent of
projected hours.
Supplier: Agreed.
Customer: During the three years after going live, Customer should be able to
purchase additional development hours in bulks of 1000h or more, at US $X,
or less than 1000h - at US $Y. After that, an annual rate escalation should not
exceed 5 per cent YoY.
Supplier: Supplier agrees in principle to sell development hours in bulks of 1000
hours minimum.
Customer: Before the start of implementation, and hence drawing down project
hours, Supplier will provide a workshop on agile project methodology and its
specific application to Customer’s project. All project team members (including
third parties) should understand how project hours and story points are being
drawn down, and how third-party dependencies are being managed. This
workshop will only be charged for travel costs.
Supplier: Agreed. This will be included in project initialization.
Customer: Implementation cost overheads will include flights, hotels nights and
per diem. Supplier will bear visa cost and other incidentals (eg taxi, travel
insurance).
Supplier: Supplier is willing to create a table showing per-person per-trip block
payments schedule. It would include our expenses but will ensure ease of
calculations, and we hope to ease agreement.
Customer: Hotel nights at Site will be capped at US $X.
Supplier: In the negotiation room, both parties agree that Customer can book a
hotel for Supplier staff at 4 stars or above standard.
Customer: Supplier will sign a five-year corporate travel agreement with
Customer with an annual commitment of $X million worth of ticket revenue.
Customer will avail special discounts to Supplier for selected frequent
destinations, upon analysis of Supplier’s travel spend.
Supplier: Unfortunately, Supplier is unable to comply. Reasons were given in the
negotiation room.
Customer: Supplier to provide a 20 per cent discount on some other legacy
services used by Customer.
Supplier: Ten per cent surcharge will be waived.
Customer: The contract should specify the option to terminate for convenience,
with a notice period and an early termination fee in each consecutive
contract year.
Supplier: Agreed. Supplier will propose a language with a formula for covering
remaining time. Minimum contract period will be three years.
KEY TAKEAWAYS
●●
In this project, we managed to try a few new concepts – a target
price deployment contract, sharing a business case to eventually
engage the Supplier into the risk-and-reward pricing scheme, and
option to buy development hours in bulks at a reduced rate.
●●
The deployment model was ‘buy and build’, ie, we acquired the
COTS and then sufficiently customized it to meet our specific
requirements. The contract has been constructed on Agile princi-
ples, with a number of sprints and story points. Upon conducting
an advance scoping study, the Supplier provided a target price based
on a customization effort estimation (around 10,000 work days).
The specifics of that contract were that if we were to complete the
deployment at less than 10,000 work days, then the balance was
still charged at 50 per cent of man-day rate. Similarly, if we were to
exceed the estimate, then each excessive man day should have been
charged to the 50 per cent rate. This commercial construct encour-
aged the Supplier to complete tasks within the target cap or less,
and obtain an incentive for unused work days. Otherwise, they
were to incur a loss by working at a 50 per cent rate.
●●
Opening up a business case to the Supplier provided them with the
sense of comfort to offer the risk-and-reward pricing mechanism,
as they believed we were too conservative with our benefit forecast.
●●
A good payment plan was instrumental to the granular planning
of the business case cash flow that allowed us to make it slightly
more attractive before any commercial negotiation, simply by
adjusting initial generic assumptions to the detailed plan with
payment milestones.
CASE STUDY 3
It might be useful to review a case where Procurement wasn’t successful and

wasn’t able to achieve any of its additional asks.
We were asked to negotiate an early termination of a five-year agreement at
the end of Year 4 due to reduced baselines, and conclude a new five-year
discounted agreement. After weeks of negotiations and internal approvals on

the supplier’s side, we were only able to achieve a moderate discount that hardly
reflected the substantial decrease of the licence count.
Customer: As per our existing contract, the cost of a concurrent user is $10,000.
A block of 10 remote users will cost $5,000 (licences) and $1,000 (hosting).
Customer aims to reduce concurrent users from 20 to 15, and remote ones from
100 to 40. Wouldn’t this assume a price reduction by $10,000 x 5 + $6,000 x
6 = $86,000?
Supplier: The pricing quoted above is for additional users and does not take into
account all of the base hosted services or licensed modules that were initially
heavily discounted on the basis of a five-year contract (now to be only four
years) and Supplier’s pricing strategy at the time. As discussed, being a part of
the wider group of companies, Supplier has had an opportunity to calibrate its
pricing against the market and this has led to an increase in licence fees,
underlining just what a good deal Customer was able to secure previously. In
fact, when re-pricing this deal, we had to apply a greater discount in order to
bring the offer down to its current level.
Customer: Would it be right to assume that the hosting cost should have
improved substantially in the last four years, due to the evolution of hardware
and virtualization technologies? Wouldn’t the hosting fee decrease just for this
reason if we were to renew the contract even with the same baselines?
Supplier: The hosting fees, like the licence and maintenance, were heavily
discounted in the original deal and when it came to this renewal, we explored
both renewing the hosting and providing a Cloud service. With regards to the
Cloud service, as the offering does differ somewhat from our current hosting
offer, through additional software and service for the managed infrastructure
service, the increase was significant and after checking with Customer, it was
agreed that the additional Cloud benefits would not make a material difference
to Customer’s usage of the system, so this option was disregarded. With regards
hosting, even taking into account a reduction in users, the renewal hosting fees
that were calculated, even taking into account the benefits you mention, were
actually higher than the current fees, so the additional discount was applied to
ensure that the hosting fees did not increase.
Customer: Is it possible to review our actual usage of the system to reconfirm the
number of concurrent licences? Having 18 concurrent licences per 18 users
seems like overkill to me. (Apologies if this question sounds unprofessional,
as I’m not a subject matter expert. I presume that concurrent licences, as

opposed to named ones, provide all users with simultaneous access to the
platform, which might not be necessary. Of course, this is to be approved or
disapproved by the usage report).
Supplier: Customer can certainly review their usage of the system and there are
logs that can be switched on to allow you to do this. Supplier would not normally
access such information and usually the client would switch on this logging data.
However, please consider that as Supplier is already providing increased
discounts, as well as allowing for the early breaking of the contract, it is unlikely
that any further fine-tuning would deliver any additional reductions.
Customer: Would we still need 40 Citrix licences if we decreased the number
of users?
Supplier: Again, this is a question for Customer to answer, but I refer you to my
earlier answer with regards hosting fees, where we have already applied
significant discounts and further tuning may not make a material difference to
the proposal.
Customer: Lastly, if we’re to extend the contract for five more years, would there
be an incentive given to us just for that reason?
Supplier: With this offer, Customer has already benefited from being allowed to
exit the existing contract one year early and to reduce costs by X per cent.
Additionally, as mentioned, Supplier has been able to review its pricing and the
offer to Customer represents a larger discount against current pricing than was
previously offered for the original deal. It should also be considered that for a
shorter term, eg three or four years, Supplier would reduce the level of discount
and the fees would be higher for such a term.
Customer: With all the above questions in mind, a proposed cost reduction of X
per cent looks suboptimal to us. Can we please unlock the costing logic a bit
more, so your assumptions would become more transparent?
Supplier: As you will be aware, the contract for the original term does not expire
until May 20xx. Supplier is only making this offer at this point at Customer’s
request, which includes allowing Customer to terminate the existing deal 12
months early. It should be noted that it took more than three months to get this
offer approved, that there was little appetite on the Supplier management side
to shorten the existing contract or to increase the discount, and that I sought
several rounds of executive management approval to provide the current
proposal.
Customer: We’re sincerely grateful for the flexibility and Supplier’s spirit of the
partnership. I agree that reviewing the terms of an existing contract is very hard
and would concur with your opinion that any decrease in the previously
contracted prices is precious.
However, we ran the same discussion with many strategic suppliers of ours,
eg Suppliers A, B and C. There’s always an opportunity to trade off an immediate
loss of revenue with the extended duration of the contract, so Supplier would be
able to recognize some additional long-term revenues.
I would agree that your offer for Year 5 of the existing contract is OK but
won’t accept that we’re terminating the current contract – that would be fair, if
we were to end the contract in May 20xx. In fact, we intend to early renew it.
What about Year 6 onwards? Can we look into the improved deal from May
20xx for, eg five years? We have sufficiently decreased the number of licences,
and I’m 100 per cent confident that the hosting cost should go down as well.
I will have to justify this offer to Customer’s executive board, and I sincerely
don’t feel it’s good enough for the extended term starting from May 20xx. My
suggestion would be to leave your current offer of $X for Year 5 of the current
contract and sign a new one for a consecutive five-year term $X-25 per cent
(due to a decreased licence count, far less hosting capacity, fewer Citrix
licences).
Supplier: Thank you for your mail. Whilst I appreciate the points you raise, I don’t
believe there is anything further we can offer.
I have gone back and checked the hosting side and I should have mentioned
that based on the reduction of users we had already reduced the number of Citrix
servers from five to three to take into account the reduced number of total users.
To be clear, I am not offering an option for a single year at a reduced fee.
Whilst I understand that you have worked with many other suppliers, I do not
know your contractual situation with them, but what I can tell you is that the
deal agreed between Customer and Supplier in 20xx was well below market
value and included a significant discount to close the deal. To now find additional
value is extremely difficult and we have done our best to present our most
competitive offer.
The proposal made to Customer represents Supplier’s best offer, which is to
renew one year early (May 20xx) and commence a new five-year term for $X per
year. The alternative would be to see out the current term and to ask Supplier for
a new quote based on the reduced usage in 20xx. However, please understand
that it is extremely unlikely that we would offer better terms than are currently
being offered and I can make no guarantees that the price might not increase.
KEY TAKEAWAYS
●●
Above is a typical example of a vertical SaaS provider (Chapter 3)
of a niche SaaS application. They knew their position as a ‘bottle-
neck’ supplier – hard to replace, closely engaged with end users,
and deeply integrated into the customer’s business processes due to
a long history of cooperation. Having delivered a quality solution
and good customer service, they had become instrumental to the
key financial process and had no fear of substitution.
●●
Similar situations of close relationships and high dependency on a
supplier tend to happen in many companies with small internal
teams operating a single platform. They are not exposed to the
procurement process, as they do not raise multiple sourcing
requests. The same supplier works with them for years, becoming
an ally and a mandatory element of the operational routine, while
procurement represents the uncertainty and risk of loss of legacy
status quo.
●●
Procurement advisory suggests managing bottleneck suppliers by
establishing closer buyer–supplier relationships, de-risking supply
dependencies, sophisticated end-user engagement models, and
creative options generation. Of that, we only ticked the last box
and offered multiple options for the review of different TCO
elements. However, we did not have time to embed procurement
into the direct ‘end user–supplier’ relationship model, and hence
failed to stand as one team.
●●
Generally, such cases require advanced preparation to align with
end users, channel all communications via Procurement, convey a
single cross-functional commercial position, and investigate poten-
tial alternatives for the ‘plan B’.
Our advice for preparing for important negotiations is to always use

a detailed plan with the commercial position aligned with all members
of the cross-functional team. It will provide the structure for all
further interactions with the supplier and serve as the evidence of
your achievements while comparing the initial position and the result.
It will also form the audit trail and a useful record of the discussions
and actions by the parties when and if you need to revisit the history
years after signing the contract (eg to negotiate a contract extension
or early termination or challenge some contract provisions).
It may sound banal but be prepared to lose or underachieve
expected negotiation benefits. It is not only a matter of your profes-
sionalism but a few other critical factors:
●●
Disproportionate calibres of a supplier and your company. This is
quite a natural situation if you represent a medium-size business,
especially in a third-world country, and face the likes of Micro-
soft, Oracle or Salesforce. In that case, you probably need to seek
a reliable and business-minded local partner, as it is unlikely
you’ll be able to consolidate enough spend to make those giants
interested to manage a deal directly.
●●
Low profile of your company account in the supplier’s ranks (even
if that supplier isn’t a globally dominant OEM). In this case you
need to work more on the SRM front to improve your position in
the Supplier Preference Model (Chapter 4) by, for example, apply-
ing a spend consolidation lever to enhance your commercial
appeal.
●●
Deep ties between end users and a supplier. In this situation, the
supplier account team has done a great job establishing coopera-
tion with your colleagues in Business or IT. You will have to do a
lot of relationship work to install procurement in the value chain
of end users and watch for any preferential treatment by the vendor
(eg tailored requirements or biased evaluations) to enforce the
integrity of a sourcing process.
●●
Bottleneck suppliers. We have already given a relevant example and
some advice. Together with end users, you need to work on finding
alternatives – not to necessarily replace a supplier, but to avoid
becoming a hostage to a single source.
●●
Unreasonable requirements. You might have overcooked your
negotiation strategy and set the bar too high, so a supplier may be
unable to achieve it. Don’t be shy of accepting that no one’s perfect.
Don’t be discouraged by temporary shortcomings in your negotia-

tions. Keep in mind that category management assumes a longer-term
strategic view, so even if you have lost a battle, you haven’t necessarily
failed a campaign.
References
Powner, D and Barkakati, N (2012) Software development: effective practices and
federal challenges in applying agile methods, GAO [online] https://www.gao.
gov/assets/600/593091.pdf (archived at https://perma.cc/854U-T93W) [accessed
17 May 2019]
Standish Group International (2014) Chaos Report: 21st Anniversary Edition
[online] https://www.standishgroup.com/sample_research_files/
CHAOSReport2014.pdf (archived at https://perma.cc/3L3K-LAKF) [accessed
17 May 2019]
Standish Group International (2015) Chaos Report 2015 [online] https://www.
standishgroup.com/sample_research_files/CHAOSReport2015-Final.pdf
(archived at https://perma.cc/F86S-FP9G) [accessed 17 May 2019]
222

223
07
US legislation and regulation on

agile deployment and contracting
and performance-based
management
As the US government spent US $83.4 billion in 2018 on information

technologies (Office of Management and Budget, 2019), it is highly
useful to examine their efforts to manage the procurement process.
The Federal Acquisition Regulation (FAR), the Clinger-Cohen Act of
1996, and the Office of Management and Budget (OMB) circulars
provide thousands of pages of regulatory guidelines for technology
procurement. We will elaborate on just two important topics related
to modular (Agile) development and contracting, and performance-
based management.
Attributes of Agile by GAO

The US Government Accountability Office (GAO) audited agencies
for implementation of the Agile methodology using the following
four key attributes. It is useful to understand the treatment of Agile
by the government auditor, as it is based on the rigorous considera-
tion of legislative and industrial guidelines, norms, and standards.
The following is taken from the 2012 GAO ‘Software Development’
report.
The Agile approach differs in several ways from traditional waterfall

software development, which produces a full software product at the
end of a sequence of phases. For example, the two approaches differ in
(1) the timing and scope of software development and delivery, (2) the
timing and scope of project planning, (3) project status evaluation, and
(4) collaboration.
●●
Timing and scope of software development and delivery. In an Agile
project, working software is produced in iterations of typically one
to eight weeks in duration, each of which provides a segment of
functionality. To allow completion within the short time frame, each
iteration is relatively small in scope. For example, an iteration could
encompass a single function within a multistep process for
documenting and reporting insurance claims, such as a data entry
screen or a link to a database. Iterations combine into releases, with
the number of iterations dependent on the scope of the multistep
process. To meet the goal of delivering working software, teams
perform each of the steps of traditional software development for
each iteration. Specifically, for each iteration, the teams identify
requirements, design and develop software to meet those
requirements, and test the resulting software to determine if it meets
the stated requirements. In contrast, waterfall development proceeds
in sequential phases of no consistent, fixed duration to produce a
complete system, such as one that addresses a comprehensive set of
steps to manage insurance claims. Such full system development
efforts can take several years. Waterfall phases typically address a
single step in the development cycle. For example, in one phase,
customer requirements for the complete product are documented,
reviewed, and handed to technical staff. One or more phases follow,
in which the technical staff develop software to meet those
requirements. In the final phase, the software is tested and reviewed
for compliance with the identified requirements.
●●
Timing and scope of project planning. In Agile, initial planning
regarding cost, scope, and timing is conducted at a high level.
However, these initial plans are supplemented by more specific plans
for each iteration and the overall plans can be revised to reflect
US LEGISLATION AND REGULATION 225
experience from completed iterations. For example, desired project

outcomes might initially be captured in a broad vision statement
that provides the basis for developing specific outcomes for an
iteration. Once an iteration has been completed, the overall plans
can be revised to reflect the completed work and any knowledge
gained during the iteration. For example, initial cost and schedule
estimates can be revised to reflect the actual cost and timing of the
completed work. In contrast, in traditional waterfall project
management, this analysis is documented in detail at the beginning
of the project for the entire scope of work. For example, significant
effort may be devoted to documenting strategies, project plans, cost
and schedule estimates, and requirements for a full system.
●●
Project status evaluation. In Agile, project status is primarily
evaluated based on software demonstrations. For example,
iterations typically end with a demonstration for customers and
stakeholders of the working software produced during that
iteration. The demonstration can reveal requirements that were
not fully addressed during the iteration or the discovery of new
requirements. These incomplete or newly identified requirements
are queued for possible inclusion in later iterations. In contrast, in
traditional project management, progress is assessed based on a
review of data and checkpoints can occur at the end of a phase,
such as the end of requirements definition, or at scheduled intervals,
such as monthly. The reviews typically include status reports on
work done to date and a comparison of the project’s actual cost
and schedule to baseline projections. Federal IT evaluation
guidance, such as our IT Investment Management guidance and
OMB IT reporting requirements specify evaluations at key
milestones, and annually, which more closely align with traditional
development methods. For example, for major projects, OMB
requires a monthly comparison of actual and planned cost and
schedule and risk status and annual performance measures using,
for example, earned value management (EVM).
●●
Collaboration. Agile development emphasizes collaboration more
than traditional approaches do. For example, to coordinate the
many disciplines of an iteration, such as design and testing,

customers work frequently and closely with technical staff.
Furthermore, teams are often self-directed, meaning tasks and due
dates are undertaken within the team and coordinated with project
sponsors and stakeholders as needed to complete the tasks. In
contrast, with traditional project management, customer and
technical staff typically work separately, and project tasks are
prescribed and monitored by a project manager, who reports to
entities such as a programme management office (Powner and
Barkakati, 2012).
Flexibility permitted by the Federal Acquisition Regulation (FAR)

You may have a perception of FAR favouring the waterfall approach,
as its framework was constructed in 1984 and even the Clinger-
Cohen Act with major changes to FAR was issued in 1996.
Despite its maturity, FAR demonstrates the most flexible and
innovation-friendly mindset:
The FAR outlines procurement policies and procedures that are used
by members of the Acquisition Team. If a policy or procedure, or a
particular strategy or practice, is in the best interest of the Government
and is not specifically addressed in the FAR, nor prohibited by law
(statute or case law), Executive order or other regulation, Government
members of the Team should not assume it is prohibited. Rather,
absence of direction should be interpreted as permitting the Team to
innovate and use sound business judgment that is otherwise consistent
with law and within the limits of their authority. Contracting officers
should take the lead in encouraging business process innovations and
ensuring that business decisions are sound. (FAR 1.102-4 (e))
Furthermore, FAR allows the use of a statement of objectives, which

suits the Agile development process just perfectly:
Performance work statement.

a A performance work statement (PWS) may be prepared by the

Government or result from a Statement of objectives (SOO) prepared
by the Government where the offeror proposes the PWS.
b Agencies shall, to the maximum extent practicable:
1 describe the work in terms of the required results rather than
either ‘how’ the work is to be accomplished or the number of
hours to be provided (see 11.002(a)(2) and 11.101);
2 enable assessment of work performance against measurable
performance standards;
3 rely on the use of measurable performance standards and financial
incentives in a competitive environment to encourage competitors
to develop and institute innovative and cost-effective methods of
performing the work.
c Offerors use the SOO to develop the PWS; however, the SOO does
not become part of the contract. The SOO shall, at a minimum,
include:
1 purpose;
2 scope or mission;
3 period and place of performance;
4 background;
5 performance objectives, ie required results; and
6 any operating constraints (FAR 37.602).
Agencies using Agile software development can meet the require-

ments of FAR 15.203 requiring the provision of requirements in
RFPs by identifying a Product Vision and coupling it with an expla-
nation of how the Agile process will be used to achieve the Product
Vision. Rather than providing a set of ‘how-to specifications’ (or
Requirements Traceability Matrix), the Product Vision will focus on
a desired outcome, similar to performance-based contracting, which
has been permitted by FAR for many years (TechFAR Hub, 2014).
FAR does not dictate the use of fixed price and scope contracts,
despite demonstrating full awareness of its preferences for the
customer: ‘the specific contract types range from firm-fixed-price, in

which the contractor has full responsibility for the performance costs
and resulting profit (or loss)…’ (FAR 16.101 (b)). Furthermore, it
says:
A firm-fixed-price contract, which best utilizes the basic profit motive

of business enterprise, shall be used when the risk involved is minimal
or can be predicted with an acceptable degree of certainty. However,
when a reasonable basis for firm pricing does not exist, other contract
types should be considered, and negotiations should be directed
toward selecting a contract type (or combination of types) that will
appropriately tie profit to contractor performance. (FAR 16.103 (b))
Modular contracting
There are four essential documents related to this subject – FAR Part
39, the Information Technology Management Reform Act of 1996
(Clinger-Cohen Act), the OMB Capital Programming Guide and
Contracting Guidance to Support Modular Development.
All these documents mandate a modular approach to technology
projects, ie dividing investments into smaller parts to reduce invest-
ment risk, deliver capabilities more rapidly, and permit easier adoption
of newer and emerging technologies. Such an approach is consistent
with Agile principles and could be effectively applied to Agile projects.
The Agile Manifesto was published in 2001, while the Clinger-Cohen
Act of 1996 requested that FAR implement the modular contracting
process to ‘provide for delivery, implementation, and testing of worka-
ble systems or solutions in discrete increments, each of which comprises
a system or solution that is not dependent on any subsequent increment
in order to perform its principal functions (US Congress, 1996).
Modular development suggests dividing an investment (system)
into projects, and those into activities. Projects produce a usable
system or functionality that can be implemented and used effectively
independent of future projects. Each project must have its cost
estimate, budget identifying full funding, schedule, performance
expectations, and key deliverables for the product or capability it will

develop and deliver. Each project should have its development lifecy-
cle (eg planning, acquisition, development and deployment) and aim
to provide functional value frequently, producing functionality in as
little as six months. Activities are tasks within a project, each of which
is necessary for the project to be successful. Typical duration of an
activity should be 90 days or less (OMB, 2012).
FAR Part 39, ‘Acquisition of Information Technology’, defines
module contracting as a preferred method of acquiring major systems
of information technology:
a Modular contracting is intended to reduce programme risk and to

incentivize contractor performance while meeting the Government’s
need for timely access to rapidly changing technology. Consistent
with the agency’s information technology architecture, agencies
should, to the maximum extent practicable, use modular contracting
to acquire major systems of information technology. Agencies may
also use modular contracting to acquire non-major systems of
information technology.
b When using modular contracting, an acquisition of a system
of information technology may be divided into several smaller
acquisition increments that:
1 are easier to manage individually than would be possible in one
comprehensive acquisition;
2 address complex information technology objectives incrementally
in order to enhance the likelihood of achieving workable systems
or solutions for attainment of those objectives;
3 provide for delivery, implementation, and testing of workable
systems or solutions in discrete increments, each of which
comprises a system or solution that is not dependent on
any subsequent increment in order to perform its principal
functions;
4 provide an opportunity for subsequent increments to take
advantage of any evolution in technology or needs that occurs
during implementation and use of the earlier increments; and
5 reduce risk of potential adverse consequences on the overall

project by isolating and avoiding custom-designed components of
the system.
c The characteristics of an increment may vary depending upon the
type of information technology being acquired and the nature
of the system being developed. The following factors may be
considered:
1 To promote compatibility, the information technology acquired
through modular contracting for each increment should comply
with common or commercially acceptable information technology
standards when available and appropriate and shall conform to
the agency’s master information technology architecture.
2 The performance requirements of each increment should be
consistent with the performance requirements of the completed,
overall system within which the information technology will
function and should address interface requirements with
succeeding increments.
d For each increment, contracting officers shall choose an appropriate
contracting technique that facilitates the acquisition of subsequent
increments. Pursuant to parts 16 and 17 of the Federal Acquisition
Regulation, contracting officers shall select the contract type and
method appropriate to the circumstances (eg indefinite delivery,
indefinite quantity contracts, single contract with options, successive
contracts, multiple awards, task order contracts). Contract(s) shall be
structured to ensure that the Government is not required to procure
additional increments.
e To avoid obsolescence, a modular contract for information
technology should, to the maximum extent practicable, be awarded
within 180 days after the date on which the solicitation is issued.
If the award cannot be made within 180 days, agencies should
consider cancellation of the solicitation in accordance with 14.209
or 15.206(e). To the maximum extent practicable, deliveries under
the contract should be scheduled to occur within 18 months after
issuance of the solicitation (FAR 39.103, 2015).
Under an indefinite delivery indefinite quantity (IDIQ) contract, the

agency awards an ‘umbrella’ contract to one or more contractors
with a statement of work that describes the general scope, nature,
complexity, and purposes of the goods or services to be procured.
The agency then places orders for specific goods or services within
this general scope of work as needs arise. IDIQ contracts allow the
issuing of small orders for short periods to fulfil particular project
development needs within six-month intervals as well as rapid
response activities in 90-day periods.
The award of a single contract with options may be beneficial
when the integration effort involves unique skills obtainable only
through the success of previous projects.
Successive contracts may be appropriate when there is sufficient
time to award successful individual contracts, the administrative cost
is outweighed by the potential cost/technical benefits derived from
the competitive marketplace, and where contractor continuity is not
a predominant concern.
A performance work statement (PWS) describes desired mission-
related outcomes, rather than how the work is to be performed.
Further, by tying payment to the contractor’s achievement of measur-
able performance standards, it incentivizes the contractor to be
efficient and effective. Such standards could be response or delivery
times, error or accuracy rates, completion milestone rates, and cost
control. A PWS must include remedies to manage performance that
doesn’t meet agreed standards.
A PWS may include the following types of incentives:
●●
Cost-based, designed to relate profit or fee to results achieved by
the contractor about identified cost-based targets.
●●
Award-fee contracts, which use evaluation factors identified in an
award-fee plan. They allow contractors to earn a portion (if not
all) of an award-fee pool established at the beginning of the
evaluation period.
●●
Award-term contracts are very similar to award-fee contracts; how
ever, instead of money as compensation for quality performance,
the contractor is awarded additional periods of performance.
●●
Schedule incentives are focused on getting a contractor to exceed
delivery expectations. They can be defined in terms of calendar
days or months, attaining or exceeding milestones, or meeting
rapid-response or urgent requirements.
●●
Past performance, where assessments are used to motivate
improved performance or to reinforce an exceptional one.
To further add to available contracting options, let’s recall three main

types of contracts: fixed price, cost-based and time-and-material. A
combination of these types with different incentives provides us with
a variety of contracting models, for example:
●●
Fixed-Price Economic Price Adjustment (FPEPA), where the labour or
material costs are continuously adjusted in connection to economic
indexes (COLA, Platts or other).
●●
Fixed-Price Incentive Firm (FPIF), realizing a higher profit by
completing the work below the ceiling price and/or by meeting
objective performance targets.
●●
Fixed-Price Award Fee (FPAF), which is very similar to FPIF, but the
award fee is based on a subjective assessment of the buyer, as opposed
to the formula-based incentive fee.
●●
Cost-Plus Incentive Fee (CPIF) and Cost-Plus Award Fee (CPAF),
similar to the above, but with the base price based on contractor-
declared cost. Such contracts need to be supported by an adequate
accounting system from the contractor that allows buyers to justify
the fairness of the declared cost base (OMB, 2012).
Please note the following instructions from OMB with regards to any
incentive-based contract:
Financial incentives may reduce risk by motivating contractors to meet

cost, schedule, and performance goals. Financial incentives can take the
form of additional profit for reducing cost, faster delivery or improved
performance. Incentives must be used properly. One way to motivate
cost reduction without jeopardizing contract performance is to motivate
based on the ‘probable cost’ resulting from the IBR (integrated baseline
review). The incentive must be large enough to be meaningful to the

contractor.
Significantly faster delivery than required. Agencies need to be mind-

ful of three things when working with delivery or performance
incentives:
●●
Such incentives are only paid for delivery that is faster than not only
what is called for in the contract, but also what is normally done in
the marketplace.
●●
For cost reimbursement contracts, the effort to deliver early to earn
the delivery incentive does not drive up the cost of contract
performance.
●●
The incentive for delivery will not result in delivery before the
Government is ready to use the items.
Delivery of goods/services that significantly exceeds Government

performance requirements. This is when the contractor delivers a
good or service that exceeds the performance requirements (other
than delivery time) stated in the contract. Agencies need to be mind-
ful of three things here:
●●
Agencies should only motivate performance that is significantly above
and beyond contract requirements.
●●
For cost reimbursement contracts, agencies should also be careful that
the effort to exceed Government requirements to earn the incentive
does not drive up the cost of contract performance.
●●
The incentive should not encourage the provision of performance that
exceeds the Government’s needs to meet the agency strategic goals and
objectives. This would be a waste of resources that could be used
elsewhere in the agency where strategic goals and objectives are not
being met (OMB, 2016).
Government agencies have had success with fixed-price incentive

contracts (FAR 16.204, 16.403), fixed-price contracts with award
fees (FAR 16.404), and performance incentives (FAR 16.402-2;
TechFAR, 2014).
Alternatives to modular contracting: advisory multi-step acquisition

Like modular contracting, a multi-step approach has advantages
regardless of the amount of development necessary. In a multi-step
approach, the agency asks for limited information in the first phase.
The requested information typically consists of information about past
performance and experience, a conceptual outline of the proposed
technical approach (versus a particular technical solution), and a rough
order of magnitude pricing. Detailed technical and cost proposals are
not received in the first phase. After requesting and evaluating the
limited information submitted by potential offerors in the first phase,
agencies can then advise each potential offeror whether it is a realistic
contender for award. In general, when the agency does issue the actual
solicitation, in the second phase, all responsible sources, even those
sources that participated in the first phase but were advised that they
were unlikely to be realistic contenders, as well as sources who did not
participate at all in the first phase, are allowed to submit proposals
and have those proposals fully considered. A third step may be added
to allow for a down select to two offerors where a pre-award IBR
will be conducted on each proposal to finalize the cost, schedule, and
performance baselines, complete the risk management plan, and select
the best offeror for award of the contract. (OMB, 2016)
The logic of this process is to allow potential bidders to engage with

the government agency closer to understand requirements and assess
their own capabilities to deliver. An agency could potentially share a
draft RFP for bidders’ familiarization. The feedback could help the
agency to improve the RFP and adjust requirements to the true capa-
bilities of the market. Meanwhile, bidders will have ample time to
decide whether to pursue the RFP and even prepare for it by mobiliz-
ing resources and planning the bid solicitation process:
There is no generally preferred contract pricing mechanism for a multi-

step acquisition. The pricing mechanism will depend on the type of
acquisition. If the acquisition is for a commercial or non-developmental
item or for a limited development effort, it should be a fixed-price
effort; if, however, the acquisition is for a full-scale developmental
system, a cost reimbursement contract may be necessary if the risk is

too great for a fixed-price contract. For development efforts, however,
thresholds should be established beyond which the project would
not be cost-beneficial and should be considered for termination.
(OMB, 2016).
Alternatives to modular contracting: competitive prototyping

Prototyping is the practice wherein an early model of a system, service
or process is built to respond to requirements with a high-level
conceptual design:
To mitigate the risk of full-scale or limited development, agencies may

use competitive prototyping. In competitive prototyping, contractors
offering alternative system design concepts are selected to develop
prototypes of their products. In acquisitions with limited development,
the development work can be completed as part of the prototyping
effort. When limited development is done as part of the prototyping
effort, the contractor would be ready to move to full-scale production
after satisfactorily completing the prototype.
Whether full-scale or limited development is contemplated, both
contractors and the agency can use the competitive prototyping phase
to exchange information. This opportunity gives the contractor a
better idea of what the end users need. Similarly, it allows the agency
to learn what the marketplace can provide. As is the case with multi-
step acquisitions generally, continuing needs definition and market
research in a due diligence effort – conducted with those sources
selected to develop prototypes – allows for an effective and efficient
information exchange. This exchange will foster achieving the best
fit between agency needs and market capabilities. Prototyping also
allows the Government to obtain enough information about the design
and production to be able to determine the product’s subsequent
affordability. A goal of any prototyping and development effort is
to get the project developed to the point that the agency can use
firm fixed-price contract for production and/or implementation.
(OMB, 2016)
Prototyping could complement Agile development as it involves

iterating at the design and planning phase to make structural deci-
sions that are used to steer development, instead of iterating in the
development phase to deliver the MVP. There are so-called l ow-fidelity
prototypes that provide a sketchy view of the desired product
characteristics, which could be used in the competitive prototyping
process for the rapid assessment of the bidder’s capability to
understand the requirements.
Performance-based management of technology projects

Title V of the Federal Acquisition Streamlining Act (FASA) requires
that agency heads must define and approve the cost, performance
and schedule goals for major acquisitions and achieve, on average, 90
per cent of the cost, performance, and schedule goals established (US
Congress, 1994).
The Clinger-Cohen Act requires OMB to develop a process for
analysing, tracking, and evaluating the risks and results of all major
capital investments for information systems – encompassing the
entire life of each system (US Congress, 1996).
The OMB Circular A-11 in Part 7, Appendix J requires the justifica-
tion of the investment to include cost, schedule and performance goals
for the investment that can be measured throughout the acquisition
process using a performance-based management system (eg earned
value management) (OMB, 2012). FAR 34.2 refers to the same: ‘An
Earned Value Management System (EVMS) is required for major
acquisitions for development, in accordance with OMB Circular A-11’.
All the above resonates with Chapter 6 of this book and the find-
ings of the CHAOS report on an alarming ratio of projects that failed
to meet performance, cost or time targets. The project review stage is
often neglected, and many companies don’t have the common meth-
odology for integrating scope, schedule and resources, and for
objectively measuring project performance and progress.
For that reason, OMB suggests implementing the Earned Value

Management methodology (EVM). The PMBOK Guide defines EVM
as ‘A management methodology for integrating scope, schedule and
resources, and for objectively measuring project performance and
progress’ and includes it as a standard (PMI, 2017).
EVM allows the project manager to answer the following three
questions, as they relate to the project: Where have we been? Where
are we now? Where are we going?
In EVM, unlike in traditional management, there are three data
sources:
●●
the budget (or planned) value of work scheduled;
●●
the actual value of work completed;
●●
the ‘earned value’ of the physical work completed.
Earned Value takes these three data sources and is able to compare
the budgeted value of work scheduled with the ‘earned value of phys-
ical work completed’ and the actual value of work completed. For
that matter, EVM uses the following project parameters:
●●
Planned Value (PV) – the approved budget for accomplishing the
activity, work package, or project related to the schedule.
●●
Actual Cost (AC) – the actual cost spent to accomplish an activity,
work package, or project and to earn the related value up to a
given point in time.
●●
Earned Value (EV) – the amount budgeted for performing the
work which was accomplished by a given point in time.
These three parameters are used to define the following performance

measures:
●●
Cost Variance (CV) = EV – AC;
●●
Schedule Variance (SV) = EV – PV;
●●
Cost Performance Index (CPI) = EV/AC;
●●
Schedule Performance Index (SPI) = SPI = EV/PV.
The performance measures shown above provide indicators as to the

status of the project (eg behind schedule, below budget, etc). A perfor-
mance measure with a positive variance (>0) is deemed as favourable,
while a performance measure with a negative variance (<0) is deemed
as unfavourable. Similarly, a performance measure with a perfor-
mance index greater than one (>1) indicates a favourable condition,
while a performance measure with a performance index less than one
(<1) indicates an unfavourable condition.
This collection of measures allows the production of various esti-
mates of cost and schedule forecasting. For example, Estimate at
Completion (EAC) – the expected total cost of an activity, work
package, or project when the defined scope is completed: EAC =
BAC/CPI (BAC = Budget at Completion). Then Variance at Comple
tion (VAC) – an indication of the estimated cost underrun or overrun
at the completion of the project – will be defined by the formula
VAC = BAC – EAC. A positive variance (>0) is deemed as favourable,
while a negative variance (<0) is deemed as unfavourable.
In summary, here are five ground rules for effective Earned Value
Management:
●●
Organize the project team and the scope of work, using Work
Breakdown Structure (WBS). Each task should have a single WBS
number and organizational code.
●●
Schedule the tasks in a logical manner so that lower-level schedule
elements support subsequent elements and the top-level milestones.
●●
Allocate the total budget resources to time-phased control accounts.
●●
Establish objective means for measuring work accomplishment.
The budget should be earned in the same way that it was planned.
●●
Control the project by analysing cost and performance variances,
assessing final costs, developing corrective actions, and controlling
changes to the integrated baseline (IBM, 2010).
AgileEVM
EVM, especially its five ground rules, sound very ‘waterfall’, but it
can be effectively used in Agile projects.
AgileEVM is an adapted implementation of EVM that uses the

Scrum framework artefacts as inputs, uses traditional EVM calcula-
tions, and is expressed in traditional EVM metrics. AgileEVM
requires a minimal set of input parameters: the actual cost of a
project, an estimated product backlog, a release plan that provides
information on the number of iterations in the release, and the
assumed velocity. In order to make estimates numerical, we can use
hours, work days or story points.
Release baseline
NPI Number of Planned Iterations

NPS Number of Planned Story Points
TPB Total Planned Budget
Metrics
NCI Number of Completed Iterations

NCS Number of Completed Story Points
TAC Total Actual Cost
TSC Total Story Points Changed (from original release backlog)
Base values
EPC Expected Percentage Complete = NCI/NPI

PV Planned Value = EPC * TPB
APC Actual Percent Complete = NCS/NPS
EV Earned Value = APC * TPB
Agile EV Metrics
CPI Cost Performance Index = EV/TAC

EAC Estimate at Complete = TPB/CPI
SPI Schedule Cost Index = EV/PV (Singh, 2015).
Just as with waterfall EVM, CP < 1 means being over budget, CP > 1
is under budget. SPI > 1 is ahead of schedule and SPI < 1 is behind
schedule.
The AgileEVM method considers the changes to the backlog after

each iteration. By using the changes to the backlog (the added or
removed estimated story points caused by new or removed features),
you effectively re-baseline after every iteration. Upon re-computing
the AgileEVM after every iteration you achieve validation of the
modified backlog against the release plan.
EVM has been proven to be statistically accurate as early as when
15 per cent of the planned features are completed. The early warning
shown by the AgileEVM metrics validates changes to release plans
and provides the business with the opportunity to make priority
trade-off decisions early in the project lifecycle (Sulaiman, 2007).
Contracting for EVM

Here are some useful guidelines for EVM-based contracting from
the National Defense Industrial Association, Integrated Program
Management Division:
●●
EVM may apply to all contract types when there is a significant risk
to achieving the cost, schedule, and performance goals.
●●
Placing incentives on achieving a Schedule Performance Index
(SPI) or Cost Performance Index (CPI) at or near 1.0 will likely
result in the reported data being managed to those objectives,
thereby diminishing the value of the process by removing early
warning signals.
●●
Compliance recognition documents establish a commitment to
maintain and use the accepted EVMS as an integral
management process on current as well as future contracts.
●●
PMs conduct IBRs (Integrated Baseline Reviews) on contracts
with contractual and in-house EVMS requirements to achieve
a mutual understanding of contract risks and opportunities
and to determine whether the PMB (Performance Management
Baseline) includes the entire scope of work, is realistic, and, if
executed as planned, will meet all of the contract’s technical,
schedule and cost objectives.
●●
As part of their day-to-day management strategy, PMs should use
EVM to ensure effective management of cost, schedule and technical
performance and to identify existing and emerging risks/
opportunities (NDIA IPMD, 2018).
EVM can apply to all contract types listed earlier in this chapter, as it
perfectly fits incentive-based contracts.
EVM is limited to staff augmentation (T&M) contracts, because a
supplier will not control and manage the scope of work and schedule.
Firm-fixed-price (FFP) contracts don’t suit EVM well, as a supplier
does not disclose the internal cost data.
All information and references provided in this section intend to
tease a reader to refer to open sources, such as those of the US
Government, where extensive and diverse information can be found
on any aspect of the procurement process, contracting models, agile
development, and performance management practices.
This information can be used as a practical reference for develop-
ing procurement manuals, especially for government organizations,
and introducing an ample level of flexibility and trust in the procure-
ment officer’s decision, similar to that which FAR exhibits.
References
Federal Acquisition Regulation (FAR) (2015) [online] https://www.acquisition.gov/
browse/index/far (archived at https://perma.cc/J8QZ-5Q5Q) [accessed 18 May
2019]
IBM Center for the Business of Government (2010) Project management in
government: an introduction to Earned Value Management (EVM) [online]
http://www.businessofgovernment.org/sites/default/files/Project%20
Management%20in%20Government%20Report.pdf (archived at https://perma.
cc/N6R9-NSTV) [accessed 18 May 2019]
NDIA, IPMD (National Defense Industrial Association, Integrated Program
Management Division) (2018) Earned Value Management Systems Application
Guide, 2 May [online] http://www.ndia.org/-/media/sites/ndia/divisions/ipmd/
division-guides-and-resources/ndia_ipmd_application_guide_rev_3_may22018.
ashx?la=en (archived at https://perma.cc/C2YX-M5XC) [accessed 18 May
2019]
Office of Management and Budget (2012) Contracting Guidance to Support

Modular Development [online] https://obamawhitehouse.archives.gov/sites/
default/files/omb/procurement/guidance/modular-approaches-for-information-
technology.pdf (archived at https://perma.cc/PXU9-5S84) [accessed 18 May
2019]
Office of Management and Budget (2016) OMB Circular A-11 [online] https://
obamawhitehouse.archives.gov/sites/default/files/omb/assets/a11_current_year/
a11_2016.pdf (archived at https://perma.cc/7SUW-6K7U) [accessed 18 May
2019]
Office of Management and Budget (2019) ITdashboard.gov [online] https://
itdashboard.gov/ (archived at https://perma.cc/H4ZG-4W7D) [accessed 18 May
2019]
PMI (2017) PMBOK® Guide – Sixth Edition [online] https://www.pmi.org/
pmbok-guide-standards/foundational/pmbok (archived at https://perma.cc/8J4V-
97VY) [accessed 18 May 2019]
Powner, D and Barkakati, N (2012) Software development: effective practices and
federal challenges in applying agile methods, GAO [online] https://www.gao.
gov/assets/600/593091.pdf (archived at https://perma.cc/854U-T93W) [accessed
17 May 2019]
Singh, M (2015) EVM and Agile: can they co-exist? Agilious [online] https://
pmiwdc.org/sites/default/files/presentations/%5Bsite-date-yyyy%5D%5Bsite-
date-mm%5D/Agile%20EVM_PMIWDC_2015-12-16.pdf (archived at https://
perma.cc/JNR8-8CH7) [accessed 26 August 2019]
Sulaiman, T (2007) AgileEVM: measuring cost efficiency across the product
lifecycle, InfoQ [online] https://www.infoq.com/articles/agile-evm (archived at
https://perma.cc/HDW4-MPH4) [accessed 18 May 2019]
TechFAR Hub (2014) TechFAR Handbook [online] https://techfarhub.cio.gov/
handbook/ (archived at https://perma.cc/GLW7-R78W) [accessed 18 May 2019]
US Congress (1994) Federal Acquisition Streamlining Act (FASA) [online] https://
www.govinfo.gov/content/pkg/BILLS-103s1587enr/pdf/BILLS-103s1587enr.pdf
(archived at https://perma.cc/9T8R-RS43) [accessed 18 May 2019]
US Congress (1996) Information Technology Management Reform Act [online]
http://www.au.af.mil/au/awc/awcgate/sp/s1124.htm [accessed 18 May 2019]
243
08
Procurement 3.1: Agile, lean,

and value delivery today
As we discussed earlier, business continually evolves under the influ-

ence of megatrends, and so does procurement. To summarize views
as to the path of procurement transformation, we collated the opin-
ions of leading industry analysts. This is how they view the evolution
of our profession in 2020–2025:
●●
Arbiter of risk, reward, and creativity.
●●
At the nexus of finance, operations, and supply chain.
●●
Talent-rich.
●●
Risk forecasters.
●●
Global supply and demand perspective.
●●
Idea generators and innovators (Feinberg et al, 2013).
●●
Value drivers: execution speed and insight.
●●
Procurement role: sourcing advisor.
●●
Business role: disciplined sourcing agent.
●●
Delivery model: hybrid centre of excellence.
●●
Resources: professional advisory staff and customer-oriented
technologies (Gartner, 2019).
●●
Shift focus from cost to value and ROI.
●●
Push smart centralization balancing all improvement drivers.
●●
Approach supplier collaboration and innovation in a different
way.
●●
Embrace digitization to drive, enable, and support this transfor-
mation (PwC, 2019).
●●
Intelligent spend engines.
●●
Advanced analytics solutions.
●●
Seamless B2B ordering.
●●
Zero-based budgeting.
●●
Financial P&L interlink.
●●
Agile organization.
●●
Staying focused on the basics: value capture, measurement, change
management (Boulaye et al, 2019).
The above statements should suffice to get a sense of direction – value

generation and capture, business partnership and advisory, supplier
collaboration, efficient operating model, supply and demand manage-
ment – all of that based on digital technologies.
We have already covered the relationship and operational model
areas. Now we will provide some practical views as to the certain
attributes of Procurement 4.0 that could be gradually achieved now
or in the near future, with no need to wait for tectonic shifts in the
company business model and culture.
The path to procurement agility

‘Agile’ has become a buzzword across many professions. Advisors,
analysts and random strangers are telling us what it takes to become
agile. Quite expectedly, this hype covers up the lack of generally
accepted definitions and standard concepts, so for some advisors
‘agile’ means ‘resilient’, for others – ‘flexible’. Some advisors suggest
differentiating ‘agile’ and ‘Agile’ (the adjective vs the one following
the Agile Manifesto), but most of them provide explanations along
PROCUREMENT 3.1 245
the lines of ‘to be agile… procurement organizations need to have the

knowledge and ability to move quickly’ (Thiede, 2017).
At the same time, agility is the number one item on the list of CPO
priorities in 2020: ‘While cost savings once again remains the top
focus for 2019, agility enters as the key priority for 2020 – showing
CPOs intend to shift their focus to more value-adding exercises’
(Procurement Leaders, 2019).
We have already obtained an appropriate theoretical background
of the Agile Manifesto – development method, suitable contracts,
etc – but this time, we will present what we suggest are the first steps
on the path to procurement agility. Making first baby steps in this
direction will keep us busy until the powers that be from the Big 4
consulting firms step onto the path of enlightenment and tell us what
exactly we need to do to become agile.
Firstly, we need to reiterate – Agile methodology is not a placebo,
and it shouldn’t be used everywhere. From an IT perspective, the
Agile approach is intended for activities that require significant soft-
ware design and development. Some IT needs can be met with
commercially available off-the-shelf items and commoditized services,
such as software licence subscriptions, with little or no development
work. Traditional services and COTS platforms can be effectively
implemented using the waterfall approach; therefore, we have indi-
cated the tendency to develop bimodal IT operational capabilities
(Chapter 4).
Similarly, procurement needs to operate in a bimodal way. We need
to be capable of supporting both agile and waterfall projects.
However, our mentality should always be agile – streamlined, flexi-
ble, less obsessed with governance and documentation, and more –
with value and performance. It must be based on trust with suppliers
and the support of end users. In this respect, agile is rather an adjec-
tive explaining the new procurement mindset.
Factors of resistance
Let us first suggest the possible definition of procurement agility – the
shortest sustainable lead time between the business requirement
formulation and benefits realization (CA Technologies, 2017). At

least, this is what the business expects from Procurement and other
support functions. Our efficiency will be measured by the time to
market and converted into a joint KPI for IT, Procurement and
Finance, and our cross-functional efforts will be subordinate to it.
As a first step, we analysed what current factors resisted our drive
for agility and grouped them as follows:
●●
Planning:
–– Business planning – top-down cycle based on long-term
forecasting with waterfall objectives.
–– Budgeting – tailored to fixed-scope waterfall projects (big
bucket of funds allocated to the full project upfront based on
bulky business cases with questionable long-term assumptions).
–– Project management – PMO used to manage waterfall projects.
–– Capacity planning – resources allocated upfront with no
considerations for ongoing changes in the project pipeline.
●●
Processes:
–– Corporate governance – sequential rigid processes with excessive
controls and overwhelming documentation.
–– Operational model – top-down hierarchical structure divided
by silos.
–– Recruitment – nightmare cycle times of three to six months, lack
of HR processes to deal with short-term labour and freelancers.
Onboarding security checks and entrance permits takes months,
eating up the chargeable project time.
●●
Execution:
–– Sourcing – standard RFx process is anti-agile – inflexible,
reactive, sequential, waterfall.
–– Contract management – lack of agile templates, standard terms
and conditions developed for waterfall projects.
–– SRM – cost-cutting ‘all stick, no carrot’ mentality.
PROCUREMENT 3.1 247
In the following sections of this chapter, we will review the current

state of each resistance factor in more detail, find contradictions to
the Agile Manifesto, and suggest possible (not prescriptive) solutions,
most of which already have worked in practice.
Agility levers: planning

Responding to change over following a plan.
Agile Manifesto, 2001
BUSINESS PLANNING AND BUDGETING

The problem with the current approach to business planning is that
the company is committing to actions and expenditures 12–18
months in advance, while the market conditions, technologies,
consumer preferences and external factors change in nearly real time.
In general, strategic planning has traditionally been an annual top-
down exercise. It typically follows the sequence of scoping the
strategic plan, gathering information, defining goals and objectives,
identifying potential strategies, developing action plans, identifying
measures, and then executing the work in a somewhat linear fashion.
The practical problems with the current paradigm of strategic
planning are:
●●
the absence of feedback loops between operational companies/
units and central administration;
●●
latency or absence of the market intel coming from operations to
the corporate strategy to adjust the strategic approach;
●●
disjointed operational and strategic planning.
The basic steps of an agile strategy development and execution

process might resemble the following:
●●
Take stock – current strategic plans, analyses, competitive environ-
ment scans.
●●
Identify a vision – articulate a destination or a driving force for
change.
●●
Build a high-level roadmap. Develop a small, select set of goals
that drive you toward your vision.
●●
Continually execute:
–– develop and update strategic planning regularly;
–– continuously communicate the strategic direction;
–– execute action plans frequently, along with progress checks;
–– make adjustments (Gates, 2018).
Summarizing all of the above in one ‘formula’: incremental planning

is based on a backlog of strategic initiatives/milestones with frequent
periodic process checks and refinement of the vision with the imple-
mentation of each new initiative (Werder et al, 2017).
Funding is the most frequent showstopper to agile deployment, as
it is hard to change, based on the full project scope, with benefits
attached to features that are preplanned many months, if not years in
advance. The current funding model might contradict incremental
development and won’t support ever-changing business require-
ments, resulting in frequent scope modifications.
There are some working financial solutions for agile projects:
●●
Fund Release Planning activity as a stand-alone WBS, and then
allocate incremental funding to the approved Release Plan.
●●
Seed (MVP) funding to cover a few initial sprints, resulting in a
prototype or an MVP. Upon assessment of intermediate results, the
next incremental funding is allocated or not.
●●
Team (capacity-based) funding. Agile is all about teamwork. You
need to secure a performing team for ample time, so they have a
stable roster and peace of mind to deliver, while the product owner
justifies the outcomes to the funding panel.
●●
Sprint-based funding – with the clear structure of a Scrum team, it
is easy to derive a cost tag per sprint. Then each task translates into
the evaluation of the number of sprint cycles to achieve it and an
associated cost.
PROCUREMENT 3.1 249
PROGRAMME/PROJECT MANAGEMENT
Traditional PMO is based on a command operations centre model
emphasizing consistent process execution from the top down. The
discipline of ‘project management for IT’ employs the waterfall
approach to development, focusing on controlling predefined project
scope, cost, and time.
According to ‘The State of the Project Management Office (PMO)
2016’, these are the top PMO Functions:
●●
PM methodology, standards;
●●
project policies, procedures, templates;
●●
PM coaching and mentoring;
●●
governance process;
●●
alignment of projects with strategic objectives;
●●
portfolio tracking;
●●
multi-project coordination;
●●
roles and responsibilities documentation;
●●
project performance monitoring;
●●
change control and issue tracking;
●●
dashboard/scorecard;
●●
interface with functional units;
●●
project/programme management software;
●●
governance steering committee facilitation (PM Solutions, 2016).
Most of the PMO functions relate to governance, processes, docu-

mentation – quite different from what’s expected of them in the agile
environment.
Let’s see how PMO could become AMO – Agile Management
Office. Four key features distinguish AMO from a traditional PMO:
●●
Tracking. AMO tracks team productivity and product delivery by
applying lean estimation techniques, emphasizing the delivery of
working software. AMO tracks by burndown charts and story
points, but the primary measure of progress is the delivery of
working software.
●●
Coordination. AMO works in a flat structure to support collabora-
tion and alignment between self-organizing teams. Communication
is regular and distributed, as opposed to the centralized mode in
PMO.
●●
Prioritization. AMO prioritizes value delivery and frequently
re-evaluates business needs.
●●
Governance. AMO provides a lightweight form of governance that
focuses on the project’s strategic vision while allowing flexibility at
the task level.
The decision of whether to establish AMO will often depend on an

organization’s experience with Agile, the scale or complexity of the
work being delivered, and leadership’s willingness to help drive a
sometimes-difficult journey of culture change (Kaji et al, 2017).
AGILE CAPACITY PLANNING

This topic deserves a dedicated section, as it represents one of the
familiar challenges to agile development.
Usually, companies engage vendors for software development to:
●●
optimize the cost of development;
●●
achieve flexibility in scaling resources up and down as and when
required;
●●
acquire technological skills not currently available in their
organization;
●●
enhance cross-functional skills and diversity deployed on the
project through outside resources.
The typical IT resourcing model will include a mixture of internal

and external resources:
●●
Internal resources (FTE):
–– expensed through the payroll;
–– extra-long recruitment period (budgeted through the annual
cycle plus 6+ months for recruitment);
PROCUREMENT 3.1 251
FIGURE 8.1 IT Resourcing model

Demand
External
Baseline
Flexible demand
Project 1 Project 2 Project 3
Internal
Time
–– normal unit cost;

–– normal work efficiency.
●●
Project resources:
–– budgeted through business cases;
–– existing resources provided by vendors;
–– high unit cost (still lower than on-call rates due to the long-term
engagement with fewer unitary overheads);
–– OK work efficiency with downfalls on onboarding and
demobilization.
●●
Flexible resources (staff augmentation):
–– budgeted through ad-hoc budget requests or opex;
–– existing resources provided by vendors;
–– extra-high unit cost due to short-term contracts with material
unitary overheads;
–– lowest efficiency due to ever-changing rosters and a need for
each new team member to adjust to the project background,
company processes and working practices, plus onboarding and
demobilization loss of productivity.
Usually, internal resources cannot satisfy even the baseline demand,

not to mention the peak periods. Project resources are added thanks
to long-term projects with sizable budgets, which allow for the

engagement of high-level professionals from suppliers. These projects
add to the available capacity during the implementation period.
Lastly, peak demand periods are covered by on-call supplier resources
involved in short-term time-and-material (staff augmentation)
contracts.
The main problems with this model are:
a high unit cost;

b low efficiency of flexible staff;
c high transactional workload, as any new engagement/extension
of the flexible staff involves a new business case or ad-hoc opex
top-up, both requiring the full cycle of internal approvals.
Further adding to the complexity of IT resourcing, we should mention

that as per the bimodal operational model (Chapter 4), the IT depart-
ment will be delivering both waterfall (legacy products and technolo-
gies) and agile projects (new services and features). Traditional
projects tend to be outsourced to suppliers, who push most of the
jobs offshore to improve the cost baseline. Agile projects require
continuous interaction between team members and hence are executed
onsite.
AGILE RESOURCING SCENARIO #1: ‘PRODUCT OR PORTFOLIO-BASED

OPERATING MODEL’
There is a solution where strategic suppliers are engaged on a portfo-
lio or product basis. An appropriate manager provides the annual
outlook of all projects within her/his portfolio or product domain
and assumes the resource required to manage it. A supplier quotes the
portfolio/product team assigned for a year and unlocks e fficiencies –
stable team roster, shared use of core resources (PM, SA, BA) across
multiple projects within the portfolio, shared support functions,
long-term rates with fewer unitary overheads.
This solution requires the highest level of trust in supplier delivery
capabilities and flexible governance, as the overall scope of the
engagement is going to be dynamic, and a supplier selection based
predominantly on technical merits.
PROCUREMENT 3.1 253
FIGURE 8.2 Product-based operating model of the supplier account team
Portfolio/Product SoW
Project 1 Project 2 Project 3 Project 4 Project 5
Project/Scrum
management
Domain experts/
Business analyst
Project delivery
teams
Quality assurance
Horizontal Solution architecture
services
Programme management office, governance (reviews,
reports, dashboards)
Single billing and invoicing
AGILE RESOURCING SCENARIO #2: ‘ TERM CONTRACTORS’

Project resources can be sourced from the pool of term contractors
provided by specialist HR providers. The usual term of a contract will be
12 months. The unit cost will be more favourable compared to supplier
personnel due to thinner margins (15–20 per cent margin of HR provider
on top of contractor pay) and the engagement lead time will be reason-
able due to using the pool of active candidates. Lastly, these contractors
could be converted to permanent staff based on their proven capabili-
ties, with no need to initiate a full-blown search and selection process.
Furthermore, IT management can assess their annual need for flex-
ible resources and raise one business case to cover the balance
between internal and project resources and the baseline workload.
That flexible resource pool can be engaged for the year based on
contractor resource to optimize the unit cost further.
AGILE RESOURCING SCENARIO #3: ‘PUSHING OFFSHORE’

To further improve the unit cost, Procurement should analyse the
supplier resourcing model for agile projects and try to push some
jobs offshore – part of development jobs, QA, project administration,
change management. The Scrum team of five to eight developers does
not require all members to be physically on-site throughout the entire

project, so some of them could work offshore, accepting incoming
tasks from onsite colleagues and working in a factory mode. It is
worthwhile fighting for each offshore man day, as it will cost 30–50
per cent less than an onshore one.
Agility levers: processes

Working software over comprehensive documentation.
Individuals and interactions over processes and tools.
Agile governance should not elaborate on documentation and

processes and should stick to plans and forecasts. It should be light of
touch and proactive, focusing on activities and the value they bring.
Agile delivery teams should decide on the empirical performance
metrics they will use and self-monitor. Depending on the nature and
specifics of an initiative, the collection of parameters will differ.
Standardized management reporting (if required) becomes part of the
delivery of each sprint.
External assessment of agile delivery is useful, as long as it comes
from agile practitioners and is not obsessed with processes and docu-
mentation. It should assess the team, working methods, communication,
flexibility, quality, etc (National Audit Office, 2012).
To summarize agile governance requirements, we will refer to the excellent

manual by the UK Government.
WHO IS INVOLVED IN GOVERNANCE?

Everyone in the delivery team is responsible for and involved in its
governance. Agile tools and techniques (daily standups, regular planning
meetings and retrospectives) are all ways of governing delivery.
Delivery teams also need help from people who are responsible for
supporting an agile team through management and governance activity.
These are generally:
●●
service owners;
●●
delivery managers;
PROCUREMENT 3.1 255
●●
senior requirement owners (SROs);
●●
auditors and assurers;
●●
digital leaders, chief technology officers and other senior civil servants.
DON’T SLOW DOWN DELIVERY

Your service team must build a service that you continually improve to
meet user needs. As service owner, you should:
●●
find a way to get work done when it’s ‘blocked’ and slowing down
delivery, especially if your team doesn’t have the authority to do so;
●●
be available and make frequent decisions throughout service delivery;
●●
be mindful of the balance between releasing new features and
maintaining quality;
●●
protect the team from, or help them handle, external pressures.
You should keep a good pace of delivery by:

●●
having short, frequent meetings, like standups;
●●
managing risks and issues that will affect the delivery of your service as
and when needed;
●●
basing controls (eg on spending) on the balance between costs and
benefits.
Transition between the phases of service delivery should be seamless, so

people who govern must anticipate problems and make timely decisions to
allow this.
DECISIONS WHEN THEY’RE NEEDED, AT THE RIGHT LEVEL

Iterative development is the best way of handling change and improving
service quality. Embrace that things change, and decisions need to be made
frequently. Make sure that:
●●
decision making is evidence-based and focused on meeting user needs;
●●
the service owner and team have the authority to make decisions and
only escalate when they need to;
●●
you handle change and improve quality through continuous iterative
development.
You should also ensure that service teams know:

●●
that they have the authority to make decisions about the service;
●●
what the boundaries of that decision making are;
●●
who is accountable for helping them when decisions outside the
boundaries need to be made.
RISK MANAGEMENT
Risks can’t be eliminated, and you should highlight and own only the ones
that could affect service delivery.
In agile, you need to deal with risks at the right time. Identify the best
possible moment to respond to important risks and only then start to plan
and carry out your response.
DO IT WITH THE RIGHT PEOPLE

As a service owner or SRO you should:
●●
make sure the people in your team have all the skills they need;
●●
give them the environment, workspace and tools to collaborate,
organize and deliver;
●●
have a flat organization structure so everyone in your team can
contribute to the team’s success.
Make sure that everyone involved in redesigning or creating your

government service is:
●●
capable, motivated and empowered;
●●
focused on goals and outcomes including key performance indicators
(KPIs);
●●
open and honest about what they do.
Find out how to set up a service team for each phase.
GO SEE FOR YOURSELF

It’s everyone’s responsibility to stay well informed. Delivery teams talk face
to face wherever possible and the best way to measure progress is to ‘see
the thing’.
SROs should visit teams regularly and take part in a delivery team’s
meetings, particularly sprint reviews or show and tells. This makes sure
they’re fully informed and can make decisions quickly.
If these meetings aren’t happening, find out why.
PROCUREMENT 3.1 257
REPORTING AND PLANNING

Going to see for yourself and looking at data that delivery teams are
already using to manage delivery, should give you the information you
need to govern.
Walls are an excellent way to track work and show important things, like
what the team is doing and how they’re progressing. It helps planning and
communication within the team and to other teams.
ONLY DO IT IF IT ADDS VALUE

In agile delivery management there’s a focus on giving value to users early
and continuously. This means your team needs to:
●●
have a service vision and goals based on user needs;
●●
set out measures of success and communicate these regularly;
●●
value quality and make sure that user needs are met (give the team time
to do this);
●●
explore and develop ideas that could add value – if they don’t work, try
something else.
To do this the service delivery team should develop a charter (written

document, posters, etc) that describes:
●●
their service vision;
●●
quantifiable goals;
●●
key performance indicators (KPIs) that show progress against meeting
user needs and organizational goals.
TRUST AND VERIFY

Governance should be simple and supportive. It should trust individuals
and give decision-making authority to teams so they can focus on
delivering.
People who govern should regularly speak to the team to help support,
steer and assure. To monitor progress, use a light touch. This means
checking services a little, but often.
Regular reflection on how teams are doing and finding ways to improve
is an important part of good governance. At the end of each iteration every
delivery team holds a retrospective where it discusses lessons learned –
both what went well and what didn’t. This lets you identify actions which
are then planned into future iterations. Retrospectives should also be used
across programmes of work (Gov.UK, 2016).
OPERATIONAL MODEL
We have already discussed options for the procurement operational
model in Chapter 1. All these options retain the subordination of
resources to the centralized procurement function or business units.
This approach lacks agility as it is hierarchical and breaks the end-to-
end process into chunks, which could lead to a lack of integral
responsibility for the value chain.
Let’s look at this from the process perspective. The Agile opera-
tional model is suggested to have the following functional attributes:
●●
End-to-end S2P cycle should not be broken to ensure the integrity
of tasks and KPIs.
●●
S2P strategy and support functions should be centralized to serve
as a relationship centre for stakeholders and suppliers.
●●
Transactional tasks need to be segregated so as not to distract
high-performing resources.
●●
There should be cross-functional alignment with the end-user
Business department, SME (if different from end user, eg HR for IT
resourcing requirements) and Finance. For that, it is advisable to
establish Category Councils.
●●
As discussed earlier, some categories may be retained with Central
Procurement (centralized), and some returned to Business (centre-
led). It is advisable for category teams to keep on reporting to
Central Procurement, while Sourcing could become part of Business.
In view of the above considerations, the agile operating model shown

in Figure 8.4 is suggested as an option.
Category Councils will approve category strategies, review appro-
priate sourcing and organizational initiatives, and moderate cross-
functional disputes. All daily work will be handled within cross-
functional teams.
AGILE RECRUITMENT
Recruitment lead time represents one of the most sizable delays to
agile delivery. The standard process is exceptionally long and uneasy:
brief – sourcing – screening – interviews – shortlisting – verification –
offer – onboarding takes three to nine months depending on security
FIGURE 8.3 S2P cycle
Performance
Category management Source-to-Contract P2P management
Category Demand Buying Supplier

Sourcing Contracting P2P
strategy management channels performance
Core activities
Benefit
Operational planning
realization
Supply base management
Contract life cycle

Spend analysis and BI
management
Support activities
SRM
Stakeholder management
259
260
FIGURE 8.4 Agile operational model
Centralized Centre-led
Central Categories Categories BU
Procurement
Category
(CP) SME
Council
Finance
Sourcing
Middle office Category X Category Y for
Back office Front office Category Y
Key activities Key activities
Key activities Key activities Key activities
• Category strategy • Category strategy and plan
• PO processing • Sourcing support • Procurement strategy and plan • Strategic sourcing
• Invoice processing • Master data and performance
• Strategic sourcing • SRM
• Supplier helpdesk management • Policy and processes
• SRM Location
• Reporting • Capability
Location • Procurement resources are
• End-user development
• Procurement resources distributed between CP and
helpdesk
are located within CP BUs
• Contract and supplier
enablement function Reporting Line
Reporting Line • Proc. resources
• Proc. resources functionally and
functionally and hierarchically report to CP
hierarchically report to or mixed (eg, sourcing
CP hierarchically reporting to
Policy, process and system BU and functionally to CP)
• CP • All category activities

aligned with and approved
by the Category Council
Policy, Process and System
• CP
Back office Middle office Front office

PROCUREMENT 3.1 261
procedures in the country. Therefore, resourcing for Agile is usually

looking at contract or flexible types of resources – expensive, but
quick to engage.
We will not enter HR professional grounds but only provide some
observations from experience. Firstly, term contractors are well suited
to convert to full-time employees – their capabilities are proven in
practice, they are quite open to a long-term contract with family bene-
fits and improved job security, and they have worked in the company
and would not be discouraged with the corporate culture and produc-
tive environment once they have consciously accepted a job offer.
Secondly, the lead time for background checks and job permits,
which could itself be up to six months, can be wasteful, so the
company can hire their candidates through the HR outstaffing part-
ner, while internal full-time hire formalities are ongoing.
Finally, a good option for accelerating agile resourcing is to trust
internal references and shortcut referred candidates straight to the
interview step of the cycle.
Agility levers: execution

Customer collaboration over contract negotiations.
Traditional ‘waterfall’ procurement is characterized by the following

attributes:
●●
Scope represents all the responsibilities of the vendor and describes
precisely what is to be delivered.
●●
Decisions and actions are documented to make all process
stakeholders (including vendors) accountable.
●●
Vendors are successful if they follow the plan and deliver only
what is prescribed. Deviations from the plan are highly problematic,
as they compromise the integrity of a competitive process.
By now, we know that all of that is not possible in agile projects.

Therefore, a cultural shift needs to happen to enable flexible processes,
cross-functional cooperation, increased trust and empowerment of
both internal team members and delivery partners, lighter documen-

tation and an overall dedication to value delivery.
Here is our practical take of what works better in making the
procurement process more agile:
●●
Before the supplier selection:
–– Procurement should actively use comply, demand and process
levers (Chapter 2). Later, the ability to apply traditional pricing
(sourcing) levers will be quite restricted due to the nature of
agile delivery.
–– Scope of work should be replaced with a statement of objectives
with the product vision. The supplier selection process should
be streamlined and favour competitive prototyping.
–– Programme scope should be segregated into logical work
packages to distribute between multiple vendors and de-risk
the programme delivery from the success of a single vendor (eg
separate architecture services from product development and
testing).
–– The supplier prequalification should be moderate on commercials
and hard on delivery capabilities, quality of resources, customer
references, and specific agile expertise.
●●
During the supplier selection:
–– Framework contracts with a panel of prequalified and price-
competitive preferred suppliers help to decrease the lead time
dramatically, as you will select from among a known pool of
capable and price-competitive suppliers. To achieve this, you
need to develop a meaningful sourcing strategy that provides an
outlook for the programme/portfolio/product with its multiple
streams, dependencies, timelines, and budgetary estimates. The
RFx is issued with a general overview of the programme and
a shopping card of agile roles and their specific qualifications,
or sprints. The long list of suppliers provides bids with rate
cards per each type of role that can be assessed individually or
translated into the cost per team/sprint.
PROCUREMENT 3.1 263
●●
Upon the supplier selection:
–– Types of contracts better suited for agile have already been
discussed in Chapter 7. The main differentiator of an agile
agreement is that it is generic in scope and precise on outcomes
(definition of done).
–– Payments should be tied to the delivery of working software
and not just the end of the iteration.
–– Contract management should be replaced by performance
monitoring, so you measure not the initial obligations of a
supplier, but the quality of deliverables and the overall agile
team performance.
–– SRM doesn’t have to stand alone, as it essentially becomes
the procurement process – a collaboration with suppliers, and
performance monitoring with a constructive mindset tuned
into value delivery, trust and empowerment of all process
stakeholders.
Lean management
Lean management is a continuous improvement method, which aims
to optimize productivity by limiting waste of all kinds. Waste in
production processes takes seven general forms:
1 Overproduction: engaging with suppliers at inadequate levels of

granularity, leading to redundancy.
2 Wait time: administration time for the creation of supplier accounts
in duplicate ERPs.
3 Inefficient transport: suboptimal freight loads coming from
suppliers.
4 Useless stock: over-commitment on volumes for obsolete goods.
5 Over-quality: contracts covering goods or services never used or
redeemed.
6 Inefficient processes: fragmented information systems (IS), and

remoteness of internal clients.
7 Redundancy: Reworking erroneous data from IS (nomenclature,
suppliers).
The lean approach to procurement thus includes both ‘natural’ levers

resulting in lower prices, and more sophisticated levers addressing
the TCO and the cost of the function itself (Oliver Wyman, 2019).
The CIPS position on Lean and Agile Purchasing and Supply
Management is that lean thinking and agility can exist side by side in
organizations, with ‘Very Lean’ and ‘Extremely Agile’ being seen at
either end of a continuum; most organizations are placed somewhere
in the middle (CIPS, 2019).
We believe that the elimination of waste is a critical path to agility
in the procurement function and propose the application of earlier
explained methods and tools as the means of implementation of lean
thinking:
1 Tail spend (low-value high-volume transactions, typically 20 per

cent of spend in each category accounting for 80 per cent of
transactions, as per the Pareto rule) is a massive waste due to a
large number of suppliers (many of those could be unknown),
categories, transactions and locations, minimal impact on P&L,
and a resource-intensive nature that distracts procurement from
value-adding activities. Tail spend could be managed through:
–– adjustment of sourcing limits, so most of the tail spend require
ments are covered by a simplified souring process (guided
buying, preferred suppliers, quick quotations, etc);
–– effective and highly automated buying channels (Chapter 2);
–– existing supplier consolidation;
–– connection to an existing supplier network (eg Ariba) to simplify
the search for new partners;
–– contract-to-pay cycle optimization (XML invoicing, PR aggrega
tion and blanket POs to decrease low-value transactions).
PROCUREMENT 3.1 265
2 Master data management represents a sizable opportunity in terms

of waste elimination due to lack of responsibility, resources, and
general awareness of the need to continuously maintain, update
and cleanse procurement databases:
–– Supplier database is often managed on a residual basis, if
managed at all – we don’t mean SRM activities, but a simple
supplier record and spend data housekeeping. The waste piles
up in terms of ‘dead’ suppliers (no POs in years), unmanageable
numbers of transactional suppliers, phantom suppliers dealt
with without POs (hence falling off the radar), inconsistent
supplier data (eg IBM, IBM Middle East, and IBM Middle East
FZE may have three records for the same supplier).
–– Supplier registration may be complicated due to extensive and
inflexible prequalification requirements, sometimes duplicated
across different systems, eg e-procurement for sourcing, ERP for
payment.
–– ERP commodity structure (category tree) may not properly
reflect the category structure in procurement, which most often
happens to technology categories, so we find relevant sub-
categories distributed across multiple other categories (eg business
operational IT systems recorded under business categories). A
messed-up category tree makes spend analysis inaccurate and
misleading.
–– MRP records (SKUs and descriptions) could be messed up due
to different (or no) rules for SKU naming (ABC/123 part number
recorded as ABC by one storekeeper and as 123 by another)
and descriptions (‘water 0.33 l’, ‘bottled water’, and ‘Bon Aqua
water’).
–– Poor MDM processes should be addressed strategically and
consistently through:
a. business case outlining the above deficiencies versus the
benefits of standardization, spend consolidation, improved
governance and data reliability;
b. new operating model that addresses all issues with MDM
and installs resources, responsibilities and controls in place;
c. development of SOP (Standard Operating Practice) for

supplier data entry, item descriptions, SKUs, etc;
d. regular database cleanups;
e. supplier consolidation;
f. enhancement of maverick spend controls (eg you may be
surprised that the legacy company policy ‘no PO, no pay’ is
still being bypassed through direct payments (clearinghouses,
direct debits). No-PO payment is one of the effective waste
elimination methods, but it requires a robust process to
follow and additional technical means to achieve the visibility
of spend and suppliers.
–– Finally, assuming complexity, substantial resource requirements,
and the need for specialized MDM practices, you may consider
developing a business case for MDM outsourcing.
3 Demand management is discussed extensively in Chapter 5 and
eliminates massive volumes of waste by avoiding overproduction,
scaling down over-quality and reusing stocks. Lean procurement
needs to be the key player in the demand management process.
4 The sourcing process must be lean, ie streamlined and flexible,
which requires adjustments to the traditional governance
framework. The process of running RFx events for any sourcing
requirement is lengthy, expensive, and sometimes counter-productive
(eg additional licences or maintenance contracts for existing
platforms can only be sourced from an OEM or their authorized
partners, while the commercial aspects are controlled by an OEM
exclusively). In fact, an inefficient sourcing process could defeat the
entire logic and purpose of agile development, as you will have to
run RFx for any incremental development. The sourcing process
must permit:
–– long-term strategic agreements to develop a partnership with
strategic and critical suppliers;
–– PSL (Preferred Supplier List) to allow Procurement to create
assisted buying channels and approach preferred suppliers with
routine commodity requirements without an RFx;
PROCUREMENT 3.1 267
–– performance-based agreements, where an extension is granted

upon meeting predefined success criteria (especially important
for agile development);
–– procurement of innovation (both the process of innovation and
its outcome). It should be possible to source from innovation
brokers (incubators), award contracts based on competitions
(hackathons etc), give preference to youth/SMEs/minorities,
select suppliers based on the results of prototyping, and run
RFx based on generic business requirements with no specific
technical scope, etc.
5 The contracting process eats up time and resources, since each
contract goes through the full cycle of reviews, modifications and
approvals. The majority of contracts should be based on standard
templates that do not require extensive reviews or are constructed
from standardized and preapproved building blocks from the
clause library.
6 The MOA (Manual of Authority) may contain excessive and/or
duplicated approvals, eg the same Finance people approving a
business case, a supplier selection, a contract and a PO. There
might be a practice of sequential approvals, so if a sourcing project
requires VP approval, the cycle would also include VP-1 and VP-2
levels, while only one of those people knows what the project is
about. MOA efficiency analysis needs to include:
–– number of levels of approval per transaction;
–– number of branches of approval (eg Business, Finance,
Procurement, Legal, CEO office, etc);
–– total number of approvers per transaction per authority limit;
–– total number of approvers per group of related transactions
(project approvals as per PMO workflow, business case, supplier
selection, contract, PR, PO);
–– average duration of approvals at steps of the cycle and by each
branch.
A waste-free MOA could shorten the procurement cycle time

dramatically. A similar exercise conducted recently resulted in the
optimization of source-to-contract cycle time by 35 per cent, and

work is ongoing to further reduce it by 30 per cent.
7 Benefit management is the key to procurement efficiency and ROI
assessment. Where are the millions of procurement savings claimed
each year? Usually, nowhere. Accounting and classification of them
may be incorrect, and savings in future periods may be mixed with
the results of the current fiscal year. The value of savings can be
calculated from the supplier’s first offer. Monitoring of actual
consumption versus the RFx forecast may be absent. Finally, the
savings might get spent on unplanned needs – the available budget
needs to be utilized in full. Several basic principles of savings
management can be introduced:
–– savings are measured against the budget;
–– there is a distinct bucket of savings applicable to the current
fiscal year (‘cash’ savings);
–– reporting is approved by financial control;
–– benefit realization is monitored on the basis of actual consum
ption (not forecasts!);
–– approved savings for the current fiscal year are deducted from a
respective business unit’s budget.
Thus, a real effect is achieved on the financial performance of the

company and so procurement efforts are materialized. We will
provide more detail on benefit management in the next section.
8 The transaction cost in public procurement is estimated at 1.8 per
cent of the contract value (Jurcik, 2012) and falls into three main
categories:
–– Search and information costs: the costs of market research,
functionality assessment, technical and commercial analysis,
proof of concept.
–– Bargaining costs: the costs required to reach an acceptable
agreement with the other party in the transaction and draw up
an appropriate contract.
–– Policing and enforcement costs: contract and performance
management (Banker, 2011).
PROCUREMENT 3.1 269
The elimination of waste in this domain could be largely driven

by procurement automation:
a. Overall cycle time reduction due to e-sourcing and contract
management software estimated at 30 per cent, which
translates to 20–30 business days depending on the complexity
of a sourcing project.
b. Global supplier networks and searchable preapproved supplier
databases dramatically decrease scouting time, which
represents an average of 15 per cent of the total sourcing cycle
time. Meanwhile, the most popular scouting methods are peer
networking, market intelligence reports, and analysis enquiries.
c. RFx thresholds need to be carefully analysed and revisited.
The industry average for a full-blown RFP process is $1
million or more, otherwise simple RFQ or tactical sourcing
events should be applied.
d. Supplier evaluation and selection and contract negotiations
represent 38 per cent of the sourcing cycle time. This is where
the agile approach bears fruit, as supplier selection and
contracting will be dramatically simplified, while most efforts
will be dedicated to performance control (Connaughton and
Albertson, 2017).
9 Inventory management is an El Dorado of waste. Obsolete and
faulty equipment, unallocated marketing materials, stands from
past exhibitions, materials with an old brand – all these are tons
of dead weight and millions of dollars on the balance sheet of the
company. Identifying them, sorting by usability, determining the
book value, preparing for sale or disposal – this is an incredibly
complicated process that few people want to deal with. Procure-
ment and supply management may elect to offload the company’s
balance sheet, optimize warehouse space and associated costs,
and obtain additional revenue through the sale of potentially
useful assets. The financial benefit of this process sometimes
exceeds traditional procurement savings.
10 The operational model needs a lot of attention:
a. On average, 30 per cent of full-time employees are dedicated
to low-complexity tactical sourcing activities that hardly bring
any value. Most of these resources could be released, eg

through application of the preferred supplier list and efficient
buying channels dedicated to high-value-generating activities.
b. As we discussed in the beginning of this book, category
boundaries can become blurred due to technology development
and changing business models. Keeping dedicated teams for
each category results in uneven workloads. There may be a
good time to think about the category CoE (Centre of
Excellence), where most experienced and capable category
managers will form a rapid reaction force to respond to high-
value sourcing initiatives across all categories. Less experienced
resources can attend to medium-to-low-complexity projects
and sourcing execution, once again on a category-agnostic
basis. Besides more effective utilization of skills and better
work morale (as people don’t feel chained to a specific
category), this model could bring 11 per cent of headcount
optimization (as per the worked example in the aviation
industry in Chapter 2).
The 10 lean initiatives for waste elimination described above, along

with many more that you may develop in view of a detailed analysis
and understanding of the business and operational specifics of your
particular company, could bring enormous monetary, resource and
efficiency benefits. There is no limitation to uniting lean initiatives
with agile improvements. Whatever the name of the method or the
mode of thinking, what finally matters is the overall fitness (leanness
and agility) of the company.
Procurement digitalization
First, let’s agree on definitions. We differentiate:
●●
digital procurement – category management of digital products
and services;
●●
procurement digitalization – automation of existing P2P processes;
PROCUREMENT 3.1 271
●●
digital transformation of procurement – complex reconstruction
of the procurement strategy, operational model, processes, and
skills to adopt the benefits of digital technologies and rebuild
procurement to support the company’s new digital business model.
Digital procurement is pretty much the same as technology procure-

ment, but we’ve used the latter term for this book so as not to
confuse our potential readers about our main theme – it is about a
technology-centric professional transformation, not just a digital
overhaul.
Digitalization is the subject of this section. Digital transformation
will be discussed elsewhere, maybe in another book 5–10 years from
now. It is such a complex and fluid subject, lacking in basics – simple
principles, models, and even definitions – and spoiled with the hype
around digital. We suggest starting to rebuild ourselves and automating
basic processes and operations first, and not leapfrogging this evolution.
Digital transformation could be approached in an agile manner.
You can prepare the vision, develop the roadmap, identify the MVP,
and start getting there iteration-by-iteration. Still, the vision is highly
subjective, because it depends on the company and its procurement
approach, so don’t trust those who prescribe a recipe for success to
fit everyone.
We suggest considering the following batch of basic modules to
serve as the foundation of your procurement digitalization:
1 spend analysis;
2 source-to-contract (S2C);
3 contract lifecycle management;
4 procure-to-pay (P2P);
5 inventory management (MRP);
6 SRM.
These modules form the logical sequence – the so-called Source-to-Pay

(S2P) process: spend analysis feeds into S2C for demand management
and sourcing, S2C results in a contract, POs are called off against that
contract, inventories formed and managed as a result of contractual
deliveries, and supplier performance is monitored as part of the post-

award contract management.
One-stop shopping or cherry picking?

Any option is possible if you consider the integrity of the sequence
provided above. The aim is to digitize the end-to-end S2P process, so
any requirement arrives at Procurement in the form of a PR and goes
seamlessly through the process all the way to deliveries and payments.
Any ‘branch’ workflows (eg e-auctions) should not stand alone.
Another important requirement is data integrity. You should be
able to collect data and conduct analysis across the entire S2P work-
flow, ie S2P cycle time in general, S2C and P2P cycle times in
particular, contract value vs PO spend (to monitor forecasted vs real-
ized benefits).
Lastly, all different systems or modules on a single platform need
to share the same master data, otherwise you’ll be swamped with
data entry, management, and cleansing across multiple systems, plus
the data quality might become compromised due to multiple points
of failure.
On-premises or cloud?
Possibly, cloud is a more manageable and less costly solution, as one
SaaS fee covers most of TCO elements, and integration is far less
complex. However, you will have to accept the standardized COTS
solution, with only configuration tweaks and no code changes. Most
of these systems are community platforms that are rolled out to all
customers in their standard form and then updated/upgraded/main-
tained all at once. For the sake of simplicity, cost-efficiency, and
manageability of your e-procurement platform(s), we suggest consid-
ering COTS products in the cloud.
Once you have implemented an integrated solution (single- or
multi-vendor), you may consider bolting on external ‘plugins’, eg
demand forecasting, e-invoicing, etc, that introduce value-added
functionality but do not compromise the integrity of the S2P process.
PROCUREMENT 3.1 273
Value generation
‘Value-delivery projects procurement will lead in 2019’ (Procurement
Leaders, 2019).
Unfortunately, ‘value’ has become another buzzword – we need to
generate, capture and sustain it. Due to ambiguity of definitions,
some people treat it only as a monetary worth. In fact, there are
intrinsic (non-monetary, eg social and environmental) and extrinsic
(economic) values, and procurement can deliver both.
Extrinsic values
Traditionally, procurement was perceived to deliver one type of
extrinsic value – savings. In fact, the procurement value offering can
be much more comprehensive.
SAVING
●●
Cash. To qualify for this type of saving, we need to generate an
immediate effect on P&L for the current fiscal year, ie reconcile
such savings against respective business budgets. Only then will we
improve the bottom line.
–– Unit price. For consumption-based items, the savings are
calculated as the difference between the historical and newly
negotiated price.
–– Budget. Usually, projects are allocated budgets through business
cases and the saving measured against it.
●●
Cost avoidance:
–– Future years. Any savings attributable to the future periods
beyond the current fiscal year are treated as a cost avoidance,
because the future P&L will account for it.
–– Extra deliverables or service level improvement. You may have
negotiated some extra physical items or software licences above
the existing need or extended the warranty period beyond
default or improved SLA from Bronze to Silver. This is a great
achievement, but it won’t improve an immediate P&L, hence it’s
a cost avoidance.
EXAMPLE OF A FINAL OFFER FOR A BUSINESS ADVISORY PROJECT
Price for one consultant: $140,000

Price for one analyst to support the project: $44,000
Price for training of three customer resources: $50,000
Total original price and scope: $234,000
Price for training 10 (increased from three) customer resources (advisory

investment): $50,000
Price for one analyst to support business intelligence project (advisory
investment): $44,000
Discount on the rate of the selected consultant: $10,000
Discounted price at increased scope: $130,000
We claimed $54,000 cash saving (zero cost of an analyst and rate card
discount for a consultant) as we required both and had their rates in the
master agreement. For training, we claimed $50,000 cost avoidance, as it
wasn’t budgeted, though useful to have.
–– Cost increase avoidance. Commodity or CPI index-related prices

(eg, labour-intensive services) can be reviewed periodically, as
per the contract provisions. It is difficult to foresee the value
of such an increase, so it’s being randomly budgeted. If you
managed to fully or partially waive it, then it’s cost avoidance.
–– Monopolistic suppliers (eg SAP, Oracle, Salesforce) can apply
self-defined cost increase rates that are well known in advance.
If you managed to fully or partially waive it and it’s been
budgeted, then it’s a cash saving, otherwise, it’s a cost avoidance.
Technical support acquired with your order may be renewed annually and
for the initial two renewal years the technical support fee will not increase
by more than 4 per cent over the prior year’s fees. If your order is fulfilled
by a member of Oracle’s partner programme, the technical support fee for
the first renewal year will be the price quoted to you by your partner; the
technical support fee for the second renewal year will not increase by
more than 4 per cent over the prior year's fees (Oracle, nd).
PROCUREMENT 3.1 275
While it is very hard to negotiate the waiver of the annual cost increase
with monopolistic providers, you need to dive deep into the relationship
history. Then you may find some interesting facts like this one related to
another single source provider:
TABLE 8.1 Sample comparison of licence count vs price list vs actual billing
Annual list price

Year Number of licences (US $) Billed price (US $)
2015 4 65,609 65,609

2016 10 249,553 149,810.74
2017 10 203,885 149,813.02
2018 6 151,692 149,813.02
New offer
2019 6 173,226 149,813
2020 6 TBD 149,813
2021 6 TBD 157,303.65 (+5%)
While we approached the renewal and were requested to accept the 5 per
cent price increase permitted by the contract, we realized eventually that
our end-user pricing did not have a direct correlation with the global price
list. Furthermore, we cannot foresee the fluctuations of the future price, as
it is defined on an annual basis and could go up or down (this is the usual
case for independent industry providers, who tend to calculate their pricing
on a ‘cost-plus’ basis and sometimes their cost goes down). We were able to
agree a waiver of the cost increase in two years of three in return for the
longer-term commitment – three years instead of one.
●●
Demand reduction. Arguably the most important type of saving, if
you are able to reconcile it against the budget. Negotiated savings
rarely exceed 20 per cent, while a year-on-year price reduction of
5–7 per cent is perceived to be a good result, and you may eliminate
up to 100 per cent of wasteful demand:
–– Wasteful demand elimination. This has already been discussed
in Chapter 5.
–– Reduced consumption. This saving is achieved by implementing

advanced technology solutions and/or improved controls. It
could be as simple as authorizing international dialling by the
cost centre owner, or as sophisticated as fuel efficiency systems
in aviation. This saving is calculated as the monetary equivalent
of reduced consumption minus the cost of implementation.
EXAMPLE OF SAVINGS CALCULATION FOR THE MANAGED PRINT

PROJECT
Current costs (five years consolidated): $10,484,983.65

Solution costs (five years consolidated): $9,411,187.00
Five-year print volume saving: $1,073,796.65 (10.2%) *Based on like-for-
like print volumes
Print management output saving @ 17%: $78,961.00
Colour-to-mono conversion saving @ 25%: $85,901.00
Five-year solution saving: $1,238,658.65 (11.8%)
You can see that not only are the print volume savings there, but also the
practical estimates of reduced consumption due to changed user behaviour
(17 per cent of documents sent for printing are no longer required by users
and have been eliminated due to restriction of automatic printouts –
simply, sometimes you hit the Print button by mistake or realize you need
to make a correction upon sending a document to print) or easy controls
(25 per cent of colour documents could be printed in black and white, if
you set that as the default).
–– Product engineering is one of the most sophisticated types of

saving and can be achieved only by an evolved procurement
function through deep collaborations with product management
and suppliers. This is when the production process is analysed,
and individual components or elements of the process are
improved or replaced with cost-effective analogues. For example,
the production process at Apple is controlled by a team of two
executives – the EPM (Engineering Project Manager) and the
GSM (Global Supply Manager).
PROCUREMENT 3.1 277
●●
Cash flow improvement achieved by negotiating favourable
payment terms, using supplier or country of origin trade financing
vehicles. Savings are calculated on the basis of the cost of capital
over the period of a deferred payment.
●●
Balance sheet savings (inventory/working capital) achieved through
the reduction of inventory or capital expenditure. It is important
that Procurement works closely with Supply Chain to sell or
dispose of slow-moving or obsolete inventories to optimize the
depreciation exposure.
●●
Transactional cost saving should be claimed when the automation
and/or process improvement results in a decreased number of
transactions, eg POs. It is important to identify the cost of transac-
tion to be able to claim that benefit.
●●
Labour cost can be claimed if procurement efforts result in a
reduction of headcount, ie due to decreased transactions. Just
releasing an officer from PO generation duties and loading her/him
with other tasks is not good enough – resources need to be released
or repurposed and respective payroll cost should be eliminated or
moved to another cost centre, eg by transferring a procurement
officer to customer service, while that cost centre eliminates a
vacancy.
A company used to issue 70,000 POs annually, of which 40,000 were

issued by the catering unit alone. They had three officers doing only POs,
some of which were valued at just $2–3. Once the company introduced
electronic catalogues, over 30,000 catering POs were eliminated.
Even assuming a workload of five minutes per PO, the company
eliminated 2,500 man hours of work, ie 1.2 man years. The saving was
evaluated at an officer’s cost to company of $26,000 per annum.
On top of that, there’s approval time by a catering manager (1 min/PO =
30,000 min = 62.5 work days, plus Account Payable time to match a PO
and an invoice and process a payment – from $2 to $10/invoice (Wiggins,
2018). All of this needs to be accounted for and translated into savings.
●●
Staff retention can be influenced by Procurement by creating
favourable job conditions for personnel or influencing staff
satisfaction company-wide. There is a cost attached to recruitment
and onboarding of new staff and if the attrition in the procurement
department is lower than in the company overall, you may claim
the benefit. Affecting company staff satisfaction in general, eg by
delivering a special discount and promotional programme from
suppliers to company employees, isn’t easy to measure, but you
can work with HR to identify certain metrics.
Specifically, the economic studies we examined reveal a number of

patterns about the cost of turnover:
●●
For all positions except executives and physicians – jobs that require very
specific skills – across the remaining 27 case studies, the typical (median)
cost of turnover was 21 per cent of an employee’s annual salary.
●●
For workers earning less than $50,000 annually – which covers three-
quarters of all workers in the United States – the 22 case studies show a
typical cost of turnover of 20 per cent of salary, the same as across
positions earning $75,000 a year or less, which includes 9 in 10 US
workers.
●●
Among positions earning $30,000 or less, which includes more than
half of all US workers, the cost of replacing an employee is slightly less
than among positions earning less than $75,000 annually. The typical
cost of turnover for positions earning less than $30,000 annually is 16
per cent of an employee’s annual salary (Boushey and Glynn, 2012).
REVENUE
●●
Sales of company products/services through reciprocal buying
agreements with suppliers. This is one of the most powerful sources
of revenue generation that needs to be exercised in any sizable deal
negotiation. Some companies run dedicated programmes with
their supplier base with revenue targets, standard contract clauses,
and tailored SRM activities. At the same time, some companies
PROCUREMENT 3.1 279
prohibit reciprocal buying, eg ‘Reciprocity: IBM’s goal is to buy

goods and services which have the best prices, quality, delivery,
and technology. IBM has a policy against reciprocal buying
arrangements, because those arrangements can interfere with this
goal’ (IBM, 2019). You need to study the local legislation and
consult Finance and Internal Audit before implementing such a
programme.
●●
Renting/leasing company assets could generate regular revenue
streams. Some companies, eg telco operators or government
entities, possess diverse property assets – offices, technical buildings,
warehouses. It is possible to optimize the internal use of those
spaces and sublease them. Suppliers can rent small spaces in airport
lounges, sales offices, and customer service centres to install their
kiosks. They can rent a desk in your office for a sales agent if they
run any dedicated staff promotion.
●●
Revenue share agreements are useful for any third-party business
that also serves your clientele, eg visa or travel insurance for
airlines, mobile devices and accessories for telco operators, office
food catering for any large company, etc. Even a small car-washing
company serving your employees in the office parking space could
provide a revenue share.
●●
Marketing revenue achieved through sales of company marketing
assets. The company may sell the naming rights of a venue, brand
an aircraft to promote a computer game or sports event, or simply
serve beverages to service centre visitors in supplier-branded paper
cups. Nowadays, digital marketing assets – website, mobile app,
social channels, customer e-newsletters – are some of your most
useful, and can be monetized through targeted campaigns by your
suppliers.
●●
Sales of obsolete assets can generate small revenues and help
offload the balance sheet. You may sell large technology assets to
specialized brokers or old company cars, retired IT devices, unused
campaign promotional materials – to employees or the general
public on e-auctions.
●●
Time-to-revenue is another uncommon benefit that can be
measured and reported. Let’s assume that a business case forecasted
the delivery of a new technology platform, which will generate
$100,000 in new monthly revenue, in 12 months. Procurement
completed the source-to-contract cycle one month earlier and
worked with a preferred supplier to optimize the delivery and
deployment time by a further two months. Then Procurement may
lawfully claim $300,000 revenue benefit due to achieving the
commercial launch three months earlier than planned.
Here are a few important notes that apply to all types of savings,
revenues, and efficiencies:
1 To be able to claim it, you must be able to prove it’s been driven by
Procurement. If your engineers implemented a fuel efficiency system
or product managers found a cost-effective replacement for a
production component, and Procurement just happened to help
them negotiate a contract, then they may only claim the price
reduction, but not the overall efficiency gain or long-term production
cost improvement. Otherwise, if you have analysed the spend,
consumption and demand, and generated a cost-saving idea, then
you should claim the full benefit, even if the engineers have helped
you to implement it.
2 Any Procurement benefit needs to be controlled and approved by
Finance. Any reports generated by Procurement for executive
management are only good for self-promotion. If you’re willing to
make a true impact on the P&L, then you need to reconcile every
dollar of savings with Finance, and presumably with Business, as
long as their budget is going to be deducted for the value of the
savings.
3 You have to consider the difference between estimated and realized
savings, especially for consumption-based items. Once you have
signed a two-year contract for 1,000 pcs and saved $100/pc, you
cannot claim $100,000 saving upfront. You need to monitor the
actual consumption for at least three months and then make some
fair estimates. Otherwise, you may claim a part of the saving
upfront and the rest at the end of the contract term based on actual
consumption.
PROCUREMENT 3.1 281
4 Reporting savings and revenues in an accurate, consistent and

timely manner is one of the most important tasks in procurement.
If you want to make a difference and deliver value, then you need
to dedicate yourselves to this process all the way to the budget
adjustment, because only then will your efforts materialize.
Intrinsic values
Intrinsic value refers to investor perception of the inherent value of
an asset. Procurement is one of the company’s assets, so this section
will talk about its perceived value. We need to analyse what makes us
useful or important for the company, apart from the monetary values
identified above.
●●
Relationships are Procurement’s number one value. We sit in the
centre of the network formed by our suppliers, stakeholders,
employees and customers, and effectively influence all of them
through:
–– Support. This is expected by stakeholders and suppliers as the
default value of Procurement. We need to smooth and optimize
operational processes, orchestrate the supply chain and carry
the burden of mandatory paperwork.
–– Moderation. Procurement is expected to resolve conflicts
between stakeholders and suppliers and maintain the balance
between the continuity of contract obligations and performance
requirements by end users. Procurement needs to act as an
independent arbitrator that does not take sides and will pursue
the interests of the business as such, not just a business unit.
–– Advice. Procurement should advise on various aspects –
mandatory processes, commercial viability, supplier relationship,
supply chain management – and support their advice with
comprehensive data and logical structures. Procurement’s opinion
should be complementary to subject matter expertise to provide
a holistic view of a subject from an independent perspective.
–– Satisfaction. Procurement performance should be largely measured

by the satisfaction of the value chain actors – stakeholders,
suppliers, employees and customers. Our role is somewhat like
air traffic dispatchers – we do not operate the individual elements
of the value chain, but interconnect, orchestrate and align them,
and therefore need to maintain everyone’s involvement, security
and satisfaction to an acceptable level.
●●
Risk management is the future of the procurement profession,
alongside relationship management. We need to be able to aggregate
multiple streams of information – global economic and political
trends, market and industry dynamics, supply base analysis, local
specifics – into a single dashboard and provide early warnings,
mitigation plans, and operational overhauls to various types of
risks. There is no other company function better suited for these
tasks, as we have the longest reach within the supply chain and the
ability to aggregate and analyse multiple views from inside and
outside the company.
●●
Brand. Procurement directly affects brand values, especially:
–– Quality. Whatever the company business strategy requires –
premium materials or low-cost yet reliable ingredients – we are
there to ensure the best fulfilment of quality requirements.
–– Affordability. Procurement has the strongest influence on the
cost competitiveness of company products and services.
–– Availability. As long as Procurement is not detached from the
supply chain management and S&OP processes, we are the
ones to orchestrate the inflow of materials and services into
the production process to maintain the required availability
standards.
●●
All three elements of brand values should be affected by procure
ment, not only through traditional ‘rights’ – quality, price, place – but
through the strategic alignment of Procurement and the business.
Procurement for a premium product company and a cost-aggressive
new market entrant will operate differently – in terms of a
procurement strategy, operating model, service standards, KPIs, etc.
PROCUREMENT 3.1 283
●●
Social. These elements of value were extensively covered in
Chapter 4:
–– sustainability;
–– integrity;
–– give back.
Let’s not forget that value generation is the top expectation of a busi-
ness with regards to Procurement’s contribution. We must provide
diverse intrinsic and extrinsic value offerings to secure our place in
the future business model of Industry 4.0.
Change management and communication

Simply telling everyone you’re going agile will not be sufficient. Such
major cultural shifts require a carefully constructed and consistently
implemented change management programme.
Change management has many names and faces. In 1969, Elizabeth
Kubler-Ross explained the ‘Five Stages of Grief’ – denial, anger,
bargaining, depression and acceptance. Despite that model having
been developed on medical grounds, it appeared to describe well the
generic human reaction to change.
Essentially, organizational change management is intended to
hand-hold employees in their walk through the ‘Death Valley of
change’ (from depression to acceptance), when emotions hit the
lowest level. Furthermore, change management needs to be continu-
ous, cyclical and ongoing to make changes stick.
A typical change management process includes three streams –
change-impact assessment, communication, and training.
To address the human side of change, we need to explain (a) why
the change is necessary and (b) what it means to an individual. The
change journey starts from the top, so the leadership has to embrace
it and create the vision. Next, the middle layer is penetrated by change
agents, where the vision is explained through cross-functional teams
and regular communication. Eventually, the base (employees) needs
to be mobilized, trained, and continuously supported to enable the
gradual cultural shift.
284
FIGURE 8.5 Typical change management process
3 mths before go live Go-live
(minimum)
Communi- Awareness Understanding Go-live support

cations plan communications communications communications
Document detailing Tools: Posters, intranet, Tools: Day in the life scenarios, Tools: Go-live
what communications presentation packs newsletters, posters, intranet countdown
will be delivered and updates messages,
how Change intranet updates
Measure readiness to change readiness
assessment
Through a series of pulse surveys, we will Change readiness
Understand WHO Change Impact assess the readiness of the department assessment:
is impacted Assessments (CIA) Document
detailing Support
Explain what’s changing Go-Live Evaluation
Stakeholder plan Change impact assessment– the readiness of
– Identify key the deliverable will focus the Finance
stakeholders on the following: What’s changing overview – engagement stream to absorb
– Identify change – Start: What activities will tool that will paint a clear picture of key the intended
champions start as result of change changes by function and audience group changes
– Identify affected – Stop: What activities will
user groups stop as result of change
– Continue: What activities
will continue as result of
change Identification and engagement of
change champions
Change champion roles and tool kit – appointment, education
and support of development of localized delivery plans
Develop training Training needs Training delivery Training Training

strategy analysis (TNA) plan (TDP) development delivery
Training strategy: Training needs Training delivery Training
– Approach to training analysis: plan: development:
– Method/mediums – Module outlines – User groups and – Training objects
– How training will – Resource number of people and materials
be evaluated requirements to be trained
– Evaluation methods
PROCUREMENT 3.1 285
We will not dive into the theory of change management; this book is
not intended for that. As usual, we will try to give some practical
advice around what has worked in various change management
programmes.
●●
Vision needs to be articulated clearly. The company wants to
become agile not because it’s trendy, but to achieve some tangible
efficiencies. The vision can be explained to individuals in common
terms, eg agile methods will increase the competitiveness of the
company, and so it will secure jobs, enable new personal develop
ment opportunities, and drive organizational shifts. People care
about their jobs, salaries, promotions, trainings, and interesting
tasks – so the vision needs to touch the right strings.
This programme gives us the opportunity to not only upgrade our

back-office IT systems, but to improve our processes, ensuring that we
embed operational excellence into our practices. It is about transforming
and simplifying business processes from start to finish, reducing
unnecessary duplication and time-consuming tasks, and introducing
more transparency and efficiency across these three key functions.
Do you think this vision appeals to people?
●●
Baseline must be established prior to triggering the actual change
process. The success of the programme needs to be measured and
possibly monetized. Don’t take the word of advisors giving you
industry-average percentages of savings or additional revenues. The
benefits of agile should be explained in terms of the accelerated time
to market, optimized headcount, improved productivity, budget
savings – but most importantly the new revenue enablement and
increased customer satisfaction. As we have reiterated on multiple
occasions, the purpose of any business activity is value delivery.
●●
Executive support is not only about attending steering committees
and issuing decrees to accelerate and mobilize; it’s about advocating,
converting and persisting. Executives should become change agents
themselves, and lead the change by example in their daily work.
From the project quality assurance report:

●●
Executive leadership and Programme governance have diminished over
time due to conflicting business priorities. It appears that there is a high
demand on the Chief’s time for Executive Steering Committee
attendance, for which we are perceived as an update forum rather than
an executive decision-making forum with efficient reporting and strong
ownership of issues and risks. The publication of the Executive Steering
Committee pack restricts the opportunity for individuals to consult
widely and socialize issues when a pack is only received the day before
the meeting, thus diminishing the capacity for the Executive Steering
Committee to act as said forum.
●●
The focus within the Programme has been the technical delivery of the
ABC application with little focus on the business change required to
implement the benefits. Stakeholder recipients of the business change
benefits have yet to produce plans for the change required with detailed
resourcing and phasing of benefits realization.
●●
There is a lack of forward guidance for the Executive Steering Committee
from the Programme Director or PMO as to what decisions are required,
what risks need to be addressed, and what the impact is on benefits within
the business case for the Programme. Reporting and information provided
to stakeholders is retrospective and focused on immediate project delivery
rather than outcomes of the Programme on achievable benefits.
●●
Change champion is a full-time job. She/he needs to be a part of
many teams – project leadership, SME (subject matter expert) and
cross-functional change management. Assigning this array of
duties in addition to the daily routine job is one way to overload
an individual and kill a passion for change.
●●
Post-cutover continuity of change management should be maintained
to ensure long-lasting results. In many programmes, cutover date is
when the change is expected to have been implemented; however, it
needs to be reinforced to transform into an operational routine.
People need to continuously practise the change and receive recogni
tion for it. Communication needs to be maintained post cutover,
even more extensively than before.
PROCUREMENT 3.1 287
With this chapter we want to persuade you that becoming ‘agile’,

‘lean’ or ‘disruptive’ is actually possible. Our existing processes
already contain the means for agility, and you don’t need to wait for
the corporate big-bang change management programme to run your
first sprints. Try to apply agile methodology to the process of becom-
ing agile. Create a vision, specify a roadmap, identify an MVP – the
best level of agility you can reach without changes to corporate
processes – and start reaching out increment-by-increment. You
won’t believe how much it is possible to achieve with a will, method
and consistency. Good luck!
References
Agile Manifesto (2001) [online] https://agilemanifesto.org/ (archived at https://
perma.cc/P8JZ-TW3N) [accessed 20 May 2019]
Banker, S (2011) Transaction costs, supply chain management, and the new
economy, Logistics Viewpoints, 27 June [blog] https://logisticsviewpoints.
com/2011/06/27/transaction-costs-supply-chain-management-and-the-new-
economy/ (archived at https://perma.cc/A7VF-AUL8) [accessed 20 May 2019]
Boulaye, P et al (2019) Revolutionizing indirect procurement for the 2020s,
McKinsey & Company, April [online] https://www.mckinsey.com/
business-functions/operations/our-insights/revolutionizing-indirect-procurement-
for-the-2020s (archived at https://perma.cc/U88F-8P5W) [accessed 20 May 2019]
Boushey, H and Glynn, S J (2012) There are significant business costs to replacing
employees, Center for American Progress [online] https://www.americanprogress.
org/issues/economy/reports/2012/11/16/44464/there-are-significant-business-
costs-to-replacing-employees/ (archived at https://perma.cc/XUS7-TSAE)
[accessed 26 August 2019]
CA Technologies (2017) A CIO’s guide: five steps to business agility [online] https://
www.ca.com/content/dam/ca/us/files/white-paper/a-cios-guide-five-steps-to-
business-agility.pdf (archived at https://perma.cc/K2PB-F2LV) [accessed 20 May
2019]
CIPS (2019) Lean and Agile Purchasing and Supply Management [online] https://
www.cips.org/documents/Lean_and_Agile.pdf (archived at https://perma.cc/
P68G-GF96) [accessed 20 May 2019]
Connaughton, P and Albertson, K (2017) Digital transformation reduces strategic
sourcing costs and cycle times by 30%, The Hackett Group, 10 April [online]
https://cdn2.hubspot.net/hubfs/514030/0_Global_BravoSolution/1_Global_2017_
Hackett%20Webinar/Hackett%20Group%202017%20Sourcing%20Cycle%20
Time%20and%20Cost%20Measurement%20Study.pdf (archived at https://
perma.cc/C94P-JN9Y) [accessed 20 May 2019]
Feinberg, A et al (2013) Charting the course: why procurement must transform
itself by 2020, Deloitte [online] https://www2.deloitte.com/us/en/pages/
operations/articles/procurement-transformation-charting-the-course.html
(archived at https://perma.cc/Q2P5-QWCB) [accessed 20 May 2019]
Gartner (2019) Procurement in 2020 and beyond: 5 shifts procurement must make
for the future [online] https://www.gartner.com/en/procurement-operations/
trends/procurement-in-2020 (archived at https://perma.cc/99A2-XKL4)
Gates, L P (2018) Agile strategy: short-cycle strategy development and execution,
Software Engineering Institute, 25 June [blog] https://insights.sei.cmu.edu/sei_
blog/2018/06/agile-strategy-short-cycle-strategy-development-and-execution.
html (archived at https://perma.cc/XWA6-RS5T) [accessed 20 May 2019]
Gov.UK (2016) Agile delivery: governance principles for agile service delivery, 23
May [online] https://www.gov.uk/service-manual/agile-delivery/governance-
principles-for-agile-service-delivery (archived at https://perma.cc/E7PT-JUCH)
IBM (2019) Global procurement: policies and procedures [online] https://www-03.
ibm.com/procurement/proweb.nsf/contentdocsbytitle/United+States~Policies+
and+procedures (archived at https://perma.cc/3VW3-9FP6) [accessed 20 May
2019]
Jurcik, R (2014) Transaction costs and transparency of public procurement,
WSEAS [online] http://www.wseas.us/e-library/conferences/2014/Brasov/
FINANCE/FINANCE-26.pdf (archived at https://perma.cc/29ZP-TBCM)
Kaji, J et al (2017) Agile in government: a playbook from the Deloitte Center for
Government Insights, Deloitte Insights [online] https://www2.deloitte.com/
content/dam/insights/us/articles/3897_Agile-in-government/DUP_Agile-in-
Government-series.pdf (archived at https://perma.cc/6DV8-WK4Q) [accessed 20
May 2019]
Kubler-Ross, E (1969) On Death and Dying, The Macmillan Company, New York.
National Audit Office (2012) Governance for Agile Delivery [online] https://www.
nao.org.uk/wp-content/uploads/2012/07/governance_agile_delivery.pdf
(archived at https://perma.cc/38UJ-SWFC) [accessed 20 May 2019]
Oliver Wyman (2019) How continuous improvement methods contribute to
procurement [online] https://www.oliverwyman.com/our-expertise/
insights/2018/mar/how-continuous-improvement-methods-contribute-to-
procurement.html (archived at https://perma.cc/W3QE-FETJ) [accessed 20 May
2019]
PROCUREMENT 3.1 289
Oracle (nd) Oracle License and Services Agreement [online] http://www.oracle.

com/us/corporate/pricing/olsa-gr-v020703-070544.pdf (archived at https://
perma.cc/M5XT-34ZJ) [accessed 20 May 2019]
PM Solutions (2016) The state of the project management office (PMO) 2016:
enabling strategy execution excellence [online] https://www.pmsolutions.com/
reports/State_of_the_PMO_2016_Research_Report.pdf (archived at https://
perma.cc/5EV4-3BP2) [accessed 20 May 2019]
Procurement Leaders (2019) 2019 Procurement Landscape [online] http://
accelerate.procurementleaders.com/rs/568-MWH-043/images/Procurement%20
Landscape%202019_Infographic.pdf (archived at https://perma.cc/6GF6-
XSKC) [accessed 21 May 2019]
PwC (2019) The Future: Procurement 2020 [Online] https://www.pwc.co.uk/
industries/retail-consumer/procurement/future-procurement-2020.html
(archived at https://perma.cc/J5LM-6XL7) [accessed 20 May 2019]
Thiede, C (2017) Agile procurement: what is it and how to achieve it, Procurement
Resources, 19 April [online] https://www.jaggaer.com/agile-procurement-
achieve/ (archived at https://perma.cc/QG8P-CXER) [accessed 20 May 2019]
Werder, M et al (2017) Be agile: taking the agile transformation journey, Accenture
Consulting [online] https://www.accenture.com/_acnmedia/PDF-67/Accenture-
Taking-The-Agile-Transformation-Journey.pdf (archived at https://perma.
cc/3MXP-JJ5T) [accessed 20 May 2019]
Wiggins, P (2018) Metric of the month, CFO.com [online] https://www.cfo.com/
expense-management/2018/02/metric-month-accounts-payable-cost/ (archived
at https://perma.cc/H659-KWCZ) [accessed 26 August 2019]
290

291
09
Conclusion
This book was created for those who don’t feel they have achieved
their best, yet. There is so much more to learn and embrace, and the
beauty of our job is that it always welcomes new ideas and actions,
it’s not stubborn or rigorous. Any problem can be solved, sooner or
later, from different angles, with diverse tools and in cooperation
with various partners and stakeholders. Just recall FAR: ‘Rather,
absence of direction should be interpreted as permitting the team to
innovate and use sound business judgment that is otherwise consist-
ent with law and within the limits of their authority. Contracting
officers should take the lead in encouraging business process innova-
tions and ensuring that business decisions are sound’ (FAR, 2015).
Once you find yourself in a procurement role or as a member of a
cross-functional team assembled to source a complex technology
product or service, we suggest having a think about the critical differ-
entiator of your procurement professionalism. It should not be just
hunger for discounts or the religious execution of an RFP routine.
You need to understand the underlying technology at a conceptual
level. You have to know what the core business requirements are.
You must be able to separate a value demand from a wasteful one.
Your negotiation toolkit must be diverse, innovative, and purpose
driven. You should be able to understand a business case, service
design package, or a project management plan and translate it into
negotiation arguments and contract provisions.
Let’s recall what we have discussed: four pillars, technology service
lifecycle, and strategic procurement process, relationship management,
agile and lean procurement, principled negotiation – this is not an

exhaustive toolkit of things you can apply to deliver the value the busi-
ness is looking for. This book is not a guideline to follow religiously; it is
rather a collection of useful facts, ideas, advice, and practical experience
to help you develop your unique approach to mastering the profession.
The material in this manuscript is highly perishable, as new tech-
nologies, concepts, and methods are emerging continuously, and
what works well today might become obsolete tomorrow. Therefore,
we are not feeding you dogmas and prescriptions – we tease your
taste buds with ideas and ‘what if’ scenarios. From the ingredients we
are offering, it’s up to you to cook a hearty traditional dinner or a
lightweight fusion snack.
The fourth industrial revolution requires Procurement 4.0, which
is agile, supportive, customer-centric and value driven. The entire
paradigm is shifting from governance and cost-cutting to value gener-
ation, speed of execution, and partnership with the business and
suppliers. Therefore, procurement integrates with the business to
share common values and achieve joint results.
Currently, procurement is at a crossroad of possible evolutionary
directions, and if we don’t choose the right path, our profession may
become extinct. Business is unforgiving to rudimentary functions and
is equipped with diverse tools to divest itself of them – outsourcing,
automation and decentralization will take their toll on those who are
stuck in the past.
Let’s ask ourselves, what can we do better than global outsourcing
or shared service centres packed with capable and cost-effective
professionals, managed by best practice processes and automated by
cutting-edge solutions. Those are highly standardized factories that
cannot nurture and develop relationships, leverage business strategy,
mitigate risks, create custom designs – so our safe haven is made up
of uniqueness, creativity and humanness, plus a constant drive to
over-achieve KPIs and overhaul the job description.
In the following list, we try to provide an overview of Procurement
4.0 from the perspective of our professional development. Maybe (or
maybe not) this is what we should become to survive and blossom
forth:
CONCLUSION 293
1 Relationship brokers and impartial conflict moderators in the cross-

junction of the business network.
2 Masters of common sense – in our actions, we should operate
with simple but effective logic that summarizes the cross-functional
teamwork.
3 Semi-pros in many specialisms – supply chain, finance, contract
law, technology, data analysis, business development, psychology…
to be continued.
4 Most conservative in the business, most adventurous in operations,
so we ensure a diversity of views and opinions.
5 Being systematic should become our motto. Our jobs are cyclic and
we must never get too tired to finish them (sourcing, contracts, bene-
fits) and start a new cycle. We’re not a factory line but we always
complete what we have started. We implement and operate the
system – not just selective support for one project or supplier, but a
fair and consistent framework applicable to every party within the
network.
6 We are omnipresent and instrumental in any value-generating
process.
The business model of the future is a fluid concept that changes under
the influence of megatrends. So, procurement may become a business
unit, marketing, advisory, or a pinch of everything – don’t wait until
that is clear, never stop evolving. ‘According to Darwin’s Origin of the
Species, it’s not the strongest of the species that survives, nor the most
intelligent, but the one most responsive to change’ (Megginson, 1963).
References
Federal Acquisition Regulation (FAR) (2015) [online] https://www.acquisition.
gov/browse/index/far (archived at https://perma.cc/J8QZ-5Q5Q) [Accessed on
May 18, 2019]
Megginson, L (1963) Lessons from Europe for American business, Southwestern
Social Science Quarterly, 44 (1) pp 3–13
294

295
INDEX
NB: page numbers in italic indicate figures or tables
5G technology 20 Android 111
Apple 34, 171
Accenture 67 application and desktop virtualization 70
adaptive maintenance 95 Industry 5.0 3
advisory multi-step acquisition 234–35 avoidable demand 140
Agile approach 76–81, 77, 200, 223–36
Agile Manifesto 175, 228, 245 Bang & Olufsen 111, 171
AgileEVM 238–40 Berne, Eric 128–29, 130
effective practices 201–05 big data 4, 5, 19
evaluation 204–05 bimodal IT 14
execution 203–04 bottleneck suppliers 219, 220
organizational commitment 202 business process outsourcing (BPO)
people and processes 202–03 147–48
strategic planning 201–02 business unit procurement (SAP) model 11
Federal Acquisition Regulation
(FAR) 223, 226–28, 291 category management 27–32
pricing 227–28 defining 27
Product Vision 227 example 30–32
statement of objectives 226 foundations of 27, 29–30
modular contracting 228–36 framework 28
vs advisory multi-step outsourcing of 8, 11
acquisition 234–35 centralized procurement model 6, 7
vs competitive prototyping 235–36 ‘centre of excellence’ 8, 9, 270
contracting models 232–33 change management 283–87, 284
Federal Acquisition Regulation change champions 286
(FAR) 229–30 embedding change 286
indefinite delivery indefinite quantity executive support 285–86
(IDIQ) contract 231 success, measuring 285
performance work statement vision, communicating 285
(PWS) 231–32 CHAOS report 200–01, 236
sample contract 77–81 Chartered Institute of Procurement &
scope freeze 158, 172 Supply (CIPS)
vs Waterfall 81, 82, 223–26 category management 27
collaboration 225–26 lean and agile procurement 264
development and delivery 224 vision of the future 4, 102, 136
project planning 224–25 Cisco 34, 99
status evaluation 225 climate change 2
see also procurement agility Clinger-Cohen Act 228, 236
Al Maskati, Heyam 14–15 cloud auditor 59, 59
Amazon 55, 62 cloud broker 59, 59
Dash Replenishment 4 cloud carrier 59, 59
296 INDEX
cloud computing 12, 19, 56–71 cyberphysical systems (CPS) 3–4

benefits of 60 integrated supply chain 4
business models 67–70
horizontal 69 Darwin, C 293
‘on top’ 69 data-enabled procurement 4–5
vertical 69 data security 187–88
characteristics 56–57 decentralized procurement model 7, 9
Cloud First guidelines 63–67 demand levers 36–37
defining 56 demand management 140–43, 266
deployment models 58 demand reduction 275–76
deployment of 60 Deming cycle 125
NIST cloud computing reference digital transformation 271
architecture 58–59, 59 digitalization of procurement 270–72
service models 57–58, 62–63, 63 DIKW mode (Data, Information,
virtualization 70–71 Knowledge, Wisdom) 5
cloud consumer 59, 59 Docusign 86
Cloud First guidelines 63–67 Dunn and Bradstreet 100
Cloud Infrastructure as a Service
(IaaS) 57–58, 62, 63 Earned Value Management (EVM)
Cloud Platform as a Service (PaaS) 57, 237–41
62, 63 AgileEVM 238–40
cloud provider 59, 59 contracting under 240–41
Cloud Software as a Service (SaaS) 57, 60, environmental and social audit 119
62, 63, 272 Equinix 62
commercial off-the-shelf software (COTS), excess demand 140
using 71–72 external audit 117–18
‘buy and build’ 81
customizing 72, 199 failure demand 140
fit and gap analysis 151 Federal Acquisition Regulation (FAR) 223,
time limitations 72 226–28, 291
Waterfall model 245 modular contracting 229–30
community cloud 58 pricing 227–28
competitive prototyping 235–36 Product Vision 227
comply levers 36 statement of objectives 226
Concur 20 Federal Acquisition Streamlining Act
conflict resolution 135–36 (FASA) 236
construction audit 120 financial management 144
consumption-based licensing 183 Fisher, R and Uri, W 129–30, 135
Contracting Guidance to Support Modular fit and gap analysis 151, 152
Development 228 Fixed-Price Award Fee (FPAF) 232
contract-to-pay, outsourcing of 9 Fixed-Price Economic Price Adjustment
cooperative buying 145–47 (FPEPA) 232
coordinated procurement model 7 Fixed-Price Incentive Firm (FPIF) 232
core spend 9–10, 11 forensic audit 119
corporate procurement (SAP model) 11 fulfil levers 41
corporate social responsibility (CSR) 132–34
social agenda, implementing a 134 Gartner 60
supplier role 185 General Services Administration 66
corrective maintenance 95 ‘generation Y’ 2
cost avoidance 273–75 geographical redundancy 62
cost-of-living allowance (COLA) 184 Google 55, 62
cost-plus contracts 175 ‘mandatory’ suppliers 99
Cost-Plus Award Fee (CPAF) 232 Government Accountability Office (GAO)
Cost-Plus Incentive Fee (CPIF) 232 89–91
INDEX 297
Government Service Administration manage levers 41–42

(GSA) 63 Manual of Authority (MOA) 267–68
Government-Wide Acquisition Contracts Master Data Management (MDM) 9, 94,
(GWACs) 30 265–66
GWAC Best in Class (BIC) 30–31, 146 matrix procurement model 7, 8
GuideWire 69 megatrends 2
Microsoft 38
hard partitioning 87 Azure 171
hybrid cloud 58 cloud computing business model 67
deployment of 61 fiscal year-end 198
hybrid contract 175 ‘mandatory’ suppliers 99
negotiations 220
IBM 62 Office 40, 86
cloud computing business model 67 Office 365 171
database housekeeping 265 public cloud 55
fiscal year-end 198 relationship management 131–32
reciprocal buying 279 Teams 197
incentive-based contracts 231–33 Moore’s Law 3
Incoterms 173–74
Incremental approach 75, 75–76, 81 Naisbitt, John 2
indemnification 188 NASA 146
Indenge, Alexis 15 National Institute of Standards and
industrial revolutions 3 Technology (NIST) 56
Industry 4.0 3, 4, 16, 20 negotiating 128–32
Industry 5.0 3 positional bargaining 129–30, 135
information system audit 119 principled negotiation 130, 13
Information Technology Management transactional analysis 128–29, 130–32
Reform Act 1996 see network virtualization 70
Clinger-Cohen Act
internal audit 118 Office of Management and Budget (OMB)
ITIL service lifecycle 21–23, 22, 52 Capital Programming Guide 228
Service Design Package (SDP) 22 Category Management: Making smarter
Service Knowledge Management System use of common contract solutions
(SKMS) 23 and practices 30–32
Service Level Package (SLP) 22 ‘Cloud Smart’ 66–67
regulatory guidelines 223
Kimble 69 open source licensing 83
Kubler-Ross, E 283 Oracle
cloud computing business model 67
Lean initiatives, for procurement 263–70 cost increase rates 274
benefit management 268 ‘mandatory’ suppliers 99
contracting process 267 negotiations 220
demand management 266 fiscal year-end 198
inventory management 269 licensing terms 86, 87–88, 187
Manual of Authority (MOA) 267–68 organizational maturity 6–8, 8
Master Data Management
(MDM) 265–66 perfective maintenance 95
operational model 269–70 perpetual licensing 83
production waste, forms of 263–64 Plan, Do, Check, Act (PDCA) 125
sourcing process 266–67 platinum SLAs 6
tail spend 264–65 PMBOK (Project Management Body of
transaction cost 268–69 Knowledge) 23–25, 26
PMBOK Guide 237
298 INDEX
positional bargaining 129–30, 135 Product Vision 227

preventable demand 140 Project Management Institute (PMI) 23
preventive maintenance 95 project management lifecycle 23–26, 24
principled negotiation 130, 136 closure 25
private cloud 58 execution 25
deployment of 60 initiation 24
process levers 37–38 planning 24–25
procurement ‘rights’ 1 project management triangle 73, 74
procurement agility proprietary licence 83
change management 283–87, 284 public cloud 58
change champions 286 deployment of 61–62
embedding change 286 domicile 61–62
executive support 285–86 geographical redundancy 62
success, measuring 285 sandboxes 62
vision, communicating 285 public-sector audit 118
defining 245–46
resistance factors RACI matrix 173
business planning and regression testing 73
budgeting 247–48 requisition-to-pay, outsourcing of 8
capacity planning / resourcing resistance factors
250–54, 251, 253 business planning and budgeting 247–48
contract management 262 capacity planning / resourcing 250–54,
corporate governance 254–57 251, 253
operational model 252, 258, 259, contract management 262
260 corporate governance 254–57
project management 249–50 operational model 252, 258, 259, 260
recruitment 258, 261 project management 249–50
sourcing 262 recruitment 258, 261
supplier relationship sourcing 262
management 263 supplier relationship management 263
procurement auditing 117–25 resource pooling 56
audit types 117–20 resource scarcity 2
construction audit 120
environmental and social audit 119 Salesforce
external audit 117–18 cost increase rates 274
forensic audit 119 fiscal year-end 198
information system audit 119 ‘mandatory’ suppliers 99
internal audit 118 negotiations 220
public-sector audit 118 SaaS model 69
tax audit 118 sandboxes 62
value-for-money audit 119 SAP
benefits of 126–27 cloud computing business model 67
defining 117 cost increase rates 274
process 121–25 fiscal year-end 198
audit itself 123 licensing terms 88
audit schedule 122 procurement layers 11
pre-planning 122–23 relationship management 131–32
recording 123–24 SaaS model 69
reporting 124–25 scope freeze 158, 172
scoping 121–22 server virtualization 70
procurement risks 120–21 service-level agreements (SLAs) 111, 180
‘procurement battle plan’ 10, 10 platinum SLAs 6
procure-to-pay (P2P) 271 right to terminate 187
outsourcing of 8 ‘shadow IT’ 12
product engineering 276 shared service centres (SAP model) 11
INDEX 299
Slack 197 demand levers 36–37

soft partitioning 87 fulfil levers 41
Software-as-a-Rental 179 manage levers 41–42
Software-as-a-Service (SaaS) 20, 83 process levers 37–38
business models 67–70 source levers 38–40
horizontal 69 spend profile 29
‘on top’ 69 staff retention 278
vertical 69 stakeholder analysis 29
Cloud SaaS 57, 60, 62, 63, 272 stakeholder relationship
commercial checklist 199–200 management 114–17
risk and reward pricing 39–40 aims of 116
software development 71–81 communication plan 116
Agile model 76–81, 77, 223–36 stakeholder map 114, 115
sample contract 77–81 Standish Group International 200–01
vs Waterfall 81, 82, 224 statement of objectives 226
commercial off-the-shelf software Statement of Work (SOW) 148–49
(COTS), using 71–72, 81 strategic commodities 8, 9
Incremental model 75, 75–76, 81 strategic procurement process 26–42
regression testing 73 category management 27–32
software development lifecycle defining 27
(SDLC) 72–73, 73 example 30–32
Waterfall model 73–75, 74 foundations of 27, 29–30
vs Agile 81, 82, 224 framework 28
software licensing 81–92 step 1: initiate project 26, 139, 140
consumption-based 183 step 2: identify business needs and study
hybrid licence 83 market 26, 139–48, 148
metrics, chargeable 84–85 business process outsourcing (BPO)
non-compliance, risks of 86–89 147–48
Oracle terms 86, 87–88, 187 demand management 140–43, 266
SAP terms 88 direct buy 144–45
Software Asset Management (SAM) 89 financial management 144
open source licence 83 indirect buy 145–47
perpetual licensing 83 step 3: specify requirements 26, 148–49,
proprietary licence 83 149
‘right to use’ vs ‘right to access’ 83–84 step 4: define sourcing strategy 26,
term licence 83 149–50, 150
‘true-up’ 86 step 5: select supplier and award
Unlimited Licence Agreement (ULA) 85, contract 26, 151–90, 191
183, 197 business case 155–57
US Government best practice 89–92 contract type 174–78
software maintenance 94–95 data security 187–88
adaptive maintenance 95 decision-making criteria 154–55
corrective maintenance 95 deliverables 173
perfective maintenance 95 final commercial offer 167
preventive maintenance 95 fit and gap analysis 151, 152
software support 92–94 implementation workflow 158–65, 159
support levels 92, 93 indemnification 188
Solutions for Enterprise-Wide Procurement lifecycle costing 154
(SEWP) programme 146–47 negotiation rules 170–72
source levers 38–40 payment plan 178–79
source-to-contract process 193, 194, 271 perks 184–86
source-to-pay (S2P) cycle 5, 271–72 pricing 179–84, 181–82
sourcing, strategic 32–42, 33 roles and responsibilities 173
value levers 34–42, 35 scope freeze 158, 172
comply levers 36 scoping study 166–70
300 INDEX
strategic procurement process (continued) cloud deployment options 62

service-level agreements (SLAs) 187 cost of service design 46
supply management costs 173–74 cost of service operations 47
technical and commercial cost of service strategy 45
evaluation 172 cost of service transition 46–47
termination of contract 186–87 cost-of-living allowance (COLA) 184
terms and conditions 186–90 example calculations 47–49, 48
virtualization 187 transactional analysis 128–29, 130–32
step 6: manage contract and supplier case study 205–06
relationship 26, 192, 192 Trello 197
step 7: review and close 26, 193 Trudeau, Justin 133–34
strategic sourcing 32–42, 33, 35 ‘true-up’ 86
comply levers 36
demand levers 36–37 Unilever 34
fulfil levers 41 Unlimited Licence Agreement (ULA) 85,
manage levers 41–42 183, 197
process levers 37–38 urbanization 2
source levers 38–40 User Acceptance Testing (UAT) 62, 73
success criteria, for tech projects 200
supplier lifecycle management 99–102, 101 value generation 273–83
contract stage 100 brand benefits 282
onboarding 100 claiming 280
prequalification 100 relationship benefits 281–82
supplier performance management 107–08 reporting 281
supplier preference model 106, 106, 220 revenue benefits 278–80
supplier relationship management risk management benefits 282
(SRM) 99–114 savings benefits 273–78
activities in 109 cost avoidance 273–75
defining 111 demand reduction 275–76
maturity in 103 product engineering 276
responsibility for 112, 114 staff retention 278
SRM Framework 103 social benefits 283
supplier lifecycle management 99–102, value-for-money audit 119
101 virtualization 70–71, 187
contract stage 100 application and desktop virtualization 70
onboarding 100 network virtualization 70
prequalification 100 server virtualization 70
supplier performance VMWare 86, 87
management 107–08
supplier preference model 106, 106, 220 Waterfall approach 73–75, 74
supplier risk management 108–08 vs Agile 81, 82, 223–26
supplier segmentation 104–06, 105 collaboration 225–26
supply base management strategy 110 development and delivery 224
Swiss AS 69 project planning 224–25
status evaluation 225
tail spend 264–65 commercial off-the-shelf software
Taleo 69 (COTS), using 81
Target Operating Model (TOM) 13–14 Federal Acquisition Regulation
tax audit 118 (FAR) 226
term licence 83 scope freeze 158, 172
Tesla 111, 171 traditional procurement 261
Thomas, K W and Kilmann, R 135–36 ‘whole-of-life’ price 179
total cost of ownership (TCO) 42–49
building blocks of technology 96 ZTE 171
301

302

303

304

The Technology Procurement Handbook

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

The Technology Procurement Handbook

Uploaded by

Copyright:

Available Formats

i

PRAISE FOR THE TECHNOLOGY

‘The Technology Procurement Handbook is a useful and practical

‘As we become firmly embedded in the Industry 4.0 era, it is good to

‘The Technology Procurement Handbook should be in the library not

‘The impact of Technology 4.0 on the procurement profession

‘What a read! Regardless which corporate function you call home,

Kogan Page books are printed on paper from sustainable forests.

© Sergii Dovgalenko, 2020

Hardback 978 1 78966 212 2

British Library Cataloguing-in-Publication Data

Library of Congress Cataloging-in-Publication Data

Typeset by Integra Software Services, Pondicherry

About the author ix

01 Setting the scene for the next-generation technology

02 Four pillars of technology procurement 19

03 Technology basics for procurement professionals 55

Summary view of technological options and

04 Relationship management in procurement 99

05 Deep dive into the procurement process 139

06 Practical advice and case studies on technology

07 US legislation and regulation on agile deployment and

08 Procurement 3.1: Agile, lean, and value delivery today 243

THIS PAGE IS INTENTIONALLY LEFT BLANK

ABOUT THE AUTHOR

Sergii Dovgalenko (Fellow and Licensed Tutor of the Chartered

THIS PAGE IS INTENTIONALLY LEFT BLANK

I would like to send love to my family for being an endless source of

THIS PAGE IS INTENTIONALLY LEFT BLANK

LIST OF FIGURES AND TABLES

Figure 1.1 Industrial revolutions 3

Figure 5.1 Step 1: Initiate a sourcing project 140

Table 5.1 Detailed financial breakdown 181

3PL Third-Party Logistics

CSCT Cloud Solutions Category Team

IDIQ Indefinite Delivery Indefinite Quality

PMBOK Project Management Body of Knowledge

SOP Standard Operating Practice

THIS PAGE IS INTENTIONALLY LEFT BLANK

Why would we dedicate the entire book to technology procurement?

of procurement’s job is accomplished before or after negotiations. In

It is made to provide a concise, memorable and practical guide for a

THIS PAGE IS INTENTIONALLY LEFT BLANK

Setting the scene for

Technology is at the heart of Procurement 4.0

Each of these megatrends alone and all of them collectively have a

tailored products and services, different standards of customer

FIGURE 1.1 Industrial revolutions

Industry 1.0 Industry 2.0 Industry 3.0 Industry 4.0

At last, digital supply chain management will unite the clusters of

Evolution of the procurement organizational model

At first, procurement resources are centralized into the nascent

FIGURE 1.2 Procurement organizational models

BU1 BU2 Group BU1 BU2 Group

Buyers Buyers Buyers Buyers

COORDINATED MODEL DECENTRALIZED MODEL

BU1 BU2 Group BU1 BU2

BU1 BU2 BU1 BU2

Buyers Buyers Buyers Buyers

• Buyers report into BU procurement • Buyers report to BUs

SOURCE Reproduced with permission of Oliver Wyman (Kochersperger et al, 2017b)

FIGURE 1.3 Levels of procurement centralization with maturity

Greenfield Developed Mature

Mature organizations evolved their procurement models to become

This business case also represents a true example of cross-functional