Government tech leaders can break the cycle of risk aversion by reframing project setbacks as essential learning opportunities that drive iterative modernization and cultural change
by Intelliworx
Few topics attract attention in technology circles like a failed IT project. In government circles, the fear of failure with technology projects is real. High-visibility government technology projects that fall short of promises earn negative news, commentaries, GAO reports and potentially congressional hearings.
The risk of failure is fairly high, too. By the government’s own accounting, its track record leaves a lot to be desired. As a result, it’s reasonable for a civil servant to believe that being part of a high-visibility IT project that fails will adversely impact their career progression.
This incentivizes the status quo and resistance to change. Silicon Valley recognized this problem – phrases like “fail fast” and “embrace failure” changed the perception of that word. Instead of viewing failure as a setback, they view it as narrowing the possible pathways toward a solution.
In other words, leading technology companies see failure as a learning opportunity. It’s a cultural phenomenon that breaks the cycle of finger-pointing, redirects an organization to view failure as lessons learned and leads to continuous iterations of improvement.
Below are five truths about learning from failure that leaders should strive to foster in government technology culture.
Stay in touch by subscribing to our email newsletter.
We will never share or sell your email address.
1. Think of “failure” in terms of learning
In the cybersecurity world, the mature response to a major breach is not to fire the chief information security officer (CISO) or the engineers involved, barring outright negligence. That restraint is a lesson baked into cybersecurity training.
There are two good reasons. First, they’ve learned an unforgettable lesson. Firing the leadership also “fires” the institutional knowledge they’ve just gained; put another way, it donates the most expensive training they will ever receive to their next employer.
Second, it may be the first time the team has employed the skills, plans and techniques for remediation in a real-world situation. Every training effort before that incident was for practice. During a breach, these professionals have learned what works and what doesn’t – and they are suitably motivated to make corrections.
Tolerance for failure is high in the cybersecurity industry because it’s not a question of if you’ll be breached, but when. The community starts with the assumption that its defenses will fail at some point – and those failures aren’t cast as collapses but as learning moments.
In government, we currently have the opposite expectation. There’s a big gap in trust at the moment, and the public expects competency, so anything less than success is maligned as failure. Changing this view starts by thinking of failure in terms of learning.
2. Failures in integration are breakdowns in discovery
Projects that do well in the pilot phase often run into unforeseen challenges when they try to scale in production. Integration is routinely cited as a common cause. There are some logical and technical reasons why integration is so hard for the federal government, but there are also some cultural factors too.
For example, a government IT leader once oversaw an effort to integrate two systems: “making system X talk to system Y.” The team had planned the cutover for months. Even so, a single task took longer than planned, and the work slowed to a crawl.
Mid-cutover, one of the junior engineers proposed a different approach. It meant more time than originally budgeted, but it looked viable, so the lead set the original plan aside and went with it.
Yet it would have been nice to have known about that obstacle beforehand. This is an example of a discovery problem, the root cause of which could be any number of factors:
- A lack of skills or experience on the team to identify the obstacle beforehand;
- Incomplete exploration of the requirements and technical specifications; and
- Inadequate engineering from the beginning.
Tech debt consumes upwards of 80% of the government’s collective spending on technology. When the GAO asked major agencies to name the legacy systems most in need of modernization, they came back with about 70. At least five of those systems are more than 50 years old, which means the people who implemented them have long since moved on.
There are going to be unknown unknowns in most government modernization projects. We have to put more emphasis on the discovery phase to avoid this trap. As they say in the carpentry trade, measure twice and cut once.
3. Requirements are hypotheses until reality tests them
Culture is also a prime reason why technical requirements are missed in the discovery. Federal IT leaders are under pressure to treat every requirement as knowable up front, when many of them can only be tested in the real world.
Why? Because it’s never been done before. No person or team has ever modernized an IT infrastructure with the scale and complexity comparable to the U.S. government. Simulations are run on partial data about how components and architecture actually work. Many of the challenges encountered are unknowable until deployment.
While we can and should be more rigorous in discovery and planning, we also need to be honest about our assumptions. That means documenting and communicating assumptions, so when we run into problems, in pilots or production, every team member knows to question the assumptions.
4. A surfaced problem is a solvable one
“Failure” isn’t the end of the line unless you stop trying. Every IT project, whether the focus is on modernization, integration or AI implementation, will hit some unforeseen barriers.
The shift we need is in the attitude towards those barriers: we should welcome unforeseen barriers because it means they’ve become knowable. We can analyze a known problem and solve it.
The solution is to account for these unknowns in the planning process. Iterative improvement has to be part of any modernization project. The larger the project, the more iterations will be required.
5. Every iteration ends with a review
Iteration doesn’t mean endless money and timelines. A thoughtful framework ought to account for pilots with increasingly larger production tests. Each test should have built-in review processes for learning and gathering the requirements for the next one.
This requires AAR levels of honesty. AAR stands for After Action Review and is a hallmark of military training. After an exercise, key leaders review the mission, objectives, and what went well – and what needs improvement. Candor is crucial to making this effective, so all ideas are welcome – and welcome without the fear of retribution.
High-risk and high-visibility IT projects would benefit greatly from incorporating AAR as key stages in a modernization project are completed.
Rather than failure, let’s call them lessons learned
The U.S. Army has a unique approach to “embracing failure” through the Center for Army Lessons Learned (CALL). Whereas an AAR can be conducted at any level and be formal or informal, CALL institutionalizes this process at a strategic level.
“CALL executes the Army Annual Plan collecting, analyzing, disseminating, integrating, and archiving lessons learned from tactical to theater/strategic levels. CALL researches root-cause analysis, defines trends/themes, coordinates with the lessons learned community of interest, and initiates product development.”
Maybe we need a CALL-like organization for the federal government’s efforts to modernize its IT infrastructure. An organization that collects, analyzes and disseminates knowledge gained from current projects is a proven way to transform “failures” into lessons learned.
The point isn’t to avoid failure, but to instead make it affordable: small pilots, a thorough discovery phase, and reviews that surface hard lessons turn each setback into the requirements for the next iteration.
* * *
Intelliworx has been providing purpose-built software to the federal government for 20 years and currently serves 40+ federal government agencies. The company is a certified service-disabled veteran-owned small business (SDVOSB) and is FedRAMP-authorized.
Contact us for a no-obligation demo.
If you enjoyed this post, you might also like:
SBA certifies Intelliworx as a Service-Disabled Veteran-Owned Small Business (SDVOSB)
