Over the past two decades I’ve been involved in more than $2 billion worth of technology procurement.
Early on, I thought procurement was a niche topic only a few specialists cared about. That changed when I started selling technology to large organisations and saw, close-up, how often smart teams still end up disappointed: projects that run long, cost more, and quietly fail to change anything important.
At CIM, where we work with major real estate owners and operators, I see the same patterns repeat. In most cases, the failure wasn’t inevitable. It was baked in right at the start.
The attention war buyers never asked for
On a typical morning I’ll have 20–30 unsolicited emails from technology providers in my inbox before 9am. That’s before LinkedIn messages, conference invitations and “quick intro” requests.
Our customers tell us the same story. Asset managers and operations leaders are constantly approached by vendors promising AI, analytics, digital twins and ESG tools that will “transform” performance if they can just get “30 minutes” of their time.
You might acquire one company or sign one major lease every few years. But your organisation might buy hundreds of technology products, services and add-ons every year. Naturally, vendors fight hard for your attention.
To cope, many teams fall back on process: RFIs, RFPs, long requirements documents, complex scoring matrices. These can help, but they also create a new problem: they assume you already know, up front, what’s possible in the market and what you really need.
That’s rarely true. And it’s where the first major failure mode begins.
Failure #1: treating symptoms as requirements
Most technology procurements start with some version of “requirements specification”. On paper, it’s about clarity. In practice, those documents often describe the symptoms of a problem, not the root cause:
- “We need a new reporting tool” – really, no one trusts the data.
- “We need a workflow platform” – really, teams disagree on how work should be done.
- “We need AI” – really, the board read a headline.
Research by McKinsey & Company on more than 5,000 large IT projects found that they run, on average, 45% over budget, 7% over time, and deliver 56% less value than expected. A big part of that gap is starting with a poor understanding of the real problem.
In building performance, a portfolio might tell us, “We need better dashboards,” but the real issue is unstructured data and fragmented workflows between site teams, contractors, consultants and vendors. When CIM's PEAK Platform is deployed into that environment, the early gains rarely come from prettier graphs. They come from surfacing root causes, assigning ownership and putting structure around actions.
Good problem definition is slow, uncomfortable work. You need to understand:
- Who the real users are
- What their current workflow looks like in practice
- What will need to change day to day
- Which constraints are real vs assumed
- What success must look like in measurable terms
When this is rushed, everything downstream suffers. Projects can hit budget and schedule but still fail, because they never addressed the real problem.
Failure #2: letting time quietly destroy value
The second failure is simple: it takes too long.
I’ve seen technology decisions that take 12–18 months to make and another year to roll out. By the time the system is live, the business context has shifted, competitors have changed their offerings, and the original business case is stale.
In real estate, I’ve watched multi-year “smart building” programs that produced glossy slide decks and very little operational change. At the same time, some of our more agile partners deploy PEAK or similar tools in a handful of buildings, prove value on performance improvement in months, then scale from there.
This mirrors what Deloitte and others have found in digital transformation: companies are pouring billions into change programs, yet most projects still miss their targets. The value erosion is often in the time spent circling the runway.
The hidden risk is that some vendors are effectively designed to stretch the journey out. New phases, workshops and change requests all feel like progress, but can quietly turn into a gravy train – for them, not for you.
If you’re not deliberate about time to value, you can end up with a solution that technically works but is strategically irrelevant by the time it lands.
Failure #3: buying technology instead of buying change
The third failure is the most common: You don’t buy technology. You buy change.
Most SaaS products today work roughly as promised. The failure lies in adoption. The organisation never truly commits to changing behaviour, incentives, processes and decision-making.
A classic example was the early rollout of sales CRMs. Leaders wanted measurability and predictability in the sales process. Salespeople saw more admin and micromanagement. The system technically worked. It failed because people didn’t use it.
The same pattern shows up in digital transformation more broadly. A recent KPMG Global Tech Report found that while around two-thirds of organisations report performance improvements from digital transformation, many still struggle to turn investment into consistent, measurable impact. The barrier is rarely the technology itself; it’s the change around it.
We see similar patterns in building analytics and FDD. Our most successful deployments are rarely the ones with the most complex configuration. They’re the ones where:
- Owners and operators agree who owns which issues
- Expectations on response and resolution times are clear
- Performance improvements are tracked and recognised
- The platform is embedded in regular operational rhythms
The technology enables change, but does not replace it.
If you’re not prepared to back internal champions, manage resistance and make the change “real” for people, you’re not ready to buy the technology.
Where we go next
If you’ve lived through projects that took too long, changed too little, or delivered tools no one uses, none of this will be surprising. But it is fixable.
With better framing, technology procurement can become one of your most powerful levers for performance – not just a compliance step on the way to a contract.
In the next article, I’ll share my top lessons for effective technology procurement: the practical playbook we use at CIM and that I wish I’d had 20 years ago.
Sources and further reading
- McKinsey & Company – Delivering large-scale IT projects on time, on budget, and on value
- McKinsey & Company – IT project optimization insights
- Deloitte – CFO leadership can double the success rate of digital transformation
- KPMG – Global Tech Report 2023
- JLL – Smart buildings simplified
- JLL – Real estate tech strategies advance AI, workplace and sustainability





