Most of have you have used a work breakdown structure (WBS) to break large units of work into the smaller activities. These smaller activities end up being used as the basis for your project schedule. This technique is also called “decomposition” – that is, breaking down larger entities into more and more granular components or “breaking big rocks into small rocks.”

You can apply this same logic when structuring very large projects. If you have work that’s too large to manage as one unique project, you can break the work up into a set of smaller projects. You can then establish a program to coordinate the individual projects so that all of the business objectives and business value is achieved.

You can use this simple model to define the underlying projects within the program.

1. Define the overall scope of the program. This is the first step. You can’t define the underlying projects unless you understand the total amount of work required. The program scope defines the totality of work. Anything not in the program scope would not be considered as a part of the program.
2. Break the overall scope into the underlying deliverables. This is where the work breakdown structure technique comes in. In this case we are actually creating a model called the Program Work Breakdown Structure (PWBS).
3. Break down large deliverables into smaller work products. Some deliverables may still be too large to create in one unique project. In this case, you’ll need to break the large deliverable into smaller work products. These can also be called sub-deliverables. For instance, a large IT system could be further broken down into databases, web, batch processes and core application logic.
4. Define each deliverable/work product to be a project. At this point you have broken a large piece of work down into a more manageable group of deliverables and work components. The trick now is to define individual projects to create each major deliverable and each work component.
5. Estimate the work required for each project. You should be able to determine, at a high level, the work required to complete each project. This may not be instantly obvious and might require some upfront analysis and research. However, you must have some idea as to the estimated effort, cost, and duration of each project before you can proceed to the next step. This will not be extremely accurate, but hopefully you can get these estimates of effort and cost to around plus or minus 35%-50%.
6. Put the projects in sequence. Now that you have the projects identified and estimated, you can create a high-level project Gantt chart. You can determine which projects need to be executed sequentially and which ones can be executed in parallel. You can also estimate the overall duration of the program by laying out the sequence of the underlying projects. Likewise you can create an overall project budget by adding up the estimated costs for all of the projects.

The days of the mega-project are over. It’s better to break down huge initiatives into a group of smaller projects, and then coordinate and manage the multitude of smaller projects under an overall program. The technique above gives you guidance on how to define what these smaller projects look like.