Almost all of today's government IT projects are managed using outdated development methods. Governments often believe that they must use a 1990s-style, waterfall-type development approach that involves a tremendous amount of upfront planning and the involvement of a large number of committees and MBA-type individuals. But there is another way. South Bend, Ind., for example has recently undertaken two significant IT projects, one of them using a traditional approach to IT development and the other using modern "agile" development methods.
Want more management news and commentary? Click here.
CSONet, a sewer monitoring and optimization system, was started as a research project at Notre Dame University and developed over six years in close collaboration with the city of South Bend and IBM. Traditional upfront planning, outside consultant engagements and a $6 million budget flowed into CSONet. Sewer projects are rarely exciting, but the CSONet project expanded sewer capacity in a way that allowed Mayor Pete Buttigieg to cut $100 million in future construction costs-a large and exciting outcome for a city with only 101,000 residents.
In contrast to CSONet's traditional development pattern, City Voice, a mitigation platform for abandoned and vacant buildings, was developed by South Bend in partnership with Code for America using modern agile methods. At a cost of only $250,000, the city rapidly iterated through a number of ideas and projects and in less than six months launched a public-facing website that incorporates advanced technologies such as interactive voice response and real-time mapping.
While both IT projects have been successful for South Bend, the costs, times to delivery and the processes used to deliver them differed greatly. How can cities like South Bend deliver a vibrant new Internet service to their residents in less time than it takes many organizations to run an RFP process? The answer can be found in a willingness to understand and utilize new development methods and an acute awareness of the political environment around today's IT development.
Government software development started in-house, as that was the only option before the emergence of today's solution-provider environment. As IT adoption grew across the country, providers developed platforms and bundles that allowed governments to apply a product-adoption mentality toward software. IT departments were retained, but in-house development was largely abandoned.
That's changing. Today, says Chicago Chief Information Officer Brett Goldstein, "there is a balance of in-house development and outsourced solutions" as more governments seek to match the IT project under consideration with the appropriate development method. Critical infrastructure such as CSONet will likely continue to be developed or adopted as it has been in the past using traditional methods. In contrast, IT projects that can be undertaken using new methods, or that are viewed as custom, unique differentiators, will be great candidates for newer, more agile development methods.
No IT project, of course, is without political risk. Traditional project development, played out over years with costs that go from millions to even billions, is often a more comfortable development pattern for government leaders, since plenty of upfront planning, documentation and committee sign-offs allow blame for failure to be understood and widespread. While agile development may deliver an ultimately successful project quicker and at a lower cost, it also may also stack up a number of failures along the way that could produce political headaches for administrators and elected officials.
The culture of agile software development also may clash with internal cultures. Employees, supervisors and departments likely will not be used to working with software that is initially problematic and undergoing rapid iterations and improvements. Stakeholders new to agile development may be confused and concerned by the lack of upfront planning and involvement. The upside, though, is that if agile development is undertaken with strong leadership, it can change the way business is done inside an organization. In South Bend, Kathryn Roos, the mayor's deputy chief of staff, reports that, after the City Voice agile project, many other departments now want to learn and undertake agile projects of their own.
For a government to fully consider agile development on an IT project for the first time, some upfront work must be undertaken. Educating staff and stakeholders about the agile process, its culture, the methods it follows and how the failure rates and costs compare to traditional methods can be a significant undertaking. Successful agile development also requires a caliber of software developer not often found in government organizations today. These individuals can command six-figure salaries for non-management positions. Evaluating whether a government could undertake hiring such individuals and successfully attract and retain them will be significant hurdles for many organizations.
In the end, what's likely to happen is that, as Chicago's Goldstein suggests, governmental units at all levels will adopt a hybrid approach and figure out what systems to develop internally using agile methods and which to outsource or develop through traditional means. Citizens will be better off as more IT services get adopted because governments' productivity goes up and the level of responsiveness increases. What's for certain is that the world of government IT is about to change, and for the better.
