Immunizing Against Predictable Project Failure

When does a project really begin? Where can we point to the effects that the stewards of the organizational resources had hoped to achieve,after those resources have been spent? How can external observers determine after the fact that the project was successful? Who gets to say that the work is good and the effort may continue? Why do so many projects create so much difficulty for so many people and organizations?

A project is a finite undertaking with defined intentions and limited resources. It is different from a service or a product or a discipline or an occasion. It serves as a rallying point for two very distinct groups of folks-those who have responsibility for organizational intentions and resources, and those who practice their craft creating information capability to further the organization's ultimate purpose. In this discussion, I'm going to refer to the first group as GoldOwners, based on the 21st-century version of the Golden Rule ("Whoever Has the Gold Makes the Rules"), and to the second group as Developers.

In every system effort, the developers are spending money that belongs to the GoldOwners (or, if pronounced differently, the GoalDonors). In return for the use of resources, the developers are obliged to return some sort of value-added consequence to the organization.

This relationship is defined and developed through the use of Chartering and Charters. Chartering provides a mechanism for negotiating and formalizing the understanding between the two groups, and the Charter is the official container for the shared contractual agreement between both sides.

I dream of the day when senior business managers will walk into the office every Monday morning or so with fully-formed Charters already in hand. They will have sorted through the research, pondering, and decision-making to focus the attention of the organization and the development crews toward establishing expectations, aligning the perspectives of all involved players, and securing commitment for the successful completion of important work.

In the real world, the situation is quite different. Work often gets underway in the absence of an explicit contract, with predictable results. People launch off in various directions, with diverse and changing understandings, and time and money drift away-while informal chats try to determine the next best thing to do, and various individuals step up and do their best from private perspectives to keep everyone else's head above water. As we might expect, results diverge from expectations.

In far too many unchartered projects, the developers wind up in the gunsights of the money-spenders, taking the blame for any and all hiccups that unfold during the life of the project.

The Anatomy of a Charter
I use the following core content as the basis of a sustainable relationship between the GoldOwners and the Developers, as made visible in a Charter format:

1. Any Charter begins with a mission-the compelling summary of all the work ahead. 
2. Then we declare our objectives (the measures of project completion and system success). These measures include external objectives (the effects the GoldOwners really want, detectable outside the boundary of the system) and internal objectives (effects that are measurable outside the work of the team and that contribute to enhancing delivery capacity and capability). Note that if the development group operates on a for-profit basis these internal objectives would show up in other Charters. 
3. The boundary declaration is an explicit portrayal of what's inside the system (i.e., subject to the discretion of the team) versus what's outside the system (stuff in the rest of the universe that the team must accept and honor). It consists of the context diagram (a graphic picture of the target system as