The ProcureTech Pilot Site Selection Algorithm

Beyond the Obvious: Identifying Your Ideal Testing Ground

Hi readers,

Happy Easter is you celebrate!

Otherwise, happy “rabbit brings chocolate” day…

(what’s this holiday about again…?! 😅)

2 things for things for you this week:

  1. What did you think of this year’s ProcureTech Cup event?

    Let me know in this 2-minute survey.

  1. Struggling to select the right first site to deploy your ProcureTech pilot? This week I'm sharing my battle-tested “algorithm” for choosing pilot sites that set you up for success rather than stress.

Onwards!

📰 In this week’s edition:

Note: Some of the content listed above is only available in the email version of this newsletter. Don’t miss out! Sign up for free to get the next edition.

Sunday Night Note Section Header (Blank)

The ProcureTech Pilot Site Selection Algorithm

Selecting the wrong pilot site for your ProcureTech implementation can doom your project before it even gets off the ground. The right pilot site, however, creates momentum that carries your implementation forward and sets you up for the "hockey stick" adoption curve that characterizes successful technology rollouts.

What is a pilot site? A pilot site is the first location, business unit, or department where you implement your ProcureTech solution before rolling it out more broadly. It serves as your testing ground, learning environment, and proof of concept all in one.

The right pilot site can be the difference between a successful enterprise-wide implementation and a failed technology investment.

Synonyms: Proof of Concept, first wave, first deployment, first rollout.

Deployment planning is an art that depends heavily on your organizational context. However, the goal should always be to maximize user adoption while giving yourself time to adjust the solution design during the first few deployments as no solution is perfect at the start...

There's a natural tendency to want to target sites with the highest potential benefits first to realize ROI faster. This is almost always a mistake.

Instead, you want to aim for a "hockey stick" benefits curve – start small with suitable pilot sites, perfect your solution, ensure you have no adoption roadblocks and then rapidly scale when the solution is stable.

Trying to tackle your core business first is a recipe for disaster. The pressure to deliver perfect results immediately will be immense, leaving no room for the learning and iteration that every new technology implementation requires.

When you're drowning in critical issues, there's no time for thoughtful iteration…

But how can you ensure you’re picking the right first site?

Use my algorithm… It’s a series of questions that will guide you to the right choice. I've ordered these criteria from most to least critical, though all are important considerations in your selection process:

1. Do the users actually want this to work?

This is foundational - I've seen countless implementations fail because solutions were forced upon users who had no interest in change.

Look for:

  • Users who have explicitly asked for better tools

  • Teams that have tried to solve this problem themselves

  • Groups that have participated enthusiastically in requirements gathering

  • Sites with previous successful change experience (they've developed "change muscles")

That last point is crucial. Sites that have recently implemented other technologies successfully often have an established change management culture and realistic expectations about technology transitions.

Resistance is the silent killer of technology implementations. Find the users who are pulling for change rather than those who need to be pushed.

2. Is the site important but not mission-critical?

The ideal pilot site sits in this sweet spot:

  • Important enough that people care about its success

  • Not so mission-critical that any hiccup causes organizational panic

You need stakeholders who will give honest feedback because the outcome matters to them, but you also need the freedom to work through inevitable challenges without executive alarm bells ringing.

Spending all your problem solving time briefing executives in escalation meetings is a "death's kiss" for any technology implementation project... 😘😅

3. Is there a culture of learning from failure?

This might be the most overlooked aspect of pilot site selection, but it's critical:

  • Look for sites where "failures" are treated as learning opportunities

  • Avoid sites where blame culture dominates

  • Select teams that document and share lessons learned

  • Find leaders who understand that iteration is part of innovation

Your pilot will encounter bumps in the road - that's inevitable and actually valuable. The right site will use these moments to improve the solution rather than abandoning it or pointing fingers.

4. How many users are involved?

Start small. The fewer failure points, the better.

A site with minimal users allows you to:

  • Provide high-touch support

  • Quickly iterate based on feedback

  • Manage change with personal attention

  • Recover quickly if things go sideways

Each additional user exponentially increases complexity. Save your large-scale implementation skills for after you've proven the concept.

Consider seasonal factors when timing your pilot:

  • Avoid peak busy seasons when users will be too stretched to engage properly

  • Also avoid unusually quiet periods that won't test real-world conditions

  • Choose a "normal" operational period that will give representative results

Remember that while you want to keep the user count manageable, you still need a "healthy transaction volume" to properly test your solution in real conditions.

5. Do the stakeholders have positive relationships across the business?

Your pilot site champions will become your ambassadors. Their connections and reputation will either accelerate or hinder your rollout to other sites.

The ideal pilot site has stakeholders who:

  • Are respected by their peers

  • Have relationships that span across departments

  • Are seen as thoughtful adopters rather than technology zealots

  • Can influence decision-makers in other business units

Remember, after your successful pilot, you'll want to create a "hockey stick" growth curve – starting slow with careful implementation, then rapidly accelerating adoption once the solution is proven. This only works if your early adopters have the credibility to convince others.

A successful pilot needs vocational champions who can tell your success story for you. Great testimonials from outside the project team will go a long way!

6. Are the users demanding?

Counter-intuitively, you want to deploy solutions to your most demanding users first, not your easiest ones. Why?

Demanding users will:

  • Force you to truly understand their needs

  • Push your solution to its limits

  • Require you to demonstrate real value, not just flashy features

  • Help you build empathy for all users across your organization

The demanding users make your solution better.

If you can win them over, you can win anyone over.

7. Does the site represent your broader organization?

While you want to start small, you also need a pilot site that's representative enough that its success can be replicated. Look for a site that:

  • Uses similar processes to other parts of the organization

  • Has typical, not unique, requirements

  • Deals with the same suppliers and spend categories as others

  • Experiences the same pain points you're hoping to address widely

  • Covers a high proportion of the categories/commodities and purchasing channels in scope

  • Works with a supplier ecosystem that's relatively digitally mature

That last point is often overlooked. A pilot site that works primarily with tech-savvy suppliers who can easily adapt to digital procurement processes will have a smoother implementation than one dealing with suppliers who struggle with basic digital communication.

The objective is to find a site where high adoption is likely, where they will be open to collaborating on design iterations with you as an early adopter but where the site isn't absolutely critical to business results.

A pilot that succeeds under unique circumstances won't provide the blueprint you need for broader rollout.

8. Is the process maturity level high?

Look for sites with high procurement process maturity. Why is this important?

  • Mature processes are better documented and understood

  • Teams understand the "why" behind process steps

  • They can more easily articulate what works and what doesn't

  • They'll provide more valuable feedback on your solution

Immature processes often hide underlying issues that have nothing to do with your technology. Starting with mature processes isolates the technology variable in your pilot.

9. Is data quality sufficient?

Data quality is often overlooked but can make or break your implementation:

  • Look for sites with clean, accessible spend data

  • Ensure supplier information is well-maintained

  • Historical transaction records should be readily available

  • Master data should be consistently formatted and accurate

  • Key fields for reporting should have good fill rates

Poor data quality can mask technology successes or create problems that have nothing to do with your solution. Starting with quality data will make implementation smoother, success measurement clearer, and user adoption more likely.

When users trust the data in the system, they're more likely to trust the system itself.

10. Will you have time for proper hypercare?

If you really want to ensure success, give yourself more hypercare time (post Go-Live support) in the first wave than in subsequent deployments:

  • Plan to be onsite with them if possible - nothing beats in-person adjustment

  • Aim for the "80%+ perfectly deployed" mark before moving to the next site

  • Include a generic "catch all" process in the initial design for any unexpected scenarios you may have missed

  • Allow for multiple reinforcement touchpoints (2-3 minimum) for proper adoption

Remember that according to change management principles, training as a "one and done" exercise won't lead to retention and adoption. Can you plan for more touchpoints than subsequent deployments with your first site? This additional investment (+ measurement) will dictate how many training sessions you need in subsequent deployments for proper adoption.

The right pilot site isn't always the most obvious choice. It's rarely the largest business unit or the one with the loudest complaints. It's the site where you can demonstrate value, learn quickly, and build advocacy for wider implementation.

While this algorithm provides a comprehensive framework, you may have a hard time finding a pilot site that meets all of these criteria. That's completely normal. Here's what I recommend:

Create a simple matrix of potential sites against this list, scoring each site 1-5 on each dimension (1 = low score for question fit, 5 = high score for question fit).

This exercise will make the choice much clearer for you. Pick the best option you have in your reality.

Perfect pilot sites don't exist, but this structured approach will help you identify your strongest candidate.

Remember: The last thing you want is to be tweaking a solution in a site where pressure mounts exponentially through the organization for every minute operations is impacted by an IT bug in your solution.

The Benefits Trap

I lightly referenced this above… Manny organizations fall into what I call "the benefits trap"… They prioritize sites with the highest potential ROI first. This approach seems logical on paper (quicker payback!), but it ignores implementation realities.

Your highest-value sites are often:

  • The most complex

  • The most visible

  • Under the most pressure to deliver results

  • The least forgiving of mistakes

Instead, follow the path of successful implementations:

  • Start with suitable pilot sites according to the above question (not necessarily highest-value)

  • Perfect your solution through iterations

  • Build internal testimonials, case studies and references

  • Create implementation playbooks

  • Only then target your highest-value sites

This creates the "hockey stick" benefits curve that characterizes successful technology implementations: measured early adoption followed by rapid acceleration once the solution is proven.

What has been your experience with pilot site selection? Did I miss any selection criteria you’d add?

Let me know in the comments 👇

👀 In Case You Missed It…
The Last 3 Sunday Night Notes:

1/ Limited Ammunition: The CPO's Digital Dilemma 
2/ Big Consulting's ProcureTech Blind Spot 
3/ What the Heck is An "AI Agent"? 

Quote of the Week Section Header (Blank)

Rejection isn’t a verdict; it’s data. Use it.

James Clear
That's a Wrap Section Header (Blank)
  1. Need Help Building Your Digital Procurement Roadmap?
    I’ve been helping global procurement teams digitalize their processes and practices for 12+ years. Reply to this email to get a conversation started.

  2. You have something to share with our 10,000+ readers?
    The digitally-minded procurement professionals reading this newsletter are thirsty for knowledge, insights, and solutions. Reply to this email to get in front of them.

See you next week,

P.S. Please rate today’s newsletter.
Your feedback shapes the content of this newsletter.

How did you like today's newsletter?

Login or Subscribe to participate in polls.

First time reading? Sign up here.

Reply

or to participate.