Customization: if you are not using the propsal template, copy and paste relevant prompts and sample answers from that template here and remove the link.
Consider the sample list of project manager areas of authority. Edit the list to fit your project. If the project manager does not have the authority to do what is needed, then the manager must request more authority, negotiate with others who have the authority, or scale back the scope of the project.
State some of the lessons learned in planning past releases or similar past projects. Explicitly stating these lessons here will help avoid repeating past mistakes.
### What are the most important facts that a project stakeholder should know about this plan?
Briefly highlight the most important things that a project stakeholder should know about your project plan. Focus on managing the expectations of project
stakeholders who might otherwise misunderstand the project plan.
### What general development approach will be used?
Name and briefly describe the software development method that you will use on this project. If you have the software development methodology template, read it for ideas and reusable sample text. The following prompts ask you to describe more specific parts of the methodology.
List the tools that you will use during this development cycle. If there is a tool that you want to use, you may need to plan time for acquisition, installation, and training.
Change control is key to actually finishing a project. Consider the sample change control mechanisms, then add, edit, or delete them to fit your development process.
Plans will always change over the course of the project. Changes that are not recorded as changes to the plan document can lead to uncoordinated efforts. It is important to explicitly identify the person responsible for updating the plan document and explicitly commit to the change notification process.
Project planning can be viewed as a system of goals with different degrees of flexibility. For example, you might say that quality must be exactly as specified, whereas schedule could vary somewhat. The prioritization of these planning goals will help to guide individual management decisions later in the project. E.g., should we ship this release with a particular known defect or take the time to fix the defect?
Consider the sample list of tasks in the template. Add, edit, or delete tasks to fit your project. If you cannot confidently estimate the duration of a task, try to break it down into smaller parts. Consult with the person who is likely to actually work on the task when making estimates.
List the deliverables that will be produced during this release cycle. Include both external and internal deliverables. Manage the delivery dates by giving specific dates when possible, or ranges of dates, or dates that are relative to milestones. E.g., the userguide will be ready 10 days after the application has been handed off to the QA group.
Use this grid to plan the number of hours needed for each task in each week. Keep in mind the dependencies between tasks and the availability of each resource.
Customization: you may wish to use a spreadsheet or MS project plan instead of this table. In that case, you may still find the reusable sample text useful in that format.
Project risks are listed on the risk management worksheet.
If you are not using the risk management worksheet, read that worksheet to understand common project risks and then simply list relevant risks in this section.
Use this checklist to help check your work on the project plan. Any question that cannot be answered positively may indicate that you should revise the plan until you are satisfied.
