The Project Charter is one of the first major deliverables in a classical project management practice. Does it apply to Agile practice? First, let us look at what should be some key information included in the charter (from PMBOK® section 4.1.3):
- Project purpose
- Measurable project objectives and related success criteria
- High-level requirements
- High-level project description, boundaries, and key deliverables
- Overall project risk
- Summary milestone schedule
- Preapproved financial resources
- Key stakeholder list
- Project approval requirements (i.e., what constitutes project success, who decides the project is successful, and who signs off on the project
- Project exit criteria (i.e., what are the conditions to be met in order to close or to cancel the project or phase)
- Assigned project manager, responsibility, and authority level
- Name and authority of the sponsor or other person(s) authorizing the project charter
Given the information included in the project charter, is there anything here which one does not need in an Agile environment? Here are a few examples of what changes one can make to the above to fit in with an Agile practice:
- High-level requirements and key deliverables: There could be some of these, but all of these may not be known for the ultimate end state. These could be the minimum viable product (MVP) to start.
- Milestone schedule: This could be associated with the sprint plan to get to the MVP. There still may be similar milestones to a waterfall process. For example, instead of completing all requirements and approving them, completing the first user stories and approving them would be the goal. While the language may change, the purpose of the milestones is the same.
- Project approval requirements: Like the milestone schedule, this can be acceptance of the MVP and a plan for what will be a client deliverable along the sprint plan and approvals needed along the way.
- Assigned project manager: While I would always advocate having one, I realize the Product Owner and Scrum Master roles may be doing some PM duty, especially in small organizations. Everyone should know what their duties are, regardless of the titles.
Most of the other elements of the Project Charter do not seem out of place in an Agile environment. Knowing the purpose of the project, objectives and success criteria, risk, financial backing, stakeholders, exit criteria, and having a project sponsor all still seem like great ideas to be successful, yes? Therefore, the project charter is still a necessity in an Agile world, and one should not leave it out for the sake of being Agile. Change the terminology to fit the method. Just because the terminology does not fit does not mean it is not part of an Agile process.
The next post in the Agile Project Management series will take a pragmatic look at the Project Charter and turn it into a series of questions anyone can use.
- PMBOK® Guide – Sixth Edition
- Agile Chartering – Beginning With The End In Mind, Robert Galen, PMtimes.