Drive change by writing structured proposal documents

In any collaborative environment, opportunities for change often arise. When such an opportunity presents itself, write up a structured proposal document describing how to tackle this opportunity. With this document, a decision on whether or not to implement the proposal can be made quickly and confidently.

I use this approach extensively, both at my employers as well as for side projects that are used by others. These documents are often called RFCs (short for requests for comment).

Motivation

Whether when working alone or collaborating with others, opportunities for change will come up. While many such changes are trivial, some are not:

• Changes that impact others, such as restructuring the filesystem of a project, or reformatting all source code to the latest standards.

• Changes that are not easily reversible, such as the choice of programming language or framework to use for a new project, or the switch to a new paid subscription of a third-party tool.

To make decisions on how to move forward with such opportunities for change, we need to have as much information as possible about the change and its implications.

We want to collect all relevant information regarding a potential decision from all stakeholders. At the same time, we want to make sure that all stakeholders understand the context and motivation around this change, and the impact it will have.

Proposed solution

When an opportunity for change arises, write up a document that describes how to take advantage of this opportunity. This proposal document has the following format:

1. Context (optional): What background information (if any) is needed to understand the rest of this document? Consider adding a glossary in this section to clarify any jargon that readers might not be familiar with.

2. Motivation: What pain point does this proposal address?

3. Solution constraints (optional): What is the set of requirements for every solution for the aforementioned pain point? Consider organising these in “must have”, “should have”, “nice to have”, and “optional”.

4. Proposed solution: How will the aforementioned pain points be addressed? What are the implications of this proposed solution? What are the advantages and disadvantages of this solution? Consider adding examples of how this solution would work.

5. Alternative solutions (optional): What other solutions would also alleviate this pain point? What advantages and disadvantages do they have compared to the proposed solution?

6. Open questions and concerns (optional): Are there any questions that have not (yet) been answered? Are there concerns that have not (yet) been taken into account? In this section, surface all questions and concerns, even if they might not need to be tackled in this document.

Write this document on a platform that supports collaboration, and has fine-grained commenting functionality, such as Google Docs or Notion. While other approaches work (e.g. sending Word documents and updates to them over email), they have long and cumbersome feedback loops. A collaborative platform tightens the feedback loop, and thereby increases participation. Increased participation means more information is shared, and thus increases the quality of the decisions.

Perform research for decisions asynchronously. Avoid making decisions synchronously, e.g. in a real-time meeting.

Ownership

Ensure that a single person is assigned as the owner of this document. The owner is responsible for writing and maintaining this document. All suggested changes to the document should go through the document’s owner.¹¹¹ If “owner” sounds too rigid, consider “steward” instead.

Lifecycle

Until the proposed solution in this document is accepted, keep the proposal document updated with any new information that comes in. Ensure that all people involved are aware of updates to the document.

Ensure that there is a clear point where the proposal is either accepted or rejected. Setting a deadline up front can be useful.

Example

This very document you’re reading is structured using this format.

Advantages

By documenting the decisions around proposals, a historical record can be kept, and can be referred to later on if needed. In particular, it can shed clarity on the constraints that were (and perhaps no longer are) present when a past decision was made.

This approach ensures all potential stakeholders are involved in the process, and that their input is taken into account.

With this approach, not everyone is required to participate in the process. In this way, this approach can be used to get people on board with breaking changes by radiating intent.

Disadvantages

This approach is not well-suited for trivial decisions, nor for urgent decisions.

Open questions and concerns

• It might be worth adding a RACI matrix to the document, to state who is responsible, accountable, consulted, and informed.

• It might be worth documenting the thought process that went into the proposed solution. References (bibliography) would then probably go into a subsection of the Proposed solution section.