Roadmap development #1

Submitted by Nicolabell on Tue, 03/05/2019 - 15:54

I'm researching about roadmaps; what they are and best practice for creating them. I have developed some in the past for work but not with any great understanding of whether on the right track, but luckily I have learned quite a lot about writing them from that experience.

What is roadmap?

In short this is a strategic plan for your project and it’s desired outcome that the team and client can look at and understand easily, which will be updated as the project progresses.

Some benefits of a roadmap:

  • It helps the team know that they’re on the right track with the time and resources available to them

  • It reveals gaps in production plans - i.e. if you are mapping out the process ahead of starting it you might discover that how you’d expected to deliver it might actually need some re-working or additional features to progress to the release of the software.

  • You can mitigate potential problems that you’d otherwise crash into without a roadmap, and this will save time and resources in the long run.

  • It improves communication and understanding between all team members but also with the client - regarding the strategy

  • Manages expectations

  • Increases efficiency

  • Keeps focus and clarity


Advice about creating a roadmap from other people and my own experiences:

  • Don’t over engineer it - this is a working document which will change with time, so it needs to remain flexible/agile. Putting a load of detail in to it before the project is on the offing could be a waste of your time which could be better spent elsewhere.

  • This is also not a list of features / detail. This will go on your Kanban board / gantt etc.

  • Be realistic with time scales. (This is why I don’t like adding dates to my own project plans; just estimates of how long each phase will take.) Obviously if you have a deadline for release then you will need to stick to it but don’t be too rigid about how you allocate time within the project.

  • Make sure not to work too linearly - if there’s a hold up in one part of the project you should be able to work on something else until the bottleneck for the other bit of development is cleared. Waterfall approaches have too much of a restrictive timeline so you might want to avoid this.

  • Someone else viewing your roadmap should be able to understand it within a couple of minutes of looking at it

  • You should keep it up to date


What it should be:

It should communicate

  • the plan to team members and client

  • to clients what to expect and when

  • what resources, budget and time are available during the project

  • What the milestones are

  • What the potential issues are

  • What you need from the client and the team.


Next: How to build a roadmap….