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.

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.

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.