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 Use a Decision Matrix for Website Project Selection

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
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.

And more email rolls in. One looks interesting. Your co-worker, who is the internal customer for all your Internet marketing efforts, has sent you an email with the title “my campaign in broken.” All the email says is “Can you fix my latest marketing campaign? It’s not working very well”

“What sort of a task is that?” you ask yourself. There isn’t an objective to it. At least not that you can measure. Who knows if you can realistically fix it. And there isn’t a “I need this by” date either. Yep. It’s just another blob-ulous task.

It is clear that you need to turn the current blob-ulous task your customer handed you into something that you can execute on. You don’t really want a task. You want to know what result they want to obtain, what product they want produced or what service they want performed – you want an objective. So how do we go from the blob-ulous task we have now to a well-formed objective?

The answer is SMART. No, not “smart” as in “intelligent”. SMART as in the SMART technique of defining objectives developed by Peter Drucker over 50 years ago. Using this long-standing technique assures your objectives are specific, measurable, attainable, relevant and time based so that you can execute against them. And at the end of your efforts it will be very, very clear if you completed the objective or you didn’t. It’s a perfect technique to use for any objective you set out to achieve – be it a result, product or service.

The SMART technique is so powerful that once you start “thinking SMART” you end up more effective. You don’t get bogus tasks assigned because you spot them when they try to slide them in. All tasks that are turned into objectives using the SMART technique, assuming you apply the method correctly, are good ones.

And applying the technique is simple. Just get your task and make sure it is specific, measurable, attainable, relevant and time-based. Once you SMART-ify the task, it isn’t a task any more. It’s an objective. Let’s review each element of the SMART technique in detail so you can master this powerful technique.

Specific – All objectives should use exacting language. They should not be vague. In our example above, “fix” is vague and so is the phrase, “not working well.” Something like “the copy on the ‘10% off followup’ campaign trafficked out 8.8.2008 is incorrect” would be more effective. Bottom line: If everyone involved can understand the objective then it’s specific enough.

Measurable – Not all objectives have to be measurable using a number. Commonly, an objective has been done or it hasn’t. Like “paint the outside of the fence with white paint” – either you have it done or you haven’t. But if objective contains words like “good” or “small” or “best” then it isn’t measurable and it should be. Making an objective measurable means that you need to use numbers instead of adjectives. As an example, there is almost no measurability in the objective “decrease customer calls to a low level” but “decrease customer calls into the call center by 10%” is very measurable.

Attainable – We have all seen objectives that were completely impossible. To make sure an objective is possible and attainable find out if others have done something like it. And also make sure that the team meeting the objective has proper resources and the project manager has authority to address the objective. Asking everyone involved “is this objective attainable?” goes along way towards making sure it is.

Relevant – For an objective to be relevant it has to be both urgent and important. It has to be next logical thing to do based on the issues, challenges and opportunities in your work environment. If your objective isn’t urgent and important, then it’s very hard to make a case for doing it.

Time based – All objectives should be time based. And most objectives are. But sometimes an objective doesn’t explicitly say when it needs to be done. Just include a due date in the objective and this one is all buttoned up.

So it’s pretty easy to see how the SMART technique can help you end up with good objectives. Just make sure all of your objectives are specific, measurable, attainable, relevant, and time based and you end up turning blob-ulous tasks into well-formed objectives. In other words, apply the SMART technique and you end up smarter. As in more intelligent. Give it a try and let me know how it goes.

Drucker’s SMART Resources

An article tying the SMART objective process with it’s intended use – Management by objective (MBO)

Good overview of SMART on 12manage.com

I really like the Wikipedia overview of SMART – especially the part about all the different words can work in the SMART acronym.

All websites are supposed to be easy to use. They have to be. If your website isn’t, then your visitors will bail and find a website that is. But how in the world do you sure your website has ease of use?

My answer came after a good bit of trial and error is to use Joint Application Design workshops for website design. Then follow that up with some simple usability testing.

But most websites groups don’t really do too much to improve the designs of their websites. Heck, most folks don’t even use usability testing on websites to see if they are easy to use or not. And I can see why. When I worked on ACT! at Symantec we did a lot of usability testing and I have to admit it didn’t work that well.

Our usability testing went something like this: We would work really hard to get the application features complete and get rid of the bugs that made the usability testing impossible. Then we would hunker down in our high dollar usability lab and pump 15 to 20 people through the testing process over about 2 weeks. We would then pull some test ‘results’ together.

There were two big of problem with this approach. We didn’t have a great idea of what to test before hand so we ended up with a big glob of anecdotal comments about the app – not actionable “this is wrong” sort of feedback. And the feedback came so late in the project we couldn’t really act on the results – we had to wait and integrate that test results into the NEXT release.

To make usability testing really work for us we needed usability feedback before we even got the application complete so we had time to fix the problem. And the feedback needed to be formatted into a “fix this problem” sort of statements. It would have been good if the testing could be a little less intense and time consuming as well.

These experiences led me to a big dilemma when I saw the really bad user interfaces coming out of the first few website projects I managed. It was clear that “Big Usability Testing” – big as in big test lab, big group of folks being testing, big glob of results at the end – just wasn’t going to work on websites either. Yet something had to be done to improve the usability of the websites we were making.

Without a lot of great ideas of how to improve usability on websites, I adapted a couple of application development ideas to website development: Joint Application Design (JAD) workshops to improve a website usability design and beta testing to test the website design’s effectiveness.

I ran across the JAD technique when I was doing client server development for a bit right after I left Symantec. JAD is an “interactive systems design concept involving discussion groups in a workshop setting” normally used as a requirements gathering exercise using a cross section of technical and business participants.

I saw it really work well for requirements gathering and some light application design. So it seemed to make sense to apply the workshop setting and cross-functional participants to the entire user interface design process as well.

The JAD workshop applied to website design worked something like this:

• Create a list of the features that the website needs to do
• Get 5-8 folks with differing backgrounds and viewpoints into a conference room
• Conduct a workshop to create a wire frame website on a white board.
• Turn the white board wire frame into HTML with some text added for things you can’t explain in the wire frame.

I tried using the JAD technique for the website design of a pretty simple site with a consulting client. After reviewing the HTML wire frame from the results of our JAD workshop with client management, we did a follow-up JAD workshop to address the issues they brought up.

Once we had the final wire frame assembled, low and behold, we had created a much more usable website design than any one person could have done individually.

For usability testing, we adapted “Beta testing” like I had seen done at Symantec on ACT! to website development. It was really easy to implement beta testing – once the website was stable enough to use without crashing we posted a version of the website out for review by some external partners.

The good news is that we got some feedback from folks outside the project. But the feedback we got wasn’t focused. It was at the “tweak this and tweak that” level and not the in-depth feedback we needed. The results were still too late in the development process to act upon without holding up the website release.

After the first experiment of how to improve website usability, I found that the JAD workshops really, really improved website usability. But beta testing didn’t give us any better feedback than Big Usability Testing even though it was a lot easier to pull off.

Fast-forward several years. I found great results using UI JAD workshops to design websites in a variety of settings – consulting and for internal customers. But still no improvement on testing the UI that was developed during the process.

Then I got to reading this really great book, Don’t Make Me Think by Steve Krug. Krug describes a really stripped down version of Big Usability Testing that was specially tailored for websites. The process it described took almost all of the practices of Big Usability Testing, simplified them and moved testing earlier into the development process.

Krug doesn’t really name this stripped down website usability testing, so for lack of a better term, let’s call it “simple usability testing.” Here is a summary practices of Big Usability Testing, the thorny issues they cause and a set of simplified practice Krug recommends instead.

This sort of process made so much sense that I had to try it out. Using a little project that I was working on, I did some simple usability testing after the design was done and guess what? Worked great. I had a couple of those usability testing magic moments where things I had never thought about came to light. It was brilliant.

So to boil that all down, I have had great results iteratively doing Joint application design to improve the initial UI design usability and then applying “simple usability testing” from Krug’s “Don’t make me think” book to assure that the design is good. It’s not particularly difficult to do and the results are really good. Let’s walk through the steps of how to do these two processes together.

Steps to improve your website’s usability

1. Assemble a set of features – Before you start designing anything you really need a list of features that the website is going to implement. Without a well-defined list of features your design team just isn’t going to know what to design.
2. Pick a cross-functional design group – To get a really good design you need the right folks to get in there and make the design workshop happen. Ideally, you would have at least two business non-technical folks, a web producer/HTML person, a senior developer, and the project manager. You want a good cross section of viewpoints and interests in your design workshops. And the folks you select should be flexible and easy to work with.
3. Set up the JAD workshop – Get a conference room with a lot of whiteboards, reserve it for the whole day and get cracking. If this is the first time through the process it may make sense to show up with a first draft wire frame to kick things off. Ideally the person that will be “approving” the UI design should be participating. If folks can’t stay for the whole time, don’t include them. Don’t allow cell phone/crackberries/laptops.
4. Conduct the JAD workshop – Spend a couple of hours to an entire day creating or revising a wire frame on a white board. Hopefully you can moderate this yourself. All participants should have an equal say in the design. Look for consensus in the design but don’t force it. It’s not critical to get down to one design but it will be great if that happens. But do make sure that your website design guidelines will allow what you are designing… it makes no sense to make a design that can’t be implemented on your website.
5. Develop a wire frame – Using the notes and white board drawing get your web producer to create a wire frame UI in HTML. In cases where it is not clear what should happen on a page then add some text descriptions or call outs. For instance, if there should be some AJAX functionality happening on a page don’t get bogged down in developing it now. Describe what the functionality should do in a note on the page someplace.
6. Iterate – Do steps 3 to 5 again to improve your design at least once. At a minimum you should have at least 2 JAD workshops with the same set of people.
7. Make a usability test script – Before you can start testing you need to make a script that will walk the user through each specific task you want to evaluate. You don’t have to start from scratch on this – Steve Krug’s website has a really good great starter script. http://www.sensible.com/Downloads/script.doc
8. Find a testing location and equipment – All you need to test is a conference room or, heaven forbid, a quiet cube someplace. You will want to videotape each testing session so bring your video camera and tripod from home.
9. Conduct the testing – Line up 3 – 8 people to test. Bring them in. Walk them through the script. Make sure and pay them $50-100 in cash as they leave. It’s great if they are in your exact website demographic target but it’s not as critical as you might think.
10. Review results – While reviewing the testing make two lists: one for general issues that came up during the sessions and one for problems specific to the new things you are testing. Prioritize the issues to fix and possible solutions if they pop up. In an ideal world, the same design group you used during your JAD workshop would review the testing videos.
11. Redesign as needed – Do another JAD workshop to address the issues brought up in usability testing. Look to solve the high priority problems specific to the new functionality you are developing and any of the general problems that can be fixed. It’s convenient but often challenging to review the results and redesign based on the results in the same session.
12. Redevelop – Now get in there and rework the wire frame based on the JAD workshop results.
13. Iterate – Do steps 7 to 12 again so that your team will do at least two rounds of usability test and redesign.
14. Start development – Once you start usability testing, I would try to start involving more application folks in the design process or at least giving them access to the wire frames as they come out. The idea is to jump-start the lower level business logic and database design processes using the wire frame to stimulate the discussion.

I’d try to use 2 JAD workshops and 2 rounds of usability testing, like I have document in the process now, for large chunks of functionality or content. The entire process could take as little two weeks if folks can be dedicated or mostly dedicated and could take a month and a half if folks are not dedicated. It will probably take at least a month the first time through.

For smaller project cut the number of JAD workshops and usability testing iterations down from there as you see fit.

Summing up – Get Great Website Usability Using Joint Application Design and Simple Usability Testing

Using a Joint Application Design workshop for your website’s user interface and the using simply usability testing as outlined in Krug’s excellent book “Don’t make me think” is really going to improve your site’s usability. And without a huge change to the development process you have in place now. If you really want to get it all together then try combining this approach to website usability with time boxing, MoSCoW prioritization and iterative development. Give it a try and let me know how it works.

Joint Application Design Resources

Great summary of the problems JAD looks to solve and how.

Great summary of the wireframe process.

Usability Testing Resources

The man himself, Steve Krug, has a great site on website usability.

The best resource on website usability has got to be Jakob Nielson’s website.

If there was ever a clear way to achieve success on a website project, it is iterative development. Not just success but success with a decreased risk of project failure and increased quality. It doesn’t get any better than that.

Iterative development makes projects successful by slicing the time available for a project into a series of smaller time-boxed projects called iterations. Then each iteration is scheduled to deliver as many features as possible that are 100% complete and ready for deployment.

The approach of simplifying a project into iterations is a great idea. And, there are lots of other compelling ideas baked into iterative development. For instance:

• Focus on short term, achievable goals – Big projects can be overwhelming for all those involved. They are just like big elephants; trying to eat the big elephant in one bite isn’t going to be pleasant. But cutting the project into small bite sized chunks helps keep your team focused on small, short term, and achievable goals.
• Get good at finishing – Getting a chunk of work all buttoned up and complete is hard. It’s a skill that every team needs but few really perfect. By completing two or more iterations per project which have to deliver completed functionality, your team will get really good at finishing because they practice doing it so much.
• Reduce risk by doing the important stuff first – One of the first things you learn as a project manager is to schedule the high risk and important features early in the project. Why? Because if something important gets screwed up early in the project, then you have time to improvise and recover. But if things get screwed up late in the project then it’s pretty unlikely you are going to finish on time. Iterative development enables you to schedule the important stuff first and get it completely done early in the project, which substantially reduces project risk.

Together these ideas blend together into something really nice. How do you apply it? Let’s revisit our supertoybox.com example we have been working on for a while…

Supertoybox.com is an e-commerce website project we have time boxed to begin 15-Aug and end on 15-Nov. That gives about 13 weeks to work with. We have 5 dedicated resources and after a bit of math that figures out to be a time box of 2210 hours.

The site has a page template designed already. We have developed a domain model and high-level design so we could get accurate feature time estimates. Each feature estimate includes design, development, testing (usability, unit, system) and deployment. This will make our iteration planning much easier.

We have also done a MoSCoW prioritization to establish the priority and importance of each feature. Our task at hand is to plan the iterative development efforts for the project.

How to Plan Iterative Website Development Using MoSCoW Prioritization and Time Boxing

1. Establish length of Iterations
Our first big decision is how long we want to make our iterations. Any project needs to have at least 2 iterations and we want our iterations between 2 and 6 weeks in length. We also want them to be as small as possible and each of them to be the same length. Seeing that we have about 13 weeks in our project, let’s try 6 two-week iterations, which would make each iteration about 340 hours long.

2. Schedule the “Must have” features
We want to schedule all the “Must have” features early in the project. This gives us two big advantages. First, if we deliver all the “Must have” features early our project is assured of success. (MoSCoW prioritization defines success as a project completion with all the “Must have” features complete) Second, if we screw something up and don’t deliver a “Must have” feature in its scheduled iteration we can try to get it done in a later iteration. We have time to recover if something goes wrong.
Scheduling the “Must have” features ends up with a pretty busy iteration 1, 2, 3, and 4:

If things are going well at the end of iteration 4 we will be done with all the “Must have” features and will be into working on “Should have” features. This would put us into a great situation where we are done delivering the important stuff and we will be down to making the website work better about 2/3 of the way through the project. Sweet.

3. Schedule the “Should have” and “Could have” features
Our goal is to schedule all the “should have” features then schedule as many “Could have” features as possible. It’s normal, even good, to have more features ready to be implemented than you have time. That way if there is more time available in an iteration at the end of the project, you can easily try to include more features.
But if you are running behind at the end of the project, then fewer features get done. The idea is that you are trying to get done as much as possible, but projects are dynamic and you won’t know exactly what will get done until you’re well into the project. So simply add the “Should have” features into iteration 5. Something like:

Then, stack the rest of the features into iteration 6 in order of importance. Something like:

Then sometime in iteration 4, meet with you team and try to figure out what you are going to attempt to get done in iteration 5 and 6. In other words, plan to improvise.

Iterative development really works well in this example. We get the important stuff done early and have time to recover if something goes wrong. We also have plenty of features to implement that will really improve the website if we have time at the end. And, if we have available time earlier in the project it’s possible we could even move features up to those iterations too – An ideal situation.

This is the last in the “Larry, Moe and Curly of Agile Web Projects” series where we quickly ran through using the time boxing, MoSCoW prioritization and iterative development techniques together. It has worked out really nicely. We have delivered as much as can be delivered in our time box. What gets delivered is exactly what the business wants and we have reduced our risks along the way. If you agree, then why not give it a try and let me know how it goes…

Iterative Website Development

The broad spectrum of iterative development are discussed in the article, “Going round and round and getting nowhere eXtremely fast? Another look at incremental and iterative development“.

The XP crowd’s view on the “History of Iterative Development”

How is iterative development different increment development? If you really want to understand anything agile or project management in depth then consult this Alistair Cockburn article, “Increment versus Iterative Development”

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 book about DSDM that 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.

First off, MoSCoW prioritization isn’t from Russia. And it’s not communist either. It’s an agile project management technique that is part of the DSDM agile project management methodology.

And one of those part acronym, part word, words. MoSCoW is short for “Must have, Should have, Could have, Won’t have”

Not only is MoSCoW a funny acronym, its best way to figure out which features should be included in a project. Its true value is found when combined with project time boxing. This makes sense because project time boxing and MoSCoW prioritization are designed to work together by our friends at the DSDM Consortium.

The underlying ideas behind MoSCoW prioritization are worth talking about before we launch into an example of it’s use. That way it will make a lot more sense when you go to implement MoSCoW prioritization yourself. Some of the ideas behind MoSCoW prioritization are:

• Less might be more – Have you heard the saying “80% of the solution comes from 20% of the functionality?” You and I both know this is true; there is a small number of features, often known as a minimum usable subset of features, that make a website work. The rest of the features are “nice to have.” MoSCoW embraces this idea by first figuring out what the minimum usable subset is and then classifying the rest of the features important but not critical.
• Workarounds are ok – It’s often painful to defer a feature until a later release. But is it a good idea to put a project at risk of non-delivery to implement a feature that could be worked around outside of the website? Nope. When using MoSCoW prioritization, features that are not part of the minimum usable subset can be worked around if they don’t make it in the final result of the project.
• Deliver value early – All project features are important. Everyone would agree they should be prioritized to deliver the greatest and most immediate business benefits early in the project. With this in mind, MoSCoW prioritization establishes the priority order in which to deliver project features instead of delivering what makes sense from a development perspective.
• Cutting features isn’t much fun – Getting anyone who wanted a particular feature in a website project to cut it completely out of a project is a tough sell. However, prioritizing a feature against the other features in the project to figure, which must, should, or could get delivered by the project is a lot easier. MoSCoW embraces this idea by having multiple levels of priority for features in a project not just “in the project” or “out of the project”

These approaches make so much sense to me. What’s also nice is how easy it is to figure out. The most basic part of MoSCoW prioritization is the categorization system. Each feature can be categorized “Must have”, “Should have”, “Could have”, or “Won’t have”.

Anything labeled as “Must have” has to be delivered in the project time box for the solution to be of use. In fact, lots of folks think the “Must” in “Must have” is an acronym “Minimum Usable SubseT” of features. “Minimum Usable Subset” of features is the minimum amount of functionality that will solve the business problem at hand. However, if all the “Must have” features are complete at the end of the project the project must be considered a success.

”Should have” feature are items are nearly as important as the “Must have” and should be included if it is at all possible. “Should have” items are often as important as “Must have” features but have workarounds allowing another way of satisfying the requirement.

”Could have” features are less critical than “should haves” and are “nice to have.” But, a few “Could have” features in the project can substantially increase customer satisfaction.

“Won’t have” features are either not critical or low return features. “Won’t have” features won’t be delivered in the current project and are deferred to the next project.

DSDM advises keeping “Must have” features hours fewer than 60% of the total project hours. And “Should have” and “Could have” features should be about 20% each of total project features. In higher risk scenarios, like a really tight timeline or a deliverable with numerous risk issues, I would try to keep “Must have” features down to less than 50% of the time box.

One thing that DSDM does not advise is to let the total project feature hours (the number of hours for features prioritized Must, Should and Could) exceed the total hours in the time box.

But experience tells me that having more project feature hours prioritized than time box hours is a good idea. In fact, I find it’s ok to add up to 50% more project feature hours than time box hours.

Why allow a project to have more project feature hours than the time box hours? Well, by their nature your estimates for each feature should be conservative. And what if things go better than expected and the project can deliver MORE than originally expected? If this happens, it’s good to have some features already queued up and ready to implement.

So the next question how do you do it?

How to Use MoSCoW Prioritization in an Agile Website Project

Let’s revisit our supertoybox.com e-commerce project we talked starting working through in the last article about time boxing.

So far, the supertoybox.com project has a large defined set of features we need to prioritize for the first site release on 11/5, just in time for the Christmas season. Here is our feature list:

Using some simple calculations, our timeframe of about 13 weeks and 5 resources cranking about 170 hours a week gives up a project time box of 2210 hours. Given that, our mission is to prioritize the list of features and end up with about 2210 hours of work that will yield a good first release of the supertoybox.com website.

1. Prioritize “Must have” features – On the first pass through the list I like identify the “Must have” features. At a minimum our site has to have a basic product catalog, search, and a shopping cart with tax and shipping calculations. We will also need to do credit card transactions, have some way of getting orders out of the system and a page framework to hang the functionality on. That’s pretty much the bare minimum. So our first pass looks like:

Using this initial prioritization, the “Must have” hours they are about 57% of total time box hours, which is about where we want to be.

2. Prioritize “Won’t have” features - Next, I like to see what I can easily defer out of the project to make it nearly the size of the time box. I try to look for large features than can be worked around and are not technically required to make the project work. For this project I would look to defer system integration and do manual order entry. We can also safely defer the reporting and statistics feature because we could likely get that information from our ERP system. Features like multiple address shipments, product category admin and the wish list can also safely be deferred. That puts us with a prioritization like:

After deferring these features, our project is down to an estimated 2240 hours, which is just about 1% larger than our time box. That’s good.

3. Prioritize the “Should have” features – “Should have” features complete functionality that are categorized “Must have.” I’d look at browse product by age, the CVV2 and paypal and shipping confirmation emails as very important but not critical features to include in this first release. Now our prioritization looks like:

4. Prioritize the “Could have” features – I like this step; all the rest of the features are “Could have” features by default. That puts us to a completed prioritization that looks like:

We get pretty lucky on this project because the “Won’t have” features are pretty easy to defer and the “Must”, “Should” and “Could” features are not much bigger than the 2210 time box:

At first glance, we have enough time to deliver the 1260 hours of “Must have” features in our time box of 2210 which ends up at 57% of the total time box hours. That’s good. The total project feature hours for this release is only 101% of the time box hours.

But, how do we make sure that we can deliver ALL the “Must have” features and pack in as many of the “Should have” and “Could have” features as possible? Let’s try out iterative development to see what that can do for us.

MoSCoW Prioritization Resources

DSDM has great resources on MoSCoW prioritization in Atern and MoSCoW prioritization in DSDM version 4.2.

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

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 has great resources on Time boxing in Atern and time boxing in DSDM version 4.2.

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

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

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.