How to Write a Roll-On Plan

The momentum from an intense product roll-out needs to be harnessed. Here’s how.

In my last couple of articles (which can be found here and here) I detailed my sketchy performance at Android mobile phone app development over the last few years. One of the points I raised in the post-mortem piece was that we, as a team, would have benefited from having a “roll-on” plan in place, which would have come into play once we had finished our initial launch – once the roll-out of the initial version of Indoor Cycling Coach was complete. This sparked a small question in my noodle: what the hell is a roll-on plan?

Googling the phrase “roll-out plan” resulted in pages upon pages of results. Not so for “roll-on plan” – I do believe I have accidentally coined a phrase. I thought I’d run with this, as it’s not every day that I come up with something that has relevance to anything, so the concept of the roll-on plan interests me and is worth exploring. Over the last month I’ve been experimenting, and have come up with a format for a roll-on plan that I’m finding very useful. Writing a roll-on plan is certainly not for everyone, and for large organisations it’s probably a waste of time, but in skeleton crews this could prove helpful.

So what the hell is it?

Let’s start with its progenitor; the roll-out plan. A roll-out is a staged series of tasks and activities, leading to the ultimate result of a product or service being released to a customerbase. The roll-out also includes all activities that are part of the bedding-in period that dictates product acceptance. With this as our definition, a “roll-out plan” is a plan for delivering a release of a product or service, including all the elements that must be put in place for acceptance by the customer/marketplace/end user.

As the roll-out itself fully involves the settling down of the bedding-in period the roll-on plan is nothing to do with the current release-in-progress. The roll-on period is that which comes after a product has settled and nestled into place. A synonym for “roll-on plan” could be “what will we be getting up to next?” The roll-on plan’s main purpose is to ensure a swift and painless re-allocation of people and resources to their next project(s), so that everyone has at least an idea of what they are working on next. It also forces the planner to confront the resourcing conundrum early, which will mitigate later bottlenecks. In a large company the notion of a roll-on plan would be ridiculous, but in a tiny outfit the planning process tends to be more freeform and transient, thus even a diminutive one-page document can make an enormous difference to the rebasing of the business. It’s there to provide a brief mission statement to re-ground the team after the intensity of the roll-out has abated. The roll-on plan should be written at the same time as the roll-out plan – the two documents can be considered siblings. It is no use trying to write a roll-on plan after a roll-out has commenced; you won’t have time.

It’s going to be a short document, probably around half an A4 page and certainly no more than one page, taking the form of a series of headings under which you will write one or two sentences. The headings I’m using are as follows:

  1. Project: state the next project the team will be working on.
  2. Purpose: state the business case for doing the project.
  3. Size: state the expected end date of the project, or a simple description of its scale.
  4. People: state who is involved in the next major project, and what their responsibilities are.
  5. Resources: state what additional resources will be required to make this project happen.

If several projects are to be undertaken simultaneously each heading will need several subsections, briefly describing each project under Direction and Purpose, followed by estimates of the overall time burdens required under Size, and assigning various people and resources to them under People and Resources.

The best way to sum up the future direction of the business is to state the next major project or projects that the team will be working on. This could be the subsequent version of the current product, a revamp of the corporate website, a consulting job, or a whole new product line. It could be development, design work, or even feasibility studies for the next version or a separate product. It might include one or two details regarding the further development of the current version.

If the answer to the question “what are we working on next” is “support” then I’d question my business’s momentum. In business I am not an advocate of constant growth, but if I can’t conjure an inkling of an idea for a future project then I am directionless and at the mercy of my competition. It is a given that large quantities of time will be committed to “support”, so this isn’t a valid answer. The smallest fragment of a kernel of an idea for a future product or project is worth writing down, just to get the brain juices flowing, even if the release of the resulting product will be years away.

A reasonable answer to the question “what are you working on next” might well be “consolidation”, which seems similar to “support” but is an entirely different beast. It’s not unreasonable to have to dedicate lengthy time to restructuring and reinforcing your business practices after a major product roll-out, especially when working with a skeleton crew. It doesn’t seem to be very forward-thinking, but establishing a foothold is as an important task as any. I’d still recommend that the roll-on plan pays lip service to future product ideas, even if these are to be worked on after a lengthy period of consolidation.

The project description you stated in the previous section needs justifying: what is the point of doing it? What benefits will it bring? No need for a massive in-depth analysis, keep it short and to the point.

If possible estimate a completion date for the project. If this can’t be conjured then state the size of the project in the number of weeks of work, or even in just very simple terms (small, medium, large). If using the latter method then ensure you keep the size estimates across different projects consistent, so that one person’s idea of “a small project” doesn’t equate to another’s idea of “a bloody massive project”.

Detailed project and product brainstorming/planning has no place in the roll-on plan, but you can begin to plan who will be expected to be involved. Answer the question: “who will be involved in the next project, and what are their roles/responsibilities”. If you’re writing a roll-on plan that highlights several projects, and the same person’s name keeps appearing across all of them, loaded with responsibilities, then you know that you’re going to have capacity problems with their time.

If you have some clarity over the next project to be undertaken then answer the question: “what resources will be required to make this happen”. Possible answers could include additional hardware, the purchase of a JavaScript framework or a plugin for the integrated development environment. The resources plan might be less about what needs to be bought, and more of a feasibility investigation, an example answer might be:

To build the reporting software we’ll need a JS framework that supports rich graphing capabilities. We currently don’t know anything about this, so we need to research and compare various technologies.


For a little perspective, let’s toss a few quotations out there:

Plans are of little importance, but planning is essential.

— Winston Churchill

Plans are nothing; planning is everything.

— Dwight D. Eisenhower

No battle plan survives contact with the enemy.

— Helmuth von Moltke the Elder

It is not expected that your roll-on plan will come to pass precisely. You might scrap a proposed future project in its entirety, new work might materialise, staff might leave, or you might realise that the new ultra-powerful PCs you thought you needed were never necessary. For me, the purpose of the roll-on plan is twofold:

  1. To focus my mind now: to force myself to have a conversation with myself and my team, to confront decisions that will have to made at some point in the future anyway, and will benefit from the extra time being mulled over.
  2. When the time comes to start something new it forms an instant briefing document for the team, so we can regroup and reorganise quickly. Working in small teams is all about adaptability and speed.

The problem we had at Twelve Gauge Software was that after the roll-out period finished we didn’t have a clue what we were expected to do with ourselves next. The roll-out of the initial version of Indoor Cycling Coach was a protracted affair with no real end – after the app went live on the Google Play store we had a measly few hours of blissful peace before the bug reports and feature requests started to drift in, and we simply bared our teeth and flung ourselves back onto the mounting workload, exactly as we had been doing during the development of the product. With no clear delineation the roll-out drifted and mutated into an ongoing support phase.

We knew there’d probably be a second version at some point, but we never really tried to plan this in advance. The notion of actually planning a follow-up came up when we started to receive feature requests that were clearly beyond the remit of the current version. If we’d sat down together for a brief discussion before the release of version 1 we almost certainly would have raised the question of their being a premium version of the app, and this question would have been quickly answered: “yes, there probably will be”. We would have at least had our expectations primed for the work ahead of us. But we were too busy getting swept up in the excitement of the approaching roll-out to give it much consideration. This discussion should have happened long before the roll-out itself even began. If I’d known the things then that I know now then I’d have arranged things differently, but I suppose that’s the point of hindsight – it’s always 20:20.

Back to Top