In the age of empires, kings and queens granted charters to companies.

In the age of empires, kings and queens granted charters to companies.

Project managers and developers have long been at odds with each other over deliverables like the project charter. The project management view is that the information is needed, albeit by parties outside the project team. On the other hand, the project teams see their effort being siphoned off.  Generally, the charter has been considered a control document, therefore the bastion of stakeholders and project managers.  Agile techniques and the institution of the Agile project charter has changed that. However, all of the parties that consumed the information from the classic charter still have information needs. There are three audiences for the information in the classic charter: the teams, stakeholders and executives.  Agile while still generating and sharing information provides it via different channels. (more…)

Cargo ships on Lake Erie

The bigger the ships, the more barnacles.

As we noted in Agile Charter Barnacles, the basic Agile project charter is brief and to the point. However, there is a natural tendency to add components back from classic charters.  The charter is a tool for the team, therefore the team needs to find the components that add value to how they work.  When these components add value, adding these sections makes sense.  A number of readers of the Software Process and Measurement blog have asked about whether adding specific charter sections make sense in an Agile project or whether there are other techniques to address their needs. Here are my answers: (more…)

A flip chart

Flip charts!

Building an Agile project charter is one the first events that marks the beginning of a new endeavor.  The charter helps a team clearly capture the project’s goals and definition of success.   For most projects, project initiation is a time full of possibilities, a time before all the mundane issues and the day-to-day begins. The process of framing the charter must acknowledge the excitement of the team without letting that excitement lead them astray.  A standard, moderated process to create a charter provides focus and direction for a team raring to deliver value. (more…)

Men fishing in a boat with an outboard motor

Barnacles slow down the boat.

The basic Agile project charter is brief and to the point. This brevity seems to beg practitioners to add components from classic charters. Here are some examples of common barnacles: (more…)

An example team charter on a flip chart

Using the flip chart method

All charters have a goal: to establish a clear and agreed upon definition of success for the team.

If you don’t have a clear definition of your destination when you set sail, any port will do.
– (unknown)

Where an Agile charter differs is it singleminded approach to being simple.  The Agile charter strives to be the simplest tool needed in order to concentrate the team’s focus by generating a clear statement of what the problem is to be solved and its solution.

While all charters would claim simplicity, some classic project charters can challenge the size of small novels (100k words between content and template) and can take months to write, wordsmith and gain authorizing signatures.  Note that this generally occurs after strenuous budgeting. Agile team charters take a different approach and can generally be completed in a single afternoon.  An Agile team charter has three attributes that immediately set them into a different universe from classic charters. (more…)

This team is eager to begin work on its charter.

This team is eager to begin work on its charter.

Project charters play an extremely important role in the initiation of projects.  The Project Management Institute (PMI) suggests that no project should begin without a charter.  A project charter creates a foundation to guide project activities.  The primary roles of the charter are to:

  1. Authorize the project to move forward.  In many methodologies the charter acts as the authorizing document.  The charter will include items such as the business need, project scope, budget and the signature of sponsors.  In some organizations the sponsor or the sponsor’s organization will author the document and use it as a form of transmittal or work ticket. While the literature is rich with processes in which the charter is written outside of the development team, I have never seen this process in action.  What is more typical is a charter written by IT and signed-off on by the stakeholders or some sort of electronic budget authorization. Regardless of methodology, in a large organization, an authorization to spend money is important.
  2. Acts as a communication vehicle. The charter is often used to capture the initial thoughts of the sponsors, product owner and team about the goals of the project and the rules they will use to govern themselves (or be governed by in classic command and control methodologies).
  3. Provide structure for the team. Who is on the project team is not always as evident as it should be.  The charter should identify the team members (and some logistical info, like time zone, if distributed) with the roles they are playing, if needed.  In many IT organizations, team members play specified, specialist roles. While specialization is a feature mainly thought to be seen in organizations using classic development and project management techniques, it can also be seen, albeit to a lesser extent, in organizations using Agile. Depending on the method used the product owner and Scrum Master should also be identified.  Other team attributes such as team norms and expectations should be identified and agreed upon.
  4. Identify needed resources. Remember that the resources needed, like business needs and requirements, continually evolve. Therefore over time the charter must evolve or be replaced. For example, a charter I recently reviewed for a new Agile project and team identified the need for a team work room and licenses for a specific automated testing tool.

The macro goal for the charter is to get the project going in the right direction.  The needs and requirements of most projects of moderate to large size/duration are relatively dynamic.   The issue is that while charters are supposed to change and evolve, once they are created they are prone to becoming shelf-ware.

A charter can contain additional information such as risks, constraints, project context and deadlines. The range of data that can be housed in a charter is limitless.  However, I have seem large projects spend months writing and wordsmithing charters that were hundreds of pages long. The process of thinking about all of the charter topics might be valuable, however rarely is the document used after the sponsors and other stakeholders sign off on the document. Whether Agile or a classic plan-based, rarely will the charter see the light of day (or an update cycle) unless the topics covered are important to the team.