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:
What did you think of this year’s ProcureTech Cup event?
Let me know in this 2-minute survey.
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:
📄 Please fill out the 2025 ProcureTech Cup Survey
🌙 The ProcureTech Pilot Site Selection Algorithm
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.
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:
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.
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... 😘😅
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.
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.
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!
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.
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.
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.
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.
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.
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"?
Rejection isn’t a verdict; it’s data. Use it.
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.
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? |
First time reading? Sign up here.
Reply