The number one reason you will lose a contract has nothing to do
with AI.
For twenty-four years I ran a technology company and implemented systems for
government agencies, education, healthcare, and insurers.
Multi-year programs, multi-million dollar budgets, environments where being wrong
shows up in a patient’s care or a business’s ability to operate. I trained
hundreds of people in systems, applications, and tools.
For ten of those years I was also a board-certified psychotherapist, which is a
strange thing for a technologist to carry, and the reason I know that the hardest part of
a discovery session is not the questions.
It is hearing what the client is not saying.
At one point senior leadership brought me in to rescue a project that was failing.
Not to advise on it. To take it and turn it around.
Here is what that taught me, and it has almost nothing to do with software.
Projects do
not fail at the tool. They fail at implementation, testing, quality control, and
handoff.
The build works in a demo. Everyone nods. Then the truth surfaces:
- How to run it was never written down.
- The people who were supposed to use it every day were never trained.
- The product owner cannot say whether it passed, because nobody ever agreed what passing meant.
The manager who inherits it is the one who discovers the gut
punch: it never worked outside that demo.
I watched projects fall apart under consultants who were highly skilled but could not
deliver. And I watched consultants with less technical depth win those same
engagements.
Not because they knew more, but because they showed a plan, a test everyone could
believe in, and a calm, prepared answer for the moment something goes wrong.
That is what clients
remember. That is what decides who gets the next engagement.
That difference is not talent. It is a method. It changes how you show up, how you
execute, and how you lead.
In twelve weeks you can master it, and it will reshape how you deliver and how you run
AI consulting engagements for your clients.
I teach every session myself, because I have spent thirty
years running technology projects and consulting engagements, and I know what it takes to
deliver work that succeeds.