In this article I discuss how I’ve successfully utilized Project Charters while working on Agile Scrum projects in the past, how to structure these types of documents, and provide some advice on how best to apply the ideas in this article within your own projects.

“But wait!,” you may be thinking at this point. “Project Charters are a component of predictive project management methodologies! I don’t want to become an AgileFall team!”

Have no fear, dear reader. I won’t be advocating for AgileFall or trying to sneak it in on you via the Project Charter trojan horse gambit. I believe traditional Project Charters can be modified to serve Agile purposes and become an asset to your next project. I’ve used them in the past to great effect on Agile initiatives, and hopefully, after reading this article, you’ll have some ideas on how you can leverage them as well.

What is a Project Charter?

First, what is a Project Charter (PC)?

According to ProjectManager.com, a PC is “… the statement of scope, objectives and people who are participating in a project. It begins the process of defining the roles and responsibilities of those participants and outlines the objectives and goals of the project. The charter also identifies the main stakeholders and defines the authority of the project manager.”

OK, that doesn’t sound too bad so far except for maybe that part at the end about “defining authority of the project manager” since Agile teams are self-managing.

Next, the Project Management Institute (PMI) has this to say about what a PC is:

“The charter is a project’s best marketing tool. It is created at the very start of the project, when the selling of the project’s goals and ideas needs to begin. It is an ideal place to document the relationships between the project and the organizational strategy.”

This is starting to sound pretty good in the context of Agile Scrum. Clearly, even for an agile project with lots of pivots, we’ll want to articulate the project’s benefits, why the project has been started in the first place, what value the project will deliver to customers, what sort of return on investment we might expect, etc.

Let’s examine a final definition from Wikipedia to round things out:

“In project management, a project charter, project definition, or project statement is a statement of the scope, objectives, and participants in a project. It provides a preliminary delineation of roles and responsibilities, outlines the project’s key goals, identifies the main stakeholders, and defines the authority of the project manager.”

A Common Theme

Reviewing the sources above we can observe a common theme starting to form; we want a document that is created at the beginning of a project that does the following::

  • Defines the objective of the project
  • Defines who is involved in the project
  • Defines how the project aligns with the organizational goals and what value it delivers

These goals, quite frankly, would be good things to have irregardless of the project management methodology utilized, and apply equally to both Agile and Waterfall projects. In fact, this almost reads like the agenda of a kick off meeting.

However, unlike a kick off meeting we now have a written record of why we started this project. We can share it with others in the organization for transparency, comments, edits, etc., and even collaborate on it with our vendors and customers if appropriate. We can also place it under version control and document the pivots and changes that occur over the project’s lifetime.

Structure

But what about the structure of the PC? Do we have to follow some stuffy format when writing a PC that would garner stern looks from our Waterfall brethren if we didn’t follow it?

“Some project managers may be misled by the word ‘document’ in the definition and by the specific list of information in PMBOK. They fear that they do not have a project charter unless they have a specific document formatted with certain headings. The PMBOK® Guide does not mandate the use of any specific document format, and project charters can take many forms. Often the charter appears in the form of a free-form email or memo.” PMI

So it appears we can be rather flexible–even Agile, we might say–when creating a PC that meets our organizational and project needs.

Writing the Project Charter

We now have an idea of what should be in the PC, and we know we can create it in a way that best suits our needs. Keeping this in mind, I have found two main use cases where I have employed PCs successfully:

  • I’m working with an external party on a development project either as supplier or purchaser.
  • I’m working with internal teams who implement Agile, but they need to interface with other departments who are not Agile or are not as familiar with Agile (think Sales for example, or upper management).

Use Case One: External Parties

The most common contract I have encountered when delivering or consuming third party development services is a time and materials agreement with an Agile Scrum framework wrapped around it.

If you think about it, this actually makes a lot of sense for both parties: Every two weeks (or at whatever frequency you agree to run the sprints at), the purchaser receives a set of finished deliverables, and they have full power to pivot and make changes based on their needs and how the project is progressing.

There isn’t a need for a complicated set of change management processes with updated contracts and deliverable fee schedules, for example. Every two weeks, both parties align on the deliverables and scope of work, and both parties know what the next set of charges and costs will be. Once the right amount of work has been done to meet the purchaser’s objectives, they can wrap up the contract and call it a day.

However, despite the fluidity of this working relationship, there is certainly something to be said for starting things off on the right foot and having everyone aligned. There are also those logistic and organizational concerns, such as who is the point of contact (POC) for various issues? How are communications managed? When do meetings occur and with whom? What are the major anticipated milestones, etc.

I have found that not having some structure around these items only serves to slow the project down, which is precisely where the PC comes into play: It fills in the gaps between logistical items, such as those discussed above, that won’t be in the formal service contract agreement but also aren’t clearly defined in the context of the Agile Scrum framework.

I usually write this document in a collaborative tool, such as Google Documents or MS Office 365, that can be easily shared and collaboratively worked on, and I’m not shy about updating it as the project progresses and pivots are made. (Think software versioning except for a project management document.)

Since we are utilizing an Agile methodology, changes to the milestones, objectives, acceptance criteria, etc. may very well change as the deliverables are examined at the end of every sprint. When this happens, I simply update a new version of the document with whatever changes were made. This takes little to no time and provides an interesting narrative of how the project progressed over time. It’s also a great tool when performing the end-of-project post mortem and lessons learned, because you have an audit trail for the project’s pivots and changes.

Below is the outline of the PC I’ve successfully utilized in the past, and I’ll provide some commentary for each heading afterwards as well.

  • Executive Summary
  • Scope Statement
  • Assumptions
  • Deliverables
  • Project Milestones
  • Stakeholders
  • Team Members
  • Procurements
  • Project Resources
  • Communication Plan
  • Risks

(You can find a PC template here, which you can download and modify to suit your needs.)

Executive Summary

I like to include a high-level summary in this section, describing what the project is trying to accomplish, why the project has been initiated, what benefits are expected from the project, and so forth. This may change, of course, as the project pivots and the learn-measure-build cycle repeats, but having some context is very helpful to those doing the work. You never know what new and interesting ideas someone might come up with if they understand the big picture of where the project is trying to go and what it is trying to accomplish.

Scope Statement

This section deals with more of the implementation details. So, for example in the “Executive Summary” section we documented the business reasons for the project, and now, in this area, we draw the boundaries around what sort of efforts we are going to go through to achieve the project’s goals.

Assume we are creating a new mobile application to interface with our core product, for example. Perhaps in the beginning we only want to create a minimum viable product (MVP) for one type of mobile phone until we validate that there is a demand justifying further development. As such, our scope statement might be something like this:

In Scope

  • Create a new mobile interface to support customer requests through our application, but only support the Motorola Edge model running Android initially until customer validation has occurred.

We might also explicitly exclude items from the project’s scope too:

Out of Scope

  • Support for offline functionality is out of scope for this project due to lack of customer interest and a possible lack of return on investment.

This clearly helps everyone stay on the same page and ensures that time, resources, and money aren’t spent on the wrong things. Sometimes you’ll find that documenting what is out of scope is more important than what is in scope!

And this is doubly so when dealing with outside vendors providing development work. In these instances, miscommunications about scope almost ALWAYS result in delays and additional costs. Best to head them off right at the start!

Assumptions

This is a great place to call out and document those items that might become “gotchas” as the project progresses. I have found it is always easier to coordinate teams at the beginning of the project vs. halfway through, and identifying assumptions is a great tool to support this.

Let’s look at some actual examples:

  • Company ABC will develop both the front end portions of the project, and the internal team will create the Python backend integration work.
  • The internal and external teams will integrate as much as possible to maximize project visibility and touchpoints. As such, there will be a joint JIRA board, shared Slack channel, and Confluence documentation area created that will be fully accessible to both teams.
  • The project’s back and front end architectures can be worked on independently and concurrently. Work should begin on both portions, starting with the first sprint.
  • The front end team can utilize mocks of the back end data model as provided by the internal team to develop against initially. These have already been created and are ready for use.

Each of these assumptions will clearly impact how the project progresses, and ensuring everyone understands them is critical to reducing misunderstandings and wasted effort.

Deliverables

We want to be a little bit careful with this section. Since we are utilizing Agile Scrum, the deliverables may very well change over the course of the project. Perhaps after one of the sprint reviews or after a customer validation session, the Product team will modify the project’s roadmap/backlog contents.

I have found two methods to deal with this:

First method: Keep the deliverables section at a very high level, so that pivots and lessons learned don’t cause dissonance with the statements in this section.

Ex: Create a mobile application providing the customer access to their account details on a cellular platform.

Second method: Include more granular details, and don’t be shy about documenting changes to the deliverables in the updated versions of this document. I talked about this philosophy at the beginning of this article, for example.

Another consideration is what is expected when two organizations are working together (vendor and client, for example), and the final project hand-off occurs. This is a great place to list what will be needed for the project completion transition, so nothing falls through the cracks.

Examples include:

  • Architecture documentation, such as API endpoints, data structures, and the like
  • How monitoring, troubleshooting, etc. has been implemented
  • Requirements and deployment needs from an infrastructure standpoint. For example, is this a containerized implementation that needs to be integrated with the existing container orchestrator?
  • Final integration testing, QC validation report, and acceptance criteria validation

Project Milestones

We also want to be a bit careful with this section, too, so that we don’t delve off into the land of Waterfall project management. Enumerating a list of project milestones with due dates doesn’t really support pivoting and applying lessons learned after each sprint cycle.

However, I have found that the milestone area can be of great use as a set of event triggers for when to communicate with other departments (Sales, Marketing, and Support, in particular). I’m sure we’ve all worked on a project where development and testing wrapped up, the CEO is chomping at the bit to release, and sales and marketing find out to their horror that they now have a week to create all of the marketing materials, sales demo workflows, and the like because this project was never on their radar as nearing completion.

The Project Milestone section; however, can provide those trigger points of when to communicate with the other teams and departments as key portions of the project complete, so we avoid situations such as the one described above. For example, a milestone for the user interface (UI) being completed could signal that the marketing team needs to access the project on the test server and begin taking screenshots for the brochures and email announcements. Or perhaps once the final testing milestone is reached the support team begins training on the new project’s functionality, so that when production rollout occurs they can resolve customer issues quickly.

Stakeholders

What is a stakeholder? A stakeholder is either an individual, group or organization impacted by the outcome of a project. They are interested in the project’s success and can be within or outside the organization that is sponsoring the project. Stakeholders can have a positive or negative influence on the project. [Source] (https://www.projectmanager.com/blog/what-is-a-stakeholder)

I usually write this section as a table of which Agile Product Owners are representing the project, any other internal team members that have a stake (ex: the head of financing for a billing system overhaul project), and anyone else who might be interested in project updates and news (ex: the customer representative who is managing the development contract).

I will also sometimes include team members from external parties if appropriate.

Team Members

I usually make two tables in this section: External team members and internal team members. This provides a “phonebook” of sorts so that it’s easy for anyone on the project to find anyone else. I include all the technical people, the product owner(s), scrum master(s), etc.

You can, of course, add additional tables and sections depending on the logical organization of the teams and/or companies involved in the project.

Procurements

Despite having a fancy heading title, this is mostly where I enumerate work that needs to be done to support the project. For example, here are some example procurements from a recent project I managed:

  • Create and provision git repositories
  • Prepare development environment setup materials for the contracting team
  • Create contracting team accounts for Confluence, Jira, and Slack
  • …

Each of these items had a direct impact on our ability to quickly integrate the contracting team into the project, and having them in the PC makes remembering and tracking them easy.

Project Resources

I dedicate this part of the document to documenting the locations (including links where possible) for all the project resources, such as wireframes, system documentation, look-and-feel guidelines, etc.

For example, in my last project I had several sections detailing the project resources broken up per department, which included links and descriptions for each item. Here is an excerpt:

  • Product Management
    • Wireframes
    • UX/UI Requirements
    • Customer personas
    • …
  • Development
    • Backend Entity Relationship Diagram (ERD
    • Code standards guidelines
    • …
  • Project Management
    • JIRA Board
    • Project Charter (this document)
    • …

This made it very easy for members of the project to quickly find the reference and documentation resources they needed. Each item has a description and a link to the actual documentation for quick reference.

Communication Plan

Frankly, this is probably the most important part of the PC. I document how we will communicate as a project team (i.e., email, slack, etc.), when meetings and other structured communication occur, whom to go to for general questions and the like for each team/department, and any conflict resolution procedures. This section will likely be highly customized as per the needs of your project, team, external parties, and organization.

Here is an example of how I broke this up for my last project into logical segments:

Project Members

[Insert tables here broken down by department and/or organization. List name, title, department, email, and phone. Also, any other details that might be required to contact each person, such as time zone for international resources, etc.]

Communication Methods

Project communications will take place via one of these methods:

  • Zoom video calls
  • Email
  • Slack
  • Written documentation in Confluence

Meeting Schedule

The following meetings will occur to support the project:

  • Daily scrum at 9 AM with the following attendees…
  • Weekly touch base at 10 AM with the following attendees…
  • Full system demo scheduled the first Monday of each month at 11 AM with the following attendees…
  • …

Out of Band Communications For day-to-day ad hoc communications not falling into the meeting schedule above:

  • Billing, contract, scope/schedule adjustments - John Doe
  • General technical questions for the internal Dev team - Sally Johnson
  • Architecture/systems questions - Chad Henderson
  • …

Technical Conflict Resolution Process Should the ABC and XYZ development teams disagree about the technical details, implementation and/or design, the following conflict resolution process will be followed:

[List whatever conflict resolution steps are appropriate here]

Once the decision has been made on how to proceed, utilize one or more of the steps below:

  • The final decision will be documented and disseminated out the engineering teams along with any appropriate supporting documentation, narrative, scope change, etc.
  • …

As I stated before, you may find you want more or less content in this area depending on your needs and project.

Risks

This doesn’t need to be a full-blown PMP style risk discovery, documentation, and planning session. I find with Agile projects a simple table of the risks along with the mitigation plan suffices. You might also include who is responsible for monitoring and executing the mitigation actions if appropriate.

Here are a few examples from a past project:

Risk:

  • Project milestones become blocked and/or delayed

Mitigation:

  • Daily scrum meetings will be held to identify blockers; the company ABC and XYZ project managers/scrum masters will collaborate daily to remove/resolve blockers.
  • Additionally, company ABC and XYZ’s management will meet weekly to measure project progress and take leadership level actions to resolve blockers, provide the development teams with required resources, etc.

Risk:

  • There are additional questions regarding the requirements from the vendor team

Mitigation:

  • Both Sally and John from the Product Management team will be available via the out of band defined communications to answer ad hoc questions during the sprint,
  • John will be present at the daily scrum, and Sally will be available during the weekly project status meetings to answer requirement-related questions._

Internal Teams Only

For projects that only include internal teams, I utilize much of the same type of PC as I described above with a few possible modifications described below. For reference, here are the PC headings again:

  • Executive Summary
  • Scope Statement
  • Assumptions
  • Deliverables
  • Project Milestones
  • Stakeholders
  • Team Members
  • Procurements
  • Project Resources
  • Communication Plan
  • Risks

(You can find a PC template here, which you can download and modify to suit your needs.)

“Stakeholders” and “Team Members” will clearly be much slimmer since we aren’t dealing with one or more outside parties.

You may not need a “Procurement” section if you aren’t setting up new assets, such as JIRA boards, slack channels, etc. This will often be the case for existing teams that already have these project underpinnings in place.

You may also be able to omit the “Deliverables” piece if you already have processes (such as DevOps) implemented to handle the transition from development into production.

And finally, the “Communication Plan” would also likely be smaller since most internal Agile teams will already have an established set of meetings and communications, such as Sprint Review, Sprint Planning, Refinement, and the like. You may; however, want to include internal parties that need to be notified as the project progresses, such as Sales, Marketing, Support, etc. See my comments earlier in this article on “Project Milestones” for more details on when and why to communicate with these groups.

Wrapping Up

I hope this article has helped to illustrate the value and application of a PC into your next Agile Scrum endeavour. The PC provides background, clarity, a common framework of assumptions and understandings, and a reference guide to project resources and participants. The PC also neatly bridges the gap that exists at times between upper management and the technical teams who are utilizing Agile methodologies, and it serves to signal when important communications should take place regarding the project’s status with other teams such as Sales, Marketing, and Support.

I have utilized this type of document many times in the past successfully, and I would recommend giving it a try for yourself if you haven’t already done so. :)

Also, there is nothing saying you have to implement the same section headings I listed and described in this article. You obviously are free to experiment, modify, and find what works best for you and your organization. Perhaps try a small subsection of the document and see how it works for you (i.e., validated learning) before incorporating the whole corpus into your operational playbook.

If you have any questions or comments after reading this, I’d love to hear them. If you try this out, let me know how it went and what changes you made to adapt to your environment.

Thank you for reading!