Book review of "Web Design On A Shoestring" (free)
Carrie Bickner's book "Web Design On A Shoestring" is being much talked-about as a good blueprint for techniques, technologies and processes to get maximum-quality web sites on a minimal budget. DMXzone staffer Bruce Lawson reviews the book, and as a bonus, you can read chapter two of the book "The Pound Wise Project Plan".
An Ounce of Prevention
If you plan well, your project has a better chance of staying on budget. Specifically, you need to address three steps formally and rigorously:
1. Define the goals of your site.
2. Define the functional requirements.
3. Define the technical requirements.
None of these steps needs to be overly involved, but you do have to take the time to write each definition in a document. These documents will help you and your budget stay on track.
Budget Threat:
Scope Creep
An unstoppable phenomenon is common to all web sites: scope creep. The development
of a web site is hard to pin down. New ideas surface, and needs change. The
scope of your project expands exponentially as new ideas and new "needs"
are added. Scope creep can be good or bad, depending on how you manage it. The
trick is to direct these shifts by making conscientious adjustments to the definition
of your site and by carefully adjusting the budget to fit the new needs. Clearly
defined project goals and carefully articulated functional and technical requirements
will help you stay sane and in the black as you begin to experience scope creep.
Shoestring Project Goals
Before you begin to work, sit down and take the time to write out what you are trying to achieve with your site. Let's work with a hypothetical example. The following is a freelance scenario, but the principles apply to any web-development circumstance.
Sample Site: Project Goals for the Something Blue Site
Imagine that an artist, Mary Hoy, has asked you to create a site based on her last exhibition, Something Blue. She can pay only a pittance. You like her work and figure that a pittance will help pay the bills, so you take her on as a client. Mary has never been involved in web site creation, so has no way of shaping the scope of the site. You correctly anticipate that her lack of experience might lead her to change her goals and requirements over time. When she sees what her work looks like on the web, she'll be inspired to try new ideas or to add functional requirements to the site. You have anticipated these problems. To protect yourself and the budget, you formalize the project's goals:
Project Goals for the Something Blue Web Site
Something Blue will be an online exhibition of the works of artist Mary Hoy. The site will include 15 of the 40 images in her bricks-and-mortar exhibition (also called Something Blue) that took place at the Good Girl Gallery in Studio City, California, in July 2003. In addition to the 15 images, the site will include 2 interviews with the artist, her resume, and her contact information. The purpose of the site is primarily to promote her work, to give Hoy an online "calling card," and perhaps to lead to a sale or two, although no selling will be done directly on the site.
This is a good example of a budget-sensitive project goal document because it is specific. First, you have established the genre of the site: This is an exhibition, not a retrospective or an e-commerce site. Second, you have quantified the scope of the project. The difference in the cost of producing 15 scans versus 40 scans might add up to quite a bit. You are probably going to be the one doing the scanning and the image editing. This will take time, and creating a schedule around a specific number of images will help you stay on track both for the schedule and the bottom line. The same is true for the interviews and the contact information; you can anticipate the number of web pages that you will have to build. As you put your budget together, you can attach a dollar amount to each major site element.
Budget Threat: Keep the Number of Decision Makers Small
As explained in Chapter 1, "The Secrets to a Successful Shoestring Project,"
one of the secrets to creating a successful shoestring web site is to keep the
number of decision makers small. The more people you involve in the goal-setting
phase, the more diffuse your project goals might be. Good resource allocation
requires a carefully defined project. If a large group of decision makers is
keeping you from nailing down the project goals early in the game, try to pare
the number of decision makers to a few key people. If you don't, you will spend
big bucks on unfocused work that goes nowhere.
The project goals document cannot save your budget or your sanity if it is not shared with the site's stakeholders. In the Something Blue scenario, the only decision maker is your client, Mary. Most sites, however, involve more stakeholders. You must communicate with all your stakeholders without turning them all into decision makers. The more levels of approval that are required to get the site moving, the more involved and expensive the process will be. More important, the more people are involved in a creative process, the more diffuse the focus can become. Distinguishing between stakeholders and decision makers is not a license to be cavalier; don't blow off the big wigs because, if you ignore them up front, they will be inclined to kill your project just before it launches. Talk about a waste of time and money! Make sure that your group of decision makers is small, but be politic in selecting the composition of that group.
Definition: Client
In this book, I use
the term client to refer to anyone who has engaged you for web production.
This could be a single client who has hired you to do freelance work, your
direct supervisor, or in-house colleagues who depend on you to develop the
company's site.
When you have formally established your group of decision makers, be sure to share the project goals document with the whole gang. It does not matter whether they are clients or colleagues. It does matter that you all agree on the goals of the site. If the goals change later, someone will have to pay for the extra time and materials; if you have formal sign-off from clients, colleagues, and bosses, you lessen your chances of getting stuck with the tab.
A formal document that nails down the initial scope places you in a much better position to ask for more resources when, for example, artist Mary Hoy decides that she wants 30, not 15, images of her work. You should never have to pay the price when someone else has a change of mind.
Nail Down the Functional Requirements Early
Establishing goals is the best way to keep control of a shoestring site, but you need to buttress that work with clearly defined functional requirements.
Let's return to Mary's Something Blue site again and create a functional requirements document. Again, this example assumes that you are a freelance web professional, but the same process can and should be applied by professionals working in any environment. You can start by interviewing your client about what she wants the site to do. The result of your interview will be a broad wish list that might include the following:
- I would like my visitors to be able to search the site for images and, when
they click on them, be able to zoom in and see each piece, down to the detail
of the paint strokes.
- My users need to be able to scan the images quickly and then pick the image
that they want to see in more detail.
- My mother has a slow dial-up connection to the web, and I want her to be
able to look at my site. I hate sites that take a long time to load.
- It must be easy for users to contact me; I want them to be able to call or send me an email if they want to buy a piece or show my art.
Clearly, not every item on such a wish list will make it onto a site with such a small budget. Your job as the web professional is to let the client know that you have heard all of her ideas and that you take them seriously, and to pare the wish list to a set of functional requirements that can be delivered on budget. You'll need to massage the wish list into a functional requirements document that can be accommodated by the resources at hand.
The result of this message should look something like this:
Bickner, WEB DESIGN ON A SHOESTRING, ISBN: 0-7357-1328-6,
Reproduced by permission on Pearson Education, Inc. Publishing as New Riders
Publishing.
ALL RIGHTS RESERVED
Ian Blackham
Following a degree in Chemistry and a doctorate in Scanning Tunneling Microscopy, Ian spent several years wrestling with acronyms in industrial R&D (SEM with a side order of EDS, AFM and TEM augmented with a topping of XPS and SIMS and yet more SEM and TEM).
Feeling that he needed a career with more terminology but less high voltages, Ian became a technical/commissioning editor with Wrox Press working on books as diverse as Beg VB Application Development and Professional Java Security. After Wrox's dissolution and a few short term assignments Ian became content manager at DMXzone.
Ian is a refugee from the industrial Black Country having slipped across the border to live in Birmingham. In his spare time he helps out with the website of a local history society, tries to makes sure he does what his wife Kate says, and worries that the little 'un Noah is already more grown up than he is.
Comments
Be the first to write a comment
You must me logged in to write a comment.