August 5, 2013
As part of starting a new project, it’s a good idea to ask challenging questions to make sure you deliver what was expected. User needs are at the foundation of project requirements. To help you uncover the needs of the end user, it’s a good idea to create a document known officially as a project charter, though in real life it can go by many names. A project charter, however it’s called, sets forth the agreement to do the project in a formal manner.
Project charters protect you, the organization, the customers, and your project itself. A project charter: formally states the commitment of the organization to do the project; provides a high-level summary of project objectives and goals; assigns the project manager; grants the project manager authority to make decisions and use resources; and issues from (but is not necessarily written by) the project sponsor. It’s good practice to make sure each step in the project management process has been accepted by key stakeholders before moving forward. Here is a project charter checklist to help you cover all your bases.
Make sure your project charter:
• Formally states the commitment of the organization to do the project.
• Provides a high-level summary of project objectives and goals.
• Assigns a project manager and states the authority the project manager has to make decisions and use resources in support of the project.
• Issues from (although is not necessarily written by) the project sponsor.
Your project charter should include:
• Version control. Project charters, along with other planning documents, may evolve during the process. For documents that may be modified, use version control numbers to ensure that everyone is working with the most recent update.
• Decision. There must be a formal decision to do this project.
• Triple constraints. Information about the triple constraints is included, although the information may or may not be sufficient to determine the hierarchy of constraints. But the fundamental constraint is typically cited, along with the reason it is fundamental. For example, a product aimed for the Christmas season would have this as the time constraint.
• Change control. since scope creep is a danger on most projects, the project charter will typically set forth specific and measurable design objectives that have been agreed to for the project, and establish a change control process for managing any changes.
• Milestones. The project charter will typically include key milestones and approval dates for the project. since planning must be done around those milestones, any change to them will become part of the change control process.
• Priority and consequences. since projects typically cut across functional department lines, there’s always a predictable risk of conflict and lack of cooperation. The project charter should make it clear that a request for help isn’t just from the project manager, but from the project sponsor.
• Duties and responsibilities. The project charter will typically establish critical responsibilities and expectations for the project manager and for other departments or individuals who will need to cooperate. That’s enough for a preliminary document like this. More detailed guidance will be included in the plan.
• Approvals. The project charter should clearly identify the sponsor and make it clear that the sponsor plans to be a participant in the project and exercise certain control authority.