Rolling out operational software without losing a week

Operational software is judged in its first two weeks. The build can be right, the data can be clean, and the project can still be remembered as the week dispatch fell apart. Software that people must use to do their jobs has no grace period: a technician who cannot close a job does not file a ticket, they call the office, and the office writes it on paper. That paper becomes a process, and the process outlives the launch. Rollout is the part of the project where that gets decided, and it is usually planned in the last two weeks by whoever has capacity.

Choose the rollout shape before anything else

The default advice is to pilot. It is good advice when the workflow being replaced is self-contained: one crew, one site, one region can run the new system without needing anyone outside the group to also be on it. Pilots buy you a small blast radius and a real rehearsal with live work, which is worth more than any amount of test-environment validation.

A full switch is safer than most people expect when the work crosses teams. If dispatch, the field, and billing all touch the same job record, running half the company on each system means someone reconciles the two by hand every day, and the reconciliation is where the errors come from. In that situation the pilot does not reduce risk, it adds a second failure mode on top of the first. A full switch is also the right call when the split itself would confuse customers, when the old system's licensing makes partial running expensive, or when the pilot period would push the cutover past a hard deadline like a contract renewal or a seasonal peak.

Pick the pilot group properly

The usual pilot group is whoever volunteered. That group is the most motivated, the most tolerant, and the least representative people in the business, and they will make the software look better than it is. An enthusiast who hits a broken screen finds a way around it and does not mention it, because they want the project to succeed. A sceptic hits the same screen and tells you, loudly, which is exactly what you need before three hundred people meet it.

Build the group to look like the operation rather than like the project team. That means including the people the rest of the workforce actually watches, because their verdict travels further than any announcement.

• At least one vocal sceptic, chosen because they will report problems rather than absorb them.
• One person who has been doing the job the longest and has the deepest habits from the old system.
• One recent hire, who will surface everything the documentation assumes you already know.
• Someone with poor connectivity or older hardware, if the software goes to the field.
• A supervisor who has to read the output, not just enter the input, so reporting problems appear during the pilot rather than at month end.

Plan for the productivity dip and say it out loud

Output drops after a switch. This is not a sign of a bad system; it is the cost of replacing motor memory with deliberate thought. A dispatcher who could book a job in forty seconds now takes two minutes because they are reading labels. That resolves, but it resolves over one to two weeks, not overnight, and planning for a single bad day is the most common capacity mistake in a rollout.

Plan the dip like any other capacity constraint. Reduce scheduled volume for the first week where you can, hold non-urgent work, avoid stacking the launch against month-end close or a compliance deadline, and do not book the project team's time on anything else. Then tell everyone the dip is expected and roughly how long it lasts. Announcing it costs nothing and changes how it is read: a slow Tuesday that was predicted is a plan working, and the same Tuesday unannounced is evidence the new system is broken. That interpretation, once it sets, is expensive to reverse.

Train close to the switch, and train tasks

Comprehensive training delivered a month early is a scheduling convenience, not a learning strategy. People retain almost none of it, because there is nothing to attach it to and no immediate use for it. The training that survives is narrow, delivered within a few days of the switch, and organized around the tasks people actually perform rather than around the structure of the software.

Write the curriculum from the job, not from the menus. A technician needs to start a job, add parts, capture a signature, and close it. They do not need a tour of the admin settings. Run separate sessions per role, keep each under an hour, and use real data from the business so the examples are recognizable. Every session should end with the person completing their own most frequent task unaided.

Documentation people will actually open

The forty-page manual is written for the project's benefit and read by nobody. What gets used is short, task-shaped, and reachable from inside the application at the moment the question occurs, such as a one-screen answer to "how do I add a part to a job" linked from the job screen itself. If the answer lives in a shared drive, a wiki nobody has an account for, or an email from three weeks ago, the real documentation becomes the colleague sitting nearby, and whatever that colleague guesses becomes the standard procedure.

Staff the first two weeks like an operation, not a project

The support model matters more than the training. Questions arrive in a burst in the first days, and their fate determines what the process looks like six months later. A question answered in two minutes teaches the correct workflow. The same question unanswered for a day produces an invented workaround, that workaround gets shared, and it is still in use long after the underlying issue was fixed.

So name a person, not a queue. One identifiable human who is visible, reachable on the channel people already use, and has no other assignment for two weeks. They need the authority to change configuration and a direct line to a developer for anything they cannot. Log every question, because the log is the most accurate list of what to fix and what the training missed.

1. 1

   Two days before: confirm every user can log in on the device they will actually use, and fix the accounts that fail. Login problems on Monday morning consume the whole day.

2. 2

   The day before: run the final data load, reconcile record counts and open-job totals against the old system, and set the old system to read-only at an announced time.

3. 3

   Monday morning: hold a ten-minute stand-up per shift covering what changed, where to ask for help, and the one thing not to do. Then start real work immediately.

4. 4

   Monday: the named support person sits with the busiest role rather than at a desk. Log every question verbatim, including the ones that sound trivial.

5. 5

   Monday evening: triage the log. Fix configuration and content issues overnight; schedule anything requiring code and say so publicly.

6. 6

   Tuesday and Wednesday: publish the fixes made and the questions answered, so people see that reporting a problem produced a result. This is what keeps reports coming.

7. 7

   End of week one: review the log for patterns, then run a short top-up session covering only the tasks that generated the most questions.

8. 8

   Week two: taper support toward the normal channel, but keep the named person reachable and keep publishing what changed.

9. 9

   End of week two: check the dip has closed. If throughput is still materially down, the problem is workflow design or data, not familiarity, and it needs a fix rather than more time.

What to do with the old system

Leaving the old system writable is the most common rollout mistake, and it is made out of caution. The reasoning is that a fallback reduces risk. In practice, under pressure, people use whichever system they are faster in, so within a week work is being entered in both, neither is complete, and every report requires a reconciliation. The split then justifies itself: the new system is missing records, so people trust the old one, so more work goes there.

Removing it too early is the opposite failure. If the archive has not been verified as readable, if retention obligations are unsettled, or if anyone still needs to look up historical work, switching it off turns an ordinary question into a crisis. The workable position is read-only from cutover, kept for a stated reference period of roughly ninety days, then decommissioned once lookups approach zero and the exported archive has been opened and checked by a person.

When to pause the rollout

Pausing has to be a decision someone is allowed to make, with criteria agreed before launch week. Otherwise it never happens, because by day three everyone is invested and tired and inclined to push one more day. Write the triggers down while the room is calm, name the person who can call it, and be explicit that pausing is not the same as reverting: it means stopping the expansion of the rollout, not undoing it.

• A workflow that generates revenue (dispatch, job completion, invoicing) is failing rather than merely slow, and there is no workaround inside the new system.
• Data is being written incorrectly or lost, because every additional day compounds the cleanup rather than the learning.
• Customers are being affected in ways they can see, such as missed appointments or wrong invoices.
• The question rate is rising rather than falling by day four, which indicates a design problem that training will not solve.
• The named support person is saturated and questions are going unanswered, which is the condition that manufactures permanent workarounds.
• Throughput is still materially below baseline at the end of week two with no clear trend toward recovery.

None of these should be a surprise on the day. Every one of them has a number attached that someone can check, and the value of writing them down in advance is that it converts an argument into an observation.