Breaking down the current flow freezes it

What it is

Today’s way of filing expenses is drawn as a tidy tree. Next week the tree is in the requirements pack, retitled Standard Task. A breakdown of current process writes workarounds, hacks, and historical residue as if they were necessary structure. Ossifying as-is practice is not a failure of the technique. It is a wrong use of the object: a tree that describes how it gets done now is treated as a spec for how it ought to be done. The more complete the tree, the harder it is to drop a branch that no longer has a goal.

Why it happens

Decomposition wants stable step names. Once named, a step becomes citable, handy for training and acceptance, and resistant to deletion—cutting it feels like vandalizing a reality already analyzed. Field workarounds (print then photograph, ask someone else to click) enter the tree as “subtasks” and get reimplemented in the new system. The organization also likes the tree as proof that current staffing is rational: finance must create the project code first, because that is how the tree goes. Analysis should have made removable conditions visible; after documentation it becomes a fence around those conditions.

Studying it

Build, for the same job, an as-is tree and a goal tree that holds the goal constant and leaves means unconstrained; compare nodes that exist only because of current tools. Trace how many workaround steps are built unchanged after the as-is tree enters requirements. Ask people who train from the tree whether they treat it as an unchangeable rule. Outcomes: branches kept with no remaining goal, and the rate at which a new system copies old workarounds.

Where it stops holding

Accident investigation and compliance forensics must be faithful to how it was done then; ossification is the point, not a flaw. When only incremental patching is allowed and means cannot be replaced, the as-is tree is the work object—just do not retitle it. A brand-new service has no present to freeze. The danger is the half-new project: speech says “we will redesign,” hands use the old tree as the acceptance list.

Applying it

• Name the file “description of current practice” and ban “standard procedure” from the header. A norm needs a separate tree rooted in the goal, not copied from current means.
• Tag every node: required by the goal / only because of current tools / field workaround. The last two stay out of the new scheme unless argued back in.
• In review of a new design, cover the old tree and match only against the goal layer. Unmatched old steps are deletion candidates, not omissions.
• If a requirements line can be found verbatim on the old tree, walk back whether it is a goal or a workaround. Workarounds do not go straight into a project.

Related

• Same group: Q4.07.1 Hierarchical breakdown reveals subtasks and preconditions · Q4.07.2 Analyze the task, not the interface
• Adjacent: Q4.13 Task analysis and hierarchical decomposition · Q4.04.4 As-is maps what happens; to-be maps what is wanted — keep them apart
• Search terms: as-is task decomposition ossifies practice · descriptive versus prescriptive HTA · workarounds in task models