Photo by Ross Findon on Unsplash

Writing up a request for comments

A story about doing the necessary investigation required for sustainable organisational change

  • We need to spell out how their solution works
  • We can be challenged directly on our assumptions, as well as why other solutions aren’t as good
  • We (or others) can follow up whether changes had the anticipated effect
  • Means we’re explicit at both intended and actual ROI
  • A sales document


A template for this can be found on GitHub’s Gists section, but below we go through each of the components of the RFC:


A summary of the proposal, including description, benefits, risks and estimated costs. Some general guidelines include:

  • Pique interest


A proposal affects more people then it may initially seem. While proposing a change may make sense from the authors point of view, the author should consider the ramifications to others, and document in the proposal how this change will affect them. Some example stakeholders include:

  • Marketing Team
  • Development Team
  • Administration Team


An outline of the problem that the proposed solution will solve. If a proposal does not solve a problem it is worthless. Outline any efficiency improvements as problems. For Example:


The solution to the problem as defined in ‘problem’ section.

Anticipated Difficulties

Any set of change will come with it a set of difficulties. The greater the change, the more it’s likely to cause a disruption — to cause problems. It is better to find and estimate these new issues, as well as illustrate how they can be addressed to mitigate any damage. Even if a problem does not have a solution, list it regardless. A problem with a solution is better, but opening up the problem for discussion may contribute a greater chance of the change being accepted.


Risks are new things that may provide unexpected difficulties as a result of the change. Risks are different than anticipated problems in that they’re accepted as an event that may happen, but not one that will definitely happen. For example, a proposal may increase costs for a short period. Or it may cause a level of disenfranchisement to the affected team.

Previous Examples

Previous examples are useful to give credence to the idea that this proposal is possible, as well as give consumers of the proposal ways they can find answers to questions that this proposal does not address.

Expert Opinion

Experts in a given area can help provide a measure of credibility to the proposal, as well as allow users to follow up with those users to seek further clarification on the issues that they’re raising.

Estimated Costs

Estimated costs are the required expenditure to implement the change.

  • New equipment / product / system purchase
  • Reskilling time, or time lost to team members being required to re-skill to operate in the changed environment.


The steps the organisation will go through to implement the change. It’s helpful when thinking about the implementation to consider each of the steps that people will take.

Completion & Evaluation

Once a proposal has been rolled out, it needs to be subject to evaluation. Change is wildly unpredictable, and should be subject to critical analysis.


Though much effort has been put in to making sure proposals are successful, many (perhaps most) of them will fail. The nature of the status quo is it’s economically given to be the status quote — to change it will require changing the economy itself.


Generally speaking these should be automatically generated; I use the Bibtex extension for Asciidoctor, and mark things up in APA format.

In Conclusion

Change is a difficult topic — far more so than it may seem at the outset. It can upset people, cause chaos, break timelines and budgets and generally be a difficult thing indeed. However, organisations that do not change wither on the vine, eventually succumbing to another, more agile company.

Post Script

I use a template for these now. You can see it here!