The team collaboration plan is a document used by the team and important stakeholders. It captures how the team will collaborate with one another. At a minimum, it should include:
Who is on the team and their contact information (emails, phone numbers)
Plan for when/where/how you will meet and get work done
How will you keep each other updated about who is doing what and when they should make it available to others for review?
What technology will you use to collaborate? What standards will you use in managing these spaces (i.e., versioning system, author/editor log, locking docs, response expectations, etc.). Spell it out. Be clear. Ambiguity -> conflict.
Roles Assignment
Define roles – who, if anyone, will run your meetings? Do you want a project manager, someone to take meeting notes, manage your collaboration space, put the docs together? Note that roles can adapt over time and be shared. For example, you can rotate leadership of team meetings – each person is made responsible for “running” a meeting, or two people are charged with managing team communication.
Project Charter
The project charter is a 1-page high-level document prepared for internal stakeholders to identify, at a very basic level, the purpose of the project. This is the document that says "here's our basic understanding of why we're here and what we're going to do". Think of it as a contract between team members and key stakeholders. It should include at minimum:
Title/name for the project
Short description of the problem that you’re addressing (or opportunity)
Value/benefit of the system
Primary audience/consumer
Key assumptions, if any
If you suddenly had a new member join the team, this is the first document you’d give them to “orient” and help understand what the team is doing. This a managerial document (not for the customer). All team members should sign the charter in recognition that they understand and agree on the initial direction of the project.
Scope Statement
The project scope statement is a 1-2 page document prepared primarily for an outsider (stakeholder or customer) that describes what your system will do, what the project will deliver, and outlines the work required to complete the project at a VERY high level. There are not a lot of details here.
This is an initial description that will be revised as you clarify user requirements (in this case, as you decide what you want the system to do). In this document, be sure to describe how your system will create value for your customer. Some of the content will be redundant with the charter, but that’s ok. The way you “frame” it should be different because it’s for the customer. Think about what Mark should have put down on paper to avoid his disastrous project.