The following are definitions that we will use throughout all of the process documentation to allow all of us to have the same common understanding and language. Each definition may contain examples and what form it should be in.
== Artifact ==
Commonly these are called project artifacts, representing all of the tangible byproducts that make up a project, including most of the items listed here. They are also specific to a project and include items like UX diagrams, test suites, server architecture, use cases.
Form: tangible aspects of a project.
== Block ==
A block or typically called a blocker, is some action or deliverable that is preventing the completion of another task. For example, imagine you were creating a website and you have designs and some code complete, but you are waiting on IT to provide servers to host it. You would say that IT is blocking the next steps of the project (e.g. QA, code review, deployment) or the IT servers are the blocker. Blocking is explicit in Bugzilla given that each bug can reference other bugs that are either dependent on its completion or the bug itself blocks another bug. A bug is not really complete unless all of the dependent bugs have been resolved.
Form: action or bug
== Communication Channel ==
A communication channel is a place where people on the project and people defined in the participation plan can communicate and collaborate on specific needs, blockers, and deliverables. The communication channel should be in a public forum that open by default, but this is not always possible or desirable. Communication channels should only be private (employee-only) on the exception. [[Engagement/Integrated_Marketing/Getting_Started/Communications|Read more]] about what platform is right for your project.
Examples:
* Bugzilla bugs
* IRC channels
* Basecamp conversations
* Yammer threads
* Google Doc comments
* Box.com comments
* Vidyo
* Github comments
Strategy:
* The less amount of communication channels, the better.
* Pick a communication channel that matches the requirements of your participation plan.
* Be open and as transparent as possible.
Form: Web or internet-based communications forum.
== Deliverable ==
A deliverable is something specific that a team or person will need to produce, create, or deliver that is needed for the completion of a project. A deliverable should have a due date and someone responsible for completing the task.
Examples:
* [[Engagement/Integrated_Marketing/Definitions#Project_Brief|Project brief]]
* Copy
* Visual designs
* IT servers
* Scope document
* Localized strings
* Front-end HTML
== Goal ==
Goals and objectives are sometimes used interchangeably, but they are not the same thing. Traditionally, goals are bigger and less tangible and objectives are more specific and measurable. Currently, Mozilla does the opposite where objectives are aspirational and goal are specific and measurable. Goals should be SMART and SMART is defined as:
* Specific – target a specific area for improvement.
* Measurable – quantify or at least suggest an indicator of progress.
* Assignable – specify who will do it.
* Realistic – state what results can realistically be achieved, given available resources.
* Time-related – specify when the result(s) can be achieved.
Form: Google Document or wiki
== Initiative ==
An initiative is a higher level than a project may span longer periods of time and doesn't always have a defined start or end date. Initiatives are made up of multiple projects and/or tasks.
Form: Google Spreadsheet, Google Document, or wiki
== Integrated Marketing ==
The collaborative process by which new Engagement initiatives are evaluated, communicated and brought to life. It is more the "how" than the "what" of activities on the Engagement team. Check out [https://mozillians.org/en-US/u/cmore/ Chris More's] [https://docs.google.com/presentation/d/1XIcxxt-6dZVBkd6RrQx3BmUt3U12EaYYQsy947akv8k/edit?usp=sharing presentation introducing the idea].
Form: process
==Iteration==
Many projects benefit from an iterative process. This
process delivers value rapidly and validates ideas in the real world.
Simply put, an iterative process attempts to deliver smaller,
less-perfect versions of a product to all or some of the product's
audience, giving them an opportunity to see or use those versions sooner
than they otherwise would, and capturing their feedback for the next
iteration. The next iteration delivers a larger or slightly more perfect
version of the product.
Form: process
== Kick-off Meeting ==
A kick-off meeting is scheduled once the scope, goals, RASCI, project hub, tracking bug, communication channels, and team is defined and the project is approved and prioritized. The kick-off meeting should include a representative from each of the teams that will be needed to during the life-cycle of the project. The purpose of the meeting is to ensure all stakeholders are aligned on what the project is all about, who is doing what and when it will happen. It should be a high-level meeting and shouldn't include low-level details.
Form: Meeting invite send to internal and external stakeholders.
==Launch==
A word frequently used in projects that have a go-live date. The
best projects have a very clear shared understanding of what "launch"
means. The most challenging projects often do not have a clear shared
understanding of what "launch" means. Launch cannot simply be defined as
"making the product available once the project is complete", since
"completion" is a hard-to-define notion similar to "perfection" and
"infinity", and is just as difficult to produce with limited time and
contributors. Instead, launch usually means that the project's work
product is delivered to its audience with enough features that it is
able to achieve its most important requirements. Which features will
determine this? A good definition of launch will enumerate them.
Form: definition and date
==Launch plan==
Launching a product that has all the necessary features
is itself a complex activity. It might require new teams to be involved
(such as the press team or the IT team); it might require a system to be
unavailable; it might require a complex sequence of events and handoffs
between various experts. Example: A project to create a new corporate
slogan would obviously involve numerous phases of creative work and
review. But launching the slogan could require making many changes at
the same time to numerous products where the slogan already appears,
plus a media campaign, and more. A project should spend time planning
for this critical moment.
Form: Spreadsheet, wiki
==Maintenance==
The product of most projects doesn't disappear into a
cloud of smoke at the end of the project. Instead it enters into a new
phase called "Production" or "Maintenance" or something else depending
on the domain. A project should consider what will happen to its work
product when the project is over. Who will continue paying attention to
the product, fixing it, communicating with its stakeholders --
maintaining it?
Form: process
== Notes Hub ==
This is the central place that all meeting and other ad-hoc note taking should happen and should be available publicly or at least to all members defined on the [[#RASCI|RASCI]].
Form: Etherpad or Google Docs
== Participation Plan ==
Initiatives and projects tend to do best when we enable the broader community to participate and amplify our efforts. As part of thinking through roles and resources for your initiative, you should consider how current Mozillians (both staff and volunteers), contractors, vendors and would-be contributors can participate in and support your initiative.
Explore the following:
Identify the types of tasks or work that needs to be done to execute on your initiative.
* Can this work be segmented into discrete streams?
* What skills are required or who are the individuals that you think would do this work?
* How would be on-board new contributors?
* Are there key markets where contributors can provide critical insights?
* Does your initiative contain sensitive or confidential information?
** The answer to this will determine how you can proceed and be as transparent as possible.
There are many ways that volunteers and Mozillians can help bring your initiative to life and are critical to Mozilla's "Million Mozillians" goal.
Form: Google Document or wiki page.
== Process ==
A sequence of steps and/or deliverables that govern the
project life-cycle. A good process provides a framework for action that
makes success repeatable (and thereby more likely). Process can't take
the place of communication; no project is as simple as its process suggests.
Form: wiki documentation
==Product==
In the context of project management, a product is the
particular outcome a project works to produce or supports an existing product. Depending on the project,
a product might be a Mozilla product like Firefox, a complete website, an event or something else real that is produced.
Form: Something tangible and real
==Program==
Similar to an initiative, except even longer lasting. A
program is an organizational structure that exists to deliver ongoing
value in a particular domain, by way of initiatives and projects.
Form: intangible documented on wiki
== Project ==
A project is defined amount of work with a clear start/end date, goals, and scope. Projects are made up tasks and involve multiple people and/or teams to complete.
Major projects:
* Involves multiple teams
* Duration of work is weeks to months
* Important to organization goals
* Important for the rest of the organization to be aware.
* External focused
Minor/internal projects:
* Involves a small number of people
* Duration of work is a few days to a few weeks
* Doesn't require many others to be aware for it to be successful.
* Improvements to our technology or process.
== Project Brief ==
A project brief defines the goal of your project, the requirements needed to make your project successful, and ensures that stakeholders are on the same page before work begins. The project brief is considered complete once stakeholders agree on its content and the team has enough information to move forward with next steps, such as starting the design process or coding. It serves as a reference for your project's scope and sets the stage for the work to come.
Use the project brief template below as a tool to have a conversation with stakeholders and team to better understand your project. The Google Docs format allows stakeholders to collaborate in forming the brief before signing off.
[[Engagement/Integrated_Marketing/Fleshing_Out|Getting started with your project brief]]
Form: Google Doc using provided template
== Project Hub ==
A project hub is the central place where anyone on a project or interested in it can go and learn about all aspects of it. The project hub should include content or links to the short project description, scope document, RASCI matrix, team members, timeline/schedule, tracking bug, and communication channels. The project hub should be a wiki page on either [https://wiki.mozilla.org wiki.mozilla.org] (public) or [https://mana.mozilla.org mana.mozilla.org] (private) or optional Basecamp (private). Any person should be able to do to the project hub and quickly get an understanding about what is the project, why it is happening, where to find more information, and how to get involved.
[[Engagement/Integrated_Marketing/Getting_Started/Project_Hub|Getting started on your project hub]]
Form: Wiki page or Basecamp.
== RASCI ==
We work best as a team. To get started, take some time to identify the key people you’ll need to execute your initiative, as well as their roles and responsibilities. We’ve been using the RASCI matrix with success:
* Responsible (Prepares or does the work)
** Example Roles: Project manager, developer, designer, copy writer.
** Subject matter experts who represent functional teams within Engagement and provide plans to the project owner based on the owner's goals and objectives, and execute on those plans (makers), for each initiative. Each Responsible pulls in other from their functional team as needed and can create a sub-RACSI (where they become the Accountable role). This is recommended for larger functional team efforts.
* Accountable (Approves work)
** Example roles: Product manager, Technical Project Manager
** There are 3 key aspects to this role:
*** Setting the Target: responsible for defining the problem and the objectives for the team, creating the [[Engagement/Integrated_Marketing/Definitions#Project_Brief|project brief]], defining key [[Engagement/Integrated_Marketing/Definitions#Deliverable|deliverables]] from the R's and approving/rejecting the work as it comes in. This person isn't defining the functional teams plans, but delegating the plan creation to the right people.
*** Day-to-day decision-making: This role makes choices on the day-to-day decisions of the campaign, but escalates core decisions up the management chain. Specific examples of “core decisions”:
**** Any action requiring budget must be escalated to a Director.
**** Core campaign elements such as the key value proposition, messaging, and target segments
**** Final selection of external agencies and campaign strategy are to be compiled in a Program Review for approval for the Engagement Leads and sign-off by Pete.
*** Drives the project in a program management capacity: defining schedules, calling meetings, following-up on key deliverables, and preparing check-ins.
* Supportive
** Example roles: Any
** These are other individual contributors who may assist the “Responsible” in executing their part of the project plans. Generally these people won’t be named at the outset of a project, rather each Responsible should work with their Functional Teams to determine who is best suited and available to contribute to the project.
* Consulted
** Example roles: IT, privacy, legal or others.
** Subject-matter experts to be involved in the project, but don’t have specific on-going contributions or responsibilities. These are people who have deep knowledge of a segment, process, our products, or skill that can enhance the overall campaign or program. For example, a campaign about privacy might call on Alex Fowler from our Privacy team for insight on the key areas on Mozilla differentiates from our competitors.
* Informed
** Example roles: leaders.
** Those who need to stay informed about project progress.
Form: Google Spreadsheet, Google Document, or wiki page. [[Engagement/Integrated_Marketing/Getting_Started/Responsibilities#Example_RASCI_Matrices|Example RASCIs]]
== Retrospective ==
A retrospective is a process that happens soon after a project is complete. A retrospective when you evaluate the good and challenging areas of a project during the entire life-cycle. A retrospective should not be a finger pointing meeting, but it should be a meeting where you celebrate the wins and you review lessons learned. Without taking time to do a retrospective, it is difficult to continuously learn and improve what we do and how we can deliver products.
Form: Google Forms, Google SpreadSheets, Google Docs, wiki
== Requirements ==
The requirements are the "what" is needed. Requirements come in various forms and include end-user requirements, performance requirements, product requirements. A user story is one of the best ways of capturing requirements, but it may not fit every single type of project or initiative. A user story is defined simple a sentence or two that describes the "what", "who", and the "why" of a project requirement.
User stories should be in the following form:
"As a <role>, I want <goal/desire> so that <benefit>" (the "so that" can be optional, but it does help clarify the
Example user stories:
* "As a general audience user, I want to download Firefox, so that I can take part in the open web."
* "As a visitor to a booth, I want to learn about Firefox OS, so I can lean more about mobile offerings (and get free swag)."
* "As an admin of a website, I want to be able to moderate comments, so that offensive language can be removed."
* "As a web analyst, I want to be able to monitor usage of a button, so that I can effectively measure conversion rates."
For each user story, you can provide additional details around that requirement or specific criteria that should be true.
Form: Google Document or wiki page
== Schedule ==
A schedule is a listing of a project's milestones, activities, and deliverables, usually with start and finish dates. A schedule at a minimum should include the kick-off date and the launch date. A preferred schedule will contain all key deliverables and dates on when they are due. Schedules can range from a high-level overview to very detailed and contain dates and dependencies for each action to be completed. The recommendation is to make the schedule contain less detail and only provide major deliverable dates so that responsible members of the project and other stakeholders can clearly see the dates their items are due.
Form: SmartSheet schedule, Google Spreadsheet, wiki
== Scope ==
The scope is all of the work that must be completed for the project to be considered done. For example, imagine you were writing the requirements to build a house. In your requirements document, you define that the user needs a kitchen, living room, and a bedroom for each of their family members. The scope would define exactly how many of each of those rooms are needed, the size of the rooms, and any specific features that are needed to meet the requirements. Scope creep or more generically scope change is when you increase or decrease the scope. In the case of the scope of the house, adding an additional game room that was not in the requirements would be considered scope creep.
Form: Google Document or wiki page
== Tracking Bug ==
A tracking bug is nothing more than a normal Bugzilla bug that is used to track the progress of deliverables that are needed for the completion of a project or parts of a project. A tracking bug should be in a Bugzilla product/component that most closely relates to the product you are creating. For example, we usually have a product and/or component for each major website at Mozilla and each functional area and the tracking bug should be filed in that product/component. Each deliverable that is needed for the project should be separate dependent bugs that block the completion of the tracking bug. You can also have a main tracking bug for the overall project and then sub-tracking bugs to connect all functional pieces.
Example tracking bug dependency tree:
* Acme project [tracking bug]
** Acme project creative activities [tracking bug]
*** Create wire frames
*** Create visual designs
*** Create buttons
**** Create website copy [tracking bug]
***** Copy for homepage
***** Copy for product pages
** Acme project development activities [tracking bug]
*** Create HTML for homepage
*** Create database
*** Make forms functional
*** Add download buttons
** Acme project reviews [tracking bug]
*** QA review
*** Privacy review
*** Security review
Form: Bugzilla bug.
