Suppose that you' re working on a new system that has as one of its components some software that uses a proprietary networking protocol—let' s call it Virtual Packet Encapsulization (VPE) just for fun. When you were going through the entire design phase of the project, you had no clue that this VPE thing was out there. The IT folks didn 't say anything about it— didn 't , as it turns out, know anything about it until they started getting into the system. Now the router folks have paid you a visit. In order to support the VPE protocol, they need to buy some software for the routers that will use VPE. The software isn' t cheap—its $1,195 per router, and there are three routers to be concerned about!
On top of that, the IT folks had been having some mysterious problems with the system, problems they weren' t able to solve but were chewing up time trying to solve. It turns out that the solution is in the addition of this router software. Because the VPE packets weren' t being passed by the routers, the system your IT folks are developing wasn 't working correctly. By buying the router software, you' l l solve a problem, but you ' l l incur additional costs you hadn t counted on.
Team members can contribute to scope creep as well, especially if they ' re accessible to customers. Customers who know the team members and are comfortable with visiting them from time to time will think nothing of dropping by and suggesting a "minor change" to the system. Team members, not really thinking about things like scope creep, often won' t have a problem with making an adjustment or two. It s great that team members are customer-oriented, but that adjustment or two might well occupy two hours ' time and, when bundled with other minor adjustments, could potentially represent a large chunk of the project' s schedule. It' s very important to educate team members about the effects of scope creep and then advise them to refer any change requests your way.
Note Keep in mind the politics of scope creep. You tell your team members that they are to refer change requests your way. You turn down the change request. The customer, now frustrated with your team member and with you, goes straight to their boss, who happens to be the project sponsor. The sponsor doesn' t understand why a simple little change such as this can' t be made without any impact on the project and without having to go through the rigors of the whole burdensome change-management thing. There ' s no good answer for this, apart from your continued rhetoric that scope creep is a dangerous thing—if you allow just this one change for the customer, then you ' re forced to allow other changes and, like water dripping on a cave floor, eventually you have a stalagmite that occupies a healthy amount of the project s scope. This argument may or may not register with the sponsor, so be ready for any kind of response.
Was this article helpful?