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.

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 about the change and its implications as possible.

We want to collect all relevant information regarding this 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.

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 point 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, if applicable.

5. Alternative solutions (optional): What other solutions would also alleviate this pain point? How do they compare to the proposed solution? Do they meet the solution constraints listed above?

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? It is useful to surface all questions and concerns, but 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 a long and cumbersome feedback loop, which decreases participation. A collaborative platform tightens the feedback loop, and 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 there is only one person responsible for writing and maintaining this document. All suggested changes to the document should go through this person.

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 presumably 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.

The act of writing up the proposal document (and thus doing the necessary research around the impact, advantages and disadvantages of the proposal) already brings clarity.

Disadvantages

This approach is not well-suited 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.