Project Charter Template

Project Charter Template.pdf

Deze mindmap bevat naar mijn idee alle aspecten van een project. Ik heb onderstaand de bijbehorende tekst weergegeven.

  • Project Charter Template
  • 1. Statement of Need
    INTENDED USE:
  • The Statement of Need incorporates the client’s business drivers and the current and future state of their environment. Why, is the client looking for a solution? What is the pain or root cause of their need?
  • INTENDED USE:
  • The Statement of Need incorporates the client’s business drivers and the current and future state of their environment.  Why, is the client looking for a solution?  What is the pain or root cause of their need?
  • 2. Benefits
    INTENDED USE:
    What benefits are expected as a result of implementing the appropriate solution? This section is designed to show why this project is a good business decision. The Benefits must support the MEASURES OF SUCCESS.

    EXAMPLE:
    The company will see benefits in the following: IBM will be hired to reduce the number of hardware/software platforms being used, increasing stability and ease of maintenance. Individuals in the field can use any modem, increasing speed and functionality, which will enhance their performance when connecting with the [RECOMMENDED SOLUTION]. Reduced number and length of long distance phone calls, due to improved data exchange and on-line availability. Simplify the data exchange process and the system architecture. Meet Year 2000 readiness through the development of new applications that are Year 2000 ready. Reduce maintenance costs. Reduce time spent in supporting the system.

  • What benefits are expected as a result of implementing the appropriate solution? This section is designed to show why this project is a good business decision. The Benefits must support the MEASURES OF SUCCESS.
  • INTENDED USE:
  • What benefits are expected as a result of implementing the appropriate solution?  This section is designed to show why this project is a good business decision. The Benefits must support the MEASURES OF SUCCESS.
  • EXAMPLE
  • The company will see benefits in the following:
  • IBM will be hired to reduce the number of hardware/software platforms being used, increasing stability and ease of maintenance.
  • Individuals in the field can use any modem, increasing speed and functionality, which will enhance their performance when connecting with the [RECOMMENDED SOLUTION].
  • Reduced number and length of long distance phone calls, due to improved data exchange and on-line availability.
  • Simplify the data exchange process and the system architecture.
  • Meet Year 2000 readiness through the development of new applications that are Year 2000 ready.
  • Reduce maintenance costs.
  • Reduce time spent in supporting the system.
  • 3. Critical Sucess Factors
    INTENDED USE:
    In this section key elements that must be in place to ensure the success of the project will be defined. This includes other projects finishing or starting, or certain tasks within other projects being completed. It may include dependencies on the availability of facilities or contractual agreements being finalized.

    EXAMPLES: Active executive sponsorship Timely acquisition of required project resources including human, software, and hardware Timely and effective participation of appointed {the client} staff assigned to the deployment team Access to training facilities Acceptance by user community

  • In this section key elements that must be in place to ensure the success of the project will be defined.  This includes other projects finishing or starting, or certain tasks within other projects being completed.  It may include dependencies on the availability of facilities or contractual agreements being finalized
  • INTENDED USE:
  • In this section key elements that must be in place to ensure the success of the project will be defined.  This includes other projects finishing or starting, or certain tasks within other projects being completed.  It may include dependencies on the availability of facilities or contractual agreements being finalized.
  • EXAMPLE
  • Active executive sponsorship
  • Timely acquisition of required project resources including human, software, and hardware
  • Timely and effective participation of appointed {the client} staff assigned to the deployment team
  • Access to training facilities
  • Acceptance by user community
  • 4. Measures of Sucess
    INTENDED USE:
    The Measures of Success (MOS) is a quantified definition of how the project will be measured when it has been completed.
    Defining a project’s MOS is one of the most critical and challenging steps in project management. It requires strategic level thinking about the customer, their problems and how the project will help solve those problems. Before we begin to develop an approach and plan for the project, we need to specifically define the desired end result the project will achieve. If we can not quantify and measure this definition, we haven’t stated it properly. Only when we do, can we accurately begin to chart the course to achieve it.
    At all costs the project manager must avoid the trap of plunging into the detail before the MOS is agreed upon. He or she must ask the tough questions of the client and the pursuit team up front and define a quantifiable and measurable MOS before the project scope, the approach and budgets are defined.
    Finding out how the client will measure success at the end of the project is not an easy task. The measurement is rarely about budget. Often the client is unsure about how to measure the success. Asking detailed questions around “How will you measure [judge, know for sure] the success at the end of the project? What [value, product, improvement, service, knowledge] do you really want to buy for all this money we are asking you to spend?” Working through these question forces the kind of thinking required for successfully planning, executing, and completing projects. With the detailed answers the project manager can drive the project toward the agreed measure of success.
    EXAMPLE:
    A poor MOS: The objective of the project was to implement a system that will, “Enable the client to provide the best possible customer service.” While the statement sounds good, and certainly no one would disagree with the worthiness of the goal, the statement is vague – the beginning of a project in trouble.
    An appropriate MOS: “Reduce the cycle time of customer order entry from two days to one hour.”
    The latter statement is measurable and quantifiable. The client may argue about whether this is what they want, and that is the point; we want to define exactly what the “best possible” order entry process (conceptual) is before we start the project.
  • INTENDED USE:
  • The Measures of Success (MOS) is a quantified definition of how the project will be measured when it has been completed.
  • Defining a project’s MOS is one of the most critical and challenging steps in project management. It requires strategic level thinking about the customer, their problems and how the project will help solve those problems. Before we begin to develop an approach and plan for the project, we need to specifically define the desired end result the project will achieve.  If we can not quantify and measure this definition, we haven’t stated it properly.  Only when we do, can we accurately begin to chart the course to achieve it.
  • At all costs the project manager must avoid the trap of plunging into the detail before the MOS is agreed upon.  He or she must ask the tough questions of the client and the pursuit team up front and define a quantifiable and measurable MOS before the project scope, the approach and budgets are defined.
  • Finding out how the client will measure success at the end of the project is not an easy task.  The measurement is rarely about budget. Often the client is unsure about how to measure the success.  Asking detailed questions around “How will you measure [judge, know for sure] the success at the end of the project?  What [value, product, improvement, service, knowledge] do you really want to buy for all this money we are asking you to spend?”  Working through these question forces the kind of thinking required for successfully planning, executing, and completing projects.  With the detailed answers the project manager can drive the project toward the agreed measure of success.
  • EXAMPLE
  • A poor MOS: The objective of the project was to implement a system that will, “Enable the client to provide the best possible customer service.”  While the statement sounds good, and certainly no one would disagree with the worthiness of the goal, the statement is vague – the beginning of a project in trouble.
  • An appropriate MOS:  “Reduce the cycle time of customer order entry from two days to one hour.”
  • The latter statement is measurable and quantifiable. The client may argue about whether this is what they want, and that is the point; we want to define exactly what the “best possible” order entry process (conceptual) is before we start the project.
  • 5. Stakeholders & Customers
    Identify the individuals within the client organization as well as any external customers and/or trading partners that will experience any level of impact from the scope of this project. Those individuals or groups that are directly impacted by the project are defined as customers. Those individuals or groups that are indirectly impacted are considered stakeholders.
  • Identify the individuals within the client organization as well as any external customers and/or trading partners that will experience any level of impact from the scope of this project.  Those individuals or groups that are directly impacted by the project are defined as customers.  Those individuals or groups that are indirectly impacted are considered stakeholders.
  • 6. Scope
    The project scope establishes the overall boundaries of the project. This section identifies those elements related specifically to scope. A clear understanding of the scope is key to a successful project.
  • 6.1. Deliverables
    INTENDED USE:
    The project is organized around deliverables. The purpose of this section is to clearly define the deliverables produced within the scope of this project and establish points of acknowledgement for the customer’s approval signature. The project will be structured around deliverables and identify the tasks needed to complete each deliverable in the planning process. It is important to be specific enough with the language to know when this item begins and ends.
    EXAMPLE:
    A poorly written deliverable: “Upgrade the network system” is too open-ended.
    A well written deliverable: “Upgrade the existing network server to a Pentium 200 processor and 20 Gig hard-drive.” Remember that what may seem obvious to your technical expertise may not be meaningful to your less technical audience.
  • INTENDED USE:
  • The project is organized around deliverables.  The purpose of this section is to clearly define the deliverables produced within the scope of this project and establish points of acknowledgement for the customer’s approval signature. The project will be structured around deliverables and identify the tasks needed to complete each deliverable in the planning process.  It is important to be specific enough with the language to know when this item begins and ends.
  • EXAMPLE
  • A poorly written deliverable: “Upgrade the network system” is too open-ended.
  • A well written deliverable: “Upgrade the existing network server to a Pentium 200 processor and 20 Gig hard-drive.”  Remember that what may seem obvious to your technical expertise may not be meaningful to your less technical audience.
  • 6.2. Acceptance Criteria
    INTENDED USE:
    This section should list definitive and measurable criteria that will answer the question, “How will we know this deliverable is successfully completed?”
    This section gives the project manager, the client, and the team the opportunity to see the expected deliverables in black and white. By providing detailed acceptance criteria you are managing the client and teams expectations. Doing this up front reduces the risk of client dissatisfaction, as they and the team know exactly how to measure the success of your deliverables.

    Review and acceptance process
    Every deliverable will be reviewed by <the client> and acceptance documented. The deliverable signoff form shall be signed by an agreed upon set of stakeholders as they are completed. The entire project, and each phase, shall also be reviewed and signed off by appropriate stakeholders.

  • INTENDED USE:
  • This section should list definitive and measurable criteria that will answer the question, “How will we know this deliverable is successfully completed?”
  • This section gives the project manager, the client, and the team the opportunity to see the expected deliverables in black and white. By providing detailed acceptance criteria you are managing the client and teams expectations. Doing this up front reduces the risk of client dissatisfaction, as they and the team know exactly how to measure the success of your deliverables.
  • EXAMPLE
  • 6.3. Work Breakdown Structure
    INTENDED USE:
    The Work Breakdown Structure defines the products to be delivered or produced and decomposes the work necessary to accomplish all of the project’s MOS. The WBS is the foundation for building the project plan. The PLAN describes the activities and sequence necessary to complete the project.
    With the MOS defined and approved by the client, we proceed to plan the level of effort required to meet the MOS. We develop the boundaries of the work breakdown structure for the project. We also define the level of involvement in the project required of the client. We define what business units, departments and staff from each need to be involved in the project. We also determine what technical areas of expertise need to be included. At this point, we do not need to worry about the detail necessary to plan the project to the task level. The work effort estimates need to provide sufficient detail about what needs to be done during the project to establish confidence that the deliverables to be produced are reasonable, that the work components are specific enough to be estimated with a high degree of confidence, and that right internal and external controls are implemented. We need to include all functionality that will ensure we will meet the MOS. This level of detail allows the project plan to be prepared in a reasonable amount of time without going into unnecessary complexity. We also need to ensure that no unnecessary activities are included in the project.
    EXAMPLE (and there are many ways to graphically portray the deliverables and how they are segmented to provide smaller sets of work within larger sets of work):

    <Double click on the chart to edit and format to your specifications>

  • INTENDED USE:
  • The Work Breakdown Structure defines the products to be delivered or produced and decomposes the work necessary to accomplish all of the project’s MOS.  The WBS is the foundation for building the project plan.  The PLAN describes the activities and sequence necessary to complete the project.
  • With the MOS defined and approved by the client, we proceed to plan the level of effort required to meet the MOS.  We develop the boundaries of the work breakdown structure for the project.  We also define the level of involvement in the project required of the client.  We define what business units, departments and staff from each need to be involved in the project.  We also determine what technical areas of expertise need to be included.  At this point, we do not need to worry about the detail necessary to plan the project to the task level.  The work effort estimates need to provide sufficient detail about what needs to be done during the project to establish confidence that the deliverables to be produced are reasonable, that the work components are specific enough to be estimated with a high degree of confidence, and that right internal and external controls are implemented.  We need to include all functionality that will ensure we will meet the MOS.  This level of detail allows the project plan to be prepared in a reasonable amount of time without going into unnecessary complexity. We also need to ensure that no unnecessary activities are included in the project.
  • EXAMPLE
  • (and there are many ways to graphically portray the deliverables and how they are segmented to provide smaller sets of work within larger sets of work):
  • 6.4. Exclusions
    INTENDED USE:
    Specifically define any gray areas in both the scope and the deliverables. Setting these expectations up-front will reduce many changes and even disagreements later. Be exact in detailing items not included in the scope of the project. Remember that the audience of the Charter may not have the technical background that would make certain assumptions obvious.
    EXAMPLE:
    The project scope as it’s defined, defers the installation of the network operating system as a separate effort, not covered under the scope of this project.
    The project may include upgrading the network system (you mean the processor and the hard drive), but perhaps excludes the installation of the newest operating system software.
    CAUTION! It is important to make certain the client does not perceive the exclusions from scope as effort that we are incapable of or lacking in expertise. Specify the intended use of the section by suggesting that the effort could be defined under a separate charter.
  • INTENDED USE:
  • Specifically define any gray areas in both the scope and the deliverables. Setting these expectations up-front will reduce many changes and even disagreements later. Be exact in detailing items not included in the scope of the project. Remember that the audience of the Charter may not have the technical background that would make certain assumptions obvious.
  • EXAMPLE
  • The project scope as it’s defined, defers the installation of the network operating system as a separate effort, not covered under the scope of this project.
  • The project may include upgrading the network system  (you mean the processor and the hard drive), but perhaps excludes the installation of the newest operating system software.
  • CAUTION!  It is important to make certain the client does not perceive the exclusions from scope as effort that we are incapable of or lacking in expertise.  Specify the intended use of the section by suggesting that the effort could be defined under a separate charter.
  • The project scope establishes the overall boundaries of the project.   This section identifies those elements related specifically to scope. A clear understanding of the scope is key to a successful project.
  • 6.5. Asumptions
    INTENDED USE:
    Explicit assumptions help to define the conditions under which the project is planned, budgeted, and managed. Whenever possible they should be stated specifically and as early as possible, so they can be used as a reference to identify changes to a project that impact the quality or quantity of deliverables, schedules, costs, etc. Assumptions are an essential part of the charter. They provide an audit trail of how you derived your estimate. This helps the client understand how you came up with your numbers and reminds you of your assumptions if you find that tasks are taking longer or less time to complete. If your assumptions are not valid, then your project is likely to take more or less time, which will impact cost and target date.
    There are always unknowns at the start of the project. The project plan gives you a standard to measure against. But the charter is always prepared early in the project when there are unknowns. You will always have variances (favorable and unfavorable) against your estimates as the project proceeds. Assumptions help you understand where and why your estimates may be off, and help you to improve your estimates as you continue on the project or go on to other projects.
    Assumptions become a very important element in controlling costs and managing scope. They can also be helpful by clarifying why the project is going to take longer than originally estimated. If an assumption proves to be invalid, the estimate will change. The assumptions enable us to explain the change to the client.
    EXAMPLES: System consists of 18 cobol programs. 10 programs are small (< 1,200 loc), 6 are medium (< 2,500 loc), and 2 are large (> 2,500 loc). The client will be responsible for final production and distribution of the technical manual changes. Production costs are not included in the cost estimate. The client will make the subject matter expert available for 2 hours per day during the analysis phase.
  • INTENDED USE:
  • Explicit assumptions help to define the conditions under which the project is planned, budgeted, and managed.  Whenever possible they should be stated specifically and as early as possible, so they can be used as a reference to identify changes to a project that impact the quality or quantity of deliverables, schedules, costs, etc.  Assumptions are an essential part of the charter. They provide an audit trail of how you derived your estimate. This helps the client understand how you came up with your numbers and reminds you of your assumptions if you find that tasks are taking longer or less time to complete. If your assumptions are not valid, then your project is likely to take more or less time, which will impact cost and target date.
  • There are always unknowns at the start of the project. The project plan gives you a standard to measure against. But the charter is always prepared early in the project when there are unknowns. You will always have variances (favorable and unfavorable) against your estimates as the project proceeds. Assumptions help you understand where and why your estimates may be off, and help you to improve your estimates as you continue on the project or go on to other projects.
  • Assumptions become a very important element in controlling costs and managing scope. They can also be helpful by clarifying why the project is going to take longer than originally estimated. If an assumption proves to be invalid, the estimate will change. The assumptions enable us to explain the change to the client.
  • EXAMPLE
  • System consists of 18 cobol programs. 10 programs are small (< 1,200 loc), 6 are medium (< 2,500 loc), and 2 are large (> 2,500 loc).
  • The client will be responsible for final production and distribution of the technical manual changes.
  • Production costs are not included in the cost estimate.
  • The client will make the subject matter expert available for 2 hours per day during the analysis phase.
  • 6.6. Constraints
    INTENDED USE:
    Constraints are factors that constrain the project by scope, resource, or schedule.
    EXAMPLES: Other systems having the data required available a final due date Limited access to facilities Only a certain number of individuals are available to work on the project
  • 7. Cost Estimates
    INTENDED USE:
    The cost estimate section of this document should detail the budget requirements for the effort defined within the scope of this project. Costs can be broken down in a number of ways, such as by deliverable, by job function, by project phase, or a combination. Generally, this section can describe the budget in one of 4 ways: No estimate yet, wait until more analysis Estimate the analysis and inventory, estimate the rest later Roughly estimate the whole project for a certain target date Use industry standard estimate figures for similar projects
    Estimating guidelines Use the Work Breakdown Structure (WBS) as a basis of your estimate Allow time for meetings and administrative tasks, there are always administrative tasks in a project Can plan for an eight hour day and describe off time piecemeal, or plan for 80% availability for everyone and ignore ‘off-time’ Project management, coordination, meetings, and administrative costs should be included. These can be listed separately or embedded into the costs for specific deliverables. As a rule of thumb, Project management typically represents 20% of the overall budget on project work, but could be more or less depending upon the education and knowledge transfer required of the project lead When estimating costs, be sure to include time for testing and revisions. These amount can vary widely depend on the complexity of the content, the stability of the technology, the expectations of the client, the skill level of the team members, the amount of time devoted to the analysis and design processes, the expertise of the subject matter experts, the review process itself, the number of planned revision cycles, system testing and volume testing requirements, etc Milestones should be designated for specific dates, completion of deliverables, or completion of project phases
    Following is a summary of estimated costs based on the milestones detailed in the scope and approach of this project (hours should also be included but are not here, and assignments if known):

    Administration $61,150.00 Quality Review $18,750.00 Project Leader $42,200.00 Phase I $188,120.00 Design $24,000.00 Development $124,000.00 Documentation $29,920.00 Testing $10,200.00 Phase II $ 77,040.00 Gather/prioritize Phase II Information $4,000.00 Design $6,400.00 Development $54,000.00 Documentation $10,200.00 Testing $2,040.00 Demo/Training $21,200.00 Beta Test/Rollout $44,000.00 *** TOTAL *** $391,510.00

  • Estimating guidelines
  • Use the Work Breakdown Structure (WBS) as a basis of your estimate
  • Allow time for meetings and administrative tasks, there are always administrative tasks in a project
  • Can plan for an eight hour day and describe off time piecemeal, or plan for 80% availability for everyone and ignore ‘off-time’
  • Project management, coordination, meetings, and administrative costs should be included.  These can be listed separately or embedded into the costs for specific deliverables.  As a rule of thumb, Project management typically represents 20% of the overall budget on project work, but could be more or less depending upon the education and knowledge transfer required of the project lead
  • When estimating costs, be sure to include time for testing and revisions.  These amount can vary widely depend on the complexity of the content, the stability of the technology, the expectations of the client, the skill level of the team members, the amount of time devoted to the analysis and design processes, the expertise of the subject matter experts, the review process itself, the number of planned revision cycles, system testing and volume testing requirements, etc
  • Milestones should be designated for specific dates, completion of deliverables, or completion of project phases
  • The cost estimate section of this document should detail the budget requirements for the effort defined within the scope of this project. Costs can be broken down in a number of ways, such as by deliverable, by job function, by project phase, or a combination. Generally, this section can describe the budget in one of 4 ways:
  • No estimate yet, wait until more analysis
  • Estimate the analysis and inventory, estimate the rest later
  • Roughly estimate the whole project for a certain target date
  • Use industry standard estimate figures for similar projects
  • 8. Approach Strategy
    INTENDED USE:
    The approach strategy tells your client the path you are planning to take. It justifies the chosen approach over another, if appropriate. It answers the questions, “Why did I decide to do the project this way? How did I come to this conclusion?” It may include qualitative as well as quantitative data, but should be at a high level.
    EXAMPLE:
    “On the basis of {this survey, interview, market} research and because {of these client, project, content specific} reasons we will {program, design, implement} the {deliverable} in {this particular} way.”
  • INTENDED USE:
  • The approach strategy tells your client the path you are planning to take. It justifies the chosen approach over another, if appropriate.  It answers the questions, “Why did I decide to do the project this way? How did I come to this conclusion?”  It may include qualitative as well as quantitative data, but should be at a high level.
  • EXAMPLE
  • “On the basis of {this survey, interview, market} research and because {of these client, project, content specific} reasons we will {program, design, implement} the {deliverable} in {this particular} way.”
  • The approach strategy tells your client the path you are planning to take. It justifies the chosen approach over another, if appropriate.  It answers the questions, “Why did I decide to do the project this way? How did I come to this conclusion?”  It may include qualitative as well as quantitative data, but should be at a high level.
  • 9. Organizational Breakdown
  • 9.1. Roles & Responsibilities
    INTENDED USE:
    This section is used to define the relationships within the project team members including their specific function and level of contribution .

    EXAMPLE: Individual(s) Role Responsibilities Executive Sponsor Meets with the Project Manager weekly to review the project plan and approve project plan adjustments Offers tactical business leadership and direction Removes business related barriers Client Provides business rule clarification Authorizes budget Provides business strategic direction Authorizes work and expenditures Provides access Removes obstacles Project Manager Communicates directly to the executive sponsor Works closely with the Project Sponsor and clients Project Member(s), communicating issues and changes that will impact the project Assists in all major project tasks, ensuring tasks are progressing and meeting the project objective Manages project resource utilization Tracks activity progress through the detailed project plan Manages the Issue Tracking Log Performs periodic reviews of the process and generated deliverables Creates a weekly periodic status report Relationship Manager (if appl.) Advises the project manager on issue resolution Partners with the project sponsor May participate on the steering committee Quality Advisor Performs periodic reviews of the process and generated deliverables Interviews selected Stakeholders and the Project Team to gain and understanding of project status and improvement opportunities Advises the project team on approach issues Assists in issue and conflict resolution Generates a summary report after each formal review May provide a project analysis following the project completion if deemed necessary Subject Matter Expert Expertise in a specific area of technology Expertise in a specific area of business Expertise in a specific area of methodology Project Leader Provides estimates to the project manager relative to activities within their area of expertise Directs the work of team members in their group Project Team Member Delivers project tasks Helps with project planning Data collection and reporting Produces deliverables Hands-on work Research and inventory

  • INTENDED USE:
  • EXAMPLE
  • 9.2. Governance Plans
    INTENDED USE:
    The governance plan details the established procedures for issue escalation and resolution. The process should reflect the organization structure as defined by the OBS and the responsibilities as defined in the Stakeholder and Customer section of this document.
    EXAMPLE:
    Issue Escalation
    Issues will surface weekly, if not daily throughout the course of the project. Effective issue tracking and resolution are critical to the success of the project. The following issue escalation process is recommended.
    Tier 1 – Project Team to Project Manager
    Project Team members escalate issues to the Project Manager who in turn documents the issue(s) on the Issue Tracking Log (see the Project Controls section of this document). The log is reviewed throughout the week by the Project Manager to ensure issues are being appropriately addressed and closed.

    Tier 2 – Project Manager to Quality Advisor
    The Project Manager escalates issues to the Quality Advisor to ensure the appropriate management members are fully aware of unresolved critical issues. The Quality Advisor will assist the Project Manager in resolving the issue, if possible. If resolved, the Project Manager will update the Issue Tracking Log and close the issue.
    Tier 3 – Project Manager to Project Sponsor
    The Project Manager escalates issues to the Project Sponsor to ensure the {Client} management members are fully aware of unresolved critical issues. The Project Sponsor will assist the Project Manager in resolving the issue, if possible. If resolved, the Project Manager will update the Issue Tracking Log and close the issue. In addition, the Project Manager will inform the Quality Advisor of the issue status and resolution if applicable.
    Tier 4 – Project Manager to Relationship Manager(Account Manager)
    The Project Manager escalates issues to the Relationship Manager if the issue requires exectuve representation.
    Tier 5 – Relationship Manager to Project Sponsor
    The Relationship Manager to attempt to gain closure on an issue prior to escalation to the Steering Committee. The Project Sponsor will assist the Relationship Manager in resolving the issue, if possible. If resolved, the Project Manager will update the Issue Tracking Log and close the issue.
    Tier 5 – Project Manager/Relationship Manager Steering Committee
    The Project Manager and/or the Relationship Manager escalates the most sensitive and urgent issues to the Steering Committee to ensure the appropriate {Client} senior management members are fully aware of unresolved critical issues. The Steering Committee will assist the Project Manager in resolving the issue, if possible. When resolved, the Project Manager will update the Issue Tracking Log and close the issue.

  • INTENDED USE:
  • The governance plan details the established procedures for issue escalation and resolution.  The process should reflect the organization structure as defined by the OBS and the responsibilities as defined in the Stakeholder and Customer section of this document.
  • EXAMPLE
  • Issue Escalation
  • Issues will surface weekly, if not daily throughout the course of the project.  Effective issue tracking and resolution are critical to the success of the project.  The following issue escalation process is recommended.
  • Tier 1 – Project Team to Project Manager
  • Project Team members escalate issues to the Project Manager who in turn documents the issue(s) on the Issue Tracking Log (see the Project Controls section of this document).  The log is reviewed throughout the week by the Project Manager to ensure issues are being appropriately addressed and closed.
  • Tier 2 – Project Manager to Quality Advisor
  • The Project Manager escalates issues to the Quality Advisor to ensure the appropriate management members are fully aware of unresolved critical issues.  The Quality Advisor will assist the Project Manager in resolving the issue, if possible.  If resolved, the Project Manager will update the Issue Tracking Log and close the issue.
  • Tier 3 – Project Manager to Project Sponsor
  • The Project Manager escalates issues to the Project Sponsor to ensure the {Client} management members are fully aware of unresolved critical issues.  The Project Sponsor will assist the Project Manager in resolving the issue, if possible.  If resolved, the Project Manager will update the Issue Tracking Log and close the issue.  In addition, the Project Manager will inform the Quality Advisor of the issue status and resolution if applicable.
  • Tier 4 – Project Manager to Relationship Manager(Account Manager)
  • The Project Manager escalates issues to the Relationship Manager if the issue requires exectuve representation.
  • Tier 5 – Relationship Manager to Project Sponsor
  • The Relationship Manager to attempt to gain closure on an issue prior to escalation to the Steering Committee.  The Project Sponsor will assist the Relationship Manager in resolving the issue, if possible.  If resolved, the Project Manager will update the Issue Tracking Log and close the issue.
  • Tier 5 – Project Manager/Relationship Manager Steering Committee
  • The Project Manager and/or the Relationship Manager escalates the most sensitive and urgent issues to the Steering Committee to ensure the appropriate {Client} senior management members are fully aware of unresolved critical issues.  The Steering Committee will assist the Project Manager  in resolving the issue, if possible. When resolved, the Project Manager will update the Issue Tracking Log and close the issue.
  • 10. Work Plan
    INTENDED USE:
    EXAMPLE
    INTENDED USE:
    This section of the document depicts a high-level work plan providing phases, milestones and major deliverables. Any application tools used for the management of the project are also specified.
    At this level the project plan details timeline information for milestones and deliverables. This can be represented in an outline format or an object originated in a scheduling application.
    Project Plan Guidelines: Refrain from using calendar dates Use ordinal dates to show timeline
  • This section of the document depicts a high-level work plan providing phases, milestones and major deliverables.  Any application tools used for the management of the project are also specified.
  • INTENDED USE:
  • EXAMPLE
  • 11. Project Control Strategies
  • 11.1. Quality Assurance
    INTENDED USE:
    This section describes the internal controls established by the Quality Assurance process.
    EXAMPLE:
    Tests required include unit testing, format testing (forms, screen design, prototypes, etc.) system testing unit testing, stress testing, environment testing, market testing. Forms and procedures may be documented here.
  • INTENDED USE:
  • This section describes the internal controls established by the Quality Assurance process.
  • EXAMPLE
  • Tests required include unit testing, format testing (forms, screen design, prototypes, etc.) system testing unit testing, stress testing, environment testing, market testing.  Forms and procedures may be documented here.
  • 11.2. Change Control
    INTENDED USE:
    Any change in scope could have an impact on the project charter, plan, schedule, or overall cost of the project. Policy issues regarding managing changes in scope will be detailed in this section.
    EXAMPLE:
    The Project Manager will notify the Executive Sponsor with a Project Change Request and seek the Client’s approval before proceeding to implement the changes. Change requests must be executed by the Project Manager. The Project Manager keeps a log of all changes. Each change requested must be resolved within 7 days and the reason for acceptance, denial, or postponement documented.
  • INTENDED USE:
  • Any change in scope could have an impact on the project charter, plan, schedule, or overall cost of the project. Policy issues regarding managing changes in scope will be detailed in this section.
  • EXAMPLE
  • The Project Manager will notify the Executive Sponsor with a Project Change Request and seek the Client’s approval before proceeding to implement the changes.
  • Change requests must be executed by the Project Manager.
  • The Project Manager keeps a log of all changes.
  • Each change requested must be resolved within 7 days and the reason for acceptance, denial, or postponement documented.
  • 11.3. Issues
    INTENDED USE:
    Issues are any events or situations that may arise during a project that may impede progress. This section is intended to identify how issues will be identified, addressed and resolved.
    EXAMPLE:
    Issues will be addressed at the lowest possible level. The Project Manager will keep an Issue Log and keep the Executive Sponsor apprised of all issues and their current state on a regular basis. Once identified, issues are to be logged by the Project Manager. The Project Manager will resolve the issue or escalate as appropriate. Issues will be reviewed as part of the standard Project Status reporting to ensure their resolution effort continues.
  • INTENDED USE:
  • Issues are any events or situations that may arise during a project that may impede progress. This section is intended to identify how issues will be identified, addressed and resol
  • EXAMPLE
  • Issues will be addressed at the lowest possible level. The Project Manager will keep an Issue Log and keep the Executive Sponsor apprised of all issues and their current state on a regular basis.
  • Once identified, issues are to be logged by the Project Manager.
  • The Project Manager will resolve the issue or escalate as appropriate.
  • Issues will be reviewed as part of the standard Project Status reporting to ensure their resolution effort continues.
  • 11.4. Communications
    INTENDED USE:
    A communication strategy must be established and documented in this section of the project charter. The strategy should reflect the vehicles used for inter-project communications between teams and the members of a project team. A project of substantial scope may require a separate communications plan.
    EXAMPLE:
    Status Reports
    Status Reports will be submitted to <the Client> on a <weekly> basis. These reports provide a snapshot of completed and upcoming tasks, issues and concerns and budgets.
    Conference Calls
    Conference calls will be held with <the Client> on a <weekly> basis. During these calls, the Executive Sponsor will have the opportunity to address any concerns or changes in the project and review the Status Report with the Project Manager.
    Meetings
    Meetings with <the Client> will be scheduled around the following milestones: <bullet list milestones. >
  • INTENDED USE:
  • A communication strategy must be established and documented in this section of the project charter.  The strategy should reflect the vehicles used for inter-project communications between teams and the members of a project team.  A project of substantial scope may require a separate communications plan.
  • EXAMPLE
  • Status Reports
  • Status Reports will be submitted to <the Client> on a <weekly> basis. These reports provide a snapshot of completed and upcoming tasks, issues and concerns and budgets.
  • Conference Calls
  • Conference calls will be held with <the Client> on a <weekly> basis. During these calls, the Executive Sponsor will have the opportunity to address any concerns or changes in the project and review the Status Report with the Project Manager.
  • Meetings
  • Meetings with <the Client> will be scheduled around the following milestones: <bullet list milestones. >
  • 11.5. Information Management
    INTENDED USE:
    This refers to the way information about the project will be documented, tracked, archived, revised, and accessed for internal project management purposes. It does not refer to documentation of the subject matter as a project deliverable. This information should be contained in the Project Workbook/Repository, maintained onsite by the Project Manager. This may, physically, be a binder, file set, and/or an electronic repository. Certain signed materials, including contracts, material acceptance forms and project change notices should be duplicated, storing the original materials at a secure facility.
    Project Workbook Repository
    In an effort to manage and maintain project documentation, the Project Manager will maintain a binder, file set and/or electronic repository of every completed report and form.
    Client Information
    Establish the process in which the project team will acquire, distribute and manage client information.
    Vendor Information
    Define the requirements and process necessary for gaining access to and managing information proprietary to any vendors that are involved in contributing the success of the project.

    The Project Workbook/Repository should include the following: Proposal and Project Charter Original, signed proposal, charter and contract Applicable Addendum(s) Project Plan Detailed Design Vendor documentation Industry reports Estimates Work Breakdown Structures/Schedules Original and Latest versions Issue Log/Resolutions Risk Assessments and Log Project Change Requests and Log Meeting Notes Charts and Graphics Current System reports and documentation Executive Status Reports Personal Status reports Project Status reports and Weekly Task Reports Project Financial Reports Project Correspondence Incoming and Outgoing Internal memos Final report and assessment Deliverable Acceptance Signoffs Final Deliverables Paper version (if appropriate) On-line version Purchase Orders/Invoices Financial Reports

  • INTENDED USE:
  • EXAMPLE
  • 12. Risk Management
    INTENDED USE:
    During the execution of the project, risks that have a potential negative impact on the outcome of the project may be uncovered. The project leader will use the Risk Management Log to implement formal procedures for managing issues on the project.
    A risk/opportunity questionnaire analysis will be scheduled to periodically review risk potential and subsequent risk management.
    EXAMPLE:
    Risk areas include changes to system, doc, lack of education/skills, etc. Identify risk areas and define who is responsible for monitoring as well as a mitigation process.
  • INTENDED USE:
  • During the execution of the project, risks that have a potential negative impact on the outcome of the project may be uncovered.  The project leader will use the Risk Management Log to implement formal procedures for managing issues on the project.
  • A risk/opportunity questionnaire analysis will be scheduled to periodically review risk potential and subsequent risk management.
  • EXAMPLE
  • Risk areas include changes to system, doc, lack of education/skills, etc.  Identify risk areas and define who is responsible for monitoring as well as a mitigation process.
  • 13. Logistics
    INTENDED USE:
    Describe in the Logistics section all the requirements for space, equipment, travel, etc..
    EXAMPLE:
    The project requires the following facilities and resources: A desk, cubical, or office space and furniture for 3 new individuals with a PC for each (PC requriements) A telephone that includes internal and external lines An additional, analog, remote access service telecommunications line A Token Ring or Ethernet network connection Computer network access and password Building access authorization for the facilities that team members will need to enter
  • INTENDED USE:
  • Describe in the Logistics section all the requirements for space, equipment, travel, etc.
  • EXAMPLE
  • The project requires the following facilities and resources:
  • A desk, cubical, or office space and furniture for 3 new individuals with a PC for each (PC requriements)
  • A telephone that includes internal and external lines
  • An additional, analog, remote access service telecommunications line
  • A Token Ring or Ethernet network connection
  • Computer network access and password
  • Building access authorization for the facilities that team members will need to enter
  • 14. Approval Signatures
  • 15. Glossary/Acronym
  • 16. Additional Related Documents
  • Legenda
  • Project Charter Template.mmap
  • Allerlei aspecten van een project die je in éeén A4’tje zou moeten willen hebben….
  • 1/1/2009
  • Reference
  • Martin van Vuure
  • Toe toevoegen zaken

Advertenties

Geef een reactie

Vul je gegevens in of klik op een icoon om in te loggen.

WordPress.com logo

Je reageert onder je WordPress.com account. Log uit /  Bijwerken )

Google+ photo

Je reageert onder je Google+ account. Log uit /  Bijwerken )

Twitter-afbeelding

Je reageert onder je Twitter account. Log uit /  Bijwerken )

Facebook foto

Je reageert onder je Facebook account. Log uit /  Bijwerken )

Verbinden met %s