The Real Reason Your Team Hates New Software
Years ago, I walked into what should have been an exciting kickoff meeting for a major technology overhaul. We had the executive sponsor in the room, the vendor waiting patiently and that early-project sense of optimism that always feels like a fresh start.
But five minutes in, the mood shifted.
The VP of Operations thought the project was about making reporting easier. The PMs were convinced it was about better forecasting. Accounting and IT assumed it was an integration effort. And our executive champion (who signed off on the whole thing) thought we were implementing better mobility solutions.
Five key stakeholder groups, five interpretations and not a single shared definition of success.
We spent the better part of an hour debating a single workflow, not because the workflow was complicated, but because nobody could explain the real problem we were trying to solve. It felt like trying to select finishes before agreeing on what the building was for. It was then we realized something construction has understood forever, but ConTech still hasn’t fully embraced: projects don’t fail during execution; they fail at definition.
Put another way, digital transformations don’t fall apart because of software, they fall apart because no one ever aligned on the purpose in the first place.
Construction Would Never Skip a Foundation, So Why Does Tech?
In the physical world, the definition of project success is necessary. You don’t break ground (really, you don’t even mobilize) until the owner’s purpose is clear, the scope is agreed upon, the stakeholders are identified and the decision-making structure is defined. Everyone, from the architect to the GC to the end users, knows that without foundational alignment, the rest of the project is guaranteed to wobble.
But when we move into the digital world, we suddenly treat transformation like a simple software install instead of what it truly is: a behavior-changing, workflow-reshaping, culture-shifting effort that touches every corner of the organization.
Instead of pausing to achieve clarity, teams rush into vendor selection, configuration and implementation. There’s pressure to “get going,” to show progress, to demonstrate momentum. And because the technology feels abstract early on, leaders convince themselves that alignment can wait until discovery, or testing, or even training.
Spoiler alert, that doesn’t work.
Misalignment doesn’t fade as the project progresses. It compounds. The tension you ignore in week one becomes the political fight in week ten and the adoption failure in month twelve. The stakes are too high to skip the foundation.
The Wrong Voices in the Room Where It Happened
Construction excels at pulling the right voices in early. Whether it be the final occupants, maintenance teams or community representatives, we’re trained to understand that the people impacted by the project must first influence the project.
But with technology, the stakeholder list suddenly shrinks. The people who know the workflows best (the superintendents, field engineers, business management and support staff) are often brought in only to “review” something that’s already been selected. They’re reacting to a solution instead of shaping it.
And that right there is the real reason your team hates new software.
It’s not the buttons. It’s not the screens. It’s not even the training. It’s that the system arrived fully baked without their fingerprints on it. They weren’t in the room at selection to share what isn’t working today or what actually needs to change. They weren’t in the room for the conversations about workflow, data flow or reporting. And they definitely weren’t in the room to share the real friction points in the field or the realities of how information truly moves across teams.
When people are excluded from the early definition of success, the change feels imposed rather than created. That is a recipe for maximum resistance.
The Definition of Success: A Foundation for Transformation
A collaborative definition of success, with the people who really do the work, solves that. Not as a corporate document, but as the story of the transformation. It answers the basic but critical questions:
Why are we doing this?
What problem are we solving?
Who is impacted?
What does success look like?
What are our constraints?
And most importantly, who gets to make which decisions along the way?
Believe it or not, though, a good definition doesn’t need to be perfect. In fact, the best ones never are. The definition of success captures the messy, early thinking that later evolves into clarity. It gives everyone a common language, not only outlining the initial plan but also the process for making changes when new information comes up. And it surfaces disagreements while there is still time to resolve them.
The projects change, believe me, they always do. But changes made without a guiding purpose lead to chaos. Changes made with alignment lead to progress.
That’s the part we seem to miss most. Defining success isn’t just about documentation, it’s about creating a shared understanding. When everyone agrees on the purpose, expectations and constraints, everything downstream becomes easier. Budget conversations make more sense. Workflow debates become constructive. Scope creep becomes controllable.
And executive memory loss (which happens to the best of them) can be countered with a single page that reminds everyone what was agreed to at the start.
If the Foundation Isn’t Right, Nothing Built on It Will Be Either
Unfortunately, I’ve seen that messy kickoff story from years ago play out more times than I care to admit. But, each time, the root cause was clear. It wasn’t a technology problem, or a vendor problem, or even a workflow problem.
It was an alignment problem. Alignment around what success meant for our team. The project was doomed not because of anything that happened during implementation, but because of everything that didn’t happen before implementation began.
Believe it or not, digital transformation demands the same discipline construction uses every day. If you wouldn't start pouring foundations on a building without a knowing what success looked like, don’t start configuring software before either. Slow down long enough to understand what you’re building, why it matters, who needs a seat in the room and what “success” actually means. Make the investment in aligning people early, not because it’s easy, but because it’s cheaper than the rework that follows when you skip it.
Your team doesn’t hate new software.
They hate being surprised by it.
They hate not having a voice in it.
And they hate being told to adopt something they never helped define.
Digital foundations aren’t built on code, they’re built on clarity.
And clarity begins with a definition of success.
Construction is cool, tell your friends!