How Ohio Used Agile Development to Overhaul its Tax System

When the overhaul of Ohio’s tax system stalled in 2012, it showed all the signs of another large-scale government failure. The project began in June 2008, when the state awarded a fixed-price $52 million contract to Hewlett Packard Enterprise (HPE) to integrate 27 legacy tax systems into a single platform called the Ohio State Taxation Accounting and Revenue System (OH STARS). After four years of miscommunication, missed deadlines and finger pointing, many were ready to admit defeat. But with a little bit of persuasion, stakeholders gave the nod to try again — and today, the state looks back to tell a different story.

Today, 14 of 23 tax types have been integrated, and six more are scheduled for completion by October. With its self-confidence redoubled, the state even expanded the project to include a $13 million front-end system that will allow citizens to file taxes electronically. The project’s reversal caught the attention of the National Association of State Chief Information Officers (NASCIO), which presented a 2014 State Technology Innovator Award to Mark Walker, who was appointed the project’s director upon the 2012 reset.

“I think it was perseverance,” said Doug Robinson, NASCIO’s executive director. “They were able to rescue a project that was close to life support. The major thing was that it was [Walker’s] project leadership and going to agile delivery. … Tax and revenue are always complex systems. They always touch and interfaces are complex so they touch many other systems, so it was his leadership and understanding of the business processes.”

Walker has been with the Ohio Department of Taxation for more than 35 years, and today he serves as its CIO. When he evaluated the project in 2012 to determine if it could be salvaged, he recalled a culture of miscommunication and misunderstanding.

Faulty Approach, Clashing Cultures

For four years, the project followed the same pattern. Using a linear development approach, the state’s businesses held meetings with the HPE development team to establish how an off-the-shelf Oracle system could replace the state’s many tax systems spread across various department mainframes and Microsoft Access databases.

Detailed discussions between the state and vendor outlined the project until both sides believed they understood each other, and then they would part ways — sometimes for as long as six months at a time — and when the developers returned to the businesses with finished work, it typically wasn’t what the state wanted.

That’s when the finger pointing began.

“When the project started in ’08, we expected the vendor to come in here and basically do the project for us,” Walker recalled. “That’s really faulted. Yes, we’re paying them to manage the project, but … they don’t understand my business and I don’t understand the product, so we really have to be engaged in basically a partnership so that we both play very critical roles in making sure that first of all the vendor understands my business needs and that they understand the product they’re using well enough to give the most efficient way of administering whatever I need to do. And we were not doing that pre-reset.”

David Montgomery, an HPE executive who took over the project after the reset, recalled cliques of bickering workers when they evaluated the project’s future in 2012.

“We had a lot of different cultures clashing,” Montgomery said. “We had government versus contracting — we had all these different camps.”

While workers were busy splitting off into factions, the original purpose was gathering dust, and everyone was losing sight of the goal.

Finding a New Approach

As one of the project’s co-sponsors, Walker wanted to find a new approach, a way to make the partnership with HPE work. Two weeks of analysis showed that it might be possible to salvage the project, but many were calling to cut their losses before the state wasted any more time and money.  After four years of churning, just $10 million of work had been completed.

“It took me a while to convince my tax commissioner that we should continue,” Walker said, “and we had to go through an awful lot of discussion with the governor’s office as well before we finally said, ‘OK, we’re going to do this.’ I think we took a significant chance, but I also think it was something that proved that government agencies can really be agile and can do things that are nontraditional and be successful.”

Agile Stats Though using one methodology over another is no more a guarantee of success than employing right-handed workers over left-handed ones, there ultimately is a reason that private-sector companies large and small use iterative development methodologies. In 2012, an agile development survey of more than 4,000 people involved in software development found that 84 percent of companies practiced agile development. Many companies still use a linear development process, but they still keep agile in their toolkit. And even though the NASCIO 2015 State CIO Survey found that the public sector is catching up in agile, government’s reputation for slow adoption of new technologies leaves open many questions about the future. Only 21 percent of respondents reported widespread use of iterative development, and one of the biggest reasons government isn’t adopting is because most procurement policies don’t fully support those frameworks. About 70 percent of survey respondents said they expect agile adoption to soon increase, but it’s unclear if those are realistic expectations. Only 23 percent of states report policies that fully support iterative development, and more than 40 percent of states report no plans to change their procurement processes.

Now committed to another attempt, both the state and the vendor made drastic changes. Walker was made director on the government side. On the vendor side, Montgomery took over as director and started by slashing his team of 200 developers down to 10, adding more as needed until the team was built back up to 70 workers. Most importantly, the traditional linear development cycle was abandoned for the faster-iterating agile development process, which forced state and vendor workers to work together daily.

“We knocked down those cultural barriers," Montgomery said, "and it’s just amazing to see something that people thought couldn’t happen."

Walker noted that he's had many visitors come in to see what the environment looks like. "And I challenge anybody to try to point out who is tax and who is vendor,” he said. “You don’t know, and it’s just one big wide open room with tables set up, and PCs and monitors. We’ve got whiteboards all over the room. It covers virtually every square inch of the walls, so the transparency and the communication is so much better now than it was pre-reset.”

New Agile Workflow

The new team spent the first 10 months creating a new framework for the project. With 27 tax systems and 23 tax types, the original team made the mistake of treating each tax as a unique entity, Walker said, but the new team soon realized that most of the taxes were similar if not the same in many ways, which allowed for greater consistency and ultimately simplified development. And agile’s shorter development cycle naturally brought the state’s businesses and the vendor closer together, which reduced the opportunity for misunderstanding and created a more resilient work culture.

“The way things are chunked out into smaller pieces, we started seeing progress almost immediately,” Walker said.

In this case, agile did more than just work — it acted as a salve to one of the state’s prickliest concerns. It was relatively easy for the vendor to swap its developers for new ones and start fresh, but Ohio continued to use the people who been slogging it out the last four years, some of them resistant to the notion of continuing onward. It turned out that agile served as the vehicle for the thing state workers had wanted all along.

“That agile process helps because my folks, all they were really asking for, even pre-reset, was a voice. ‘Let me help you understand what we mean.’”

Keystone of OH STARS Success

The biggest lesson to come out of the OH STARS reset was the necessity of executive support, Walker said, because finishing a project like this means borrowing the most forward-thinking people from each business. Without support from the top, he said, it would be hard to get those businesses to give up their best employees for such long stretches of time.

“It’s a little unusual, and I know contractually Dave [Montgomery] is still my vendor, is still responsible, but we really do have a partnership,” Walker said. “There is not much that happens on this project, from strategic or tactical to planning, that we don’t jointly do.”

Montgomery agreed that working closely using an agile methodology was the keystone of their success.

“We found a little more complexity because it takes a lot of agencies to work hand-to-hand to deliver this,” Montgomery said. “It’s very rare from an agile perspective — commercial or government — of this large of an agile delivery success. A lot of people still don’t believe you can do agile on this big of a project with this many people, and they’re wrong.”