Over the past few weeks I have been talking with some old co-workers about our experiences with our old clients. One of the things we talked about was how rare it was that project managers really examine closely the real impacts of cutting scope. By this I mean that they often feel that, for example, if they cut a set of tasks from their project that is estimated to take 30 days that this means they actually cut 30 days from their project. While this might be true for things like a construction project it does not always work out for things like software development projects.
At first thought it sure sounds good though. You have a feature that when you add it all up will take 10 or 20 days to develop. You cut it from the project in an effort to shorten your project and you feel pretty good. (Well as good as you can ever feel after you cut a feature you obviously at some point really liked!) Then you feel pretty flush and you figure you can now shorten your QA time in the schedule because you now have fewer features to test! This is getting better and better. Right? Well maybe not.
The thing that I have noticed people forgetting is that sometimes it takes time to NOT finish a feature. How is the feature or code you are pulling from the product linked or related to other features in the product? Do other features or parts of the application depend on code you plan on pulling or not finishing? Will it require you to rewrite other code to deal with the cut you want to make? Was the application designed in a way that will make this hard or easy? If you decide that you do need to make changes to other code to compensate for this cut has that code already been tested? Will you need to retest code because of this cut?
You see what I’m getting at here. It could end up costing you more time to cut the feature than cutting it would save you! Isn’t software fun?