Programme vs Project Plans

Home Forums Microsoft Project Discussion Forum Programme vs Project Plans

  • This topic is empty.
Viewing 3 reply threads
  • Author
    • #473509

      Hi all, I wonder what best practice has been written on the creation of programme plans? As programmes have a different objective to projects, what are the differences you would expect in the content?

    • #473559
      Avatar photoDaryl 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.

    • #473614
      Avatar photoJigs Gaton

      The PMI courses bring u down to a certain level, but to see what individuals do across industries, see this site for sample MSP plans, sorted by industry:

      It’s been a dream of mine to collect a random sampling of plans across all segments, and then do a data analysis on them all. But so far, just a daydream…

    • #484790
      Gaven Rank

      I know from the experience that when we tried to integrate Salesforce into our system we did not go into the nuances. Then I found an article about crm software development company , so I propose that you read these facts and look at it. You may also learn here to request help, and with the help of skilled personnel, you can easily and quickly turn Salesforce into your system.

Viewing 3 reply threads
  • You must be logged in to reply to this topic.