# NIST OSCAL Team Authoring and Deciding

## Executive Summary

We ought to annotate documents and decisions, maybe even items at the granular level, [with a RACI chart](#RACI-Chart-Clear-understanding-of-roles), and clearly define states from beginning to end.

stateDiagram-v2
    [*] --> DRAFT
    DRAFT --> FEEDBACK
    FEEDBACK --> REVISION
    REVISION --> FEEDBACK
    REVISION --> REVIEW
    REVIEW --> APPROVED
    REVIEW --> REJECTED
    REJECTED --> DONE
    APPROVED --> SOCIALIZE
    SOCIALIZE --> DONE
    DONE --> [*]

We can find lightweight ways of annotating this on documents, regardless of tool, but adapt information in any tool to consistently identify this information.

## Background

In the NIST OSCAL Team, we often need to author a document. This document needs to be written or presented in writing for feedback and review. Similarly, when executing a plan, we reach a key decision point and we must review that as group, provide feedback, and a responsible member or members must decide. It is often unclear who performs what role in these two kinds of task as they frequently arise, what is the status of a document or decision, and how to manage the progression from initation to completion.

We need the following.

1. Clear understanding of roles in a document or decision.
2. A lightweight process for understanding the status of a document or decision.
3. A process that identifies the cycle of feedback, revision, and completion of a document or decision in relation to these roles.

## RACI Chart: Clear understanding of roles

To clarify roles in a lightweight way that will not require a novel invention, I am recommending we have [a RACI table](https://www.forbes.com/advisor/business/raci-chart/) with named team members where applicable in a tracking tool and/or the document/decision itself.

RACI is short for Responsible, Accountable, Consulted, Informed. In a document or decision, the team member or larger community would play one of the roles below.

- **Responsible:** Responsible designates the task as assigned directly to this person (or group of people). The responsible person is the one who does the work to complete the task or create the deliverable. Every task should have at least one responsible person and could have several.
- **Accountable:** The accountable person in the RACI equation delegates and reviews the work involved in a project. Their job is to make sure the responsible person or team knows the expectations of the project and completes work on time. Every task should have only one accountable person and no more.
- **Consulted:** Consulted people provide input and feedback on the work being done in a project. They have a stake in the outcomes of a project because it could affect their current or future work.
- **Informed:** nformed folks need to be looped into the progress of a project but not consulted or overwhelmed with the details of every task. They need to know what’s going on because it could affect their work, but they’re not decision makers in the process.

A notional example table in a document or decision is below.

(Note: part of an example document for planning our first international OSCAL concert tour.)

| Role | Assigned |
| ------------- | --------------------------------- |
| Responsible | Alexander Stein |
| Accountable | Wendell Piez |
| Consulted | David Waltermire, Michaela Iorga, Arminta Jenkins, Chris Compton, Dmitry Cousin, Nikita Wootten, Wendell Piez |
| Informed | OSCAL Community |

Alternatively for general brevity or to denote this information on individual items and tasks to make it applicable to general documents and decisions or granular items:

(R: AJS; A: DW, MI; C: DW; MI; AJ; CC; DC; NW; I: Community)

It is worth noting as it is critically important: any person can be in multiple roles, but inevitably only one person can be in the accountable role for any document or decision to accept it. Multiple people can be assigned to other roles, even if overlapping, as demonstrated by the example.

## Process

With roles in place, we should be able to envision a simple process of drafting the initial version, providing feedback, revising with feedback, reviewing, and completing a document or decision.

1. **DRAFT:** The responsible person or persons are writing the first draft of a document and decision, they must complete the draft and change status to **FEEDBACK** when drafting is done and they are ready for feedback.
2. **FEEDBACK**: The consulted person or persons will provide feedback on the decision or document. If they have no feedback, it is recommended they put a notation (to be discussed below) to indicate they reviewed the decision or document, but accept it as-is and have no feedback to provide.
3. **REVISION:** The responsible person or person(s) incorporate feedback into the draft until they are ready for feedback again.
4. **REVIEW:** After one or more cycles of review, the accountable person or person(s) is expected in the **REVIEW** state to review the decision or document, accept it, return it back to the responsible group for further revision, or reject the decision or document.
5. **APPROVED/REJECTED:** The accountable person has marked the decision or document as approved or rejected. If approved the accountable person or persons must choose to socialize to the informed person or person(s).
6. **SOCIALIZE:** With this status the accountable or responsible party is in the process of notifying the informed person or person(s). The decision or document stays in this state until it is done.
7. **DONE:** The decision or document is complete, and the person or person(s) in the project can move to the next decision or document.

A state chart is [defined in the executive summary](#Executive-Summary) to more visualize the different possible states.

Therefore, a status notation and a deadline field, in combination with a full or abbreviated RACI table as proposed, is lightweight and can be used ostensibly anywhere.

| Status | Deadline |
|--------|------------|
| DRAFT | 2024-01-01 |

| Role | Assigned |
| ------------- | --------------------------------- |
| Responsible | Alexander Stein |
| Accountable | Wendell Piez |
| Consulted | David Waltermire, Michaela Iorga, Arminta Jenkins, Chris Compton, Dmitry Cousin, Nikita Wootten, Wendell Piez |
| Informed | OSCAL Community |

Below is the same example like above but in a shorthand notation for brevity generally on a decision or document, or perhaps on granular items for complex projects.

(DRAFT; 2024-01-01; R: AJS; A: DW, MI; C: DW; MI; AJ; CC; DC; NW; I: Community)

As alluded to before, in the case of feedback, it is important for every consulted person to acknowledge they reviewed it, even if they have not provided explicit feedback in written or verbal form. Therefore, in the case of **FEEDBACK** status, the team members can add their initials after that status to acknowledge, whether or not they provide explicit feedback, they have effectively been consulted. Below is such an example.

| Status | Deadline |
|--------------------|------------|
| FEEDBACK: DW, MI | 2024-03-01 |

| Role | Assigned |
| ------------- | --------------------------------- |
| Responsible | Alexander Stein |
| Accountable | Wendell Piez |
| Consulted | David Waltermire, Michaela Iorga, Arminta Jenkins, Chris Compton, Dmitry Cousin, Nikita Wootten, Wendell Piez |
| Informed | OSCAL Community |

(FEEDBACK: DW, MI; 2024-01-01; R: AJS; A: DW, MI; C: DW; MI; AJ; CC; DC; NW; I: Community)

In this example, AJ has completed a draft of a decision or document and requested feedback by 1 March 2023. So far, only David and Michaela have completed their feedback, but Arminta, Chris, Dmitry, Nikita, and Wendell have yet to do so. AJ will expect to wait until the deadline for the others to provide feedback, and if they have not commented on the decision or document bad their initials, he can be confident they found the document acceptable without any critical feedback warranting revision.

## Complete Example Process Flow

TBD