Here are some news headlines that the governor of any state would like to trumpet: The state has slashed its wireless telephone costs by 25 percent. A new purchasing process has saved the state $62,000 in the acquisition of public-safety and police vehicles. Centralizing state agencies, such as human resources, information technology, state facilities, and legal services has resulted in cost savings of more than $3 million. A new program aimed at tax scofflaws has led to an $8 million increase in revenues.
These are actually some of the results of Governor of Rhode Island Donald L. Carcieri’s “Fiscal Fitness” program, also known as the “Big Audit.” Launched three years ago, the Big Audit was intended to be a far-reaching initiative that would cut costs, improve efficiencies and streamline the state government. Its mission – to establish Rhode Island as a model for the delivery of cost-effective government services to citizens who have confidence that tax dollars are being spent efficiently. One of the behind-the-scenes areas in which the Big Audit has had a big impact has been in the method used to develop software applications to meet business needs.
“The governor had a vision for a more effective and efficient government,” said Mark Treat, who, at the time, was the director of Rhode Island’s six-person project management office within the IT division. With 200 employees, the IT division is responsible for maintaining the information infrastructure, including networks, servers and applications, for the 10,000 or so state employees. Treat’s office was charged with the delivery of IT projects statewide, as well as facilitating the “change management” that was often an element of the project delivery. As a result of changes being implemented as part of the Big Audit process, IT project delivery is moving from what Treat described as a culture of surviving disappointed expectations to a culture of delivering significant new capabilities.
Launching the Big Audit
To conduct the Big Audit, a task force was assembled with representatives from across the state government. Individual teams were assigned to study specific areas. “They took people from one agency and had them study a related area,” Treat recalled. For example, within the area of health and human services, a person working in the mental health division might have been assigned to review the processes serving the elderly. In that way, the “audit” would be conducted by people familiar with the operation of an area, but not burdened by the need to defend the established way of doing business.
The individual teams looked at how state agencies were delivering services and generated around 450 ideas for improvement, ranging from reengineering business processes like licensing to improved signage.
The individual teams were grouped into “super” teams that reviewed all the suggestions for a specific area. The suggestions were then reviewed by the project management office, which had representatives from the major functional areas of state government: education, health and human services, public safety, transportation, natural resources, and general government. Finally, in conjunction with the mega-team leaders, the project management office prioritized the suggestions and sent them to the governor’s office.
An advisory board, whose members were drawn from the state legislature, directors of the major state agencies, and the major public employee unions, then evaluated the suggestions. “They provided input to the governor’s agenda,” Treat noted. Eventually, it was the governor’s office, however, that made the final determination of which project to tackle and when.
Application Delivery Process
As could be expected, many of the projects involved changes with the applications used to support specific processes. They required new applications to be built or new functionality to be incorporated into existing applications. But when the project management office, which had been created as part of the fiscal fitness program, reviewed the status of the software projects under development, it uncovered serious challenges. “We found that the division of IT had over 300 projects in some stage of development and a large percentage of them were struggling, behind schedule or over budget,” Treat said.
There was an immediate crisis too. On one project, after 18 months, the vendor responsible had been unable to deliver as expected and was released. “The project had a tight timeline and we were trying to figure out how to get the priority deliverables out of it,” Treat said. The project office investigated the root causes of the problems in application development and delivery. It identified several factors.
In general, Treat said, the state followed a waterfall approach and would eventually outsource an entire project for development. User requirements would be solicited and documented. Then a specialist would translate those requirements into a Unified Modeling Language and develop use cases. The business users would then review the work of the IT specialists. “Of course, many of our business users had no idea how to read UML, but after so much effort they would be pressured to agree that the documents met their requirements,” Treat said.
At that point, the state would put out a request for proposals (RFP) and the contract would typically be awarded to the lowest bidder. The entire procurement process could take 12 to 18 months and included a series of handoffs from users to analysts back to users for validation, to the vendor committee, to a scoring committee and then to the contract. “What you wound up with was a low bidder with poorly defined requirements that the users really didn’t understand,” Treat said. “All that time had passed and no value had been created. We had mis-communicated more often than not. Projects failed to meet expectations because the expectations were not clearly communicated.” The documentation process associated with the waterfall method, Treat observed, gave people the illusion of control of a project, but it was just that – an illusion.
Collaborative and Iterative
Faced with the need to salvage a specific project, Treat and his team opted to move towards a more collaborative and iterative process for application development, as well as what he called a staff augmentation approach. Dedicated teams of state employees would be assigned to a project and outside vendors would be tapped to supply the skills the team was missing. “Before, it was the culture to outsource entire projects and it would be the vendor’s responsibility to deliver the entire solution,” Treat said. “But, in reality, the state has to be actively and intimately involved. The state has to define the requirements clearly and approve the deliverables quickly. It has to test and accept work completed.” On a typical project, those tasks could require hundreds or thousands of work hours that were not being well managed.
With that in mind, the state also decided to move away from anchoring projects around a massive RFP and adopt the principles associated with agile software development processes. “We didn’t adopt a specific agile methodology, but incorporated the guiding principles into the way we did our application development,” Treat said. Those principles included a focus on building software rather than creating documentation; creating frequent and rapid iterations of applications throughout the development process; individual communication rather than rigid, formal interactions; responding to change as opposed to following a plan; and building a collaborative relationship with vendors rather than focusing on negotiating contracts. “We started to breakdown the project into smaller pieces and make the process more iterative,” Treat said.
To achieve this goal, the state launched a series of training programs in which all the stakeholders – the business users, the IT staff, and vendor representatives – learned how to use modeling tools together as a team. Business users learned how to model their business processes and to work with data and process diagrams. “The communication was fast, because you could do it on a white board,” Treat said. “You could validate and test the models and get very rapid feedback. And you could communicate so much more with pictures and diagrams.”
Interestingly, business users enthusiastically embraced the approach. “A lot of people are in state government because they believe in the mission of their organization,” Treat said. “They want to help the elderly or the environment or children. When you give them the power to enable these things, they get behind it because it will have an impact on the cause they believe in.” Before long, a broad range of business users were using very sophisticated modeling techniques.
Once the models were developed, they would be handed to development teams. Then, working with commercial business process modeling technology (BPM), the teams would prototype and configure the applications. “BPM was the enabling technology,” Treat said. “BPM lets you visually model a process and turn it into an executable application. You can then measure it against the process that you defined. It gives you an environment in which you can rapidly prototype and show the prototype to the users rather than a big UML document. Users can see what they like and don’t like and the developers can iterate on that.”
Cultural Change
The shift in the application development process was not without its challenges. While business users eagerly embraced it, some members of the IT staff were not as enthusiastic. “It involved new technologies and new ways of doing things,” Treat said. “And change is difficult.”
Nonetheless, the new approach dramatically improved the level and quality of communication between IT staff and business users. Business users, Treat said, “could speak the language of IT. The state manages a tremendous amount of information. For business users to be able to use the proper terms for data structures and data models, and to understand entities, attributes and concepts of normalization – it was empowering.”
Indeed, Treat said, in his view the improved communication was the most significant result from the change in process. “Rather than through Word documents and written requirements, we moved to diagrams and pictures,” Treat observed, which could much more clearly and concisely convey the necessary information. The communication was fast; the feedback was rapid and progress towards goals could be measured in weeks rather than months or years.
Measuring Success
The state is now applying the new application development process to many applications, including permitting, licensing and invoice payments. Other targets of opportunity include claims processing, case management and administrative workflow. “A lot of things become a ‘case’ in state government and BPM is terrific for case management,” he said.
Though just in the early stages, success will be measure in two ways, Treat said. Government services should improve. It will be easier for constituents to complete a transaction, open a business or get a license. Second, state agencies will be able to better fulfill their missions and real cost savings will emerge. BPM, he said, will be supported by a shift to an underlying service-oriented architecture, enabling integration across agencies and systems. “There will be a huge payoff over a long period of time,” Treat said.
