Project plan

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.

Introduction

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.

Organization

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.

Sponsor

Specify who’s providing the funding for the project.

Steering commitee

List the current members of the steering commitee.

Project team

List the project team members. Specify their role(s).

Project environment

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.

Stakeholders

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.

Timeline

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.

Milestones

Maintain a list of milestones, and tick them off as you pass them. Explain the criteria for passing each one.

Iterations

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).

Monitoring

Explain how the activity and progress will be monitored. Often, this means looking at a Jira dashbaord.

Reporting

Explain how and when reports will be created to show progress. Summaries can be included in the iteration reports.

Business case

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.

Risk management

Describe your approach to risk management. How are risks identified and recorded? How often, and by whom? Are you ranking them?

Risks

List current risks.

Problem management

How are problems identified and recorded – and handled? And by whom?

Problems

List current unsolved problems.

Delivery management

Delivery means implementing the solution and putting it to use in the corresponding business processes.

Release management

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.

Incident management

Describe tools and processes for reporting and handling incidents while the project still runs.

Handover

Describe any procedures for handing over each incremental solution delivery to the regular operations and support teams.