The Project Charter

The project charter has traditionally been important because it is the first official project document which formally begins the project.

In the PMBOK Guide, the PMI defines a project charter as a “document issued by the project initiator or sponsor that formally authorizes the existence of a project, and provides the project manager with the authority to apply organizational resources to project activities”. The latest PMBOK edition has made explicit mention of a “Develop Project Charter” process. It defines this as “the process of developing a document that formally authorizes a project or a phase and documenting initial requirements that satisfy the stakeholder’s needs and expectations”. This project chartering process is indeed valid and is broader than the charter document itself.

I have seen many organizations extend PMI’s definition and make the charter a multi-page document that includes a large scope definition, assumptions, constraints, PM tasks, estimated costs and risks, among other items (which are usually part of a later-stage document, such as the SOW). Unfortunately, this interpretation misses the point put forth by PMI, and in this case, academia has it right. It takes effort to compile scope, costs and the other information necessary to project management. Many organizations need to pass some gateway of officialdom before they can commit time and resources to that effort. The project charter is that first gateway – it authorizes the organization to consider the effort to be worthwhile enough to begin creating the foundation and gives the project manager the license to do so.

For smaller projects, the Charter may be the only project document, so it may need to take on more detail, although it arguably deserves a different name in that case.

Regardless, the IT manager should not take a stand on semantics and standards interpretation here. Rather, the IT manager should ensure that there is some organizational mandate before expending resources on planning a project. And of course, get that mandate in writing, because “if it is not written down, it didn’t happen”.

I recommend a charter be no more than two pages, so it can fit on the front and back of one physical page. The audience will be IT and business management, not the project team. I typically include the following items which again are only described at a high-level.

  • Purpose of the charter, which is something to the effect of “this document formally authorizes the project, giving IT a documented mandate from the sponsoring organization to proceed with the initiative”, and mention that subsequent documents will refine the scope
  • Vision/problem statement
  • Business goal, or something to tie the project to that folks outside of IT are familiar with; e.g., acquisition, new product, maintenance of infrastructure
  • Customers
  • Requirements, which basically refers to the source of requirements, not the requirements themselves
  • High-level statement of work, as in a few bullet points
  • Out-of-scope, if necessary
  • Success criteria and end conditions
  • Potential source of funding
  • Resources, which will refer to a potential pool and not identification of team members
  • Assumptions/Constraints/Risks
  • Acceptance section (signatures of sponsor, customer representative and whoever is managing the project

Alex Brown has some good examples of unorthodox charters here at his site. Those items above that are sometimes included in a charter are definitely valid, but I recommend addressing them in a SOW.