Intent

My goal for any procurement is for the organization to make a well-considered decision, factoring in the maturity, scale, risks and impacts of the problem or opportunity at hand. While this guide is written as a step-by-step guide, It's common for many steps to occur simultaneously, and others to be omitted completely. As the recommender, it's essential that you balance rigor and urgency to ensure the best outcome for both you and your organization.

The Ideation & Development Of Why

It starts with an idea...

We have all hit that wall where we become frustrated by the difficulty or toil of something. Many have also gotten energized when we have seen an opportunity to improve something. This is the catalyst for the process to begin.

Example:

• A recruiter becomes tired of writing the same email multiple times to candidates while keeping track of the different statuses of all the candidates.
• A person responsible for guests at the office is frustrated by the experience the guests have when they visit the office.
• A person responsible for payroll would like to reduce the amount of manual corrections to timecards.
• An IT professional is struggling to keep track of the organization's assets in a spreadsheet.
• An IT professional is frustrated in how long it takes to develop automation between existing softwares.
• A team/project leader would like to hold their team accountable to specific work items while providing transparency to the project's stakeholders.
• A people leader is frustrated by the customization options from the current HCM/HRIS system.

Developing your idea

A great idea is just the beginning. Go deeper to present a well-rounded view of the problem or opportunity, gather input from peers or managers and, whenever possible, use data to reinforce your perspective. As the recommender, your role is to lay the foundation for what will serve as the thesis of the final output. Begin by crafting a compelling argument that defines the problem or opportunity and explains why it's important to address it now. A strong argument will help ensure a smoother process. Ensure all data points are properly cited and, if possible, linked to source documentation to strengthen your case.

If you can't immediately gather the evidence needed to support your argument, consider setting up instrumentation to collect data or wait until the necessary information becomes available. It's common—and sometimes expected—that certain procurements may pause or even stop before they begin.

Example: From January 2024 to October 2024, we discovered and resolved 295 time-tracking errors between our time card and payroll solutions. Each error took between 10 to 120 minutes to resolve once identified. While the productivity cost is significant (estimated at $15,000 so far in 2024), it is minor compared to the loss of employee trust each time an error is found. By evaluating and implementing a new time clock solution that connects directly to our payroll system, we can reduce errors to zero, thereby building employee trust and reducing the workload on our payroll team. Our current solution's contract ends on February 1, 2025, so acting now gives us ample time to assess options and implement a new solution.

Stakeholder & Requirements Gathering

Identify & align your stakeholders

Procurements cannot be achieved alone. No single individual within an organization possesses the complete knowledge, experience, or perspective needed to fully represent what's best for the organization. Organizations are inherently distributed, each of us serving as stakeholders for our respective areas.

Primary Stakeholders

You likely already know the primary stakeholders—they are the group of people who would benefit most from the procurement. For smaller procurements, this might involve a single individual representing multiple stakeholder groups, while for larger procurements, multiple people may represent distinct groups.

General and Administrative Stakeholders

In addition to primary stakeholders, several other key groups should be involved in nearly all procurements.

• Legal: It's nearly impossible to procure software without agreeing to a legal document, your legal team should be consulted on every procurement.
• Financial Planning and Analysis, FP&A or Finance: Almost all organizations have a budget process established, therefore your Financial Planning and Analysis (FP&A) team should be consulted.
• Accounting: Most software worth using requires a payment method in exchange for the services vendors, Your accounting team should be consulted.
• Security and/Or Compliance: All software has access to at least some organizational data therefore you Security and Compliance teams must be consulted.
• IT: All software connects to infrastructure that is the responsibility of the IT function at most organizations, so IT should be consulted.

These stakeholders should have a standard set of requirements that can be incorporated in your process or be consulted to provide specific requirements as needed.

Note: Legal, IT, FP&A and Security/Compliance groups most of all are consulted too late or, in some cases, not at all in the procurement process, despite their significant influence over whether a procurement can proceed. I strongly encourage recommenders to engage these groups early and frequently to ensure that potential blockers are addressed early in the process. While it may feel unfamiliar or unusual to consult these groups so early, doing so prevents them (and you) from being surprised or blindsided by unexpected issues late in the process.

Aligning Stakeholders to Roles

Your stakeholders and you deserve to know what role you all are playing in the procurement. I recommend using the RAPID framework to organize my stakeholders.

You as the individual who is reading this document are very likely the R or Recommend role.

Your boss or someone else in your leadership team is likely the Decide role. Your stakeholders will make up a combination of Agree, Input and Perform.

Requirements gathering

In collaboration with your stakeholders, work to define a set of measurable requirements. Using the MoSCoW method, craft statements that can be evaluated clearly as true or false for each software under consideration. Each stakeholder group should develop its own list of requirements, while your role as facilitator is to guide rather than dictate these requirements. You should encourage each group to incorporate a varied range of requirements. For instance, if a group has only "must-haves" without any "should-haves" or "could-haves," they may need to stack-rank their "must-haves" or consider additional possibilities. To deepen the conversation, prompt each group to define some "won't-haves." These exclusions can foster insightful debate and help each group differentiate between essential and non-essential features, leading to a balanced, well-prioritized list of requirements.

Here is an example of a first draft of IT's requirements for a software procurement.

The software must have:

• support Single Sign On (SSO) with Okta via OIDC or SAML
• support IdP-initiated Single Sign On (SSO)
• support SP-initiated Single Sign On (SSO)
• the ability to enforce Single Sign On (SSO) With Okta
• the ability to create, update and deactivate users/accounts with Okta via SCIM
• the ability to assign different permissions to different users/accounts
• the ability to restrict access to specific IP ranges
• the ability to set a session timeout in hours (18 hours)

The software should have:

• the ability to assign a read only admin access
• have a documented API for common administrative tasks
• have completed a penetration test in the last 12 months
• have completed a SOC II certification process
• publicly accessible status page (if hosted by supplier)
• in-product access to an audit/event log

The software could have:

• publicly accessible release notes

The software won't have:

• inbound access to organizations networks

Software Selection

Creating your first list of options (~5 options)

At this stage, you have gathered enough data to begin searching for software that meets the needs of you and your stakeholders. Your goal is to identify approximately five options that, as the recommender, you believe would be a good fit for your organization based on the insights gained so far.

This step is best completed after the requirements are written. As the requirements should drive the selection of vendors, not the other way around. You might even advise stakeholders not to mention specific product names they have used in the past to reduce bias at later stages.

Get out your tape measure and mark for your first cut (~3 options)

Having your list of potential software as well as Moscow based requirements from all your stakeholders you now have the ability to measure how closely your options meet your requirements. I will use this as my first real opportunity to engage the vendors by taking the requirements and giving them a worksheet to fill out. It allows them to understand what it is we are looking for as well as for them to do some work for us to help us align on what tool is best.

The output of the step will be a percentage that meets requirements for each of the tools helping you to narrow the field from the ~5 to ~3 you want to move forward through the process.

Demos and/or Direct Experiences

This step is often the most fun for people and so they want to do it first, but the longer you can wait the better you come prepared to use this time wisely.

Demos and direct experiences require large blocks of time from your stakeholders which can be expensive but also look poorly upon the procurement if you are not intentional about how you use the time. The better you can align your expectations, with those of the software vendors the better experience you and your stakeholders will have.

Demos

Based on the scale and complexity of the procurement, I may split the demo into separate sessions, allowing participants to join according to their specific interests. To ensure an accurate comparison between products, I aim to have each software demo address the same set of requirements, allowing us to view comparable features across each option.

Give your Stakeholders a Voice

Written requirements alone don't capture the full picture in an evaluation. There's an intangible side that reflects how software feels to use—the pleasure and ease-of-use that some experiences provide, while others don't. While this shouldn't be the sole factor in selecting a product, the perspective of stakeholders is invaluable. Many of us have used software that technically met business requirements but was frustrating to use, leading to dissatisfaction, inefficiency and at worst a failed implementation. Even if these elements can't always be fully addressed, giving stakeholders a voice in this area helps highlight the trade-offs and allows a greater acceptance to procurement decisions.

The simplest way to gather this input is by asking stakeholders to rate the solutions on a scale based on their personal experiences, not the perspective of the organization or peers. I emphasize that I want to know what they genuinely think of the solution—not what they think others will think.

Measure Twice

Use the updated requirements along with stakeholder voting data to narrow the field from three options to two. Ideally, a clear primary and secondary choice will emerge from this process. If not, consider re-engaging stakeholders to refine or expand requirements based on any new insights they've gained.

Reference Checks, Organizational Fit & Estimated Cost

Reference Checks

Now that you've narrowed it down to two candidates, it's helpful to gather insights from customers who use each solution on your shortlist. Leverage both the account management team at each vendor and your own network to find a few contacts for each tool. Aim to connect with customers in similar positions to your organization or in roles that reflect where your organization plans to be. For example, if you're a late-stage startup planning to go public, consider speaking with an organization that has made that transition using the software. Additionally, it can be valuable to talk to someone who has transitioned away from the software you're considering, to gain perspective on potential limitations.

Example Questions:

• What process led you to choose this software?
• Which solution was your second choice, and why?
• Given the chance, would you choose to purchase this software again?
• Were there any unexpected challenges or benefits you encountered between purchase and launch?
• What advice would you give to another organization planning to implement this software?

Organizational Fit

One more interesting factor you could consider in evaluating software is whether the supplier or company behind that software is an alignment with your organizations, mission and goals. This could be something related to sustainability, ethics and/or core values.

Estimated Cost

In my experience, cost is often one of the last factors discussed in depth during a software evaluation. As the recommender, you may already have a general sense of the solution's cost, but I encourage you to avoid diving into pricing details until you have a clear understanding of which tools you'll use and how they'll be implemented. Only at this point can you accurately estimate the true cost and potential value of the solution for the organization.

I also recommend refraining from discussing solution costs with stakeholders until later in the process. Stakeholders may naturally weigh the cost against their personal perception of return on investment, which may not capture the broader organizational impact. Your goal is to keep stakeholders focused on the value the solution brings; measuring that value against cost should be the final step and ultimately the decision-maker's responsibility.

This approach may be unfamiliar to some organizations that prefer to start with demos and cost comparisons. Instead, consider software selection as you would a hiring process: you define a job description and a general idea of the role's market worth, reach out to your network to identify candidates, and conduct interviews to assess fit. Only at the end do you negotiate compensation and close the deal.

The final artifact

As you progress, compile your insights into a document or artifact that will serve as the comprehensive recommendation for the decision-maker. This document should also show stakeholders how their input shaped the selection process and clarify any trade-offs involved in moving forward. Additionally, it will provide valuable historical context for future discussions, allowing decisions to be revisited efficiently with a clear record of when, why, and how the final choice was made.

Discuss and Decide

If you've done your job effectively, the decision should be straightforward: the value of the solution you recommend should clearly outweigh any identified costs or risks. Ideally, it would be as simple as a checkmark. However, reality doesn't always work that way—new information may surface late in the process, or there may still be uncertainty over whether the primary or secondary option is the best fit. My advice to both the recommender and the decision-maker in such cases is this: don't feel pressured to proceed just because the process has come this far. It's entirely okay to pause, wait for further insights, or actively seek out new information before moving forward.