Operations Research Lessons are Timeless … Especially in the Age of AI

Twenty years ago we published a piece focussed on Mark Daskin’s Everyday Lessons from Operations Research that he delivered at INFORMS 2006. They are just as relevant today, if not more so, in the age of AI (Hype).

  1. Service and Performance Gets Worse as Utilization and Variability Increase
    This is true in so many ways. Dumb users asking stupid questions with poorly formed prompts that don’t match the training prompts flooding the internet with poor and hallucinatory answers that are fed into the next AI model in the collective race to the bottom. Response times decreasing as the models need to get bigger to process ever more mediocre data and, hopefully, create better responses (even though that won’t happen). Costs going through the roof as a result of the constant need for more computing power.
  2. … But Variability is necessary.
    Because every request is fundamentally different, even if phrased the same as the lack of standardization, and training on that standardization, ensures every user has a different intent with their request.
  3. Expect the unexpected in today’s world.
    Most responses will be okay, some will be bad, a good number will be completely hallucinatory, and every now and again the hallucination will provide a revolution insight — which will go unnoticed because most users now lack the cognitive power, and possibly the intelligence, to even detect a hallucination in the first place due to the mass cognitive atrophy Gen-AI is, provably, inducing.
  4. If it is too good to be true, it probably is not.
    But yet we continue to believe the lies, damn lies, and hallucinatory hype spewed by the purveyors and pushers of Gen-AI and the garbage it spits out.
  5. Life is full of errors.
    And Gen-AI multiplies those errors tenfold to ten-thousandfold!
  6. A good decision can result in a bad outcome.
    Even when the AI gets it right on the data, the data is always backward looking, not forward looking, and the right decision based on a past trend can still be wrong if a key variable or assumption just changed and the data does not yet reflect that. So even when the AI actually gets it right, it can still be wrong!
  7. If you are not using all you have, don’t pay for additional quantity.
    If you only have a small amount of data to train the model on, don’t pay for the largest model available — not only will it not help your case, it will hurt as there won’t be enough data to “train” the model even to reasonable levels of accuracy (relative to what the model is theoretically capable of). Always go with the smallest model that will theoretically meet your needs — and, moreover, if you have multiple distinct needs, multiple distinct models will perform much better than trying to create one big mega model.
  8. You can never do better by adding a constraint.
    Never, ever, ever. Whatever you are trying to minimize will increase. Constraints restrict options and that will always result in increased cost, increased risk, etc.
  9. Keep it Simple
    The best AI, especially in the age of Gen-AI, is no AI. More specifically, don’t use AI where AI is not needed. Deterministic automation, when properly applied, has worked well for decades and now, in an age where we can encode adaptive workflows, suggest exception resolutions, have the rules automatically update when a resolution is accepted or created, and improve over time.
  10. Think about problem formulation.
    The formulation dictates the potential solutions … and the better you define a problem, and a stepwise algorithm to resolve that problem, the less need you will actually have for (Gen-) AI.
  11. Look for compromise solutions.
    If a problem ends up being defined particularly constrained or complicated when multiple parties get involved, work together to simplify the constraints or complexity where it truly isn’t needed. There’s a big difference between preference and requirement, and understanding that allows for the creation of good comprise models and solutions.
  12. Data is not information.
    It never has been, and never will be. Moreover, data pulled out of an LLM might not even be accurate, so the chance of it producing usable information is even less. Always remember that.

Procurement Hasn’t Learned Any Lessons in the Last Two Decades! Part 4

William Hefley’s 15 lessons learned from dealing with client organizations talk on “Identifying Issues in Sourcing: Informing Development of Best Practices” that was delivered at the 2006 Informs Annual meeting aren’t the only lessons that should have been learned 20 years ago that still haven’t been learned by the majority of Procurement organizations today. So we continue the series!

16. Process Change Requires Mapping, Desired State Definition, Gap Analysis, and Change Management

Any time the C-Suite decides a process needs to be updated, a department outsourced, or a solution replaced, they jump right to bringing in a Big X consultancy to tell them what to do without understanding exactly what they are doing now, what they need to do in order to improve, and what the gap is. They give the consultancy a big picture objective, desired outcomes, and tell them to go, go, go. The consultancy feeds the company profile, the company requests, and their standard advice and decks into an LLM and has it produce a 200 slide strategy deck. Then they hand it to the new interns, fresh faced graduates with no real world experience, to review and touch up and draft a “killer executive summary”. The interns shunt it up to the project lead, who spends an hour customizing it to his story telling style, books the delivery meeting, presents it, makes exaggerated promises, and everyone cheers.

A project with little thought goes ahead, gets delivered, and then crashes and burns. And the cycle repeats.

17. Major Technology Implementations/Replacement and Supply Chain Network Redesign are Mega-Projects

Every organization treats these as simple sourcing and simple one-and-done projects when nothing could be further from the truth. Technology project (partial) failure rates are past 88% and AI project failure rates are 94%. The odds of you succeeding are insanely bad! The reason is that every one pretends they are simple projects, unrealistic timelines can be easily met, and adoption will automatically happen when the implementation is complete. We all know nothing could be further from the truth. But even worse, buyers continually reward vendors who underpay the effort, present the shortest project schedules no matter how unrealistic they are, and give many assurances that their incredible ease of use will make users want to use the solution.

18. If An Engagement Doesn’t End At Least As Much As it Starts, It’s A Lost Cause!

Companies love to add new processes, new SaaS solutions, new technologies, new product lines, new service lines, new support partners, and new GPOs to “keep costs down”. But very few ever completely end processes, decommission SaaS (especially if the licenses can be put on P-Cards / personal credit cards), retire old product lines, block user preferred services, etc. It’s uncountable how many times organizations have brought in vertical experts to optimize telco costs, streamline SaaS costs, consolidate janitorial and suppliers and MRO, etc. only to see half the promised savings never materialize as some offices refuse to change carriers, give up their preferred SaaS app (which is why some enterprises have over 1,000), still buy what they need as-needed from the local distributor, etc. Without the resolve to end things, new engagements don’t deliver because anything they “save” or “improve” gets “lost” or “degraded” because the organization just diverts focus even further.

19. A Needs Assessment Must Precede Any Services Selection and Engagement

Right now, most consultancy based projects start as a result of a balance sheet exercise, a consultancy push, or a technology hype cycle. In the latter case, right now the vast majority of organizations are engaging Big X consultancies to help them with their “Gen-AI” initiative — even though they have no idea how it works, what it does, or where it should be applied. The same thing happens every time a new consultancy craze (outsourcing, rightsizing, DEI, etc.) comes along. And any time the CFO decides a cost is too high and the CEO mentions it to a consultancy CEO, suddenly there’s a new demand for a transformation project to cut costs. All without any analysis of what the organization actually needs, what opportunities there are for real process improvements and cost reductions, and what the organization actually needs to achieve success.

20. There’s No Success Without Project Assurance

And, of course, every organization believes that once the project is done, the new process will be adopted, the new system will be used, and results will magically materialize. The reality is that without a proper change management and training plan, stage based implementation, work alongside training and monitoring, and general project assurance, the new process will be ignored, the new system bypassed, and nothing will change. And in two and a half decades in this space, I’ve never seen a system implementation or process transformation plan with proper project assurance.

Procurement Hasn’t Learned Any Lessons in the Last Two Decades! Part 3

Twenty years ago we wrote a post on William Hefley’s talk on “Identifying Issues in Sourcing: Informing Development of Best Practices” that was delivered at the 2006 Informs Annual meeting. In it, he presented 15 lessons learned from dealing with client organizations. Fifteen lessons that, apparently, the vast majority of organizations still haven’t learned 20 years later. We’re going to conclude our discussion of Hefley’s initial list to make it clear how little progress Procurement has actually made in the last two decades.

11. Clients typically do not execute communication plans for internal or external audiences.

To be more precise, they typically don’t even bother creating communication plans. For a technology / SaaS purchase, the affected users are told a switchover is coming and when they’ll get training. That’s it. Shock and Awe might work in marketing campaigns, but it just scares the sh!t out of users who spent a considerable amount of effort learning how to use the existing systems, and who have lived through multiple system replacements where none delivered on the promises and just made their lives more difficult.

No thought is put into explaining why, what effort was made to understand their role, how they ensured the new system would not take away any capabilities the users depended on and would only add more useful functionality. No explanation as to how the switchover would take place, what hands-on training would be available, and what support would be available if additional help was needed.

And eve if the vendor outlines a plan, the customer ignores it and assumes the vendor will handle what is needed when the time comes. And then the customer wonders why adoption lags and users do their best to bypass the new process, system, etc.

12. Buy in of management, power brokers, and other key stakeholders is important for any project.

In many departments, including Procurement, once they are assigned the project, they just run with it. Being overworked and under-resourced, the goal is to get it done, but ignoring the stakeholders just makes things more difficult when it comes time to validate the final selection, sign the contract, and/or switch the product/service/solution. They will resist not just because they were’t included in the process, but because they have no reason to believe the product/solution/service is better. A communication plan is essential to getting stakeholders involved in the process.

13. Clients are seriously challenged by internal and external change management.

This is the understatement of the centuries — this century and last century at the very least. The rise of decentralized organizations, the lack of cross-functional knowledge, and the general decline in education and mentorship in general since the Industrial Revolution means that most people in most departments struggle to manage their jobs and basic processes at a decent level of efficiency and effectiveness.

There’s no real understanding of how to do change management — how to plan it, execute it, measure it, correct it, and ensure success. Even though it’s fundamental for successful projects (and yet organizations wonder why so many fail to achieve their goals), it’s necessity is barely acknowledge.

14. Clients need to know skill sets and competencies required to manage services internally and externally.

And most organizational departments, and Procurement in particular, barely know the skills they need to do their jobs. (We recently overviewed 30 necessary Procurement skills that make most of the skills lists and 5 that didn’t.) When it coms to change management, they have no clue — and to make matters worse, most service and technology providers don’t know either. They think process redesign, implementation and integration skills are enough. Not even close.

15. Clients need to retain, develop, and deploy appropriate technology and management skills to manage, oversee, and coordinate with service providers.

And when you think about it, there have been hundreds of solutions for the Sourcing and Procurement of indirect products and direct materials and cookie-cutter solutions, but for decades there was no solution for sourcing strategic consultancy solutions. Since most organizations need embedded process guidance in a modern tool to do anything complex when it comes to process transformation or solution implementation, you can see why things don’t go to well. KMS and Project Management Solutions might be good for capturing the imparted knowledge (which no one will ever look at because they are not integrated into processes) and project plans but that’s not appropriate consultancy selection and management. Not even close.

Procurement Hasn’t Learned Any Lessons in the Last Two Decades! Part 2

Twenty years ago we wrote a post on William Hefley’s talk on “Identifying Issues in Sourcing: Informing Development of Best Practices” that was delivered at the 2006 Informs Annual meeting. In it, he presented 15 lessons learned from dealing with client organizations. Fifteen lessons that, apparently, the vast majority of organizations still haven’t learned 20 years later. We’re going to continue to take them one by one to make it clear how little progress Procurement has actually made in the last two decades.

6. Clients tend to abdicate entire responsibility to providers after a deal is signed.

How many times have we seen this. A new software solution is selected, and the client expects the provider to handle the entire implementation, take care of all the third-party integrations, help them locate and clean their data (with an unwilling and unprepared IT), and ensure the system gets used without any training or adoption plan. Or a new supplier is selected to create a custom component, and once the spec is sent over, the organization thinks they can be 100% hands off until the first shipment arrives. We all know how well that works without regular oversight, expedited shipments of initial units for quality testing, etc.

7. Clients negotiate better deals when internal stakeholders are involved.

But yet, when they hire an external consultant or negotiator to handle the sourcing/negotiation, they go completely hands off. Even the senior buyer doesn’t bother to review any proposals until the consultant narrows it down to the final three, and only then to make sure the core requirements are met. They don’t bother to involve stakeholders to determine if some requirements could be relaxed in certain conditions, if alternate products could be considered, if the value of included services might offset the cost per unit, or so on. Nor do they ensure that the right incumbent, known, and/or new suppliers are invited to the bid. They leave it all up to the consultant who tends to focus on providers he has negotiated the best deals with, which may not be the best providers for them!

8. Both clients and service providers are challenged in SLA (Service Level Agreement) interpretation.

This one is as true today as it was then. We don’t think that things have improved in any Procurement organization. First of all, most SLAs are poorly written. They are confusing, open to interpretation, and designed by lawyers to enable them to ensure their client is never at fault in just about any situation where a loss occurs. As long as the service provider makes some effort, the lawyers will get them off scott free.

And that’s the root cause of all the problems. Instead of creating something crystal clear, because lawsuits aren’t going to arise if both parties are honest in their products and service capabilities and make a genuine effort to meet them, they muddy everything up so neither party really understands.

Add that to the fact that neither side has invested time into what makes a good SLA for their service (needs) actually is; how to define proper product implementation, integration, utilization, repair, etc. service plans; or when to even consult the SLA; there’s no real understanding of what an SLA is, what it should contain, and how to use it. Considering that most contracts are poorly written as well (because no one understands the importance of Plain English), this shouldn’t be surprising.

9. Most client and service provider teams interpret scope differently.

Nothing has changed. Regardless if it’s technology, custom manufacturing, outsourced services, or anything else you can think of. The buyer thinks they can just hand over the entire implementation, production line design, service management, etc. to the supplier and be hands off from the time the contract is signed and the specs delivered, while the supplier expects it’s their responsibility to just flip the SaaS switch, produce the product to fully defined specs that include the desired production process in detail, or just provide manpower to execute buyer defined services.

In most situations, the parties are worlds apart until the first major milestone hits and nothing is accomplished on either side, the parties meet, and realize their expectations and understanding are polar opposites. Then comes a huge delay as a massive change order needs to be negotiated.

10. Client organizations often have difficulty with expectation management.

Building on the last two points, client organizations tend to expect the supplier or provider to do too much, hit the impossible deadlines they forced the provider to agree to, and deal with any “unexpected” problems that come up, even if entirely the fault of the client for not ensuring all of the information they provided was accurate, their data up to date, and the supplier offerings met all of their needs before signing the contract. Expectations are never realistic, and that’s another reason most projects don’t deliver to expectations.

Procurement Hasn’t Learned Any Lessons in the Last Two Decades! Part 1

Twenty years ago we wrote a post on William Hefley’s talk on “Identifying Issues in Sourcing: Informing Development of Best Practices” that was delivered at the 2006 Informs Annual meeting. In it, he presented 15 lessons learned from dealing with client organizations. Fifteen lessons that, apparently, the vast majority of organizations still haven’t learned 20 years later. We’re going to take them one by one to make it clear how little progress Procurement has actually made in the last two decades.

1. Clients often make decisions to source without considering:

  • fit with broader strategy
  • short term organization performance impact
  • appropriateness
  • risk of losing internal expertise

Not much has changed. Despite all the talk of strategic spend management and business spend management over the past two decades, at the end of the day, the majority of organizations reduce their sourcing activities to lowest cost option as long as the bare minimum requirements for product, risk management, compliance, etc. are met. The supplier fit with broader strategy, the short (negative) performance impact of a product/solution with a lower quality, or the risk of losing external expertise by allowing a GPO to handle tail spend or a consultant to handle strategic spend.

2. Clients tend to rely on consultants to conduct source selection without consideration of consequences.

It’s clear that clients don’t consider consequences of sourcing selection, because if they did, they’d never throw a strategic sourcing event over the wall. It’s one thing to bring a consultant in to work with you, but another to hand everything over to a consultant who does not understand your business objectives, current goals, or customer requirements. They’ll save on the unit cost, and maybe even on the total landed cost. But it means nothing if the defect rates go up, warranty costs rise, sales drop due to unsatisfied customers, or reliability drops.

3. Some client organizations establish special sourcing projects named to convey popular images to investors.

This still happens today. There’s always a special sourcing event for the hot technology (SaaS, Cloud, Predictive Analytics, AI, etc.), the new consulting fad (outsourcing, GPO, strategic realignment, rightsizing, etc.), the new organizational policy (DEI training, in-house third party workforce, process realignment, etc.). Usually to please the C-Suite, mandated by the C-Suite to please the board, or mandated by the board to please the investors … not to actually drive organizational value.

4. “Distress outsourcing” leads to more distress.

This is still happening every day. Except now, it’s even worse with companies outsourcing key processes to services-as-software firms employing agentic solutions based on hallucinatory Gen-AI to drive key processes with little to no guardrails or oversight! Between handing off tail-spend to third party GPOs, strategic categories to consultants, processes to services-as-software firms, organizational knowledge and alignment is disappearing faster than ever before and distress is multiplying by the project!

5. Most clients do not baseline existing operations or benchmark desired states.

This is especially true in software / technology acquisition projects! There’s no mapping of current processes, no benchmarking of process times, no identification of areas ripe for automation, and no real understanding of what sort of improvements are realistic. Instead, they just jump on the proposal from the vendor who promises the largest KPIs in the shortest time and then wonder time after time when the KPIs are not only never achieved, but not even approached. That’s one of the reasons that tech project failure rates, which reached a low of around 70% around 15 years ago have climbed back up to an all time high to 88%+ (Bain, 2024) in general and 94% (MIT, McKinsey, 2025) for AI tech projects. The other reasons are that major tech acquisitions and implementations are mega-projects (which have a 99.5% failure rate) but not scoped and treated as such, and instead always scoped assuming perfect data, 100% availability 24/7, and complete specs — which is never the case.