Home

Have you ever tried to find a good “how to” article or a good strategy overview written for professional website managers?

I did. And I could find plenty of good stuff aimed at the “I love thinking about the Internet” set or the “I love cutting edge web technology” set. But very little at the “I am running a website group at a real company” set.

Although techie articles and pie-in-the-sky articles have their place, when you need real answers for real problems they just don’t give you what you need. You want actionable answers not down-in-the-dirt details or information about macro trends on the Internet.

So I set out to make a website that provides actionable answers to the questions that website managers ask on the topics that matter. Topics like:

  • Project Management finding big problems, coming up with solutions and mobilizing the teams to get the problem solved
  • Content Management slicing and dicing through requests for new web pages, getting the pieces together and getting it live without hiring a legion of web producers
  • Internet Marketing getting the folks to the site, getting them on the list, and then getting them through the funnel to sales or a shopping cart
  • Web Development developing the technology that makes it all possible

And while those are pretty big topics, they are the topics you deal with every day when you run a big-ish website. And if you hang with me, I am going to spill the good stuff I learned from doing this stuff myself.

The next question you are thinking is… who is this guy?

How to Build a Website Project Roadmap

Building a website project roadmap is pretty straightforward. Here we go:

Create a project list – To get started on making a roadmap you are going to need a list of projects that are coming up in the future. A project roadmap will be most useful for larger content, design and functional projects one month in length or longer so you don’t overwhelm folks with minutiae. For your first revision, I’d recommend making the roadmap for a year or less.

Order the project list – Ideally, you would order your projects from highest impact to lowest but that’s not going to work all the time... Check out this article on rationalizing your project selection process for more on figuring out the potential impact of projects. Following impact, I’d recommend ordering projects by:
1. Hard dates (like product launch or holidays),
2. Project dependencies - one project must be done before another or a project depends on something outside the project organization to happen
3. Politics – Yes, politics this will come into play, but I recommend trying to reduce it’s impact if possible.

Pick a tool – There are tons of different tools you could use to make your roadmap: presentation software, charting software, a Gantt charting, or HTML editor. It does not matter too much what you use although HTML is very easy to store on your Intranet and that’s a good place for the roadmap to live.

Create the Gantt chart – The most important part of the roadmap is the high level Gantt chart. It’s key that the roadmap fit on one page, contains a start and release date, and the all-important “this plan will change” phrase. It’s also helpful to show dependencies between projects if they exist.

Make project overview pages – Once the Gantt chart is starting to take shape you will want to create one-page overviews for each project on the roadmap. Think of this project description as a condensed project charter. Each project description should include the project sponsor, business goals, features by user interface, features not included, dependencies and assumptions.
  • Business Goal – This one is pretty simple to figure out but often not spelled out for projects. You want to list the answers to the simple questions: What problems will this project solve? Or, what opportunity is this project going to exploit?
  • Features – Now we want to list the very high level features that are going to deliver the business goals. There should be a maximum of 15 features listed. I like to list high level features by website user interface, something like “internal interface - product catalog administration” or “public interface – updated secondary navigation”
  • Features not included – Perhaps more important than which features are in the project is which features are NOT in the project. Be sure to include the features that have been discussed but have been ruled out for delivery in this project specifically.
  • Assumptions and dependencies – Spend time making sure that the document and validate any assumptions you have made about the project. For instances, assumption might say something like “assuming we have proper funding.” And make sure the dependencies spell out issues that must be resolved before the project can start with a statement something like “dependent on resolution to [the big honking problem that is keeping this project from starting]“ Skipping these documentation steps is the quickest way to turn your project roadmap from a simple communication exercise into ticking time bomb.
So now you have the outlined of how to make a website project roadmap. But it’s just a tool. And how you get the tool out there and use it will make it successful. Or not. Let’s talk rollout.