The Project Starting Line: Writing the Project Charter

The Project Starting Line: Writing the Project Charter

You are ready to start a new project. What is the first step? Writing a project charter. Usually the charter is written before the project starts as the charter is often used to decide whether or not to fund the project. Once the project is approved, the charter becomes the formal document that officially authorizes the project and gives the project manager authority to execute it.

The charter can be written by the project manager. However in many organizations, especially large ones, it is written before the project manager is assigned. In that case it may be written by the program manager, the functional manager, the project sponsor, or even a committee investigating the feasibility of doing the project. So if you are a project manager assigned to a new project, is it possible that you were not at all involved with creating the charter.

When you, the project manager, get the charter, it may be already signed by the stakeholders. If not, make that your second task. Your first would be to review the charter and request modifications, if necessary. For example, if you get a charter that wants a 6-month project done in six weeks, you need to make it clear to all stakeholders (and your boss) that this is an impossible request. Put your requested changes in writing and include why you are requesting them. That way when the project fails to meet the deadline, you can clearly show why that happened (and while actually saying "I told you so" may be frowned upon, you at least have "covered your ass.")

Occasionally, the project manager is assigned before the charter is officially written. In that case, you need to write the charter. How you write it depends on the reason it is written. There are many reasons for doing a project. Here are some of the more common ones:

• New technology: Your company is looking to buy/already bought/developed some new technology and a project is created to investigate it/install it/use it/train people to use it, etc.

• Government request: The government has passed a law or wrote a new regulation that requires your company to make some type of change; the new project will make this change.

• Customer request or market demand: Market demand or multiple requests from customers require some type of change or addition to your business. Your company needs a project to investigate/install/develop/train employees to make this change.

• Business need: There are many other types of business needs that require project. Any request to make a change to increase market share or profit typically requires some type of project.

So what goes in a project charter? Start with the basics: name, dates, and players. First, you are going to want the project name. Typically the name is picked before the project manager is assigned. Projects are often given names that stand for something longer, like the Aries Project or the Genesis Project. But easy to remember names aren't useful if the full name is only created to have a cute shortened name (All Rules in Environmental Systems). It's better to have the name explain the project (Environmental system upgrade) even though ESU isn't as clever as Aries.

Next, list the project manager, program manager, sponsor, and who prepared the charter (usually you don't list all the stakeholders in the charter, but can if desired). Then put in the proposed start and end date and the audience. Next comes the objective. At this point it should be a short synopsis of the purpose of the project (example: "the objective of this project is to upgrade computers for the entire company from Windows XP to Windows 8"). If the purpose is to improve people performance, you want to follow the objective with performance objectives ("After completion of this project, the sales team will be able to:... ")

Objectives are followed by two important pieces: the deliverables and success metrics. You need to be as specific as possible about the deliverables. If you are a project manager and you were given a charter without specific deliverables, you need to meet with the sponsor and get these in writing before you start. Now it's true that sometimes you don't know what the deliverables should be before you start. In that case you should not deliver the end result off of the charter. You first need a charter where the deliverable is an analysis document.

Project Managers fall into this trap all the time. If you work from a charter that doesn't list deliverables, or one that lists vague deliverables (a new corporate library), you are destined to fail, because everyone will have a different idea of what the result should look like. The deliverables identifies the scope of the project. If you are supposed to deliver an eLearning class and a job aid, then no one can ask what happened to the reference manual. If it was not listed as a deliverable, it is not included in the scope of the project. When you don't know the deliverables, your first charter needs to be an analysis of the situation and with a list of deliverables as the outcome of the project; you can then create a second charter that spells out exactly what needs to be done to consider the project complete. Success metrics go along with this.

Success metrics spells out what is considered a successful project. A successful course may be one where student pass a test with 80%. A successful system installation may be on with less that 1% errors or one that is running at by certain date. You and the sponsor need to determine what success means. If 75% of the people attending an event gave it an excellent rating does that make it a successful project or do you need 80%?

All charters should also include assumptions, constraints, and risks. At this point you are only listing risks at a high level. For example, subject matter expert (SME) availability would be a high level risk. If there aren't any SMEs available to give you the information you need to complete your project, the project can't get done. If a project is SME dependent, you would want to list the SMEs on your charter as well.

The last part may be the most important part to those in charge: the financial benefits and the budget. Why are we spending the money on this project? What is the expected return on investment? As a project manager you need to decide if this return is feasible based on both the deliverables and the budget. If you see that what they want can't be done with the money they are giving you, or if you don't believe the project will provide the expected financial benefits, you need to call that out BEFORE you start the project. If you don't, it become your fault if the project goes over budget or if the benefits aren't received. This is another trap project managers often fall into Figure out what it should be and if sponsors won't change the charter, and if you are not in a position to decline the project, put your concerns in the charter under the risks section..

The bottom of the charter contains boxes for signatures. Make sure the client/sponsor, and everyone else who needs to approve the project signs it. In many cases an email saying "I approve the charter" will suffice. If they don't sign off on it, don't start it. This is a contract. If you don't get them to sign, you may have trouble getting them to pay for it. With a signature that are committed to project as written, you avoid scope creep (sponsors saying that they expected more than what was delivered).

When you are done with the charter, and the project is approved, the project manager starts the project plan. A good project plan should start with the charter. Your project plan is a living document. It continues to grow and change as your project evolves. Too often the charter gets forgotten as the project progresses. By making it part of the project plan, your charter doesn't die. When the charter stays with the project, you have a better chance of having the result of the project meet the needs and satisfy the customer requirements as identified in the charter.