Requesting Requirements

Requesting Requirements

RFI. RFQ. RFP. RFT. RFO. RFS. Oh, FFS.

Immediately I’m seeing meetings that start with Subject Matter Experts (SME’s), spread to some form of Procurement, Finance get added in, Legal of course are required, IT, Security, Profit Protection, Sales and suddenly what was a fairly simple idea has become a cross-functional behemoth.  It is, of course, absolutely necessary that the right stakeholders are involved at the right time, with the right framing, but there is a huge difference between providing input and driving.

It’s not been a one-off occurrence and has ended up like this because the first conversations, those at the SME level, have quickly morphed into conversations about suppliers as opposed to being about the operating model, the long-term strategy of the business or even the problem we're ultimately trying to solve. Instead, it often begins with names, perhaps someone has seen an impressive technology demonstration, or, worked successfully with a particular logistics provider before, or it’s a Gartner report that has found its way into a meeting or errant deck. Before long, there is a growing list of vendors to engage, warehouse operators to visit, transportation providers to benchmark and software platforms to evaluate.

There is, of course, nothing inherently wrong with any of that, we are blessed to be working at a time where the market is full of outstanding providers who’ve invested enormous amounts of time and expertise into building genuinely impressive capabilities. As a leader in logistics I have got more available to me than ever before in the form of visibility and data management tools especially - innovation in our industry has never been stronger. The challenge isn’t that these solutions exist; it is that they can unintentionally shape our thinking before we've properly understood our own requirements.

Procurement is frequently viewed as a commercial exercise where we compare pricing models, negotiate contract terms, assess implementation timelines and evaluate service offerings. Those are all important components of selecting the right partner, but in my experience they are not where successful procurement projects are won or lost.

I have seen the most important work happen much earlier, before the Request for Proposal has even been drafted - in the conversations that force an organization to understand itself.

That sounds deceptively simple, I mean surely every procurement exercise begins by defining requirements? In theory, yes. In practice, however, there is a subtle but important difference between documenting what we think we need and genuinely understanding why we need it – let alone the fact that the majority of times requirements are reverse engineered on the solutions available.  Time and time again I have seen the requirement building get driven by ‘this won’t be available’, ‘this is not offered’ as opposed to truly documenting what the organization actually wants.  It doesn’t mean everything on the list will be available, and it absolutely should be organized/categorized by priority (I like a simple must have, should have, could have structure), but without that true core list, inherent challenges within a supply chain may never get solved, or worse, become technical debt.

I've been fortunate to lead procurement exercises covering transportation providers, warehousing operations, technology platforms and professional services and each one has reinforced the same lesson: The organizations that achieve the strongest outcomes are not necessarily those that conduct the most detailed supplier evaluations but the ones that spend the greatest amount of time understanding the business they are trying to improve.

It is remarkably easy to become captivated by capability; technology demonstrations are designed to inspire confidence; warehouse tours showcase the very best examples of operational excellence; transportation providers present dashboards filled with performance metrics, predictive analytics and visibility tools. Every supplier quite understandably wants to demonstrate the breadth of what they can offer, and many of those capabilities are genuinely exceptional.  A more recent development on the platform side is that many companies are now doing everything as they favor modular design (e.g. TMS, Freight Audit, MRP, etc.). The danger is that organizations begin building their requirements around what suppliers have chosen to present rather than around the outcomes they are actually trying to achieve.

I have seen procurement exercises where requirements documents seem to have evolved directly from a series of vendor demonstrations and features that looked impressive during a presentation suddenly become mandatory requirements, despite nobody having asked whether they solve a meaningful business problem. Worse than that, I have seen actual requirements slip off because they have not been prioritized or weren’t part of a vendor presentation. Workflows become increasingly bespoke, not because they create competitive advantage, but because the capability exists and an underlying sentiment of ‘it’s there, so we want it’.  To truly lead in both supply chain and the procurement process, perspective and discipline is required in separating genuine requirements from attractive possibilities, understanding that the two are not the same thing.

I strongly believe that procurement is one of the purest forms of strategic leadership, forcing organizations to articulate what success actually looks like, demanding alignment between functions that often have different priorities, and being explicitly clear in what area each stakeholder is responsible and accountable for.  Finance naturally looks through the lens of return on investment and cost control, Operations focus on execution, resilience and service, Technology teams consider integration, architecture and scalability. Commercial functions understandably prioritize customer experience and growth. None of these perspectives are wrong, but they are rarely identical, and successful procurement depends upon bringing them together long before suppliers are invited into the conversation.

Rather than falling into ‘AI slop’ style content and listing all of the challenges, it’s more helpful to focus on what does make the difference. Every successful procurement exercise begins with understanding the business before understanding the market (of vendors/suppliers) – a frequent question I will ask is “What is the problem we are trying to solve?”.  It’s not particularly revolutionary but if you/the team can’t answer that then you’re in trouble.  It can be simple discussions about who we are as an organization today, where we want to be in in a years' time and whether the investment we are considering genuinely helps us get there. Those conversations are not always straightforward and can expose differences of opinion, challenge long-held assumptions and occasionally require difficult compromises. They are, however, infinitely easier to have before a contract has been signed than after a solution has already been implemented.

Success looks like investing time in defining what success actually looks like. That is a horrible sentence, grammatically, but it gets the point across.

One project in particular has remained with me because it fundamentally changed how I approach procurement. I inherited the project part way through – the initiator had assembled a strong cross-functional team who were making what appeared to be good progress with suppliers identified, timelines established and discussions were becoming increasingly detailed. From the outside looking in, the project looked healthy.

The more time I spent within the project, the more uncomfortable I became and red flags began to pop up. The first one was that while we had a cross-functional team there was no consensus on what success looked like - Operations quite understandably focused on execution, service levels and scalability. Technology, however, were not engaged until far too late and it felt like we were laying track while the train was moving with integration conversations happening in parallel with negotiations being finalized.  We were negotiating for a service that we didn’t truly know how we would implement – how on earth would we calculate cost, ROI, resource investment or even capability?!

It wasn't that the suppliers were wrong, nor that the people involved lacked capability, in fact everyone was working hard and making sensible decisions based on the information available to them. The problem was that we had allowed the procurement process to gain momentum before we had reached genuine alignment internally, attempting to evaluate solutions before we had fully agreed on the problem.

Stopping a project that already has momentum is never comfortable, especially one approaching its final phase, and in this case, a potentially paradigm-shifting solution. On one hand I didn’t want the team to feel that they had worked hard for nothing, or that the work wasn’t valued, but as a leader I have a responsibility to ensure that we’re acting responsibly and in the best interests of our organization.  Also, being utterly selfish for a second, this project, despite not being initiated by me, would have my name on it and I will not be associated with mediocrity.

A week before we were going to sign the contract, I called time-out and informed the team, our organization and our selected vendor that we were going to stop the project, return to the drawing board and resume with truly defined requirements.  Looking back, pressing pause was, without a doubt, the most valuable decision we made. It gave us the opportunity to ask the truly important questions that had not been satisfactorily answered previously:  What capabilities did we genuinely require? Which problems were preventing us from achieving our strategic objectives? What would success actually look like 12, 24 and 36 months after implementation rather than simply on the day the contract was signed?

One of the disciplines I have tried to encourage within procurement exercises is the willingness to ask "why?" one more time than feels comfortable. Why is this functionality essential? Why does this process exist today? Why is this service level necessary? Sometimes those questions uncover genuinely critical requirements that absolutely deserve investment, or, better they can reveal that a particular process has simply existed for so long that nobody has stopped to consider whether it still adds value.

Those conversations can be surprisingly revealing, often exposing opportunities that have very little to do with procurement itself. A requirement initially believed to necessitate a new technology platform may instead be solved through process redesign. A perceived warehouse issue may actually stem from inventory policy. Transportation costs may be driven less by carrier performance than by ordering behavior elsewhere in the organization. The procurement exercise becomes valuable not because it identifies a supplier, but because it forces the organization to understand itself more deeply than it did before the project began.

So, when building out your next procurement project, ask why.  And then ask it again.