How to build a roadmap for your web strategy

How do you decided what project to do next in your web strategy? Is your approach an ad-hoc one based on knee jerk reactions? If so you need a roadmap.

This article finds us five posts into our series on web governance, and if you are still reading along, congratulations.

So far we have covered getting to know the clients business, carrying out a SWOT analysis and setting business objectives. This week we turn our attention to laying out a roadmap.

Let’s begin by looking at what a roadmap is and why you need one.

The role of your roadmap

A roadmap is a working document that outlines your proposed web projects over the coming months.

Notice that I refer to it as a working document. That is to say, it is continually being amended and revised. New items will be added all the time and you will never complete your roadmap.

It is not a wish list. Wish lists are good and I actively encourage website owners to keep a running list of ideas they would like to implement, irrespective of how viable or otherwise those ideas are. Wish lists are a place to keep note of things you would like to do. A roadmap is a list of things you are going to do.

Hopefully in time many of the items from your wish list will make their way onto your roadmap. However, before they make it, they will have to justify their inclusion. I will come on to that later.

The other important differentiation between a roadmap and a wish list is that the roadmap is prioritised. Items at the top of your roadmap are to be done first.

Each element in the document outlines a proposed project. This should include a description, dependancies and objectives of the project. Other information can be added but is not essential.

Although a roadmap is an important document, it is not a complex one. I think that people over engineer their roadmaps because they are important and therefore need to appear to be impressive.

Avoid over engineering your roadmap

Many roadmaps go into a huge amount of detail about the projects they include. I am not sure this entirely necessary.

I agree that work should be specced, its just that until you actually reach a project on the roadmap, you cannot be entirely sure what the specifics will be. After all a project may be affected by elements before it on the roadmap or new projects added later.

The other problem is that a roadmap needs to remain flexible. If each element on it is so carefully specced and specified them it becomes harder to move them and even harder work to add new projects.

My tendency is to keep a roadmap as a lightweight document, that is easy to edit and changes overtime. Only spec the next project in any significant detail.

Finally, I normally avoid adding times to a roadmap. A timeline locks projects down and doesn’t allow the flexibility to easily add or remove things. Also, lets be honest, timelines are rarely realistic.

A roadmap should allow you to easily adapt to circumstances. For example if a redesign project gets delayed because it is waiting on new branding, you should be able to move to the next item on the list. A timeline discourages this kind of thinking.

Now we have our roadmap defined. How do we decide what to add to it?

What should be on your roadmap?

Most website owners and other stakeholders have no shortage of ideas about how their site could be improved. I am going to presume that is the case for you (I will write a post in the future for those who struggle to come up with ideas).

The challenge is not generating ideas, but deciding which ideas are actually worth adding to the roadmap and then implementing.

Fortunately, we already have two great tools at our disposal for making this decision; business objectives and SWOT analysis.

Using your business objectives

The first question you need is, does this idea help achieve our business objectives? If you cannot clearly demonstrate how an idea will help meet a business objective then keep it on your wish list. You never know your business objectives may change in the future and the idea will become appropriate.

Comparing an idea to your SWOT analysis

If something passes the business objectives test, the next thing you will want to do is compare it to your SWOT analysis. Does the idea address a threat or weakness in your strategy? Does it play to your strengths or embrace an opportunity? If the answer is yes, then it is a good candidate for your roadmap.

That said, before you add it to your roadmap, it might be worth doing a quick SWOT analysis on the idea itself to get a better handle on its feasibility. After all it is possible for an idea to address business objectives but be infeasible to implement. It never hurts to look at what strengths, weaknesses, opportunities and threats a prospective project represents.

If you are unsure about whether an idea is feasible or not, consider adding a proof of concept project to your roadmap. This will allow you to test an idea out before doing a full implementation.

Once you have decided that an idea is worthy of turning into a project and adding to the roadmap, the final question you must answer is how high on the list it should appear.

Deciding priorities

Remember that our roadmap is prioritised. Items at the top of the roadmap are to be addressed first.

When you have a new idea worth adding to the roadmap, you need to decide how high on the list to add it. New items are not automatically added to the bottom. Instead, they are placed according to five factors.

  • Effectiveness. If a project is going to have a large positive impact on the business then it should certainly be weighted as more worthwhile and receive a higher place on the list.
  • Complexity. Unfortunately high impact projects are often hard to build. The complexity of the project therefore also has to be a factor. Sometimes you want to priorities less effective projects simply because they are easy to implement. Of course in an ideal world you want projects that are easy to implement and also create a big impact.
  • Dependancies. Some projects cannot be started until another project has ended. In such cases it is impossible to place them higher on the list even if they are big, quick wins. Also some projects cannot start because of outside constraining factors. In this case there is no point placing it high on the list unless you know the dependancies will quickly be in place.
  • Time constraints. Some projects need to be given priority because they must be completed by a certain date. However, be careful not to allow projects to be prioritised because of an artificial deadline. Less effective projects can often be prioritised because a champion for that project claims that it has a strict time constraint. Don’t forget that every project that ‘skips the queue’ does so at the expense of potentially more worthy ones.
  • Resourcing. You might have a great project that would make a huge difference and be easy to implement. However, if you don’t have the people with the right skills, this needs addressing first. Sometimes great projects must wait until the right people are available.

Remember that the roadmap is an ever evolving document. By the time one project is launched, another two may well have been added to the list. In addition some elements on the roadmap will be repeated regularly (such as usability testing). We will explore that more in a future post.

With your roadmap in place, you can start implementing it through a series of projects. However there are various logistic issues to solve surrounding that. This is what we are going to cover in the next post of the series. This is where we tackle the issue of web governance proper.

Map and Pin from Bigstock.com

Headscape

Boagworld