Crafting a Theory of Change for Digital Transformation in Government

← Back to Main Project Page

This essay is part 1 of 2 in the Digital Service Network’s series on theories of change for government Digital Service teams. In it, we break down the component parts of a sound, explicit theory of change for digital transformation in government, and feature advice and experiences from practitioners in the field. You can find essay 2 in the theories of change series here.

Without a theory of change, there’s no structure to what you’re trying to achieve. A team needs one to move in a coordinated fashion – it’s critical. I can’t imagine what our team would’ve been like without our theory of change. It would’ve felt like we were just throwing things at the wall to see what stuck.

Stephanie Cain
Former Deputy Director, Colorado Digital Service

What is a theory of change?

A ToC is a clearly articulated strategy of how an individual or organization expects to bring about a desired change in a particular context. In other words, it’s a theory of how and why an intervention works.

The concept of ToCs was developed over the last several decades by evaluation scholars and has since been applied across a wide spectrum of domains. A ToC typically has three elements:

• A mapping of the current state,
• An articulation of the desired end state, and
• A credible set of casual mechanisms to get from one to the other.

Breaking down a sound, explicit theory of change

A basic ToC is a strategic tool that offers a principled way to choose and manage short- and mid-term efforts in order to generate a desired long-term outcome. A sound ToC—and, one might argue, a more complete ToC makes clear the assumptions underpinning it and dependencies along the path toward change. An explicit ToC is one that’s also used as a tool for communication and is commonly understood among relevant stakeholders.

A sound, explicit ToC demands specificity and openness about how and why you expect change to occur in a particular way, at a particular time and place. The DSN aims to support digital government practitioners in developing sound, explicit ToCs for digital transformation. Below, we break down the three elements of a good ToC, and along the way we provide perspectives from government staff in the field who do this work every day.

Element 1: The current state

What it is

The current state captures the status quo and maps the landscape within which a team currently operates to deliver digitally-transformed government services.

Why it is essential

A deep and nuanced understanding of the current landscape of services—and the people and processes in it—will help you later locate the assumptions you’re relying on and the dependencies in place when forging a path toward change.

How to craft it

The first task for a DS team is to document this landscape in terms of the issues that currently exist with digital service delivery. Through our research and engagement with DS teams, we’ve observed different kinds of issues these teams face, which we group into three high-level categories:

Your jurisdiction may or may not have these issues, or may experience them to greater or lesser extents. Within each category, DS teams can ask pointed questions to more precisely characterize the service delivery status quo in their jurisdiction:

Broken motivational layer:

• Who, precisely, doesn’t care? What would convince them to care— in other words, what’s their incentive structure and how does your team fit into it?
• If you’re asking someone to change the way they do their work, what’s in it for them? Is there trauma from past, failed efforts at reform? Is there limited exposure to new ways of doing things?
• How are responsibilities for the service in question distributed? For instance, are the people responsible for operating the service different from the people held accountable for its outcomes?

Broken informational layer:

• What service information is currently inaccessible or unavailable to residents?
• Which residents face these informational issues? Why?
• Who controls access to this information? What specific systems host this information?
• At present, how do these residents fulfill their informational needs in general?

Broken service layer:

• Which resident outcomes are not where they should be or where we want them to be? What services help shape these outcomes?
• How do people currently access and receive those services?
• How do staff currently administer those services?
• What systems underpin these services, and who’s responsible for building and maintaining them?

To answer these questions, you’ll need to hear from staff, electeds, vendors, residents, etc. and draw on your team’s collective experiences. Your team’s understanding of this landscape will inevitably deepen as it gets some projects
under its belt. This is a good sign: a strong ToC is iterated on and refined as new information becomes available. Because it’s a hypothesis, there’s no “right” ToC. Your first ToC won’t necessarily be your best, and that’s to be expected.

Our theory of change has evolved over time. In the beginning, the premise was that having a team that could attract strong tech talent into the state would lead to better outcomes with our tech products. That was true, but as we’ve grown as a team, we’ve spent more time evaluating the root causes that lead to so many public sector tech products not living up to what we hope they will provide to the public.

Matthew McAllister
Former Director, Colorado Digital Service

Early on, CDS was super focused on talent—get people in place, and that’ll lead to change. We tried a number of different talent plays. But we learned that putting people in place isn’t enough to cause change, especially if those individuals aren’t set up for success. Our approach became much more focused on the environment surrounding new talent, as we figured out which of our assumptions were
initially off and what we were depending on for success.

Stephanie Cain
Former Deputy Director, Colorado Digital Service

Element 2: The desired end state

What it is

The desired end state is the long-term outcome that DS teams drive toward. A strong ToC includes a specific, observable, and achievable desired end state.

Why it is essential

It’s easy to take the desired end state for granted because it may seem obvious that everyone understands they are working toward the same goal: better government services. But “better services” is a flexible phrase, and there are likely as many ideas about what it means as there are stakeholders involved in your work. It’s important to define “better” with a clear, tangible vision in mind, so everyone is on the same page. This is an invaluable opportunity to build a coalition around your team’s work.

Everyone on the team needs to understand the impact you’re trying to make—the “after” state you’re working toward. Will the impact be immediate? Will it impact some people more than others? Why? What will success look like? When will we be “done”? Use this and other information to prepare for the change you’re working toward before you set out to make it.

Shira Honig
Senior Data Policy Advisor, MCSS, Ontario

How to craft it

Your vision statement should be articulated in a way that, first and foremost, centers the needs of the people who use government services. But it must also take into account the needs and expertise of the staff who administer those services, as well as the priorities of your administration. The needs of many stakeholders must be kept in balance when articulating your team’s desired end state.

This may lead a team to craft an end goal that’s quite broad, so that many stakeholders can see their priorities reflected in it. But teams should avoid being overly general: your end state should be specific enough that you can clearly identify what needs to be done to achieve it, build consensus on how to prioritize resources, and figure out how to measure success.

Teams can achieve this by teasing out larger, fuzzier goals (e.g., “better government services”) into smaller, specific
parts. This process will benefit greatly from the landscape mapping necessary to define the current state for your ToC.

Maybe there’s a set of observable qualities that your team and stakeholders believe all services should possess—simple, efficient, accessible, equitable, etc.—that you define in terms of a modern, digital experience with government services. Or, your team might have a legislative mandate that serves as the foundation for your desired end state.

One thing we’ve asked is: ‘What type of change are we trying to create?’ There’s one kind of deep change you might bring about if you work with an individual department on a specific project. There are other kinds of changes that might touch everybody across the state, but which might be shallower.

Stephanie Cain
Former Deputy Director, Colorado Digital Service

Element 3: The causal pathway

What it is

The causal pathway is a course of action that a team believes—based on specific and contextual evidence—will bring about the desired end state from the current state.

Why it is essential

A strong ToC needs a clear path toward success that’s informed by context-specific evidence to suggest that path
actually exists. Generating this evidence helps prevent mistakes and avoid unintended negative consequences.

How to craft it

First, focus on the outcomes—short, intermediate, and long-term—that must be achieved along the way toward your desired end state. Define how you’ll know each intermediate outcome has been achieved—each step toward the end state should be observable. Then, focus on the interventions your team will make and the levers you need to acquire and pull to achieve those outcomes. This process doesn’t need to be linear.

The result should be a domino effect of sorts—a series of interventions linked to resulting outcomes that ultimately
lead to your desired end state. Again, you should iterate on this path over time as your team’s knowledge matures.

Be rigorous about interrogating the assumptions and dependencies inherent in the path you’ve built to ensure it’s
realistic (not miraculous).

Questions to repeatedly ask are:

• In order to achieve this outcome, what do we need to accomplish first? Whose cooperation will we need? Why do we expect them to cooperate with us?
• What does our plan depend on? Are these dependencies within our power to accomplish? If not, who or what do we need?

You might look to emulate the paths other teams have taken; but again, be rigorous in doing so. Don’t just copy and
paste because you’ve seen another team achieve success—map out their approach against your own current and desired end states (you didn’t do all that work for nothing!) to assess whether the preconditions for their success hold true in your context.

The changes we’re going for and the broader context of the state helps us decide tactical things like, for example, are we going to try to set up a single technology project for success, or are we going to provide training in Agile for the entire state? Our theory of change helps us decide which lever is the right one to pull at any point in time.

Stephanie Cain
Former Deputy Director, Colorado Digital Service

One of the first things to do when creating a theory of change is find out what people’s fears are, where their priorities lie, and what pain points they face, so you can align your theory of change with those factors. Think about change from a user perspective. This includes people above you, below you, and maybe even to your left and right. […] Don’t forget about the folks on the other end of your change.

Shira Honig
Senior Data Policy Advisor, MCSS, Ontario

Kick-start your team’s theory of change

Building a ToC isn’t a task a new team needs to do on day one. A strong ToC requires some homework, like the
landscape mapping and relationship-building discussed above. You will already be doing a lot of that work as your team selects and starts up its first projects.

Digital Service teams need to recognize when they’re in a place to put a line in the sand and say “this is what our theory of change is” and when they need to be in a listening place to figure out what that theory of change should be. If you put that line in the sand too soon, it won’t have the same gravitas as if it were fed with actual data and lived experience.

Stephanie Cain
Former Deputy Director, Colorado Digital Service

After a few months, a newer team will be ready to start crafting its first ToC. A more mature team is likely ready to start the process right away. Whether your team is ready to start immediately or in the coming months, when you launch your ToC work you should include your whole team and plan to spend about:

• 2 hours mapping its current state
• 1-2 hours articulating its desired end state
• 3+ hours plotting and assessing a casual pathway

Depending on how you’re able to structure your time, these steps could be completed in a single day. Revisit your
team’s ToC a few times a year to update and refine your thinking.

People come into government because they want to create “impact.” But that term has become cliche. What does it even mean? A theory of change can help you show what the impact of your work will be. It helps you move beyond the impact as a buzzword and arrive at impact in a tangible way.

Justin Elszasz
Former Chief Data Officer, Baltimore