by   |    |  Estimated reading time: 6 minutes  |  in assyst Blog   |  tagged , , , ,

What is Procurement Debt? The pain you avoid when you make a great tech purchasing decision

In software development, technical debt is the future cost of picking an easy solution now over a better one that takes more time and effort to build. It’s about getting results now, even if this carries flaws which must be ironed out later. Procurement debt is what happens when the same is applied to choosing enterprise technology. E.g. cut corners today, pay tomorrow, feel regret. But why not avoid the pain and choose the right IT management solution first time round?

Buy now pay later

Ronald Reagan, 40th President of the United States, once said: “For decades we have piled deficit upon deficit, mortgaging our future and our children’s future for the temporary convenience of the present”. Decades later, this still rings true:

  • Government borrowing is the way countries buy things now and pay for them later.
  • Credit cards are how consumers get things now and settle-up later.
  • Technical debt is the developer equivalent: in deciding to save time today, he or she is mortgaging his or her own future. Time must be spent later to fix it.
  • Procurement debt is an organization cutting corners on a technology buying decision to save time and avoid effort now—again, mortgaging its own future.

You could say that the common theme here is a desire for instant gratification. We live in a fast-paced world where expectations are high and people are impatient. However, today’s debts must be repaid sooner or later.

Technical debt

Software developers often know that the code they are cutting will do the job, but something isn’t quite right; it’s a sticking plaster, not an elegant solution. They might make a note to themselves that they need to fix it later to make it more robust or run faster. In particular, the nature of agile development teams working in quick, short bursts forces corner-cutting in order to ship working (but shaky) code on time.

Indeed, agile development teams often carry forward an increasing volume of technical debt tasks into the next sprint until there is simply no room for anything else. This is the mortgage “repayment”, and it can cripple innovation. Technical debt creates rework. Rework is waste. And waste stands in the way of productivity.

Procurement debt

Procurement debt is similar phenomenon to technical debt, but it affects enterprise technology buyers. When a buying team makes a snap decision—without the proper due diligence—simply to avoid putting in the effort now, then this can carry a heavy price tag later. Without spending time working out what they really needed, and what each vendor could really deliver, they find out that the technology they’ve bought can’t do what they need it to do. Now they must pay developers and consultants to hammer the software into a shape that fits their organization.

So what are the causes of procurement debt in enterprise business?

#1 Lack of due diligence

The number one cause of procurement debt is the rush to buy technology without proper consideration of why.

Just like a software developer writing inelegant code to deliver a feature before the end of a sprint, sometimes procurement debt happens because there is pressure to act quickly. The perception is that there simply isn’t time to be diligent: We need new ITSM technology now.

The reality is that there isn’t time to do anything other than the right due diligence. Anybody who has experienced the fallout from a poor enterprise technology procurement decision will know, in hindsight, that the impact and cost of a poorly informed decision far outweighs the impact of a delayed purchase—by an order of magnitude.

Unfortunately, the truth is that many technology buyers begin the procurement process with a particular solution in mind, and then rush through the process of justifying the decision without thinking deeply about if it really is the right thing to do.

How to avoid it

Of course, it doesn’t have to be this way. Thinking should be flipped from a rushed, buy-now-pay-later mentality, to a more considered pay-now-buy-later approach. Make sure to take time to do the due diligence. Spend time in analysis (see Is it time to change your ITSM tool?) Talk to stakeholders and end users to unearth your true requirements. Think about how to anticipate future requirements. One very effective way to do this is to frame your analysis in terms of current IT maturity and how you aim to improve it.

You can’t be agile with an enterprise technology purchase like an ITSM toolset. Large-scale software procurements require a waterfall model; they need heavy up-front analysis of requirements. The only way you can iterate an ITSM solution is if you’re building it yourself from the ground up; something which most organizations would consider madness (when a choice of mature cloud IT management technology is readily available).

#2 Choosing an extensible platform over ready-to-go functionality

The other main cause of post-procurement pain relates to the “style” of IT management product you buy. The “it can do anything” proposition of a platform can be emotionally appealing, and ultimate flexibility can be seen by some as minimizing risk. This may even be seen as a revelation: “We will never need to change our software again! It’s the ultimate in future-proofing!”

However, the reality doesn’t often match the dream. Yes—the functionality may be there, but it is in the way that these features are accessed that hides a lot of buy-now-pay-later pain. Organizations often find that the unique features that they “needed” which drove them towards an extensible platform were not such a high priority when faced with weeks or months of development work—and hefty training and consulting bills.

How to avoid it

Work out what you need your ITSM software to do—and select a solution that will do that for you—right out of the box. No coding, no scripting, no fuss, no mess. In the cold light of day, a toolset that gives you ready-built features that line up with your priority requirements (think 80:20 rule), will likely deliver more value more quickly—and without the ongoing overheads that the “platform” tools carry. Think it through, consider the true priorities and take time to weight things up before you decide. Don’t walk blindly into Procurement Debt. Don’t make an enemy of your own future.

Find out more

Want to find out more about how you can make better technology procurement decisions—and avoid procurement debt? Read our whitepaper:

Choosing IT management tools that work for you

download buyer's guide

Leave a Reply

Your email address will not be published. Required fields are marked *