A Chartering Journey

Member Submitted

create their own personal version. These multiple versions will seldom, if ever, match. The probability that everyone is moving in the same direction is minimal. The chartering process is a negotiation between all the parties leading to alignment, with the charter as the tangible output. Quoting my friend III, "If there is major difficulty in forming and agreeing on a Charter, imagine the grief that would emerge from plowing ahead anyway."

A project team is often so focused on day‐to‐day activities, they lack the time to look around and understand what effect the system will have on its environment–and the effect the environment will have on the system. Understanding the longer term objectives and defining the boundaries constrains the alternatives available for each project decision. A full understanding of the resources allocated to solving the business problem further refines these constraints. The constraints, however, are a liberating reduction of choice, rather than the strait‐jacket of micromanagement. Together, these components of the charter answer a need to understand the broader context of the project.

Finally, making the authorizing players explicit identifies where the team may look for guidance when faced with a decision. Additionally, it is clear to whom the team should escalate a decision when it is outside their chartered authority or responsibility. Sadly, I was involved in a large project for which the sponsor was either unable or unwilling to fully accept this role. This executive "in charge" very effectively disempowered the team by refusing to make decisions, or support those made by the team, leading to an expensive failure.

As a project unfolds without an explicit charter, several assumed charters will emerge. It is better to think about the issues at the beginning of the project, negotiating an explicit and commonly understood context. Does this mean that a charter is done once and becomes immutable? No–it goes through iterations as the team and the sponsor learn more about the project. As the world changes, it may create change in the context of the project. When this occurs, the charter evolves to reflect reality–publically, but prudently. Within the evolving context, the project team can make good decisions–more often leading to a successful result.

Returning to the scenarios above, how would things have been different with a charter?
In the first scenario, fully stocked with a clear vision and the principle that properly loaded trucks were more important than detailed accounting, the team could have understood that getting beer on delivery trucks would have to be more efficient for them to be successful. They would have directed their efforts towards solutions that improved the stocking efforts. Additionally, making the system boundaries clear would have demonstrated that inventory tracking was less important to the sponsor–or even outside the sponsor's intent for the project.

In the case of the electronic tax payment system, the sponsor could have made the team's efforts less taxing by making the objectives and resource limits clear. This would have highlighted the desire to get the system running correctly, while leaving better performance as a longer term objective. Obviously, the system had to perform adequately, but there was time to make adjustments as the number of payments grew.

So what have I learned on this chartering journey?
I have to admit that I occasionally forget about the importance of a charter. However, in my latest endeavor, my partners and I have saved a considerable amount of wasted work by looking to our very succinct charter when making important decisions. We've found that we spend less time and throw away less effort by remembering our charter and taking the

About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.