Category Archives: Project Assurance

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.

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: