We recently had a new client – a smaller commercial real estate company – agree to terms after TWO YEARS of communication.
Two years of warm exchanges, punctuated by months of silence that sometimes seemed inexplicable to us.
They’d seen the demos, checked our references, and knew that our existing clients had trusted us with similar projects. Yet they remained unusually hesitant to sign a contract.
So we went further. We put working prototypes in their hands without being asked or requiring any commitment. Rather than asking them to trust our promises, we tried to demonstrate good faith through our actions.
And still they hesitated.
Eventually, we began to understand what was different.
Existing clients had seen firsthand how we conducted ourselves, how we responded when challenges arose, and how we supported them after the contract was signed. That made subsequent project decisions easier.
A new client has none of that experience. They’ve heard promises from technology companies before. They’ve signed contracts, committed their teams, invested time and money, and sometimes been disappointed.
Those are the scars failed projects leave behind – and they inevitably influence the next decision.
Looking back, the experience changed how I think about the risk involved in implementing new technology. Here are some of those lessons…
💡 Hesitation Can Be Entirely Rational
For a long time, their hesitation was difficult for us to understand.
From our perspective, we knew our capabilities. We knew our track record. We knew how much effort we would put into making the project successful.
But they couldn’t know those things with the same certainty.
And the consequences weren’t symmetrical.
The potential benefits of a successful implementation existed somewhere in the future. The consequences of a failed one – lost time, frustrated employees, disrupted processes, wasted money and damaged credibility – would arrive much sooner.
Seen from that perspective, hesitation isn’t necessarily resistance to change.
Sometimes it’s simply rational risk management.
💡 A Contract Cannot Eliminate Implementation Risk
Contracts, statements of work, requirements and acceptance criteria all matter.
But complex software implementations rarely unfold exactly as anticipated.
Real data behaves differently than sample data. Business processes contain exceptions nobody thought to document. Requirements evolve as users see the solution working. And sometimes the most valuable discoveries happen only after implementation has begun.
A contract can establish responsibilities and expectations.
It cannot anticipate every problem.
Which means the real question eventually becomes something different:
What will these people do when something doesn’t go according to plan?
That is much harder to capture in a statement of work.
💡 The First Project Is Fundamentally Different
Existing clients already know the answer to that question.
They’ve seen how you respond when something breaks.
They know whether you answer the phone.
Whether you acknowledge mistakes.
Whether you adapt when circumstances change.
Whether you obsess over the wording of the contract – or focus on achieving the outcome everyone originally intended.
That institutional knowledge dramatically changes the perceived risk of the next project.
A new client has none of it.
References help. Case studies help. Demonstrations help.
But none of them are quite the same as lived experience.
Perhaps that’s why earning the first project with a client is so different from earning the second.
💡 Trust Requires Both Parties to Assume Risk
There’s another side to this that is easy to overlook.
The vendor is taking a risk too.
We trust that the client will engage their people, provide access to the right information, make decisions when decisions are needed, challenge us constructively, and remain committed when implementation inevitably becomes more complicated than the original demonstration.
Neither side can guarantee the other’s behaviour.
The client is betting on the vendor.
The vendor is betting on the client.
Successful implementations happen when both recognize that they are not transferring risk to the other party.
They are assuming it together.
💡 Good Faith Has to Be Demonstrated
Perhaps this was the most important lesson for us.
For much of those two years, we were trying to give the client more reasons to believe us.
Eventually, we started giving them more reasons to believe in us.
There is an important difference.
Working prototypes mattered because they required effort from us before there was a contractual obligation to provide it.
Listening carefully mattered because their concerns weren’t objections to overcome; they were information about what they needed to feel comfortable moving forward.
And taking those concerns seriously demonstrated something that another presentation or reference call couldn’t.
We were prepared to assume some risk too.
Trust became less about what we said and more about what we were willing to do.
💡 Software Implementation Is a Shared Responsibility
It’s tempting to think about software implementation as something a vendor delivers to a customer.
I’ve become increasingly convinced that this is the wrong mental model.
The vendor brings technology, methodology, experience and accountability.
The client brings institutional knowledge, people, data, decisions and organizational commitment.
Neither can produce the desired outcome independently.
And both have something meaningful at stake.
That makes implementation less like a transaction and more like a temporary partnership built around a shared outcome.
💡 Maybe We Were Asking the Wrong Question
For two years, we were essentially asking:
What else can we do to remove their reasons for saying no?
Looking back, perhaps the better question was:
What evidence do they need to become comfortable saying yes?
Those sound similar.
They aren’t.
One treats hesitation as an obstacle to overcome.
The other treats it as something worth understanding.
Change is a big deal in complex companies.
Particularly when the people making the decision are putting their budget, their team’s time, their credibility and sometimes their professional reputation behind a company they have never worked with before.
No contract can eliminate that risk completely.
At some point, both parties have to take a leap.
Perhaps trust isn’t believing that nothing will go wrong.
It’s believing that you’ve chosen the right people to work with when something inevitably does.
