Across the projects I've done so far, I can identify three things in particular that will speed you up.
First, understand which rulebook you're playing by.
Is this a program that's allowed to skip or modify the existing process, governance, and cadence for innovation and change? Or does it have to fall into your standard innovation and change pipeline?
I put this first because sometimes the goal of an FDE build is something so big, hairy, audacious, and valuable that it's worth revisiting what speed, governance, and checks and balances actually make sense to get it into production.
For example, if you build something that can triple or quadruple a sales team's success, does it really make sense to put it through a six-month governance process?
Either model can be valid. The important thing is to say out loud, at the beginning, which rulebook you're playing by so everyone understands what's allowed and what the rules of the road are.
Second, get extremely clear on your definition of success and your definition of done.
A tremendous number of AI projects across the industry are failing because they're doing technology for technology's sake instead of using technology to achieve a business outcome.
It's still completely normal to combine traditional automation, traditional AI/ML, generative AI, and LLMs to achieve the outcome you want. The projects I see generating lots of “wow” moments but never reaching production are usually innovation for innovation's sake rather than being tied to something like: “Here's how we make more money with less effort.”
Third, recognize that every AI transformation project is actually a many-team project.
Engineers, architects, and business stakeholders are only part of it. You're still going to have to scale the change to hundreds, thousands, hundreds of thousands, or potentially millions of people. Even if it's only a few hundred people, you're changing how they do their jobs.
That creates a huge organizational change management, skills refactoring, and capability refactoring problem.
If you wait until the end of the project to start that work, you've essentially created a three-to-six-week stopping point—or longer—while all of that catches up.
Instead, shift left.
Bring the OCM team, end users, training teams, people creating videos and documentation, and other adoption stakeholders into the sprints and configuration reviews. Then those workstreams run in parallel instead of serially.
That alone can save a tremendous amount of time.
