In this guide, I will show you how to create the perfect program management plan. Unlike many other guides you see online, here I will not try to sell you my program management tool, but just to explain how a proper program management plan gets created. Once you follow this guide, you will be able to manage your programs more effectively – including if you don’t know where to start right now.
What is a Program Management Plan?
A program management plan is a document that defines how you manage a program. It is like a set of instructions for the program manager on how it should do his job. Many people believe it is about planning a program, defining the budget and constraints, and so on. However, a program management plan is about how to manage the program. It is about how to plan it, how to define the budget, and how to define constraints. The actual plan, budget, constraints, and more, are not part of it.
Ideally, if you give the program management plan to a program manager or project manager, she will be able to create the actual plan for a given project. If you give the same plan to another program manager, he will create the same (or at least very similar) plan.
So, the goal for a program management plan is to define effective rules that ensure the program will run in a successful way. This includes things like foreseeing and addressing risks, managing dependencies and constraints, involve the right stakeholders, or keep some information confidential.
What is a Program?
If you are looking for a program management plan, most likely you know already what a program is. Yet, it is worth giving a simple definition so that we know we are talking about the same thing.
A program is a collection of separate projects that integrate together to create a larger goal or objective.
What happens inside each single project has nothing to do with what happens inside another project. However, the output of a project is important because it serves as an input for other projects. Imagine you are building a house: the way you dig a hole for the foundations is not important for when you start to build the structure. However, the output (the hole for the foundations) is crucial to allow the structure to be built. And, on the other hand, the way you build the structure is not important for how you dig the hole.
Program management is all about integrating different projects. It is about ensuring the output of a project feeds into another project at the proper time and without issue. In short, program management is about managing dependencies.
Create the Best Program Management Plan
Structure MUST be flexible
If you read the Program Management Body of Knowledge Guide (PMBOK Guide) curated by the Project Management Institute (PMI), you will see there are several topics your program management plan should cover. You may be tempted to cover them all.
Yet, in my experience as program manager, I see it more effective to make a selection of what you want to address. Not all points will be relevant for your program, and thus the structure of the document should not be fixed, but adaptive to circumstances.
The document structure needs to change based on the type of program you manage. Programs with high uncertainty may need a detailed dive deep on risks, while programs that are more predictable may need just a quick section of risks.
Thus, in this guide on how to create the best program management plan, we will not focus on a structure that is imposed on you (as program manager). Rather, we will see the various items that are important to call out during in this type of document, why they are important, and how to think about them. You can use this guide to navigate your program and decide what to write down.
Internal Dependencies
The first thing you should think about when writing a program management plan are internal dependencies. Those are the dependencies are the reason why the program exists. Your organization owns multiple projects, and the output of a project becomes the input of another project. Those are internal dependencies because your organization owns all these projects.
There are two parts of the story here. One is how you manage those dependencies: how you keep track of each, how you register a new dependency if it arises, how you decree if they are late or not, and so on. The other part, which comes later, is the list of actual dependencies. You need to complete the first before addressing the second.
You may work on the two parts iteratively, until you get each part in the shape you want. Ideally, the list of dependencies should start with a list of projects and their outputs, and an arrow that shows what output feeds into what other project. Do not focus on timelines first, just focus on dependencies themselves. Then, for each dependency, you should be able to assess the impact of “what happens if this is late?”. Based on this, you can start to make considerations about how the dependency should be managed.
In your program management plan, you should call out how often you will report on the status of a dependency, and who owns that dependency (typically, it is the project manager for that given project). You should also set up clear communication challenges to escalate, or bubble up, this issue to management if there are problems. This should occupy a significant part of your project management plan. You should consider thresholds, for example “this project cannot be at risk for more than 3 weeks in a row”, and clear actions to perform when thresholds are met.
External Dependencies
Another key part of your program management plan is external dependencies. Those are identical to internal dependencies, except the projects that produce them are not managed by your organization, but rather by external teams. Those may be other parts of the company, suppliers, customers, or a wider community.
When talking about external dependencies, you need to address the same points you addressed with internal dependencies. Define how you will manage them, list them, and create a graph to show how each dependency feeds as an input to one of your projects. This may also be in the other way: your project may produce an output that is needed in an external project.
With external dependencies the role of escalation becomes crucial. Since they are external, you have no direct control over what is happening, so you should spend a good level of details to ensure everyone understands what are the impacts of delays or date slides, and what to do when those things happen and when (for example, after X days of delays). Overall, the structure of this section is identical to the one for internal dependencies, it is only the content that changes.
Risks in the Program Management Plan
Risks are another key part of the program management plan. Like dependencies, they need to be constantly monitored and managed. Unlike dependencies, however, which are projects and activities owned by people, risks are things that can happen in the environment “by themselves”.
Managing risk has two parts: monitoring the risk, and enacting a contingency plan. Monitoring the risk means that someone is always actively looking for the risk to happen, and checks how likely that is to happen at any given time. When the likelihood of happening crosses a certain threshold, a contingency plan is applied: a set of actions to address the risk.
Risk is about uncertainty, and it is not necessarily bad. Risk is an uncertain event that can have either negative or positive impact on a project or program. As a program manager, you should have some risk owners that monitor all the risks, and contingency plans at the ready to exploit positive risk and mitigate negative risk.
It is a good idea, as part of the program management plan, to define how you will monitor risks, what a risk owner should do, and how often (weekly, monthly, daily?). It is also crucial that you set up a framework to measure risks, and ideally it should be on a numeric scale (read How to measure anything for more information). Risks labeling such as “low”, “medium”, or “high” are not effective.
Communication and Stakeholders
As a program manager, your job is conveying proper information in the right direction to get things done. This means you need to develop a way to track who are the people involved in your program (stakeholders), including the ones that just need to receive information and updates about it.
Then, you should plan on how to convey this information to them. Is a weekly email report good enough? Should you have some weekly meeting to move the program forward with all the project managers involved? Maybe a daily standup?
Think about all the possible reasons of why an option may make more sense than another for your specific program, and write it down in the program management plan.
Program Management Plan in Summary
In summary, the project management plan is the document that defines how you manage a program. There, the most important part you should cover are dependencies (internal and external), but also risks and communication play a critical role. When creating such a plan, you may want to add a RACI matrix to ensure everyone has clear what he or she should do.
