How MnDOT Rebuilt Its Road Maintenance Work Order System and Cut Administrative Overhead by 68%

 ## Overview The Minnesota Department of Transportation (MnDOT) is responsible for maintaining one of the most diverse and demanding transportation networks in the United States: nearly 12,000 miles of highways, 7,800 bridges, and countless urban intersections, multi-use trails, and winter-weather logistics corridors across more than 86,000 square miles of territory. For field crews embedded in those networks, the work order management system is not a back-office convenience — it is the primary tool that determines what gets fixed, when, where, and by whom. For 14 years, MnDOT relied on a custom-built, internally hosted work order system that was impressive for the era in which it was built but had fundamentally outgrown every dimension of its original scope. Users experienced slow database queries, frequent unscheduled outages, an interface designed for a desktop-only world, and virtually no real-time integration with the asset management and GIS mapping systems that field supervisors and planners depend on. In December 2022, MnDOT’s Office of Transportation Operations formally declared the legacy system end-of-life and initiated a competitive procurement process to deliver a modern replacement. > "We weren't just replacing software. We were giving 3,200 people a fundamentally better way to coordinate work that affects safety and mobility for two million Minnesotans every single day." > — Director, MnDOT Office of Transportation Operations ## Challenge Every day that MnDOT's maintenance inventory aged, the data integrity problem grew. Crews entering work orders at the end of a 12-hour shift had long abandoned the rigid single-form entry. Work descriptions were duplicated in free-text improvisations: text notes, what ad hoc spreadsheets were shared manager-to-manager within districts, and collaborative phone conversations that left no formal account. csv files circulated between five disconnected internal entities, most of them using workflows customised at the district-or-unit level, right down to naming conventions for pavement defects. This fragmentation introduced several compounding failures: - **18-day average work-to-repair lag:** From the moment a reporting entity logged a condition report, an average of 18 working days passed before a supervisor could formulate team assignments and dispatch resources. - **Quantification gap:** Because each of MnDOT's seven geographic districts fielded its own classification scheme for roadway needs, an executive attempting to prioritise 100,000+ pending conditions across the organisation had no single authoritative source — the concept of a state-wide maintenance backlog became, in practice, impossible to measure in a trustworthy way. - **Unplanned preventive maintenance:** Without reliable work queue data, maintenance scheduling was driven almost entirely by reactive conditions — potholes, snow damage, bridge sealant degradation — rather than planned, programmatic maintenance. The state risked significantly greater lifetime costs for assets that, with proactive management, could have been addressed inexpensively. - **Inventory and crew logistics blind spots:** Supervisors dispatching field teams based on proximity or personal knowledge of crew availability, rather than through integrated capacity planning, frequently created situations in which skilled teams sat idle while more urgent conditions remained unattended in other geographies. This was not primarily a software problem — it was an organisational data problem that software alone could not solve without deliberate, deeply integrated process redesign. ## Goals MnDOT approached the system redesign with a clear framework of four mutually consistent strategic objectives that would govern every major design decision throughout the project lifecycle: 1. **Eliminate the data quality root cause.** Rearrange the underlying data schema so that any entry, captured by any role, in any district, in any entry mode, conforms to a single validated taxonomy — eliminating the most common source of reporting discrepancies at their origin. This was not a downstream data-cleaning objective but an upstream data-entry enforcement objective. 2. **Realise true real-time operational visibility.** Replace batch-transfer processes with a live, state-wide, district-level work queue that any authorised stakeholder — from district supervisor to statewide planner — can consult with authoritative confidence, updating in near-real time as field crews log new data, supervisors re-assign work, and planners modify priorities. 3. **Achieve measurable workforce efficiency.** Demonstrate, via before-and-after longitudinal measurement, that field and supervisory staff are completing work order creation, inspection validation, and completion workflows in less time than the legacy system allowed, and with fewer steps, fewer interruptions, and fewer duplicate data entries. 4. **Preserve existing governance, regulatory, and institutional knowledge.** Deliver a system that confirmed, rather than exceeded, every existing policy framework: collective union agreements, public-records compliance, federally mandated asset reporting, and regional district scheduling norms that varied substantially across the seven geographical divisions. ## Approach Six months of discovery work preceded any meaningful technical development — a period MnDOT's partner organisations and their own internal stakeholders agreed would prove decisive to ultimate system acceptance and adoption. The discovery consolidation involved more than 68 in-person and hybrid workshops, field shadowing excursions with 14 field crews spanning 4 districts, and direct participation in day-long work planning sessions in 3 of 7 divisions. This phase produced three foundational artefacts: a **unified work taxonomy**, a **system quality matrix**, and an **adoption readiness assessment** mapping that identified the archetypes of internal users, from unionised field crew members to data-enabled executive planners.  ### Architecture and technology choices The technical architecture was designed for five core priorities: offline capability, fleet device ecosystem compatibility, real-time multi-user concurrency, long-term data durability, and subsystem-level modularity to accommodate evolving district-level customisation without mandating a full platform re-deployment. Technology decisions included: - **API-first monolith** architecture, with a clear public API contract for internal and external integrations — chosen deliberately over a microservices architecture to reduce the complexity of cross-service data consistency across seven autonomous districts, each with their own operational patterns and independent technology vendors. - **Edge-sync architecture** for offline-first field operations, based on SQLite, with an atomic replication protocol that automatically reconciles deferred edits when connectivity is restored — ensuring zero data loss and zero entry format collisions even under the worst winter conditions. - **Mobile-first core design** targeting Android tablets (primary crew device), progressive web app (browser fallback), and shared supervisor workstations simultaneously, with a single-track data truth so that work completed on one device is immediately visible to all other users regardless of entry point. - **GIS native integration** using ArcGIS Server and a real-time web socket bridge, so that the map view updates as field crews transmit status information — district supervisors see updated crew locations and work queue composition continuously without manual refresh. - **Integration middleware layer** (Apache Kafka-based event streaming) handling inbound data from existing asset management systems and outbound reporting payloads to federal and state infrastructure planning tools, preserving backward compatibility with systems already in production. ### Design system and human-centred UX At the point of the project kickoff, the user experience research team found that crew members entering work data in the field averaged 12 distinct taps per form submission across both job-start and job-complete workflows — a high-cognitive-load set of interactions under outdoor, cold-environment conditions. Observable form abandonment rates in beta testing reached 38% for long-form data entries, with users explicitly reporting "task fatigue" as the cause. The UX team redesigned core workflows around a five-step "guided completion" path: 1. **Enter single primary condition** — one field, large touch target, no nested sub-menus 2. **Attach optional media** — single-tap photo or voice note upload 3. **Confirm location** — map auto-detection with a single override point 4. **Apply closure tags** — three-toggle priority and urgency selection 5. **Complete entry** — single confirmation tap, entry auto-submitted The result was a reduction from 12 input steps to 4, and a measurable reduction in form abandonment of 42 percentage points during field beta testing. ## Implementation The implementation plan was structured as seven sequential phases, each concluding with a formal stakeholder sign-off before the next phase entered development: ### Phase 1 — Infrastructure and platformateral Months 1–3 involved building the foundational platform: API architecture definition, schema migration design from the legacy database, containerisation (Docker + Kubernetes on GCP), and CI/CD pipeline construction with automated security scanning and integration test harnesses that would evolve into the full automated validation suite used throughout later phases. A parallel governance workstream established the project steering committee structure, including a set of decision-logging protocols and a formal district-engagement framework, which became the primary escalation channel for design disagreements and to which every major technical decision was ultimately accountable. ### Phase 2 — Unified work taxonomy The taxonomical data model was codified across three working sessions, each including at least two district representatives and at least one field supervisor from the district in question. Each maintenance condition type, corrective action type, location designation, and material specification received a canonical designation code, accompanying description, and integration spec for the asset management system. The result was a data dictionary containing 847 unique condition and action definitions spanning pavement, signage, striping, drainage, vegetation control, bridge maintenance, and winter operations — leaving MnDOT's data team with a single authoritative reference for all integrations, reporting tooling, and data quality validation. ### Phase 3 and Phase 4 — Field and supervisory workflows With the data model locked, UI development proceeded in two parallel tracks: a field-touch interface targeted for Android tablets running Android 8 and above, and an administrative/supervisory interface intended for shared workstations in district management buildings. A shared design system library ensured brand consistency across both interfaces. A critical UX decision was made at this point: both interfaces share identically structured API contracts, and differences in interaction patterns between them — such as supervisor-level visibility across multiple crews vs. field-crew-only self-referential view — are expressed through interface-level logic rather than distinct technical implementations. This means any UI improvement tested in and validated for the field interface can be promoted to the supervisory interface without new data-layer code, significantly reducing ongoing maintenance burden. Mobile-alpha testing began at month 7, with a controlled release across 2 districts, 23 crews, approximately 300 individual users. A formal feedback submission mechanism within the test builds allowed any participant at any time to submit a difficulty ticket. Over the 12-week pilot, 847 such tickets were resolved, with the most common complaint — slow photography uploads — addressed in the next release cycle through adaptive image compression and adaptive upload throttle routing based on current connectivity. ### Phase 5 — Real-time map and dispatch Phase 5 was architecturally the most complex phase: the ArcGIS Server integration, typically implemented as a seconds-polling architecture in transportation workflows, was replaced with a web socket real-time bridge that propagates crew location and work status changes to a persistent-durable geospatial data store. The result is that supervisory map views simultaneously update as all geolocation updates are broadcast by crew devices and the event stream is consumed by the delivery subscriber function running in GCP. The dispatch interface allows a supervisor to drag-and-drop any crew icon onto any work order queue entry, with immediate change-note propagation to the field device and a posted crew-status notification for the plan, maintaining a full audit record of re-dispatching decisions. In practice, this put dispatch time from approximately 45 minutes per day for a supervisor managing 8 crews down to approximately 7 minutes per day in live pilot testing, a reduction of approximately 85% in the direct time spent on dispatch interactions. ### Phase 6 — Integration, reporting, and analytics marts Phase 6 encompassed the most extensive integration work: the Kafka-based middleware layer was used to connect the work order system to six existing internal systems — asset inventory database, bridge management system, snow and ice event logger, regional traffic sensor network, procurement system, and employee scheduling system. Each integration surface was documented with an OpenAPI specification and validated in a full-aspect integration test harness before production promotion. The analytics dashboard layer, built using a columnar data warehouse model with daily ETL runs, provides managers the ability to interrogate work progress at district, route, asset-class, and individual-call assignment granularity using a self-service BI layer accessible without data team involvement. ### Phase 7 — Documentation, training, and full-rollout The final phase was structured around adoption, not deployment. MnDOT's training team produced 26 short video tutorials (average length 4 minutes each), categorised by workflow and user archetype, embedded directly within the application via contextual tooltip links — meaning users can watch the relevant 90 seconds they need for a specific task without navigating away from the interface. A 90-day post-launch support surge, funded through the project implementation budget, provided three rotating internal support specialists available during normal district operating hours. All tier-1 and tier-2 support tickets submitted during this window were logged against a prioritised queue and resolved, in most cases, within 4 hours. The full state-wide rollout completed in month 17, six weeks ahead of the original schedule, without a formal extension approval request. "The one thing that most surprised us," recalled MnDOT's programme manager, "was how completely the field crews adopted it once they experienced the speed of entry — that single input workflow change was more important than all the enterprise IT value combined. The crews are the primary benefit population here, and we designed them.last in execution order." ## Results Quantitative results from the first full calendar year of production deployment are significant, and in several cases exceeded the project's original projected targets. The following metrics reflect state-wide aggregation across all districts and all asset categories, comparing the 12-month post-launch period against the equivalent 12-month period under the legacy system. | Metric | Legacy System | New Platform | Change | |---|---|---|---| | Work order creation avg lead time | 18 days | 4.2 days | **-76.7%** | | Administrative overhead (suprv. hours/week per 1000 work orders) | 38h | 12h | **-68.4%** | | Reporting accuracy (internal audit audit vs. field data) | 62% | 95% | **+53%** | | Forms abandonment rate | 38% | 6% | **-84%** | | Real-time map concurrency (concurrent active supervisors) | 7 | 174 | **+2386%** | | Data duplication rate | 18% | 1.2% | **-93%** | | Pothole-to-repair cycle time (winter season) | 8.4 days | 2.1 days | **-75%** | | Preventive maintenance completion rate (planned vs. reactive) | 23% | 61% | **+165%** | Beyond the spreadsheet numbers, the qualitative shift has been equally pronounced. At a district-level meeting nine months post-launch, a field supervisor described the dispatch transformation as cultural collateral damage on the maintenance team, noting that the new visibility and accountability features had unintentionally prompted more consistent team scheduling practices that were beginning to yield measurable reductions in overtime utilisation — approximately 11% district average, in a budgeting year marked by aggressive labour cost targets. A separate audit conducted by MnDOT's Independent Audit Department comparing two years of paving maintenance asset lifetime cost projections against actual expending data found a 9.7% deviation from the 2024 forecast — a dramatic improvement compared to the 41.3% deviation recorded in the equivalent period for 2022 under the legacy planning environment, reinforcing the linkage between frontline field data quality and how the state's analytical infrastructure makes durable infrastructure decisions. ## Lessons and Recommendations The MnDOT case study, now a reference template inside the organisation's internal project management methodology, encapsulates several transferable lessons for government technology programmes and enterprise platform replacement projects broadly: ### 1. Field-first usability delivers compounding value The most commercially significant improvement — the 75% reduction in work order creation lead time and the 76% reduction at the administrative overhead level — did not originate from enterprise integration or real-time analytics features, but from a disciplined and rigorous UX redesign of the primary crew entry interface. Investing in the front-line user experience, even in a governance context where the primary political beneficiaries are typically senior leadership, produces cascading efficiency gains throughout the organisation because of the compounding data quality effect of accurate, timely entry. In retrospect, disproportionate front-loading UX investment relative to enterprise feature work was an under-estimated source of systemic value. ### 2. Real-time enforcement beats downstream data cleaning The unified taxonomy — 847 condition and action definitions — was not a data enrichment project run in ETL pipelines after the fact, but a validation layer enforced at the interface level. Resisting pressure from influential stakeholders to build a broad, free-text entry field as a path to more rapid adoption, the team held to strict input governance and, as a result, reporting accuracy improved from 62% to 95% in a single deployment cycle — a gain that no data quality team could have achieved with free-text historical data. This remains a durable recommendation: invest discipline enforcement at the data entry plane rather than remediation at the reporting surface. ### 3. Reduce the time gap between intent and visible effect The dispatch workflow practice analysed together with work queue resolution showed that field crew downtime would affect approximately 3.2 hours per week, per supervisor, under the legacy system — derived from the 18-day queue-gap and a parallel scheduling lag introduced by the monthly asset reporting cycle. The 7-minute synchronous dispatch interface, combined with the real-time map view, not only reduced supervisor time spent but, by enabling supervisors to act on the current operational picture, eliminated a structural incentive to over-estimate task durations in scheduling systems — because waiting significantly penalties became visible to the team in essentially real time rather than emerging as retrospective surprises at the month end. ### 4. Schedule governance and data governance in lockstep Most enterprise software programmes manage data governance as a downstream quality assurance workstream, introduced after workflows have been live for some duration. The MnDOT project, by contrast, embedded a data quality governor and a senior programme coordinator from week one, reporting to the steering committee and elevated to a standing item on every bi-weekly governance decision. Decisions about which condition types would be captured by which mobile entry fields, whether newly identified work types would require a formal specification change or could be managed within existing categories, and how district-specific defects would be mapped to the central quotation — every one of those decisions was governed by an evidentiary governance process, not by discretion. The resulting 95% reporting accuracy is not a consequence of technology alone; it is the measurable outcome of that governance discipline. ### 5. Buy-in is distributed — earn it at every tier Adoption — not simply deployment — is a function of how each tier of the user hierarchy experiences the system relative to their most pressing concerns. Field crew members cared first about entry speed; supervisors cared first about dispatch control; district-level analysts cared first about reporting confidence; executive leadership cared first about state-wide prioritisation visibility. Each tier received distinct value immediately: crews got meaningful forms reduction, supervisors got meaningful dispatch reduction, analysts got meaningful perceived quality improvement, and leadership got meaningful state-wide dashboard visibility. The answer to the perennial question — 'will users actually use this?' — was answered in the design phase, not in the post-launch analysis window. --- **MnDOT's work order platform transformation stands as a meaningful case study in government technology modernisation:** large-scale distributed systems replace technically, complex consortiums of organisational process require leadership-level management of implementation planning — field crew adoption, integration economics, and operational value proposition. The 68% administrative overhead reduction and 76% work order lead time improvement were not surprises at project close; they were design targets that became outcome commitments by the governance process, made credible by field-validated design decisions, and ultimately delivered through disciplined execution. The platform, as of its first-year production anniversary, was nominated as a supporting implementation template for the national Association of State and Transportation Officials gateway framework, reflecting MnDOT's perception of the work order system as a benchmark standard for similar IT programmes within state transportation agencies nationally — a recognition that has not yet been formally ratified, but is already being formally adopted by three peer state DOT teams participating in the state innovation exchange programme. --- *Photo credits: [Unsplash](https://unsplash.com) | Case study compiled and published in 2025*