|
|
| (5 intermediate revisions by one other user not shown) |
| Line 11: |
Line 11: |
|
| |
|
| =Desired outcome= | | =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.
| | This program is about ensuring that when the the Apps program is marketed, the end users have the ability to be supported the same way as other Mozilla and Firefox users are supported today. |
| | |
| | This includes, support content for the most prominent features, support forums and feedback mechanism. It also includes the prework to set up a help-desk that will support paid apps. In the case that paid apps launch in Q1, this project will include email support for such apps. |
|
| |
|
| =Success metric= | | =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?
| | * Article Visits |
| | * Article Helpfulness |
| | * # Support Questions |
|
| |
|
| =Scope= | | =Scope= |
| If necessary, provide info about what this goal is ''not'' about, or other relevant information that will help avoid confusion.
| | This project is dependent of the Apps and Marketplace programs. If the program delays this project will be delayed too. |
| | |
| =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= | | =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.
| | TBD |
| | |
| 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:
| | [[Category:Support Archive]] |
| * 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
| |