James Cook is Vice President at The MITRE Corporation and the Director of MITRE's Center for Enterprise Modernization. (Andy Cleavenger)
The technology industry continues to innovate at an ever-increasing pace, bringing new capabilities to market seemingly on a daily basis. Yet, government agencies struggle to successfully integrate these new technologies into their existing technical and business environments. This is partly due to budget limitations and other constraints, and as a result, there are many opinions about what is needed to overcome these various challenges and enable agencies to more consistently realize success in their IT projects. Personally, I believe many of the ideas being floated around are valid. But based on my over 30 years of experience, I believe there’s a fundamental question that isn’t often discussed, yet begs our attention: “Should the government be its own integrator?”
I know this question elicits very different reactions, but let’s consider it objectively. The federal government spends roughly $80 billion annually on IT, for hardware, software, and services. While much of this spending is for new investment, the majority is for operation and maintenance of the existing technology environment. When new technologies and systems are introduced, they must be integrated into agencies’ current IT environments without interrupting operations. It is this integration requirement that poses a key challenge: Without active government leadership and engagement, both technically and programmatically, the seamless integration of old and new systems cannot be done by outside contractors alone.
All too often, IT failures in the federal government are attributed to incompetence or poor leadership. But from my experience, the issues really boil down to individual roles and expectations. Is the government playing the right role relative to industry, and are the expectations appropriate, based on the information and access afforded to each?
To successfully introduce new technology and get the expected business value, I believe federal agencies must be resourced and able to do the following things:
Own the technical baseline — The technical baseline for any program is the primary basis for cost, schedule, and execution. The ability to predict and successfully perform is, in large part, contingent on the completeness, correctness, and stability of the technical baseline. From my experience, the government is best positioned for success when they own the technical baseline because predictably of cost is better, schedule is more achievable, and risks are more clearly defined, anticipated, and mitigated. To some degree, since the government is by definition responsible for the success of the program, many think it’s important that the government also be accountable for the technical baseline. From my experience, this is an important success factor.
Independently develop a basis of estimate (schedule and cost) based on the technical effort — Organizations that have assumed ownership of the technical baseline became better able to define scope and level of effort from a technical, process, and organizational perspective. This has resulted in greater predictability of cost and schedule, and greater ability to predict and mitigate risks.
Engage and enroll business owners as full partners — Organizations that have moved themselves into integrator roles have also adopted a joint governance and management approach where the business owner is a partner in the effort, not a customer. Joint business-IT led government teams (and Program Management Offices with senior IT and business owner leadership roles) help create enterprise ownership, better understand broader issues because they work the business and IT challenges together, and define/manage requirements, which is a key element in the baseline.
Establish clear outcomes and success metrics for contractors — Outcomes and expectations should be aligned with what’s reasonable. For instance, is it really appropriate to hold a contractor accountable for delivering an integrated solution if they are dependent upon changes to legacy systems which they don’t control or manage? Using this example, you might say this is proof that the government, by default, is the integrator since only they can address the legacy issues.
Understand and account for risks and “uncomfortable realities” — Recognizing, qualifying, and actively mitigating risk is an important part of success. Too often, optimistic plans, reports, and statuses are provided in spite of the obvious risks. Internal to agencies and in discussions with OMB and Congress, risks should be a welcome part of the discussion, a sign of a healthy and robust project management environment; they should not be treated as problems or issues. Implementing significant IT solutions into a large, diverse, and complicated legacy environment is inherently complex and risky. Any integrator will seek to identify the risks, acknowledge their presence and potential impact, and work aggressively to mitigate them. It’s important that agencies take this on, and that Oversight applaud this behavior and not penalize it.
In future articles, I plan on coming back to these themes, highlighting some useful cases, and exploring their broader potential applications. I hope these thoughts will be helpful and ultimately feed a broader discussion about how government can successfully play the integrator role, as well as uncover the types of investments necessary for them to do so. I’ve seen this work, and in those cases both government and industry have benefited from their mutual successes.