Avoiding Scope Creep
The Project Schedule
The project scope specifies what expected deliverable products will be produced by the project and thus details what the project includes and excludes, along with any constraints. Analyzing the steps necessary to produce the deliverable products defined in the project scope leads to the Work Breakdown Structure (WBS) and defining the relationships between the tasks and their durations leads to the formation of the project schedule.
The project schedule is a detailed breakdown of the WBS, which defines the relationships between tasks as well as the projected start dates and durations of those tasks. As a result, the project schedule predicts the completion date for the project
Forming a project schedule without the definitions provided by the project scope would be an impossible task. How could a project manager schedule tasks with no idea of what the products of those tasks would be or when those tasks should be completed?
Two types of buffer time should be added to a team’s project, lead time is added before certain tasks and scheduling the project finish before the project deadline provides lag time. Both of these time cushions add to the project buffer. Since the project deadline is an absolute constraint, How much buffer time is enough is a difficult variable to calculate when the actual times necessary to complete the various tasks are unknown.
Murphy’s Law, which states that if anything can go wrong -- it will, should not be an issue unless the Project Manager (PM) were off target forming assumptions. Parkinson’s Law, which states that work always grows to fill the available time, could be a factor but should not be an issue if the PM drives the milestone targets to completion on time.
Poor Planning and Scope Creep
As a Systems Engineer and Wide Area Network (WAN) analyst I have not been involved in any development projects. However, scope creep can also affect infrastructure projects when they are poorly planned or executed. The most extreme example of this from a project I was involved in was an implementation of Internet Protocol Telephony (IPT), which is a form of Voice over Internet Protocol (VoIP) that aims to replace an organization’s phone system with one that operates over an existing data network.
I became involved in the project after the design and planning stages were allegedly complete. Actually there was neither a design nor planning stage and the project proceeded in an ad hock manner. The system was meant to replace a local government agency’s Private Branch Exchange (PBX) with a new IPT system and required replacing some major infrastructure components including the core routers and switches.
Scope creep became a problem because the contract never specifically stated what our responsibilities were and what was the client’s. There was no scope statement so after the core switches were replaced, every infrastructure component that malfunctioned and every new protocol they wished to implement became part of the project. The intent was to implement a voice-communications system but we also implemented Dynamic Host Configuration Protocol (DHCP) throughout the organization and Virtual Private Network (VPN) connections between the main and remote offices. This type of activity continued until the money for the project ran out
Success or Not?
Although the phone system was successfully installed and placed into operation, nobody would claim that the project was a success because the project was never formally closed. To this day, the organization that I worked for performs support activities that are not billed because the customer finds new capabilities for the phone system and claims that the functionality should have been included in the original project scope. This could have all been alleviated through proper planning and the inclusion of a simple piece of paper: A formal scope statement, which is the most powerful tool to eliminate scope creep.