If you are like me, you've been involved in a project that got off track. You may have even sponsored a project that delivered a different result than you intended. If so, please join me on my journey to learn how to mitigate, if not avoid, project teams and sponsors working toward divergent ends.
Scenario 1: The sponsor wants stout and gets light beer.
Long ago, I reviewed a project building a system to manage stocking delivery trucks with cases of beer. The new system was nearly unusable in the warehouses. Reasons included slow performance and too much data entry by the warehouse workers. It turns out that the sponsor's goal for the project was to make stocking the trucks each day more efficient. The system had become even less efficient than the existing process of filling empty space on the truck with whatever was lying around. Unfortunately, the development team’s goal was to more precisely track inventory in the warehouse.
Scenario 2: We may take payments incorrectly, but we can take lots of them!
A few years later, I led a team that delivered an electronic tax payment system. We projected that transaction volumes would grow slowly over time–with no payments even arriving on the first day. The peak volumes were months, if not years, away. More critically, the system had to be perfectly in balance every day by a specific time. As the initial delivery date loomed, however, a part of the team spent significant time, money, and effort, concerned that the system would not be able to perform under full load. This distraction delayed delivery to the test team, resulting in inadequate testing, followed by several preventable issues upon delivery.
What went wrong? In each scenario, the project team lost sight of the project sponsor's desires. A project team does not wake up one day and decide to deliver something other than what the sponsor and organization wants. They get to that point based on a series of smaller, isolated decisions that slowly steer the project in the wrong direction. What can we do to improve the chances that each small decision is correct?
Context comes from the Latin for "weaving together". Context is the setting or circumstance that brings together a set of events giving them meaning. A project sponsor cannot (and should not) be involved in every decision made on a project. The sponsor needs a mechanism to give the project team a clear sense of the context. The sponsor's best tool to establish the circumstances and setting for all the actions on a project is a project definition document, or "charter" (see below for an outline). Properly defined and communicated a charter "weaves together" all the specific decisions and actions.
The dictionary defines charter as being about authorization to proceed within certain limits and conditions. Charter comes from the Latin word chartula meaning document or "little paper"–it is meant to be a tangible artifact. A charter creates the foundation for every project decision. It combines a description of what the sponsor is trying to accomplish (vision and mission), the values (principles) of the organization, the target (objectives and boundaries) for the project, resources the organization is willing to commit, and the authorization to go forward with the project.
An effective charter is the result of negotiations between the person establishing the charter (the project sponsor) and the team carrying out the charter. It is a negotiated agreement, or commitment, between these two parties establishing the overall context of what the project is to accomplish. The charter, however, leaves open how the work should be performed. The choice of specific methods remains the project team's responsibility.
How does a charter help create context for decisions?
First and foremost, a charter is tangible–explicit and visible–to facilitate a shared understanding of the context established by the sponsor. If the charter is invisible, or tacit, each person on the project will mentally 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 most direct path to our objectives. I also find that reviewing projects has become easier. When a charter is lacking, I can quickly predict that I'll see inconsistent direction (and generally do). When there is a charter, I can immediately understand the context of the project and look for divergence.
For the relatively small investment in time, a charter is the best tool I've found to keep the context of a project in the front of the team’s mind. What better way to enhance the probability that daily decisions will add up to successful result?
