Delivering Successful IT Projects: The Procurement Stage

On June 11, 2025, McCarthy Tétrault hosted our national webinar Delivering Successful IT Projects to discuss strategies and tools to deliver successful IT projects. Partners from our Technology Group and Litigation Group explored the procurement and implementation of business critical IT systems, such as Enterprise Resource Planning (ERP) and Customer Relationship Management (CRM) systems. This blog series highlights key takeaways and answers questions raised by the audience. Click here to subscribe to our blogs or reach out to the speakers to get access to the recording and Q&A: Dana Siddle, David Crane, Jade Buchanan and Alexandra Cocks.

If the first step of your IT project is procuring the software, you need to step back. Publishing a request for proposals (RFP) is a key milestone in any IT project, but rushing out of the gate will guarantee slip ups. An RFP is a legal document—and a binding contract if done in a “Contract A” procurement. It requires preparation commensurate with the size of the project. In this post, we set out considerations for when developing your RFP or proposal.

Know Your Buyer

Every organization purchases software on a regular basis. Many have dedicated personnel with a range of relevant expertise, including information technology, procurement, vendor management, compliance, legal, contracting, privacy and information security.

Stakeholders:

A transformative IT project is going to have different stakeholders than day-to-day software purchases. Those stakeholders may also have less experience with your organization’s existing IT purchasing processes.

Unexpected stakeholders are a potential source of project delays. Examples include failing to recognize that your project has compliance implications that require oversight from subject matter experts, or not appreciating that your spend or risk thresholds may require a higher level of approval than day-to-day projects. Clearly document who needs to be consulted and when, and clearly set out the scope. Be prepared to manage feedback and park issues that cannot be addressed on go-live.

Compliance Requirements: 

Privacy and security assessments are necessary in almost any large IT project in Canada, irrespective of the sector or legal regime. However, they are often built for routine projects and require some adjustments for transformative IT projects. For example, an organization might not conduct a privacy impact assessment until a contract is negotiated. To accommodate that, conducting a preliminary review before issuing the RFP helps surface key issues and requirements in advance. A large IT project may also require compliance teams to be more involved or require external expertise. Bringing them in too late often means redoing work or not being able to use the full functionality of a product because it is not compliant.

Desired Outcome:

What is the problem you are trying to solve? A clear vision will guide a project, helping to thwart scope-creep. It will also help you narrow down the list of potential solutions, weeding out those that are not viable, before getting to the procurement stage.

Current State:

Many major IT projects aim to modernize an outdated system. Understanding your current state will improve the clarity and detail of your requirements for procuring a replacement. Also consider the tools in the contract with your existing vendor, if you have one. There may be knowledge transfer or transition clauses you can rely on. Understand their interest in competing—they are the most likely to challenge a procurement if unsuccessful. Conversely, other strong candidates can challenge the procurement if they perceive it as favoring the incumbent.

Not Procuring:

When considering your current state, you should also look at existing IT products and existing contracts and other means of purchasing software. While you probably will not find you can achieve your desired outcome without buying any new products, you will have a clear picture of your best alternative to a procurement. For example, you may have an existing contract with a vendor that can assist with design services should you run into issues that delay the procurement. You may also reduce the scope of the procurement by relying on existing tools.

Know the Market

Before the RFP:

Customers have a range of tools to understand the marketplace, including consultants and requests for information.

Customer-Market Fit:

Once you know your needs and your options, you are empowered to make a realistic choice, balancing various trade-offs. A common example is that customers frequently seek to get a product that works “out-of-the-box”. While there are upsides, it is not necessarily better for customers to change their processes to fit new software rather than customizing the software to match existing processes. Customization, which requires software development / coding, can introduce coding defects and make systems harder to maintain, but it may be necessary when unique processes provide a competitive advantage. On the other hand, changing business processes can create significant change management challenges, as people may struggle to adapt. The most successful projects usually find a balance between customization of the incoming system and accommodation of the legacy system. Additionally, some modern systems are highly configurable, which reduces the need for customization. When customization is worth the risks, customers can mitigate the risks by building the capacity to identify and mitigate the risks, such as through training and knowledge transfer from the implementer and ensuring they have the ability to test how new versions of the software affect the customizations before full deployment.

Structuring Your RFP:

Organizations that have procurement processes that are not IT-focused may find they need to adjust to the IT world. For example, many organizations are accustomed to standard “Contract A” procurements. In the IT projects world, there is a strong preference for negotiated procurements where neither the customer nor the vendor is bound until the actual contract is signed. Attempts to run a “Contract A” procurement may be met with resistance.

RFP Process:

A single RFP may not be the right approach. Most IT projects involve one or more major software products and an implementer/integrator. Some software vendors implement their own product, but some do not. Taking into account your needs and the state of the market, you can determine how you procure each. You might also consider a staged RFP process: issue an initial RFP for the discovery phase, and then, once requirements are clear, issue a second RFP for the implementation phase. This helps clarify scope and costs before making a full commitment. In all cases, it is important to define expectations, deliverables, and exit options up front. Using offramps, staged procurement, and careful vendor management helps control risks and maintain flexibility throughout the project.

Know Your Customer

Know What You Are Agreeing To:

An RFP can be a binding contract. Before bidding, it is important to understand the procurement process. While your product might be the right fit, you may not be able to meet the organization’s non-technical requirements or accept their form of agreement.

Know When to Push:

RFP processes typically include the option to ask for questions or clarifications. If there is a deal-breaker for your organization, consider inquiring before you decide to not bid. An RFP for a large IT project can be a big, complex document. The issue may be resolvable and you may not be the only potential proponent raising the concern. It is seldom wise to bid and then hope for the best.

Get Advice:

You are the expert in your product, but your product might appeal to a broad range of sectors. Bidders have a range of tools they can use to learn about their customers, including the RFP itself, the questions function, and external experts who understand the sectoral needs.