Part 5. Picking Your First Automation Project: Why It Should Be Boring.
A town I worked with had 10,000 residents and decided its first automation project would be permitting. Not a piece of permitting. All of it. Building, electrical, plumbing, sign, special event, the works, unified into one seamless portal. Eighteen months and one very expensive consultant later, they had automated approximately none of it, but they had produced a 40-page requirements document and a standing Tuesday meeting that outlived two department heads. Meanwhile, the town next door automated their meeting-minutes distribution in an afternoon, using software they already owned, and quietly saved a staff member four hours a week for the rest of time. Guess which town automated something else the following year.
The Seduction of Being a Hero
Every town has one project that everyone agrees is the real problem. It's usually permitting, or procurement, or some version of "the way we handle public records requests is a disaster." It's the project that gets mentioned at every budget hearing, the one a council member ran on fixing, the one that would, if solved, make you look like a hero. It is also, almost without exception, the worst possible place to start.
Big, visible, politically charged processes tend to share three features that make them terrible first projects: they touch multiple departments who don't agree on how the process should work, they involve edge cases that took twenty years to accumulate and that nobody has fully documented, and they are watched closely enough that a stumble becomes a council agenda item. Starting there isn't ambition. It's choosing the hardest test in the class to take first, with an audience, before you've read the textbook.
The Four Bs: Boring Buys Buy-In and Budget (weekly alliteration requirement, done!)
A boring project is not a small one, necessarily, and it's certainly not an unimportant one. It's a project with a narrow blast radius. If it goes sideways, a handful of people are mildly inconvenienced for a day, not a resident who can't get a permit before their contractor's crew shows up. Boring processes tend to be repetitive, well-understood, and low-stakes enough that you can finish them, which matters more than people expect. A finished small project beats an unfinished large one in every way that counts: it produces a real result, it teaches your staff what automation involves, and it gives you something concrete to point to the next time you're asking for budget or buy-in.
The goal of your first project isn't to solve your town's biggest problem. It's to build the muscle and credibility you'll need before you attempt the project that is actually big.
Three questions worth asking before you commit
Is the process the same every time? If the answer starts with "well, it depends," that's a process with branches, exceptions, and judgment calls baked in, and those are expensive to automate well. Look instead for the process where step two always follows step one, regardless of who's doing it or which week it is.
Does a mistake annoy someone or hurt them? A misrouted meeting reminder is an annoyance. A missed code-violation deadline that results in a resident losing an appeal window is harmful. Pick projects where the downside of an early, imperfect version is a shrug, not a lawsuit.
Can one person see it through, start to finish? If your first project requires sign-off from four departments and a memo to the council, you have accidentally picked a governance project and dressed it up as a technology project. The best first projects live entirely within one person's authority to test, adjust, and deliver.
What this looks like in practice
The projects that pass all three tests are rarely glamorous, which is exactly the point.
Automatically distributing meeting minutes and agendas to a standing list the moment they're approved.
Sending renewal reminders for licenses and permits sixty, thirty, and seven days out instead of relying on someone remembering to check a spreadsheet.
Logging incoming public records requests into a shared tracker the moment they hit the intake inbox, so nothing sits unread for two weeks because the one person who checks that folder was on vacation.
Routing vendor invoices to the right approver based on department and dollar amount instead of a stack on someone's desk.
None of these will get you a headline. All of them will get you a finished project in under a month, using tools you likely already own, and a story you can tell that ends with "and it just works now" instead of "and we're still working through some issues."
The payoff
Here's what nobody tells you about the boring project: it isn't really about the four hours a week you save on minutes distribution, though that's real and it adds up. It's about what happens the second time. Once you've delivered one small, working thing, the next conversation about automation starts from a different place. You're no longer the department asking for money to fix a vague problem; you're the department that has already delivered, asking for the resources to do it again on something bigger. Council members remember finished projects. Staff remember which initiatives actually changed their day-to-day and which ones generated a binder. Boring, finished, and real beats ambitious, stalled, and theoretical every single time, and it's not close.
Your homework before the next post
Pick one candidate process, something you already suspect could be automated. Now write down three things about it on a single page: how many times a month it happens, how many different people touch it along the way, and what actually breaks if the first version isn't perfect. If the answers are "often," "one or two," and "not much," you've found your first project. If they're "rarely," "everyone," and "a resident gets hurt," set it aside for later and keep looking. You want boring. Boring is winning.
Next up: The Pilot Nobody Notices — Rolling Out Your First Automation Without Calling It One.
About the Author: Layne Thompson is Senior Vice President at JMA Resources, Inc., where he leads Growth, Innovation, Research, and Development initiatives. With more than 30 years of experience spanning military service, federal leadership, private industry, and local government, he is passionate about helping communities implement practical, cost-effective technology solutions that deliver real results.
Layne previously served as Borough Manager for the Borough of Mechanicsburg, Pennsylvania, from December 2022 through December 2025.
