Introducing Program Maps

This post describes program maps – a graphic technique for showing the interrelationship between various components of an IT program and program events plotted against time.  Rather than making your stakeholders (management, executives, users) sift through pages of confusing Gantt charts or reading through voluminous plans, stakeholders can see what’s in store using a program map.

Program maps are loosely based on the transit map created by Harry Beck for the London Underground. Here’s an up-to-date version of the London Underground transit map:

London Underground Transit map
London Underground Transit Map

Mr. Beck could have taken the easy way out and superimposed the subway lines and their stations on top of a map of London. Instead, he developed a representation showing the spatial relationships between the stations and the rail lines independent of their actual geophysical location. What you see as  a grid pattern in the map is not even close to the real configuration of London’s subway system. Despite this “distortion”, you can easily find your way around greater London using this transit map.

How does a transit map relate to an IT program? The map gets us part of the way there, but we also need to show the various events and activities across time so we can add a scheduling component to the map. To do that, the program map borrows from Gantt chart practices by repurposing the timescale on the metro map. Sounds confusing? Here’s an example of a program map:

Example Program Map
Example Program Map

For the London Underground, the transit map shows the various lines making up the Underground system and the relative location of the stations on a transit line (a different color used for each line). The program map borrows the line and station concept from the Underground map, but goes a step further by superimposing a horizontal time axis (a Gantt chart timescale). The different “tracks” or “lines” found in the subway system become the program components with each program component corresponding to a “track”.

Example program components are:

  • Software acquisition and development projects
  • Operations and maintenance activities (such as user support/help desk and system operations support)
  • DevOps (an Agile approach that unifies development and software operations)
  • Software maintenance projects resulting in new releases of existing systems/applications (a “traditional” software engineering practice)
  • Other activities and projects that make sense to you and your organization to include in and manage as part of the program.

Your program management and planning documentation should define the program components for you.

Program Map Graphic Notation

This section describes the graphic notation used in program charts.


At the top of a program map is a time scale similar to that used in a Gantt chart. In the example above, the program map covers a four-year period starting with the current year (Year 1) and ending at the end of Year 4. I recommend starting the timescale in the current year or current year – 1. Use the approach that best suits your stakeholder’s expectations and information needs.

You can use calendar or fiscal years, but you must show the year type in your timescale or in a prominent place on your diagram. When indicating the year type in the timescale, use “FY” for fiscal year (e.g., FY 2019 for fiscal year 2019) or “CY” for calendar year (e.g., CY 2019 for calendar year 2019). Use the year type most familiar with your executives and management. For example, in the U.S. federal government, using fiscal year (running from October 1 through September 30) is the way to go.

Also like Gantt charts, you can use a secondary timescale to break the years down into quarters. I recommend not going anything shorter than calendar quarters because you want to show the “big picture” and not get bogged down in the details. If quarters don’t matter, leave them off your diagram. The key is to provide enough detail to give a good, high-level view of the program plan without implying precision that may not exist.

Four-year time scale with each year subdivided into quarters.
Example Time Scale

Component Swim Lanes

Making up the vertical axis of the program map are two or more swim lanes representing the program components. This is where program maps deviate from Gantt charts where you would see a list of summary tasks and constituent tasks and associated milestones. Use stacked horizontal rectangles for the swim lanes and set the starting (left) and finishing (right) sides of the swim lanes to correspond with the starting and ending dates the timescale.

Label each swim lane with the program component name following your program management plans. The example below shows three swim lanes, each corresponding to a program component. Labels for the program components are rotated 90 degrees to conserve space.

Example Swim Lane
Example Swim Lanes – One for Each Program Component

I recommend not having more than five swim lanes in a program diagram because it makes the diagram too busy.  If you have a large program with more than five components, consider splitting the program across two diagrams.

Component “Track” Symbols

This is where we untangle the various train tracks seen in the London Underground transit map and straighten them out, using a track for each program component. Compared to a Gantt chart, a component track is all of the tasks and milestones associated with a component schedule “flattened” into a line (the “track”).

You can show events planned or that have happened if the timescale includes earlier years using various symbols on the appropriate track. Also found on program maps are symbols to show interactions between different program components.

Component Start

Every component in a program has an initiating event shown as a solid circle on the left end of the component line:

Component Start Event
Component Start Event

Do not include the component start event on the track if the initiating event occurred before the start of the time scale used in the diagram. Consider the situation where the legacy system component shown in the example program map started before Year 1 (say year -4). Since the initiating event is “off the chart”, the track indicates continuity from the past by not showing the initiating event on the legacy system component line.

Similarly, the modernization project track shows the initiating event starting at the beginning of the first quarter in year 1. From this, we know the modernization project to replace the legacy system started at the beginning of Year 1.

Component End

For every start, there must be an end, and this is shown in the program map diagram using a closed circle at the right end of the component track:

Component End Event
Component End Event

In the case of the example program map above, we see a component end event occurring at the end of Year 2 for the legacy system. A note on the diagram tells us that this is when legacy system decommissioning will take place.

Component Continuation

Use the component continuation symbol (a right facing arrow) to show activities and projects going into the future beyond the end of the timescale.

Component Continuation
Component Continuation

The user support swim lane in the example diagram has an arrowhead pointing to the right indicating that user support for the new system continues “off the chart” beyond Year 4.


A Milestone is a major event occurring during the timescale period affecting a program component. Use a solid diamond shape aligned with the approximate date on the timescale to show when the event will happen (or happened if it occurred in an earlier year covered in the timescale).

Component Milestone
Component Milestone

The example program map above shows a series of milestone events occurring each quarter on the modernization component track. A note tells us that the milestones represent planned quarterly releases of the new system – representative of a DevOps approach to system maintenance and operations.

Looking at the User Support program component in the example program map, we see a milestone indicating the end of user support for the legacy system when the system is decommissioned at the end of Year 2.

Interactions Between Component Tracks

Diagram notations discussed above applied to a single component track.  The notations described in this section are for show synchronization, merging and forking interactions between two program components.


The program map uses a dashed, double arrow-headed line  between two components to show synchronization:

Synchronization between two components
Synchronization Between Components

In the example program diagram above you can see synchronization between the:

  • Legacy system and modernization program components with a note telling us that users will begin transitioning from the legacy to the new system in the middle of year 2 .
  • Modernization project and user support with a note telling us the user support activity is beginning the transition to the new system at the start of year 2.

Synchronization components also have a timing element – they mark the beginning of the synchronization activity and should correspond to the year (and quarter, if using  them) of the timescale. They do not show the end of the synchronization activity because that’s depicted in the individual component tracks.

In the example program map, you can see that user transitions from the legacy to the modernized, new system start at the beginning of the third quarter for Year 2, wrapping-up six months later when the legacy system is decommissioned.

Similarly, transitioning the user support function to the modernized system begins six months before the system goes live in late second quarter year 2. We know the system is going live at that time because the first release occurs then (shown by the first milestone on the modernization track) and the angled line (merge symbol described next) joining the legacy system track and the first milestone in the modernization track.


Use the merge notation to show a component being replaced by another component:

Merge Components
Merge Components

In this example, the component being replaced is above the subsuming component. You can just as well draw a merge like this:

Alternative Merge Symbol
Alternative Merge

Which one you use depends upon the layout of your diagram. In either case, the diagram shows the component on the right side of the diagonal merge line subsuming the component on the left. The right end of the merge line should correspond with the date in the timescale to when the merge is completed.

The example program map shows a merge from the legacy to the modernization component at the end of the second quarter in year 2. It also shows the legacy system decommissioning at the end of year 2. Most of the merges I’ve seen on diagrams follow this pattern – a legacy component being replaced by a new component.


A fork shows splitting a component into two or more components. Here’s the technique used for showing a fork:

Fork Example

I haven’t run into too many forks – most organizations strive to reduce or consolidate components rather than create new ones. I can’t think of a reason why you would fork a component and then immediately decommission one of them, which is why you see two continuation arrows in the fork example.

Program Maps Do’s and Don’ts

Now that I’ve described the various bits and pieces of program diagrams, I’ll offer some advice in using them. But before I start, remember that program diagrams are a means of easily conveying potentially complex relationship between program components and time.


  • Periodically update your diagram! Nothing is as telling as an out of date diagram.
  • Show a version number “as of” date on your diagram.
  • Consider having a user experience designer (if one’s available) or someone well versed in graphics design review your diagram and revise it if necessary.
  • Use annotations to explain important events on the diagram, but use them sparingly to avoid cluttering the diagram.
  • Consider using color to differentiate between swim lanes, component tracks, and other elements.
  • Indicate you are using fiscal or calendar years in your timescale


  • Put too much detail in the diagram. Program diagrams summarize a lot of information – you can refer to other documentation for additional information.
  • Think that all stakeholders will automatically understand the diagram. You may have to explain to them how the diagram works.
  • Go beyond quarters in your timescale – remember, program maps are high level views and too much detail can be self-defeating.


I’ve used program maps for two IT programs and to graphically show the technology transition plan for a federal agency (the U.S. Nuclear Regulatory Commission). Program maps, when properly constructed, can convey a lot of information that stakeholders can easily absorb.

I am not aware of a software package or tool capable of natively generating  program maps. Microsoft Visio or any of the more popular presentation tools (PowerPoint, Keynote, Open Office and such) can be used to create program maps.

Please share in the comments section your experience using program maps. I’m also interested in your suggestions for improving this technique.

Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: