Team-Sourced Scope Creep
We all know about the dangers of scope creep--it’s one of those cardinal sins of project management. We’re all good project managers, so we strive to strike it down at every turn, pushing back on stakeholders, aggressively applying the change-request process and preserving the integrity of the agreed-upon scope--except when it comes to our own team.
Come on, admit it…we’ve all done it. Your lead developer comes to you and says that the new functionality can’t be implemented without a change to the existing database structure that was never documented in the original functional specifications or design. You work through the issue with the developer and agree that the change has to be made. Do you then go back and create a change request and submit it to the formal process? Probably not.
The rules apply to you, too
The pushback I get from project managers is that this isn’t really scope creep--it’s something that has to be done in order to deliver the rest of the required functionality, and no one is going to argue with that. I agree it does have to be done, but that doesn’t mean it’s not scope creep. A change in the regulatory requirements that a company operates in may drive a change that absolutely has to be included, but it still has to go through the change-control process.
Scope management is
Please log in or sign up below to read the rest of the article.