How an “Open Project” Approach Can Change the World

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 new 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 ini­tiated 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.

Open Project Design Lessons from the Evolution of the Internet.

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 to be followed. Instead, an open project approach should be viewed as a mindset. 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:

Tip One: 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.”

Tip Two: 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.

Tip Three: 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.

Tip Four: 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.

Tip Five: 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.

Tip Six: 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.

Tip Seven: 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.”

Tip Eight: 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.”

Tip Nine: 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.”

Tip Ten: 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.”

Tip Eleven: 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.

Tip Twelve: 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 – it’s a shopping mall connecting apps developers and iPhone users.

Since Internet-like open projects are beginning to shape government and non-profit 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:

Leave a Comment


Leave a Reply

Josh Nankivel

Thanks for this. Even for creating products that aren’t so large and complex, the open project (open source) model is powerful.

In general the constraints around closed projects and hierarchical management tend to discourage creativity and risk-taking.

Cutting corners is more likely than pushing the boundaries.

I think the hybrid approach that takes most of these tips to heart in a project with the normal constraints of budget and schedule is going to look a lot like Lean/Agile – and I think the project organization has to be as flat as possible.

The less hierarchy in a project, the better. That probably goes for organizations in general as well.