Fortunately, there are a number of strategies you can follow to keep scope creep from derailing your projects. We’ll outline these strategies in a moment. First, however, here’s a short cautionary tale that illustrates how badly things can go awry without proper planning and control.
Horror story
While working at a consulting firm, I witnessed the scope struggles of our sister company during an in-house development effort to deliver a Web-centric desktop environment to users. This project, which began in earnest about five years ago, followed no project plan and had only a lead developer to guide its progress. It was started with a handful of talented Java developers who had only the vision of their non-technical president to guide them.
If this sounds like a nightmare, it was—and still is. Today, this company has one nonpaying client and a product that was surpassed by competitors two years ago. While it continues to limp along, the company itself has become unable to pay its employees, is seen as a bottomless money pit by investors, and is still considered by its management to be a start-up. With no formal project agreement to work from, the scope of this project changed constantly, even daily, and all efforts, from development to sales and quality assurance, became stunted by the massive workload a changing vision created.
On the bright side
The effects of scope creep are not always negative, depending on your situation. If you work as a consultant or for a consulting firm, “feature-itis" can be great for business—as long as it’s handled professionally. For in-house software development, additional features could give your product the edge over your competition. But, that edge is lost if you release a month or two late. Regardless of the perceived effects of scope creep, cost is the bottom line. By controlling your cost of development and by delivering on time, your project can be a success, without compromising flexibility in production.
Scope control starts on day one
Controlling the scope of your project begins before the first line of code is written. Every development effort should have a corresponding project plan or project agreement, regardless of the situation. Even if you’re just one developer trying to make the boss happy, you’ll benefit greatly from documenting your efforts before you begin them. Use the following guidelines to set yourself up to successfully control the scope of your project:
Be sure you thoroughly understand the project vision. Meet with the project drivers and deliver an overview of the project as a whole for their review and comments.
- Understand your priorities and the priorities of the project drivers. Make an ordered list for your review throughout the project duration. Items should include budget, deadline, feature delivery, customer satisfaction, and employee satisfaction. You’ll use this list to justify your scheduling decisions once the project has commenced.
- Define your deliverables and have them approved by the project drivers. Deliverables should be general descriptions of functionality to be completed during the project.
- Break the approved deliverables into actual work requirements. The requirements should be as detailed as necessary and can be completed using a simple spreadsheet. The larger your project, the more detail you should include. If your project spans more than a month or two, don’t forget to include time for software upgrades during development and always include time for ample documentation.
- Break the project down into major and minor milestones and complete a generous project schedule to be approved by the project drivers. Minor milestones should not span more than a month. Whatever your method for determining task duration, leave room for error. When working with an unknown staff, I generally schedule 140 to 160 percent of the duration as expected to be delivered. If your schedule is tight, reevaluate your deliverables. Coming in under budget and ahead of schedule leaves room for additional enhancements.
- Once a schedule has been created, assign resources and determine your critical path using a PERT Chart or Work Breakdown Structure. Microsoft Project will create this for you. Your critical path will change over the course of your project, so it’s important to evaluate it before development begins. Follow this map to determine which deliverables must be completed on time. In very large projects, I try not to define my phase specifics too early, but even a general plan will give you the backbone you need for successful delivery.
- Expect that there will be scope creep. Implement Change Order forms early and educate the project drivers on your processes. A Change Order form will allow you to perform a cost-benefit analysis before scheduling (yes, I said scheduling) changes requested by the project drivers.
If you can perform all of these steps immediately, great. However, even if you start with just a few, any that you’re able to implement will bring you that much closer to avoiding and controlling scope creep. That way, you are in a better position to control your project, instead of your project controlling you.