Category Archives: Project Assurance

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!

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.