• Getting approval to purchase new technology is just the beginning of an often-complex procurement process
  • A successful procurement process includes clear business requirements, a vendor short list and a structured RFP review
  • Expedite results by building internal stakeholder relationships and communicating proactively throughout the process

Congratulations! All the work you put into conducting a technology gap assessment and building the business case for a new system has paid off. Your proposal has been approved and you can move forward with finding and purchasing a solution. Now the real work begins.

Going through the technology procurement process, especially in a large organization, can be painstaking and time-consuming – not to mention politically charged, as everyone involved has a strong opinion on which vendor to select. To better navigate the procurement process, follow these eight steps:

  • Craft a strong business requirements document (BRD). Having a comprehensive BRD is crucial – not only for the procurement process, but also for finding the best technology solution to meet your needs. A good BRD specifies what use cases are in (and out of) scope for the proposed solution; defines and prioritizes key functional requirements; and specifies the performance, security, legal, support and training requirements the solution must meet. A BRD also should identify critical success factors for the technology and identify potential risks. In many organizations, the IT function has a BRD template to populate.
  • Identify the vendor short list. Given the effort required to go through the procurement process, sending a formal RFP to every possible vendor isn’t practical. Use the BRD to identify a short list of vendor solutions that address the majority of your defined requirements, via online search; conversations with sales reps; and/or discussions with peers, industry analysts and current vendor customers. A realistic short list at this stage includes around five vendors that are a potential fit.
  • Write the RFP. Depending on your organization’s process, an RFP template likely exists that must be completed to solicit vendor bids. While procurement specialists can assist with the process, the team wishing to make the purchase usually authors the RFP. Typical RFP elements include standard instructions and dates for all bidders, general contract terms and conditions, questions about the vendor’s organization (e.g. structure, funding, viability), customer reference requests, a project overview, a prioritized list of the technology requirements the vendor must address (pulled from your BRD), cost estimates and licensing options, a recommended deployment plan and timing, problem resolution processes, and any additional information your organization requires (e.g. security standards, International Standards Organization or regulatory compliance).
  • Define RFP review and approval. After the RFP has been written, define the RFP review and approval process. While procurement may have guidelines for this stage, it’s important to identify who will review RFP responses from a business and an IT perspective. Keep the review team small (e.g. the business champion, an IT representative, a procurement specialist). RFP responses can be sizable and complex documents, and guiding a large review team through them can be challenging. Determine the objective business and technical scoring criteria for the RFP responses, and define a standard scoring scale. A structured review of RFP responses will allow you to reduce your vendor short list to one to three top vendors.
  • Conduct vendor demos. For additional vendor selection criteria, ask RFP finalists to provide structured demos of their solutions. This allows internal stakeholders to see the vendor’s offerings in action. To get maximum value from the demos, provide all vendors with a common demo script and company assets to populate the demo environment, allowing for an apples-to-apples comparison of solutions. Determine which stakeholders to invite to the demos and provide all participants with a standardized scorecard and scoring scale to collect objective feedback on the solutions. Some vendors may set up a test environment or proof-of-concept trial to allow your team unstructured access to their solution.
  • Check customer references. Check the customer references provided by the vendor, and identify additional customers through your network to speak with. To get the most from reference calls, develop a standard set of interview questions and score customer responses. Questions can cover topics such as system functionality, support and issue resolution, training, and the reference’s overall relationship with the vendor.
  • Make the recommendation. Now is the time to assess the RFP responses, vendor demos and customer reference data. You will have a range of objective scores, qualitative feedback from a variety of internal stakeholders and likely a very good sense at this point of which vendor best fits your needs. Summarize the findings and key data, and make the final vendor recommendation to the executive decisionmaker or committee for approval.
  • Participate in contract review. The last stage of the procurement process focuses on the submission and formal review of the vendor’s contract. While this step is typically owned by finance, legal and/or procurement, the business champion, IT and key internal stakeholders must be involved to ensure the final contract supports critical requirements. Contracts often go through multiple reviews.

The other two elements that ensure a smooth procurement process are relationship building and communications. Get to know the stakeholders in the procurement process before you start, and ask questions to learn more about your organization’s specific process and pitfalls to avoid. During the process, communicate openly and proactively on the state of the process with all key internal stakeholders. This will reinforce your objectivity and credibility when it comes time to announce the selected vendor, and will lay the groundwork for future user adoption.