Posts from — March 2008

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. I reviewed it on March 30, 2008.

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.

Improving a project after it starts is hard. You have already started down a path; expectations have been set and you’re committed.

But what if you started the project from a better place… a place where all your projects had less to do because the approach, techniques and guidelines were figured out, quality was assured, and the arguing stopped because you all shared the same vision.

If you could go to that place… it’s like every project would be set up for success before it even started. So how do you get to this place? Each step takes you a little closer to the Promised Land…

1. Rationalize Your Project Selection Process – If there isn’t process to figure which project is next, well, which project is next? Lead a group of business folks and use a simple spreadsheet tool to rationalize this normally irrational process.
2. Build a Website Project Roadmap – A high-level project schedule with enough detail to tell folks what is happening and when, is an amazingly powerful thing. The best use of an afternoon ever.
3. Adopt a Time Boxed Project Strategy – If projects aren’t released regularly, heads will roll. But what if you delivered a project full of business value every couple of weeks, guaranteed? Try time boxing your projects to keep your head attached forever.
4. Get Agile – Lightweight agile project methodologies are a natural fit with websites projects. Adopting an agile project methodology for your functional, design and content releases makes your team and website… um, more agile.
5. Bugs – Track ‘em to Squash ‘em – It’s simple. If you don’t track bugs, they don’t get fixed. With tons of cheap hosted or onsite bug database options, there isn’t a reason not to have one.
6. Revisit your Site Design Guide – You probably have a site design guide. Somewhere. And if it was up to date, maybe you could avoid that “I want my project to work completely different than the rest of the site” conversation again.
7. Get on Board with the Branding Guidelines – I never get to own the brand. And every time I start wanting to change some brand treatment or anything having to do with the brand, I get slapped down. So instead of trying to do something cool with the brand, go with what the brand owner wants and live to argue about something you can actually change.
8. Release a Release Checklist – Wouldn’t it be great if you could know when the project is ready to release instead of just guessing? Move the “it’s done” decision from gut-feel to science using a release checklist.
9. Perfect Your Release Process – Getting content and functionality from the website group live on to the site reliably is a must. If your team can’t do it perfectly every time, then getting it perfected should be next on your to do list.

Now close your eyes and imagine that you had these things done. Do you think you would be in a better place… where it’s pretty darn near all good? I thought so. Now go make it happen.