But he’s never seen one quite like the current project to set up e-billing and online payment for school and property taxes.
That’s because the vendor, eGov Strategies, took an agile approach. Instead of developing the project and then handing it over, or taking an existing product and plugging it into Clavin’s systems, the company adopted a project calendar based on sprints. They would focus on building individual pieces of the system, then testing them with users and tweaking them, adding features and fixing bugs as they went.
And it didn’t take a big overhaul of how the city handled procurement in order to do it, nor did it take a lot of legal preparation or staff training. The vendor just decided it was going to work on the project in a new way.
It turns out to be an improvement on the usual way of setting up new systems, Clavin said.
“A lot of these companies have one big module and they think they can plug it in and make it work, and it doesn’t work that way with other systems we’ve implemented here,” he said.
That’s a familiar approach when it comes to government IT work, and Clavin said it’s caused problems before. He had to delay launching one system for a year because it wasn’t handling data correctly.
It’s partly because New York towns like his have special tax requirements that differ from other states.
Just look at the system in question. It’s designed to handle a process where the town must mail out bills — and receipts — for two separate taxes, twice a year. That’s eight individual mailings for many people, and there are a lot of people in the system. The receiver’s office collected $2.5 billion last year. The mailings rely on calculating penalties and interest.
The new system is meant to allow customers to access bills and pay them online.
“We end up paying 42 cents a letter,” Clavin said. “So that’s a tremendous savings right off the bat. If we can get 15 percent of the citizens paying online, we’re saving thousands on postage, not to mention manpower.”
All that complexity makes it tough for a town like Hempstead to just pick up a piece of software designed for other systems and plug it in. So an agile approach made sense to him — it allowed his employees, the people who know how the process works, to help guide the product toward working for them.
Jason Brietweiser, director of dev ops and scrum master for eGov, said the approach basically allowed the company to nail down users’ needs and preferences earlier in the process.
“The methodology we’re using assures that we’re actually working on things that matter to the users,” he said.
That means that the company isn’t wasting time building things people don’t need, or building it in such a way that it doesn’t quite do what users need it to do. It also gives the employees a head start on learning the new software.
“By the time they start handling reports, they’ve been using the system for months,” said Ken Barlow, eGov’s chief solutions officer and co-founder.
What it all adds up to is a greater likelihood that a project will be done on time, doing what it needs to do and avoiding unexpected hiccups along the way.
But agile is not an approach often used at the local level of government. In fact it’s probably not very common at any level of government in the U.S., though there has been movement at the federal and state levels to give agile methodologies a try.
“You do see it on the federal side, they put out an RFP that says that this needs to be agile,” said Alan Pyrz, eGov’s chief technology officer and co-founder. “We’re not seeing that at the local level.”
