The project charter is the initial document providing information about the goals, objectives, methods, deadlines, and other key facts of your project. The purpose of this document is to capture goals and objectives at a high level and ensure that the project plan supports achieving these. Unlike the Business Case (described elsewhere on this site), it does not need to be updated as more information is learned about the project work. Rather it is a point of reference, used to ensure that your project is still on track. More importantly to you, it should define your authority over the project.
The project charter will be your reference point when determining the success or failure of your project. Any departure from the scope specified in the scope statement will be perceived as a significant failure. Any departure from the key milestones contained in the charter will also be perceived as a failure. Your project approach may change during the course of the project. If it does, this won't be perceived as a failure so long as your key deliverables, milestones, and scope have been met. Any changes to approach should be managed by the project's change management process and trigger a revision of your charter.
Cover PageThe charter should have a cover page which will identify the document (Project Charter) and the project name. The author, revision number, and date should also appear on the cover page. You may also want to include your project's logo (if it has one), or your organization's logo. The revision and revision date are standard for any document but this one should not change during the project. If it does, you'll probably be dealing with a change request at the Steering Committee level.
The next page, in order, should be the revision history page. Again, this should contain one entry - the initial revision. Any additional entries will contain the author of the revision, the revision number, and the reason for the revision.
Project ScopeThe description of the project scope should be at a high level. The scope statement may be available from another source - for example, your project sponsor may have written such a document (it may not be called a scope statement) that describes in broad terms what the project is expected to deliver. If it isn't, you'll need to craft it yourself. The scope statement appearing in the project charter should be written in general terms. For example, if you're building an order entry system for a telecommunications company, you might describe it as follows:
"The ABC project will create and implement an order entry system consisting of a software application, database, and network to capture orders for our XYZ line of products. The system will support the entry of the order including the product being ordered, the delivery date, delivery method, the customer name, and shipping address. The system will also be used to track the order from entry to delivery. The system should support reporting by the engineering department, the shipping department, and the customer care department........."
The scope statement should not be specific as to the software to be used to create the software application, or the RDBMS. These may appear in the Project Approach section. It should not contain descriptions of software features or database design in technical terms. Descriptions should be in business terms.
Project ApproachThis is where your authority is defined. Make certain this information appears in any charter you author and is approved by your executive sponsor! The roles and responsibilities of the author key members of the project team (such as the executive sponsor) will also appear here. Roles may be associated with names of critical or key resources, or may simply be role names such as "development team lead".
Project deliverables and quality targets should be listed in this section. In the example quoted above, you'd include the software application and database as key deliverables. You might also include a reporting engine, a web site, LANs, WANs, User Manuals, and user training as deliverables. Don't forget performance targets when describing deliverables. For example, you may want to support entering an order in under 5 minutes, generating a status report in less than 30 seconds. Include any load targets you're aware of. For example, if the system has to support 150 order entry clerks, or the processing of 50 orders concurrently, or the archival of 500,000 orders. Quality targets should be defined in precise measurable terms. For example, the system will be implemented with 0 category 1 defects, no more than 5 category 2 defects, etc.
Key milestone dates are also captured in this section. Key dates for the example we're using here might include: requirements gathered and approved, software development completed, database implemented, QA testing completed, etc. Whatever other deadlines it contains, it must contain the implementation date.
List any risks that are known to the project. Don't forget that any assumptions you make about the project are risks. If the assumption is disproved, a risk event will happen. Any issues encountered prior to this point should also be captured. The project approach will include any decisions taken to this point to use a specific software tool or software development life cycle method. A glossary is a very useful appendix to this document. In it, you should explain any terms that your readership may not understand. At a minimum, any technical terms should appear here. Don't forget that the purpose of this document is to communicate your project's goals and objectives, typically to a senior audience. That audience shouldn't be baffled by any language the document contains.