You Bought Software - IT Got a Project

"Software is sold as a product. It's consumed as a project."

Every enterprise software deal has a number on the contract and a much larger number on IT's calendar. The gap between the two is where most of the disappointment in enterprise software actually lives, and it's almost always invisible at the moment the organization says yes.

In Episode 6, Robert Brindle tells four stories. An HR system selection where price beat performance and the productivity loss ate the savings inside two years. A SaaS purchase that ran a year with none of the security or identity controls procurement and IT exist to put in place. A major ERP transformation where the supplier low-balled the bid, knowing the change orders would deliver the margin. And one platform that worked, because the joint intake happened before any supplier got near the room.

For the C-suite, suppliers, IT leaders, stakeholders, and procurement professionals.

---

New episodes every Monday. 

Subscribe wherever you listen. 

Website: https://procurexcellence.com 

Email: robert@procurexcellence.com 

Topics covered: vendor proposals, procurement rejection, discovery process, risk management, mission-driven purchasing, stakeholder alignment, supplier relationships

Transcript

SPEAKER_00 0:00

A colleague of mine was telling me a story recently, another CPO at a different organization, somebody I've known for a long time. It was about a year and a half ago he said their organization signed a contract for a platform they genuinely needed. The program team had been vetting it for months. The functional fit was strong, they'd run two reference calls. Procurement had negotiated for commercial terms that the team felt good about. Legal had cleared the contract and finance had even confirmed the budget. The supplier was reputable, the product was solid, and the implementation was scheduled to go live in just ninety days. This aligned with the contract expiration of the incumbent. Six months later, however, the platform still wasn't live. And it wasn't because the supplier had failed, their team showed up. Their training was decent, their support staff was responsive. The platform itself worked exactly the way the demo had promised it would work. But to actually use it, they had to integrate it with three other systems. They had to migrate data from a legacy tool nobody had touched in four years. They had to build a single sign on through their identity provider. They had to provision over 600 user accounts across multiple business units, each with different access requirements. They also had to negotiate API access with two suppliers whose contracts had never anticipated this kind of integration. And they had to do all of that with an IT team that hadn't been part of the decision to buy the platform until the day the contract was signed. By the time they went live, ten months after the original target, their internal cost to implement the platform was nearly equal to the three year contract value they had signed. None of that internal cost had been in the procurement savings report. None of it had been in the original business case. But it was real money, it was real time, and it had real people behind it. And it had been entirely invisible at the moment the organization said yes. The supplier had been paid in full from the day the contract was countersigned. When my colleague finished telling me the story, I told them what I'm about to tell you. This isn't unusual. Every organization I've worked with I've advised or talked to has lived some version of this story. Yes, the names change, the platforms change, and even the scale of the dollars change. But the structural pattern doesn't. This is episode six of the other side of the table. I'm Robert Brindle. And today we're talking about the most expensive collision in any organization. The collision between what gets bought and what actually has to be built. The gap between the software and the project that the software requires to exist, and why the people who sell, sponsor, approve, and sign these deals almost never see the bill until IT writes it. Here's the cleanest way I can put it. Software is sold as a product, but it's consumed as a project. Those two things have different cost structures. They have different timelines, they have different stakeholders, and they have different definitions of what done means. When a supplier sells you a platform, they're selling a product. The product has a license fee, a subscription model, a feature set, a roadmap, and a price. Everything about the way the product is positioned, demoed, and contracted is built around the idea that you're buying a thing. But you're not just buying a thing. You're buying a thing plus everything required to make that thing function inside your organization. And almost none of that everything is on the supplier's price list. Integration is a project, data migration is a project, identity and access management is a project, security review is a project, and change management is also a project. End user training is a project. And finally, operational ownership is a project as well. The platform you bought is the smallest piece of the work you're actually committed to. This is true for almost every category of enterprise software. It's true for CRMs, it's true for HR systems, it's even true for finance and ERP platforms. It's true for the deceptively small, we just need a dashboard tool. That turns out to require a data lake, a pipeline, an access model, and an analyst to maintain them. And here's the part that matters most. The supplier already knows this. Their professional services team has a number for it. Their implementation partners also have a number for it. The analyst reports about their category has a number for it. The number you're quoted on the original proposal almost never reflects that number. So when an organization makes a decision to buy a platform based solely on contract value, they're making the decision against the wrong denominator. The actual decision should be made against total cost of ownership, or TCO, which is mostly an IT calculation, not a procurement one. And in most organizations, by the time IT is asked to produce that calculation, the contract has already been signed. Let me give you a way to think about how big that gap actually is. Take a CRM platform with a list price of let's say $300,000 per year. The contract value then is $900,000 over three years. That's the number on the procurement summary. That's the number that goes to the executive sponsor for approval. Now, think about what it actually costs to make that platform produce any value. Implementation services from the supplier or a third party, internal IT time across integration, identity, data, security, double change management, and user training, operational ownership. The actual three year cost is rarely under two million dollars for a deployment this size, even when the contract reads only $900,000. The decision got made against the wrong number. I'd like to tell you four stories that show how this plays out. Three of them cost more than they had to. One of them is what it looks like when these collisions get caught early. The first story is about an HR information system. A few years ago, an organization I worked with was running a competitive selection for a new HRIS. The evaluation committee had HR leadership, finance, IT, and procurement. We ran the RFP, we scored the responses, and we narrowed it down to two finalists. The first finalist was the platform HR leadership genuinely preferred. Stronger functionality, better reporting, a more credible implementation track record with organizations our size. The HR team, the people who'd live in the system every day, they were aligned on it. The second finalist was about thirty percent cheaper. In the room when we sat down to make the call, the conversation kept going back to that price gap. The evaluation framework technically awaited the price. Finance, however, was anchored on the lower number, and the committee voted with the cheaper platform. We bought it, we implemented it, and within eighteen months, HR was working around it. Reports they needed weren't available. Configuration changes that should have taken hours were taking weeks. The implementation partner had cut corners on training because the implementation budget was tight, and the internal HR team was now spending hours every week patching gaps that the platform had left. The platform did what it was sold to do. It just didn't do it as well as the alternative would have. Within two years, the productivity loss had eaten the price difference at signature. Within three years, the organization was looking at a replacement. The lesson there is uncomfortable. Especially for finance and procurement, price is the cleanest data point in an evaluation. Performance is messy, subjective, and hard to measure. So when the room is unsure, the room defaults to price. That default is dangerous in any platform decision, but it's especially dangerous in HR, where the people who use the system every day are usually not the people in the room when the decision gets made. If you're an executive listening to this, the question you should ask your evaluation committees is this. Did the people who live in the system every day, did they vote with the same weight as the people who will sign the check? If the answer's no, you don't have an evaluation. Instead, you have a finance review wearing an evaluation costume. The second story is one most procurement leaders will recognize because almost every organization led some version of it. A program team and another part of the organization needed a tool. The category doesn't really matter. Project tracking, file collaboration, marketing automation, take your pig. They went to the supplier directly and they signed up. They put it on a corporate card. Within a few months, they had thirty users, a meaningful monthly subscription cost, and a workflow built around the platform. Procurement found out when the renewal value crossed the threshold that triggered approval. By then, however, the tool was integrated into how the team worked. Removing it was not really an option at that point. The first conversation wasn't a sourcing conversation, it was an after the fact compliance conversation, and it was a very uncomfortable one. But the bigger problem wasn't the procurement bypass. It was what we found out when IT actually looked at the platform. The supplier had access to data that should have been under our information security review, but it never had been. The user provisioning was manual, which meant employees had left the organization months earlier still had active accounts. There was no single sign on, there was no audit trail of any kind. The platform had been operating for the better part of a year without any of the controls our procurement and IT processes are designed to put in place. Now nobody did anything malicious. This was a small team with a credit card that had solved their immediate problem and moved on. And the controls that exist to surface exactly this kind of risk have been bypassed entirely. This is the modern version of the IT collision, and it doesn't show up at the procurement table. The supplier didn't need to negotiate around procurement because the customer never brought procurement in. The buyer was a program manager with a budget authority and a credit card. The deal closed in fifteen minutes. The implement implications, however, took us years to clean up. Every CIO listening has lit this. Every procurement leader in listening has also lit this. And every supplier in listening knows exactly which sales motion produces this outcome. Because for some of them, it's a deliberate strategy. The third story is the most expensive one I'll tell you today, and it's one I think every C suite leader needs to hear. An organization I'm familiar with ran a major ERP transformation, significant in scope and very invasive to the organization. It was years long, multiple business units impacted. They went through a competitive selection, evaluated three credible suppliers, and chose the lowest cost bid by a wide margin. The signed price was lower than the next bid by a number that probably should have raised flags. It didn't, however. The leadership team was under pressure to keep the program affordable. The supplier had provided a confident and detailed proposal. IT had been brought in for the technical review, but only the technical review. The contract structure, the change order language, the assumptions that priced the implementation, those had been negotiated by procurement and the executive sponsor without IT in the room. Within six months, the change order started. Every one was defensible on its face, a scope clarification, a configuration nobody had specified in the original requirements, an integration that had been described in the discovery phase but not priced into the statement of work. None of them individually were egregious. All of them, however, transformed the economics of the deal. By the time the implementation was halfway through, the cumulative change order value had eclipsed the original contract. By the end, the project came in at roughly twice the signed price, and the executive team in the postmortem asked the question that always gets asked, how did we let this happen? Here's the answer. The supplier knew exactly what they were doing. They'd bid the work at a price that wouldn't have been profitable at face value, because they knew on a project of that complexity, change orders were inevitable. They'd built their margin into the change order structure, not the original price. They'd read the procurement playbook better than the procurement team had, and they'd done it with the cooperation, however unintentional, of an evaluation process that prized lower initial cost over the actual total cost of delivery. When the supplier bids significantly under everyone else on a complex implementation, that's information. Sometimes it means they have a genuinely better cost structure. Often, though, it means that they've read the room and identified that the buyer is selecting based on price. Those two scenarios produce very different outcomes. The structure of the contract, the change order language, the assumption review, those are the things that decide which scenario you actually get. None of that gets built without IT, finance, and procurement working the deal together. I want to tell you a fourth story, and this one ends differently. A few years ago, my team brought in a digital asset management system for marketing. It was a category my organization had been struggling with for years. Asset chaos, version control problems, and license tracking. Approval cycles that took longer than the campaigns themselves. The marketing team had a clear point of view about what they needed. The difference this time wasn't the supplier, it was who walked into that first meeting. When the CMO came to me, my first move wasn't to schedule a demo. It was to schedule a 30-minute joint intake call with our IT director, our information security lead, and the marketing lead. Before we ever spoke to a supplier, we had agreed on three things. What systems the platform would need to integrate with, what data it would touch, what was the realistic implementation timeline that was coming from IT's perspective, given everything else on their plate. That conversation took a half an hour, but it saved us about four months worth of work. Because by the time we ran the supplier discovery calls, we weren't asking the suppliers to tell us what implementation looked like. We were telling the suppliers instead what the implementation had to look like, and asking them to map their offering to it. The conversation actually shifted. The suppliers who tried to wave off our integration requirements quickly dropped out of contention. The supplier who had landed the deal had a credible implementation plan in their second meeting, not their tenth. And when the contract finally closed, the implementation hit its date because we'd built a timeline backward from the IT's actual capacity, not the supplier's marketing approach. The total contract value was lower than the supplier's first quote. The total cost of ownership was dramatically lower than we'd paid for the previous platform in this category. And the implementation cost didn't show up as a surprise to anyone, because everyone who needed to know had already been in the room from the start. That's what joint intake looks like when it works. It isn't a bigger process, it's an earlier process. It's the same conversation but move to the front of the deal. So that's the picture. Let me say what it means depending on where you are sitting at the table. If you're in supplier sales, the most credible thing you can do in your next pitch is to show up with an implementation conversation already on the table, not after the contract. At the discovery call, bring the integration architect architecture sketch. Bring the realistic timeline, including identity and data. Tell the prospect what their IT team will need to commit. Yes, that lengthens your sales cycle. It also dramatically increases your win rate against suppliers who are still pretending that the platform will install itself. The customer who signs with full eyes open is the customer who renews. The customer who signs with the supplier's optimism still untested is the customer who becomes a reference call you can't use. If you're in the C-suite, total cost of ownership is mostly an IT calculation, not a procurement one. If your procurement team brings you a contract for a platform, and the only number on the page is the contract value, you're seeing only half the picture. The other half lives in IT, and you need them in the same conversation, not sequenced after. The next time a major software deal hits your desk, ask one question. And is that number reflected in the business case? If the answer is no, the deal isn't ready to approve. It isn't bureaucracy. It's the thing that prevents the all hand surprise six months from now. Here's another one worth asking. When was the last time your CIO and your CPO walked into your office together to present a major deal? Not in sequence together. If the answer is rarely or never, the workflow in your organization is sequential. And the surprises you keep getting in two year in year two of a new platform contract are downstream of that. Fixing it doesn't require a reorg. It requires you as an executive, signaling that the joint conversation gets your time, and the sequential conversation doesn't. If you're an IT or you're the CIO, get into intake. A supplier demo is the wrong place to enter the conversation. The discovery call is Build with Procurement a joint intake process where any software request gets defined, threshold triggers, and architect review before the demo, not after. If your procurement leader isn't already pushing for that, push for it together. The two of you have aligned interests here, even if the workflow has historically pulled you apart. If you're an internal stakeholder, bringing in a new platform, the software you want is a project for IT. Treat it that way from the start, not after the demo went well. Not after the budget got approved. At the start, the fastest path to a platform you actually want is to bring procurement and IT into the room early so that the sequence will work. Bringing them in bringing them in late doesn't protect your timeline. It guarantees your timeline will slip in a way that you don't control. If you're in procurement, stop running the supplier discovery alone for software deals. The intake call should have IT on it. The discovery call should have IT in it. The architecture conversation belongs before the commercial conversation. Yes, it slows the front of the funnel. It also saves you from rebuilding the deal at the back, which is the most painful work we do, and the work that produces the worst outcomes for any organization. So here's what I want you to take away from this episode. The software you bought is the smallest piece of what you committed to. The bill that lands on IT that lands on IT is the biggest piece of what you committed to. And the gap between those two numbers is where most of the disappointment in enterprise software actually lives. You can close that gap, not perfectly, not by adding more process, but by changing who's in the room from the start. The procurement and IT joint intake is the highest leverage workflow most organizations have available to them. It doesn't require new technology, it doesn't require a new headcount. It requires two functions who already have aligned interests, agreeing to run discovery together instead of in sequence. For suppliers, this changes how you sell. For executives, this changes what you ask for before you approve. And for IT and procurement, this changes when you enter. For stakeholders, this changes what you bring to the table on day one. And that's the work. That's episode six of the other side of the table. I'm Robert Brindle. Next week, we're going to talk about the politics of saying no. The part of the procurement craft nobody trains you for, and everybody eventually has to learn. I'll see you then.