Categories
- Agile (6)
- Architecture (1)
- art (2)
- Big Data (1)
- books (11)
- Cars (1)
- Change (9)
- common sense (3)
- Contracting (1)
- Cool (1)
- Design (5)
- development (1)
- emotions (3)
- entrepreneurship (2)
- google (1)
- great quotes (2)
- happiness (1)
- innovation (3)
- IT (8)
- IT Architecture (3)
- Knowledge Transfer (2)
- leadership (3)
- Lean (1)
- links (1)
- literature (1)
- lyrics (1)
- management (9)
- Media (1)
- Negotiating (1)
- networks (1)
- people (5)
- Personal Improvement (8)
- planning (5)
- productivity (3)
- Programming (1)
- Project Management (23)
- Projects (1)
- psychology (3)
- Requirements (5)
- Risk (2)
- scrum (2)
- strategy (6)
- struggle (1)
- summer (1)
- teams (5)
- Test Automation (3)
- thinking (5)
- Training (2)
- Travel (1)
- waterfall (4)
Tag Cloud
Agile
Architecture
art
Big Data
books
Cars
Change
common sense
Contracting
Cool
Design
development
emotions
entrepreneurship
google
great quotes
happiness
innovation
IT
IT Architecture
Knowledge Transfer
leadership
Lean
links
management
Media
Negotiating
people
Personal Improvement
planning
productivity
Programming
Project Management
Projects
psychology
Requirements
Risk
scrum
strategy
teams
Test Automation
thinking
Training
Travel
waterfall
Project Charter Observations
Posted by Rich Crowley in Project Management
In my experience, organizations create charters in two distinctly different ways. Some use the charter as one of the first documents created in the project life cycle. For these organizations, the charter is a stake in the ground to give all stakeholders identified to that point some insight into the key high level attributes of the project. It tends to be a brief document because often there is still a large list of unknowns about the project.
Other organizations like to create a much more comprehensive project charter document that is only published once the list of unknowns in the project is whittled down to a much shorter list. For projects with IT involvement, such a charter would typically be done after business requirements have been completed and approved and perhaps architecture and high level design established as well.
My preference is to have a charter established as early as possible once a project has been approved. The value in this, even though the document is often very light on detail, is that it serves as the driver for getting the sponsor and project manager on the same page and it allows these two stakeholders to jointly set and manage project stakeholder expectations. Managing projects where the charter is not created until much later provides too much time for stakeholders to form their own ideas about what is in scope, who is accountable for what, what the time line is, what the key deliverables and critical success factors are, etc.