8 Tips
for Implementing a Smart and Sustainable AI Plan
Before you embark on an uncertain AI journey, you need a
set of clear objectives, a roadmap, and a cap on costs.
EXPERT OPINION BY HOWARD TULLMAN, GENERAL
MANAGING PARTNER, G2T3V AND CHICAGO HIGH TECH INVESTORS www.howardtullman.com
Oct 21, 2025
I recently wrote about the depressing rates of failure
of corporate
AI projects of all shapes and sizes and suggested that—for millions of
smaller businesses—building a dedicated small language model (SML) made the
most sense, as virtually none of these companies have the tech resources to
support major AI undertakings.
Responses to that column have been plentiful, and many pointed to another
problem with these kinds of projects: how are senior managers and business
owners who have no expertise in this constantly changing field going to know
when to say “No” and shut down an expensive, overly long, or wayward effort?
This is made even more complicated because so many of these
efforts and initiatives are being farmed out to third parties and consulting
firms whose own experience and expertise may range from extensive to
non-existent. It seems that anyone these days can hang out an AI shingle
and—while they may talk a good game—no one can guarantee that they know what
they’re doing, since the business hasn’t been around long enough for sole
practitioners or firms to establish any kind of credible and replicable track record.
Great entrepreneurs have tremendous intuition and an uncanny
ability to sniff out even the most gifted storytellers and detect when the
stories they’re being told don’t exactly smell right. It’s utterly unsettling
for any manager when the “progress” on the project and the movement seems to be
heading more sideways than forward. You may not know exactly what’s going
wrong, but you know that things aren’t headed in the right direction.
Even with the angst and upset stomachs that always seem to
come with shepherding any new project to the finish line, it’s never easy to
know when to pull the plug and eat the sunk costs. As I noted in my earlier
article, this is even more painful when a project is by definition
binary—either it works, or it doesn’t—and failed AI projects by and large have
neither skid marks nor any valuable remnants to build upon. They just fail.
So before you embark on any of these costly and uncertain
journeys, you need a set of clear objectives, a roadmap to get there, an
operating strategy, and a timetable as well as a cap on costs. Every situation
is going to be different, but here are eight critical things to keep in mind as
you’re designing your own plan.
Don’t hire anyone who expects to learn on the job (and on
your dime)
These days everyone looking for new work professes to be an
expert in AI while a significant number of them are just running three steps
ahead of you and trying to figure things out on the fly themselves. This is not
someone in whose hands you want to place your business or your future. Take the
time to check things out carefully and ideally to talk to prior clients and
customers.
Make sure they know what you want
A lot of these hyped-up tech wizards think they know what
you want and need because that’s what they’d do and build if it was their
business. This is a sure sign of sorrow down the line. You aren’t funding their
dreams or their fantasies; you want them to build a specific tool or system
that serves certain purposes within your company and which may be pedestrian
and boring in their view, but that’s the job that’s on offer. Take it or leave,
but please don’t take it with quiet reservations and think that you’re going to
sell me a big bag of changes and upgrades and super new features that I don’t
need or want.
Put it on paper in words that you can understand
It’s not as easy as anyone thinks to sit down with a blank
sheet of paper and try to describe all the ins and outs and all the
alternatives that make up even a relatively simple business process. It doesn’t
have to be technical or use fancy terms and descriptions or the latest jargon,
but if you can’t simply describe it, no one’s going to be able to build it for
you. And here’s a hint: you’ll never think of everything that you need or want
to include in your first draft. Write something up. Put it aside and think
about it overnight and I guarantee that a day later you’ll have a host of
changes, inclusions and improvements to add to your description.
Flow charts (even primitive ones) help keep the effort
aligned
It may seem obvious, but it’s very easy for the developers
to lose sight of the end game and the key objectives and to disappear down
“interesting” rabbit holes, which may be fun and challenging, but which are
always costly and unlikely to advance the mission. Having simple flow charts
which remind everyone of what is supposed to be being built and where things
need to be headed is VERY helpful in herding all the cats and keeping things
moving forward in the right direction.
Don’t accept updates and explanations in gobbledygook
Having suffered through too many texts, emails and other
missives relating to this concern, I simply offer the following example and let
it speak for itself. I hope you can appreciate how very helpful this update was
to my understanding:
“This is a tiny snippet of code that took all day to
generate, but it’s crucial to our future.”
~$ curl -sS http://127.0.0.1:5057/api/ask \
-H ‘Content-Type:
application/json’ \
-d ‘{“q”: “When did
X occur?”}’ \
| jq ‘{origin, model,
offer_gpt, offer_gpt_reason, response: (.response // .payload?.response)}’
{
“origin”: “fallback+gpt”,
“model”: “gpt-4o-mini”,
“offer_gpt”: true,
“offer_gpt_reason”: “no_corpus_hits”,
“response”: “X occurred in 1973 and continued for Y years.”}
Insist on the execution of concrete steps that you can
see and measure
Tie the project’s progress and your regular updates to your
original design specification and any flow charts you may have created and
demand face-to-face conversations where you can discuss and be shown how things
are progressing and what has been accomplished in terms that you understand and
can evaluate.
Watch out for ChatGPT runaways
I’ve discovered that ChatGPT has been smart enough to
convince many of these newer AI “experts” that it can handle requests from them
to generate large swaths of code which will become part of the ultimate system
and deliverable and which purport to implement directions and questions from
them and offer them turnkey “safe” solutions so that they merely have to copy
the computer’s code into their own effort. There’s no question that this saves
time, but it leads to a really unfortunate endpoint because, as often as not,
the suggested code fix breaks some other part of the overall program.
This is an underappreciated systemic issue with ChatGPT
because it can’t really remember or track everything that went before or even
its own suggestions. The sad and scary part which I call the “ChatGPT runaway”
is that the developer is now faced with a mountain of code and an error or
break somewhere buried in that mess which he has no clue as to how to locate or
fix. His only recourse is to ask the computer what happened and how to fix the
problem and the doom spiral is likely to simply continue unless someone jumps
off the merry-go-round and calls it quits.
Have concrete milestones of performance and drop-dead end
dates
The very best protection you can have in these projects is a
plan and roadmap that includes specific and concrete milestones which you
adhere to and absolute drop-dead completion dates. This limits your exposure,
it caps the likely costs, and it largely prevents scope creep. If the project
doesn’t get completed on time, so be it. You can review the results and
determine whether the scope of the project was unrealistic, the time allotted
was insufficient, or the talent wasn’t up to the task. But, in all events, you
will hopefully avoid endless discussions about a forever receding future
delivery date, excessive costs and other wasted resources, and an ultimately
painful parting. You need to make it clear from the outset that you intend to
pay for results, not for promises.
The bottom line is simple: “almost” only counts in love and
in horseshoes. Even if you don’t know the technical reasons why a project isn’t
proceeding or what went wrong in the design or planning process, trust your gut
and stand your ground and know when to say “enough is enough.”
