make your website all better

The Three Stooges. The Three Tenors. ZZ Top.

All of these trios are memorable and for good reason. Each member is an outstanding individual contributor. Each trio has found a unique synergy. And they have all created masterpieces in their respective fields.

And let me add one more memorable trio: Time boxing, MoSCoW prioritization and iterative development.

Although not people these three practices are just like other memorable trios. Is each member an outstanding individual contributor? Check. Unique synergy? Check. Create masterpieces? Check. Yep, Time boxing, MoSCoW prioritization and iterative development are a great trio too.

So, do other folks think these practices are a great trio? Well, creators of the DSDM agile project methodology think they belong together and call them “key principles.” And they are all individually recognized as sound practices as more of these practices are in every single agile project methodology.

So why bother with implementing all three of these practices? Couldn’t you do less and be ok? Yep, you could do less and implement just one of these practices and it is going to help improve your projects.

But when implemented as a trio these three magical processes are so powerful that they can literally transform how your projects work.

And Time boxing, MoSCoW prioritization and iterative development will do these major transformations for any content, design and functionality website project that comes along.

And what is even more amazing after some serious thought is that it’s clear to me that time boxing, MoSCoW prioritization and iterative development are a lot like The Three Stooges individually and as a trio. Wacky, huh?

Time boxing is a lot like Moe. Moe was the leader and set the tone for The Three Stooges, just as time boxing does for our agile trio. But, time boxing seems a bit smarter than Moe.

A bit smarter because the time boxing technique acknowledges that almost every web project arrives with fixed end dates and limited staffing flexibility. Instead of trying to fight for more time and resources, the fixed end date and limited staff are considered a “time box” that can’t be modified.

Then your job is to fill the time box with the most important features that will fit inside. This approach turns your typical project startup discussion from “I need more time and more people for this project” into “ok, I can accept the dates and not hiring anyone. But, we need to talk about limiting the features that can be delivered.” I find talking about which features to deliver instead of time and resources a refreshing change. And, I bet you will, too.

MoSCoW prioritization is a lot like Larry. Larry gets most of the slaps and without him the trio just doesn’t work. Just like Larry, without MoSCoW prioritization, iterative development and time boxing just don’t work either.

MoSCoW prioritization sorts the features in your project by business value and then groups them into four buckets: “Must have” features must be present and complete for the release to deliver any value at all. Your project should be considered a success if you can deliver all the “Must have” features.

“Should have” features are important but have a workaround if they don’t make it into the final release. “Could have” features are “nice to haves” but do help increase customer satisfaction. “Won’t have” features are considered deferred until a later project.

Although this prioritization isn’t anything magic, it gives you critical information needed to fill your time box and assure successful delivery of the “must have” features. Then it helps you maximize the use of any project time left to complete “Should have” features and finally, the “Could have” features.

There are lots of ways that Curly reminds me of iterative development. Curly was the breakout character of The Three Stooges; he was the guy that made them famous. Just like Curly, iterative development is the breakout practice of Agile project management. Still today, most folks think of iterative development when they think of agile project management.

And Curly made sure every scene was success for The Three Stooges by on screen improvision. Iterative development makes sure your project will be a success by making it more likely that all the “must have” features will get delivered and as many of the “Should have” and “Could have” features as you can fit in.

Iterative development makes projects better by slicing the time available for a release into a series of smaller time boxed projects called iterations. Then each iteration is scheduled to deliver as many features as possible, which are completely finished and ready for deployment.

Planning iterations completely relies on the MoSCoW feature prioritization. First, we want to schedule the “must have” features into iterations that occur early in the project. This substantially increases the chance of getting ALL the “Must have” features done.

Once the “Must have” features are scheduled into the early iterations we want to schedule the “Should have” and “Could have” features into later iterations. Because features are added in order of priority, as established during the MoSCoW prioritization, all of the iterations are filled with features the business folks really want. And they get really happy when you give them what they want, don’t they?

So there you have it, using our agile trio you have a whole new way to make your business folks happy. Time boxing, MoSCoW prioritization and iterative development are proven techniques that increase your chances of successful project delivery. And they work together to maximize the amount of value your project can deliver in a way that actually decreases the chances of project failure. Good stuff.

But how do we apply these practices? Let’s talk through each using an example project and get the details on Larry, Moe and Curly time boxing, MoSCoW and Iterative development.

Time box, MoSCoW prioritization and Iterative Development Resources

The DSDM consortium creates the Dynamic System Development Method. The new version of DSDM is called Atern. (login required). You can also access the older version of DSDM (version 4.2) using the same login.

Wikipedia has some good information on DSDM, time boxing, MoSCoW prioritization
and iterative development.

Because DSDM gives their methodology to folks that join the DSDM consortium (which seems a lot like selling it really) there isn’t a ton of books about it. The best I have found is DSDM Business Focused Development.

If you are up for something brief and about the latest version of DSDM, called Atern, the best book about DSDM isn’t really a book. It’s a little pocket guide. Easy to read and high level enough for anyone.

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 – Books

Good luck finding any books on this topic. I can’t find any books that cover it specifically or generally. Let me know if you can find any.

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.

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.

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.

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.

Website Project Selection Decision Matrix – Technique

The Project selection decision matrix technique described here is a project management best practice as defined by the project management institute (PMI). Except the PMI would call this a scoring model.

Website Project Selection Decision Matrix - Websites

American Society for Quality
This site has a pretty good description of using a decision matrix but be prepared to wade through some technical terms and general geekery.

Website Project Selection Decision Matrix - Books

Practical Project Initiation - Karl E. Wiegers
This book is among the best I have seen for down to earth practical project management techniques. And the section on project selection is excellent. This book is highly recommended.

Now that we have made our website project selection matrix, here are a couple of tips to rolling out your website project selection decision matrix into your organization a success:

Tailor your impact driver list – The example’s impact driver list isn’t the right impact list for your group, so you will want to tailor it. Some of types of impact drivers you might want to add are: financial performance (Internal rate of return, project payback), technical (complexity, reusability), resources (funding, staff, materials cost), strategic value (project strategic fit, strategic direction fit), risk (business, technical). I’d recommend at least 6 impact drivers but less than 12 with a good balance between technical and business drivers.

Set a minimum impact score – Make a minimum impact score that a project must score above to be implemented. This will weed out the projects that are simply not worth the money to implement and save a lot of needless discussion.

Set up a project selection group – Try to build a group of decision makers, not lackeys, from the business, marketing, and technical groups you do work for. Use this group to help guide the project selection process. I’d recommend meeting with this group at least quarterly.

Work through the decision matrix as a group – Working through the decision matrix as a group will help everyone understand each project’s issues and trade offs, and help draw consensus between the groups where it’s possible. Where consensus is not possible, I recommend that you, as the website honcho, break the tie.

Develop a high-level project roadmap - Project selection using this process is great but when can they generally expect these great projects to be complete? A high-level schedule of upcoming projects, also called a project roadmap, will help everyone understand when the good stuff is scheduled to appear.

It’s pretty easy to see how using a project selection decision matrix can really transform the way your organization thinks about projects. It may be so transformational that you could see the folks sponsoring projects think about the value of a new project before they propose them. Give the decision matrix process a try in your organization and let me know how it goes.

Interested in learning more about a decision matrix?

In this example, we will make decision matrix and then use it to evaluate the “press release redesign” and “support site requires maintenance contract” from the “Rationalize Your Project Selection Process” article.

1. Make an impact driver chart – First, we need to make a list of different project impact drivers we want to measure. Revenue gain, costs savings and strategic value are things that clearly drive any project’s impact. And there are tons of other benefits we could add. But to keep it simple just add website usability improvements and availability of funding for the project.

2. Assign ranges for each impact driver – To make scoring consistent and remove as much debate from how each impact driver should be scored as possible, give each impact driver a series of ranges for their possible values. Then we assign each range a score of 0, 1, 3 or 5.

3. Weight each impact driver - Each impact driver offers a different amount of benefit to a project - revenue increases of real money is a lot bigger indication of project impact than funding availability for instance - so we want to weigh each impact driver differently. Think of each impact driver weight as a percentage of the whole project impact; We want the total weight to equal 100%.

4. Make the decision matrix – Now that we have set up our impact driver chart, we need to make the decision matrix itself.

5. Score your projects – This is the fun part. “Press Releases Redesign” project has funding and improves usability but doesn’t add revenue, reduce costs or even have strategic value. But the “Support Site Requires Maintenance Contract ” project increases revenue, has some strategic value but is a little short on funding.
Our scores, as computed using the impact driver chart, go in the score column. The weighted score is the score times the weight from the impact driver chart. Then we total up the weighted scores to get the projects total impact score.

6. Bask in the brilliance of it – Now it’s clear that the “press release redesign” project doesn’t pack the impact of the “Support Site Requires Maintenance Contract” project. And our decision matrix will work for every project that comes our way. Nice.

But before you rush off and slam this process into your organization, it’s important to note that getting good organizational results can be tricky. Here are a few tips on organizational roll out for your website project roadmap.