Recently I have been asked a lot about what the difference between a Project and a Program Manager is, and what makes a great Program Manager. Well these questions got me thinking. First, no one is perfect - we all have our strengths and weaknesses. Having said that, I try to push them first to what we defined in the Role Expectations for our Project and Program Managers. But what I think the deeper question here is - what do I need to do differently as a Program Manager that I might not already be doing as a Project Manager.

I think for me, there are two key differences in what it means to manage a project vs. a program. First, it is about the level that you are communicating at. As a Project Manager you have your core team and stakeholders that you work with. Everything is moving to the same end goal and timeline, whereas in a program you have multiple projects that have different timelines and scope. In addition, you are communicating to the Project Managers or workstream leads that are leading the individual projects that are part of your program. This means that you may have multiple core teams dedicated to each project or workstream. Therefore, the message you communicate is going to be specific to their project and scope - but still needs to be part of the broader context of the program.

The second difference is about the details. As a Program Manager you need to be across all of the details for every project/workstream in your program. That is, you need to be across all of the different moving parts and understand what the impacts, risks and dependencies are across your program at any given time. Warning: don't confuse being across the details with being a Subject Matter Expert on the details (that is not what I am saying). Together with Analysis Skills in knowing what the impacts are on the program; it is this level of detail that is going to drive your decision making. So in order to be able to have the conversation with your senior stakeholders you need to be up-to-date on what is happening in your programs at the micro level. This means working closely with your Project Managers and Workstream Leads to on top of what is happening at the delivery level (progress, risks, issues, dependencies, resource constraints, etc.). Having all of the information allows you to appropriately do the analysis and be able to drive conversations with your stakeholders and sponsors for the correct course of action.

Both of these key aspects require an ability to see the bigger picture. But what does that mean? There was an old TV Show from the 80's (Alf) where the main character was told he needed to see the bigger picture, to which he responded to confused 'Do you mean the one above the piano?' It sounds silly, but not everyone can or does see the bigger picture - and it is not the one above the piano Alf! :D

Instead, this is about being able to understand how everything is tied together with one another. There are a number of threads that when you pull on one, it has an impact on another. If I pull off a Backend Engineer from the foundation tasks to work on the API Integration, what are the impacts to the Dashboard Interface that the Frontend Engineers are working on which relies on that foundation task? If the Dashboard is delayed because it is down one person, what will this mean for my Partner Onboarding Flow? If you can't answer these questions in the context of the overall program objectives then you don't have the bigger picture in sight. Sometimes those answers may not be straightforward, or that the impacts are hidden in terms of indirect inputs. What I mean by this is that causing a delay to one team may also cause a downstream delay because Team A was working on a feature that Team C is dependent on to be ready for them by the end of the month. So if the feature is either not ready on time, or has a reduced scope, then they will be indirectly impacted by this decision/delay. So how you react to the first decision point needs to be considered in light of both upstream and downstream impacts. This is what it means to see the bigger picture. In some cases, programs follow Newton's Third Law of Motion, which states that for every action (force) in nature there is an equal and opposite reaction. On a program you have multiple forces at play, so you need to understand what the reaction is for each and every one of these.

So back to the question, what makes a great Program Manager? Amongst many factors, it is someone that can see the bigger picture and understand what the impacts of their reactions are across the entire program. Look beyond the piano and take the time to see everything that the program touches and how the projects impact on one another.