#Agile Project Charter

With the current project I am working on we discussed how we can make the Project Charter or Project Kick-off activities much more Agile. We are proposing to use new Agile methods and want to enhance our communication and allow team members to easily understand what they would be doing on the project.

On other projects I have been part of, these Project Kick-off activities involve a meeting that can have a lack of energy and enthusiasm. The Project Charter document is typically reviewed that details the roles and responsibilities of the clients and team members. In many cases the document is overly textual and team members come away from reading the document not understanding what a typical day or week will be like on the project. Even when a meeting is held to review the document, the content can still be somewhat generic and not allow people to understand their place on the project.

An Idea

After thinking about this problem, I was reminded I heard these issues and comments before. I think we have all heard these comments many times about User Requirement sessions that reviewed a large textual document and then scheduled excruciating meetings to review the documents in detail. And then at the end of those sessions, the clients still didn’t have a good understanding of what those requirements meant to them personally and understand what their place in the solution was.

So I thought if User Stories are successful in grounding clients with the solution and enhancing communication on User Requirement by making them personal, why not try the same with Project Team User Stories to describe the team member’s project interactions in the same way?

Project Manager Example

Here is an example of what a Project Manager’s interaction could be. There are some heavier weight processes and documents that would not be used all the time, but I thought it would be good to include them so I thought the entire process through. I’m still working on the wording of each story, but I think you can get the intent of the idea.

As A I will When So That
Traditional Project Manager Create the Project Schedule using traditional methods At the start of the project We have a realistic starting point and plan for the project
Traditional Project Manager Complete the Project Initiation Checklist At the start of the project All required tasks are completed
Traditional Project Manager Hold the Client Project Charter Meeting for the Client At the start of the project All Clients understand their role and expectations on the project
Traditional Project Manager Hold the Development Team Project Charter Meeting for the Development Team At the start of the project All Development team members understand their role and expectations on the project
Traditional Project Manager Create the Risk Register At the start of the project To derive the Risks, define the mitigation plans and incorporate the Risks and mitigation plans into the project schedule, and to communicate the risks to the stakeholders
Traditional Project Manager Create the Issue Register At the start of the project To document the Issues, define plans to address, and manage to the due dates.
Agile Team Member Review and understand theUser Story Map Before the first Iteration So that I understand the plan for the project and the content of the work required.
Team Member Review key documents when they are produced

  • Business Requirements
  • Solution Architecture
  • Active Architecture
  • System Requirements
  • User Story Map
  • Test Strategy
Before the first Iteration and throughout the project So that I understand the plan for the project and the context of the work required.
Agile Project Manager Create the Iteration Plan Before the first Iteration So that we can transfer an Initial Plan to a Manageable plan.
Agile Project Manager Create the Kan Ban Board Every Day The status of the project is available to everyone
Agile Project Manager Create the plan on the Agile Project Management Tool Every Day The status of the project is available to everyone
Agile Project Manager Update my tasks on the Kan Ban Board Every Day The status of the project is available to everyone
Agile Project Manager Update my tasks on the Agile Project Management Tool Every Day The status of the project is available to everyone
Agile Team Member Provide my update at the Stand-up Meeting Every Day The entire team is aware of what I am working on an any issues I may be having
Traditional Project Manager Create the Status Report Every Week The status of the project can be communicated to the stakeholders
Team Member Update the Risk Register Every Week To update the Risks, update the mitigation plans and incorporate the Risks and mitigation plans into the project schedule, and to communicate the risks to the stakeholders
Team Member Update the Issue Register Every Week To update the Issues, update plans to address, and communicate due dates.
Agile Project Manager Hold the Iteration Planning Meeting At the start of every Iteration The team can jointly determine the content of the next Iteration.
Agile Project Manager Hold the Planning Poker Meeting At the start of every Iteration The team can jointly estimate the User Stories in the next Iteration and refine the requirements.
Agile Project Manager Hold the Mid-Iteration Planning Meeting At the middle of every Iteration The team can jointly determine status of the Iteration and determine if adjustments need to be made. If appropriate, the mid-week status can be communicated to Stakeholders. Risks and Issues will also be reviewed.
Agile Project Manager Calculate the Iteration Velocity At the end of every Iteration We can plan a reasonable workload for the subsequent iterations.
Agile Project Manager Hold the Iteration Retrospective At the end of every Iteration The team can provide feedback and improve for the next Iteration.
Agile Project Manager Hold the Demonstration Meeting At the end of every Iteration The client can present the content of what has been completed in the last Iteration.
Traditional Project Manager Hold the Project Retrospective At the end of the project Lessons learned from the project can be captured and incorporate into future projects.
Agile Leader Promote Collaboration over Documentation Continuously Miscommunication and Documentation waste is minimized
Agile Leader Promote Rapid Discovery Event Continuously We can quickly define the requirements in a collaborative way. Miscommunication and Documentation waste is minimized
Agile Leader Promote light weight Documentation Continuously Documentation waste is minimized
Agile Leader Promote frequent delivery Continuously True progress is shown and realized
Project Leader Ensure key documents are produced when required

  • Business Requirements
  • Solution Architecture
  • Active Architecture
  • System Requirements
  • User Story Map
  • Test Strategy
Continuously Required project and corporate memory is created
Agile Project Manager Focus on managing issues and risks not tasks Continuously I facilitate progress on the project not documentation
Agile Project Manager Document all scope changes that cannot be accommodated Continuously I facilitate the communication of scope changes to the project to all stakeholders
Agile Project Manager Defer all setting of priority decisions to the client Continuously We work on the true priorities of the client.
Agile Project Manager Promote the use of Visual Project Management and Agile Project Management Tools Continuously We communicate relentlessly the status of the project to the project team and the Stakeholders in a graphical and easy to consume manner.
Team Member Seek collaboration and consensus on all decisions, but understand that schedule decisions are the responsibility of the Project Manager Continuously Decisions are made striking a balance between collaboration to seek all sources of information and efficiency to make difficult decisions when required in regards to schedule.

Summary

I’m excited about the idea. I think we need to be careful so that people understand that they still need to have an Agile mindset and these are guidelines only. But with the right leadership, I think this format could really assist in the Agile project Kick off.

7 thoughts on “#Agile Project Charter

  1. Do you really even need to document all that? My Project Charters are typically 2-pagers that answer the question “Why is the business paying to do this project? What do they expect to achieve?”

    • Great comment Dylan. I recommend that those still get done as this format does not answer those great questions about purpose and value. (I actually like doing innovation games like product box to derive that detail) This document was meant to communicate the ‘how’ as opposed to the ‘what’ and ‘why’. I agree those other areas are even more important to be covered. I also like deriving these stories together with the team.. hopefully the document is lighter than this one but I included all the stories I could think of to better share the intent…

  2. This is great! Not only can it help with the “How”, but gives ideas on the “What” for the Charter and management.

    Any thought to adding a Communications Plan user story and something to address the”people change management” piece (i.e. Prosci’s ADKAR)?

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s