Quick Links

Reply To: Programme vs Project Plans

Home Forums Discussion Programme vs Project Plans Reply To: Programme vs Project Plans

Daryl Deffler

Hey Phillip
A few thoughts and examples from what I’ve experienced.

Programs generally encompass a higher more broad objective while projects are targeted at a specific component of the program objective. For example, The Program objective might be to increase sales and individual projects within it will target specific components such as implementing the new sales software, launching a new marketing campaign, training the sales force on new techniques, etc. The individual projects can typically stand alone and provide a very specific end product/deliverable. Schedules at the program level (if any) should only contain work focused at the program level (example later). Projects should only contain work related to delivering that one specific objective. Meaning, don’t put tasks related to a new marketing campaign in the schedule to implement the new sales software.

Thinking in terms of a larger program:
From a project schedule perspective, I would expect each project to be a unique stand-alone project schedule for several reasons. First, each project probably has a different PM (and often team) assigned and you want them to be able to manager their schedule independently of other project schedules in the same program. Second different projects may use different methodologies. Training/Marketing projects may be more waterfall while software projects may be Agile. Third is simplicity. Merging multiple projects into one project schedule can technically be done, but in doing so, you will significantly increase the project schedule complexity from both a setup and on-going maintenance perspective.

From a sponsor reporting perspective, individual projects are also more effective. If needed multiple schedules can be easily combined using MS Project techniques (Master/Subprojects) or even through external tools such as Excel. However, if everything is combined in one Program schedule, it is usually more difficult to pull them apart if needed for reporting. So consider what the sponsors want to see and how it is best presented to them as a factor as well. For example, on a large program I managed, I presented a sponsor overview report that combined all project schedules so they could easily monitor overall key Program indices. This was my combined view. But if that overview showed issues, they could easily dive into individual project schedules to identify A) which project was driving the overall problem and B) what the specific issue was in that individual project.

Project capitalization may also be a factor in creating different project schedules. Meaning work on this specific part of the program can be capitalized into business tax credits while others parts of the program can’t. In these cases its critical that capitalized/non-capitalized work is segregated in case of IRS audits.

One other consideration, which comes more into play as the Program size increases. If its a large program, there might be a team of 4 – 10 people who work strictly at the program level supporting, coordinating, and directing the individual project PMs/teams. I’ve found its much easier to create a program level support team project for these people, rather than trying to figure out how to integrate them into multiple individual project schedules.

So, in summary, there are a lot of factors that should come into consideration when determining how to set up your program/projects in MS Project. Small programs with a relatively small amount of work, individual projects are only a few hundred hours, consistent capitalization across all aspects of the program, and only one PM running the entire thing may lend itself to a single schedule that includes everything. But I’ve found that as the program size increases, the number of projects within it increases (and so on), it becomes more effective to create multiple project schedules.

Bottom line, there is no hard/fast rule that it has to be done this way or that way. It really boils down to identifying the right way to effectively manage all the work taking into consideration a lot of perspectives such as those noted above. Your ultimate objective is to provide a program/project environment that is easy to manage, track, and report.

Hope that helps.