I have often seen "program managers" simply manage a group of projects by overseeing each of the projects in their program. They act as a sort quality control of the project outcomes and perhaps oversight the scheduling and financials of each of their projects. In some cases they are more a hindrance to the progression of a project as they place a layer of bureaucracy over the project staff rather than a layer of coaching or mentoring or assistance.

But I rarely see them "program manage". This is what I wish to discuss here and I want to use an example to explain what doing "program management" is. And so I will use the approach I have explained in previous blogs to illustrate a program level decision. This I hope captures the essence of doing "program management".

If we look at the below diagram, we have two Vehicles separated in time:

• Vehicle #1 goes from 2010 to 2012.
• Vehicle #2 goes from 2014 to 2016.

Both these Vehicles are impacting in some way, the one System - in this case a Facility System. So let us say for arguments sake that this Facility is a maintenance depot for say a large organisation. Vehicle #1 needs to modify the existing facility to accommodate a new set of support and diagnostic tools in the period 2010-2012. Vehicle #2 is required to modify the same facility to accommodate upgraded maintenance tools for the upgrade to an existing system.

Now, the logical decision for the program is to move the work that needs to occur on the Facility System during the period of Vehicle #2 forward to the period of Vehicle #1 if at all possible. This may involve all work or perhaps just the facility modifications to make room for the new or upgraded systems.

This means that work on the Facilities System is largely achieved in one period of two years rather than two periods of four years making savings in cost and schedule. Additionally, there is less disruption to the occupiers/users of the Facility.

The point I wish to make, is that this is a "program" level decision. It shouldn't really be a project level decision where the managers of the two projects get together and discuss whether it could be done and if so how. That is assuming project managers have been appointed for both projects in the first instance! This meeting should happen, but perhaps after the Program has made the decision to investigate the options.

The other point I wish to make is that if there isn't a mapping of Vehicles to Systems across a rolling Program of projects, it is difficult to understand how these opportunities can be exploited.

But let's look at this another way - the Facility issue is in fact a risk to the smooth operations of the organisations using that facility. If disruption to that facility is a risk, then bringing the disruption of Vehicle #2 forward to coincide with the disruption of Vehicle #1 may be an option for reducing or mitigating that risk.

So program level decisions are different to project level decisions and program management is much more than oversighting your projects. It is about analysing and assessing the risks and opportunities in your program and making decisions to mitigate the risks and take advantage of the opportunities a rolling program of projects can offer.