make your website all better

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: A Handbook with Tools (Best Practices (Microsoft)) - 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?

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.

I thought that by 2011 every website would have content management figured out. One way of solving the content management system conundrum would have emerged and everyone would be doing it. But guess what? It’s still a free-for-all out there.

Some folks swear by home grown stuff. Others like open source solutions. And others have gone all out and purchased a big package to solve the problem.

And I guess that makes sense. There just isn’t one solution that works for every site and every organization. There is too much diversity in what folks want out of their content management system (CMS) and processes.

But even with the diversity of needs out there, I do think there is a sweet spot of “just enough” CMS. A place where you get enough CMS to get ease of use and efficiency but not so much that you kill creativity and agility. Check out the article “The CMS Sweet Spot” for the details.

Regardless where you end up with a content management system, there are a set of issues critical to figure out if you want to run a content rich website and keep from hiring a legion of web producers to keep the lights on. More specifically, I’d say that there are 6 issues you should get figured out to make CMS work well for your organization:

1. Didn’t We Just do Something Like That? When your group cranks out the same project over and over, then it isn’t a project - it’s content production. Separating the projects that tend to require more up front work and client interaction from the day-to-day “update this section, launch this product, post this press release, change this page” sort of stuff will save so much effort that it will amaze you.
2. Release a Release Checklist – Wouldn’t it be great if you could know when the project is ready to release instead of just guessing? It would be great if you could move the “it’s done” decision from gut-feel to science. And that is exactly what a release checklist will do. A release checklist for projects and content production items introduces a touch of science in what is typically an emotional call.
3. Find Your Site Design Guide – You probably have a site design guide. Somewhere. 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. And you could avoid a lot of work too.
4. It’s Supposed To Be Easy, Right? – I have never seen a website that wasn’t supposed to be easy to use. But few folks really get in there and test their content, information architecture or functionality to figure out if it is easy to use. There is so much value in just a little testing that once you start your team will be hooked on getting first hand feed back from real users.
5. If You Don’t Track Bugs They Will Squash You – It’s simple. If you don’t track bugs, they don’t get fixed. And lots of defects on your site will kill its effectiveness. Plus with tons of cheap hosted or onsite bug database options, there isn’t a reason not to have one. Most bug tracking software will even help you track issues, too.
6. 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. Not hard to do but critical to do.

Nothing on the list is rocket science but there are a lot of meaty issues to get figured out. The nice part is that whatever CMS you pick to get these issues worked out will first make things all that much easier to get your content management system straightened out. Give it a try and let me know how it goes.

Bursting into my office a co-worker started ranting, "This is completely [expletive deleted] irrational. Why, the [expletive deleted], are we redesigning the press release section, again, when we could make a ton of money making user access to the support site require a maintenance contract?"

I agreed. It was completely irrational. Why would we do a low impact project now and defer the high impact project until later? Wasn’t that completely backwards?

And this was part of a larger problem. Our project to-do list was filled with every project that anyone ever dreamed up. And it seemed like all the pet projects from the politically powerful were at the top of the list and the high impact project languished, undone at the bottom.

Even though we had gotten good at executing projects, our ability to select the right projects to execute sucked.

What we needed was a rational project selection process.

We needed a process that would rate the impact of each project so we could objectively compare them. We needed a process that would separate the high impact projects we should fast track for implementation from the lower impact projects we should defer. A process that would reject the very low value projects before they got on the project list. And this process should objective reducing the chance of folks talking low impact, pet projects on to the list as well.

Yeah, that’s it. Good-bye politics. Hello rational decision.

So if this situation sounds at all familiar, you are wondering, “what’s the fix? I have this problem too”. We implemented a decision matrix process. And after some work implementing in our organization, it actually worked. Rationality broke out all over our project selection process. It was great.

A decision matrix works by turning the total benefit of a project into a numeric score. But instead of launching into bunch of techno-babble describing how it works, it’s going to be easier to understand if we just walk through an example.

How to Make a Website Project 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.

Website Project Selection Decision Matrix Organization Roll Out

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?

Website Project Selection Decision Matrix Resources

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 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: A Handbook with Tools (Best Practices (Microsoft)) - 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.

It’s mid August, and suddenly there is a new website project. Get supertoybox.com live November 15 for the critical Christmas retail season.

At least they know what they want the site do. Supertoybox.com is a full featured e-commerce site with tons of features. So many features that it will take your team until the Christmas after next to get them all done.

And the kicker - you can only use internal, available staff… no additional resources, not even temps. That leaves you with a design team and development team of 5.

Ok. After a bit of chatting, it’s clear that there is no changing the project end date or the amount of folks that can get the work done. But there is something good. They do have a site design worked out and agreed upon.

They want to know if you can get it all done. Good question. So your next task is to estimate the proposed work. Here is what you came up with:

Um. That’s a lot of work. How much work? If each member of your team of 5 is very productive and cranks out 140 hours of dev time per month that’s a bit over 9 1/2 months worth of work. And there is just about zero chance of 5 folks delivering 6640 hours of work during a 3 month project.

But the good news is that each feature estimates include design, testing (usability, unit and system) and even customer approval – everything that needs to be done to get the feature ready to deploy. So everything we need to do to deliver the feature is in the estimate. Still, all that work isn’t going to fit into that little box.

That’s a serious situation. What is your plan to fix our little dilemma?

Lots of folks would just suck it up and say ok and proceed to work a lot to try in vain to get this project done… We have all tried this approach. Worked too hard for too long on projects with little chance of success. And it’s no fun and often turns out badly. Missed dates. Bad quality. Lots of bugs.

But there is a strategy that works great in this sort of situation…time box the project. So you ask, how does one “time box the project’?

To time box a project you simply:

• Assign a non-changeable project start and end date,
• Fix the project staff at a particular level,
• Then implement as many features as possible knowing that some features aren’t going to make it in.

Ok. So, let’s apply time boxing to your supertoybox.com project and see how it works.

We already have a non-changeable end date of 11/15 and we are going to plan on starting 8/15. That gives us about 13 weeks of development time. That’s the length of our box.


And our staffing level is already fixed; we have 5 developers. Each developer is highly productive (85% of time spent at the office getting project work done) So lets figure they are going to spend 34 hours a working on this project. At that pace we will be cranking out about 170 hours (34 hours per week * 5 developers) of development work per week. That’s the height of our box.


Now it’s easy to figure out how much work we can get done. It’s the volume of our box, 2210 hours. (170 hours times * 13 weeks).


Now, if we can only complete 2210 hours of work before 11/15 then all we have to do is to get the project sponsors to figure out which 2210 hours of features they would like us to implement.

Then, you can just start on the other features after Christmas.

Sounds like a good way to solve this problem, huh? I think so.

And it gets better. The supertoybox.com project already has fixed end date and fixed resources… But if you time box ALL your projects - the content, the functionality and even the design ones, it’s really hard to sign up for more work than can be done. And, if you don’t sign up for more that can be done, the chances you will deliver successfully are higher.

But there is one problem we haven’t solved yet… How in the world are you going to get the project sponsor to cut the big list of features down to 2210 hours so that it fits in our time box? We are going to use MoSCoW prioritization, that’s how.

Website Project Time Boxing Resources

DSDM is one of the sources for the time boxing technique. But only has a passing mention of it in their e-book.

Agile advice has an interesting article on time boxing about episodes of Saturday Night Live.

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