When we think about a project plan, what do we typically think about? Most people I talk with think a project plan is the schedule…. they think about the Gantt chart… the dependencies... and the critical path. The project plan can contain the schedule, but it is bigger than that. A project plan is a project manager's strategy for how the project is going to be run. It is a tailoring of the project management framework and describes what processes are going to be applied to run the project.

Business Case and Charter

My approach to writing project management plans is certainly not unique, but I am also not sure it is 100% standard. A good project management plan should start off with the business case and charter. This is a statement of the value we expect from the project and your authorization to move the project forward. These documents set context for the product vision and development activities. They establishe the project constraints, known risks, and any assumptions the business is making that could have an impact.

The Product Vision

The vision should describe the customers of the product and the value they will derive from using it. It might address the market segments you are going after and any business constraints the project is operating under. There can be quite a bit of overlap between this document, the business case, and the charter depending on how your team uses these artifacts. I like to think of the vision as the place we really get specific about the product and what it needs to actually do.

You can think of the vision as describing the actors or personas that will use the system, the major product themes, and major epics that are going to be delivered to market. I might also consider delivering a high level release plan to communicate the overall project schedule.

A Note on Documentation

When talking to an agile audience, I always try to be careful to state that these documents do not have to be 100 page monsters. If you are working with a small team and with an embedded and empowered product owner, these documents can live on a whiteboard or a wiki. If you are running a large, and possibly distributed program, you may want to leverage a wiki or some other lightweight electronic communication tool. If you are working in a traditional document driven organization, you might have to create something in document form. Just keep it as lightweight as possible.

The PM Knowledge Areas

Now comes where we describe how we are going to deliver to the expectations of the business. We need to state how we are going to manage cost, time, and scope and explain how our project will manage risk. We need to let the business know our strategy for communicating progress and how will we will ensure quality. We need to communicate what we are going to do if we need to buy anything or hire anybody into the team. We need to get on the same page about how we are going to make staffing decisions and how we will handle any HR issues along the way. We need to communicate how we are going to make sure everything is working together to deliver value.

These are not questions only for traditional teams, agile teams have to answer them too. Often, we assume these things because agile processes have the answers built in. It is just part of the process. Sometimes we need to be willing to explicitly communicate how we are going to proceed in language that the business understands. A lightweight project plan can be just such a tool.

It's all about communication

Sure... the plan might change... we want to preserve the ability to inspect and adapt. That is why we keep the artifact as lightweight as possible. The act of writing this stuff down makes sure that we think it all through, that we don't take anything for granted, that everyone has a common understanding of how we are going to approach the project.

I have had great success in the past walking my PMO through each of the PMI knowledge areas and documenting how our agile techniques are going to manage time, cost, scope, risk, quality, procurement, human resources, communication, and integration management. The point of the exercise is not about the document, it is about getting everyone on the same page, it is about communication and understanding.

After all... that should always be the point of documentation… communication and understanding.

From Leading Agile