12 Tips for Designing an Open-Ended Project

How do you tackle a large-scale, complex challenge that evolves over time, involves thousands of stakeholders, and where there is no clear solution? For example, is there a road map for how the Internet evolved? Could we do it again?

IBM Center author David Witzel examines the evolution of the Internet over the past four decades in a recent report, looking for lessons in the use of open project design that could be applied in other policy domains. He explores how a wide range of autonomous, overlapping and interconnected open projects initiated by government staff, techies, entrepreneurs and students around the world resulted in one of the most profound changes in society across the globe since the dawn of the Industrial Age. 

Traditionally, leaders use hierarchical “closed system” approaches to solve large, complicated problems. A closed project has a defined staff, budget and outcome, and uses hierarchy and logic models to direct activities. It is particularly appropriate for problems with known solutions and stable environments, such as the development of a major highway project.

But today there are instances when a problem is so complex, that it demands another approach. Witzel calls this an “open project” approach. An open project is useful to address challenges where the end may not be clear, the environment is rapidly changing, and/or the coordinating entity doesn’t have the authority or resources to directly create needed change. In these open projects, new stakeholders can join at will, roles are often informal, resources are shared, and actions and decisions are distributed throughout the system.

Witzel distills a series of tips for those who may want to use an open approach in other policy domains. A key insight underpinning Witzel’s tips is that this is not a precise methodology. Instead, an open project approach should be viewed as a mind-set. Leaders have to dis­cern whether the challenges they are facing can best be solved using a closed or open approach. If an open approach seems appropriate, then he offers a dozen design tips, based on his observations of the evolution of the Internet:

1. Let everyone play. The Internet grew up with a strong “do it ourselves” culture open to contributions from many players organized through an informal working group open to anyone who wanted to participate. Witzel notes: “Opening projects to more participants helps bring in additional resources, attracts advocates, and captures new ideas.”

2. Play Nice. Make it easy for people to participate. “A common mistake in collaborative projects is to inadvertently reduce participation by setting high walls to protect the project from low-quality contributions or vandalism.” Instead, make it easy to recover from damage rather than avoiding damage—like Wikipedia does.

3. Talk about what you are doing while you are doing it. “Participatory projects need to find open approaches to coordinate activities.” Narrating your work—by publicly sharing project details as you go along—is one way to do this. It results in trust-building and allows others to adjust their contributions as the project evolves.

4. Use multiple channels of communication. Internet pioneers used overlapping channels to communicate, since different contributors approached the Internet in different ways. It encourages more people to be involved.

5. Give it away. Creating widely available and reusable intellectual property was a key component for getting others to participate in the creation of the Internet.

6. Reach for the edges. The designers of the Internet decided early on to encourage and support activities “at the fringes” of their networks of projects. They saw contributions from the edges as a key source of innovation and feedback.

7. Make it work, then make it better. “When trying to engage and coordinate large numbers of distributed people and groups, simplicity matters. It makes understanding easier, eases learning and improves communication.”

8. Make it work, then standardize. “Much of what we think of as the Internet is really just common language—standards and agreements—to send and receive data or behave in a certain way . . . the goal of these standards was not to strictly define processes, but to communicate and coordinate.”

9. Take advantage of all types of organizations. “An interesting project is likely to require contributions from an ecosystem of government, nonprofit, business, academic and individual participants with varying interests and incentives.”

10. Design for participation. “Breaking work into manageable pieces” . . . modularity and granularity . . . “makes it easier for individuals or small teams to understand what needs to be done, spread their labor across activities, and clime the learning curve to become involved.”

11. Increase network impact. The ability to connect networks to other networks helps explain the power of Internet growth as an interconnected network-of-networks. “Increasing connectivity, connecting more groups, and increasing flexibility in defining groups will tend to increase value.

12. Build platforms. “Platforms are tools that help people and organizations coordinate their activities so they are jointly more productive . . . Successful platforms have a multiplier effect—the value they create comes from other projects.” Examples include the Apps store for Apple products—a shopping mall connecting apps developers and iPhone users.

Since Internet-like open projects are beginning to shape government and nonprofit efforts, it will be interesting to see how these tips stack up against actual experience in other policy domains. Previous IBM Center reports touch on such topics, and offer similar tips, or lessons:

• Managing Recovery: An Insider’s View, by Edward DeSeve (2011)
• Food Safety: Emerging Public-Private Approaches, by Noel Greis and Monica Nogueria (2010)
• Designing and Managing Cross-Sector Collaboration: A Case Study in Traffic Congestion, by Melissa Stone, Emily Saunoi-Sandgren, John Bryson, and Barbara Crosby (2009)
• Integrating Service Delivery Across Levels of Government, by Jeffrey Roy and John Langford (2008)
• Collaboration and Performance Management in Network Settings: Lessons from Three Watershed Governance Efforts, by Mark Imperial (2004)

(Image via hxdbzxy/Shutterstock.com)