Project Charters and the Five-Tools Project Manager

In the last article I described the idea behind becoming a very highly valued five-tools project manager. This time, let’s look at the first tool, the project charter.

Charter Basics

To start, recognize that all projects have a charter.

I’m not suggesting all projects have a written or even a conscious charter, however. Too many project teams fail to formulate a charter intentionally but rather drift – or blunder – into various facts they’ll later wish they’d known at the start.

Because when projects go south, they usually do so from the very beginning. The team doesn’t realize it, of course. It’s only when they get to the end of the failed project that they look back and recognize that the seeds of failure were sown the day they began working on it.

There’s a lot more to Legal Project Management than charters, of course. But this simple tool – and it is quite simple, no matter how it may sound in the abstract – is the biggest and most easily implemented key to project success.

In essence, a charter sets the stage at the start of the project – not necessarily getting your ducks in a row, but at least identifying the ducks.

The charter need not be written. There is no one-size-fits-all form, or format. It doesn’t even need to live within a single document. And not every charter will reflect the nine particular elements of a Legal Project Management charter, described briefly below and in more detail in the follow-up article.

That said, there’s high value in keeping a written charter within a single document. You can share it easily with new team members as well as use it as inoculation against client or intra-team requests that might otherwise spin the project out of control.

How Long Should the Charter Be?

I try to fit the nine elements of a charter within two pages. The charter should summarize the issues rather than exhaust them. Keep it short enough so that when someone – a client, a new team member, your manager – asks what the project is about, you can show them. If it takes them more than a minute or two to read and make sense of it, it’s too long, or you’ve overcomplicated it.

Remember, it’s not the only project document. It’s simply the first (and most important), the one that supports the rest of the work going forward.

The Language of the Charter 

Write the charter in language the business client will understand, rather than legalese. Don’t “dumb it down,” but rather make it accessible.

Obviously, in-house counsel asking you to test some arcane point of law might see language different from a business client seeking guidance on a transactional matter. Suit your language to your client’s needs. (Also consider the client’s relative sophistication and familiarity with the legal issues.)

Although I structure my own charters as a table, I’ve also seen good charters written in a “legal memo” format. Whether prose or bullet points, what matters is the content, and the language expressing it.

Who Creates the Charter?

The team should write the charter together. The charter is not a solo exercise, The Word delivered from the heights of project management.

The charter has a dual purpose. One aspect is obvious, identifying the ducks you need to line up in the next stage of the project. The other aspect appears when the team creates the charter together.

Together, the team will ask tough questions. The discussion will also clarify gray areas, where different team members have slightly different interpretations of a given issue.

The Nine Elements of a Legal Project Management Charter

The next article, in the October issue, will discuss what you actually capture in the nine elements:

  1. The business problem.
  2. The client vision.
  3. “Done.”
  4. Out of scope.
  5. Dates and deadlines.
  6. Budget.
  7. Staffing and resources.
  8. Stakeholders.
  9. Project risks.

(This article is adapted from Steven B. Levy’s new book: Legal Project Management Field Guide: Five Tools for Busy Professionals.)


  1. While true that some projects don’t require all elements of the above..whenever there is a project involving a client/client group and several other parties to implement the project, then at least a written project scope is very helpful for all parties.

    The project scope will also highlight exclusions, what the project will not cover. This also is very helpful as the project moves along since it’s too easy to add on projec scope changes that cause scope creep, extended project timelines, etc.