Don't Build a Tool for a Moving Process

A business asks for a custom workflow for work that happens occasionally, but each case still needs different decisions before anyone can define the right steps. The request sounds like a software problem, even though the process itself hasn't settled.

The requested tool may be hiding an unsettled process

When someone asks for a custom tool, I don't start by turning the request into screens and fields. I first look at the decisions the work requires.

A business may want every case to move through the same workflow. But if each case needs a different judgment before the next step is clear, the requested workflow is only a guess at how the work should run.

That matters because a tool needs rules. It needs to know which step comes next, what information is required, and when the work is ready to move forward. If those rules change from case to case, the tool can give the appearance of order without making the decision any easier.

The business may still need a better method. It may need the work captured in one place, with fewer missed steps and less searching. That doesn't mean it needs a custom tool yet.

I separate repeated steps from changing decisions

I look for the part of the work that actually repeats.

Some steps may already be stable. A person may need to collect the same information, record the outcome, or check that the work is complete. Those steps can often fit into a short manual method.

The decisions between those steps may be different. One case may need a different review from another. A request may change direction after someone sees the details. The next action may depend on information that isn't known at the start.

I separate those repeated steps from the changing decisions before I decide whether anything should be built. I don't treat every part of the request as a system requirement just because it appears in the current description of the work.

This also gives the business a way to test the process without committing to the wrong structure. The repeated work becomes easier to follow, while the unsettled decisions remain visible instead of being hidden inside a workflow.

If the same decisions keep appearing in the same order, that gives me something stable to build around. Until then, the manual method is doing useful work. It's showing which parts belong together and which parts still depend on judgment.

A tool can make the wrong rule harder to change

Building too early creates more than a development task. It creates a rule that people may have to work around when the process changes.

A custom tool can make one interpretation of the work feel official. Once that interpretation is built into screens, fields, permissions, or step changes, changing it takes more than changing a sentence in a document. The business has to revisit the workflow and the tool that carries it.

That adds maintenance to a process that may still be changing. People may start entering information in a way the tool accepts, even when that isn't how the work needs to happen. They may keep separate notes or use workarounds when a case doesn't fit the available path.

The tool then becomes another part of the problem. It still has to be used, but it no longer matches the decisions people are making. The business paid to preserve a process before it knew which parts were worth preserving.

I don't avoid tools because manual work is always better. I avoid building around rules that haven't earned their place yet.

The process stays manual until the pattern is clear

I leave a process manual when its rules change more often than the work justifies building around them.

That limit is important. A process can be inconvenient and still be too unsettled for a custom tool. The question isn't whether the work could be made more polished. The question is whether the same decisions and steps recur reliably enough to support a system.

Until that pattern is clear, I keep the method simple and repeatable. A short checklist can define the steps that should happen every time. A shared document can hold the details and leave room for the decisions that still depend on the case.

This gives the business something usable without pretending the process is finished. It also makes changes easier to see. When the checklist needs to change, the change is part of the operating method rather than a fix to a tool that has already hardened the old rule.

There may still be work worth improving around the manual process. I can remove confusion from the checklist, make the shared document easier to use, or clarify where a decision is needed. I don't need to turn those improvements into a custom workflow before the underlying pattern is clear.

I keep the current checklist and shared document

For this kind of request, I keep the current checklist and shared document in place until the work shows a stable shape.

The checklist carries the repeated steps. The shared document carries the information and the decisions that still vary. Together, they keep the process usable while the business learns which rules actually recur.

I can build around a process when the same decisions appear often enough to justify building around them. Before that, a tool would be making a choice the business hasn't made yet.

The process stays in a short checklist and shared document until the same decisions appear often enough to build around.