How to tell whether your team has time for software or automation work

Software projects and automation projects don’t usually fail because of code. They fail because the organization that commissioned them wasn’t ready to receive them. The build can be perfect; the project can still produce no value.

This is the readiness diagnostic we run before scoping a project for an operator. If a client doesn’t pass it, we don’t take the project until they do — because the predictable outcome of an unready engagement is a delivered system that no one uses.

Why readiness matters more than technology

The technology question — what stack, what platform, what tool — gets most of the attention in these conversations. It deserves some, but it’s rarely the variable that determines outcome.

The variables that determine outcome are organizational:

• Is the right person empowered to make decisions, and do they have time?
• Are stakeholders available to clarify requirements as questions arise?
• Is the current state documented well enough to model accurately?
• Is the team willing to change behavior to use what gets built?
• Is the change management protected during rollout?
• Is the post-launch period planned, not assumed?

When these answers are clear, almost any reasonable technical approach produces a good result. When they’re not clear, even the best technical approach produces a system that gets shipped and ignored.

The six readiness signals

Signal one — there is a named project owner with decision authority

One person on the team, named, with explicit authority to make decisions inside an agreed scope. Not a committee. Not the CEO who’ll review at the end. Not the most senior person who happens to be too busy to engage in the middle.

The project owner needs three things: bandwidth (real, protected calendar time), authority (the power to say yes or no without checking up the chain on every decision), and credibility (the rest of the team will accept their decisions).

A project without a real owner stalls on decisions. The vendor asks “do you want X or Y,” and three weeks pass while the answer gets routed through people who weren’t supposed to be in the loop.

Signal two — stakeholder time is available, by name

For each role that needs to weigh in — sales, operations, finance, customer success, whoever — a specific person, available for one to two hours per week during scoping, and ten to fifteen hours total over the project.

The pattern that fails: stakeholders identified by role, not by name. “Someone from sales” becomes “we never quite got the sales person on the call,” which becomes “the project shipped without the sales workflow being right.”

The fix is naming people up front and getting their commitment in writing.

Signal three — current state is documented in writing

Before any new system can be designed well, the current system has to be understood. The current system is usually a mix of explicit processes (the official workflow), implicit processes (the actual workflow), and tribal knowledge (what specific people just know).

If the current state can’t be written down clearly — even messily, in a shared doc, with notes — the project will surface gaps in understanding that turn into rework and delay.

The good news: the act of writing it down often reveals the cleanest opportunities for the new system, because it forces clarity that wasn’t there before.

Signal four — the team is willing to change behavior

This is the signal that operators most consistently underestimate.

A new system requires the team to do things differently. Sometimes the difference is small (a new field to fill in). Sometimes it’s significant (an entirely new workflow). Either way, behavior change is required, and behavior change is hard.

The signal that the team is ready: leadership has talked openly about the change with the people affected, the rationale is clear, and there’s at least cautious buy-in from the people who’ll have to live with it. Without this, a beautifully built system arrives to a team that quietly keeps doing things the old way.

Signal five — change management bandwidth is protected

Adoption isn’t automatic. New software needs training, documentation, hand-holding, and follow-through. Someone on the team has to own the rollout — the communication, the training, the post-launch support — and that someone needs the bandwidth to do it.

A project that allocates ample time to building and zero time to rollout produces a system that’s technically excellent and operationally invisible.

Signal six — the post-launch period is planned

Software is never done at launch. The first thirty days reveal what the requirements gathering missed. The first ninety days reveal what the team actually needs that no one anticipated. The first year reveals where the system needs to evolve.

A readiness signal: the operator and the partner have a shared understanding that launch is the start of the work, not the end. Continuous-custody arrangements bake this in. Project-and-walk-away arrangements try to ignore it and pay the cost later.

The honest test

Run through the signals against your own situation. For each, mark “yes,” “partial,” or “not yet.”

• Two or three “not yet” answers — postpone the project until those are addressed
• One “not yet” answer — name it openly with whoever will run the project, plan around it
• All “yes” or “partial” — proceed; the partial answers will firm up during scoping

The point of the test isn’t to talk yourself out of the project. It’s to make sure that when you commit, the project actually works.

What “running it for you” changes about readiness

A continuous-custody partner can absorb some — not all — of the readiness gaps:

• The partner can supply the discipline a missing project-management capacity would otherwise need to provide
• The partner can run change management as part of rollout
• The partner can keep stakeholder reviews short and well-prepared so the time stakeholders contribute is well-spent

What a partner can’t supply: decision authority, organizational willingness to change, and protected stakeholder time. Those have to come from inside the business.

A good partner is honest about which gaps they can close and which the operator needs to close before the project starts. The operators who succeed with these projects are the ones who do the readiness work first and the technology work second.