Procurement Processes That Kill IT Agility
Procurement departments exist for good reasons. They negotiate better prices, ensure contract terms protect the company, manage vendor relationships, and prevent fraud. I understand why these processes exist.
But in practice, most enterprise procurement processes are designed for buying physical goods with long lead times and stable requirements. Applied to technology purchasing, they create absurd situations where we can’t buy the tools we need to do our jobs without six-month approval processes.
This is how you end up with shadow IT. Not because IT professionals are rebels who don’t respect process. Because following the process makes it impossible to operate effectively.
The Speed Mismatch
Technology moves fast. A developer needs a specialized tool to debug a production issue. A security vulnerability is announced and we need to upgrade immediately. A vendor releases a new service that solves a current problem.
In a well-functioning organization, these decisions happen in hours or days. Sign up for the service, add a credit card, evaluate whether it works, decide to keep it or cancel. Total time: maybe a week.
In most enterprises, the procurement process looks like this:
Get quotes from three vendors (three weeks, because vendors don’t respond quickly to small deals). Fill out justification paperwork explaining business need (one week, because you need input from various stakeholders). Submit for budget approval (two weeks if you’re lucky, longer if it crosses fiscal periods). Legal review of contract terms (four weeks minimum, longer if terms are non-standard). Procurement negotiates pricing (another four weeks). Finance processes the purchase order. Vendor provisions the account.
Total time: three to four months. By which point the production issue has long since been worked around, the security vulnerability has been mitigated differently, or the business problem has been solved another way. The procurement process added no value and burned time from multiple departments.
The Three-Vendor Requirement
Many procurement policies require three competing bids for purchases above a threshold. This makes sense for commodities. If you’re buying office supplies, getting competitive quotes ensures you’re not overpaying.
For technology, it’s often nonsense. If we need to integrate with Salesforce, there’s one Salesforce. Getting “competing quotes” means finding two alternative CRM platforms and doing full evaluations, even though we already know we need the Salesforce integration because that’s where our data is.
The intent is to ensure competitive pricing. The reality is that it forces fake evaluations of products we’re never going to buy, just to satisfy the procurement requirement. Everyone involved knows it’s theater, but we do it anyway because policy says so.
When I pushed back on this last year for a specialized monitoring tool that had no real competitors in its category, procurement suggested we compare it to a general-purpose monitoring platform and an open-source solution. Neither actually solved our problem, but they would satisfy the three-vendor requirement. That’s bureaucracy, not good decision-making.
Budget Approval Hierarchies
Spending authority thresholds make sense. Individual contributors shouldn’t be able to commit the company to six-figure purchases. But the thresholds are often set too low for technology.
At my current organization, anything over $10K requires VP approval. Over $50K requires executive committee review. This means that a mid-tier SaaS product that costs $30K annually requires a meeting with the VP to justify, even though it’s a rounding error in the IT budget.
The result is that IT leadership spends enormous time preparing justification documents for relatively minor purchases. And decisions take weeks because getting on the VP’s calendar isn’t immediate.
A better model would recognize that IT operates differently from other departments. Technology purchases are often recurring subscriptions, not one-time capital expenditures. The cost structure is different. Approval thresholds should reflect that.
Contract Review Bottlenecks
Legal review is necessary for large vendor contracts. I don’t want to sign agreements that expose the company to unreasonable liability or lock us into bad terms. But legal review has become a bottleneck for even trivial SaaS agreements.
Most SaaS vendors have standard terms. They’re not going to negotiate for a $20K annual contract. You can take it or leave it. But our legal team still reviews every agreement, proposes redlines, and then acts surprised when the vendor says no.
This serves no purpose. The legal team isn’t going to prevent us from using the service if the vendor won’t change terms. We’ll just sign the standard agreement after wasting a month. Better to have a fast-track process for standard SaaS agreements under some threshold and reserve legal’s time for contracts that are actually negotiable.
The Risk-Averse Default
Procurement processes are designed to minimize risk. But they only optimize for one type of risk: the risk of bad purchasing decisions. They ignore the risk of opportunity cost, the risk of being unable to respond to problems quickly, and the risk of competitive disadvantage from slow technology adoption.
When a procurement process delays adoption of business AI solutions by six months, that’s not risk reduction. That’s creating a different risk by making the organization less competitive.
The right balance depends on the amount and type of purchase. A $500 developer tool should have minimal process. A $500K enterprise platform should have significant oversight. Most procurement processes treat everything the same way.
Shadow IT as Rational Response
I’ve seen developers expense $2K of SaaS subscriptions on personal credit cards and submit reimbursement requests. This bypasses procurement entirely because expense reimbursement has a different process. It’s technically against policy, but managers approve it because otherwise the work doesn’t get done.
I’ve seen teams use free tiers of services without telling anyone, then get surprised when they hit usage limits or need to upgrade. This creates security and compliance risks because IT doesn’t know what’s being used.
I’ve seen business units “rent” consultants who bring their own tool licenses, specifically to avoid the procurement process for those tools. This is expensive and inefficient, but faster than trying to buy software properly.
All of this is rational behavior by people trying to do their jobs. The procurement process isn’t serving the organization, so people work around it. The solution isn’t to crack down on workarounds. It’s to fix the process.
What Better Looks Like
Fast-track approval for purchases below some threshold. At our organization, anything under $5K can be approved by a team lead with notification to finance. No procurement involvement. This handles probably 70% of technology purchases and eliminates weeks of overhead.
Standard terms acceptance for commodity SaaS. If we’re buying a recognized vendor’s standard plan at list pricing, legal doesn’t need to review. IT leadership can sign directly. Save legal’s time for contracts that actually require negotiation.
Annual budget allocation for technology teams. Give each team a budget for tools and let them manage it. If the data engineering team has $50K for tools annually, they can buy what they need within that budget. No per-purchase approval required. This creates spending accountability while enabling autonomy.
Faster vendor onboarding for approved categories. Maintain a list of pre-approved vendors for common categories (cloud hosting, SaaS productivity tools, monitoring platforms). Purchasing from approved vendors can skip some procurement steps because due diligence has already been done.
The Cultural Shift Required
None of these process changes work without cultural change. Procurement needs to see their job as enabling the business, not protecting the business from itself. Finance needs to trust that IT leadership can make reasonable spending decisions. Legal needs to accept that not every contract can be redlined.
And IT needs to operate responsibly. If you’re asking for streamlined purchasing authority, you need to demonstrate good judgment. Track spending, don’t exceed budgets, cancel services that aren’t being used, and document decisions.
The current situation isn’t working. Procurement processes designed for a different era are actively harming technology organizations’ ability to function. The cost isn’t just time. It’s competitive disadvantage, frustrated employees, and shadow IT that creates security risks.
Fixing this requires both process change and cultural change. Procurement, finance, legal, and IT need to work together to create purchasing processes that balance control with agility. That means different processes for different types of purchases, appropriate thresholds, and trust that technical leaders can make good decisions.
Until that happens, we’ll keep having situations where the official process takes six months and the unofficial process takes six days. And everyone will keep pretending that’s normal.