Program Design



While most government programs are built on long-established processes and protocols, yours probably has few blueprints to follow, if any. You will likely be drawing on sectors or areas of expertise that are not common in government programming. Even if you are starting with a concept that has been implemented in other countries, meeting your specific goals in your context will require significant design modifications. The following guidelines will help you develop a comprehensive, realistic outline for your concept from start to finish.

Remember: this stage is still about the theoretical program mechanics; concrete planning comes later. For now, your job is to make choices about the ideal form and structure of your program, while remaining agnostic to the inevitable constraints of time and resources—those will come soon enough.

You are at this phase if:

  • You have reviewed existing similar solutions (and ideally had conversations with their implementers)

  • You have an understanding of the legal frameworks and government protocols that may affect your program

  • You have official support to move forward with a program

  • You may not yet have a budget

Determine a Pathway to Impact

Everything you do should advance your program’s ability to achieve its target impact. To manage effectively, you must be able to understand how each piece of your program contributes to this goal, and in what sequence. A “Theory of Change” diagram can help you clearly map (and then track!) these pathways to impact. There are various approaches to creating a theory of change or mapping intended pathways; the most important thing is to lay out clearly the steps required to address target needs and arrive at the end goal.

Watch for your own assumptions.

Use your Theory of Change to spot areas of your program narrative that rely on assumptions. How does each step of your concept respond to the specific need you have identified? What makes you confident that each step will lead to the next? (And, what further inputs will be required to ensure that they do?) On what unstated resources, attitudes, or contextual enablers are you relying? Make adjustments when you spot a missing linkage between action and outcome.

Design Considerations in Government Innovation

As you create your Theory of Change, you will need to start narrowing down from the broad idealism of “government innovation,” which will mean calling out common assumptions. The following list will help you test a few of the common choices and tensions within government innovation programs, surfacing decisions that are best made early in the design process. These can be tough decisions, as each will require trade-offs, but establishing more realistic parameters for your ambitions at this stage will help you set up an implementation that shines.

Establish your non-negotiables.

Identifying the highest-value and “non-negotiable” aspects of your program design now will help you more easily prioritize and make trade-offs later on, during budget negotiations and program implementation.

Understand your value and capabilities.

Your unit has something of unique value to offer this program. Focusing on the inputs and activities that you are well-positioned to deliver will strengthen the likelihood of impact. And, perhaps more than anyone else, you must be able to rely on yourself throughout the program; being honest about your capabilities and values at this stage is essential.

Sample Theory of Change


Needs or Problems to be Addressed

  • Place the citizen at the center of policymakers’ considerations
  • Have an isolated space where new ideas can be born, nurtured, and developed
  • Infuse government with new talent and expertise
  • Make project development bureaucratically lighter, faster, more effective, and efficient
  • Have a continuous project design and implementation feedback loop

Inputs & Activities

  • Human Centered Design (HCD) methodology and mentoring
  • Political capital
  • Specialized human capital
  • Project budget independent from traditional allocation of public resources
  • Strategic advice, follow-up, mentoring, and public exposure for teams
  • Communications efforts


  • Five creative and unexpected tech-based solutions to long-standing problems
  • A “bubble” for the incubation of new ideas
  • A process of knowledge, problem-solving skills, and expertise transfer
  • Cross-cutting relationships that support the implementation of the National Digital Strategy
  • Extensive documentation and research, with communications to disseminate
  • Target users widely adopt the tech-based solutions developed by Innovation Agents teams


  • The Mexican Government becomes a platform for innovation. This means that:
    • Citizens can engage in sustained collaboration with government agencies to co-create and co-produce solutions that make more efficient use of public resources.
    • Government attracts the best minds from outside to work with insiders who have technical expertise.
    • There are increased incentives for government agencies to try new approaches and deliver results.
    • Government uses rapid prototyping techniques, and breaks with traditional bureaucratic processes for efficient project development.
  • External fellows have unique technical expertise that is difficult for the government to attract through traditional hiring mechanisms.
  • Internal fellows are knowledgeable enough to represent their agency’s perspective and needs.
  • Internal and external fellows will co-manage and spend time working together collaboratively.
  • There is effective knowledge transfer between the fellows and their teams.
  • Project teams will see value in and commit to the HCD process and carry it out as planned.
  • At least one project will be successful enough for the government to release and promote.
  • The program, and the projects it supports, can be sufficiently isolated from political priorities and external pressures.

When pushing bureaucratic boundaries in your program, there may be a tendency to put off reviewing the relevant legal and regulatory frameworks that govern how your program can be structured and executed. But open government programs are still government programs, and thus subject to all of the same regulations and protocols. Understand the letter of the law and comply with it. This will avoid unnecessary delays and risks, and later save you from having to expend energy catching up on compliance.

As you explore new territory, there will certainly be legal ambiguities (such as access to and use of open data) that may pose risks or challenges for your program. You may choose to push harder on the boundaries in some places, but lean in to ambiguities judiciously. Focus your reform efforts on places where it is most likely to bring significant benefits; stay well within the lines elsewhere. When an existing process is straightforward, ensure compliance—this helps cushion your program, so that you can assume the risks that are actually necessary (and that have the highest potential rewards).

Lesson Learned


Avoiding Innovation Orphans

At the end of the Innovation Agents pilot, lack of clarity around legal ownership and responsibility of the final products created challenges with (and even halted) their completion and public release. It also jeopardized their future. For example, one team released a functional prototype, but was unable to host the public-facing site on its servers, due to the risk of unauthorized access. Another team reached an advanced stage with its prototype app, but its completion and release was stalled in part because the hosting government unit did not have clear legal precedent or a documented responsibility to release and manage an app for citizens.

Carrying forward a new project requires resources, and without a pre-existing, clearly-defined mandate or documented responsibility, it may be difficult to identify an owner at a critical juncture. Establishing the frameworks for ownership and responsibility for every step of the program is vital in this early design phase.


Design an institutional legacy.

Because of the intersectional, multi-stakeholder, and boundary-pushing nature of innovative government programming, there is often no clear line of responsibility and accountability to maintain momentum around program outcomes once your official implementation period comes to a close. During the early stages, strive to establish an institutional and/or legal channel that will provide a home for the next iteration of your program and the lessons learned.

Develop your timelines

Your program’s timeline is a critical element of its design. A well-considered timeline will set expectations, help participants plan their commitments, and help you measure and share your success. Strive for an ambitious but realistic timeline. With any program, and innovative pilots in particular, there will be pressure to deliver outputs quickly. While you need to be ready to demonstrate “quick wins,” an overly grueling timeline will rob your participants of the ability to deliver well on a complex project. Conversely, an overly lax timeline may result in participants losing interest in even relatively straightforward tasks. Balance the pressure of deadlines with respect for the ambitious nature of your final program outcome.

As a rule of thumb for timelines, if you want participants to design, pilot, and implement a brand new product, you will likely need to provide at least 9 to 12 months. If your ideal endpoint is the development of a product concept or policy recommendation, the timeline could be as short as three months.

Lesson Learned


Conservative Project Choice in Light of Tight Timelines

One of the participants in Innovation Agents, an experienced social entrepreneur, was excited about joining as soon as he heard about it. He had an idea for a new platform that he felt was ideal for such an “incubation” type program. However, the original program timeline accounted for only six months of design and development and three months for a pilot implementation. Feeling that this was far too little time to bring his ambitious idea to its full potential, he nearly declined to participate altogether. In the end, he joined, but instead of incubating a brand new idea, chose to scale an existing platform. The aggressive program timeline meant a lost opportunity to support a potentially valuable *new *innovation.


Account for busy schedules.

Individuals and units that are motivated to participate in innovative new programs are typically ambitious. This often means that they have many other commitments to manage simultaneously. While these high-achievers will be largely self-motivated, their competing demands—and the frustrations of pushing boundaries to innovate within government—may sidetrack their focus on your program. Design your timeline with realistic and enforceable milestones and periodic check-ins throughout; these will help keep your program’s participants motivated to stay on track amidst already-full agendas.

Account for delays.

With their innovative, agile approaches, many open government programs can seem capable of the aggressive timelines that are more often expected in technology or private sector contexts. But such ambitious expectations are typically unrealistic. Open government programs are just as subject to the timelines of government bureaucracy as traditional programs, and sometimes even more so because lines of responsibility and decision-making domains aren’t clear. Often, there is no existing official process for approving certain activities, requiring you to first find out who needs to make a decision before you can move forward. This can further slow momentum and progress, so should be taken into account during timeline planning.

Lesson Learned


Uniformity of Requirements, Diversity of Participants

Although each of the five Innovation Agents teams was housed within different ministries and government institutions, they were all asked to follow the same timeline. Some offices found the program deadlines overlapping or interfering with other internal calendars.

The Ministry of Finance, for example, is completely booked during budget season. While the Finance team was scheduled to use those months to finalize a testable prototype of their project, they were unable to move forward due to other office priorities. On the other hand, the team working with the National Entrepreneurs Institute had an internal deadline that required a full public release of the project by January 1. In the original program timeline, this was the target date for launching “version 1.0” for piloting. The team struggled to follow the program as designed in part because they had more stringent timelines of their own. While timeline shifts are often inevitable, delays (or required advances) can be anticipated and accounted for in program design.


Define roles and target profiles.

People are the core to the successful implementation of any program. It is important to recruit strong matches for your team and—when you have the freedom to do so—your agency counterparts, with the appropriate technical skills, time availability, and (if needed) political position.

It is also important that each person on your team knows exactly what he or she is expected to do, as there may be overlapping responsibilities that could lead to confusion. Open government programs will be unfamiliar and may require your colleagues and participants to take on responsibilities or lead activities that are new to them. Bringing together individuals from inside of government with those from outside introduces potentially different expectations for what roles or titles entail. To mitigate the associated risks, you must clearly define all roles and target profiles for both the program implementation team and program participants.

Lesson Learned


The Complicated Team Dynamics of Driven Innovators

The strength of Innovation Agents came from the diverse expertise of its participants: Each core team included an internal government innovator, an external social entrepreneur, and a technology development team. Each of these roles was defined at a high level, but the specific responsibilities and expectations were never clearly established. While this was by some accounts an intentional choice to allow participant ownership of the projects, it also left a great deal of room for confusion and frustration as the teams worked through their collaboration dynamics. In two of the teams, disagreements about roles and responsibilities ultimately led to the original technology team’s decision to leave the project. This caused disruptions prior to and after the change, which might have been avoided with more upfront discussion.

Previous Phase:

Securing Political Support