I didn't start my career in tech.
I spent over a decade in the U.S. Army as a Cyber Electronic Warfare Warrant Officer in Special Forces. Before I was building automation systems for businesses, I was operating in environments where poor planning had real consequences — the kind you can't undo with a rollback.
When I transitioned out and started building AI systems professionally, something became immediately clear: the planning frameworks I learned in the Army worked better for AI architecture than anything I found in the tech world.
This isn't a "military metaphor" piece. This is a direct translation of operational planning methodology to building automation stacks — with specific frameworks you can apply today.
Why Most AI Projects Fail Before They Start
The most common reason AI automation projects fail isn't technical. It's that people start building before they understand the operational environment.
They see a tool, they see a use case, they start connecting things. Six weeks later they have a fragile automation built on assumptions that turned out to be wrong, with no documentation, that only one person knows how to maintain.
In Special Forces, we called this "conducting operations without orders." You're moving, you might even be moving fast — but you have no shared understanding of the mission, the environment, or the decision criteria. The first time something unexpected happens, the whole thing collapses.
The fix — in operations and in automation — is disciplined planning methodology.
METT-TC: A Framework Built for Complexity
METT-TC is the U.S. Army's primary mission analysis framework. Applied to building an AI automation system, it forces exactly the right questions before you write a single line of configuration.
Mission: What Are We Actually Building?
This sounds obvious. It is not. "We want to automate our sales process" is not a mission. That's a direction. A mission has a specific, measurable end state: "Reduce lead response time from 4 hours to under 10 minutes, and ensure every inbound lead receives a qualified follow-up within 24 hours without requiring manual intervention from the sales team."
That's a mission. Now you know what success looks like. You know what to build toward, and you know when you're done. Before I start any client engagement, I push until we have a mission statement this specific. It changes the entire project.
Enemy: What Will Degrade Your System?
In business automation, your "enemy" isn't a person. It's every force that will work against the system functioning as designed:
- Data quality problems — Garbage in, garbage out. If your CRM data is messy, your automation will automate the mess.
- Process exceptions — The edge cases your automation doesn't handle, that pile up in someone's queue until they become a crisis.
- User resistance — The team member who doesn't trust the automation and keeps doing things manually, creating double-data problems.
- Vendor instability — The API that changes without notice, the tool that gets acquired and deprecated.
- Security threats — Prompt injection, data exposure, unauthorized access to workflow credentials.
Good planners war-game the enemy before contact. Map your failure modes before you build. Design mitigations in from the start.
Terrain and Weather: Know Your Environment
In physical operations, terrain determines where you can move, where you're exposed, and where you have advantage. In automation, your "terrain" is your existing technology stack, your data architecture, and your team's technical capabilities.
A workflow that makes sense for a company on HubSpot, Google Workspace, and Slack looks completely different for a company on Salesforce, Microsoft 365, and Teams. Same mission, different terrain, different design.
"Weather" in this context is timing and dynamics — is the company in a growth phase or a cost-cutting phase? Is there a product launch coming that will change your data volumes? These factors affect what you build and when. Skipping terrain analysis leads to technically correct automation that doesn't fit the environment it's deployed into.
Troops and Support Available: Honest Resource Assessment
Special Forces operates with small teams and finite resources. We were ruthless about honest assessment: what can we actually do with what we actually have?
In AI automation, this means: What is your team's actual technical capability? Who will maintain this after it's built? What's your real budget — not aspirational budget, actual budget? Do you have clean data to work with, or is data cleanup a prerequisite?
I've seen companies try to build Phase 3 automation (AI-powered intelligence layers) with Phase 1 resources — no technical staff, dirty data, no documentation culture. It doesn't work. The mission has to match the resources. Better to build three solid, maintainable automations than ten fragile ones that require constant rescue.
Time Available: Decision Points and Sequencing
What's your timeline, and what are the critical decision points along the way? In operations, we always identified the "point of no return" — the moment when you're committed to a course of action and can no longer change plans without significant cost.
In automation projects, this is usually when you've migrated data, deprecated old processes, or trained staff on the new workflow. Knowing your timeline forces sequencing discipline. What has to happen before what else can happen? What's parallel vs. sequential? Build the timeline backwards from your end state. Work forward from today.
Civil Considerations: The Human Factors
In Special Operations, civil considerations are often the most important factor. The human environment determines whether the mission succeeds or becomes a long-term problem.
In business AI, civil considerations are: How will your team respond to this change? Who are the stakeholders who need to be informed or bought in? What existing workflows are you disrupting, and for whom? Are there compliance, legal, or regulatory factors that constrain what you can build?
The most technically excellent automation system will fail if the people using it don't trust it, weren't trained on it, or feel threatened by it. Plan for adoption. Communication and training aren't afterthoughts — they're part of the operation.
Why This Gives ZaraAI Clients an Edge
Most automation consultants start with tools. I start with planning.
By the time we get to "which tool should we use," we already know the mission, the failure modes, the environment constraints, the resource reality, the timeline, and the human factors. Tool selection becomes straightforward because the requirements are already clear.
That's not how most people build automation systems. That's why most automation projects underdeliver.
The operational planning discipline that Special Forces drills into you — and that I've applied directly to AI system design — is genuinely different. It's not marketing language. It's a different way of thinking about complex systems in complex environments.
If you want to build AI automation that holds up under operational conditions — not just demos well on day one — I'd like to talk.