Skip to content

Latest commit

 

History

History
175 lines (131 loc) · 8.26 KB

CommonFactBase_Master_External.md

File metadata and controls

175 lines (131 loc) · 8.26 KB

Common Fact Base Template (for GitHub)

What Is a Common Fact Base?

A comprehensive set of information that allows all stakeholders (past, present, and future) to have a shared understanding of important facts and information about a given problem, project, or decision.

How to Use This Template

  • Fork the GitHub repo.
  • You could copy and paste or import it into a wiki page or collaborative platform.
  • Fill out all applicable fields.
  • Customize as needed. Delete the tops, unused sections, etc.
  • Publish early and update often.
    • You could incorporate it into an existing project wiki or website.
    • As your project or decision progresses, continue to build out new sections and add details. You might want to break this into smaller documents.
  • Use collaboration and feedback features to support your open decision making process, e.g. comments, polls.

Make It Comprehensive, Yet Consumable.

Use the inverted pyramid method to organize content.

Have a Project Charter?

If you compelted a project charter, publish it as the first piece of your common fact base. As your project progresses, build your common fact base by adding info suggested in this template.

Decisions to Make Before Publishing

  • Where will you publish? The idea place is:

    • easy for your project team to update and manage
    • easy for your stakeholders to access and navigate
  • Who will be able to view this and other documents?

    • At Red Hat, we default to open. If there's no good reason to restrict access, we try to make it visible to everyone.
    • That said, organizational cultures and norms vary, so make sure your project sponsor and teams are comfortable. Discuss the risks and benefits.
    • For highly sensitive projects, consider slowly opening access in concentric circles.
    • If a project is "sensitive" simply because people may react negatively, you can build trust and respect (and give people time to navigate the grief curve) by being open from the start.

The template begins below.

[Name of your decision of project]

Problem

Problem statement (1-2 sentences)

  • Learn more (link to details below)
  • Problems we're not trying to solve (link to ever-growing list)

Objectives

  • What you want to do about the problem, in broad terms. Desired future state.
  • What "good" would look like, in 1 - 2 sentences that anyone can understand.
  • May not be needed, if captured in problem statement.

Who May Be Impacted

  • Hint: they are usually your stakeholder groups and potential stakeholder groups.

Timeline

Phase Ideation + Research Prototyping + Testing Development Launch
Timing Jan - May 2017
* complete *
Apr - Jun 2017
* in progress *
Jul 2017 - Aug 2017 Sep 2017
Milestones
  • Gather ideas from stakeholders (link to details on ideation process + ideas gathered)
  • Identify up to 5 potential solutions
  • Build prototypes
  • Document limitations
  • Select solution for full development
  • Develop and harden solution
  • Identify launch risks
  • Roll out solution
  • 30 day survey
  • View detailed timeline and project plan (*link to details, e.g. view-only smartsheet or other document)
  • Link key milestones in timeline to relevant documents and details, where people can learn more.

What's Happening?

  • Latest status update goes here
  • Learn more (link to detailed notes)

Make Your Voice Heard

Questions? Ideas? Here's what to do:

  • List feedback + collaboration channels; highlight opportunities to provide input (e.g. surveys, join focus group, comment on this page).
  • Share feedback loop
  • Share decision-making process
  • Explain how to stay informed
  • Learn more

Team

(Could also be titled "Roles + Responsibilities")

Executive Sponsor Project Sponsor Project Owner Stakeholders Contributors Questions?
Name, title, team, contact info, etc. Name, title, team, contact info, etc. Name, title, team, contact info, etc. Name, title, team, contact info, etc. Comment on this page. Or contact so-and-so. Whatever you want them to do.

Open Decision Making Targets

Based on our project team's experience and the scope of this project, we are aiming to demonstrate the following maturity levels as we apply the Open Decision Framework:

Communication Transparency Release Early + Release Often Collaboration
ESTABLISHED TRANSFORMATIVE ESTABLISHED TRANSFORMATIVE

What We've Learned So Far

  • Shoft the wording of headlines like these, as your project progresses

Possible Approaches

  • In the early states, list any option or solution under evaluation or consideration.
    • As your project progresses, update heading (e.g. "Approaches we're testing," then "Proposed solution").
  • Learn about other solutions considered (link)

Business Requirements

  • High-level, most important requirements (up to 5)

Constraints

  • Key constraints on the decision or project
  • Include relevant legal, reporting, confidentiality, etc. factors (to the extent possible)

Assumptions

This is where you'll want to state the obvious (and invite others to question your reasoning). Need help?

Risks

  • Known risks, potential areas of controversy, cultural impacts, unintended impacts

Decision Criteria

  • High-level, most important criteria
  • Weighted importance

Scope

  • Clearly define what's in and out of scope. Link to details explaining why, if needed.

Tradeoffs

  • When you have to give something up to gain something better, explain it here.

Revisiting This Decision

When do you anticipate revisiting this decision? Timeline or criteria or key factors that would contribute.

How to Provide Feedback After Launch

  • Think about this, then include some version in your fact base at each phase of the project, to demonstrate your willingness to own the outcome of the decision.

Research

Feedback Gathered

  • Summarize + link to details
  • Changes made based on feedback
  • Changes not made, despite feedback (and why)
  • Prototype + user testing results
  • Post-launch feedback and metrics

Data and Findings

  • Summarize and link to details

Background

History + Context

This is probably the first paragraph of your first draft or launch communications. Sorry, it belongs down here.

About the Problem

The super detailed version of the "Problem" section goes here.

Problems we're not trying to solve:

  • Related problems that you know people will ask you about
  • Related things you wish you could solve, but cannot
  • Optional, but very helpful to include

Detailed business requirements:

  • Requirement #1: Details here to help others understand it
  • Requirement #2: Details here to help others understand it
  • Order from most to least important. Include info like weighting, relative importance, etc.
  • Link to detailed requirement documents, if it's complex.

How We Gathered the Requirements

Explain the process and stakeholders you worked with, external research, etc. Helps validate them.

  • Link to detailed data, survey results, etc.

Other Solutions Considered

(could provide a solutions evaluation matrix, instead)

Eliminated early on:

  • Name + why
  • Name + why

Eliminated later in the process

  • Name + why
  • Name + why

Good solutions that we didn't move forward with:

  • Name + why (e.g. higher cost, might reconsider in the future, etc.)