How to make your proposals bulletproof

The simple exercise that will save you months of wasted effort

At Change.org we’ve seen our fair share of ideas that went off the rails during implementation. They sounded good during the planning phase, but during the build phase we came across issues that extended the timeline (sometimes months or more) and ultimately burned through the ROI we had modeled out.

To combat the problem and keep projects on track, we recently adopted an exercise to proactively elevate and manage risks called “ROAM”. We’ve found it to be really effective. In fact, it’s nearly impossible to lose with this approach — in most cases it adds just a few more days to a project, instead of losing potentially months or years on a bad idea.

What exactly is the ROAM exercise?

ROAM stands for Resolved, Owned, Accepted and Managed. I’ll get to what these represent in a minute, for now this is the process for elevating and managing risks:

1. It starts with a meeting where a proposal is described and participants brainstorm possible risks
2. Owners are assigned to investigate risks and recommend solutions
3. The solutions are discussed and the proposal is revised

An example

Recently, our Front-end Platform team (responsible for the foundation of our website) started considering two different technologies to power a key piece of our new foundation (for the technically curious, it was between GraphQL and Falcor).

Decisions like these have big implications: codebases stick around for a long time so we need to be vigilant about decisions that could come back to haunt us.

Our last codebase

The FE Platform team created a presentation on these two choices. To get a diversity of opinions, a number of representatives across our product development group participated in the kickoff session.

1. Introduce the proposal

The presentation contained both an overview of each choice and a point of view about the benefits and drawbacks of adopting either option, so the group had a position to draw opinions from.

2. Brainstorm risks

Everyone in the room took 10 minutes to write down all the risks of adopting GraphQL that they could think of. In this instance, because we were trying to make a decision between two options, we also spent 10 minutes on Falcor.

These aren’t just technical risks. For example, one risk could be “Difficult to hire people with this experience” or “Lack of community support” — this is why it’s important to have a diversity of voices in the room.

3. Visualize impact and likelihood

Each participant went over each risk they wrote down and we discussed how likely it was to happen, and if it did happen, how bad it would be.

Each risk was placed on a chart:

Putting the risks on a chart helps visualize the highest priority risks

4. Categorize

Starting from the upper right corner (risks that will be really bad and likely to happen) and moving down to the bottom left (not that bad, and not that likely), the facilitator asked the group which category each risk should fall into on the ROAM board.

The ROAM legend

• Resolved: After discussing, there’s no risk after all
• Owned: We don’t know what to do, so someone will find out
• Accepted: It’s a risk, but we’re going to live with it
• Managed: We already know what to do and who is in charge

All of the risk categories are important to identify, but Owned is the only section to pull next steps from because it means “this risk is important to resolve, but we don’t know what the resolution is yet.”

5. Next steps for “Owned” risks

We moved each sticky from “Owned” onto 3x5 cards and filled out:

• What the next step is
• Who is responsible
• When the proposal will be complete

This is your opportunity to assess and resolve risk, so make sure each owner has the time to dive deep!

At the end of this process, this is what our ROAM board looked like:

No risks from Falcor needed to be immediately investigated because we had already invested some effort into using it. Be flexible with this exercise so it works best for you!

6. Reconvene and update the plan

Now that we had the results of our risk assessments, we reconvened to make a decision. In this instance we ultimately decided on GraphQL because two risks with Falcor were predicted to cause too much burden: lack of community support and difficulty hiring and retaining talent.

There’s no magical calculation you can do at the end of this process. The group has to take stock of the risks in front of them and do their subjective best to determine the best path forward.

It’s not just about choosing a path forward

What’s particularly great about the ROAM process is you’ve not only identified risks, but also their solution paths. Planning is essential for great execution. You’ve just fed two birds with one scone.

If you want to try out a ROAM exercise for your org, we put together this guide that you can use for your own ROAM exercises.