The Need for Greater Technical Talent in the Government: A Case Study

Lessons from the software behind America’s immigration system show us why modern technologists, from product managers to designers, are needed in government now more than ever.

We know government tech projects often fail. Timelines get pushed out, contractors rapidly turn over, costs increase, and, ultimately, public services fail to meet the needs of the American people—often just as they need them most. One of the major reasons for these problems is that the federal government does not have the modern technical talent necessary to deliver large-scale IT programs that consistently work for the end user. This does not just include software engineers, but designers, researchers, and product managers too. In this case study, we’ll look at this issue through the lens of one of the most storied federal IT programs—the U.S. Citizen and Immigration Services (USCIS) Electronic Immigration System (ELIS). We found that the program had challenges with its technical talent through the burdensome, nontechnical oversight and the lack of technical expertise on the ground. This case study pulls information from 13 GAO and OIG reports between 2005 and 2021, as well as interviews with 6 current or former senior leaders within USCIS, with a particular focus towards the technical talent associated with the project.

DHS CIO performance ratings for the ELIS Transformation Program. Historical poor performance makes ELIS a clear example of a federal IT program with its challenges. (Source: IT Dashboard)

Background

The Department of Homeland Security (DHS) was founded in 2002 in response to the 9/11 attacks. This major government restructuring took agencies responsible for public security and put them under one roof. One of these agencies was Immigration and Naturalization Services (INS), which at the time was located in the Department of Justice. Under new DHS management, the benefits-focused components of INS became U.S. Citizen and Immigration Services (USCIS) in 2003. USCIS’ main responsibilities, set then and continued today, are to process and provide immigration benefits, visa or naturalization applications, and any adjustments of status (i.e. green cards).

Several years after its founding, USCIS set out to modernize their immigration application processes, which a 2005 OIG report called “primarily manual, paper-based, and duplicative, resulting in an ineffective use of human and financial resources to ship, store, and track immigration files.” In 2005, USCIS established the Transformation Program Office (TPO), later renamed the Office of Transformation Coordination (OTC), which was meant to serve as a centralized management structure for IT transformation and modernization. As part of the TPO, USCIS launched the effort to build the Electronic Immigration System (ELIS), named in honor of Ellis Island.

Now, more than 13 GAO and OIG reports later, the ELIS program is one of the most discussed government IT projects, and has historically been cited as an example of troubled government IT management and implementation (see the history of CIO performance rating in the image above). The original contract for ELIS, awarded to IBM in 2008, was scheduled to last until 2013 and cost taxpayers $500 million. However, GAO found in 2016 that the program was only processing about 31% of the total workload and had reported expenditures of more than $3.1 billion. While there are many reasons for these challenges, this case study will focus on one key problem: the lack of in-house technical talent. Through many conversations with leaders close to the ELIS project, we found this technical talent gap manifested in two key problems: mismanaged oversight from the top and a lack of technical expertise on the ground.

An example of an adjustment in the program’s estimates. Since its inception, the program has seen delayed timelines, increases in budget, and limited functionality. (Source: 2015 GAO Report)

Burdensome, nontechnical oversight from the top

The Problem

From its inception, the ELIS program had multiple organizations situated in oversight positions: TPO, the USCIS Office of Information Technology (OIT), and “the business” directorates representing the actual immigration officers that would use the system. ELIS was run by TPO, an organization separate from OIT. Within TPO, few, if any, leaders had expertise in software development—one of the TPO Chiefs was an accountant by trade. The TPO Office of Transformation Coordination (OTC) Chief reported directly to the USCIS Deputy Director, and sat at the same level as the USCIS Chief Information Officer (CIO), who was the head of OIT. This structure created friction in decision making, as one interviewee noted: “OTC acted like an independent body and made its own decisions about everything,” rather than working with OIT or the business. Because of the design of the organizational structure, technical leaders in OIT and front-line users in the business were not often fully integrated in decisions about ELIS. The lack of coordination between program management, technical leadership, and front-line users led to a lack of shared vision and purpose for ELIS. One interviewee noted, “If you asked TPO, the goal would be to transform the process from all paper to all digital. If you asked IT, the goal would be to replace old systems. No one thought about the customer angle or improving the effectiveness of our immigration system.”

Flat hierarchy with no clear ownership over technical programs. (Source: 2009 OIG Report)

The initial software releases of ELIS were unusable and broken. A 2014 OIG report found that immigration officers could adjudicate on paper at least two times faster than they could adjudicate in ELIS. As the system became more of a concern for USCIS and, more broadly, DHS, additional oversight boards entered the picture. The alphabet soup of offices, oversight boards, and leadership teams tasked with offering input on the project grew exponentially. Beyond the key stakeholders described above at the USCIS level, a 2009 OIG report describes one level up, “Oversight of the entire program at the DHS level falls under the authority of the Investment Review Board, the Joint Requirements Council, and the Enterprise Architecture Board, which approve or review key documents such as the Acquisition Plan, the Program Plan, and the annual Expenditure Plan.” Other oversight bodies continued up the federal hierarchy, including the DHS Office of Inspector General (OIG), Government Accountability Office (GAO), Office of Management and Budget (OMB) and Congressional committees, all with a vested interest in ELIS’ progress.

Burdensome oversight from every level of the federal government. (Source: 2009 OIG Report)

With over nine different offices and organizations providing oversight, all of which had limited technical expertise, decisions on the program took up significant time and energy. Utilizing antiquated processes that focused on budgets and timelines instead of technology, these oversight boards created additional roadblocks for the IT officials trying to build a functioning system. One example is the 424-page requirements document approved by DHS leadership that ultimately was described by a 2011 GAO report as “incomplete and vague”. Not only was the sheer number of oversight organizations problematic, but the lack of modern technologists in-charge led to project management and waterfall-based planning instead of product management and agile development. Ultimately, the process became bogged down by these bureaucratic hurdles. As a 2011 OIG report found, “Transformation leadership told us the governance structure was too complex and unwieldy, with too many stakeholders and boards involved in making decisions. Specifically, the transformation chief, transformation program manager, transformation IT project manager, and the USCIS Chief Information Officer (CIO) expressed concerns with the length of time it has taken to make a decision.” With too many nontechnical cooks in the kitchen, a disjointed vision, and cumbersome decision-making process, the ELIS program was inevitably placed in a fragile environment.

Proposed Solutions

Proposed solution 1: Put technical leaders in charge of technical projects

Oversight of government IT projects requires individuals with technical expertise who understand goal-setting, system design, and modern development for digital services. As we move into a software-based service delivery world, the technical expertise put in charge of these projects must understand modern and agile ways of working. Leaders and oversight bodies that emphasize outdated methods like waterfall development, a software methodology that forces a sequential flow and that was utilized in the early days of ELIS, will only contribute further to the delay and ultimate failure of government IT projects.

Proposed solution 2: Simplify the oversight hierarchy to increase accountability and streamline decision-making

With so many groups and organizations in charge of ELIS, it was difficult to determine who to actually hold accountable for the poor delivery. The complex governance structure also created an environment where the vision and goal for the project varied widely depending on who you asked. A simplified organizational structure, particularly with oversight, can help shorten the decision-making process and ensure that all parties (users, IT, and program managers) are on the same page. In particular, the oversight bodies that are charged with analyzing and addressing technical projects should themselves be technical experts.

Lack of technical expertise on the ground

The Problem

While technical leadership is important, it is also key to have the right people on the ground writing the code, designing the interface, and managing the technical architecture. As is the case with many government IT projects, the majority of folks actually building the software for ELIS were contractors. After IBM’s failed attempt as a single-contractor solution, USCIS adjusted the approach in 2012 to include multiple contractors, an approach USCIS called Flexible Agile Development Services (FADS). Over the next several years, the contracting group grew to include four different contracting companies and sixteen development teams composed of individuals from the various companies. The technical aptitude of the group varied, according to those we spoke to who were close to the project. Initially, most of the contractors were developers, business analysts, and scrum masters, with no designers or researchers on staff. One interviewee asked whether the companies “brought in the z-team” for ELIS, highlighting the variable quality among the firms. Another interviewee noted the focus was on “project management”, not “product management”—exposing a focus on timelines and budget, over delivery of quality services. The result was a group that was nearly completely made of software developers, bogged down by oversight processes, driven by schedules rather than by design, with no sense of how their individual work fit into the larger immigration service. One interviewee described it as a “factory culture” for code, as developers sat in independent rooms with no joint technical understanding of the end user’s workflow.

While a change in approach helped modernize the execution on the ground, there still was not an effort to increase the hiring of in-house technical talent. (Source: 2015 GAO Report)

In addition to the hands-on-keyboard developers, the Transformation program brought in contractors to keep other contractors accountable. Contract management for IT programs is not an easy task, especially when those individuals managing the contractors lack the technical expertise to hold the outside firms accountable, and so this is a fairly common setup in government technology projects. Nearly a dozen agile coaches and a dozen Independent Verification & Validation contractors were brought in to manage the development and perform quality checks, but the quality of the ELIS system still suffered. A 2006 OIG report described the problem, saying that “the most significant weakness was a lack of permanent OCIO [OIT] staff to manage and deliver IT services in support of the USCIS mission. Additional deficiencies involved strategic planning, IT security, program and contractor oversight, communications, training, and performance management.” In certain cases, the lack of federal technical management even led to a turning of the tables, with some interviewees describing how certain contractors with an outsized impact would tell the full-time federal employees what to do.

Proposed Solutions

Proposed Solution 1: Hire senior product managers, designers, user researchers, and software architects in-house

Technical talent does not just mean more software developers. To build a strong technical platform requires understanding product management, user experience, service design, data security, and system interoperability among other IT systems. The first step should be to flip the mindset from project management to product management, focusing on the users and purpose of the product. With a user-centric model, design and interoperability come to the forefront. The product will not work for the end user simply with good code. Full-time designers, user researchers, and software architects are necessary to ensure the success of such a large government IT project.

Proposed Solution 2: Improve contractor accountability by hiring and training technical Contract Officer Representatives (CORs) and rethinking the traditional requirements process

Contractors are still an important part of the federal government’s ability to quickly build and deploy software in support of service delivery. Moving forward, the government needs to instill more forms of accountability to ensure federal employees can make the most of the contracts and take the lead in developing such critical systems. For complex IT projects, the person directly responsible for the contract is often the Contract Officer Representative (COR). A first step the federal government could take is to hire and train more CORs with a technical background, such as is done through the DITAP training program. If a nontechnical COR is put in charge of a highly complex technical system, it’s unlikely that they’ll have the best tools to manage the contractors. Second, the standard requirements process that typically kicks off any government IT project is not built to support modern software development. Instead of starting with a rigid set of requirements outlined by nontechnical contracting officers, technical programs should continuously discover what to build through user research, orienting around a problem rather than a prescriptive set of requirements. The key to rethinking this process is ensuring that technical individuals are brought into the conversation early, as contracts are being developed. These discussions are often dominated by high-level program managers and procurement officers. A technical eye can provide expert support, such as by reviewing demos from contracting firms, broadly limiting the amount of “z-teams” brought in to work on critical software products.

Conclusion

While ELIS faced many challenges from 2005 to 2015, USCIS has made significant progress, and many excellent technologists contributed to turning the project around. The need for stronger technical talent in oversight roles and on the ground, however, remains. Of course, these points are not limited to USCIS, or even DHS. Problems with IT programs, such as those discussed here with ELIS, are pervasive and systematic across the federal government. According to an often-cited report from the Standish Group, government tech projects over $6M only succeed 13% of the time. While many factors contribute to the challenges associated with government IT, a stronger technical workforce would allow for more efficient oversight and more effective implementation. Fixing the technical talent gap may be more important than ever as the government seeks to modernize and address new problems such as cybersecurity, artificial intelligence, and the need for more immediate service delivery. Groups like the U.S. Digital Service,Technology Transformation Services, Code for America, U.S. of Tech, Coding it Forward, and Tech Talent Project are dedicated to bringing technical talent from the private sector to work on these public missions. As the government structures the next chapter of the federal digital community, we need to ensure technologists are brought into the decision-making early and often. A simplified program hierarchy will allow technologists to implement good processes and deliver programs on-time to the American people. Beyond the necessary software engineers, the definition of technologists must also include product managers, designers, user experience researchers, and software architects to ensure the product actually works for the end user and is interoperable across the agency’s technical ecosystem. Finally, as contractors represent an important part of the federal IT workforce, the government must improve accountability by placing federally-employed technologists in charge of the contracts.

By studying government IT failures and challenges, we can learn from our mistakes and create a federal technical workforce that improves the delivery of programs, creates new innovations, and, ultimately, builds a smarter government for the American people.