Keeping the Creep Out of Your Scope

Web projects are deceivingly complex, and notoriously susceptible to "scope creep". For those of you who have been lucky enough to remain unacquainted with scope creep, here's how it's defined in Web ReDesign 2.0: "The slow, inevitable swelling of a project's scope from something defined to something significantly bigger, scope creep happens with almost every project". This dismal evaluation concedes that scope creep is an unavoidable threat to every web project, but it can be minimized with good planning.

All too often a project's requirements are not clearly defined before the designers and developers dive into their work, and this is the primary cause of scope creep. Planning for web projects is especially tricky because it's nearly impossible to predict every single requirement before actually starting to build a web site. With this in mind, you should consider separating the process of requirements gathering into the following stages:

1. Determine the Business Requirements – Define the main objective of the web project (ie: the site must allow users to make purchases online and integrate the transactions with an internal accounting system).
2. Assess the User Requirements – Develop use cases that map out the steps a user must take in order to achieve the business requirements of the site (ie: users should be guided through the process of choosing one or more products, adding them to a shopping cart, and supplying the information needed to complete the transaction). Consider every possible scenario, such as what should happen if a user decides to backtrack at any point during the process.
3. Determine the Functional Requirements – At this stage, it’s time to consider the technologies that will be employed in order to meet the business and user requirements of the project. This includes addressing issues such as: which client and/or server technologies should be used, or if a database is required, how should it be built. Functional requirements gathering also includes identifying the actual web pages that must be built, and what task each page will be required to perform. At this time it’s a good idea to start developing mockups of the user interface and high-level prototypes. This will help to identify any user and business requirements that may have been overlooked. If you unearth anything that could lead to major scope creep, then it’s time to revisit the business and user requirements with these new considerations in mind. In a worst-case scenario you might discover that the project is not feasible, but at least you’ve realized this during the planning stage, and not halfway through the development.
4. Define the Quality of Service Requirements – Once the business and user requirements have been refined, and the functional requirements have been set, you'll want to be sure that the final product will perform at an acceptable level. It would be a disaster to complete a complex web application, only to find that it cripples your network, or that the database can't keep up with the number of concurrent users at any given time.

Thorough requirements gathering can be a lot of work, but it’s worthwhile to put the effort into planning a project so that all players involved understand their roles and the expectations of the project from the beginning. Without this understanding, you're just asking for scope creep.