Whether you are contracting to licence or acquire custom software, hardware, or related services, IT procurement creates unique challenges and is often associated with high costs, complexity, and a relatively high rate of failure. Improperly informed IT decisions can be costly. These challenges can be daunting even to the most seasoned practitioners. Understanding some of the key challenges and related strategies for addressing them can be pivotal to the success both of a procurement process and, sometimes, of the organization itself.
The challenges in undertaking IT procurement have been recognized outside of the supply chain profession. While the Canadian Free Trade Agreement (CFTA) is in its infancy, its authors and negotiators seem to have indirectly recognized the challenges of IT procurement in certain circumstances. This is the case with, for example, instituting a limited tendering provision if a change of a supplier for certain additional goods or services cannot be made “for economic or technical reasons such as requirements of interchangeability or interoperability with existing equipment, software…” This section of the CFTA, which will require some significant unpacking, is indicative of the challenges faced in this area of procurement.
While there are many challenges with IT procurement, this article will briefly explore two such challenges: the rapid pace of IT development and the corresponding requirement for IT specialization when procuring IT, and related strategies.
 Canadian Free Trade Agreement, Article 513 1. (c)
1. Rapid Pace of Change
Technology is the growth industry and we live in an era of exponential change. Figuratively speaking, what is new today will be old hat tomorrow. Procurement specialists struggle with choosing what will be the surviving standard for any technology, which impacts IT procurement and can provide the supplier with an advantage. The IT supplier’s critical knowledge of the IT being procured and what is on the horizon for IT development is a strong advantage. One way to begin addressing this challenge is recognizing that silo purchasing of IT is a non-starter. The complexities of IT procurement call out for the participation of multiple team players and stakeholders from the purchasing organization. Further, depending on the project, organizational project integration is often required for success, and internal subject matter experts or retained consultants are needed, as they play a greater role in IT procurement.
2. IT Specialization
IT suppliers know their business well and have focused experts working to develop, market, sell, and support their IT wares and services. Given the desire to avoid failure in an IT project, this can lead to a heavy dependency on a chosen IT supplier. Accordingly, purchasers should acquire IT specialization to assist in their IT procurement and practices. To strengthen the position of the purchaser, specialized IT knowledge is required for the following, and other, reasons:
- The Purchaser’s Needs
Why buy the latest and the greatest top-of-the-line IT when something that costs less will be sufficient? As the decision-making may be removed from the end-user, it is critical to understand end-users’ needs and wants. An IT needs assessment, which includes a fact-finding and review process, can be useful for setting the stage for what to purchase. At the end of the day, this analysis can have a significant impact on the decision-making process.
A big question for new IT purchases is how well a new system will work with a legacy system and how to roll out that integration. This requires understanding legacy systems, reviewing current contracts, considering issues relating to transitioning to a new supplier, acceptance testing, and, perhaps, undertaking a proof of concept. While acceptance testing is generally understood within the supply chain profession, that is not always the case for a proof of concept. A proof of concept is an initial verification confirming that a concept has the potential to actually work as needed, and also determines scope, functional fit, level of customization, resources, and so on. For the purchaser, a proof of concept can identify overselling and provide a clearer understanding of the investment required, a better evaluation over a period of time, and an improved understanding of the implementation. This additional time and fee will be less costly than a system that the purchaser is dissatisfied with or a failed implementation. However, the downside of using a proof of concept is the time it requires, which can result in project delays and their associated costs. While a proof of concept is neither suitable nor required in all IT procurements, it is worthy of consideration.
- (Hidden) Lifecycle Costs
Given that the lifecycle costs can overshadow the initial acquisitions costs, understanding all of the lifecycle costs and knowing what is covered in the contract are both important. Software and hardware, whether licenced or acquired, often have a seemingly never-ending series of updates and upgrades. Understanding the difference between these two items – updates and upgrades – is a start to understanding the lifecycle costs of IT purchases. An update is generally understood to mean any correction or similar type of change to the purchase made by the supplier or developers during the life of the purchase. No additional cost is typically paid for this. On the other hand, an upgrade is understood to mean a new version of or addition to the purchase and either enhances the performance of the purchase or provides a new feature or function. There is usually a charge associated with an upgrade. Another cost consideration is how regular maintenance will be undertaken – as well as when the warranty period ends, which is when the maintenance charges should commence.
While we have just started to skim the surface of IT procurement challenges, the importance of increased IT knowledge and adding IT subject matter experts to an organization’s talent pool will start to yield quantifiable results. Consider increasing your IT procurement toolbox to include strategies not previously considered such as an IT needs assessment, considering integration and lifecycle cost at the RFx stage and, where appropriate, engaging in a proof of concept process.
Author: Debby Shapero Propp is a commercial lawyer with a focus on supply chain, technology and health law, providing legal services in the private, public and broader public sectors.
Readers are cautioned not to rely upon this article as legal advice nor as an exhaustive discussion of the topic or case. For any particular legal problem, seek advice directly from your lawyer or in-house counsel. All dates, contact information and website addresses were current at the time of original publication.