Progress at the speed of failure

As consumers, it’s easy to see the quickening pace of technology at the world’s largest companies. It seems like every day there is a new way to use technology to accommodate our needs and wants, from controlling the temperature in our homes to accessing health records. And the speed at which technology is changing, growing and shaping our lives is accelerating more and more every day.

This application of technology would be a dream come true in government. Imagine the ability to adapt quickly to the needs of citizens, and even use predictive technology to make proactive decisions before problems arise.

We are on the cusp of this transformation in the public sector, but a cultural shift must occur first: The ability to accept — and even celebrate — failure.

The world’s most successful companies use failure as an opportunity for growth. In software development, we use a model of constant improvement — or agile software development — to make adjustments based on new information. We are constantly looking back at completed tasks and asking: how could it have been better?

For decades, progress in government has been hindered by the inability to make small, quick decisions and adjust later as needed.

It’s important to understand why failure has been such a frightening concept for so long in the public sector. Most government operations were formed in the post-World War II era of the 1950s and 1960s. Arguably during this “steady” era, the preferred approach to government was to gather as much information as possible, collaborate on a course of action, and make thoughtful big decisions. The impact was slow to come to fruition, but such decisions often remained relevant for decades.

Today, that approach falls short when the impactful relevance of any decision is rarely more than a few years.

The need for speed has been clear when it comes to matters of public policy. Look, for example, at emerging issues around drone regulation, whether or not to govern bitcoin, or adding digital security regulations to private companies. Speed, however, isn’t just a legislative matter — it’s vital in every corridor of government.

The new formula for success is making fast, small decisions with limited information, and making course corrections as realities unfold. In other words, the risk of becoming more agile is that there will be failures along the way, and that’s OK.

Cultural shifts are never easy and can take time to evolve, but there are steps you can take to apply agile decision-making in your organization:

Step 1: Choose a project

Especially in federal agencies, multi-year projects are quite common. From updating legacy systems to revamping a website, these undertakings are perfect for applying agile execution. But the project you choose for applying agile thinking doesn’t have to be large — it can be as simple as replacing an outdated process with a digital option. In fact, a hallmark of an innovative organization is one that is able to break monolithic goals into discrete, independent projects. It’s not easy, but it’s essential, and arguably is the most important success factor. Albert Einstein said it best: “Everything should be made as simple as possible, but not simpler.”

Make the goal of the project crystal clear, and that might involve clarifying what the project will not accomplish.

Step 2: Identify roles and responsibilities (and have a DRI)

Like software development teams, it’s crucial that roles for execution are made clearly established up front. Every participant needs to know their responsibility and the responsibility of the other team members.

One of the keys to success is to break the notion of a chain of command and the associated decision-making chain. Following an Apple model, every project has a leader known as the “directly responsible individual” or DRI. The DRI is hands-on and involved in every aspect of the project; the incumbent may come from any part of the organization and is rarely upper management.

Put bluntly, the DRI is the person on any given assignment who will be called on if something isn’t done right. The simple premise being if a single person is clearly and publicly assigned responsibility for a project, the project is more likely to be driven to a positive outcome than if the responsibility is shared by a larger group.

As a side benefit, DRI roles are highly visible and create opportunities for individuals to show their true potential.

The DRI is not a neutral project manager and is likely to have germane knowledge and experience, but some tasks require more than one class of expert. For example, a developer, a cloud engineer and a security professional might all materially and equally contribute to the success of a project.  In such a case, who would be the DRI? The simple answer is “it doesn’t matter.” Maybe the cloud engineer becomes the DRI because she has capacity, or maybe it’s the security person with a rich history on this type of project. Whoever is selected, the DRI must be empowered to celebrate failure along the way, and encourage team members to do the same. The best DRIs shield the team from over inspection and the consequential risk aversion.

Step 3: Divide progress into two-week sprints

A “sprint” is a term we use in software development that is a push for a finite set of outcomes, usually between one and two weeks in duration. This is a very specific and achievable set of objectives, and every day there is a team meeting (or “stand up”) to assess the progress toward the sprint goals. These meetings are short, no longer than 30 minutes, and people literally stand — a physical reminder to be brief.

Each person on the project covers three simple topics:

• What I accomplished since the last standup
• What I am working and will accomplish before the next standup
• What is getting in my way or blocking me from meeting my commitments

Government projects would benefit greatly from this model because it promotes full clarity, and allows for quick decisions on a tight timeline, forcing more agile progress toward the larger goal.

Step 4: Make room for adjustments

When a decision can’t be made due to fear of failure, everybody loses. This has historically been one of the greatest barriers to success in the public sector. Using an agile approach, which makes room for failure and quick pivots, is essentially a series of “small” wins building toward a larger overarching goal.

Throughout the project, the team should assess its progress toward the goals. If it’s a new software application, review it with the end users throughout the project, not just at the end. If its offering new services to communities, calibrate with members of the community throughout the project, not just at the end.

Calibrate often, and make room for mistakes, but remember that failure is an opportunity for growth.
Life is changing too rapidly to predict the future with any accuracy, but we know that technology is not slowing down anytime soon. As government embraces agile methods for execution, adopts tried and tested methods, and becomes comfortable with the notion of failure, we’ll start to recognize progress as often as we do in the private sector. Let’s start today, one project at a time.

Bob Ainsbury is a Silicon Valley technologist with roots in engineering and a rich history in high-growth companies of all sizes. He is chief product officer at Granicus.

Copyright © 2024 Federal News Network. All rights reserved. This website is not intended for users located within the European Economic Area.