Procurement is broken. Here’s how companies can avoid the biggest blunders.
Stagnant procurement processes often kill innovation. As more companies look to build software instead of buy it off the shelf, the first process that requires improvement is the one where the contract gets signed.
To avoid irrational fears, policy-driven blinders, and downright rule-bound stupidity during the procurement process for innovative technology, avoid these four mistakes.
You’re not. You’re going on a journey. Custom software development is not something you should purchase like paper clips. Procurement departments are wired to haggle over incremental per-piece pricing, volume numbers, and delivery dates.
Pre-packaged technology providers have “inventory” sitting on the self; they sell what’s in the box. In contrast, custom technology consultants take pains to map out investment options and craft custom software executions. When business units express the desire to go on a technological journey, procurement should help them pick a tour guide, not insist on cross-shopping hotels. Projects slow down or can implode altogether when procurement gets this wrong.
Custom software service companies exist because someone decided what’s in the box won’t work. For a custom execution, the process is the product.
Custom technology engagements are best controlled by budget and ambition, not deadline. The goal of a tailored software creation process is to create working software as soon as possible. After all, code is a liability; you want the least code possible. Features determine how much code will be written, and at the moment of contract signing, the features you think you’ll include are always dubious.
What you will want in the contract is a nod toward a delivery date for a minimum viable product, and a proposed sprint schedule. But it’s folly to assume anyone knows the final end date of your journey at the time of contract signing.
Developer cost per hour is a terrible way to look at a custom software project. Is the value of the Empire State Building a function of the price of steel and the labor hours that went into it?
Procurement departments run straight into this trap because developer cost per hour, like the price of steel, can be easily measured. If custom software development were merely a function of developer time, then hiring an array of the cheapest offshore coders would get the job done. You’re paying for business technologists who can implement or invent technology that does what you asked for — make your business faster, more efficient, more profitable, more robust.
Because out-of-the-box software contracts have been negotiated with standard deductions, buyers often assume custom software is also highly negotiable. But the logic of volume pricing doesn’t apply to creation-from-scratch. Always fighting for a discount off sticker price is not only obnoxious, it’s myopic. (And, in some cases, downright stupid.)
Procurement helps its business units succeed by doing a complete cost-benefit analysis. Often, the best way to measure the value of custom software development is to stack it against the cost of doing nothing.
Simply, you can’t get a unique act of creation wholesale.
Best custom software procurement practices
So how can procurement pros know they’re getting the right price, and not getting taking to the cleaners, on custom software procurement? Here are some guidelines:
Businesses often try custom software when they see a chance — often fleeting — to grab new revenue. But the lack of neat edges on the forefront of innovation can cause some real problems for policy-driven departments like procurement.
In short, procurement leaders need to be as innovative as their fast-moving business units require.