Mapping the Current Building-Permit Process Before Automating It

Executive summary

Process mapping is treated as a preliminary. In permitting it is the deliverable that determines whether anything else works: configuration, measurement and change management all draw on it.

This article describes how to produce a current-state map that is specific enough to configure against — one permit type at a time, with real timestamps, named decision points, and the rework loops that staff know about but documents rarely show.

Why mapping precedes tooling

Two failure patterns follow from skipping it. The first is configuring checklists against an idealised process, which produces deficiency notices that do not match how files actually arrive. The second is claiming improvement without a baseline, which makes any later result unattributable.

Federal programme material on approval efficiency and CMHC municipal action-plan summaries both assume documented process as the starting point for change [1][2].

Scope one permit type, end to end

Map a single permit type first — typically the highest-volume Part 9 residential type [3]. Mapping "the permit process" in general produces a diagram that is true of nothing in particular.

Distinguish elapsed time from touch time. Elapsed time is what the applicant experiences; touch time is what the department consumes. The gap between them is the improvement opportunity, and it is invisible if only one is measured.

How to run the mapping exercise

1. Pull twenty recent files of the chosen permit type, including two that went badly.
2. Walk each file with the staff who handled it, recording actual dates and handoffs rather than target dates.
3. Mark every decision point and the criteria actually used.
4. Mark every rework loop and its trigger, including informal phone-call fixes.
5. Record where information is re-entered or re-read, which is where structure will pay.
6. Note where the process differs by applicant type or file quality, and why.
7. Validate the map with a different group of staff before using it.

Implications for authorities having jurisdiction

Keep the map current. A map that describes a process abandoned two reorganisations ago is a liability during configuration. Assign an owner and review it when volumes, staffing or code editions change.

Publish the applicant-facing portion. Applicants who understand the sequence and the decision points submit better files and escalate less.

Implications for applicants and professionals

Applicants can map their own side: how long design coordination takes, when consultant sign-offs arrive, how deficiency responses are assembled. In many projects the applicant-side loop is longer than the municipal one and easier to shorten.

Risks, limitations and safeguards

• Mapping the intended process rather than the actual one is the standard failure; use file evidence, not policy documents.
• Staff may fear that mapping is a performance exercise; state the purpose and keep it about process.
• Small samples can mislead on volume-driven effects; treat the map as qualitative and the timestamps as the quantitative baseline.
• Maps go stale quickly; assign an owner and a review trigger.
• A map is not a target state; do not fund improvements from the map alone.

PermitAssure perspective

PermitAssure engagements begin with the current-state map for one permit type, because checklists, deficiency taxonomies and rule scope are configured from it. Where a department has no map, producing one is the first phase and is useful independently of any platform decision.