Four planning rules to avoid project disasters

Please note that this post is from 2012. Evaluate with care and in light of later events.

One key reason to study history? To learn from the past:

1. Take small steps.
2. Favor reversibility.
3. Plan on surprises.
4. Plan on human inventiveness.

James C. Scott presents these four rules in his book, Seeing Like a State, a 1998 exploration of the history of major failed state projects (like Soviet collectivization and Tanzanian forced villagization). His work focuses on the necessary (for failure) intersection of state’s seeking to order a society, a “high-modernist ideology,” the existence of sufficient state power and an authoritarian desire for control, and a civil society that doesn’t resist.

But what does this have to do with your latest project?

Even if you aren’t planning a major state project, Scott’s advice is remarkably useful for anyone:

First, take small steps.

Scott suggests a humble approach: “presume that we cannot know the consequences of our actions in advance.” To deal with this ignorance, take small actions, then step back and observe the result. If you’re moving everyone in your company to Google Docs, try a pilot project first and see how it works. If you’re moving all your servers to the cloud, try doing it system-by-system (or some other smaller unit), rather than all at once.

Second, favor reversibility.

Remember, writes Scott, “Irreversible interventions have irreversible consequences.” If you’re switching to a cloud environment, consider keeping your old servers around for a few months, just in case you need to roll back. If you’re launching a new site (perhaps in an A/B testing fashion for a pilot group), don’t destroy the old system — just in case. For programmers, Git and similar version-control systems are key to this process — and non-programmers can leverage the same idea in other contexts.

Three, plan on surprises.

Given a choice, “[c]hoose plans that allow the largest accommodation to the unforeseen.” If you’re planning a farm, choose and prepare land that can support a variety of crops. If you’re building an API, allow for flexibility in use — don’t try to lock developers into on way of doing things — APIs like JSON, for example, can be accessed by a wide variety of programming languages, and allow for much wider developer base. If you expect a maximum of 10 API calls per day per developer — make plans to handle 10,000, just in case. Cloud computing excels at this kind of surprise capacity scaling.

Four, plan on human inventiveness.

Expect that future participants in your project will be smart enough to improve what you’ve done already. Whether your building out an agricultural water supply or creating a blogging platform, expect a dynamic future. Humans don’t just sit around and use what they’re given — they tweak it, fiddle with it, hack it. You can try to get new laws passed to limit this (hello, Hollywood), but human inventiveness is a powerful force. Use it instead of fighting it.