It' s important to be able to differentiate when a change request is valid from when it represents an element of scope creep. Scope creep doesn ' t usually consist of a single change request. Instead, scope creep happens when several changes, though inconsequential in and of themselves, added together represent a significant increase in the project' s scope—whether the increase impacts the project budget or its schedule. This is why you need to be nit- picky about change requests, making sure that they are really necessary within the context of a project and then getting approval to go forward: because they have cumulative effects.
Note Scope creep doesn't usually occur as the result of one single change request, but it can if the change is large enough to have a major impact on the project.
You should also remember that the time when you wrote the requirements document was the time to think about all of the things that might be required of the system, so that you could include all of those elements in the scope document. Change requests shouldn' t consist of things that are obvious, that you should' ve caught at requirements formulation time. It ' s a mistake on your part if this happens. Change requests that come to you should be surprises and will likely consist of one of two different types: Nice-to-haves Dor example, a customer approaches you to tell you that she' s been looking at some of the screens that are being developed. She says she ' d sure like to have a button placed on one of the screens that does some function—a function way out of scope and not even talked about at requirements formulation time—but one that ' s doable nonetheless.
Need-to-haves Some change requests absolutely must be satisfied regardless of the impact on the project's scope. You cannot provide the project's deliverables otherwise. For example, a database vendor who's working with you on the implementation of your project might request a specific software component that you had not planned on purchasing—that you weren't, in fact, aware that you needed at requirements formulation time.
Here's the problem: Often customers who are turned down when they request a change to the project will go straight to the sponsor and complain that you're not being responsive to their needs. They view the entire project process as customer-driven (and it is—but the customer gets involved at the front of the project, not during the project, except at testing time), so you aren't being customer-service-oriented when you turn down their change requests. Lots of times the customer happens to be an employee of the sponsor (as a PM, you probably won't be), and if the manager's any kind of manager at all, he's sensitive to his employees' frustrations and tends to agree with your customer's point of view. The next thing you know, you're implementing the change even though you don't think it should be introduced in the project! So the whole thing pivots on politics and really has nothing to do with scope impact or all of the other PM stuff we've talked about up to now.
There are two ways you can manage scope creep: proactively and reactively. Proactively, you can avoid a lot of the politics by communicating up front, right at the beginning of the project, that your goal is to formulate solid requirements from which you won't want to deviate. You can spend the extra time with the customer to define the screens (on paper, if need be) and the processes they' d like to see, then use your IT specialists to translate to the actual IT system the project will produce. Be clear that you ' re looking for all the elements of the system (or at least as many as the customer can think of) ahead of time, and that there' l l be little to no tolerance for changes once the project' s underway. This sounds rigorous, but you ' re faced with the quandary of allowing for scope creep and yet bringing the project in on time and on budget if you don't set down some operating rules.
The reactive method is to simply plan in a scope-creep fudge factor and then deal with each change as it comes forward. The problem with this is that the project' s budget and schedule will be far over reality, and if managers have worked with other projects, they' re going to think you ' re not very good at what you do (never mind that they' re the same ones who will doubtless approve the many change requests that you think represent scope creep).
In either case, the best tool you can use is your communication ability. Sponsors, stakeholders, and customers need to be clearly told when a change request is a nice-to-have, wasn' t negotiated at requirements formulation time and, if implemented, represents scope creep at its finest. You should not mince words (though always being ever-so-diplomatic) when it comes to calling scope creep what it is. A nice way of putting a change request denial is to say, "This change request is something that will fit nicely in a revision of our project ' s deliverable—unfortunately, changes like this have to take place in another project at a later date."
Pealing with third-party interference may represent some different challenges. Change requests that are made by third parties could potentially be much more difficult to turn down because they don' t fall in the nice-to- have category; they ' re generally need-to-haves. It just turns out that you didn't anticipate the request as you were formulating the requirements.
Was this article helpful?