-
When IT Is Your Company’s “Piggy Bank”
February 10, 2012
-
4 Key Things a Project Manager Must Do
February 10, 2012
-
Essential Project Management
February 10, 2012
-
8 Traits of Top Project Managers - Part 1
February 9, 2012
-
Agile Project Management - Engaging Your Customer!
February 9, 2012
-
9 Tips to Avoid Traps in Project Planning
February 9, 2012
-
Why Projects Succeed - Executive Sponsorship
February 8, 2012
-
On Customer Participation in Agile Projects
February 8, 2012
-
A Project Charter for Lazy Teams
February 8, 2012
-
The Power of Process: How Bad Project Management Kills Great Ideas
February 7, 2012
On Writing the Project Charter
May 24, 2009 | Author: PM Hut | Filed under: Uncategorized
On Writing the Project Charter
By Joseph Phillips
The project charter authorizes the project. This document launches the project and gives the project manager the authority to use organizational monies and resources to reach the objectives of the project. It’s a powerful document, and without one of these you’re setting yourself (and often your project) up for failure.
When I consult or teach on project management there’s always some discussion about the project charter and who creates the thing. For some organizations the charter is a boilerplate document. The project manager and customer slap in some details, and it’s considered done. In other organizations the charter is written entirely by the project sponsor. While still other project managers report that they write the charter, and the project sponsor signs the charter as if they wrote the thing.
Here’s what matters when it comes to writing the project charter – it doesn’t really matter who writes the charter as long as the person who signs the charter is the right person. In other words, the person backing up the charter must be the person with the authority to back it up. The person signing the charter should have the authority within the organization to grant the project manager time, money, and resources to reach the project objectives.
Joseph Phillips is the author of five books on project management and is a, PMI Project Management Professional, a CompTIA certified Project Professional, and a Certified Technical Trainer. For more information about Project Management Training, please visit Project Seminars.
Related Articles
feel free to leave a comment
Comment Guidelines: Basic XHTML is allowed (a href, strong, em, code). All line breaks and paragraphs are automatically generated. Off-topic or inappropriate comments will be edited or deleted. Email addresses will never be published. Keep it PG-13 people!
XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>
All fields marked with " * " are required.
- Agile Project Management
- Ask the Hut
- Certification
- Change Management
- Communications Management
- Computer Based Information Systems
- Concepts
- Corporate Transformation
- Cost Management
- Critical Chain Project Management
- Delegation
- History
- HR Management
- Implementing Project Management
- Integration Management
- Lessons Learned
- Management
- Miscellaneous
- People Issues
- PMBOK
- PRINCE2
- Procurement Management
- Program Management
- Project Lifecycle Phases
- Project Management Advantages
- Project Management Advantages
- Project Management as a Career
- Project Management Best Practices
- Project Management Charts
- Project Management Definitions
- Project Management Ethics
- Project Management for Beginners
- Project Management Guides
- Project Management Musings
- Project Management Office
- Project Management Proposals
- Project Management Templates
- Project Portfolio Management
- Project Workforce Management
- Quality Management
- Requirements Management
- Risk Management
- Scheduling
- Scope Management
- SCRUM
- Soft Management
- Time Management
- Training
- Uncategorized
1 person has left a comment
This is a great point. All too often, people rely on documents as proof that something is a priority, or that it’s going to get done. Documentation is a great way to get everyone on the same page (as it were), but they aren’t a great way to show what’s at the real core of a project.
In the end, relationships are more important than what’s on a piece of paper. If the plan says one thing, and the boss says another, there’s no question of who’s going to get their way.