Stalled network automation projects, back in production.

Signs a project has stalled, not slowed

• The platform has been installed for more than six months and fewer than three workflows run in production.
• Changes still arrive as tickets, and an engineer still types them in.
• The person who built most of it has moved on, or is about to.
• The source of truth project is in its second year and nothing has touched a device.
• Nobody can say who owns the first workflow.

How the assessment starts

It begins read-only. Platform and driver versions, installed packages and their operational state, the device list and its sync status, the repository if there is one, and the last six months of commits. Then the change records: how many changes went through the platform, how many went around it.

Then conversations with the people who build it and the people who are supposed to use it. Those two groups usually describe different projects.

admin@ncs# show packages package package-version
admin@ncs# show devices list
admin@ncs# devices check-sync | include out-of-sync | count
Count: 61 lines

What the scorecard contains

Each of the seven stall patterns gets a finding, the evidence behind it, and a severity. Evidence means output: the check-sync count, the commit log, the package that has been uninitialized since March, the ticket that shows an operator working around the workflow.

The 90-day plan names the first workflow to put in production, why that one, what it depends on, and what has to be true before it ships.

Then one workflow, in production

The first workflow is deliberately small: frequent, low-risk, and boring. An interface description. A VLAN on an access port. A pre-change check that runs before every maintenance window. Small enough to ship in weeks, used often enough that operators form a habit.

It ships with the things that keep it there: the code in git, a lab or simulator pipeline that runs a dry-run diff on every merge request, a named owner, and a runbook the team has actually used.

Common questions

Does this only apply to one platform?

No. We have done this on Cisco NSO, Cisco Crosswork, NetBrain, Forward Networks, and on in-house Python and Ansible. The stall patterns are the same everywhere. The fixes change by platform.

Is NetStacks the answer to every stalled project?

No, and we will say so. The platform a team already owns is the one we make work. NetStacks comes in when a client needs a terminal, a controller, or change control that the existing stack does not provide.

How much of the team's time does an assessment take?

Two to four hours in total from the people who build and operate the platform, spread over two weeks, plus read-only access.