Support/ProjectTemplate

This is a template for quarterly goals or projects you are leading. The purpose of it is twofolded:

• To remove ambiguity about what exactly a project/goal is about, and what it's not about.
• To make it easier for everyone to know the status of a project.

This template can be used as a skeleton and simply copied to a new wiki page or etherpad.

DRAFT
The content of this page is a work in progress intended for review.

Please help improve the draft!

Ask questions or make suggestions in the discussion
or add your suggestions directly to this page.

Title of project/goal

Brief exec summary of the project's or goal's purpose. Also list who is owning it and any stakeholders.

Problem statement

Provide an accurate and clearly articulated problem statement:

• What is the problem that we are hoping to solve with this project?

Desired outcome

Describe with words the desired outcome after the completion of this project. What will be different? What will be improved? Be as clear and precise as possible, and avoid assumptions on what the reader's prior knowledge about it. In other words, elaborate on this more rather than less.

Success metric

How will the success of the project be tracked? Which of the org's top goals does this project support? What KPI/needle are we trying to move?

Scope

If necessary, provide info about what this goal is not about, or other relevant information that will help avoid confusion.

Communication plan

At a high level, describe any communication plans (e.g. planned blog posts, forum thread posts, internal MoCo communication, etc) that should happen as part of this goal. Also specify who needs to do the communication -- you, community management, or someone else. This section can of course be merged with the Project plan / Timeline section below if it's easier to follow.

Project plan / Timeline

At a high level, describe what steps we need to take to get to the completion of this project. In some cases, it might be mostly unclear, in which at a bare minimum it should be clear what the next steps are. In other cases we may already have a pretty clear idea of all steps needed.

The project plan should be a "living" part of the document and should be updated frequently to remain accurate. Again, it doesn't have to be super detailed, but it should contain enough info that you should be able to scan it and assess the overall status and health of the project.

Remember that by writing a plan or next steps down, you also help yourself to get a better sense of the work to be done. Writing should not be seen as non-work or a waste of time, especially not if it also helps stakeholders and other interested parties to stay informed with the project.

The project plan could be something as simple as a bulleted list with action items, owners, and deadlines:

• Initial kick-off meeting on July 27 w/ stakeholders (David)
• Delivery item #1 completed on week of Aug 13 (Rosana)
• Delivery item #2 completed the week after item #1 (Cheng)
• Present results at board meeting (David) on Aug 30
• Implementation of solution X (David & Michael) Sept 5