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?

Build a Website Project Roadmap Series (Complete)

Walk down the hall at work and ask the first person you see “what’s the next project the website team is going to work on?” Or “what are we trying to get up on the website by the end of the year?”

Instead of the answers you got like “ahh” or “ummm”, wouldn’t you rather hear a glowing oratory about the bright shiny website features you have planned?

Yeah, it would be great if that person walking down the hall, or anybody in your company, knew the plan. But the best way to communicate your plan isn’t a fireside chat with each person in your company. The best way to inform your group and your company about the future of the website is a project roadmap.

A project roadmap is a high level Gantt chart of upcoming projects with some bits added. So that folks get an understanding about what each project is I like to add a project description, which spells out the business problem, a high level feature list, a list of features NOT in the project with a tight set of dependencies and assumptions.

Now some of you are reading this thinking “Are you friggin’ nuts? That hard ass project sponsor guy (you know, THAT guy), will see the roadmap, and take it to be the ‘set in stone’ plan. Then he will hold my feet to molten lava until I deliver each and every detail of these projects as ‘promised’.”

And you are thinking, “I have very sensitive feet”

Yep, we are hitting on the two balancing acts in a good roadmap:

· Providing just enough detail to inform folks of a plan without getting into the implementation details and second
· Providing future project information is likely to change without firmly setting expectations.

The good news is that we can knock both of these problems out with just a bit of document formatting.

To keep things high level without getting into implementation, all we need to do is keep the project brief to one page in length. Why does it have to be just one page? You can’t give the reader any specifics about the plan in a one-page document, that’s why. You try to add any specifics and you end up over a page. Keeping the description to one page forces you to distill the project down to its essence.

And there is considerable precedent for a one-page document being the perfect length for a “just the overview, no details” document. When Eisenhower needed just enough information during the planning for D-day invasion, he restricted memos and briefs to one typed page. I suggest we follow his lead.

The “provide future project information without setting expectations” problem is also pretty simple to fix. Just add the phrase “this plan will change” to every single page of our project roadmap. With that little key phrase in place your roadmap doesn’t set expectations. Just the opposite, it tells folks that the plan will change. And remind them every time you update it that the roadmap will change. In a few months they will be telling you to stop reminding them.

We haven’t taken all the risk out of circulating your roadmap, but there are so many benefits to communicating the plan that you have to do it.

The first big benefit is a vision of where your website is headed for folks in your org that have a big problems that needs fixing. When they see that help is on the way, via a project on the roadmap, they will get a sense of hope regardless of how far away the fix is scheduled. Others will see that bright shiny future you have envisioned, or at least that you are all on the right path.

Your team also gets benefits. There is nothing better than being able to plan where the technology, design and content of the website are headed. And that little bit of planning comes when one of your folks looks at the roadmap. Plus if your roadmap is compelling, (and we know that it will be), folks can see past their day-to-day doldrums and think about how good things will be when this plan is finished.

You get benefit too. Using the roadmap to communicate issues that need to be addressed before a project can start is big new tool in your toolbox. Say for instance, you are doing a redesign project and the consensus is to use an agency for the work. But which agency should do the work hasn’t been picked so work on the project can’t start. Updating the roadmap with this dependency in big red letters, and announce the roadmap update in an email titled “redesign project will start late” should get some heat on this issue. Getting folks attention on urgent issue that needs to be solved prior to project start is a natural use for the project roadmap.

Ok. So it’s clear that we want a website project roadmap because there are benefits to all involved. Now let’s talk about how to create a roadmap.

How to Create 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 roll out.
Let’s talk roll out.

Website Project Roadmap Organizational Roll out

After you get your website project roadmap done your next step is getting it out there in your organization. These activities will help make that happen successfully:

Preview your first roadmap – Folks all over your organization might be shocked when they see the first roadmap. Maybe their project isn’t on there. Maybe their project is different than what they want. Maybe They don’t quite understand what the roadmap is. Whatever the case, it’s worth your time to preview the first version as a “work in progress” to your team, your boss, and project sponsors. This is best done in person.

Update it or it dies – Your project roadmap will change frequently: after releasing a project, substantial change of project dates or as projects are added and deleted. And if you don’t update the roadmap when the plan changes, it will be constantly out of date and folks will start to ignore it. Use the roadmap as a good excuse to communicate your bright shiny future whenever you get the chance.

Soften the blow personally – When a project sponsor or other significant person is adversely affected by a project roadmap change, it’s a good idea to talk to the person before you send out an updated project roadmap. Blindsiding someone with bad news using a public document like your roadmap is never a good thing.

Widely distribute the website project roadmap – Get the roadmap out some place so that folks can see it. I’d recommend your intranet site as a good place to store the most recent version of the roadmap.

Now after working through the why, how and org roll out of website project roadmap, don’t you think it’s time to put one together? It’s not hard to pull together, I’d say an afternoon or two, and the benefits are simply huge. Create a website project roadmap for your organization, roll it out and let me know how it goes.

Want to learn more about website project roadmaps? Check out the website project roadmap resources.

Website Project Roadmap Resources

Website Project Roadmap Technique

Creating a project roadmap for a set of projects or a program is a pretty common thing as a quick google search points out but there is almost no information about to make one. I find this interesting because ongoing set of projects, often called a program, almost always has a need for a roadmap as a lightweight planning and communication tool.

The closest project management technique like the one documented here this is Technology Roadmapping. Technology Roadmapping is a product management technique, which starts by identifying a set of business need then defines a set of projects to deliver the solution at a high level. Similar to the technique I have described but adds a large strategic planning element and a lot more rigor.

Website Project Roadmap Resources – Websites

There are very few resources on how to make a project roadmap. But technology roadmapping has some good ideas on how to mix in more strategy and rigor to the process that I have described.

Sopheon makes a software product which help with the process of technology roadmapping. And have a great article on the process.

Yeah, I know that wikipedia isn't the most reliable source of information, but the ideas in this article are pretty good.

Looking for a book about project roadmapping? Good luck with that. But when you get right down to it a project roadmap is a light weight form of portfolio managment. I like the book Manage Your Project Portfolio: Increase Your Capacity and Finish More Projects (Pragmatic Programmers) as a guide. Not great but good.