January 3, 2014
In late summer of 2012, Consumer Financial Protection Bureau regulators went to their technology office with an idea.
The standard way to put proposed new federal rules online is in large blocks of text, similar to how they’re presented on paper in the decades-old Federal Register. By using hypertext and modern Web design, they thought, regulators could make proposed rules more available and comprehensible to the general public and reduce busy work for industry attorneys and activists who spend hours parsing through regulations each day.
The technology team liked the idea and got to work, interviewing lawyers, bankers and other frequent regulations readers as well as regulation writers inside government. They also looked at private sector reading tools that manage large blocks of text.
By October 2013, the team had launched a pilot site, eRegulations, which allows users to navigate proposed regulations section by section and to pull up common definitions of regulatory terms alongside the regulation text itself. There’s one CFPB regulation up on the site now, related to electronic funds transfers, and the technology team is gathering feedback to figure out how they can improve the site before offering more regulations.
The tool even got a call out from the White House, which described eRegulations in its second set of commitments to the international Open Government Partnership as a model for making regulations more accessible to the public at large.
How was a small team, working part time, able to improve the way regulations are presented in just over a year while other government technology projects can take years or more and still be clunky or even useless upon release?
One advantage for the CFPB team was that the new agency actually has software coders on staff, an official said, so they could do most of the work in-house rather than farming it out to contractors. That meant the team could work more easily in short cycles of about two weeks, taking what they’d built out to the user community after each cycle and re-shaping their plans based on users’ feedback.
“Over time it’s evolved to where it is now,” CFPB Technology and Innovation Designer John Yuda said. “If you’d talked to us a year ago, we knew there was an opportunity to do something. I don’t think we would have necessarily been able to describe for you the tool that we landed on.”
That’s different from contracted projects where government officials must have a pretty clear vision before they begin so companies bidding on the project can give a clear accounting of their costs and approach.
“The way federal procurement works, it makes more sense to do more of the definition of the project upfront,” Yuda said.
This process of building software in short cycles is often described as agile development. The methodology is used throughout industry and has been praised by government technology officials, including Chief Information Officer Steven VanRoekel and Chief Technology Officer Todd Park.
Auditors say a more agile building process could save the government from costly failures such as the troubled HealthCare.gov launch in which the government received a final product with more than 400 software bugs. Under a more agile model, the argument goes, designers tend to find and fix small errors as they go rather than facing one massive failure at the end of the project.
The eRegulagions site got support from some of the 30 CFPB design and technology fellows participating in a two year program for tech professionals to build tools that help regulated companies comply with the laws CFPB enforces and to use data collected by the agency to help the public. Fellowship particpants also produced AskCFPB, a searchable library of more than 1,000 questions and answers about consumer products and services, such as credit cards, student loans and mortgages.
In addition to building eRegulations one piece at a time, CFPB developers also open sourced the project from the beginning, posting each new piece to the code sharing site Github. Sites like Github allow outside developers to study Web projects and to adopt or retrofit portions of them for their own use. The U.S. and Indian governments, for example, have open sourced the code for their open data sites, Data.gov and Data.gov.in, so other governments can launch their own open data sites without starting from scratch.
The CFPB tech team has briefed other agencies about eRegulations but no other agencies have committed to adopting the tool, an official said. If other agencies are interested in the tool, they might simply plug into the CFPB version or they could use the open source code to launch their own versions. In that case, CFPB might adopt and benefit from modifications they make, the official said.
“We have a policy that our custom development will be open sourced,” Yuda said. “The new approach to that over the last year is that we’re trying to start with open source from the beginning rather than developing something internally and then having to go back and make sure that we’re able to open source it. It forces us to be a little more careful and a little more buttoned up as we go rather than pushing that stuff off until the end.”
If CFPB goes forward with eRegulations, the agency will consider adding new capabilities users have said they might appreciate, such as the ability to add Web-based marginalia and other notes to personal copies of regulations and possibly adding a way for users to comment on proposed regulations directly through the application, an official said.
“Where it’s going really depends on what we hear from the public, largely from the compliance industry and other folks that have to use regulations on a day to day basis as part of their jobs,” Yuda said. “What we hear from those people will guide not just how we go forward with this but whether we go forward. If we hear it’s useful, then we’ll continue. If we hear that it’s not, then we have limited resources and we need to invest those in areas where we’re going to be providing value to the American public.”
January 3, 2014