WebsiteHoncho

Website Project Selection Decision Matrix Resources

2011-10-30T21:10:00.000+01:00

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.

Website Project Selection Decision Matrix Organization Roll Out

2011-10-30T21:09:00.003+01:00

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 Resources

2011-10-30T21:08:00.004+01:00

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

Website Project Roadmap Organizational Rollout

2011-10-30T21:07:00.003+01:00

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 Content Management Done Right

2011-10-30T21:06:00.003+01:00

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:

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

Use a Decision Matrix for Website Project Selection Series (Complete)

2011-10-30T21:05:00.000+01:00

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

Website Project Selection Decision Matrix Resources

Website Project Selection Decision Matrix – Technique

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

Time Box Your Website Projects

2011-10-30T21:04:00.000+01:00

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.

The Larry, Moe, and Curly of Agile Website Project Management

2011-10-30T21:03:00.000+01:00

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. If you are up for something brief and about Atern check out the e-book. Easy to read and high level enough for anyone.

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 aren’t a ton of books about it. The best I have found is DSDM: Business Focused Development, Second Edition.

The Content Management System Sweet Spot

2011-10-30T21:02:00.001+01:00

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

Rationalize Your Project Selection Process

2011-10-30T21:00:00.004+01:00

MoSCoW Prioritization Isn’t From Russia

2011-10-30T20:57:00.003+01:00

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 used to have some great resources on MoSCoW but no longer.

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

Iterative Development = Project Success

2011-10-30T20:57:00.000+01:00

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 aren’t a ton of books about it. The best I have found is DSDM: Business Focused Development, Second Edition.

The DSDM consortium creates the Dynamic System Development Method. The new version of DSDM is called Atern. If you are up for something brief and about Atern check out the e-book. Easy to read and high level enough for anyone.

How to Use a Decision Matrix for Website Project Selection

2011-10-30T20:56:00.000+01:00

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

How to Build a Website Project Roadmap

2011-10-30T20:54:00.003+01:00

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.

Get Great Website Usability Using Joint Application Design and Simple Usability Testing

2011-10-30T20:53:00.002+01:00

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, [amazonify]0321344758::text::::Don’t Make Me Think[/amazonify] 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.

Big Usability Testing	Big Usability Testing Problem	Simple Usability Testing Solution
Buy equipment and make a dedicated usability testing lab	$$$$ - a usability lab costs a lot of money	Find a conference room, bring your video camera from home
Hire a usability expert	$$$ - a usability staff costs buck few website can afford	You test, you analyze the results, you figure out the solution
Create a usability study	It takes a long time to make and digest	Make a list of problems found and prioritize them
Test functional software	Once software works it’s hard to change the UI	Test anything (wire frames, software, mockups) that will give the user an understanding of what you are doing
One round of usability testing	What if you didn’t fix the big problems you found in the first round of testing?	Do more than one round of testing
Test between 10 and 20 people	Testing a lot of folks takes a lot of time (and money)	Test between 3 and 8 people and be ok with that

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

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.
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.
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.
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.
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.
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.
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
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.
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.
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.
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.
Redevelop – Now get in there and rework the wire frame based on the JAD workshop results.
Iterate – Do steps 7 to 12 again so that your team will do at least two rounds of usability test and redesign.
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.

From a blob-ulous task to a SMART objective

2011-10-30T20:51:00.000+01:00

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.

Does Your Website Work?

2011-10-30T20:50:00.002+01:00

It’s not easy to look at the website you work on every day and tell if it is effective. You already know the content, navigation and all the features. And it’s not like just looking at the website is going to really tell you everything anyway.

What you really need are some tools and techniques that get you in touch with what your users are experiencing. You need answers to questions like:

Is my website up or down for my visitors?
Can visitors find what they are looking for and searching for?
Why are visitors coming to my website?

And now that we are talking about questions, how do you know how well your landing pages are working, how your offers are working or how full your online sales funnel is?

Simple, old-fashioned log file based website analytics isn’t going to answer all these questions. You need a comprehensive data collection and analysis process that gives you complete, actionable answers to the questions that are vital to making your website is working well.

There is good news though - getting these actionable answers has never been easier. Log file analysis, custom coded surveys, and huge expensive usability labs have given way to JavaScript based analysis tagging, easily deployed online surveys and usability labs using your video camera in a cubicle. With all these newer techniques available, it makes sense to revisiting how you get answers to your “does my website work?” questions. Almost every single question has a new, better way of getting it answered.

Is my website up and available for your users? How fast do my site pages load where my visitors are?

Internal site monitoring tools are useful for figuring out if your hardware and software are available for your visitors. But they have one significant limitation. They can’t tell if your website is available outside your network, out there on the great big Internet. Fortunately there are tons of hosted solutions that can be used to simulate visitor site access from around your country and around the world then alert you if problems crop up. Considering the price of these services are as low as $25 per month there isn’t a reason to not get a monitoring solution in place today.

Is my website easy to use?

Not long ago usability testing was the domain of big software companies. These companies had tons of money for a complete dedicated usability testing suite that often costs $100,000 or more. While usability test suites are expensive, the biggest problem with old style usability testing was that the software needed to be completely functional before testing could be done. The software had to be so complete that it was hard to get the usability testing feedback back into the development process and get the software out the door on time.

Somewhere along the way common sense took over and someone discovered that there was a ton of value doing informal testing early in the development cycle. Instead of big usability suite and tons of folks in the process, think small test groups and a home video camera with testing going on in a conference room or cubicle. Instead of complete functioning software, think HTML wire frame or screen markups. Small amounts of this type of informal usability testing will yield amazing insight into the usability of your site for a really low cost.

Can users find what they are searching for?

There are tons of visitors that come to your site and use your search function straight away. So if your search function isn’t working well, then you have big, big problems. Luckily there are two great ways of getting insight into if your visitors are finding what they are searching for: Search results analysis and an after-search survey feature.

Search results analysis helps you tune your website content so that searchers can find what they are looking for. Hopefully the search function on your site records what each and every visitor searches for – if not then it needs to. Once you get a hold of this data simply spend an hour a week looking through the searches visitors conduct and what your search feature returns. This will give you invaluable insight into the effectiveness of your search feature and the content tagging and key word richness of your page content. Use this insight to tune your content and your site search will get a lot better. The real bonus part of this activity is that you will help your SEO efforts with this search results analysis as well.

An after-search survey will give you insight into if your visitors are satisfied with the results of the searches they are conducting. The best implementation of this sort of survey is to add a small form to the bottom of your search results pages with the question “Did this search give you the information you needed?” with a yes/no and submit button. Getting good feedback using this simple piece of functionality gives you great actionable insight into your visitors thoughts on your site’s search effectiveness.

Why are users coming to the site? Are users satisfied with the website?

Sometimes the easiest way to get information you need from your visitors is to simply ask them. Sure, you could get a developer to code up a survey for you and figure out a good way to distribute it, but why bother? There are tons of great, hosted survey services offerings out there that require no developer time, no additional infrastructure and little to no setup cost. And you get great reports and can brand the surveys with your website look and feel. Using a survey service to get feedback directly from your users make sense on so many levels.

Are my landing pages successful? Are my offers successful?

Effectiveness of landing pages, offers and other forms has long been a challenging thing to measure - old style web log analytics solutions work but it’s not a pretty solution. Sure, your developers could make it work but your website would end up with fugly URLs, it’s difficult to scale if you traffic a ton of campaigns and it is far from web 2.0/ajax friendly.

But using JavaScript tagging solves most of these issues. Instead of analyzing web logs created by your webservers, JavaScript tagging uses an in-page script that is run when the page is loaded on the clients browser. When this browser script is run the clients’ browser communicates to a separate server to record the access. Using JavaScript tagging enables your website to keep its nice URLs and your developers can easily create a way of recording other information, like which campaign drew the person to the landing page, when the script is run. JavaScript tagging is a much cleaner, easier, accurate way of getting form conversion data about landing pages and offers.

What is the ROI for my online campaigns? How many online visitors, prospects and customers are visiting my website? Are the leads I am forwarding to sales good leads?

Sometimes you need big tools that are expensive to make and maintain to get good answers about your website. And this is one of those cases. To get critical end-to-end metrics like online campaign ROI, the effectiveness of the leads forward to sales and the like, you need tons of data. And that data isn’t available on your website. And even if it was in your website database, your transactional website DB is not setup to do in-depth data roll ups and reporting.

Let’s face it. The only place that campaign data, online visit information, sales data, and customer data come together is in a data warehouse. Hopefully the folks that run your CRM and ERP systems are already on the road to implementing this sort of thing and you can leverage those efforts. If not, then creating a marketing data warehouse is what you need to look into. There are a couple of vendors out there who sell “pre-built” marketing data warehouse products but don’t look for a complete solution without some heavy customization.

But after going through the implementation of a marketing data warehouse before, it’s worth it. Until you can give the business the answers they need to judge the end-to-end effectiveness of online marketing, they are just shooting in the dark. Even the most basic of end-to-end information has tremendous value. Expensive but well worth the investment.

There you have it - getting good actionable answers to your website questions has never been easier. And once you get them in place there is so much value that you will wonder how you got along before hand. Why not give these ideas a try and let me know how it goes?

Build a Website Project Roadmap

2011-10-30T20:48:00.001+01:00

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.

Build a Website Project Roadmap Series (Complete)

2011-10-30T20:47:00.001+01:00

How to Create a Website Project Roadmap

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

Website Project Roadmap Resources

Website Project Roadmap Technique

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.

Looking for a book about project roadmapping? Good luck with that. But when you get right down to it a project roadmap is a light weight form of portfolio managment. I like the book Manage Your Project Portfolio: Increase Your Capacity and Finish More Projects (Pragmatic Programmers) as a guide. Not great but good.

9 Things to Improve Your Next Project BEFORE It Starts

2011-10-30T20:45:00.001+01:00

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…

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

8 Steps to a More Effective Internet Marketing Program

2011-10-30T20:43:00.001+01:00

Internet Marketing is a beast. It’s complicated. There are tons of experts. Tons of blogs. Tons of hype. And tons of “answers”.

It gets worse. Your website probably has some tricky marketing stuff going on, too. It’s marketing a wide range of product from cheap to pricey. It’s marketing lots of these products, in many different product lines, for numerous internal customers. It’s supporting an e-commerce, direct and indirect sales channels.

Given all that, and the pressure that comes from the fast pace of websites work, it’s easy to see how website honchos might get a bit lost and overwhelmed. How do you get your arms around what you need to get done strategically with all this going on?

I feel your pain. In fact, once I ended up with even more tricky marketing stuff, or perhaps a better way to say it is, with a trickier internal customer. I ran the website and Internet marketing group for a marketing-intelligence, web analytics company which made everyone there a bit of know-it-all... because well, they did know it all. And I spent more time than I would like to admit behind the power curve before we managed to get our act together.

But we did get it together. From 20 campaigns a quarter to 170 campaigns per quarter. From 900 unqualified leads to 27,000 qualified leads per quarter. From no marketing database to a data warehouse of 600,000 names. In two years.

Getting to a place where Internet marketing worked for us wasn’t easy. It was all pretty new and we didn’t really know what would work and what won’t. However, figuring out what works will be easier for you. Because I am all about sharing what works. In fact, this entire website is all about sharing what works.

The first thing you need to do to get good at Internet marketing is to get your mind around a couple of good practices: make your website the centerpiece of your marketing efforts and treat email marketing and your website as a single integrated effort.

Make your website the centerpiece of your marketing efforts

Your website is the most cost effective, targeted, measurable way of marketing. If you drive folks to the site, it’s probably fairly cheap to get them there. You can target your exact market very specifically. Your website can triage their needs and point them at the right product and the right sales channel. Plus you have ways of tracking how they got to the site and if they ultimately buy. It’s like old-school direct mail all jacked up on steroids except cheaper.

But your website can only do its magic if it is the centerpiece of your marketing efforts. If you want your Internet marketing efforts to be successful, then your marketing has to focus on driving folks to the website – the end result of all of your marketing should be your website.

That means that all campaigns drive folks to the website. All advertising drives folks to the website. All email marketing drives folks to the website. Even brand building activities should drive folks to the website. The more you focus your efforts on driving folks to the website the more folks will get there and get into your sales pipeline to potentially buy.

Email marketing and your website must be integrated

There are still so many companies that still treat email marketing and website marketing as separate almost unrelated things. But really they don’t work well until they are completed integrated together.

Websites really need email marketing to keep the company/visitor conversation going when your visitors aren’t at the website. If you wait for your website users to come back by themselves you are likely to wait a long, long time. Why not have a conversation with them and get them back to the site ASAP?

Without a focused persuasive website email marketing isn’t going anywhere, either. The website has to provide a great landing spot for email campaigns and have great marketing materials to support those visitors if they start poking around on your site.

You have to have both a persuasive website and great email marketing to make Internet marketing really work. It’s as simple as that.

So now that you are on board with some good Internet marketing practices let’s talk about getting you started on building a more effective Internet Marketing program. It’s just 8 steps but each will really help focus you on what is important.

8 Steps to Improve your Internet Marketing Program

1. Model your funnel – In the off line sales world, savvy sales folks know all about their sales funnel. They know how many folks they need to talk to, present to, create a proposal for and ultimately close to meet their quota. But do you know how many new visitors you need to hit your sales goal? Or how many new names you need on your list? How many prospects do you need to get qualified and off to sales as leads? Or close via e-commerce? You need good answers to these questions or it’s like you are flying a supersonic jet in the mountains with your eyes closed. You need to start managing your website just like the off line sales pros do - with a sales funnel.

2. Attract and engage using deliverables – Because you are a sharp marketer it’s likely you can target and attract the right folks and get them visit your site. But most visitors are going to bail quick if you can’t convince them that your firm and its products are the right choice to fulfill their needs.

You could convince them by offering competitive prices or slugging it out with your competitors on a feature-by-feature comparison basis. And provided you have a good position, it’s likely you will get this sale. But you want more than that. You want these folks to keep coming back to the site to buy again and again. To get those repeat visitors and sales you need to implant your firm as the thought leader about the problem your visitors need to solve. That way your visitors will be very likely to return over the long haul to get more of the thought leader knowledge that only you can give them. And return to buy as well.

The best way to achieve thought leadership is to attract visitors by offering the prospect information (a deliverable) that positions your company as the experts about the products you sell and the problems they solve. By using these deliverables and mixing how your traffic your deliverable offers out (co-branded email, SEM or adwords, etc.) you are going to fill up your funnel with the right folks. And these folks are very likely to stay in your sales funnel until they buy.

3. Tune your content - When folks show up at your website they are at different spots in the buying process. Some are just learning that they have a problem while others are ready to buy today. If your content is only for buyers or for learners, then someone isn’t going to get what they need. To make sure they get the info they need, identify what types of content is needed for each stage in your buying process. Then make sure you have content that fits the need. It’s the only way to keep your visitors engaged and your funnel full.

4. Optimize your landing pages – Landing page optimization is a cottage industry these days. Rightfully so, considering landing pages have an enormous impact on the effectiveness of your online campaigns. The good news is that landing page optimization should not be a huge battle over creative issues. Getting the right metrics and analysis process in place is half the battle. Getting good at trafficking marketing campaigns and tuning your landing pages is the other half. The creative part of landing pages tends to take care of itself if you use the metrics from your landing pages to guide your actions.

5. Close the deal using offers – We see it all the time. 3 for the price of 1. Sale today only. Offers come at us left and right all day for one simple reason. They work. And if you want to get your prospects off their duff and have a reason to buy now, you need to get offers in front of these folks pronto. To make that happen, you need the capability of delivering an offer to a prospect via an email or on your website. Then use that capability as much as possible without annoying the folks you are trying to close. Without offers you are leaving money on the table.

6. Qualification, qualification, qualification – In the real estate business it’s all about location, location, location. With sales leads it’s all about qualification, qualification, qualification. If you aren’t collecting important qualification questions like time until purchase, opportunity size, and “which product do they need?” questions, then you are spamming your sales folks with leads. Leads that aren’t ready to work with a sales person yet or might not even need any product you sell. And not only are you spamming your sales folks, if you don’t properly qualify leads, you are annoying the hecky-darn out of the prospects in your pipeline too. Qualification is, without a doubt, the most important part of the sales lead process.

7. Does your website work? – To get the critical insight to your websites’ effectiveness, you need to answer to questions like:

Is my website up or down for site visitors?
Can users find what they are looking for/searching for?
Why are users coming to my website?

And now that we are talking about good questions, how do you know how well your landing pages are working, how well your offers are working or how full your sales funnel is? Simple, old-fashioned log file based website analytics isn’t going to answer all these questions. To answer these critical questions you need a comprehensive data collection and analysis process that gives you complete, actionable answers. Without these answers it’s pretty darn hard to end up with an effective website.

8. You can’t start a fire with a hammer – You need the right tools to start your online marketing fire. And a hammer, or in this case a couple of HTML pages, just isn’t going to cut it. That’s why your website better have a robust SQL database back end. Your email setup needs to support email list management and sending out tons of email. Campaign management including an automated way of creating customized landing pages is key to trafficking your outbound activities. Oh, and while you are at it you need a robust analytics and reporting capability tied into your marketing data warehouse, which includes sales, customer and contact data. Not small things but important tools if you want to get Internet marketing working in a way that is effective and measurable.

So now you have the basics you need to improve your Internet marketing program. Make your website the centerpiece of your marketing efforts. Get your website and email marketing efforts working together. Then get these 8 steps underway. Not simple stuff but these are the steps that I seen make Internet marketing really work. Why not give it a try and let me know how it goes?