Is Your Procurement Policy a ‘Ticking Time Bomb’?

Sunday night! Time for another Sunday Night Note.

After a week, my boy is getting over the excitement of being able to get up from his bed (thanks for asking 😅). See last week’s note if you have no idea what I’m talking about…

Fall is here in Montreal. The reds, oranges and yellows are starting to make their appearance on the trees. A beautiful (but short) time of year! It’s also typically a period where many ProcureTech implementation projects get going. This got me thinking about the topic for this week…

As you write up your project charters, make sur you’ve thought about the influence of your Procurement policy on your project before it rears its ugly head as a risk/issue in a project status meeting… You’ll be glad you asked yourself the below 2 questions…

Have a great week ahead.

Best,

Joël

Is Your Procurement Policy a ‘Ticking Time Bomb’?

One of the constraints I have often encountered during Procurement Tech implementation projects is the "suboptimal legacy Procurement policy" constraint. This is when an organization has a legacy Procurement policy that hasn't been updated in 5-15 years. It was written in a different 'age'... 😅 But, because changes require approval from the heavens (e.g. your board of directors), Procurement organizations were discouraged from seeking any improvements to the policy over time... Navigating a change to approval seems impossible!So, instead of adapting and modernizing their policy, organizations have developed manual processes to cope with odd and old requirements. This ensures they'll pass internal audits and everyone stays happy (although inefficient...). This becomes ‘business-as-usual’ and fades to the background.However, this constraint quickly becomes an issue as you introduce technology into the fold... A key assumption, although perhaps not documented in your S2P project charter, is usually that the Procurement policy will remain As-Is when implementing tools.Now, I'm sure you're starting to sense the problem... Let's say my policy gives very imprecise and wide ranging direction on who can approve different types of purchases in the business. When you come to implement that in a system, there are no business rules to implement! The project team realizes this mid-project, scrambles to find direction and it becomes a huge risk to the success of the implementation.

Either that, or you design rules at the project level but get push back from stakeholders who say the new tool is too complicated and they would rather just follow the policy as it is currently written…So, why am I telling you this?I want you to get out ahead of this earlier rather than latter... Re-read your existing Procurement policy and check for 2 things:

1. Are there wide ranging, imprecise rules in the policy for any process that would make it hard to automate/implement in a system?Systems are great at automating precise business rules. Without them, you're just left with questions with no answers: “So who should approve this example requisition? Why? What do you mean ‘it depends’? That's my line... 😅”

2. Is there an easy, document change control procedure that will allow you to make changes to your Procurement policy without having to move ‘heaven and earth’?You need flexibility to adapt your Procurement policy, especially if you're in a period of digital transformation. Without it, you'll feel like your hands are tied by the legacy policy and won't take the best business decision...

Regardless of where you are in your digitalization journey, I encourage you to fight this 'policy update fight' now while it's inconsequential. Your future self will thank you!

—

Quote of the Week