🎣 The Catchup

Well readers,

I tested positive for COVID this weekend. I made the mistake of telling a colleague “Wow! Compared to last year, November has been awesome health-wise… Nobody has been sick at the house…”

I should just have shut my trap 😅

BUT, instead of wallowing in self pity and tissues, I’ll instead share a picture of glory from last weekend (context here for new readers).

My son can now say “Oh yeah!? Well, my Dad can lift 100 lbs right over his head! When he doesn’t have covid…” when getting into petty standoffs with other kids in the school yard without lying… 😅

This week’s note is about the missing piece between Procurement objectives and your technological roadmap: capabilities. They tie everything together in this age of innovation…

Have a great week ahead.

Best,

Joël

P.S. In case you missed it, here was my most popular LinkedIn post of the week.

What’s the weirdest thing you’ve ever seen on a Purchasing Requisition? (I didn’t think I would trigger people this way 😅). Let me know your best story.

P.P.S. Sorry for the late send tonight… The noggin is slower with covid…

🌙 Sunday Night Note

As you set your Procurement function’s objectives for 2024, I’m sure they include some technological components, whether the implementation of new systems or the improvement of existing ones… (If not, they should!)

In this context, I thought it would useful to review the concept of business capabilities while contrasting it with business and functional requirements.

Now if you’ve ever been in the aura of a software implementation project, you’ve heard about business requirements… (“What do you need the software to do?”). You define what you need and then you find software to fill that need.

Increasingly, I think this question and approach is a trap for Procurement teams. Why? It assumes that you know what you need in detail. In this day in age, that’s a tall order… (think generative AI…)

Given the explosion of solutions now catering to Procurement on the market (there are now 400+ solutions on James Meads’ directory at procurementsoftware.site alone), it is naïve to think you know what you need at a business/functional requirements level. Heck, I study this space for a living and am having a hard time keeping up with the possibilities.

So here’s an approach based on business capabilities which I think is much more useful as you work on developing your Procurement software architecture:

1) Company Values, Mission and Vision

Hopefully, your company’s values, mission and vision are both true and clear. These shouldn’t change often…

Here’s a reminder on their meaning:

• Values → How get things done. The standards in place. The lines we will not cross. The cultural foundation.

• Mission → Why are we doing what we’re doing? What’s the purpose? And it can’t be making money…

• Vision → If you achieve your mission, what does that look like?

As everything else in the business should be based on these 3 foundational pillars, it’s difficult to get clear on the lower levels in this framework when values, mission and vision are only tepidly related to the real day-to-day activities…

I get unreasonably flustered when I see a business with “marketing only” values, missions and visions… It’s fundamental! I’ll assume these are set and coherent for the rest of the exercise. Otherwise, I can’t help you today 😅

2) Company Objectives

When you break the vision down into milestones with timelines, you get company objectives (usually yearly). The clichés are always financial objectives: grow shareholder value, earnings per share, revenue and/or reduce costs (grow profit)… But good objectives answer the “why” question and tie them back to the company mission/vision while respecting the company values. For example:

3) Other Business Unit Objectives

Procurement is a support function. We must never forget this. Before setting our own objectives (which revolve around creating value for the business), we must understand how our core business units are setting their objectives and how they define value. This is the same for other support functions like IT, maintenance, etc.

For example, a given business unit may be focused on growing sales, CAPEX projects and reducing emissions based on the overall objective example above. Procurement needs to be in-tune with the rest of the business and coordinating with other support functions before setting its own objectives.

4) Procurement’s Objectives

Once you are in-tune with the objectives of the core business units, you’ll be able to set internal objectives based on your constraints. An idea, based on our example:

• Execute 50 CAPEX sourcing projects,

  • Clocking in 5% average savings when Procurement is involved

  • Ensuring machinery purchases are evaluated on productivity enhancements and emission reduction vs. current machines before taking the purchasing decision

5) Required Capabilities

Once you have your objectives, you should focus on breaking them down into the business capabilities required to achieve them. Think of People, Process and Technology as capabilities usually require all three. I like writing capability statements out as “X with the Ability to Y”.

For example, to run the CAPEX projects in my objective above, I need:

• A team with the ability to run 50 CAPEX projects in a year

• A process with that will support 50 CAPEX projects in a year

• A system with the ability to support the execution of 50 CAPEX projects

• Or a combination thereof

I may be able to get more detailed with my capability statements if I have meatier objectives. For example, if I know my 50 CAPEX projects will be for Facilities projects, then I will want a team with the ability to run facilities projects. The better the capability statements, the easier it is to determine the steps I need to take to develop this capability.

It may seem unnecessary to convert objectives into capability statements but doing so flips your mindset. Instead of having your team go in a random direction in hopes of reaching the objective, it helps identify the constraints and determine the way forward more systematically and explicitly.

For example, you may not have additional headcount to reach this objective. Therefore, the people dimension of your capability is:

• 3 Category Managers with the ability to run 50 CAPEX projects in a year.

You may be able to get 3 GREAT Category Managers but odds are that you now know you need to focus on process and system to give your existing Category Managers the required ability and your organization the required capability. Perhaps you are able to shorten the process for CAPEX Procurement using business process management principles. You’ll at the very least identify your policy/process constraints here as well.

If that’s not enough, well that’s when you turn to your Technology Architecture and Roadmap.

6) Technology Architecture and Roadmap

Given you now have your required business capabilities, you can approach technology without caring much about the business and/or functional requirements.

Instead of looking at the market and asking “what can you do for me?” with a lengthy RFI/RFP process supported by a never-ending business requirements gathering exercise, you can instead ask “Here’s what we want to do. Here are our constraints. Can you do it? Show me.”

This is a small mindset change but it makes a world of difference in focus, speed and results. In the current market for Procurement applications, players are all experimenting with new technologies, concepts and processes. It’s increasingly unrealistic to think you will be able to compare them Apples to Apples with a traditional RFx event. Especially if you’re trying to do anything innovative yourself.

You should instead rely on business capability statements and use a “small bets” approach to limit risks and maximize value (which is what you’re trying to do with the business requirements based approach anyways).

I’ll cover small bets in detail next week.

💭 Quote of the Week

🏷 Recommendation of the Week

Just finished reading Shane Parrish’s Clear Thinking: Turning Ordinary Moments into Extraordinary Results. I highly recommend it if you’re looking for concrete exercises to improve your decision making. The book is filled with great questions to ask yourself, such as the one below:

P.S. I get a small commission if you purchase a book via my link. Read it either way 😅
You have an offer for Pure Procurement readers? Reply to this email. Let’s see if there’s a fit.

💬 Help Spread the Word

If you like this newsletter, please share it with another Procurement professional in your network. The email writes itself:

“Just read this. Thought of you. Think you’d enjoy it.”