Category Archives: Project Assurance

Why Your ProcureTech Initiative Will Fail … Part 1

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).

1. You Don’t Understand Your True Needs

You’ve never done a full end-to-end process analysis on your organization, you don’t understand how inefficient your processes are, what processes you actually need, why you need them, and how much better you could be doing. You just know that the KPI metrics you are tracking are not on par with industry averages based on what your overpriced consultants are telling you, that your balance sheet isn’t as good as best in class, and that you need to do something … and that something is get a shiny new tech toy that the overpriced consultants will help you select by telling you who to invite to your RFP. (And you should know all the problems with this — they’ll only recommend the partners they have sycophant partnerships with, get referral and implementation fees from, and who will ensure that they remain your overpriced consultancy of choice.)

2. You Don’t Understand What You Already Have

Once you understand what the correct processes are, why, and where the automation points are, you need to revisit the systems you have to see where they can solve the problems. Chances are you have a number of suites, supply chain platforms, and ERPs with easy to implement plug-in modules that solve a lot of the problems you have without buying any new systems. And even if new systems might do it better, chances are the improvement won’t be worth the extra money, downtime, and change management — which will all cost you dearly. The reality is that if you can get an 80% solution today, with tools your people are already using, that’s much better than a potential 95% years in the future.

3. You Don’t Understand What Your Capabilities Actually Are

By this we don’t mean your process capabilities or technological capabilities, we mean your actual functional capabilities. Your domain knowledge, your ability to execute on that domain knowledge, and your natural efficiency. It’s pointless improving processes to apply more advanced techniques or employing modern technology to speed up processes when you’re not capable of managing those advanced processes or technology. If you employ processes and systems you’re not ready for, they won’t deliver any results while costing you millions of dollars in the system selection and implementation processes.

4. You Don’t Understand How Long It Will Take to Upgrade Your Capabilities

Even if you figure out you need to upgrade your skills and those of your team’s, even if you posses a fair degree of human intelligence, you don’t know how long it will take. It’s not just buying a knowledge dump from a consultancy or giving your team a 5-day crash course, because knowledge that is not applied is not retained. There’s a reason College and University courses give assignments and projects as well as exams — the more you apply, the more you retain. If the imparted knowledge is not applied, it will not be retained. Until your team can start applying, repetitively, the new knowledge in improved processes, they won’t retain it and they won’t advance. The best training will be a day or two a month over months, not a week. And that’s for stage 1. It will take years to get your team from average to mastery. We’ve known for decades that major transformation projects take 5 to 10 years, and that the average journey to best in class for the committed is 8 years. Technology doesn’t change that. The longer you choose to ignore this fact, the longer you will fail.

To be continued in Part 2.

Two and a Half Decades of Project Failure

  • 2024 Bain: 88% of business transformations fail to achieve their original ambitions (Source)
  • 2023 HBR: Some estimates place the failure rate as high as 80%.
  • 2023 Gartner: states that 85% of AI projects fail. As well, 87% of R&D projects never get to the production phase.
  • 2023 EY: 2/3 of senior leaders have experienced at least one underperforming [digital] transformations in the last 5 years (Source)
  • 2020 Standish Group: 66% of technology projects end in partial or total failure (based on the analysis of 50,000 projects globally). 31% of US IT projects were canceled outright and the performance of 53% ‘was so worrying that they were challenged.’ (Source)
  • 2020 McKinsey: 17% of large IT projects go so badly that they threaten the very existence of the company (Source)
  • 2020 BCG: 70% of digital transformation efforts fall short of meeting targets (Source)
  • 2020 KPMG: 70% of organizations have suffered at least one project failure in the prior 12 months (Source)
  • 2019 Everest Research Group: 78% of enterprises fail in their digital transformation initiatives (Source)
  • 2018 PWC: 75% of digital transformations fail to generate returns that exceed the original investment (Source)
  • 2018 Standish Group: only 29% of IT project implementations are successful, and 19 percent are considered utter failures (Source)
  • 2017 Gartner: 75% of all ERP projects fail (Source)
  • 2016 Innotas: 55 percent had a project fail in the last 12 months (Source)
  • 2015 Genpact: more than 66% of digital transformations fail to meet expectations (Source)
  • 2013 Innotas: 50 percent had a project fail in the last 12 months (Source)
  • 2012 McKinsey: large IT projects run 45 percent over budget and 7 percent over time, while delivering 56 percent less value than predicted (Source)
  • 2011 HBR: average project cost overrun is 27%, 1/6 projects is a black swan with a cost overrun of 200% or more Source
  • 2011 Forrester: 70% failure rate of change management initiatives (Source)
  • 2010 Deloitte: only 37% of projects delivered the functionality on time and budget meaning that 63% of projects failed to some degree (if not entirely) (Source)
  • 2009 Standish Group: failure in 68% of projects is probable (because success in 68% of projects is “improbable”) Source
  • 2001 Standish Group: 52.7% of projects will cost 189% of their original estimates and 31.1% of projects will be canceled before they ever get completed (Source)
  • 2001 Robbins-Gioia Survey: 51% viewed their ERP implementations as unsuccessful while 46% did not feel the organization understood how to use the system (Source)
  • 2001 Conference Board Survey: 40% of the projects failed to achieve their business results within one year of going live those that did achieve benefits had to wait (at least) six months longer than expected (Source)
  • 1999 Gartner: 75% of e-business projects will fail to meet the business objectives through 2002 (Source)

Is it just me, or is it the case that:

  • many of the firms who have been chronicling project failures for over two decades are also
  • many of the firms that have been guiding IT projects for over two decades?

Stop Wasting Your Time With Contract Management

The Mandarin (Yes, The Mandarin) recently posted a great article on why you should stop wasting your time with contract management

As the author clearly states, every department, state and federal, in which I have worked has a set of policies and directives on contracting and contract management. Almost every contract has a contract management plan. Yet we continue to get it badly wrong.

He quotes a recent review of Home Affairs which got a shellacking about their utter inability to reasonably prepare for the end of a contract (as well as other Procurement issues). It’s as he says, when it comes to preparation for contract termination, which should be part of a well formed contract management plan, it’s almost always “too little, too late”.

Contract Management isn’t working, and more importantly, neither are contract management platforms. (Making a colleague of mine who poo-poo’d them almost two decades ago as not worth your time, because they didn’t do any more than what a high schooler could do with some scripting and an access database, a visionary genius.)

So why do we get it so wrong? The author starts off by saying we think about contracts the wrong way, which we do (and there’ll be more on that later), especially since many approach it as a matter of performance and punishment since the contractor or vendor just needs to do what they promised and whatever performance or punishment framework included in the contract will encourage the contractor or vendor to deliver on time.

And, at the end of the day, most organizations just see it as a reporting and control framework, driven by compliance. When, as the author points out, it is supposed to be about outcomes, and, even more importantly, as the author points out, it should be a tool for managing the value chain.

The author then recommends that you fix things by:

  • owning the business outcomes
  • understanding and measuring mutual obligations
  • measuring, reporting, and managing the entire business, not just the odd contract
  • making what’s required visible and clear
  • not treating relationship management and contracting as mutually exclusive
  • using performance measures you understand

Which is all good advice, but not going to fix the fundamental problems. The fundamental problem is that it’s not contract management, it’s project fulfillment (even if you are just buying stuff).

This means that before you can do a contract you have to:

  • first develop a detailed project plan including requirements, desired outcomes, and timelines
  • identify what sub-plan you want to farm out to one (or more) vendor(s, but that requires a lot more planning and possibly subcontracting)
  • create the contract schedule with this plan as well as milestones, reporting requirements, and mutual obligations
  • decide what performance incentives or penalties you want to include to speed up performance and/or prevent late deliveries/completion
  • decide what matters (most) to you and what you are going to require around vendor geography, personnel, sustainability, etc. requirements
  • evaluate the risk and define appropriate mitigation (out) clauses
  • hand it off to legal to complete the Ts & Cs
  • then do a Procurement event
  • then complete it in negotiation, pushing the plan into your project management system once counter-signed

It’s project and relationship management at the end of the day, the rest is just document management, making CMS something that you can do with a high school student and an Access database, since its not where the contract is or how its indexed, but how it’s accessed and used on a daily basis, which should be through the project management system.

And that’s why Project Assurance is so critically important.

Don’t know what that is? Read my original and current series on Project Assurance:

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

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.

Then, in Part 2, we told you that even before we dove into the project steps for which both assurance, and guidance (because assurance isn’t enough if the project [plan] isn’t right), is needed, we were going to give you one critical action that you needed to undertake to ensure everything starts off, and stays right. And that particular action is to:

  • engage an independent expert to guide you through the entire process and help where needed

because the complexity of Procurement and Procurement Technology has reached a point where it just overwhelms the average Procurement professional. It’s been more than two decades since global conditions impacting Procurement have been so complex and technology has reached the point where even experts are struggling to make sense of the market madness, meaningless buzzwords, and the overwhelming onslaught of Hogwash.

We also pointed out that this expert must be truly independent and cannot be:

  • a resource of the company,
  • a resource of the vendor, or
  • a resource of the implementation provider.

This resource is critical in each of the phases we described in our original Project Assurance series (Part I, Part II, Part III, Part IV, and Part V). Here’s a high level description of why.

  • Strategy: the first step is a “health assessment” that pinpoints where the organization is in Procurement Maturity, and what it should be looking for to get to the next level (otherwise, what’s the point?), and this is where an expert can do a maturity and gap analysis
  • Acquisition: the expert can help craft the right RFP for the organization, identify which vendors have the appropriate technology (to ensure every response received would at least address some of the key pain points, and that the responses would be comparable), and help with the evaluation and review (acting as sale-speak to plain English translators)
  • Planning: once one or more solution (and implementation) vendors are selected, the expert is key in the creation of a realistic, and logical, project plan that ensures the organization doesn’t agree to a “big-bang” implementation proposal (which always results in a “big-bang” and has led to major supply chain failures), that the resource requirements won’t be too strenuous on the organization, and that the most critical capabilities are implemented first
  • Design/Plan Review: the plan is compared to the strategy, RFP, and overall business goals to make sure everything is aligned before the project progresses
  • Development/Implementation: the expert ensures each phase starts, completes, and is properly tested and verified on time; uncovers the reasons for delays and the root causes to prevent future problems; and when changes are required, helps to define and supervise change management (plans)
  • Testing & Training: the expert will not only ensure that the proper tests are designed, but that they are properly implemented and repeated until complete success is the result

In other words, the right expert is your guide to ensuring each step is designed right as well as conducted right, who can also take over any tasks you don’t have the expertise to do so in house. And, most importantly, the right expert is your key to Procurement Project Prosperity!