Enterprise Work-Management Platform Rescue

I joined a utility to administer a work-management platform that was expected to be nearing handoff. What I found was a different assignment: the organization had software and a partially completed implementation, but it did not yet have an operating system employees could use to manage day-to-day work.

The GIS foundation was useful and worth preserving. The operational layer was not ready. Accounts, service-request and work-order structures, departmental workflows, routing, permissions, and usable navigation still had to be translated from how the organization worked into how the platform should behave.

Over roughly two months, I learned an unfamiliar CMMS while rebuilding that foundation. I launched the rebuilt operational platform by July 21, 2023, supported departments directly through stabilization, and then expanded the system with event-driven integrations and automation. Approximately 100 employees across the organization were in scope.

The utility needed one reliable place to coordinate operational work across Customer Service, Dispatch, Engineering, Construction, Operations, Meter Reading, Water Accountability, Inspection, Sewer, Finance, and GIS/IT. Installation alone had not created that capability.

Employees did not yet have a practical way to receive, understand, route, or complete work. Templates and task sequences were missing. Department and crew structures had not been translated into assignments. Generic navigation forced users to search across organizational records; field employees faced the same problem in a mobile context.

The responsible decision was not to start over reflexively. It was to preserve what worked, understand what was missing, and turn the existing investment into a usable production system.

I had not previously administered Cityworks or another CMMS. While learning the product, I also needed to learn how different departments defined work, ownership, urgency, handoffs, access, and completion.

Office and field users required different views. Access could not expose every record or function to everyone. Some processes belonged in one task-driven job; others needed downstream work only after a decision. Launch pressure meant discovery and configuration could not be leisurely, separate phases.

The challenge was less about finding every available feature than deciding which operating model the platform should enforce.

The implementation vendor completed the GIS configuration, and I retained that work. I assumed ownership of the remaining operational rebuild and the ongoing application workstream.

My responsibilities included department discovery; request, work-order, and task design; routing and automatic assignment; groups, crews, and least-necessary permissions; material and labor-rate administration; homepage, menu, dashboard, query, notification, mobile-queue, training, support, integration, governance, and roadmap work.

This was collaborative enterprise work, but the operational configuration, launch, stabilization, and continued expansion became my responsibility.

I began with the work rather than the software. For each department, I mapped what triggered a request, who owned the next decision, what information had to travel, where approval mattered, and what users needed to see without searching through unrelated records.

The launch was not the finish line. I spent the following months training employees in the context of real work and changing configurations when production use exposed friction. Embedded support turned adoption into a feedback loop.

• Preserve the functioning GIS foundation instead of replacing useful work.
• Use task-driven workflows when several stages belonged to one operating process.
• Apply least-necessary access through departments, groups, crews, and permissions.
• Replace search-heavy navigation with department menus, dashboards, targeted queries, and context-aware mobile inboxes.
• Stabilize core work management before adding integrations and advanced automation.

The rebuilt platform established structured service requests, work orders, tasks, routing, assignment, permissions, crews, material administration, labor-rate maintenance, department navigation, and mobile access. It surfaced relevant work by role and department.

After stabilization, Cityworks events could trigger a governed integration layer that evaluated conditions, updated records, assigned work, sent notifications, performed calculations, and created downstream work.

In hydrant-flow testing, standardized field collection and automated calculations prepared a consistent result for engineer review and certification, helping move customer-requested work from days to same-day completion. In the large-meter process, an approved request could automatically create and route installation work. Automation supported the correct human authority rather than bypassing it.

The organization moved from an incomplete implementation to a production work-management platform supporting company-wide departmental scope. Approximately 100 employees were in scope, although that figure is not a verified count of active users.

Departments gained clearer access to work and consistent templates, tasks, routing, permissions, crews, and administrative structures. Later integrations reduced manual handoffs without removing required review or approval.

The strongest outcome is durability: the platform became an operating capability, not a launch artifact.

I continue to own configuration, workflow design, integrations, troubleshooting, training, governance, production support, and the roadmap. New needs are evaluated as process and control questions first.

Cityworks CMMS, GIS foundation, Cityworks Mobile, payroll-connected labor-rate maintenance, webhooks, queued event handling, and Power Automate. The value lies in the operating model those tools support.