By this time, you should have a pretty good idea of the requirements of your project. You are confident of your architecture and design. Your tools are in place and you are able bring up your runtime. The schedule shows all the milestones that you want to achieve by the end of the quarter. Minimally, you should describe what features are going to be executed for the first (11/05), second (11/19) and third (12/03) releases. You can have intermediate milestones within each of these releases. (e.g. when the design should be done, when the code should be completed, when you hope to have "all" the bugs stamped out, when you are going to deploy). You should list the estimated "cost" for feature. By the time you are executing a release, you should have resources (people) assigned to the various features. The costing should add up -- e.g. the total estimated time to execute the feature should match the people-hours assigned. Since all teams are executing on web application products, we strongly suggest that you do three releases with defined features in each release. Your site should be live and running through out the quarter. We suspect that there will be significant changes/updates at about the time of each release. Not having a live site throughout the quarter (e.g. your first release is an alpha and second a beta where the site really isn't really running until the third release) is discouraged. If you decide to go with a continuous release process, your task is a bit trickier. You might want to specify some fine grain milestones that you wish to enumerate. Your schedule can be updated at the project goes on. However, you should be able to track changes because you (or your boss) may wish to see how you line up against your original plans. |
Classwork > Project Milestones >