Program Management – When should a project become a program?

Projects, on an individual basis, exist throughout any organization. They can be part of an overall product deliverable, an internal initiative, a process change effort or a tiger team working on R & D.

Whenever any project is instantiated, it has roughly the same constituent pieces: a project manager, a team, a set of stakeholders and most likely a project sponsor. The term ‘project’ is used rather liberally in all circles nowadays, including modern lexicon. We often here of neighbors or colleagues talk about their home ‘projects’, such as painting a room or redecorating a section of their house. Clearly, projects themselves have become a staple fixture within personal and professional arenas alike.

But this begs the question: when does it make sense to enact a program? What aspects of an overall organizational goal necessitate the need for a larger, broad-based program to be created and maintained? Under what circumstances is a program warranted and what precisely is the difference between running multiple, simultaneous projects and a single program?

In most cases, one fundamental question needs to be asked when determining if a program is necessary: are the multiple projects being worked on inter-related in a tangible way and if so, do they have common milestones and inter-dependencies?

As a project manager, when managing several projects and trying to determine if a ‘program’ is needed, a good frame of reference is to consider real world examples and cases where programs were enacted by other organizations. For example, consider something like the Microsoft XBox360 console.

The console itself, when completed, is a singular unit for purchase. Customers will buy the console as a whole (with potentially some additional peripherals) and take it home. But if one examines the console itself, how many individual pieces and components does it contain? As an exercise, we will itemize them:

  • Motherboard and CPU
  • Hard drive or memory card
  • Graphics Card
  • Ancillary access ports
  • Game controllers
  • Operating system
  • Ethernet capability

Now as many might surmise, it is likely not the case that all of these components are being worked on by the exact same people or even in the same location. It is also possible that some of these constituent components are ‘farmed out’ to third-party vendors. Or some aspect of those components is farmed out.

In any sense, what is clear is that in order to produce the end product, there are several pieces that need to be created and maintained and that all of these pieces are part of the whole. And being that the release cycle of the console necessitates the need for the pieces to be delivered in the same timeframe, this is an obvious example of the need for a program.

In a similar sense, as a project manager, the best way to determine whether a program is warranted or not in your particular case is to look at all the individual pieces and dependencies. Determine how they inter-relate and get a gauge of who is working on what and where. As a rule of thumb, as the complexity of the deliverable increases, the need for a program (or even multiple programs) goes up.

The choice to create a program will often become self-evident as the project manager begins to take ownership of various projects. Once a determination is made of the overall set of projects and how they inter-relate, a more informed decision can be made.