Which Permit Rework Reasons Should Engineering Offices Review Each Month?

Engineering permit rework reasons should be reviewed monthly by grouping returned or corrected applications by cause, process stage, affected requirement or field, reviewing office or role, and final outcome. The goal is not to blame applicants or staff. It is to identify one recurring cause that the Office of the Building Official (OBO) can address through clearer instructions, better data validation, training, routing, or another authorized process improvement. A connected engineering permit workflow can support this review when the LGU already records consistent transaction statuses, reasons, and responsible roles.

Republic Act No. 11032 requires government offices and LGUs to review and improve transaction systems and procedures when necessary to reduce red tape and processing time. Monthly rework analysis should improve how an approved process is carried out; it should not invent new requirements or remove lawful technical checks.

What should count as permit rework in a monthly review?

For management reporting, rework can mean an application that returns to an earlier step, is corrected or resubmitted, or needs another review because information, documents, technical details, routing, or another process condition was not accepted.

The OBO should define this term before calculating any rate. A technical deficiency should also be separated from a routing or encoding mistake when the office wants to understand where the process is failing.

Keep the definition stable across the reporting period so changes in labeling are not mistaken for real improvement.

Which engineering permit rework reasons should the office group together?

The office should use controlled categories for engineering permit rework reasons aligned with its Citizen's Charter, evaluation forms, National Building Code procedures, and local workflow. Useful examples include:

• Incomplete listed requirement: A required document or attachment is missing.

• Incorrect or inconsistent application data: Submitted names, project location, lot information, or other data do not agree.

• Plans or specifications requiring correction: The technical submission needs revision after authorized evaluation.

• Zoning or land-use issue: A planning or zoning condition needs clarification or correction.

• Technical or code-compliance issue: A condition must be corrected under applicable technical rules.

• Wrong form or outdated version: The transaction used an incorrect form or document version.

• Routing or process-stage issue: The transaction reached the wrong reviewer or skipped an expected handoff.

• Other documented reason: A less common cause that should still be described.

These are practical management categories, not a national OBO reason-code list.

Why should missing requirements be separated from incorrect information?

They point to different corrective actions. If many applications are missing the same required attachment, the office may need clearer public instructions or a better intake check. If documents are present but the same field is repeatedly inconsistent, the stronger response may be data validation, form design, or staff guidance.

RA No. 11032 states that during preliminary assessment, the receiving officer should inform the applicant of deficiencies in accompanying requirements, limited to those enumerated in the Citizen's Charter. The monthly report should therefore distinguish a missing listed requirement from another type of correction.

A useful building permit rework report should therefore show both the broad category and the specific affected field, requirement, or document.

Why should the process stage be recorded?

The same reason means something different depending on where it appears. A project-location inconsistency caught at intake may point to a form problem; the same issue found later may show that earlier validation missed it.

Useful stages can include intake or preliminary assessment, zoning or planning review, technical evaluation, assessment or fee-related processing, payment confirmation, approval, release, or another locally defined checkpoint.

The exact stages depend on the LGU. The purpose is to identify where rework enters the process so the corrective action targets the right control point.

How should technical issues be separated from administrative-data issues?

Technical findings remain under the authority of the Building Official and qualified reviewers applying the National Building Code, referral codes, and applicable rules. A management report should not reduce them to clerical errors.

Administrative-data issues may involve inconsistent project addresses, wrong references, duplicate records, or routing errors. They may be improved through clearer forms or validation without changing technical standards.

Keeping the categories separate prevents a monthly KPI from creating pressure to reduce legitimate technical review merely to lower the rework count.

What should a monthly building permit rework report contain?

A concise report can include:

• reporting month

• permit or application type

• number of submitted applications

• number of returned or reworked applications under the defined rule

• rework reason category

• specific affected requirement, field, or technical area

• process stage where the issue was identified

• reviewing office or role

• final outcome after correction

• selected corrective action

• action owner

• next review period

This is a practical management record, not a DPWH-prescribed form.

How should Engineering calculate a monthly return or rework rate?

If the office uses a rate, define the numerator and denominator before comparing months. One simple internal formula is:

Returned or reworked applications ÷ submitted applications × 100

The report should state what "submitted applications" means, whether resubmissions are counted again, and whether one application can carry multiple rework reasons.

Without these definitions, LGU permit monitoring can produce percentages that look precise but are not comparable.

How should the office review repeated project-location inconsistencies?

Suppose one month's records show that project-location inconsistencies appear more often than missing-document returns. That does not prove a nationwide trend. It is only an internal example of how the OBO can use its own records.

The office should inspect which location fields are inconsistent, which stage catches the problem, and which source is treated as authoritative.

If unclear instructions cause the pattern, clarify the field. If staff encode the same location in different formats, standardize the entry rule. If source records disagree, route the issue to the proper records review.

How should OBO return reasons be reviewed without oversimplifying them?

OBO return reasons should be specific enough to support action but not so detailed that every case becomes its own category. A useful approach is to use one primary reason category plus a short controlled subreason or affected field.

"Incorrect information" is too broad if the office cannot tell whether the issue is the project address, owner name, floor area, or permit type. Dozens of nearly identical free-text reasons are also hard to compare.

Controlled reason definitions also support traceability. The related GoLGU guide on transaction checkpoints and return reasons in LGU workflows explains why returned transactions should retain the original action, reason, corrected information, responsible users, and new review result.

How should the office choose one corrective action from the monthly findings?

The corrective action should match the cause. Examples include:

• clarifying an existing Citizen's Charter instruction

• improving intake guidance for a frequently missing attachment

• adding validation to a high-error data field

• standardizing a project-location reference

• training staff on a repeated routing issue

• escalating a recurring technical issue for authorized review

The office should choose a correction that it is authorized to make. A high rework count does not permit staff to remove a legal requirement, ignore a technical deficiency, or shorten a required review without authority.

Who should own the monthly engineering workflow improvement?

Assign one owner to the improvement action even when several offices contributed to the cases. The owner may be the Building Official, an engineering supervisor, intake lead, planning or zoning counterpart, ICT/system administrator, or another authorized role.

Engineering workflow improvement works best when the report identifies the action, owner, target review period, and evidence that will show whether the change helped. An action such as "remind staff" is weaker than a specific change such as "revise the project-location instruction and review the same reason code next month."

How should the next month be compared without manipulating the metric?

Use the same definitions, transaction scope, and reason-code rules unless the report clearly documents a change. If the office changes the intake process halfway through the month, note the effective date rather than pretending the whole period used one process.

A lower return rate is not automatically positive. It may reflect real improvement, weaker reason recording, or incomplete cases moving forward. A higher rate can also appear after stricter preliminary checks.

The review should therefore compare the rate with the underlying permit correction trends, reasons, stages, and outcomes.

How does current Philippine policy support monthly process review?

RA No. 11032 requires covered offices to evaluate and improve transaction systems and procedures and to communicate listed deficiencies during preliminary assessment.

The DILG-DPWH-DICT-DTI Joint Memorandum Circular No. 2018-01 provides construction-permit streamlining standards, including evaluation checklists and comprehensive correction sheets or notices for deficient applications. It also provides for implementation monitoring.

These sources support consistent deficiency recording and process improvement. They do not prescribe the exact monthly management report proposed in this article.

How can GoLGU support monthly permit rework review?

GoLGU's public ERP page describes traceability, role-based access, centralized data, workflows, and reporting. Those capabilities can support an OBO that already records consistent application references, stages, and return reasons.

The public information reviewed does not establish that GoLGU automatically diagnoses rework causes, calculates the rate, recommends corrective actions, or changes Engineering procedures. Those controls remain defined by the LGU.

LGUs that want to review how permit transactions, return reasons, workflow stages, and management reporting could fit into a connected system can request a GoLGU ERP workflow consultation.

Frequently Asked Questions

Should every returned building permit application be counted as rework?

Only if it meets the OBO's defined reporting rule. The office should state what qualifies as returned or reworked and apply that definition consistently for the reporting period.

Can the OBO create its own return reason categories?

It can use practical internal categories for monitoring, but those categories should align with the Citizen's Charter, evaluation process, National Building Code requirements, and authorized local procedures. The categories should not create new applicant requirements.

What is the difference between a missing requirement and a technical deficiency?

A missing requirement means an expected document or item is absent under the applicable procedure. A technical deficiency concerns the substance of a technical submission or compliance review. They should be reported separately because they usually need different corrective actions.

Should one application have more than one rework reason?

That depends on the LGU's reporting design. If multiple reasons are allowed, the report should state whether the rate counts applications or individual reason occurrences so the denominator remains clear.

Does a lower monthly rework rate always mean the process improved?

No. The office should also check whether reason coding, intake standards, transaction scope, or review practices changed. A lower rate is useful only when the underlying definitions and controls remain comparable.

Can an ERP automatically decide which Engineering process should be changed?

No such GoLGU function was verified for this article. An ERP can support records and reporting, but authorized OBO and LGU officials should determine the appropriate process improvement.

Conclusion

Engineering permit rework reasons become useful when the OBO reviews them as a monthly management signal rather than a list of individual mistakes. Group cases by cause, stage, affected requirement or field, reviewing role, and outcome. Define the denominator before calculating a rate, then choose one evidence-backed corrective action and assign an owner. The strongest monthly review protects legitimate technical evaluation while identifying preventable permit correction trends that can be reduced through clearer instructions, better validation, training, routing, or another authorized process improvement.

References

• Republic Act No. 11032, Ease of Doing Business and Efficient Government Service Delivery Act of 2018

• DILG-DPWH-DICT-DTI Joint Memorandum Circular No. 2018-01, Guidelines in Streamlining Building Permits and Certificates of Occupancy

Disclaimer

This guide provides general operational information for Philippine LGUs. It does not replace the National Building Code of the Philippines, its implementing rules and referral codes, Republic Act No. 11032, Joint Memorandum Circular No. 2018-01, the applicable Citizen's Charter, zoning and fire-safety requirements, local ordinances, technical evaluation, or instructions from the proper authorities. Engineering offices should verify the current rules and approved local procedures before changing permit requirements or review steps.