The Web is great: I can publish content whenever I want, and it’s instantly available to my audience all around the world.
The Web sucks: I can’t keep up with all the changes I have to make.
New Web publishers, especially those that are used to traditional print cycles, are sometimes stymied by the rolling publishing cycles the Web affords. Instead of a long production process, where all elements are tied to the same publish date (’cause they’re all on the press at the same time), the Web allows pieces to be published independently. Even after publishing, they can be shuffled, re-edited, deleted, etc. This is great; and it also sucks.
It’s great because the most time-critical items can be published fastest and begin generating value immediately. It’s great because the inevitable error-that-slips-through can be fixed. It’s great because user feedback can affect the product throughout the entire publishing cycle without blowing the budget.
It sucks because there’s no closure. Unless I’ve set up a publishing schedule, where I group everything together and publish all at once, I can be making minor tweaks ad infinitum. And as the maintenance iceberg grows, I’ll be surprised to find myself exclusively making updates and never free to evaluate and publish new content and services. And a big risk is that something goes out of date and I didn’t notice.
Relief is available, however. One can impose rigid grouping and publishing cycles, or deputize content owners to make the updates, or use a spider utility to crawl the site for expired content. But some strategy needs to be in place to maximize the greatness and reduce the suckage.