I recently attended a project management seminar which served as a nice complement to my previous PM training — and frankly, it's been awhile since I have had the chance to sit down over a few non-lethal exercises and re-evaluate my own skills. Out of it I took many things, but what stuck with me most was the reminder of how important scope documents are when it comes to [web] project planning. Sometimes, when you're continually busy, you just do; and you lose sight of control processes that can make all the difference between a success and a failure. 

In my tenure I've come across just about every kind of web project; some easy, some fun, and some ... OK, far too many for my taste ... that were downright scary. The mystery and illusion of the web gets all sorts of businesspeople into hot water, because most of the time, they have no idea what they are buying or what they need to seek out in a web system, and they often don't consider what it is attached to. Many align one or more business problems with a features and benefits list and out comes the checkbook.

This is also why some many "experts" have been able to cash in on fads like the great SEO rage of 2002-2006. When a vendor squirms their way into the CEO's voicemail and leaves a message like ... "Did you know no one in Smallville can find your website and can't buy your products because it's not geo-tagging Smallville?" ... usually the response is rather reactive and elicits an emotive, "drop everything; we need to fix this," call-to-action. Because, after all, an "expert" is never someone that works for you. The next thing you know some clown in a suit is in dancing on the conference room table with the same hatched-up Powerpoint he used with his last sucker.  I always find it funny when they forget to change the client name in the Powerpoint.

So, back to the point ... having a clearly defined scope before committing to a project or setting a deliverable date.

My experience tells me that few people know where a website begins or ends because of the Frankenstein factor. There are so many web tools in the modern business world that, if you don't clarify exactly what you are working on, you end up working on everything that is not web. 

A few years ago I worked with a company that was using a simply terrible ERP system that could store few details about the company's products, yet they wanted a cutting-edge website that *had to* interface with their stone-age ERP. Garbage in, garbage out—right?  

A scope document doesn't even have to be a document at all; it can be a simple statement like: "XYZ Company will updated ABC Company's corporate web site [not the other ten websites they have, or link to] at www.abc.com by applying a look new and feel with updated graphics, CSS stylesheets and a revised contact form. This project includes 100 hours of billable time and sign-off is required for each specific milestone on the project plan. At the end of 100 hours, and per the project plan (which should include hours for everything) the project will terminate. If anything changes during the project, or after a milestone is marked completed, a separate change order will be necessary."

Web developers know that we build systems to solve business problems, we aren't able to produce missing data or data elements out of thin-air. If I had a dime for every time someone tried to pull the "Oh, I thought 'the new system' could import all of our data" [and mysteriously fabricate all of their missing data] card out, I'd be sitting on a beach in the Mexico. So, it's important to clarify that, no, the website will not read all of your printed collateral from PDFs, SEO-optimize it, and then triple your sales at the touch of a button. And often, businesspeople believe that just because a website is "new", that it must have better functionality; it may not. Often websites are replaced as they stand, if only to sure up aging technology. 

And I take the last comment back ... if I could deliver that system, I'd be sitting on a beach in the Mediterranean.