An Excursion into Government Legacy IT Systems - III

3.     Action Plan

3.1     OAI Project – “Government Systems 21 (GS-21)”

OAI will be the GS-21 Program Management Office (PMO). It is recommended that OAI start small – as the office gains confidence and direction, resources can be added. In the spirit of “eating one’s own dogfood,” the GS-21 PMO IT should use GS-21 to build GS-21.

Like any business, OAI will need a mission statement, quality policy, and charter. These are left as an exercise to the PMO to assure full ownership.

We again stipulate that, rather than seek off-the-shelf commercial products to meet government IT needs, OAI will follow a course of action that puts it in the position of smart buyer for the agencies. We further stipulate that the smart-buyer role will take on the look of general contractor, where OAI will use in-house and contractor resources to perform its functions.

3.2     Conduct workshops, open forums, and industry days

Several advantages accrue from stakeholders knowing what is going on, but a sense of being on the inside, rather than on the outside looking in, is one of the most important. We recommend that OAI invite leadership from various federal government agencies to describe their systems as part of initial GS-21 planning. Workshops should be open, goal-directed by the IPT, and well-advertised by OAI. Customers, potential (SETA) contractors, and vendors should be invited to participate. IPT representatives should be asked to describe the status of architecture and UI standards planning and workshop attendees should be asked for critical comment.

Rapid responses which show that agency input is central to OAI planning will help assure early adopters that GS-21 will benefit their agencies. Early adopters should be invited to join the OAI IPT.

3.3     Gather Requirements from agency managers and system users (customers)

OAI will gather and manage GS-21 requirements. This must be an open process and must be done carefully to assure coverage, allow for extensibility, and avoid requirements “creep” (the constant addition of new requirements which prevent goals from ever being reached). OAI will follow these guidelines:

·         Generate requirements in conjunction with early adopter agencies;

·         Benefit from accumulated agency-user wisdom;

·         Avoid pre-conceived, imposed solutions;

·         Avoid crony capitalism (arbitrary restrictions to the benefit of one company);

·         Consider all input to overcome internal agency resistance.

3.4     Market the Approach

As the GS-21 proceeds, marketing to agency heads, agency users, and the public must continue. This marketing must center on benefits already achieved and those planned, so that it conveys the progress of the effort. For OAI, inclusion is the key to getting the wind at their backs; marketing based on progress is the key to keeping it there. The IPT must be central to the marketing and should include the following:

·         Requirements management and refinement;

·         Progress as confirmed by Alpha and Beta testing;

·         Cost sharing with agencies - once cost savings begin to appear;

·         Experience sharing (among agencies).

3.5     Development

GS-21 development will ideally start small and grow as a dynamic, new company would. This will allow OAI to make sound technical decisions and to build the confidence, consensus, and momentum necessary to success. In the world of system development, motion is not the same as progress; it takes time to build working relationships and trust such that stakeholders are pulling in the same direction.

An Excursion into Government Legacy IT Systems - II

2.     Stakeholders

2.1     OAI

We stipulate that OAI will play the role of smart buyer of IT systems for the government. To obtain cost-effective results, OAI will need to understand agency requirements, vendor products and services, and program constraints (such as cost and schedule). In the role of smart buyer, OAI will perform these functions:

·         set GS-21 requirements in close cooperation with the agencies;

·         request contractor proposals for system engineering (SE) development;

·         request vendor solutions within SE guidelines; and

·         conduct integration, test, evaluation, and acceptance of proposed solutions.

Critical point: since a variety of risks – from discontinuity of service to perceived favoritism – would be associated with turning over responsibility for Government IT to a private company, short of revoking its own charter, OAI does not have the option of refusing the smart buyer role.

2.2     Integrated Process Team (IPT)

IPTs are widely used throughout industry and government because they raise the probability that all stakeholders have input to project decisions. This lowers the risk of omitting critical factors from consideration. The IPT will be under OAI supervision, but the full value of the IPT can only be realized if OAI is responsive to IPT guidance. That guidance must reflect the full range of stakeholder concerns.

2.3     The initial customers – government agencies

OAI will work directly with selected government agencies, and agency leadership, to set program goals, schedules, and cost estimates. A common source of resistance to a new system lies with the workers who must use it. However, when those workers are invited to apply their experience to the benefit of the system design, they are much more likely to become system advocates. Therefore, OAI will work closely with internal agency-system users to get their buy-in and have the “wind at their backs.” These are the natural roles for agency users in conjunction with OAI:

·         Define system requirements and User Interfaces (UIs);

·         Conduct initial (Alpha) testing and recommend refinement;

·         Submit trouble tickets as appropriate;

·         Participate in testing, evaluating, refining, and accepting the system;

·         Periodically review system performance and recommend changes; and

·         Train users and user-trainers;

2.4     The ultimate customers – the public

The systems of certain agencies, such as the VA and OPM, will enable public access; other agencies, such as DHS, may not. For the former, it will be important to assess the user experience. Public satisfaction may or may not be a driving force, but public dissatisfaction can destroy morale and progress. Therefore, the OAI must ensure that sufficient time and attention are devoted to introducing and monitoring system access by the public.

2.5     System Engineering and Technical Assistance (SETA) Contractors

While OAI is a government agency, many OAI activities will require specialized contractor skills. To avoid potential conflict of interest, SETA contractors who directly support OAI and the GS-21 program must be “fire-walled” from developers and vendors; moreover, they may not hold OAI management positions.

Since innovation is part of OAI, it is recommended that OAI use innovation in contracting. For example, rather than issuing Requests For Proposals (RFPs) which focus on price (low bid), OAI should strongly consider issuing RFPs which solicit innovative approaches to tasks which OAI has already priced according to their budget. This approach would have several benefits:

·         OAI would quickly learn to price tasks realistically;

·         Proposal emphasis would be on quality and job performance;

·         Proposers would be encouraged to organize personnel based on ability to do the job rather than on cost;

·         The fixed-price contract would not generate cost over-runs;

·         Companies would have strong incentives to improve cost-effectiveness since they would retain any savings as profit.

2.6     Vendors / Private Companies

The heavy lifting of GS-21 development will fall on private companies. They will be invited to participate in several different ways:

·         Participate in the definition of the GS-21 architecture and standards;

·         Develop a GS-21 integration, test, and evaluation (ITE) Facility; and

·         Offer artifact (hardware and software) to implement GS-21 requirements within architecture and standards guidelines;

·         Integrate, test, and evaluate prototypes in the GS-21 ITE Facility.

An Excursion into Government Legacy IT Systems - I

Abstract

The Office of American Innovation (OAI), chartered by the administration to pursue "excellence in government," has an opportunity to modernize government IT systems. These systems, used by agencies that the American public relies on, are old, inefficient, and costly to maintain. President Trump has said that the cost of preserving legacy computer systems is “so high, it’s not even a believable number.” The challenge of modernizing legacy IT systems is not new and, unfortunately, prior efforts have little to show for the money. However, this grand challenge must be addressed because we cannot afford to allow our IT systems to continue to degrade and user morale to continue to suffer. The public would blame current leadership for such a failure.

The good news is that it can be done; an agency of government empowered to undertake that mission - let's stipulate that OAI is that agency - can modernize legacy-IT systems by combining sound business practices with system engineering. The resulting IT systems must be consistent in their designs, easy to use, and capable of evolving in response to increased demand, extended functionality, and new technology. To turn this vision into reality, OAI will need to carefully partition the problem, define the roles of stakeholders, build an Integrated Process Team (IPT), and avoid the minefields that have derailed previous efforts. This White Paper describes a path to success.

Introduction

The Office of American Innovation (OAI), chartered by the Trump administration to pursue "excellence in government," has an opportunity to address challenges posed by government legacy IT systems (systems developed years ago which still run). This is the first of ten posts in a White Paper explaining how to modernize these systems. Failure is not an option; the costs are too high. Moreover, government cannot simply turn this complex problem over to private industry; the risks are too high.

The legacy IT problem is serious, but not hopeless. The problem can be solved using management skill and resolve, system engineering, and sound business practices. There is more good news: it is possible to build an effective government-industry team such that OAI has the “wind at its back;” and it is possible do this job at a reasonable initial cost, a prelude to major long-term cost savings.

1.     Scope

This white paper addresses modernization of legacy government IT systems. The new family of government IT systems will be referred to as Government Systems-21 (GS-21).

1.1     What makes government systems different from private-sector systems?

Why is the government-IT-system problem so hard and why can’t we simply turn this job over to a successful private corporation? The private sector provides several types of IT systems: consumer devices and host software; enterprise systems such as database management systems; and software as a service that resides “in the cloud.” Vendors profit from selling products and services to as many customers as possible. Vendors may upgrade products at their discretion, and while they have strong incentives to make their products both state-of-the-art and upward compatible, they are under no legal obligation to do so. Likewise, they are under no obligation to refine their products or services in response to the needs of any one customer.

By contrast, government is a single customer whose requirements reflect the needs of the public and are dictated by the functions of and legal constraints on their agencies (privacy, security, persistence, etc.). Government agencies have typically contracted for systems built to their own, independent requirements and specifications. This has resulted in a variety of monolithic systems which lack consistency among the various agencies and, since they are unique, require very specialized knowledge to maintain and modify. We propose a new generation of IT systems, GS-21, which 1) observe interface and data standards over time and across agencies, 2) give highest priority to security, 3) support one-time data entry, data consistency, real-time transaction-based redundancy, and (authorized) access to data across systems, 4) can evolve in response to increased user demand, extended functionality, and new technology, and 5) are responsive and resilient in the face of high demand and various threats.

While GS-21 will be developed using commercial technology, adoption of “off-the-shelf” systems is not expected to be a viable GS-21 solution.

1.2     Agencies

Many federal agencies and offices have their own IT systems. Those that do include the Social Security Administration, the Office of Personnel Management, the Department of Homeland Security (which has several), the Internal Revenue Service, and the Department of Veteran Affairs. A challenge for OAI is to provide incentives for candidate agencies to sign on as early GS-21 adopters. Those incentives include

·         gaining influence in the GS-21 community,

·         being part of the early expression of GS-21 requirements, and

·         becoming trainers for later adopters.

1.3     Challenges

One attractive feature of a new system development is that we can start small, like a small business. However, this convenience should not mask these GS-21 challenges:

·         To seize the opportunity by acting with determination;

·         To enlist agency users in requirements definition, UI design, and data specification thereby making GS-21 their system and making them GS-21 advocates;

·         To invest in System Engineering from the start; and

·         To favor technical and programmatic decisions over political decisions.