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

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.