Government agencies look to modernization to improve the level of service to their citizen stakeholders and increase the efficiency of their internal workers. The goal is to increase the capabilities of citizens while decreasing response times and costs. Modernization has the promise of bringing agencies up to speed but the result is often decade long programs that once completed, cost millions of dollars and leave the agency already behind the pace of technology. One hard to maintain monolith of software is replaced by another. Government needs to adapt a strategy of continuous improvement that aligns the needs of the users with technology decisions. Software systems need to be built that can be easily maintained and replaced without impacting the entire process. In addition, the walls that separate business and IT need to be broken down. The two groups should work together to identify where technology can bring the most value to the end user.
Utilize services to break functionality into smaller pieces that can be enhanced and replaced individually
Traditionally software systems were built as one large standalone system that could perform all the necessary tasks to conduct business. Over the past decade things have moved to more component based development where individual pieces are developed as standalone programs and then integrated. This allows organizations to choose the best solution for each business process rather than building something that can do everything just OK. This also allows organizations to make, build or buy decisions at a service level. In addition when a component needs to be replaced or updated it can be done without requiring the whole system be changed. This allows for continuous improvement to the overall system without large impacts to the organization. Agencies that are looking to modernize should be considering individual internal and external solutions that can be integrated rather than building one huge replacement system.
Iterative software developments allows small pieces of functionality to be released in a short time frame bringing quick and continuous organizational value
The traditional software development lifecycle often has requirements being gathered from stakeholders a year or two before code is released into production. This resulted in the final product no longer meeting the current highest priority needs of the business. In addition the cost of change within the project when scope did need to be adjusted was high. The Office of Management and Budget under the President has identified this problem and recommended that projects be broken into six month increments. An iterative software development approach allows for the focus to always be on the most pressing needs of the business. Small pieces of value providing software can be given to the users quickly. This will allow users and the business to provide feedback on what is really providing value and what needs to be changed. This approach also allows government agencies to quickly respond to legislations and requirements from changing administrations. No longer will millions of dollars be tied up in one individual program that we do not know will succeed until the end. Instead, agencies can see results in a short period of time and adjust priorities as the needs of the users change.
Break down the walls between Business and IT
Business and IT can partner to understand what the greatest needs are and how technology can bring about value. Often these two groups are kept separate and only come together during the initial requirements phase and during user acceptance testing. This can result in a product being built that does not meet the true needs of the business, but needs to be put into production to meet a deadline. The business is unhappy with the end result and IT is frustrated that time was spent building something that is not as beneficial to the organization as originally thought. When IT and business work together the result is not individual long projects, but continuous improvements through technology to the overall business process. Business owners are meeting with IT on a daily basis to discuss functionality and to communicate their true needs. Business leaders are able to provide objectives that can be measured against expected value once the product is implemented. Technical resources such as system architects and business systems analysts are working with business owners to show how technology can increase productivity and provide more functionality to the end user. The U.S. Government Accountability Office has similar recommendations for making sure end users and stakeholders are involved throughout the process. The result is an entire organization moving forward together.
User Adoption is an often overlooked component to releasing new functionality
Many times the consideration of the end user and how they will accept the change that is coming is left to the last minute. This results in hastily created training and communication materials and end users left fending for themselves in the new environment. Change mangers, including training teams, should be included early in the process so they can understand the impact to the organization and prepare the users. One way to get user feedback before a formal software release is to have a beta release to a small group of users. These predetermined users will be able to provide real world feedback on the software and allow adjustments to be made before the final release.
By adapting a component based, iterative software development approach, agencies can more quickly see benefits and set themselves up for continued success in the future without having to always replace giant systems as part of multi-year long programs. Integrating business and IT in the development process will lead to happier end users and less time wasted correcting issues caused by misinterpreted requirements. Agencies will be able to respond to changes in legislation and the needs of their citizens in time measured in weeks and months instead of years.