Most technology projects that fail do not fail because the technology stopped working.
They fail because the people who were supposed to operate the system were never set up to do so, or because there was no structured process holding the deployment together when things got complicated. I have seen this pattern more times than I can count across nearly three decades in the field.
This article is about that pattern: what causes it, where it shows up, and what a structured approach to people, process, and technology actually looks like in a production environment.
The part of the deployment nobody budgets for
When an organization buys a new platform, the budget conversation almost always centers on the technology: licensing, hardware, implementation hours. The people side rarely gets the same attention.
Somebody has to operate what gets built. Somebody has to understand the policy logic well enough to modify it when the business changes. Somebody has to know what working looks like so they can tell when it stops.
If those people aren't identified before deployment starts, and if they aren't actively involved throughout the design and build process, the organization ends up with a system that runs fine as long as the implementation team is still on-site. The day that team leaves, the clock starts on how long before something breaks and nobody knows why.
This is not a technology problem. It is a people problem that technology cannot fix.
Process is what keeps a project from becoming a crisis
Enterprise technology deployments are complex. Dependencies surface that were not visible in the scoping conversation. A change in one layer of the environment affects something three layers away. A configuration that tested cleanly in the lab behaves differently under production traffic.
None of this is unusual. What is unusual is having a structured process that accounts for it.
Without a defined process, teams respond to complexity by improvising. Improvisation in a production environment is where scope expands, timelines slip, and the project ends with a system that is partially deployed, partially documented, and fully dependent on whoever remembers what was done and why.
Why we built S.I.M.P.L.E. around this problem
At BTA, we formalized this thinking into our delivery methodology: S.I.M.P.L.E. (Start, Immerse, Map, Prove, Launch, Evolve). Every stage has a defined deliverable, a defined handoff point between BTA and the customer team, and a defined exit criterion. Work does not move from one stage to the next until the exit criterion is met.
| Stage | What happens |
|---|---|
| S · Start | Scope, stakeholders, and exit criteria defined before work begins. |
| I · Immerse | Current-state assessment of the environment. Real numbers, not assumptions. |
| M · Map | Architecture design, sequencing, and a prioritized roadmap. |
| P · Prove | Controlled validation before production. Failure points are caught here. |
| L · Launch | Production deployment with the customer team working alongside BTA engineers. |
| E · Evolve | Formal handoff. The customer team operates the environment. BTA transfers the operating knowledge. |
The Prove stage is where the technology gets validated under real conditions before it touches production. The Evolve stage is where the handoff happens: the customer team is not just handed documentation, they have been working alongside BTA engineers throughout the engagement and are ready to own the environment when it ends.
S.I.M.P.L.E. has run on more than 1,000 projects. We have not had a project we didn't complete. That is a process outcome, not a technology outcome.
The right sequence
People, process, and technology work in that order for a reason.
Start with the people: who owns Day-2 operations, what skills they currently have, and what they need to develop during the engagement. Build that into the project plan from day one.
Then build the process: how decisions get made, how changes get validated, how the team communicates across stakeholders. Agree on exit criteria before work begins.
Then select and deploy the technology: with the people context and the process framework already in place, the technology deployment has a foundation to land on.
Reversing that order is the most common sequencing mistake we see. Organizations that start with the technology purchase and try to work backward to people and process typically end up redesigning the engagement partway through, at significant cost in time and effort.
What this looks like in practice
The clearest example is a segmentation deployment.
The technology side is well understood. Platforms like Cisco Secure Workload give organizations the enforcement mechanism they need. The harder work is the mapping: understanding what is actually communicating with what in the environment, designing policies that reflect business intent rather than just IP addresses, and validating those policies before they touch production traffic.
That work requires people who understand both the technical environment and the business requirements. It requires a process that holds the mapping and validation stages in place before anything gets enforced. When all three are aligned, the deployment produces a segmentation architecture the customer team can operate and maintain on Day-2. When they are not, it produces a partially enforced policy that nobody fully owns.
Three questions before any deployment
Before any significant technology deployment, these questions are worth having answered in writing.
Who on the customer team will own this on Day-2, and are they involved in the deployment now?
If the answer is unclear, the handoff will be unclear. Day-2 ownership needs to be named before the project starts, not assigned at the end.
What is the defined process for moving from current state to production, including how changes get validated before launch?
A deployment without a defined validation stage is a deployment that finds its failure points in production.
What are the exit criteria at each stage, and who has authority to approve them?
Exit criteria prevent scope creep and keep a project from ending before it is actually done. If nobody has defined them, the project has no agreed definition of done.
If you are working through a deployment where those answers are unclear, happy to compare notes. We have run these enough times to know where it usually goes sideways.
Talk to BTA: gobta.com/contact-us
Read how S.I.M.P.L.E. works in practice: https://www.gobta.com/how-we-work/simple