<include a short description of your organization and any organizational issues (a paragraph or two will usually suffice). See your text for background information. Things to includes are:

<What process will your group follow? Give a sentence or two description of the process and the rationale for selecting this process. Give a diagram of the process that includes the major phases and the sequencing of the phases. See your text for background information. You may decide to implement a "hybrid" model that is not exactly as shown in your text.>

<What Operating System, programming languages, compilers, libraries, ...>

<How will your group handle version control and change control? Who is responsible? What procedures will be followed? ... See your text for background information>

<What QA activities will your group do and when will each activity occur? ... Who is responsible for making sure this occurs? How will the results be reported?>

<Break down your project into a hierarchy of work packages. For each work package, estimate how much work time it will take to complete. For each work package, state who is responsible for its completion. Note: it is expected that this information will be at a high-level at the beginning of the project and will be updated monthly to provide more detail.>

<This should be detailed enough so that important activities and dependencies are evident. Estimated durations of activities and the critical path should be included. See your text for discussion and example PERT charts.>

<You must estimate and track your technical progress using appropriate metrics for each phase of your project. What is a useful metric for each phase of your project? For example, for requirements phase, the total number of requirements, the number of requirements changes, the number of TBDs, ... For OO analysis and design, you might want to count UML diagrams completed. For detailed design and code, you might want to count packages, classes, methods. You will also want to think about other technical metrics such as: memory usage, execution speed, size of various documents, complexity of code (using any of the complexity metrics), ... These can help in planning and in tracking your project work.>

<Choose your metrics carefully -- select metrics that will be easy to collect, easy to report, and easy to interpret. The goal is to give management insight into the progress and risks of your project.>

"At a minimum, each team member will post the following information weekly: individual time and activity log, individual status information, individual issues and problems, and individual defect log.

Each week, the project manager will: read and analyze the logs; examine the technical content of the work done to date; examine the technical progress metrics; consider the QA results; reassess the potential project risks; and take corrective action if necessary.

The project manager will issue a Project Management Report on the schedule as indicated in the deliverables section above. At a minimum, the Project Management Report will be generated every two weeks and will include the following information: 1 sentence description of overall status, 1 or 2 sentence of any planned changes to the project plan, graph of planned vs actual time, graph of planned vs actual for each technical progress metric, updated PERT chart."