|
|
Schedules are like laws; they are created by legislative bodies and meant to be obeyed, but they are also designed to allow exceptions if evidence warrants special circumstances.
Likewise, milestones created at the beginning of the project may need to be changed based on problems that occur during development. For instance, the decision to change the original game specification (e.g., to support a new computer, a new 3D card, alter preplanned artwork or audio clips) in order to make a better product is a situation that may warrant “breaking the law” of the schedule.
If another month of development time would greatly improve the gameplay, remove non-show-stopping bugs, or allow for better visuals or audio effects, then circumstances justify deviating from the schedule. To ship a game on a target day, month, or year, regardless of the state of the product at that time, can spell disaster for that product (not to mention the harm it does to the publisher’s reputation). Missing seasonal dates like Christmas is bad, but shipping a buggy or poorly made product is worse.
You should only modify a project schedule if there are valid reasons. The team and publisher must agree that the additional time will substantially benefit the product.
|
|