Larry Singer Over the last several years, information technology professionals have been required to deliver the mission-critical applications their businesses need to meet end-user expectations. In both the public and private sectors these high-profile applications have been large and complex, and they have utilized new, sometimes cutting-edge technologies. All of these application development efforts have shared one common trait: RISK. When the end user is anticipating something extraordinary from an information technology (IT) initiative, the risk is magnified even more dramatically. Studies have shown that a significant percentage of large projects fail to reach successful completion. In the private sector it is possible to gauge the risk in financial terms. If a private-sector project fails, the business can make rational decisions about how they are going to mitigate the risks by reinvestment in new projects or other post-failure alternatives. In the public sector, failures are trumpeted in the press, the subject of scrutiny in legislatures, and can result in ineffective implementation of critical public policies. The options to mitigate risks in the public sector must be part of planning systems up front, not after the fact.
Managing Risk There are different strategies to deal with risk. One common option is to transfer risk to a third party, usually a systems integrator (SI). The principle assumption behind this approach is that the SI vendor is better equipped to deliver information systems than state or local government employees. Sometimes this is true. But even if they have more skilled project managers and staff available, the SI vendors are subject to the same types of risks that afflict both public- and private-sector, in-house staffs. Many times, the SI vendors are forced to work in conditions that promote even more risk than the in-house team would face. In order to win competitive bids - where low cost is often the deciding factor differentiating equally qualified bidders - SI vendors make project assumptions that are based on best-case scenarios. They cannot afford to budget for rework when errors are identified, and they cannot afford to replace planned technologies with improved technologies that become available during the course of their projects. If they plan for these contingencies they price themselves out of competition. SI vendors compete for multiple opportunities across the country simultaneously, which promotes an approach that has them deploying the best of their teams to win new business, and the second or third teams to deliver the product. There is a sly joke in the SI community that goes something like "don't confuse winning with delivery." The fault for this approach is not entirely with the SI vendor. The public procurement system itself creates a situation where the ability to respond professionally to an RFP is valued higher than the validity of their approach to reducing risks of project failure. The most important flaw with an approach that is intended to transfer risk away from government personnel to a private-sector surrogate is that the transfer never actually occurs. The substantial majority of the risk always remains with the government. Contracts use vehicles like performance bonds and penalties to make it appear that the vendor has assumed the risk. But like private-sector efforts, the risk to the SI vendor is just financial. As long as the vendor has a number of different projects underway around the country, it can still remain profitable despite the inevitable individual project failures. The SI vendor is often able to mitigate even the imposed financial risks by disclosing project problems late in the project, when the government has little alternative but to provide relief to the vendor rather than risk canceling the contract and giving up the money and time already spent. If an SI vendor fails, the intensity of public scrutiny is still focused on the government officials charged with responsibility for the program. The people who ultimately feel the full burden of project failures are the stakeholders in the community who are anticipating improved service levels and more effective programs from their government.
Wisconsin's Model There are efforts under way around the country to mitigate risks that - combined with utilizing the skills of the SI vendor community and in-house staffs - seem to be quite effective. In Wisconsin, state CIO Mark Wahl is supporting Jean Hale of the Department of Employment Relations in dividing their statewide Shared Human Resources System (SHRS) into several smaller sub-projects. Wahl contends "we will show our ability to deliver this client/server project in a smaller, lower-risk portion before we proceed to subsequent phases. [Hale's] approach allows us to confirm and enjoy the anticipated benefits of the new processes and systems before the whole system is completed." With this approach, while the risk of project failure still exists, the scope of the risk is reduced. Another approach is to fully analyze the systems requirements and implement the system as a pilot, or prototype, prior to a full statewide, or enterprise, deployment. The risk of this approach, especially for a client/server-based system, is that the small-scale model cannot fully anticipate issues of scaling the deployment up to a larger network and higher transaction rates. The benefit of this approach is to confirm that the system, if deployed more widely, will deliver the promised returns on the investment. Usually the analysis and design portions of the application development process represent a small portion of the costs of a project, while they yield the majority of a system's problems and benefits. By tackling this portion of the development lifecycle first, the risk of deploying a poor system, or not meeting end-user requirements, can be fully mitigated. These last two options reduce risk by dividing a big project with high risk into smaller projects with reduced risk. Divide and conquer is a maxim that should be applied to any kind of large-scale project in the public sector where we simply cannot tolerate large-scale failures. Larry Singer - an industry expert on strategic computing - is a senior executive fellow in public policy development and management.
