Category Archives: Technology

Proper Project Planning is Key to Procurement Project Prosperity! Part 2

In Part 1 we noted that we wrote about the importance of Project Assurance, and how it was a methodology for keeping your Supply Management Project on Track, ten years ago and that this typically ignored area of project management is becoming more important than ever. Given that the procurement technology failure rate, as well as the technology failure rate as a whole, hasn’t improved in the last decade, and is still as high as 80% (or more) depending on the study you select, that’s a problem. Especially when, for many companies, theses projects typically start in the million dollar range. (Even if the annual license is only 100K, by the time you multiply that by 3, the minimum term any vendor will give you, the annual maintenance fee by 3, and then add the implementation, integration, training, and ongoing integration maintenance costs and ongoing training costs, it’s well over 1M.)

But we also noted whereas there might have been a time when this was enough to tip the odds of success in your favour, it’s not quite enough anymore. Given the complexity of modern procurement (which hasn’t had as many complex problems to deal with simultaneously in over two decades) and modern technology (which is now AI enabled, AI backed, AI powered, AI enhanced, and or AI driven, even if it isn’t), when most organizational users are still struggling with basic technology (not enabled, backed, powered, enhanced, or driven by [fake] AI bullcr@p).

We told you we were going to dig into the project steps and help you understand what you need to do to get it as right as you can and greatly increase your odds of success. But first, there is one critical action you need to make that is common to all steps that is critical for your Procurement Project Prosperity and that is:

  • Engage an independent expert to guide you through the entire process and help where needed, including assurance.

As noted, this individual

  • cannot be an internal resource, even from a different department, as they are still subject to the internal pressures from the C-Suite (fast, cheap, etc.) that might be counter-productive to project success (that is critical for eventually obtaining the ROI you purchased the platform for in the first place)
  • cannot be a vendor representative as their only goal is to get you to buy more, or at least keep your subscription at the initial purchase level (which likely contained seats you never used, SKUs you don’t use enough to justify, and third party feeds/integrations you aren’t taking advantage of)
  • cannot be an implementation team representative, even if they are a third party consultancy, as the odds are that consultancy has a preferred partnership with the vendor and will be biased towards keeping the vendor and doing whatever is easiest (and thus most profitable for) the vendor to keep getting their implementation referrals

Now, what’s the difference between helping and pure assurance? In addition to making sure each step is accomplished effectively, this person is also guiding you through the creation of the necessary artifacts of each step to ensure success. This person is helping you define the goals, not just ensuring the goals are met. The person is simultaneously a project guide and a project evaluator, bringing the Procurement Best Practices and Technology Knowledge that your organization doesn’t have, and helping you identify the right intersection to take you forward on your journey.

And this goes well beyond just helping you write an RFP (although this is a key step, which is why the doctor has been telling you to get expert RFP help for your Procurement technology RFP for close to two decades, because a bad RFP is one of the leading causes of project failure).

This is because, as we noted ten years ago in our original Project Assurance Series (Part I, Part II, Part III, Part IV, and Part V), project success depends on more than just getting the technical specifications right. Project success also depends on getting the talent right — as it is the people who will have to use the new system. And project success also depends on getting the transition right —- if the changeover is not smooth, significant disruptions to daily operations can occur. And, equally important, they also depend on an often overlooked 4th “T” —- tracery. Organizational success depends on selecting a superior strategy and seeing it through until the desired results are achieved (or the organization changes the strategy). (And since you don’t know what you don’t know, the small cost of engaging an expert, relative to the overall project cost, will generate a return far, far greater than the technology ever will.)

Tracery, which stems from late Middle English, can be defined as a “delicate, interlacing, work of lines as in an embroidery” or, more modernly, as a “network”. Implementing a strategy requires effectively implementing all of the intersecting “threads” that are required to execute the strategy to success. If any one aspect is overlooked, the project can fail. And if you can’t even see all the threads, it should be easy to understand how most projects essentially fail as soon as they begin and why you need a master weaver if you want to beat the odds and actually succeed.

Come back for our next installment where we will dig into the six traditional project steps outlined in our original series and dive into what your independent, third party, Procurement technology project guide (who will be independent from you, your vendor, and the vendor’s third party implementation team) needs to do.

Procurement Organizations Need Automation, But that DOES NOT Necessarily Mean AI!

A number of leaders in our space, including Sarah Scudder in the comments to this post, have been noting to me that they are seeing AI resonate with companies of all sizes.

Sarah notes that:

1. She’s seeing AI agent automations resonate with smaller companies.

Smaller companies need automation desperately, but it’s important we educate smaller companies that doesn’t mean they need AI. We’ve had adaptive rules-based automation and tailored machine learning in this space for almost 20 years and they can get fantastic results without having to risk being pre-alpha testers for unproven AI while getting the solution they really need for a fraction of the cost of this new, relatively unproven, AI tech! (Remember, firms that dumped millions into this bandwagon need to recoup those millions fast before their investors abandon them, which means high prices for unproven tech!)

2. She’s seeing copilot intelligence resonate with bigger companies who understand risk.

Which makes sense for a small segment of the market who are ready for it because augmented intelligence and automated suggestions with yes/no approvals are great for organizations who

  1. understand risk and
  2. understand the categories/markets/domains they are applying the technology in, because a true expert will identify the 95% of the time it’s working just fine; the 3% of the time it’s probably okay (and not worth the effort to double check manually due to the risk threshold); and the 2% of the time they need to slam the breaks and take over.

However, that’s not a very large segment of the market. What most companies still need is better analytics, category intelligence, and guidance from category experts on how to use it and then where and when to integrate automation and co-pilot capabilities.

Furthermore, I’m also being told that:

3. Mid-Markets are looking for technology they can roll out to the organization at large to get tail-spend under control, manage intake, and/or relieve pressure on Procurement to focus on more strategic efforts.

Which resonates, but, again, this is an area where AI is typically not needed. Catalogs, be they hosted, punch-out, hybrid, etc. with the ability to also request/book standard, pre-negotiated, services, easy search, and easy RFQ where there is no standard item but the buyer has budget authority, the vendors are preferred, and the amount doesn’t hit a threshold is often enough. Maybe a natural language search to find the right policy documents or bring up the right products or forms, but that doesn’t require modern AI either — we’ve had that for quite some time as well.

And, as Sarah implies, while organizations of all sizes need help to overcome their excessive workload and limited market insight so that they can prioritize risk management and mitigation in their procurement activities, this doesn’t mean they need AI. Automation yes, advanced technology a definite yes, but AI, rarely! Remember that when building and recommending ACTUAL solutions and not just buzzwords.

Proper Project Planning is Key to Procurement Project Prosperity! Part 1

Ten years ago we wrote about the importance of Project Assurance, and how it was a methodology for keeping your Supply Management Project on Track (Part I, Part II, Part III, Part IV, and Part V).

We told you that Project Assurance, which takes a proactive approach and tries to identify issues, and implement mitigations, before they arise, involves the organization periodically stopping to objectively assess project failure points as they arise, typically with the help of an outside third party who can be completely objective, to identify what is and is not being done well and what could cause failure later if not adequately addressed now.

In traditional Project Assurance, there are six health assessments at six critical points in every project (for each of the six initial project phases defined by the classic waterfall project methodology). In particular, there is an assessment at each of the following steps:

  • Strategy (Pre-Presentation)
  • Acquisition (Pre-Vendor Selection)
  • Planning (Pre-Design)
  • Design (Pre-Acceptance)
  • Development (Pre-Testing)
  • Testing & Training (Pre-Acceptance)

And that the right assurance expert can help you with

  • expectation management during the strategy development
  • narrowing the procurement gap during the acquisition phase
  • aligning the troops during the planning phase
  • delineate the disconnect during the design phase
  • evaluate for acceptance during the development phase
  • tame the transition during the testing and training phase

And we stand by these posts and the importance of a third party expert helping you with the assurance ten years later, because we feel that if more companies adopted the methodology, we might not be in the situation a decade late where we still have a ridiculously high failure rate in procurement technology projects (as well as technology projects as a whole), that, depending on the study quoted, still exceeds 80% in some cases.

But we also recognize that, given the complexity of both modern Procurement (which hasn’t had so many issues to deal with simultaneously in over two decades), and modern technology, project assurance isn’t enough to save a project that isn’t planned right from the get go. (You just don’t have time to identify and fix all the problems once things get underway and you have the army of grunts simultaneously doing the implementation, all the integrations, and training as they try to rush an enterprise project that used to take two years and get it done in 9 months so they can promise payback within a year (which never happens when they do this — but that would be a different rant).

So, in this short series, we are going to dive into the project steps and help you understand what you need to do to get it as right as you can and greatly increase your odds of success.

If You Still Don’t Believe That Gen-AI is Bad for Procurement …

Then maybe you should do the math.

It’s very expensive for what it doesn’t do. You can pay 10K a month or more just for a conversational interface to search your data or push data into your applications. For 10K a month, you can get a decent core P2P application or source-to-contract application that, well, actually does something.

It’s even more expensive to train these systems on your policies, connect them to your applications, test that basic requests generate reasonable responses, train it to guide your users to get to an eventual answer, and so on. This could easily be more than a year or three of license fees.

But the true costs are in the utilization. Every time a user asks a question, or responds to a question posed by the Gen-AI to try and elicit the users intent, it takes compute time. LOTS of compute time. At least 10X the compute time of a standard search engine or keyword based retrieval system. In some cases, 30X. (The wattage required is easily 10 to 30 times traditional Google search.) So if you’re a mid-sized organization with more than 1,000 employees, a portion of your cloud computing costs, which average between 2.4 Million and 6 Million a year (according to CloudZero), is going to increase 10X to 30X. Let’s say 5% of that was basic search and inquiry, 120K to 300K. Almost inconsequential. But multiply it by 10 to 30, and you’ve just added another 1 Million to 9 Million to your bill. Think about that.

That “low-cost” Gen-AI “chatbot” that makes enterprise search and application interface “easy” (but not as easy as a well designed workflow, FYI), that you think costs 10K a month after implementation, training, and most importantly, cloud computing costs could actually be costing you 100K a month (or even 500K). For what? A fancier Google?

As Procurement professionals, you can, and should, do the math. So even if you don’t believe the doctor when he says Gen-AI is a fallacy, then believe the math.

The math says Gen-AI is just NOT worth it.

How Should a Provider Qualify a Client?

Carefully.

But let’s backup.

Not that long ago, THE REVELATOR penned a post that asks what are the most important things a solution provider needs to know about a practitioner-client.

This was followed by a post that asked why are some clients successful and others not.

And the answer here is simple:

The Wrong Fit.

Which means that if the provider wants a successful client, they need to make sure the client is the The Right Fit and that they, as a provider, have The Right Stuff.

It’s not about the size of the cheque the client can write, it’s about the size of the value the provider can deliver, because if the provider can’t deliver value, there will only be one cheque. But if the provider does a great job, the cheques will keep coming year after year after year. And those cheques will get bigger over time. (A successful organization focusses on lifetime value, not one-time value.)

So, how does a company qualify a client?

In the comments, the doctor outlined a few key points that included:

  • what problems is the client looking to solve (and why)
  • what problems should the client be looking to solve (and why)
  • are those problems the provider can appropriately solve at a price point the client can afford, at a TQ (Technology Quotient) level the client can handle, and at a realistic ROI both parties can be happy with

But first, the provider needs to answer the following:

  • what problems does their solution solve, and solve well
    … and do they have successful clients they can point to
  • what processes do the successful clients follow,
    and can those processes be easily adopted by other organizations
  • what culture does the company have, and what cultures does the provider mesh with

And then, the provider needs to figure out:

  • if the problems the client is looking to solve are the problems the client should be solving
  • if not, can the client be educated into the problems they should be looking to solve (and can the provider accomplish that)
  • are the client’s problems appropriate to the provider’s solutions
  • and will the client adopt the right process modifications
  • and, finally, will the companies cultures mesh

And if any of these questions come up no, the client is not one the provider should take.