• Like
Project charter presentation
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.

Project charter presentation


Project charter presentations are used during the meeting with the Project Sponsor or Steering Committee. This meeting is organised in order to get the sign-off under the final copy of the project …

Project charter presentations are used during the meeting with the Project Sponsor or Steering Committee. This meeting is organised in order to get the sign-off under the final copy of the project charter document. When during the meeting some alterations or new decisions are made then the corresponding document should be altered.

Published in Business , Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
  • Very comprehensive presentation. It would have been best if few suggested examples were put under Risk assessment, and Consequences for Implementing the project.
    Well done though.
    Are you sure you want to
    Your message goes here
  • MM-EM / MBA reference...

    Capstone and Training Program for MM-EM due first week December.
    Are you sure you want to
    Your message goes here
  • Good presentation, though would appreciated more detail on risk, especially on how to classify/ prioritise project risks
    Are you sure you want to
    Your message goes here
No Downloads


Total Views
On SlideShare
From Embeds
Number of Embeds



Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

    No notes for slide


  • 1. Project Charter Presentation Template Author: Bogdan Gorka, PMP
  • 2.
    • The project charter (sometimes referred to as Project Definition Document) defines the key project dimensions such as scope, objectives and overall approach for the work to be completed. It is the most important point of reference for project stakeholders interested in the project rationale, its goals and scope. Project charter is also a written contract between the Project Team and Project Sponsor stating clearly what is expected from the project.
    • This template can be used as a guideline about the contents for project charter presentation
    • Such presentation can be short for the overview purposes or can be detailed depending on the Sponsor’s appetite for details
    About this presentation Project Management Methodology Fundamentals |
  • 3. Meeting agenda
    • Welcome 09:00 - 09:15
    • Project Overview 09:15 - 09:35
    • Strategy Alignment and Scope 09:35 – 10:30
    • Break 10:30 – 10:40
    • Organisational Impact 10:40 – 11:00
    • Identified Requirements overview 11:00 – 11:10
    • Project Delivery Approach 11:10 – 11:30
    • Decisions 11:30 – 12:00
    • Other issues
  • 4. Project Overview Project Tempo
  • 5.
    • In this section describe the general project background and business context. This may come from your overall business strategy or be a result of the previously completed feasibility study. In this section describe briefly why the organisation is interested in pursuing with the project. Put enough information here so the general rationale for the rest of the documents is clear.
    • An organization's business need or new opportunity may be based on a market demand, technological advance, required training, legal requirement, or governmental standard.
    • This section may also refer to a separately prepared business case analysis and recommendations included there
    Organisational Context Project Management Methodology Fundamentals |
  • 6. Problem statement – justification for action
    • Instead of writing ever present ‘Project Scope’ I would suggest starting off with clearly stating problems that we are we addressing. That is why I propose the structure as below:
    • 1. Problem statement – state just facts that made you think that you want a change, what basically bothers you and why this induced you to action. This should shortly represent the nature and setting of difficulties that the organisation is currently facing and be powerful enough explaining by the organisation is determined to get rid of these difficulties. In other words it is the project’s business driver.
    • 2. Project Final Outcome – After project desired state – how it will look like when the problem is solved. The statements in this section becomes automatically the success criteria to be measured after the project completion. It is another name for project goal which describes the future and directs the planning activities.
    • To help you understand the difference:
      • Project output (Objective): New document management system installed and functioning
      • Project outcome (Result): Incoming documents are processed more quickly and accurately (and that can be put in measurable dimensions)
  • 7. Project Mission
    • Although this section should be relatively short, it is pretty difficult to write it. Try to describe generally but in a straightforward way what effect you are trying to achieve by delivering project results.
    • Example:
    • To cut general effort required for paperwork in the office by introducing a new document management system enabling company-wide access to business documents along with electronic workflow and sign off. The project should be completed by the end of year 2010 with the budget not exceeding $1m in capex.
    • In this way we have a short story for everyone interested in what the project is about and what are the limits set by the Sponsorship.
  • 8. Strategy Alignment Project Tempo
  • 9. Business Strategy Alignment
    • Before stating further what the project is about, we must ensure that it is in this way or another aligned with the corporate strategy
    • Project that are cross functional and are not aligned with strategy will be very difficult to run due to the following reasons:
      • Lack of interest in the project from the Project Sponsor’s peers
      • Difficulty to find good and reliable internal resources to deliver project scope
      • Lack of involvement from the internal resources will result in underdeveloped scope statement and undiscovered risks
      • Eventually the project almost certainly will not get funded or will be abandoned during or after the design phase.
  • 10. IT Strategy Fit
    • If the project will use the IT resources, it should state clearly how much the proposed solution is aligned with the existing systems and networks architecture
  • 11. Objectives and Scope Project Tempo
  • 12.
    • Project objectives describe what tangible results the project works will deliver. In order for the project objectives to be truly tangible, they have to be specific and concrete. It is best achievable when they are deliverable based.
    • In this way, the completion of any given objective will be evident when one of more deliverables are done.
    Project Objectives Project Management Methodology Fundamentals |
  • 13. Project Objectives and Scope of Delivery Project Management Methodology Fundamentals | Project Objective Deliverables
    • Standardise and update existing document flow procedures
    1. Existing document flow procedures identified 2. Procedure owners identified 3. New procedures designed and written
    • Search and select software vendors for document management systems
    1.Research systems vendors on the market 2. Perform Request For Information Process as per Vendor policy 3. Collect RFI feedback and prepare solution selection guidelines
    • Prepare Requirement statement
    1. Select potential key users for workshops 2. Prepare and organise user requirements elicitation workshops 3. Summarise requirements in the User Requirements Traceability Matrix
    • Other objectives
    Other deliverables
  • 14.
    • Out of scope:
    • It is important to clearly state what results / deliverables will not be delivered. Sometimes key project stakeholders have some expectations they think will be delivered on the occasion of a new project. They should be informed, and especially the Steering Committee, that these features, results or deliverables are out of scope and will not be prepared. Managing expectations is crucial taking into account that the project charter serves the role of a contract between the Project Team and Project Sponsor.
    Scope exclusions Project Management Methodology Fundamentals |
  • 15. Impact on organisation Project Tempo
  • 16. Organisational Impact
    • It is necessary, in order to get a full picture, to describe how this project will change the current status quo of the organisation. If the change is big, the project charter should include only a summary of the full change assessment analysis separate document.
    Organisation/Department/Processes How will the be affected/No of people impacted
    • Mail Office
    Current practices in documents flow will be identified and changed considerably. No mail handling is currently done electronically and employees are not used to working on computers. After the project both the procedures and tools will change.
    • Accounts Receivable
    Currently only some invoices are being signed-off electronically. For now it is the project intention to include this work-flow fully in the scope. Affected 50 people.
    • Entire business – budget scope
    When the affected department will change into a fully electronic workflow this will mean that the budget of $10m spent annually will be managed differently. That is why this project is more risk sensitive and is business continuity critical. That is why only safe and proven solutions will be chosen.
  • 17. Another template for Business Impact
    • The Consequence of implementing the project:
    Area Impact
  • 18. Process Change Impact
    • List which business processes will be affected by the project
    Organisation area Process Name
    • Finance Department
    Accounts Receivable Accounts Payable Manual invoicing
    • IT Department
    Application landscape update
    • Mail Office
    Invoice processing TOTAL: 23 processes
  • 19. System Change Impact
    • Which existing systems be affected by the project
    • What existing interfaces will have to be upgraded, changed
    • Overview of data to be migrated
    • State generally if the change is considerable in terms of risks and resources
  • 20. Business Requirements Overview Project Tempo
  • 21. High Level Business Requirements
    • What the end result should be / look like
    • What business result are you trying to achieve. Describe it in such a way that the expected quality of results will be easy to understand
  • 22. Project Delivery Approach Project Tempo
  • 23. Implementation Assumptions
    • (Assumptions made about the project related to resources, scope, expectations and schedules.)
    • Implementation Approach - Assumptions
    • The solution will be introduced with the implementation partner using the following assumptions
    • We will use the pre-configured DocuNext solution dedicated for the mining industry. The re-design of existing processes will be based on the gap analysis between the AS-IS process map and the preferred TO-BE map
    • The system launch will be performed at all locations in one time – the big bang approach
    • We will implement the system in two waves – most crucial functionalities first and additional remaining functionality next
    • We will use the PRINCE2 methodology with PMBOK elements
    • We will use the VISIO based process maps and convert them later into our ARIS corporate model
  • 24. Implementation Constraints
    • Implementation Approach – Constraints
    • The first way of implementation cannot exceed 1 April 2011
    • The budget for this project cannot exceed $1.5 for both implementation waves
    • Some 25% of future system users are not competent in basic PC usage.
  • 25. Training Approach
    • The project will adopt the a train-the-trainer approach where project key users will be trained on the advanced usage of the system
    • Users in other locations will be invited to one of the two training facilities in Adelaide or in Melbourne
    • In order to accelerate the training process we will use the Computer Based Training tools and pre-recorded short movies.
  • 26. Change and Communication Approach
    • Business Change and Communication Approach
    • The impact of the project on the organisation will be considerable and it is very important for the business community to understand why the project is being commissioned and what benefits are expected after the implementation.
    • Below is the outline of the approach to introduced in this project:
    • Fixed dates of meetings with Project Sponsor and Steering Committee every six weeks
    • Steering Committee Stage Gate meetings confirm the completion of each phase
  • 27. Project Communication Approach
    • HR Department will be involved in spreading the word-of-mouth about the project using their regular communication channels. They will be well briefed and equipped with the information pack.
    • Project internal communication will be done via weekly Status and Risk Meetings as well as the project message board.
    • Communication to the future users community will be executed by the monthly Newsletter containing the key milestones completion, information about project team and current progress
    • We will periodically do a research of users’ community perception of the project to be able to counterpart any misunderstanding or myths
  • 28. Project Reporting
    • Project reporting will include:
      • Weekly team leaders’ status reports – for Project Manager
      • Weekly project status report – for Sponsor
      • Monthly project status report – for Steering Committee and external communication
      • Steering Committee status presentations – for cycle meetings every 6 weeks
  • 29. Project Implementation Schedule - Project Approach -
  • 30. Project Schedule
    • Overview of Project Schedule:
    Phase Phase Start / End dates Milestone Deliverable Discovery Phase Scoping & Visioning Design Phase Construction Phase Testing &Delivery Phase Go live with Pilot Sites Roll out and Project Close out Sign-off
  • 31. Project Organisation and Resourcing
  • 32. Project Team Structure - Project Organisation and Resourcing -
  • 33. Project Team Structure 1 x Steering Committee 1 x Project Manager Process Owners Executive Sponsor Functionality Team Applications Team Technical Team Change Mgt & End User Training
  • 34. Roles and Responsibilities - Project Organisation and Resourcing -
  • 35. Steering Committee
    • The Steering Committee for this project includes the Executive Sponsor, Process Owner, Project Manager, Team Leader. On behalf of the Board, their responsibilities include:
      • Verify the business requirements and scope
      • Approve organisational, policy, and strategic changes.
      • Committee necessary resources and budget on enterprise basis.
      • Authorise changes to the plan
      • Make timely decisions
      • Educate peers and staff on the merits of the project
      • Ensure integration across the project is attained
  • 36. Process Team Management
    • Executive Sponsor:
      • Ensuring process view of the Project.
      • Chairing monthly process team meetings.
      • Providing guidance and direction to process team (from Board perspective).
      • Resolve process and organisational issues.
      • Resolve personnel issues.
      • Ensure broad base involvement and business ownership.
      • The executive sponsor is responsible to collect track and analyse the benefits from a process change. He or she is also the primary point of contact with the business process owner. Together, they are responsible to improve the processes, using the measured benefits as feedback information
  • 37. Process Team Management (Cont)
    • Process Owner:
  • 38. Process Teams
    • (Functionality, Applications, Technical, Training and Change Management)
  • 39. Project Risk Assessment
  • 40. Project Risk Assessment Summary Identified Risk $ Impact and mitigation strategy
  • 41. Project Financial Justification Project Tempo
  • 42. Cost Justification Methodology Estimated Potential Benefits Estimated Implementation & Support Costs Net Savings Benefits Costs A B C - = Minus: Equals:
    • Over the Analysis Period
    • Operational Benefits
    • Avoided future planned projects
    • One-Time Costs
    • Staff Related Costs (internal and external)
    • Hardware
    • Software
    • Facilities
    • Training
    • Other
    • On-Going Costs
    • Operational support
    • Hardware
    • Software
    Net Saving from Implementation
  • 43. Financial Assumptions
    • (The financial analysis presented in this document reflects the information and assumptions available to the project team at this time …)
  • 44. Project Implementation Costs
    • Paste the project preliminary budget including separate budget for identified risks
  • 45. Maintenance (ongoing) Costs
    • Present costs that will be borne to maintain the project results after the completion
    • Include additional headcount, licenses, service agreements
  • 46. Cost Savings
    • As a result of calculations show the logic behind and calculations which justify the costs of the project
  • 47. Benefit Realisation - Project Justification -
  • 48. Benefit Realisation Plan
    • Who by name is the owner of the benefits to be reviewed after the project completion
    • What is the role of this person during the project
  • 49. Cost vs Benefits Summary - Project Justification -
  • 50. Cost vs Benefits Summary
  • 51. Conclusion / Questions ?