RossOlson.com

Where to start: Steps for Getting a Web Project Planned

Flabbergasted and Flumoxed?

Kickstarting a web site can be an adventure in itself. It's not always easy to get things off the ground. If you're building websites for commerce or clients, you'll soon be experiencing the joys of planning a web site. Here's some steps you won't want to forget.

The idea of a project plan is to get the whole web site planned out ahead of time. Before all the mistakes are committed to code. Check out these 13 steps to getting your site planned.

1) Write the Project's Summary Statement

A Summary Statement is a two line sentence that brings the reason for a site down to it's base reason for existence. I generally follow the 'elevator pitch' method that was described eloquently here.

This Summary Statement is very useful for communicating to the other people we work with, our clients, our boss, our boss's boss, and even our parents. But most of all it gives us, a core concept to keep in mind when developing the rest of the plan for this site.

2) Survey Available Assets and List Them

An asset is anything that might go on a web site. This includes Contents as well as Functions. Articles, Images, Catalogs, Shopping Carts, PDF Brochures and manuals, Videos, Message Boards, Newsletters, Press Releases, administrative tools. All of these pieces are chunks that can be put into a site.

What we want to do here is find out what's within reach. We get all of the assets into one room, and get them all in as close to the original versions as possible.

3) Brainstorm Additional Assets

What can be built, designed, shot, programmed, or constructed that would be great for this site? This is a great time to bring in others. Even VPs can get into a brainstorming session and look like they're actually doing something of worth. Throughout the session we keep in mind the Summary Statement by writing it at the top of the white board.

4) Filter Out Assets REVC

REVC is the mnemonic device I use to filter the good ideas from the poor ones. Revenue, Efficiency, Value, Cost are aspects of each asset that are usually taken into consideration when developing any web project. Other may have additional criteria, but these will cover 80% of the projects out there.

Revenue: The DotBust world has left us with the harsh reality of revenue. If you're working on a site that has to make some money each asset should be looked at from the point of revenue. How much money can we charge for this? Per-use basis? Monthly subscription? Collected Micropayments? Over the course of a year? a month? Give each assets a simple rating of 1 to 5 stars based on how much money it probably will make.

Efficiency: This is often the 'hidden' benefit of web sites and many projects. In most situations, if we can show that our site will cut Customer Service time in half (and we've got a CSR staff of 200) we can save upwards of $50 a month in wages! If you're switching customers from free printed newsletters to free electronic newsletters, chances are your costs will drop. Give that PDF manuals section a 4 big stars, but only give that flame-baiting moderated message board 1 star.

Value: What we're looking at here is the value of a particular asset to the visitor of the site. A good value rating *can* help an asset pull it's own weight on a site. Got award winning articles, but aren't brash enough to actually charge for content? Then they must have high value. High value assets can help a site develop an audience. Many sites are trying to make a buck by offering lots of tasty mashed potatoes, but get the money by selling the gravy. It's working for some, but not all.

Rate the asset's value with an outside opinion. Sometime this is called 'market research', sometimes it's called asking Jerry at the front desk what he thinks of the idea. If we've got actual footage of Ghandi meeting Elvis, the asset gets five stars. If it's a collection of 'Under Construction' GIFs, no stars. If it's animated Under Construction GIFs, we take a previous star away.

Cost: This will be an estimate for assets that need to be developed, but for assets that can be bought or licensed it can be easy. Keeping in mind that time is money, take into account the length of time it will take to develop and get that asset ready to go for the site. The more things cost, the more stars we take away from the stars we've already given it.

The Star Bar: Figure out what your minimum number of stars will be for the assets to be included, and ignore the rest. Notice that I said ignore, not remove. These other ideas may very well be easier to do, have more value or cost less at a later point in time. Save these ideas for 'Version 2' or for the competing web site that you will build to seek revenge on your former slavemasters. Bwhahahahahaaaa... erm, sorry about that.

5) Organize Assets Into "Appropriate" Groups

Appropriate groups means getting these assets into piles that make sense to new users. Remember when Amazon's inventory was just 'Books'? Then it was Books, Movies and Music. Three simple tabs soon expanded into row upon row of green tabs filling our browser with layer upon layer of product classifications. Every site expands and has additional content come later, but it's important to think ahead and think from our audience's point of view. Group the ideas into a handful of concepts. I really recommend staying between 4 and 10.

How these groups emerge will help determine how people will navigate the site. This is the step that a trained information architect should be brought in. You know all the stuff you want to have in a site, now you've got to get it organized. On smaller sites, you can do it yourself. On larger sites it may be a bit more difficult.

6) Label the Groups

Read Chapter 5 of 'Information Architecture for the World Wide Web' by Rosenfeld and Morville. Do it now. Already read it? Read it again.

Now let's review. Labels need to be chosen carefully. They should represent the depth of the content that their category covers, and establish the distinctions between contents of differing categories. The labels should be comfortable for the user, not dictated by the developers' database that they used for a previous client. ("But we've already built the whole shopping cart for the camera store. We'll just make this stamp shop use the same code!") Finally, the labels should cover the full extent of the information that is on the site, covering all the subject matter that visitors might want.

7) List Each Page With Its Primary Assets

Now comes the real work. Get a sheet of paper that represents each page of the site. On each page list the primary assets that will be on that page. Have a page for each step through any web application. This includes error pages for each step of any application.

This is called PLANNING! We are planning to put each of these elements on our web site. We can step through each page and see what steps haven't been thought out. We can get into the details of each page and it's necessities without investing time in design or development. We can find stuff like additional fields that need to be added to databases and membership profiles. We can quickly go back and add those fields to our database schema and our registration system.

Don't forget the administration tools. In most sites that we've worked on, if the site needs administration tools, these can easily take up 50% of the pages that we end up building.

All of this is done BEFORE a single pixel drips onto a Photoshop canvas or one function is called via Perl, JSP or Visual Basic. Whole sections of a site can be renamed with a flick of the wrist, steps in an application can be shuffled and reshuffled with a minimum of effort.

Once these pages are typed up and organized, the document is called the Site Content Outline.

8) Create a Site Map

This is subjective. If the site is small enough, I won't bother with this step since I don't need to explain the content outline to myself. But if there is a need to communicate the site's structure quickly to someone else, a site map can provide a quick and easy visual communication tool. Most people use Visio, ConceptDraw or Illustrator/Freehand/CorelDraw.

9) Estimate Time/Cost of Each Page

Suddenly the task of estimating the hours for a project becomes a matter of adding up simple elements on multiple pages. That membership system doesn't take 10 hours like your Cold Fusion guy said, it take 150 hours because of all the back-end reports that need to be generated and all the admin tools required to maintain the databases.

Add a little tally to the bottom of each page: (3 hours / $150) or (2 minutes / $30). When we're done, we add it all up. That's not just an estimate, that's a damn good quoted price.

10) Correlate with Initial Estimate

How close did the tally come to the original estimate? Are the resources overextended, or did we end up with enough to fund the wrapup party at the swank bar just across the street?

If we're over our budget, we go back raise the minimum star level. We DO NOT simply remove pages from stack we just created. We take out whole assets, not pages from the middle of an asset. And for sake of TBL, don't remove the error pages.

11) Inventory Each Element of Each Page

Now we can add in the rest of the secondary elements that will be on a page: The Navigation bars, the Ad banners, the search boxes. The pages will say stuff like 'Site Masthead'. We write 'Site Masthead' fifty, a hundred, maybe even five hundred times. (Of course you might consider using an Outlining tool like Acta, but it's your choice.)

The Detailed Content Outline communicates to Designers exactly what elements need to be created, and lets Developers know exactly how each application will flow. Include the developers and designers in the brainstorming sessions They get pretty angry if they don't feel like they've had a chance to express their own views of the project before they handed a laundry list to complete.

12) Identify Pre-production Issues

All of this provides us with a list of questions that need to be answered and decided upon before producing the site. Has the hosting service provider been chosen? What platform will the site be on? Has the corporate re-branding effort finished and will that affect the design for the site?

13) Establish Timeframes/Schedules

Now we know the facts and we know the questions. We know how fast each of our designers and developers work, how their time is scheduled in the coming weeks and months. We double all the estimates and call it good.

---

Our plan is made and we know what we're building. We take all the information that we've developed so far and compile it into a project plan or maybe a bid. This kind of planning is hard work, but it pales in comparison to to the hours wasted reworking projects that weren't thought out ahead of time.