- A New Perspective on Scope
- Classic Scope Control
- Managing Scope Change
- Common Scope Headaches
- Summary
Classic Scope Control
Standard software development models are requirements-driven: They assume that the project team will be delivering a final product with characteristics that can be clearly defined up front. These methodologies provide a disciplined, sequential process for defining the schedule, budget, resources, risks, and scope. For the sake of simplicity, let's assume a representative process with four stages: Define, Implement, Control, and End (DICE). The hypothetical "DICE" approach has a few distinguishing characteristics.
Define. All project requirements should be captured in the Define stage. The output of the Define stage is the project plan. The approved plan includes the scope, budget, and schedule. Project work is broken down into a hierarchy of phases, activities, and tasks. The plan serves as a contract between the project manager and the project sponsor. The purpose of this contract is to commit the project team to the terms of the plan. The plan should capture as much detail as possible, and it must be complete before implementation begins.
Implement. Once the schedule of deliverables has been set, Implementation begins. During Implementation, the project manager assembles and deploys the resources (people, hardware, and software) that are needed to deliver what was agreed on during the Define stage.
Control. During the Control stage, the project manager monitors and reviews the project team's progress against the schedule of deliverables. The project manager also resists the introduction of changes into the plan.
End. At the End, the product is released. Project success is measured by comparing the final results to the original set of requirements. If the project team delivered against the original specifiations on time and within budget, the project is deemed a success. Project failure is usually attributed to scope changes on the part of the client or inaccurate effort estimates up front. This analysis is used to make more accurate effort estimates in the future.
Figure 5.1 illustrates this generic software development process. This diagram is a simplified representation of the "classic" approach, which has been adapted to the Web.
Figure 5.1 DICE Software Development Lifecycle
Classic software development processes were designed to hit a fixed target. Unfortunately, the Web presents a moving target, as business models and implementation technologies are reinvented at an exhausting pace. In spite of this mismatch, the majority of current best practices in use by Web project managers today are inherited from this classic model.
The Standard
It is difficult to identify a "canon" of software development methodology, but a few heavy hitters set the bar for industry standards:
Guide to the Project Management Body of Knowledge (PMBOK®), 2000 Edition. Newtown Square, PA: Project Management Institute, 2000.
McConnell, Steve. Software Project Survival Guide: How to Be Sure Your First Important Project Isn't Your Last. Redmond, WA: Microsoft Press, 1997.
Rational Unified Process®: The RUP is a Web-enabled set of software engineering best practices. RUP is used today by many organizations that develop e-business applications. See http://www.rational.com.
The Project Web SiteGetting Everyone on the Same (Home) Page
Document and version control is essential to scope management. If your team can't easily access the latest project documentation, they cannot know the scope of your project. Once your requirements documentation has been created, it needs a home. Important documents should be easily accessible to all members of the project team. As the scope of the project evolves, "Who has the latest version?" becomes a very popular question! A project Web site should contain links to all of the latest project documentation, upcoming milestones, and the date of the most recent updates. As the project manager, you should maintain the project Web site, which will solidify your role as the "chief librarian" for all project documentation. Here are a few tips.
Use a file-naming convention that includes author, version, and date.
Only one person should be responsible for maintaining the most recent copy of a document and uploading it to the site. (That means you!)
Do not be lazy by simply overwriting older files with new ones. Be disciplined about keeping backup copies of older versions.
Provide links to an archive of previous versions as well as the most recent version.
Project Web Sites Made Easy
Maintaining and updating the content on your project Web site can turn you into an HTML slave. Avoid the headache by using Web logs. "Blogs" are free, easy-to-use, customizable publishing tools that can be placed directly on your own Web server or used as a third-party service (http://www.blogger.com).
Several service providers offer customizable project extranets at low cost or even free of charge! Two of them are:
eProject Express (http://www.eproject.com)
Intranets.com (http://www.intranets.com)
Provide multiple file formats for project team members who do not have Visio, MS Project, or other software. For example, export Visio diagrams as .GIF files. Export MS Project documents in Excel. Specify the file format and file size alongside the hyperlink.
Upload meeting notes and status reports in addition to the usual project documentation.
Include a project team roster with contact information (including instant messenger handles), titles, and a brief description of each person's roles and responsibilities on the team.
Use a Web log system like Blogger (www.blogger.com) to make the job of updating content on the site easier.
Include links to the various rounds of graphic design mockups, prototypes, and demos in addition to technical documentation.