Category Archives: 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.

The Lost Art of Service Management

In the age of Services-as-Software, Agentic AI, and BS AI Employees, service management has officially become a lost art!

By definition, a service is an act or work performed by a person or group that benefits another. The key word is “person“. Not software. Not machines. Not fake AI. People with Human Intelligence (HI!).

Since service management is the systematic practice of creating, designing, delivering, supporting, and managing the lifecycle of services an organization provides to its customers, that means that the art of service management is using Human Intelligence (HI!) to appropriately design, create, deliver/perform, and support the outcome of the services the organization offers to its customers. Human Intelligence (HI!), NOT AI.

More importantly, it’s the art of:

  • creating services that will provide value
  • designing delivery methods that will be efficient and effective for the provider and the customer in the delivery of the value
  • delivering the services with a human touch
  • supporting the customer through the delivery when they need help fulfilling their end of the service (such as providing data, organizing meetings, making decisions, opening up systems, etc.)

And, generally, delighting the customer with the service by actually providing value. Something that can only be done by an intelligent human that understands what the customer actually values. And that’s a return on their money. It’s not just a strategy in a powerpoint deck (and certainly not one created by hallucinatory Gen-AI), a GPO that takes 10% off of insignificant tail spend, or a flip the switch system integration with no training, ongoing monitoring, or project assurance.

It’s a step-by-step strategy with implementation support at each step; a self-serve Procurement process setup and managed by the GPO in a manner that doesn’t require Procurement to need them on a day-to-day basis; and on-going onboarding training, adoption monitoring, and support process to ensure the system is used, tested, and improved by the daily users as soon as key functions come online.

Service management is becoming a lost art just as art itself is becoming lost in the age of unintelligent Gen-AI. Like art, service management requires humanity to get it right. By definition, humanity is something systems do not have!

Why Your ProcureTech Initiative Will Fail … Part 2

We’ve written many series on best practice tech identification, tech selection, and tech implementation in the hopes of inverting the odds from an 80%+ chance of failure to an 80%+ chance of success, but given that failures are literally still happening on a daily basis, it seems that most people can’t be bothered to read best practice advice so today we’re going to flip the script and tell you all the reasons you’re going to fail and then you hope you go back and read the best practice advice we’ve freely given you (in series such as Successful Vendor Selection – The Series).

5. You Don’t Understand How To Select Proper Systems

As per our previous instalment, the answer is never to select the systems recommended by your favourite Big X consultancy whose recommendations are always in the mutual back-scratching club. With all the finders fees and recommendation fees built into the relationships, you’re paying multiples of what you should be for the tech even if the tech is appropriate. Typically the tech in the big vendors isn’t the best or most modern tech, and often the tech you fall back on only if you’re such a large enterprise that smaller vendors can’t serve you.

It’s not vendor size, Big X recommendation, marketing, or hype. And it’s never (Gen-) AI unless there’s no other solution. AI accelerates what you give it. And when you give it bad process, bad data, and bad instructions, you get an even worse result than what you have now. Until you’re best in class with last generation tech, you’re not even ready to consider AI.

The answer, as we’ve said before, is to find an independent consultant or consultant from a niche consultancy with no vendor relationships and no implementation team. The consultant/consultancies only line of business must be advisory, solution advisory, and project assurance — not implementation and integration and definitely not vendor partnerships. While the consultancies with the partnerships will tout the benefits and how they get (their customers) top tier support, first response, and the newest releases; that’s hype, not results. Results come from the systems that are right for you, not the systems right for the Big X consultancy.

Unless, of course, you are skilled enough to implement the best practice selection process yourself.

6. You Don’t Understand How Long It Will Take To Implement New Systems

A technology system implementation, replacement, or upgrade is an organizational mega-project in a mid-sized or larger organization. Even though SaaS vendors can partition a new instance in minutes, that’s not implementation, integration into your systems, incorporation into your daily processes, or institutionalization into your team’s routine. That all takes time. Lots of time — and a lot more time than your vendors will tell you. They know that you’ll be drawn to the proposal with the shortest implementation time so they will lie about how long it will really take and base their proposal on the theoretical minimum if everyone worked 12 hours a day, 7 days a week, and nothing ever, ever went wrong.

But we know the truth. Everything that can go wrong, will, to some degree. No one can dedicate as much time as the project plan says. All of the integrations will take longer than estimated. The data will be 10 times worse and 10 times as incomplete as was assumed, so there will be delays to clean the data and integrate external sources to buff it up. So things will drag out well beyond the proposal. Typically multiples.

That’s because no one will admit it’s a mega-project, and that’s why the technology project failure rate keeps increasing year-over-year despite being at an all time high of 88%+ in general, and 94% if Gen-AI. The reality is that mega-project success rates are 0.5%, as chronicled by Bent Flyvbjerg & Dan Gardner in How Big Things Get Done, where a study of over 16,000 projects across 136 countries going back to 1910 revealed the success rate. This is where technology project success rates are headed until everyone wakes up to the reality that they are dealing with mega projects and all AI does is speed up the failure.

7. You Don’t Understand How To Do Change Management

It’s not just implement the software, integrate the data feeds, flip the switch, and go. That’s a surefire guarantee for system avoidance and bypass.

Change management involves understanding how the processes are changing, what training the users will need, how best to go about it, how fast the switchover can actually happen, planning for, and managing all the non-technology details and implementing proper project assurance to make sure it actually happens. That last part is key — project assurance that starts before the first step of system implementation and continues until the adoption and usage hits the required targets — which will typically be months, if not years, after initial system implementation depending on the system. A few months for a dedicated solution or small suite, to a few years for an organization wide ERP or SCP for a large multi-national organization in dozens of countries.

8. You Don’t Know How To Recognize and Correct Issues To Avoid System Bypass

Just like no implementation will go according to plan (which is why over-optimistic schedules will never happen), no design will be as perfect as believed. Something critical will always be missed and multiple significant issues will crop up over time. The ability to recognize these issues quickly and do something about them before your employees start bypassing the system — because once they start, they won’t stop — the harder it will be to get them back on the system.

Let’s say you buy a new e-Procurement system designed to curb P-Card tail spend and allow the vast majority of spend to follow procedure, be tracked against budgets, and properly managed over time. Sounds great in theory, but lets say that any purchase not in the catalog requires an RFQ with at least 3 vendors, or a 3-way price comparison between 3 online vendors with a manager’s sign-off, which adds time and hassle for purchases that used to be one and done because the amounts were under thresholds, all of the options were always within a few % of each other, and saving $2 on a $100 purchase is NOT worth 15 minutes of an employee’s time who’s fully burdened cost is $100 an hour.

If you don’t pick up on this quickly, and let them one-and-done purchases under the old P-card amount through easy-peasy punch-out, they’ll go back to P-carding everything and if you take the P-card away, they’ll go back to the personal credit card and monthly expense report. You need to quickly figure out who is bypassing, why, and how you make the system easier to use than bypass.