Project Management 101: Understanding Web Project Management

At Blue Lab, we've successfully launched, maintained and turned-around hundreds of websites from eCommerce to informational. Since the mid 1990's, we have watched web technology grow and change --and we've learned a lot about what's commonly referred to as, "best practices" for web-development project management.

In the early days, I studied the project management body of knowledge (PMBOK) - and later the Rational Unified Process (RUP), where iterative development was born into and/or out of software development -and later web software development. All this was to unhinge designers and engineers from the classic waterfall approach resulting in bringing a product to market (online) as soon as possible (once a pre-determined minimum feature set was integrated).

Excellent Project Management is built upon two documents:

The industry standard software for creating a Project Plan is Microsoft Project. However, I also have experience using a secondary tool, Alexsys Team 2 - particularly for task management.

The Feature Specification Document is primarily authored by the project manager with contributions from the project's engineers, developers and designers. The beginnings of the document almost always begin with a project's business requirements and long-term goals. The Feature Specification Document is known as a "living document," which means that as a project progresses through the basic stages of development (requirements, team building, scheduling, development, integration, QA and launch), the document grows as in a journalistic fashion.

In lay-terms, the Feature Specification Document is the blue print from which engineers, developers and designers build the system. I should mention here that the Feature Specification Document is also the road map for building the data model and database (where applicable).

The Feature Specification Document is what future development teams and/or the webmaster will use as a reference.

The three most common reasons (or excuses) for not creating documentation are:

When a project is not documented, the end result invariable looks sloppy - and in the long run, development is done twice. There's a saying, "if you buy cheap, you'll have to buy twice."