Structured Agility: Developing an Agile Project Charter
By Chuck Snead
The PMBOK v5 defines creating the project charter as “the process of developing a document that formally authorizes the existence of a project and provides the project manager with the authority to apply organizational resources to project activities.”
On the surface, this may sound totally non-Agile, but from a project integration standpoint, this is a very key document for both SDLC and Agile projects because it defines their boundaries, who the key stakeholders are, and it provides a vehicle for the organization to formally commit to the projects. Obviously, the type of organization and needs of the project will determine how the charter gets produced.
Most organizations (especially large ones) have a formal process for defining, selecting, and authorizing projects. For Agile projects, the fundamental differences from an SDLC perspective are (1) how much information needs to be provided, and (2) who is involved in creating the charter. For example, Agile projects operate by the Lean “barely sufficient” philosophy of just enough information to provide adequate decision-making, and no more. Additionally, since Agile is a team-centric process, the development team (or as much as has been defined) will be involved.
So, what does “barely sufficient” mean in this context? Well, Agile projects conduct continuous planning at many different levels, from the highest level product life cycle planning, down through planning for a specific release within that life cycle, planning for a specific time-boxed development period within the release, and even down to the development activities for a specific day (the daily stand-up, or scrum); each progressively elaborated as its respective planning horizon becomes active. Because of this, much of the up-front, in-depth planning normally conducted for a SDLC project is not needed; merely what is necessary to meet the goals of the charter/scope. Given that, let’s discuss how an Agile project may still meet the need to create a project charter.
Below is a figure I put together to define the Agile process of creating a project charter, modeled after the PMBOK v5 “Develop Project Charter” process:
For an Agile project, the charter and initial scope will usually be defined at the release planning level, although they may also span multiple releases for very large or lengthy projects. But, typically, a specific Agile project will cover a 3 to 6 month development period targeted to produce a defined set of features that will either represent the entire product, or a distinct version of it. Since Agile projects are comprised of staged, time-boxed development periods – called iterations (or sprints, in the Scrum lexicon) – they will often begin life through something called “Sprint 0”: a specified period prior to the start of a project in which a product owner, project manager, and some portion of the proposed development team will meet and lay out the vision (or theme) for the release, assemble enough of a list of features (and just enough underlying detail) so that a reasonable estimate of scope and size can be created, shape these features into a loosely defined release plan, and provide an estimate of costs and resources needed to conduct the project. All of these – and any other organizational requirements – will be considered as deliverables for Sprint 0.
So, for the project charter, the product owner(s) and project manager will already be known. The statement of work will be comprised of the business need (and possibly a cost-basis analysis), the overall scope of the project (in relation to the business need), and how the business need relates to the organization’s strategic plan. These will usually be provided by the product owner, but may need to be shaped up as Sprint 0 deliverables.
The business case is generally an expanded version of the business need and cost-benefit analysis, with additional references to any specific legal requirements, organizational and technological needs, market demand, potential impacts and risks, and other criteria that are needed to make an informed business decision. Based on experience, this will almost always wind up being a deliverable for Sprint 0.
Finally, agreements with other units and/or contractors, environmental factors, and organizational assets are artifacts that will generally be provided by the product owner, and shaped up as Sprint 0 deliverables.
So, as with all things project related, Sprint 0 is best started with a kick-off meeting, which will generally consist of the following people: (1) the main sponsor of the project, (2) the product owner, (3) the project manager, and (4) a designated team lead and as many members of the development team as is known. This last step is a fundamental difference between Agile and SDLC projects, and reflects the importance the Agile methodology places on team interaction, right from the start of the project.
The agenda for the kickoff meeting will start with the usual introductions and possibly a word of support from the project’s sponsor (who may then elect to leave the meeting), followed by a product owner led discussion of the business need and purpose of the project. This will invariably lead to a Q & A session, as the team members (and probably the project manager) ask more detailed questions about the project. Finally, it will wrap up with a discussion of the requirements to produce the charter and initial scope, and other deliverables that may be needed to support them, as required by the organization. At the end of the meeting, the team should have a loosely defined plan for developing the Sprint 0 deliverables, and the people responsible for them. Based on experience, the kickoff will usually take about two hours to accomplish.
After the kickoff, it will be the responsibility of the project manager and product owner to work with the rest of the team to produce the Sprint 0 deliverables. This is usually accomplished with a series of subsequent brainstorming sessions, attended by representatives of the various customers, development team members, and other stakeholders who can provide information on the desired features and scope of the project. Note, again, that although these may resemble SDLC JAD sessions, discussion of each feature should stop when enough information has been gained to reasonably estimate its size and complexity. More detailed analysis of these features will occur closer to the time they will be developed.
Finally, once the Sprint 0 deliverables have been created to the satisfaction of the product owner and primary sponsor, they are ready to be delivered to the authorizing agency.
Once the charter and other required artifacts have been delivered, the product owner and project manager will probably be required to answer any subsequent questions. Also, if there is good certainty that the project will be approved, this grace period is a good time to start doing the more in-depth analysis of the first group of development tasks, and any other housekeeping required to assemble the team and get them up to speed. At any rate, at the end of this process, the team will have a good plan in place to help ensure a successful Agile project!
Chuck Snead is a Project Management Professional (PMP), PMI Agile Certified Practitioner (PMI-ACP), and Certified Scrum Master (CSM) with over fifteen years of experience managing Waterfall/Traditional and Agile projects, for both the private and public sectors. He also has a Master’s degrees in both Information Technology and Business Administration, and he teaches various IT and project management courses as an adjunct professor. You can read more articles from Chuck on his blog.