Effective project management: Controlling scope creep

We had a great Product Manager for our software project. The lady knew all her stuff, had a great rapport with the product support team and a direct contact with some of the larger customers for whom we did projects for. The design team liked how she was able to take the customer requirements and work with the design team to get the requirements into the required details that the High level design documents were able to be generated. Further, the past experience with her showed that she was available during the design and development phase for reviewing critical issues and for any consultation. 

However, inspite of all this, we used to run into issues near the scheduled completion date of our features. The team was always running and running to meet the schedule (even coming in some times during off days in order to meet the schedule - showed a good commitment for the over and beyond effort) and we never did miss the dates by more than a day, and with the required level of quality. During reviews, the team members would detail this problem out, asking repeatedly as to why this was allowed to happen since it meant a lot of extra effort for the team members and why we were not planning effectively. 

When this happened a few times, we decided to investigate more properly - after all, this could be a problem in the way we were doing the time and effort estimation, or maybe some team members were not pulling their weight. We got a couple of the more experienced leads to go ahead and they started combing through the documentation, and effort metrics to determine what was the problem. It was soon pretty clear that the time taken for coding, defect generation and fixing as well as for the earlier preparation of documents was not improper, but there were some cases where the effort overshot the estimation by around 20%. Now we were getting somewhere. However, this could not be isolated to some specific individuals, so there was a need to do a more detailed analysis.

Spoke to one person, spoke to another person, and so on. The surprising conclusion was that this was feature creep. As the people were preparing the design documents and then the development process, when there was a suggested improvement, either by the team members or the product manager, nobody really resisted, since this was apparently doing the right thing by the customer (and in a significant portion of the cases, the case for a small enhancement was put up by the product manager).

We spoke to more people, and although there were some standard design and development reasons for the effort-estimate mismatch, there were many cases where the feature creep was also causing problems. We had to make changes; you really cannot keep on pushing right upto your schedule without drastically increasing the risk of quality issues. We put in a new system  that once the requirements and design were frozen, any new changes, even if minor, would need to be tracked as a special category of defect, called a feature enhancement and these will not be approved unless the defect review team approved the changes.

This gave us a lot more insight about the kind of changes that were being requested, allowed future versions to track for changes made during the course of the project, and ensured a more detailed review of the changes, ensuring that there was no risk to quality.