Getting Your Project Off to a Good Start
You've just been appointed project manager for a new project.
Senior managers have already signed off the project's business case, and you're busy recruiting your full-time project team. You're also identifying a wider group of people in your organization from whom you'll need to get support for certain project tasks. Some of these people have already been involved in developing the business case, and some are completely new to the project.
As project manager, you'll often need to implement a business case that's already been approved. You'll have team members who have had different levels of involvement in the project so far. The problem is that some of these people may have different views of the project's goals, particularly if the project has been planned over a long period of time.
So, how can you get your team working in a positive and productive manner, and how can you make sure that everyone understands the goals of the project?
This where a Project Charter can help. In this article, we'll review the reasons you might use a Project Charter, and look at the main things that you'll need to include in one.
Why Use Project Charters?
Project Charters outline project goals, and give an overview of how projects will look and feel while you work on them. You can use Project Charters in discussions with project team members, governance groups, and other stakeholders – either individually or as part of workshops – as a way of ensuring that everyone understands the project's requirements.
Writing a Project Charter forces you to think through the project as a whole. You must understand all of the existing project documentation, consider how you want to approach implementing certain parts of the project, and identify the key points that everyone involved in the project needs to understand.
You can also use a Project Initiation Document (PID) instead of a Project Charter for these purposes as they are very similar documents. However, a Project Initiation Document is usually much more detailed. So a Project Charter is more suited to projects where you don't have the resources to write a detailed Project Initiation Document, or where you want to start work on the project quickly.
The project management methodology that your organization uses may also determine whether you should use a Project Charter or a Project Initiation Document.
Format of a Project Charter
You can deliver your Project Charter as a report or a presentation.
- In report format – Use this if the Project Charter must be self-explanatory. For example, you may want to use it as a team reference document, to provide a baseline of what you and your stakeholders require and expect from the project. You can then submit the Project Charter as part of the project approval process.
- In presentation format – Use this if you'll present the Project Charter as part of a discussion. For example, you can use the charter to give a project overview to your team at a project meeting; or use it to brief your governance group and stakeholders at their first project meeting.
Contents of a Project Charter
The contents of each Project Charter are specific to the project, but they generally include the following:
- Background and rationale.
- Project requirements.
- Project delivery.
- Next steps.
1. Background and Rationale
This section describes how the project has reached this point. In particular, it will:
- Identify the opportunities the project will exploit, or the issues it will resolve.
- Provide a record of key events and discussions so far, including any key decisions that you have already made.
- Refer to the project mandate or to other statements made by senior managers that have helped identify the project and its requirements.
- Identify the project sponsor and any other key people who have been involved in initiating the project, such as people involved in creating the project mandate, business case, or strategy document.
- Provide references and links to other existing project documentation that project team members may need for more detail. This could include the project mandate, business case, and strategy documents.
2. Project Requirements
This section gives more information on the project itself.
- Objectives – List the project's objectives. Prioritize these objectives, if appropriate.
- Customers and other stakeholders – Identify the customer(s) of the project. Describe the main interests and concerns of other key stakeholders. It's often useful to include a high-level stakeholder analysis at this stage.
Scope – Define the project's scope (what you need to do to deliver your project). Remember that scope creep (uncontrolled changes in your project's scope) is a common problem with managing projects, so it's definitely worth spending time on this area.
You can specify scope by defining the project's functionality, systems, interfaces, processes, departments, and external stakeholders (such as suppliers and customers). It's also sometimes helpful to state what is not part of the scope of the project.
Constraints – List the key constraints, limitations and restrictions that could affect the project. These may be in the original project mandate, or they may have been part of later discussions.
An example constraint could be, "the project cannot be delayed beyond September 30, 2010 because the output must satisfy a legal requirement." Or, "staff from the finance department cannot contribute to workshops during March, because of their commitment to preparing year-end statements."
Milestones and deliverables – Give the timing for project phases, and identify key milestones. It's important to specify which dates you have already agreed to, and which timings are open to discussion or subject to confirmation. But bear in mind that any deadlines that you set here will be used by stakeholders and governance groups in the future.
If there are expectations about the quality of the finished project or interim deliverables, list these here as well.
Costs, benefits, and assumptions – Outline the high-level business case costs and benefits. Identify where you can find more details or the full business case. Remember to include qualitative as well as quantitative benefits.
Also, list all of the assumptions that you have made in your projected cost and benefit statements.
Investigate assumptions as early as possible within the project delivery timelines. Assumptions that are wrong can be expensive to fix, and may delay the project.
For example, if the business case assumes that there is sufficient IT hardware to cover the project needs, investigate this as early as possible. If this assumption is not true, you’ll need time to negotiate an increase to your project’s budget.
3. Project Delivery
This section of the Project Charter focuses on how the project will be delivered.
Challenges, risks, and issues – Identify any key challenges, risks, and issues that might affect the project. Focus on the big items - not necessarily on everything that you can think of.
For example, if project timelines are aggressive and your department has an unsuccessful track record of implementing projects with short timescales, this might be a risk.
Discuss and agree the key challenges, risks, and issues with the project team during the early stages of the project. This will help team members to engage with the project, and allow them to take ownership of it.
Project approach and key principles – Identify the key principles that you have already agreed on about how you will deliver the project. This is particularly important for complex projects, as well as for projects that require significant changes within your organization.
Say, for example, that three geographic regions were to be included in phase one of the project. The central project team could then produce a core implementation strategy that each region would then customize for its specific needs.
- Governance framework – Explain how the project will be governed, and who is involved. In particular, describe the approval processes for phase exit and entry, and for any critical project deliverables.
- Team roles and responsibilities – It's useful to include all project roles, not just full-time roles. Be sure to include those people involved in project governance; and identify who is responsible for managing communication within the project, and for managing relationships with your key stakeholders.
Team management processes – If you've already agreed your processes for reporting; planning; managing risks and issues; and, time recording; then identify what you require from each member of your team.
Many project teams like to create a list of "ground rules" that outline what people can expect from other team members.
4. Next Steps
A Project Charter is often used as part of a team workshop or briefing, so it's useful to include a set of next steps so that team members know their responsibilities, and can start working on the project as soon as they are ready.
Typical next steps are for team members to:
- Review earlier project documentation (such as the project mandate and business case).
- Create their approach for implementation, and record this in a strategy document.
- Plan the next phases of the project in detail.
- Map out resources required throughout the project.
Project Charters are useful documents that help you ensure that everyone knows the goals of a project. They minimize any confusion about what must be done within it, and explain how things should be done.
Using a Project Charter gets your project team off to a good start by creating a positive and productive work environment, where everyone knows what their roles and responsibilities are.