For modern procurement leaders, success in IT procurement is predicated on the identification of logical expectations of the software or solution's performance, plus the measurement of reliable metrics and KPIs for measuring the performance and success of the product. So how you can accomplish this? Start by following the IT Procurement process as outlined below and working closely with your business stakeholders to understand their needs.
What is the IT Procurement Process?
IT procurement is defined as a series of activities and procedures directed toward the acquisition of information technology. These activities are usually categorized within a single process formally known as the IT Procurement Process, which is widely recognized as one of the key strategic business processes within every modern business organization.
The IT Procurement Process is the means by which a company is able to execute its internal and external projects efficiently because all necessary products and services required for the completion of those projects have been made available. The process allows business leaders to determine the requirements for IT systems, and also allows them to communicate with suppliers, administer procurement contracts, manage assets and assure the quality of the acquired products and services.
Considerations from CIOs
The foremost leadership position under the purview of IT typically belongs to the Chief Information Officer, or CIO. Despite the uniformity of their titles, CIOs have varied widely in their beliefs about the role of procurement in IT and how closely it should be managed in relation to their companies’ projected returns on investment (ROI). Specifically, while some CIOs are concerned with ROI, others feel that IT leaders are best served when they focus on the innovation and ingenuity the organization needs to create through the use of the purchased technology. This is far different from the thought process of a procurement leader in another industry, like a manufacturing procurement leader—who can more easily think about the interactivity between different resources and their effect on the finished physical product.
Of the CIOs that factored ROI into their operational equations, several felt that ROI should remain a secondary concern, because project initiation should be the foremost objective, and ROI is not thought of as something that can be accurately gauged and predicted within the early stages of an IT project.
Many CIOs feel that procurement leaders are poorly equipped to handle IT purchases despite their belief that they are competent to do so. This stems from those procurement leaders feeling empowered by their handling of other purchases for less dynamic pieces of equipment or machinery, which have no obvious connection to IT purchases.
One of the concerns with procurement leaders attempting to generate an accurate ROI projection for IT projects has to do with attempting to calculate ROI across each individual project the IT software and equipment would be involved with. For example, a company investing more money overall in the staff involved with an IT project has the potential to yield a superior ROI compared with companies that invest less, with all other variables being equal. Further, procurement departments are routinely accused of believing that software will fix everything, despite quality differences between types of software, and despite the cutting of corners during the implementation of that software.
Finally, the CIOs polled also felt as if procurement teams are often allotted and undue degree of authority. If the procurement teams are going to exercise that power, they should be admonished to integrate themselves with the project teams they are assisting and wield their power as if it were a tool to help bring the project to fruition with the best possible software and equipment. They are not advised to view it as their sole duty to act as a cost-cutting authoritarian.
Acquiring vendor partners in IT
Prospective vendors often engage with procurement teams from the standpoint of ROI, but procurement teams are cautioned against looking at vendor-derived ROI numbers, which are often inaccurate. Unless the vendor is also able to present information suggesting the ROI projections were derived from the real-life performance measures generated by a tech company of a similar size with a similarly skilled staff, and with a similar amount of money invested in the project, then those numbers are not to be believed. Without those similarities established, the ROI projection from the vendor may be wholly inaccurate.
Procurement team members are frequently concerned with the functionality of the items being purchased and whether or not they will perform as advertised. While this attitude tends to persist within the procurement departments of IT companies, technology and software have developed to the degree where technical performance is a relative non issue. Therefore, preemptive meetings with vendors to address technical issues are usually unnecessary.
Instead, agreements with IT vendors should be structured around SLAs and KPIs. An SLA—or service-level agreement—is a contract between a service provider and its internal or external customers that documents what services the provider will furnish. It also defines the service standards the provider is obligated to meet, which allows customers to understand the benefits of the service in clear terms, along with how the vendor is prepared to address performance issues with the products.
The three primary types of SLA are multi-level, customer level and service level. Service level SLAs are uniform across the entire business. This means if the human resources department and the finance department are using the same service, the same service agreement will be valid across both departments.
A customer level SLA applies to all of the services used by a customer that are provided by the same service provider. If an IT vendor provides its customers with a suite of solutions that authorizes the use of separate products by the same customer, the provision for the customer to use all of the vendor’s distinct services is accounted for within the customer level SLA.
Finally, the multi-level SLA involves an SLA that is separated into multiple levels that apply differently to different members of the organization, but remain within the same SLA. In practice, one or two departments may be governed by a service level SLA, while other departments would have access to all of the services detailed under a customer level SLA, yet all of these distinctions are plainly stated within the same multi-level agreement.
KPIs—key performance indicators—are the agreed-upon indicators of progress toward an intended result. KPIs are designed to create an analytical framework for decision making, and within the structure of a contract with an IT vendor, KPIs should be used to dictate whether or not a service has lived up to its guaranteed performance level, and can also influence the terms of the contract and the final amount paid to the vendor for their service. Certainly, if the agreed upon KPIs demonstrated that a service did not function as promised by the vendor, then the IT customer should be entitled to some sort of refund or reduced rate since the service failed to deliver results at the contractually-stipulated level.
The IT Procurement Process Framework
More than 20 years ago, the Society for Information Management put together a working group to develop a framework for IT procurement management. The working group returned with a six-process framework which was divided into two categories: Deployment processes and Management processes.
Deployment processes consist of activities that are performed every time an IT product or service is acquired. Each individual procurement spawns a life cycle that begins with the identification of requirements, continues with the acquisition of the necessary products and services, and ends with contract fulfillment.
Requirements determination involves all of the steps and approvals required to proceed with the procurement process. This includes sub-processes like project team organization, the use of analytics to justify investments and general assessment of the risks involved with undertaking the project.
Acquisition is the process of identifying the appropriate suppliers and finalizing procurement arrangements for the needed products and services. Finally, contract fulfillment is the process of managing and coordinating all activities involved in fulfilling the contract requirements. It includes accepting products or services from the vendor, installing service systems, and the general administration of the contract.
Under the category of management processes are activities involved in the overall governance of IT procurement. The three primary classes of IT procurement management processes are supplier management, asset management, and quality management.
Supplier management involves the optimization of customer-supplier relationships to add value to the company. It includes activities such as strategy development within the supplier portfolio, the creation of relationship strategies for key suppliers, assessing supplier performance, and managing supplier communication.
Asset management is the process of optimizing the IT assets acquired during procurement throughout their entire life cycles to align with their intended purposes. It includes such things as the development of asset management strategies, policies, and information systems, evaluation of the lifecycle cost of IT asset ownership, and management of asset redeployment and disposal policies.
Quality management is the process of realizing continuous improvement in the IT procurement process and in all products and services a company acquires for IT purposes. It includes product testing, statistical process control, acceptance testing, quality reviews with suppliers, and facility audits.
Important IT procurement themes
The Society for Information Management’s working group also identified four themes which they considered to be of the utmost importance to senior procurement managers. Those themes are Process Management, Design and Efficiency; Measurement, Assessment, Evaluation; External Relationships, and Internal Relationships.
The first of these—Process Management, Design, and Efficiency—revolves around the idea that IT procurement managers are primarily concerned with the optimization of the procurement process. Beneath this theme fall issues like the use of automated tools like EDI and procurement cards, reduction of cycle time in contracting processes, development and use of all reporting systems, and the integration of sub-processes at early and later stages of the procurement life cycle.
The second most important theme—Measurement, Assessment, Evaluation—defines the search for reliable ways to measure performance, and this applies to both external suppliers and the internal procurement process. These dual focuses allow procurement managers to measure their own contributions while simultaneously measuring the performances of their outside vendors.
External Relationships and Internal Relationships delve into the methodology behind the creation of effective working relationships. The importance of such relationships is an outgrowth of the cross-functional nature of the IT procurement process within organizations, and the general transition from internal to external sources for information resource acquisition.
The process framework and key issues identified by the SIM IT Procurement Working Group also set guidelines for future efforts to improve the IT procurement process. The five action items they created are:
- Develop IT procurement performance metrics and use them to benchmark the IT procurement process.
- Clarify roles in the procurement process to build effective internal and external relationships.
- Use the procurement process framework as a tool to assist in reengineering the IT procurement process.
- Use the framework as a guide for future research.
- Use the framework to structure IT procurement training and education.
The most important action item on this list is the mandate to Develop IT Procurement Performance Metrics and Use Them to Benchmark the IT Procurement Process. The four classes of performance metrics identified by the work group were effectiveness metrics, efficiency metrics, quality metrics and cycle time metrics.
At the time of the initial development of the IT procurement process, solid performance metrics were virtually non existent. Decades later, we are privileged to live in an era where new forms of performance data are now readily available, and IT procurement managers are encouraged to use every resource at their disposal to promulgate the best metrics for evaluating performance.
Measure everything
Obviously, the reliance on performance metrics dominates discussions of procurement within IT, and this is a result of the service orientation of the software in the industry. The data-driven nature of modern business activities means IT customers arrive at vendor negotiations with a prepared list of performance measurements they need the vendor’s services to help them attain, while the vendors counter with a list of projections about the lofty standards they purport that their services should allow any customer to attain as long as they implement the service and effectively execute within its parameters.
In short, success as a procurement leader will be overwhelmingly predicated on the identification of logical expectations for product performance, coupled with the establishment of reliable metrics for measuring the performance of those products. This can be accomplished by becoming thoroughly enmeshed within the project team, understanding its needs, gathering and transmuting information into reasonable metrics, and then relaying that metrics to vendors in the form of contractual obligations.
