Why enterprise technology projects fail when solutions are sold before problems are understood

Insight  August 31, 2026

At a glance

  • Most tech disappointments start in the sales conversation, not the software
  • "Sit back and just listen" - the real problem surfaces when you stop pitching
  • Copying a competitor's solution can create more problems than it solves
  • Honesty over reassurance: trust is built through trade-offs, not sales polish

Featuring Beau Jagger
SAP & Data Capability Manager of COSOL


A sales executive’s job is to sell a solution. The more complex the challenge, the more sophisticated the pitch becomes, and somewhere along that curve, the distance between what is sold and what is needed can quietly widen.

For Beau Jagger, SAP & Data Capability Manager at COSOL, that gap is where most technology disappointments begin. Not in the software itself, but in the way organisations engage with the people advising them.

“It’s incredibly important to sit back and just listen,” she says. “If you let the conversation flow, you can start to tease out the real problems.”

That sounds simple, but it rarely is. By the time a business reaches out to a partner, the conversation is often already framed. There is a preferred platform, a budget, and a sense of urgency. Sometimes there’s even a preferred solution, shaped by what a competitor has implemented or what has been presented in a polished demo. The role of the advisor becomes one of validation, and many sales execs are happy to oblige, because they’ve seen the solution in action as well.

Beau approaches it differently. The first task is not to confirm what the customer thinks they need, but to understand how the organisation actually works.

“How is this task being done? Who is doing it? Why is it done that way?”

Understanding the operating reality behind what customers ask for

These are not diagnostic questions in the traditional sense, but a way of surfacing the operating reality behind the request. In asset-intensive industries, that reality is often layered. Systems carry the imprint of past decisions, processes evolve in response to constraints, and (poor) data quality can reflect years of incremental compromise.

“Customers might say they need something because they’ve seen another company use it successfully,” Jagger explains. “But their system, processes, and data could be completely different.”

When that distinction is overlooked, technology becomes a container for unresolved issues. A new system absorbs old problems, reshaped but unchanged and the outcome is familiar: friction in workflows, resistance from users, and a gradual erosion of confidence in the investment.

“If you implement something based on that assumption, it can create more problems than it solves,” she says. “That’s when people say, ‘the old system was better,’ even if it wasn’t.”

What sits underneath that response is not nostalgia but a comparison between expectation and experience. The promised outcome was clarity, efficiency, and control, but the lived experience is nothing more than complexity in a different form.

Beau has spent much of her career stepping into those situations. “There have been many cases over the years where I’ve ended up taking over what I called ‘problem child’ accounts,” she says. “When you dig into those, you often find that what was sold didn’t align with what the customer actually needed.”

How misalignment takes shape when assumptions go untested

There was no malicious intent in that misalignment. More often, it’s the product of momentum. Conversations move quickly, assumptions go untested, capabilities are emphasised, and constraints receive less attention.

Beau and her team’s approach introduces a different kind of discipline; holding the solution back long enough for the problem to become fully visible.

“You can begin to tease things out,” she says. “You uncover things like custom code, outdated processes, or inefficiencies. Then you can assess whether a new solution will actually fix the issue, or whether some level of change is required first.”
That assessment sometimes leads to a different recommendation than the one the customer expects.

“I often describe SAP as the Rolls Royce of ERPs,” she says. “It’s incredibly powerful if it’s implemented properly. But the question is whether the customer actually needs that level of capability at their stage of growth.”

In some cases, the answer points to something simpler. In others, it leads to a different architecture altogether, where a “best of breed” approach delivers a more precise fit for specific asset management needs.

The common thread is alignment, not between product and aspiration, but between solution and operating reality. That alignment relies on a form of honesty that is not always associated with sales.

“I tend to take a more honest approach and explain both the potential and the reality,” Jagger says. “Customers are more receptive when you’re upfront, and it builds trust.”

Trust, in this context, is not built through reassurance., but through clarity and conversations where trade-offs are explicit, limitations are acknowledged, and decisions are made with a full view of their implications. It also depends on confidence, and not only in the individual leading the conversation.

“To do that, you need confidence across multiple levels,” she explains. “In yourself, your team, the product, the company, and even the client relationship.”

Honest conversations depend on confidence across people, product, and partnership

This breadth of confidence reflects Beau’s unique career path. She began in sales, but it didn’t stay there. Over time, proximity to delivery reshaped how she thinks about solutions, and she wasn’t content signing deals and walking away.

“I’ve been fortunate to work with very strong solution architects, technical consultants, and functional consultants,” she says. “Over time, you absorb knowledge from them. You fix problems, and eventually you find yourself repeating insights you’ve learned along the way.”

That exposure changed the centre of gravity in her work, and the focus moved from closing deals to shaping outcomes, and positioning capability to understanding what it takes to deliver it.

“I was seeing how projects were being delivered and felt that they could be approached in a better or more interesting way,” she says. “You either accept it or you do something about it.”

Moving into delivery created a different vantage point. It brought the downstream consequences of early decisions into sharper focus so that Beau could work with others to identify gaps in scope, misaligned expectations and the cumulative effect of small assumptions left unchallenged.

“From a technical perspective, if my team and I are scoping a project and leave gaps, those gaps will come up later, leading to delays, miscommunication, and stakeholders not fully understanding the end result,” she says.
What closes that gap is not tighter scoping, but shared ownership. When customers are willing to be open about how their business runs, and COSOL’s team brings multiple perspectives to the table early, the dynamic shifts from vendor and customer to something more collaborative.
“Anyone who thinks they can do everything in SAP is setting themselves up to fail,” Beau says. “You need different skill sets and perspectives, and you need to bring those together.”

That same principle extends across the table. IT, operations, end users, architects, consultants; when those voices are brought into the same conversation, not in sequence but together, the problem becomes clearer. Trade-offs are understood earlier and decisions are made with context, not assumption.

Trust is what makes that possible. The kind of trust that allows a team to say, this won’t work the way you think it will, or we need to rethink this before we move forward. Equally, the kind that allows a customer to bring the reality of their environment into the room without filtering it into something more presentable.

When that happens, projects stop feeling like something being delivered to a business, and start becoming something built with it.

About COSOL

COSOL is built on one belief: in asset-centric industries, reliability is everything. We’re a trusted, data-led asset management partner for organisations around the world who can’t afford to fail. And known for our deep expertise, dependable delivery, and ability to keep critical assets performing at their best. 

The company recently celebrated 25 years in business, are Australian-owned and operated, and  recognised as reliable partners by their clients across the globe.