Six common government IT anti-patterns and how to fix them


An anti-pattern is a common but poor solution to a recurring problem.

Think of it in terms of this old joke: During an annual physical exam, a patient gestures and then says to the doctor, “Doc, it hurts when I do this.” The doctor replies, “Don’t do that.”

This old joke parallels many conversations I’ve had with executives. Their organizations often have the habit of doing or requiring some activity that causes serious pain for the people involved. So, with that old joke in mind, here’s a list of six anti-patterns you really ought to stop doing, and what you should do instead.

Anti-pattern #1: Strategy by IT vendor selection

Simply implementing certain technologies isn’t going to be enough to succeed in a world that is becoming more transformed every day. “Digital” is a comprehensive shift that touches every aspect of the mission, from leadership style to services to the value chain.

Instead, refine your business model to anticipate and leverage leading edge digital trends to enable the mission. Align with stakeholders on a shared digital narrative for personalized citizen experiences, proactive decision making, straight-through processing, real-time automation, and journey-focused innovation. Say “No!” to things that don’t fit the narrative. Now you’ve got a strategy.

Anti-pattern #2: Putting IT changes into production outside of regular business hours

Typically referred to as code freezes, change freezes, or black-out periods, these actions are typically under the control of inspection processes and change control boards that push paper and hope to catch failures.

However, if a system is so fragile it can’t absorb a change predictably, the problem isn’t the change. The problem is the fragility. Coddling the system won’t make it any less fragile.

To address this, start by applying a minimum of 20% of the system budget to reduce digital debt. Part of that work will include automating testing and promote-to-production activity. Once the system is stable under change, make it a standard practice to move changes into production during regular business hours.

Anti-pattern #3: Running at release N-1 or older for more than 12 months, for on-premise implementations of COTS/GOTS applications

This practice was once an accepted way to minimize the risks associated with new releases. Now we know a wide range of risks come from old releases; new releases and patches mitigate the risk of old vulnerabilities.

Forget releases. Forget patches. Forget on-premise software entirely. Consume Software-as-a-Service. You’ll always enjoy the latest functionality and the protection of the latest security fixes.

Anti-pattern #4: Using management consoles / engineering consoles to provision, configure or tune resources

If you’re using a console you’re performing a manual activity. Manual activities generate errors, delays and cost.

Instead, use scripts to provision, configure or tune resources. Put installation instructions in YAML files, not Word/Excel/PowerPoint files. Build libraries of scripts in repositories like GitHub, Ansible and Jenkins. Reuse proven scripts at every opportunity. ‘Just say no’ to consoles.

Anti-pattern #5: “But wait, first we need a taxonomy before we ask anyone to capture information…”

There are a couple of problems here. First is the phrase “But wait, first.” Taxonomies are typically created by architects, which is to say people infatuated with architecture. Architects want to detail things to the Nth degree. Then, they apply criteria similar to that of a mathematics test: is it correct and complete? It takes forever to create a taxonomy. That makes it a poor activity to put near the beginning of the critical path.

The second problem is that citizens/consumers are just not interested in your organization’s taxonomy; they each use their own vernacular. And as your employees go about their day-to-day knowledge work they use whatever terms come to mind immediately. So, the taxonomy sits idle.

Here’s how to use taxonomies successfully: Keep them off the critical path of any project. The question shouldn’t be about whether the taxonomy is ‘correct and complete’, but rather if it is useful. Don’t tell users about taxonomies; instead tell app developers to use taxonomies solely to define data and data exchanges between systems. Apps developers are trained to apply taxonomies. They’ll get it right.

Anti-pattern #6: FAR Part 15 with Statements of Work (SOWs)

When dealing with innovation or digital transformation, or acquiring IT in general, avoid FAR Part 15 contracting at all costs. There are several problems here. FAR Part 15 typically drives a timeline of 18 to 24 months which is roughly equivalent to the lifespan of a typical consumer-oriented IT product, and twice the lifespan of a consumer-oriented IT service. By the time the solicitation is released, the technology has completely changed.

A related problem is with the use of a Statement of Work (SOW) to describe the government’s need, or what acquisition professionals call the “requirements.” SOWs tell IT companies how to do something not what needs to be done. Making SOWs prescriptive forces you to guess at what you’ll need in the future, then live with the results whether you guessed correctly or not. SOWs don’t allow for designs to evolve based on user feedback.

Instead, use agile work methods. They focus on discovering a solution to a problem after the contract is awarded, rather than specifying the detailed solution up front as with Part 15. An agile contract focuses on problems and outcomes, often using Product Backlog Items that describe high level contract delivery areas.

Following recent Office of Management and Budget and Office of Federal Procurement Policy, stop using SOWs and shift to using a Performance Work Statement (PWS) for acquiring services. A PWS states requirements in terms of results, rather than methods. Also consider taking advantage of the Agile Contract Format (ACF), with Statements of Objectives (SOO). SOOs make it much easier to write solicitations that center on outcomes instead of process. A SOO is a summary of key agency goals, outcomes, or both, that is incorporated into performance-based service acquisitions so that competitors may propose their solutions, including a technical approach, performance standards, and a quality assurance plan based upon commercial business practices.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: