“Why are we doing this?”
“I’m not even sure what it is we’re doing.”
“Funny. We’re building the item.”
“Nobody seems to like it. Who are we building it for?”
“Stop being ridiculous. They’re just confused about what it’s intended to do. They need training.”
“What is it intended to do?”
“You seriously don’t know? I thought for sure that you knew . . . who do you think knows?”
Hyperbole and sarcasm aside, many long-running projects suffer from a feeling of being lost at sea, not sure who will drown, who will be eaten by sharks, and who will try to swim to the shapes that are either clouds or islands in the distance. They lack direction that is best found in a single artifact: the Project Charter.
A project’s charter is a physical document that is authored by a sponsoring authority outside of a project itself. It emerges from a business need, a marketing and feasibility study, an idea for a pet project, or some other catalyst that warrants a temporary re-assignment of resources. The business case for a project should always be documented in its charter. I subscribe to the “more data the better” philosophy here because a charter is in essence a contract between the sponsoring authority and a project manager. On either side of any agreement, I only want to be part of projects that are winners and winning projects satisfy real needs in measurable ways.
High-level requirements, assumptions, constraints, risks, and deadlines are all boundaries that should be addressed in a charter. If specific processes or artifact outputs (e.g., documentation expectations) are required for all projects in your universe (check with your local PMO), you definitely want those expectations identified in your charter next to all of your primary deliverables.
A charter will name the key stakeholders of its project, starting with a project’s manager since the charter is a document granting him or her the authority to assign resources to project tasks. Without a competent manager at the helm, in my opinion, you do not have a project. Key team members; subject matter experts; outside consultants; internal resources, and any other important, known stakeholders should be identified.
It is expected that the charter’s content is largely estimates and assumptions. Approximations and ranges of estimates are fine, but a charter should be clear about the difference between estimates (also known as guesses) and boundaries (e.g., things like the total amount of funds available). This is where some executives begin to recognize that writing a project’s charter is not a project manager’s job at all, but rather the responsibility of the sponsoring authority. A project’s manager should have input into a charter if possible; but in most organizations, the heart of the charter is likely established at a level above him or her.
I realize that there will always be skeptics and naysayers who reject the ceremony of a formal charter as superfluous to a winning formula. They have a good argument: “Many projects have been launched and have finished successfully without a formal documented called the ‘Project Charter.’” That may be true (okay, it definitely is true), but it is also true that without project charters, you don’t know which ones they are.
Charters help to provide “apple-to-apple” comparisons between proposed endeavors and collectively, the charters within your organization will paint a picture of what your enterprise values, where you are headed, and when you plan to arrive. A charter is a stake in the ground, a contract, a measuring stick, and a splash of color in your mural of the future. Formalizing the establishment and accountability of projects through charters will do wonders for the efficiency of your enterprise.