Project charters play an extremely important role in the initiation of projects. The Project Management Institute (PMI) suggests that no project should begin without a charter. A project charter creates a foundation to guide project activities. The primary roles of the charter are to:
- Authorize the project to move forward. In many methodologies the charter acts as the authorizing document. The charter will include items such as the business need, project scope, budget and the signature of sponsors. In some organizations the sponsor or the sponsor’s organization will author the document and use it as a form of transmittal or work ticket. While the literature is rich with processes in which the charter is written outside of the development team, I have never seen this process in action. What is more typical is a charter written by IT and signed-off on by the stakeholders or some sort of electronic budget authorization. Regardless of methodology, in a large organization, an authorization to spend money is important.
- Acts as a communication vehicle. The charter is often used to capture the initial thoughts of the sponsors, product owner and team about the goals of the project and the rules they will use to govern themselves (or be governed by in classic command and control methodologies).
- Provide structure for the team. Who is on the project team is not always as evident as it should be. The charter should identify the team members (and some logistical info, like time zone, if distributed) with the roles they are playing, if needed. In many IT organizations, team members play specified, specialist roles. While specialization is a feature mainly thought to be seen in organizations using classic development and project management techniques, it can also be seen, albeit to a lesser extent, in organizations using Agile. Depending on the method used the product owner and Scrum Master should also be identified. Other team attributes such as team norms and expectations should be identified and agreed upon.
- Identify needed resources. Remember that the resources needed, like business needs and requirements, continually evolve. Therefore over time the charter must evolve or be replaced. For example, a charter I recently reviewed for a new Agile project and team identified the need for a team work room and licenses for a specific automated testing tool.
The macro goal for the charter is to get the project going in the right direction. The needs and requirements of most projects of moderate to large size/duration are relatively dynamic. The issue is that while charters are supposed to change and evolve, once they are created they are prone to becoming shelf-ware.
A charter can contain additional information such as risks, constraints, project context and deadlines. The range of data that can be housed in a charter is limitless. However, I have seem large projects spend months writing and wordsmithing charters that were hundreds of pages long. The process of thinking about all of the charter topics might be valuable, however rarely is the document used after the sponsors and other stakeholders sign off on the document. Whether Agile or a classic plan-based, rarely will the charter see the light of day (or an update cycle) unless the topics covered are important to the team.