Digital transformation in government is mostly about the things that don’t make the press release. The software purchase is easy. Getting the organization to actually change how it works is where most of these initiatives stall.
Here’s what I’ve run into doing this work in New Jersey.
The obstacles are pretty predictable
Legacy systems are the obvious one. Agencies running on mainframes from the 1980s, vendors who’ve gone out of business, institutional knowledge walking out the door with retiring staff. None of this is surprising, but it compounds. A modernization project that should take six months takes two years because every decision hits a dependency on something nobody documented.
Budget is the second constraint, and it’s not just about money — it’s that procurement processes were designed to prevent fraud, not to ship software. Lowest-bidder rules and multi-year approval cycles are brutal when you’re trying to move at anything resembling modern pace. Building a business case for “technology spending” to people who’ve been burned by failed IT projects is its own skill.
The harder problem, honestly, is culture. “We’ve always done it this way” is a real blocker, and it’s usually not stubbornness — it’s that people don’t trust that a new system will actually work, because in their experience it often doesn’t.
What actually helps
Start with a specific problem, not a vision. “Digital transformation” as a concept is too abstract to rally people around. “Municipalities can’t submit lead reporting data without faxing a PDF” is concrete — you can build a solution for that, measure whether it works, and point to it.
Talk to the people who use the system, not just the people who manage it. This is where I’ve learned the most surprising things. The forms that seem redundant often capture data that someone downstream depends on. The workarounds people have invented are sometimes smarter than the official process.
Treat it as a product, not a project. A project has an end date. Government software needs to keep running, getting updated, staying compliant. Building it with no plan for what happens after launch is one of the most common ways these things fail.
Case study: Municipal Lead Portal
The best example I can point to from my own work is the Municipal Lead Portal — a cloud-based React application for tracking lead hazards across all 564 New Jersey municipalities.
The challenge was that multiple agencies needed to access and update shared data in real time, with role-based access for different types of users, while staying inside state security requirements. The previous process involved a lot of manual data entry and duplicate reporting.
We built role-based access control, real-time data synchronization, and mobile-responsive interfaces that actually worked on tablets in the field. Reporting time dropped by 70%. More importantly, the data quality improved because people weren’t transcribing from paper.
Technical decisions that matter
Database choice matters more than people admit. PostgreSQL for relational data with complex queries, Redis for caching and sessions, managed services where the operations burden would be hard to sustain internally. Don’t pick what you’re comfortable with if it’s the wrong tool for the problem.
Build APIs from day one. Government systems need to talk to each other, and if you don’t design for that upfront you’ll spend years building point-to-point integrations. RESTful endpoints with real documentation and a versioning strategy are not a luxury.
Security has to be baked in, not bolted on. Regular pen testing, encryption at rest and in transit, MFA, principle of least privilege, comprehensive logging. Government applications are targets. Treat them that way.
What doesn’t work
Scope creep kills projects. Define the MVP, launch it, measure it, then expand. “While we’re at it” additions are where timelines go to die.
Ignoring accessibility is both a legal problem and a practical one — government services have to work for everyone, including people using screen readers, people on older devices, people with limited digital literacy.
The hardest thing to remember: technology is the easy part. If the people using the system don’t trust it, haven’t been trained on it, or find that it doesn’t fit how they actually work, the project has failed regardless of how good the code is.
Resources
Gavin Rozzi leads digital transformation initiatives at the New Jersey Department of Community Affairs, where his team has reduced municipal reporting time by 70% while serving 564 municipalities. Explore his New Jersey work or book him as a speaker for your next conference.
About Gavin Rozzi
