PLANET 4 COMMUNICATION PLAN & OPEN DECISION FRAMEWORK

From Planet4 Communication Team | Remix 2.0 | updated July 5, 2016

Original by

Overview

The Planet 4 (P4) Project

This project entails a global overhaul of Greenpeace’s web presences. In 2011 Greenpeace International completed the rollout of the current web Content Management System (CMS) Planet 3 (P3), which is currently adopted by 26 of 28 Greenpeace offices with over 50 country sites.

P3 has been in operation for 5 years. It’s time to tear down the system behind greenpeace.org (and many other Greenpeace sites) and build anew. Time for rethinking content, design, voice, etc. This undertaking will seek to use open principles and involve the users, staff and stakeholders of Greenpeace to ensure the development of community accepted content and platforms.

P4 Communication Plan

This document includes a structured communication plan designed to ensure that the aforementioned stakeholders and users have timely information and are empowered to contribute to the project. The plan requires Greenpeace to work in a way we might not be used to working in – out loud, in public, with rapid prototyping and response. We will assign roles and multilaterally contribute to keep our process and progress transparent and accessible. We will actively seek diverse perspectives and strive for inclusivity.

The P4 Communication Plan includes the Open Decision Framework to extrapolate the reasoning behind ideas and processes proposed. Using the framework can help you develop a similar communication plan.

What the Open Decision Framework is

A flexible, transparent and open approach to making decisions and leading during the P4 Project. This methodology may also be suitable for other Greenpeace projects, once pioneered with the Planet4 initiative. The Framework was developed by the Red Hat community and licensed for remix. Please see the Github Repo for more information.

INSERT DESIGNATOR, IF NEEDED

Planet 4 Communication Ecosystem

INSERT DESIGNATOR, IF NEEDED

Output: Detailed Notes on �Public Google Doc

Responsible: all participants

Output: Blog Post on P4 MEDIUM Publication (#GPP4)

Responsible: Rotating author

Archive: Public Wiki

Responsible: PM / Comms

Archive: Greennet / Wiki page

Responsible: PM / Comms

Social Sharing: #GPP4

Responsible: Comms Hubs

Feedback loop: �Mailing lists + MEDIUM

Responsible: PM / Comms

Output: Monthly Slides / Infographic on progress

Responsible: PM, Sponsor or Supplier

Feedback loop: GP Matters

Responsible: Int. Comms

Feedback loop: Skype

Responsible: PM / Comms

Planet 4 Engagement Crossover

INSERT DESIGNATOR, IF NEEDED

Social Sharing:

#GPP4

Feedback loop: �Mailing lists

Feedback loop:

GP Matters

Feedback loop:

Skype

Output: �MEDIUM

Meeting:

Community Call

Output: �Wiki

Output: Drive

Internal engagement

External engagement

Meeting: �Weekly Project Team�Open Call

Comments:

On Outputs

Feedback loop: �Mailing lists

WHAT IS AN OPEN DECISION?

INSERT DESIGNATOR, IF NEEDED

TRANSPARENT

INCLUSIVE

COMMUNITY-CENTRIC

Explain what problems you're trying to solve, the requirements and constraints involved, the process you will follow, how people can contribute and document your decision making.

Engage others for feedback and collaborate throughout the decision-making process.

​

Seek out diverse perspectives, including potential detractors.

Think of people as with competing needs and priorities. Some people have opinions on UX while others want to talk about testing. This framework helps involve the right people at the right time.

​

When a decision will help some community members, but disappoint others, manage relationships and expectations while getting stuff done.

Open decisions are made using open source principles

Open discussion�Open Discussion begins when you share your "source code" with others. In our context, this means sharing meeting notes, plans, and other documents or images in a public space. A free exchange of ideas is critical to creating an environment where people feel empowered to use existing information to contribute relevant new ideas.

Participation�When we are free to collaborate, we create. We can solve problems that no one person may be able to solve on their own. When we invite people into this work, we enable them to participate.

Release early + often�Rapid prototypes can lead to rapid failures, and that leads to better solutions faster. Ideas should be released half-baked, and we shouldn't be afraid to say “We're not sure...” When we're free to experiment, we will see problems in new ways and find answers in new places. We will learn by doing.

Meritocracy�In a meritocracy, good ideas can come from anywhere, and the best ideas win. Everyone has access to the same information. Successful work determines which projects rise and gather support and effort from the community.

Community�Communities are formed around a common purpose. They bring together diverse ideas and share work. Together, a global community can create beyond the capabilities of any one individual. It multiplies effort and shares the work. Together, we can do more, but we have to be willing to have open discussions, invite participation, release early and often and acknowledge and implement the best ideas, no matter where they come from.

INSERT DESIGNATOR, IF NEEDED

Adapted from: https://opensource.com/open-source-way

How open source principles lead to better decisions

INSERT DESIGNATOR, IF NEEDED

Our comms strategy for P4 (proposal)

1. Define and confirm roles + responsibilities (Steering Committee)
2. Agree on potential aspects of the project that cannot be open (steering committee + project team)
3. Agree on Comms plan and Terminology (steering committee + project team) + Share it in WIKI
4. Create a Communication Calendar - Aligned with Project timelines - and assign roles (comms team)
5. Establish a shared public platform for updates (Planet4 Medium Publication) and grant access rights to GP account
6. Consolidate the project background (comms team)
7. Identify INTERNAL key stakeholders (project team)
8. Define collaboration methodology and interaction channels - social, newsletter, calls, open meetings (comms team)
9. Address risks, limitations, and potential impacts (project team + legal) - Explore comms contingency plan? (comms team)

​

Planning & Sponsorship (June)

Preparation & launch (July)

Execution & continuous engagement (Aug-Jan)

• Publish the Project baseline Document in a simple, easy-to-digest format with links for more info on the WIKI (comms team)
• Present to staff and stakeholders comms methodology, interaction channels and documentation storage Greennet > Wiki page (Project team)
• Schedule ALL meetings/calls until the end of 2016 - Aligned with Project timelines - (comms team)
• Create Greennet / Wiki / Platform spaces and assign Admin rights (comms team)
• Publish and share publicly the Content & Engagement Strategy Manifesto (project sponsor + comms team)
• Create a Public Glossary of terms (comms team)
• Shape and launch the internal survey on requirements (project team)
• Define a UNIQUE feedback methodology for both internal and external agents

​

• Consolidate survey results and embed them in project requirements (Project Team)
• Consolidate and share notes of weekly project team meetings (Project Team)
• Share Monthly project updates using the agreed templates and channels �(Project Team)
• Run community calls according to communication calendar (Comms team)
• Identify Champions for both Product usage (Internal, web editors) and consumption (Public users, developers..) (Project Team)
• Share the mockups and gather feedback on design and functionality (Project Team)
• Engage the Community (int. And Ext.) in Test scenarios of the different iterations (Project Team)
• Start working on large scale Launch and roll-out Communication (Project team)

You can't please everyone.�But when you make open decisions, people feel...

• I understand why the decision was made and how it aligns to Greenpeace's strategy, goals, and mission.
• There was visibility to the P4 requirements, research, and evaluation criteria.
• The decision-making process was inclusive and transparent.
• Although I wasn't the decision maker, I was able to contribute to the process.
• I may not agree with the decision, but it's obvious that the decision makers understand Greenpeace's values and the culture we striving for.
• I might be disappointed, but I wasn't surprised.
• My voice was heard and valued.

INSERT DESIGNATOR, IF NEEDED

NEXT STEPS

This week:

• Remy to investigate PM Tool / Solution
• MEDIUM is validated → Kelli to Get agreement from Comms Hubs to leverage gp.org Medium channel (24K followers) - Done, we have our P4 Publication
• Luca + Laura to wrap up comms plan + Open decision framework
• Cutover Project tools suite
• - Blog / Social → MEDIUM (#GPP4) - SM Aggregator (kind of GP DE social radar) TBD
• - Archive / Knowledge Repository → Wiki
• - Notes → Open GoogleDocs folder (DONE)
• - Project Official Documentation → BOX (Open)
• - Project Management → TBC
• - Voting → Uservoice
• Look at Fairphone.com, very good community and blog. Keeping the users engaged. Explain their dilemma’s and thought processes very well.

INSERT DESIGNATOR, IF NEEDED

RESOURCES

Original by

OPEN DECISION FRAMEWORK

INSERT DESIGNATOR, IF NEEDED

• What is the potential impact on the organization? On the culture?
• Who do we need to include in planning?
• Whose problem are we trying to solve?
• Who will we need or want help from?
• Who has solved a similar problem?
• Who is likely to disagree, dissent, reject, or opt out?

Questions to ask

Lead with transparency

• Establish a shared platform for updates (Medium Publication with syndication)
• Publish the problem statement and the directional document (project sponsor)
• Identify any aspects of the project that cannot be open (project sponsor)
• Publish the project background (comms)

Diversity of thought + Inclusion

• Engage internal staff and stakeholders early on, especially those who may disagree (share channel + document storage locale, e.g. public wiki page)
• Seek out diverse perspectives (geographies, departments, levels) (personal outreach)
• Champion collaboration and provide channels for feedback (social, newsletter, calls, open meetings)
• Address risks, limitations, and potential impacts

Begin to define roles + responsibilities

Plan to be open

• Who will write or design which documents (e.g. meeting notes vs functional docs or slides)
• Potential to generate controversy
• Impact on culture and future decisions
• Where to publish (Medium via syndication, twitter, wiki, greennet, internal newsletter)

Key considerations

There are a handful of issues that may generate controversy and upset within Greenpeace, including:

• TBD – what will we fight about?

If your project or decision involves any of these themes, take extra steps to make your process open, inclusive, and transparent.

Common flamewar triggers

PHASE: IDEATION

OPEN DECISION FRAMEWORK

INSERT DESIGNATOR, IF NEEDED

PHASE: IDEATION

• What is our RACI?
• What internal staff, stakeholders, and collaborators will we involve? (which lists, which skype groups, which external groups/lists?)
• How often will we engage and communicate with them?
• What are the open source options? (we can seek to build coding communities)
• How might choosing a proprietary technology or format limit our choices in the future?
• How can we use this approach to shake up Greenpeace culture?

Questions to ask

Steps you can take to be open

• Impact – who, how often, and unexpected
• Where and how to collaborate
• Roles + responsibilities

Key considerations

Engage customers + collaborators

• Gather input from staff and those who you will need help from (surveys, interviews, focus groups, etc.)
• Make it easy to participate + manage. Use Greenpeace established collaboration tools, like meetings and shared documents. Plan to consolidate and publish feedback (on Medium or syndicated).
• Remain open to new information and perspectives and document it. (included updated notes or reactions, highlight and respond to comments)
• Consider peer-to-peer feedback and communication options in addition to formal channels (twitter, community calls, discussion group)

Set expectations upfront

• Be specific about what type(s) of feedback you're looking for + who is making the decision(s)

• Publish decision process and project plan, with roles, dates, constraints

Explain the obvious

• Publish the scope of the project or decision, and reiterate often
• Publish decision factors and their relative importance
• Publish your research, including difficult trade-offs, business requirements
• To the extent possible, publish any relevant legal, reporting, or confidentiality concerns

Plan the transition

• Develop and gather feedback on communication, change management, and adoption plans
• Think through how you could respond to upset individuals (on memo-lists and other channels)

PHASE: Plan + Research

OPEN DECISION FRAMEWORK

INSERT DESIGNATOR, IF NEEDED

PHASE: IDEATION

• What can we pilot or release early to gather input?
• How will we test?
• Which staff members can help test?
• Does a cross-functional working group make sense?
• Can we build a community of passion around this project or decision?
• Have we engaged the people who will have to do the work?
• Who do we need more buy-in or support from?

Questions to ask

Steps you can take to be open

• Representation of different types of customers
• Unexpected impacts and use cases
• Unspoken risks and concerns

Key considerations

Build your community

• Ask departments who from their team can provide feedback
• Socialize decision with users and stakeholders, especially those that may be more vocal about impacts
• Investigate options and accommodations for negatively impacted users

Promote open discussion

• Evaluate, acknowledge, and incorporate feedback
• Highlight changes made in response to feedback
• If a suggestion won't work, explain why
• Publish progress often
• Provide regular updates to sponsors, users, and stakeholders

Make it safe to voice concerns

• Invite project team and collaborators to raise risks and concerns you've overlooked.
• Ask: What might prevent this project from succeeding? What concerns will your team have? What are we missing?
• Publish risk and limitations uncovered along the way

Conduct a premortem

• Pretend it's launch day, and people are surprised or upset. What triggered it?
• Identify changes you would make or points you might clarify in response, and make them proactively instead

Activate your ambassadors

• Equip the community to help you clear up misinformation and misunderstandings

PHASE: Design, Develop & Test

OPEN DECISION FRAMEWORK

INSERT DESIGNATOR, IF NEEDED

PHASE: IDEATION

• How will we monitor mailing lists and other feedback channels after the launch?
• If we have done early releases, will we continue to make incremental improvements based on feedback?
• How willing are we to make revisions based on feedback?
• What's a reasonable window of time for additional input and refinement?
• Did we overlook something important? How do we address it?
• Does the decision need to be revisited?
• Did open decision-making lead to the desired outcomes (slide 6)?
• How can we share our lessons learned and encourage open decision-making at Greenpeace?

Questions to ask

Steps you can take to be open

Begin with the end in mind

• Demonstrate alignment with Greenpeace's strategy, mission, culture, and values
• Outline the steps you've taken to make all decisions openly
• Highlight use of this framework
• Tell associates where to find detailed information
• Show how feedback shaped the decision or project
• Explain how to provide input after launch
• Acknowledge when you're not fully satisfied with the decision or know that others will not be
• Share your timeline or criteria for revisiting the decision
• Stay engaged with those who reject the decision

Default to open

• Reiterate relevant requirements and constraints
• Share relevant legal, reporting, or confidentiality issues
• Communicate success criteria and publish relevant metrics

Contribute upstream

• Publish your methods, lessons learned, communications, and decision criteria to an archive, so others can review past decisions, learn why a decision was made, and see how leaders have responded to similar issues in the past
• Offer guidance to others on open decision making and choosing collaboration tools

PHASE: Launch

RESOURCES

• The Open Source Way handbook – guide to creating and nurturing communities of contributors
• The Open Organization (book + online community)
• Prioritizing by impact, see grid in Máirín Duffy's “5 UX Tips for Developers”
• Opensource.com – A Red Hat supported publication focused on how open source principles can be applied to business, education, government, and more
• The Advice Process (Daniel Tenner)

INSERT DESIGNATOR, IF NEEDED

APPENDIX

Original by

HISTORY

Where the Open Decision Framework came from

• Based on principles practiced by open source communities
• Research by Duke University's Fuqua School of Business and Diana Martin (2009 – 2010); additional community resources
• Developed by the People team at Red Hat, with contributions from cross-functional focus group
• Grew from People team Project Management Office's effort to create an open project management methodology (2012 – 2013)
• Google Calendar memo-list conversations served as a catalyst to share drafts with all associates and invite participation (2014)
• Tested by IT and Engineering, in the Google Calendar bridge working group (2014 – 2015)
• Updated and maintained by Rebecca Fernandez (rfernand@redhat.com)

INSERT DESIGNATOR, IF NEEDED

WHY THE FRAMEWORK EXISTS

A collection of proven practices that:

• Drive better alignment between business decisions and our organizational strategy, goals, culture, values, and mission
• Demonstrate “what good looks like” in decision-making and communication
• Offer consistent guidance for teams and leaders on cultural expectations, balancing transparency and confidentiality
• Improve associate engagement, signal-to-noise ratio on memo-list

INSERT DESIGNATOR, IF NEEDED