Today I came across the dilemma of changes requested to a project charter. This brought me to think more about the purpose of a project charter, and how inevitable changes to projects should be addressed.
The purpose of a project charter is to provide a high-level, not-too-detailed-but-just-enough outline of the work that will be done in a project. More importantly, it also represents a commitment by all parties involved (including the client, project manager, CIO, and other stakeholders as required) to complete the work according to the general parameters defined. Changing the commitment requires communication & re-approval to make sure everyone still agrees on the charter. This means that a charter should be broad enough not to change.
In the case of today's example, fortunately the changes to the charter were not substantive. The only change being requested was addition of detail to the project deliverables, which got me thinking about scope of work and project planning.
Project managers have a need to document in detail the work that was loosely defined by the charter, to communicate to the client about what exactly will be done, and when. This is totally normal and expected, and an important part of our project process. As project planning takes place, a clear picture of the work required develops and is communicated to all those involved in the project.
This need is exactly why our organization developed a Project Scope document.
During the planning part of a project (i.e. after a charter is approved), the PM uses the Project Scope document to define all of the tasks that will be completed during a project. This is especially important for large projects which are time-consuming and/or high-risk. You know it when you see it: a project that is likely to experience scope creep, time creep and other project challenges is a good candidate for using the Project Scope document and process.
The Project Scope document helps the client and PM agree on the detail of what will be done before the work begins. If changes must occur after you & the client have agreed on the project scope (i.e., once project execution begins), then you have two choices:
- document new tasks and scope change requests separately as issues; or
- go back and change the project scope
Solution #1 means that an Issue Log is created for each new problem or issue. This solution is recommended, as it is the most flexible and lowest cost. As time and resources permit, these issues are addressed over the course of project execution. The PM will keep the Issue Log with the rest of the project documentation, and monitor resolution of noted issues. In this way, issues can be documented, prioritized and repaired in the time available for a project. (Did I mention it's important to add some buffer time to your project schedule to make sure you can account for these unforeseen issues?)
Solution #2 should only be used for projects that are in serious trouble. Going back and substantially updating the project scope is expensive in both time, resources, and political capital.
For a well-run project, a PM should expect to have 80% (preferably more) of all major tasks documented in the Project Scope, so that you minimize issues during execution. Project managers that encounter frequent unforeseen issues or problems during project execution should spend more time on project planning activities.
The bottom line: it's important to spend some time documenting exactly what will be done, by whom, and when before you start executing project tasks. Planning might seem expensive, but it typically saves cost and aggravation, builds client and stakeholder goodwill, minimizes risk, and helps keep projects running smoothly and successfully.
