Most of the project plan is defined early in the first iteration. It’s revised regularly throughout the entire project, usually more intensively as iterations are nearing their end and the next is being planned.
The introduction follows the general documents pattern.
Many project plans include a glossary subchapter under the introduction. However, the project plan dies with the project while the solution lives on. Therefore, I recommend that the glossary is maintained in the solution architecture.
List persons, groups and other organizations that play a role. Specify full contact information (including geographical location), and how (and when) the project will communicate with each contact.
Specify who’s providing the funding for the project.
List the current members of the steering commitee.
List the project team members. Specify their role(s).
Describe where the team is seated within the office compound.
Specify which tools to use for documentation and other work. Provide links to intranet pages or guidelines in file shares that help.
Also mention if tools like Jira are used to manage tasks.
List all stakeholders – explain their interest in the project its deliverables.
Planning and execution
Start by declaring your approach – even if it’s the detestible and doomed-to-fail waterfall approach. Hopefully, you can promise an agile aproach, perhaps adhering to Scrum or SAFe.
Maintain a timeline that goes back to the project’s start. Plot in past, current and planned iterations (or sprints).
Don’t break anything down in activities – that’s done in the iteration plan.
Maintain a list of milestones, and tick them off as you pass them. Explain the criteria for passing each one.
Maintain a list of past, current and planned iterations. Mention each iterations primary focus (and phase), and whether it includes an incremental solution delivery (meaning not just documentation, as is often the case in the first one or two iterations).
Explain how the activity and progress will be monitored. Often, this means looking at a Jira dashbaord.
Explain how and when reports will be created to show progress. Summaries can be included in the iteration reports.
Explain and estimate factors significant to the outcome of the project.
Key performance indicators
Based on significant factors, derrive meaningful key performance indicators that will be helpful in monitoring the solution’s performance even after it’s fully institutionalized.
Describe your approach to risk management. How are risks identified and recorded? How often, and by whom? Are you ranking them?
List current risks.
How are problems identified and recorded – and handled? And by whom?
List current unsolved problems.
Delivery means implementing the solution and putting it to use in the corresponding business processes.
Explain the administrative process for creating a release (including how to write and publish release notes).
Training and support
Describe which training and support the project provide.
Describe tools and processes for reporting and handling incidents while the project still runs.
Describe any procedures for handing over each incremental solution delivery to the regular operations and support teams.