CHANGE ISN'T ALWAYS GOOD As used in software engineering, scope refers to the set of features or functionalities that are required to be present in the finished product. Items are either in scope or out of scope. It is usually the job of the project manager to work with the client, handling change control to the FRD. For example, if you were developing software for an automated teller machine, it would probably be in scope for the machine to be capable of giving the correct amount of money on a withdrawal (at least, one hopes that it would be in scope ). However, the client might suddenly decide that the bank customer should be allowed to specify how the withdrawal should be paid out (in five $10 bills rather than two $20s and a $10, for example). Unless that had been mentioned up front during requirement gathering, it would probably be considered out of scope by the development team. At this point, the project manager would contact the client, indicate that the request was out of scope, and look for direction from the client. On a time and materials project, in which the client pays by the hour , the project manager would present an estimate for the cost of the new requirement. On a fixed-price contract, the client would need to increase the cost of the project, remove another requirement, or drop the request. It's common in large projects to see requirements bargaining, in which new requirements are traded for less important ones already in the FRD. When the client manages to sneak in new requirements because the FRD was vague or because he has the clout to push them through, developers complain about scope creep. |