Management Plans

I will be the first to admit that I have a very specific method by which I approach a project. I like to do things my way. I'm sure many Project Managers are the same; they have a style that suits them and they use that method when they manage their projects. Mine is likely to be different from other Project Managers, and that is fine. The last time I checked there were many ways to achieve project success. However it is important that the Project Manager takes the time to share his or her approach with the team, and that is where Management Plans come it.

Anyone can read the PMBOK and walk away with a half dozen management plans. They will walk you through Communications Management, to Scope Management, Risk Management, Schedule Management, Cost Management and so on... All of these plans have value and are important in communicating how the project will run. In the case of the Communications Management Plan, I always include an escalation section identifying how decisions will be made when the stakeholders can't reach consensus. This is a good example of how a little bit of planning up-front can help to save a lot of time. It is very easy to write down and commit to this process when a project is just starting up because nobody has any disagreements, and people aren't dug into their factions. Trying to identify how a decision will be made when people are already dug-in to opposing side is much more complicated and difficult.

But you won't find what I consider to be the most important Management Plan in the PMBOK. This plan is critical for me when I am working with new teams of people who aren't familiar with my approach. I am talking about the Requirements Management Plan. This plan provides the model by which the project team goes from a position of having zero knowledge about something to a finished project. For me, this framework begins with Requirements Sessions in which we focus on the baseline business process. We work to diagram it and the key use cases of that process. Then we use this information to begin our discussions of what the benchmark business process should look like. This approach forces us to examine the differences between these two processes. We generate a set of use cases from this benchmark process and those use cases are really important to downstream activities.

The first branch of work from the use cases is to develop the Requirements Specification then the Data Requirements Document. These two products then drive the development of the System Design Document and the Database Specification. The System Design Document and DB Spec are in turn used to generate the System Security Plan and functional software.

The second branch from the use cases is to drive the development of the Unit Test Plan. This is the building block for testing and verification of the functionality. The Unit Test is a part of the Integration Test Plan as well as the Acceptance Test Plan.

Thus as functionality changes over time and the use case changes, it is somewhat easier to mature that change through the documentation when it is clear how each piece if related to the others. By taking the time to document these relationships and how we go from zero to working functionality people who want to understand why they are participating in a requirements session or a design session can see how their work builds momentum to the finished product.

Anyway, for my money, the Requirements Management Plan is the most important and valuable Management Plan in a project.