I have been working on designing a solution to the latest batch of requirements to our system. There was some error on the scheduling of this task. Somebody put a placeholder in the schedule, estimating about how long prior jobs like this took. That is good for a placeholder. That will not work for the real schedule, especially when the customer wants a whole lot more than usual this time around.
I brought up the issue a couple times. Finally someone took note and realized the schedule was all screwed up. The managers got together and put two senior developers on the task. The problem is that one of those senior developers works more like a junior development.
The project manager asked me if we could pull this off. I told him yes if there were no other interruptions. Another manager said we needed to fix a few bugs. I said we could fix some bugs, but all that needed to be factored into the scheduel. A final schedule was drawn up. Then we got down to work.
Along comes a requirements analyst. She told me the customer wanted to make a change to the requirements. I Said that was fine and could be captured. But we could not act upon those changes with the current schedule. The analyst told me the customer would not be happy with this. I replied that happy or not, the scheduled could not accomodate changes to requirements. This holds true even if somebody thinks the changes are small.
In the end, I got management backing. The new changes will be addressed in a future delivery. The moral of the story is simple. Figure out all the requirements up front and then freeze them. If you do not do that, there is no way to keep a constrained schedule, especially if it is tight.
