Key Question: How complete is the project charter? Does it have all the necessary components with a sufficient level of detail?"Most likely a weak project charter is on file somewhere because many people do them just because they have to. Generally, some defining document is required so the project can be funded. Runaway projects tend to have project charters with poorly written sections with ambiguous wording or, worse yet, missing key sections,. To make matters worse, the project charter is usually tucked and kept for historical purposes only. The project charter should be actively reviewed and maintained on a regular basis. Without a solid project charter, it is very difficult to hold people accountable for the project's success or failure. The following list contains the sections and content of a good project charter:"
- Executive Summary "A brief (one to three pages) summary that highlights the project from a business perspective. This section should contain the reason(s) the project is undertaken, cost, schedule, ROI based upon accepted company policies, intangible benefits, affected organizations, and the consequences of not doing the project."
- Project Scope "Describes what the project is supposed to accomplish. This sections starts as a snapshot of the project's function at the project's inception. It should be updated regularly as part of the change control function. The key areas in this section include the project's critical success factors, deliverables and known out-of-scope items and activities. This is one of the most likely areas that got out of control in a troubled project situation. The In-Scope section should be explicitly called out in the Scope section to quantify the items to support the project estimate (i.e. estimating assumptions). The quantified items also act as boundaries with which to invoke change control and limit scope creep."
- Management Approach "Describes how you're going to manage this project. This section contains the project management methods that will be employed during project startup, execution and completion that will help keep the project on track. The key areas include the activities associated with change management, issue management and plan management. These activities and their associated tasks should be directly reflected in the project plan. Not following the methods in this section, especially change control, is clearly the leading cause of runaway projects."
- Technical Approach "Describes the methods to be used to ensure the project management and technical quality. These methods include such things as the accepted standards regarding project charter content, estimating, status reporting, and project notebook content. Also, the timing and procedures for project reviews or audits should be stated here as well. From a technical quality perspective, methods such as structured walkthroughs would be articulated. Items related to the walkthroughs such as objectives, attendees, timing and procedures are included. Again, all of the tasks associated with this approach should be included in the project plan."
- Roles and Responsibilities "Describes the function and authorities of the various project roles. This is not a job description of each project team member because a person can fill multiple roles and certain roles may be filled by more than one person. Key roles and responsibilities should include:"
- Functional business team
- Executive sponsor "Works with the technical project manager to act on behalf of the functional business team for accepting deliverables, authorizing change requests and resolving escalated issues."
- Project sponsor "Works on a day-to-day basis with the technical project manager and assists in resolving issues, as well as designating, delegating and scheduling the subject matter experts' time as required."
- Subject matter experts "Provide specific business and technical information to the technical project manager as requested and specified in the project plan. If necessary, identify key subject matter experts for clarity."
- Technical team
- Project manager "Responsible for the day-to-day management of the project and reporting status to the project sponsor and project executive sponsor."
- Project architect "(also known as the technical project manager) Responsible for the technical viability and quality of the project."
- Technical team members "Various technical team roles such as business analysts, programmers, testers, technical writers, trainers, data administrators, database administrators and so on. It is very important to describe each appropriate role, especially if that role is to be fulfilled from an 'external' organization such as a shared services group or outside consultants."
- Project Plan "This will be explained in full detail later in this chapter."
- Budget and staffing plan "Describes the costs, both internal and external, including hardware, software and labor. The labor component is tied directly to the project plan and should reflect a reasonable ramp-up, peak load and ramp-down staffing level. Most project management software allows for material costs to be entered in the project plan as well as labor. If material costs are included in the project plan, those variances can be tracked and managed as well."
- Project organization chart "Displays the reporting and authority structure of the extended project team. The project steering committee should be indicated with all members. All direct and indirect relationships should also be noted. This section tends to have been omitted in troubled projects or there is an extremely complex organization chart. Keep it simple!"
Key Question: How current is the project charter?"Every time there is a change to the project, that change should be reflected in the charter. The project charter should be the most current snapshot of the project's scope and business case. The audit trail for each generation of the project charter should reside in the project notebook. Most projects get derailed when the project team just sticks the project charter on the shelf and never looks at it again. Changes to the project charter reflect the need to change the scope of the project development boundaries. Scope changes are a big deal and when approved, require a complete recasting of the project plan estimates or a re-baselining of the plan to reflect the changes in the dates. Changes within scope - variances from the plan - are normally authorized through the Change Management process and do not require the entire plan to be re-baselined but only the changes tasks."
The above is an excerpt from a book written by Sanjiv Purba and
Joseph Zucchero, published by McGraw-Hill/Osborne, 2100 Powell Street,
10th Floor, Emeryville, California 94608 U.S.A. Sanjiv has over 20
years of experience managing large projects and many years engaged in
rescuing ailing projects.