title: Open Decision Framework url: https://github.com/red-hat-people-team/open-decision-framework/blob/master/ODF-community.md#open-decision-framework hash_url: 272e63c4d3672925043c6bfa06f19ed9 Community Version 1.0.4 Updated Apr 10, 2017 © 2014-2017 Red Hat and contributors | The Open Decision Framework was created by the Red Hat People team and is available under Creative Commons Attribution-ShareAlike 4.0 International License ([CC BY-SA 4.0](https://creativecommons.org/licenses/by-sa/4.0/)). Red Hat and the Shadowman logo are trademarks of Red Hat, Inc. registered in other countries. Modified versions must remove all Red Hat branding. Notes ========= * This markdown version of the slides is intended to facilitate easier collaboration and tracking of changes. * Page numbering corresponds to the LibreOffice (.odp) and PDF files in the repo. Contents =========================================================================== * [Overview](#overview) * [What is an open decision?](#what-is-an-open-decision) * [Open decisions are made using open principles](#open-decisions-are-made-using-open-source-principles) * [How open source principles lead to better decisions](#how-open-source-principles-lead-to-better-decisions) * [You can't please everyone](#you-cant-please-everyone) * [Open Decision Framework](#open-decision-framework-1) * [Phase or activity: Concept, Define, Ideate](#phase-or-activity-concept-define-ideate) * [Phase or activity: Plan, Research](#phase-or-activity-plan-research) * [Phase or activity: Design, Develop, Test](#phase-or-activity-design-develop-test) * [Phase or activity: Launch, Deploy, Close](#phase-or-activity-launch-deploy-close) * [Resources](#resources) * [Appendix](#appendix) * [History: Where the framework came from](#history-where-the-open-decision-framework-came-from) * [Why the framework exists](#why-the-framework-exists) Overview =========================================================================== **What it is** - A flexible, open approach to making business decisions and leading projects **When to use it** For decisions and projects that are likely to: - impact our culture or - affect associates beyond your immediate team **How to use it** - Build steps from the Open Decision Framework into your project plan or decision-making process What is an open decision? -------------------------
Transparent | Inclusive | Customer-Centric |
Explain who is making the decision, what problems you're trying to solve, the requirements and constraints involved, and the process you will follow. | Engage others for feedback and collaborate throughout the decision-making process. Seek out diverse perspectives, including potential detractors. | Think of people as customers with competing needs and priorities. When a decision will help some customers, but disappoint others, manage relationships and expectations while getting stuff done. |
Principles | → | Practices | → | Outcomes |
• Open exchange • Participation • Release early + often • Meritocracy • Community |
→ → → |
• Transparency with internal customers and other stakeholders • Customer involvement • Gain feedback and adapt iterative changes • Ideation with customers • Build trust and respect via collaboration |
→ → → |
• Customer buy-in • Stronger and faster adoption • Best ideas win • Fewer bugs, issues, and unanticipated impacts • Higher associate engagement • Decisions aligned to strategy and culture |
Steps you can take to be open | Questions to ask | Common flamewar triggers |
Lead with transparency • Publish a problem statement and possible approaches • Identify any aspects of the project or decision that cannot be open • Publish your ideation process Build diversity of thought + an inclusive environment • Engage internal customers and stakeholders early on, especially those who may disagree • Seek out diverse and underrepresented perspectives (geographies, ethnicity, departments, job levels, gender, age, etc.) • Champion collaboration and provide channels for feedback • Address risks, limitations, and potential cultural impacts, especially with historically controversial issues |
• 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 else could be impacted? • Who has solved a similar problem? • Who is likely to disagree, dissent, reject, or opt out? Who else may care? |
There are a handful of issues that often generate controversy and upset within Red Hat, including: • Decisions, policies, or changes that impact associates, such as rewards and wellness programs • Changes to associates' work environment • Implementation of proprietary technology • Use of proprietary formats • Data privacy and sharing If your project or decision involves any of these themes, take extra steps to make your process open, inclusive, and transparent. |
Key considerations | ||
• Confidentiality, privacy, and regulatory requirements • Potential to generate controversy • Impact on Red Hat's culture and future decisions • Roles + responsibilities (OPT model: https://github.com/red-hat-people-team/opt-model/) • Where to publish |
Steps you can take to be open | Questions to ask | |
Engage customers + collaborators • Gather input from internal customers and those who you will need help from (surveys, interviews, focus groups, etc.) • Make it easy to participate + manage. Ask customers which collaboration tools they prefer to use. Have a plan for consolidating and publishing feedback. • Remain open to new information and perspectives • Consider peer-to-peer feedback and communication options in addition to formal channels 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-list and other channels) |
• How will we make decisions? • What internal customers, stakeholders, and collaborators will we involve? • How will we engage and communicate with them? • What are the open source options? • How might choosing a proprietary technology or format limit our choices in the future? • How does this align with the company strategy and mission? • Where might this conflict with Red Hat's values and culture? |
Key considerations | ||
• Impact – who, how often, and unexpected • Where and how to collaborate • Roles + responsibilities (OPT model: https://github.com/red-hat-people-team/opt-model/) |
Steps you can take to be open | Questions to ask | |
Build your community • Ask departments who from their team can provide feedback • Socialize decision with customers and stakeholders, especially those that may be more vocal about impacts • Investigate options and accommodations for negatively impacted customers Promote open exchange • Evaluate, acknowledge, and incorporate feedback • Highlight changes made in response to feedback • If a suggestion isn't feasible, explain why • Publish progress in an open place • Provide regular updates to sponsors, customers, 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 |
• Can we pilot or release early to gather input? • How will we test? • Which internal customers 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? |
Key considerations | ||
• Representation of different types of customers • Unexpected impacts and use cases • Unspoken risks and concerns |
Steps you can take to be open | Questions to ask | |
Begin with the end in mind • Demonstrate alignment with Red Hat's strategy, mission, culture, and values • Outline the steps you've taken to make this decision 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 business 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 the 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 |
• 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? • How can we share our lessons learned and encourage open decision-making at Red Hat? |