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
|
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
|
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.
Hi there
Great idea to show the table very easy to work now on project.
Thanks
Martin
LikeLike
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?”
LikeLike
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…
LikeLike
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)?
LikeLike
Thanks Luc. I must admit I’m not familiar with the ADKAR process. Is there a reference you could suggest?
LikeLike
Start with: http://www.prosci.com/
or something like this: http://www.change-management.com/tutorial-adkar-overview.htm
LikeLike
Thanks Luc!
LikeLike