You are in a meeting with senior managers at your organization where it was revealed the company wants a smartphone app developed and released.
This is a simple utility app that counts the number of times a smartphone screen turns on, and the impact the on/off has on battery life.
The goal is to have the app available for potential customers (Google and Apple) as soon as possible to begin generating revenue, and improve upon it as you move along.
The project goal is to put out the best product you can, as quickly as possible, by utilizing technology and customer feedback to improve upon the product incrementally.
The end goal is to have a usable, desirable app available on iOS and Android as soon as you can.
At the end of the meeting, the attendees tag the IT Director as the sponsor and you as the project manager and want you to proceed immediately. You now have a team and are not creating this app alone. As the lead, you have decided to put an Agile PM plan in place. You must develop the Case Study Charter based on a hypothetical meeting with the team. It is imperative that you be creative and thorough, include
Why are we doing this project? This is the project vision.
Who benefits and how? This may be part of the project vision and/or project purpose.
What does done mean for the project? These are the project’s release criteria.
How are we going to work together? This explains the intended flow of work.
A servant leader may facilitate the chartering process. A team can coalesce by working together, and the project charter is a great way to start working. In addition, team members may want to collaborate to understand how they will work together.
Teams do not need a formal process for chartering as long as the teams understand how to work together. Some teams benefit from a team chartering process. Here are some chartering ideas for team members to use as a basis for their social contract:
Team values, such as sustainable pace and core hours;
Working agreements, such as what “ready” means so the team can take in work; what “done” means so the team can judge completeness consistently; respecting the timebox, or the use of work-in-process limits;
Ground rules, such as one person talking in a meeting; and
Group norms, such as how the team treats meeting times.
