8

Managing a Program

In this chapter, we’ll discuss in more depth how to manage a program. As discussed earlier in this book, program management builds on the foundations of project management by utilizing the same key management areas. However, there are some differences due to the larger scope and broader impact that a program has compared to a project within it, so both of these concepts play a substantial role in defining the differences in management techniques.

We’ll explore how to manage a program by doing the following:

• Driving clarity at the program level
• Deciding when to build a program
• Tracking a program

Let’s begin!

Driving clarity at the program level

In order to drive clarity at the program level, we need to understand what sets a program apart from a project: scope and impact. Let’s look at what each of these means in the context of program management:

• Scope: The scope of a program or project is the set of requirements that will be met by the goals. It’s easy to dismiss this as being the same as the full set of requirements that are given, but that isn’t always the case. Going back to the project management triangle in Chapter 2, in Figure 2.3, both time and resources can impact the scope. It is a negotiation process between the TPM and the stakeholders as to what the right balance is going to be. Other factors, such as technical feasibility, may also hinder the ability to meet a requirement. This is especially true in cases where those setting the requirements are not technically inclined; they may ask for a feature that sounds feasible but is not something that can be achieved.
• Impact: This refers to the set of stakeholders and systems that are affected by achieving the goals of the program or project. Every service, application, or device that the scope will involve is affected by the changes. Going beyond that, any client of those same systems is also affected and must be considered when making the changes. These clients may be internal as well as external, such as users.

Figure 8.1 uses the Mercury program to illustrate where the scope and impact exist.

Figure 8.1 – Scope versus impact

The scope is the combined work of the projects within the program; this is essentially the five operating system applications. For impact, this includes both the internal teams as well as external users. For example, in the Windows rollout project, the stakeholders are the desktop devices division management, the Windows team itself, as well as the expected user base for the Windows client. The mobile devices team is impacted by the Android and iOS rollout projects, but this does not affect the Windows team or Windows users, so there is no impact on those groups. Though Windows users might also have smartphones, and thus also care about iOS or Android releases, the Windows and smartphone releases won’t intersect – they are by and large users in multiple groups. In contrast, the Mercury program is impacted by every stakeholder from every project.

In some organizations, the impact may also be measured by a dollar amount. You may hear colleagues referring to themselves as managing a $2 million program or portfolio, though arguably, the dollar amount has a direct relation to the number of users and stakeholders impacted as well.

Understanding the difference between scope and impact will help us define proper boundaries in both programs and projects.

Defining boundaries

The boundaries of a project or program are simply its goals and, by extension, the requirements that it will deliver. For a standalone project or program, these are just the goals themselves. For projects within a program, however, it’s a little more nuanced. Defining the boundaries of a project or program can help ensure scope creep is noticed and that the designs that fit the requirements stay within the bounds of the project, and help you see which projects should be part of a particular program. Without a clear boundary, a program can stray from its purpose.

To understand how to define the boundaries within a program, let’s first talk about how we set the boundaries within a project. At this level, it’s fairly straightforward – we define milestones and features. As discussed in Chapter 5, Plan Management, milestones are often the same across projects and break the project up into phases, such as design completion and user acceptance testing completion. The features are where some work is done as they are specific to the requirements. Looking at the Windows rollout project feature list in Chapter 5, in Table 5.8, you can see that there are several self-contained deliverables, such as the user profile object and presence object. Each of these features groups together a set of requirements into a cohesive deliverable.

This same methodology is used at the program level, where a feature is represented by a project instead. Looking at the Mercury program as a whole, the goal is to make the Mercury application available to 90% of users across all platforms. As discussed in Chapter 3, Introduction to Program Management, an easy way to break this apart is by drawing boundaries around each operating system. Each project would then have a well-defined boundary within a single operating system but would also line up well with the stakeholder boundaries of the Mercury company.

From a feature perspective, there is an additional boundary that can be created that further restricts the platform scopes that we introduced by carving out the P2P subsystem as a separate project. Again, this has a well-defined boundary of delivering the P2P functionality in a consumable library by the operating system teams. In this way, each project is a feature, albeit a large one.

Now that we’ve learned how to drive clarity at the program level using the scope and impact to define boundaries, we’ll use this knowledge to discuss when and how to define a program.

Deciding when to build a program

We know what a program and project are, but this has all been with the assumption of a pre-existing program. As a TPM, one of your jobs will be deciding when a program needs to be created – when it is appropriate to the needs of your organization to do so.

Knowing when to create a project is straightforward – you receive requirements to deliver a new application or service, a new feature, and so on, and you create a project to deliver on those requirements.

However, knowing when a program should exist is a bit more nuanced and depends on the situation. There are two avenues in which a program is created: from the beginning when requirements are given and during project executions where a need arises. Let’s explore both scenarios.

Building from the start

Deciding to form a management program around a set of requirements is how most people perceive program formation as it fits the form that project creation takes and thus makes sense. To make this decision, you need to first clarify the requirements as this process will require analyzing the requirements closely to define appropriate boundaries.

Chapter 5, Plan Management, went in depth into driving clarity in requirements, so I won’t repeat much here in that regard. The biggest difference between driving clarity in requirements for an existing project compared to before project and program formation is that your clarity helps you categorize the requirements. You are looking for patterns or deliverable chunks of requirements – much like determining features in a project.

When examining requirements, you are looking for scope and impact cues that may serve as logical delineations between multiple projects to deliver on the requirements you have. Once a set of requirements is broken out into more than one project, a program is needed to ensure the full requirements are met.

Using the Mercury program and project list as an example, Figure 8.2 illustrates a typical project and program boundary.

Figure 8.2 – Program versus project boundary

The Mercury program goal requires that the P2P application is available to 90% of the user base. In Chapter 3, Introduction to Program Management, we examined the ways of achieving this and concluded that making the application available on all five operating systems was the best approach. Looking at the requirements with this in mind, a natural delineation could be to carve the requirements apart by the operating system. Though these could have been treated as features in a single project, the stakeholders were different for each operating system, and thus the impact on these stakeholders rarely overlapped. The impact cues are what help us decide that creating multiple projects is the right way forward. As there is more than one project, a program is also needed to ensure that these projects keep the program goal in focus, as well as facilitating cross-project collaboration.

Had we decided to just deliver to the desktop operating systems, as an example, then a single project with multiple feature deliveries may have been appropriate as the stakeholders all roll up within the same desktop devices division within the Mercury company. So, the combination of what to deliver to meet the program goal requirements and the organizational structure of the company helps form the decision to build a program. Each company has its own organizational structure, so whether or not a program makes sense for you depends on your company as well as the requirements you are working with. The only hard and fast rule comes down to having multiple projects to get the requirements met.

Though building a program from the beginning is natural, it is not the only way a program may need to be formed. Let’s explore what types of scenarios will lead to creating a program mid-execution.

Constructing a program mid-execution

When I say mid-execution, I’m referring to any point after one or more projects are in-flight and a program is created to encompass them. Chapter 4, Driving toward Clarity, introduced the perpetual skill of driving clarity, and this goes beyond the requirements and issues at hand. TPMs are adept at looking at the bigger picture and piecing together when one project may impact another. It is our job to ensure the health of our projects and programs across our organization.

In this constant state of analyzing, a pattern much like the one you look for when given new requirements may emerge. As an example, my current team is working on several projects that impact customer experience. Each project came to life separately out of different needs and different stakeholders; however, looking at the requirements for each project, a common end goal could be discerned relating to the ultimate end state for the customer experience. I did an exercise where I combined the projects into a program to see how they would fit, and this led to realizing that one of our unfunded projects fit into the program to close it out and therefore had more value than initially thought. This exercise ended with creating the program and funding the last project.

Without the program, the projects would have been successful on their own, but the program brings cohesion and purpose to the group of projects and helps uncover value that wasn’t obvious on the surface. This will lead to a better outcome in aggregate than each project could deliver on its own.

Figure 8.3 illustrates the construction of a program from existing projects.

Figure 8.3 – Defining an in situ program

In this figure, multiple in-flight projects, each part of their own program, are combined into a program to align their goals to a shared desired end state. In this case, Program D is the new program created to encapsulate projects A.2, B.2, C.2, and C.3. The program is temporary and will end prior to Program B and Program C concluding.

This brings up an interesting concept of a project existing within multiple programs. If project management tools are to be believed, this should not be allowed, but there is value in allowing overlap as the overlap highlights different aspects of that project’s goals and helps ensure the wider organization is moving together in the same direction while ensuring singular goals are also achieved. In a sense, this overlap is natural and feeds into the TPM’s ability to see both the forest and the trees, and not get stuck in one or the other.

Now that we’ve driven clarity at the program level and learned when to create a program, we’ll look at the different aspects of tracking a program.

Tracking a program

A program has the same key management areas as a project and each one has additional aspects to consider given the larger scope and impact. We’ll touch on each of these key management areas:

• Program planning
• Risk management
• Stakeholder management

Program planning

Regardless of how the program came to be, the key requirements in the planning stage remain the same. The reason that a program exists is to facilitate multiple projects in achieving a common set of goals. The most important step for a program is to define a common set of goals.

If the program is being created from the beginning and no project has started, this is a straightforward task as the requirements as a whole will tell you what the end goals will be. Each project would then take a subset of these requirements to form its own goals. In the case of the Mercury program, the requirements stated that the Mercury application needed to be available to 90% of the user base. This became the goal of the program, and the projects took the subset of requirements needed for their given operating system.

In the case where the program is being formed from projects that are in flight, this exercise can be a bit more abstract. This is because it is easy to assign items into known categories and yet hard to determine what categories should be given those same items.

Let’s pretend that the Mercury program doesn’t exist, and instead, each operating system team is independently creating a P2P messaging app. Each application will look very different in terms of the user interface as each operating system has different conventions to adhere to. Looking at each one individually, it’s harder to see where a cross-platform P2P subsystem could be utilized because you are looking at the application as an isolated idea. However, if the potential opportunity for de-duplication of effort and assured cross-platform capability is seen, then a program goal can be created from this opportunity.

It may be that the program goal is written in a way to make this preferred synergy part of the goal and states that a common network layer component is part of the end state. The result of looking at the program as a combination of existing projects compared to a goal split into projects can change the nature of the goal to ensure alignment and understanding, though the end state will be the same.

Now that we’ve planned the program, we need to look at how to manage risk.

Risk management

In Chapter 6, Risk Management, we looked in depth at risk management practices and touched on how risk assessment and management at the program level is about a difference in perspective. The program will focus on cross-project dependencies and the risks involved, whereas the project will focus on cross-task dependencies as well as risks associated with a given task itself.

At the program level, we need to examine how a project’s deliverables may overlap with another project’s deliverables. These intersections will always include some risk. Chapter 6, in Figure 6.3, talked specifically about the risk of project delays due to the subsystem component that was required for each operating system project to complete. Aside from scheduling risks, there may be inconsistencies in APIs and behaviors of those APIs from the operating system to the operating system. The intersection of the subsystem with all five operating system projects represents a risk that the subsystem API capabilities don’t align with the needs of a particular operating system. Any change to the API contract can lead to issues in the other operating systems, which could lead to a cyclical risk given the high number of touchpoints. This is certainly solvable as this isn’t the first application to have a shared API across multiple systems, but the risks are still present and need to be paid attention to. For cross-project dependencies such as these, the TPM running the program would own the risk and ensure that the risk strategies are followed within the impacted projects.

Some risks that exist at the project level may be important enough to be tracked at the program level as well. In these cases, the owner may still be at the project level, but the visibility of the risk is elevated to the program level and usually a larger set of stakeholders. Ensuring the risk strategies are followed still falls on the project TPM but will require scrutiny from the program TPM due to the high-profile nature of the risk. As an example, the Windows rollout project may have a risk that impacts their ability to enter into cross-platform testing on time. Though this is solidly a project risk based on task slippage, it has the potential to impact the other projects’ ability to finish cross-platform testing. As such, the program TPM will report on the risk to the program stakeholders – which includes all operating system teams and divisional management. The Windows rollout project TPM, Cassette, would own the risk, with the program TPM watching closely and providing help as needed.

Sharing risks from the project to the program level and aligning program goals across projects require strong communication strategies. This additional overhead of a program coordinating across projects adds risks related to dependency delays and longer design times to allow for syncing across teams. To reduce the impact of these risks, let’s look at stakeholder management to see how we can provide a strong communication foundation for the program.

Stakeholder management

The role of the program TPM is to set the projects up for success. They are there to ensure that each project TPM understands the role of their project in relation to the program. As a project TPM, they should already understand the goal of their project but may not realize how it fits into the larger picture of the program. The program TPM also needs to ensure that the stakeholders are aware of all of the projects and the interdependencies that may concern them. To accomplish these tasks, there are multiple ways to engage your stakeholders throughout the program to offer proper guidance. We’ll explore each in the following subsections.

Kickoff

Once a program is created, either at the beginning along with the associated projects, or in flight, a kickoff meeting is needed. A kickoff meeting is where all stakeholders come together to discuss the program and its goals, as well as the role each stakeholder will play in the management of the program. Just like at a project kickoff, this is where the communication plan is shared with the program team, including expected deliverables used in the communication plan.

The kickoff sets the stage to ensure that everyone is aware of the end goal of the program and not just their respective project goals. Each project lead gets an idea of how their project may impact other projects in the program and each stakeholder has a chance to raise concerns and point out potential new stakeholders.

Leadership syncs

In Chapter 7, Stakeholder Management, we discussed the concept of leadership syncs to help coordinate across the projects. Not all programs will necessarily require the use of leadership syncs, but in cases where cross-project risks are involved, this is a valuable line of communication to get up-to-date information on the risks the program is tracking.

The leadership sync should flow very similarly to a sprint stand-up. This means going round-robin from TPM to TPM to get a quick status on each project, including any blockers or concerns. This continues the theme of the kickoff by not only informing you as the program TPM of the current status but also ensuring all project TPMs are aware of what each other is doing. If a new major issue is surfaced, address it after the round-robin is complete so those not impacted may leave. This concept, known as the parking lot, is also used in sprint stand-ups to ensure a quick and efficient use of everyone’s time.

Roles and responsibilities

As covered in Chapter 7, every project should have its own roles and responsibilities chart. In most cases, it is the same for every project. This is also true at the program level. Table 8.1 is a RACI chart for the Mercury program:

Step ID	Name	Program TPM	PM-T	Project TPM	Business
1	Program Planning	A(/R)	C	C	(R)
2	Project Status Report	A	C	R	C
3	Program Quarterly Business Review (QBR)	R/A	C	C	I

Table 8.1 – Program-level roles and responsibilities

The roles here are usually less than at the project level as there isn’t as much day-to-day work involved to track. However, it is still important for everyone to know their role in the management of the program. The program TPM is accountable for the program plan and depending on the involvement of the business, the responsibility may be with them, or on the TPM as well. This also outlines the project status reports and lists the project TPMs as responsible. Since a program exists, the accountability is with the program TPM. Lastly, the program’s QBR is owned by the program TPM and the project TPMs are consulted. Though this may seem obvious, it sets up the communication strategy for the program.

Communication strategies

Projects tend to use the weekly status report and Montly Business Reviwes (MBR) as their main ways to communicate with a wider audience. With a program, the QBR will become more prevalent as the impact of a program will be high enough to warrant meeting with senior leadership. This may mean that of all of the communication plans listed in Chapter 7, all of them will be utilized when working on a program.

As the program QBR builds on the project status reports, ensuring that every status report is on time and that the schedule of reports is set up properly falls on the program TPM. Figure 8.4 illustrates a reporting timeline for the Mercury program that allows for timely feedback to the program TPM.

Figure 8.4 – Aligning communication

As mentioned in Chapter 7, Stakeholder Management, the key to effortless communication is setting up a schedule that naturally feeds the right information into the right reports at the right time. Here, all project weekly reports are due prior to the QBR so that the QBR can have the most up-to-date information to draw from. Any clarifications needed can come about during leadership syncs or directly if urgent enough.

We’ve discussed the ways in which we can engage with our stakeholders, and how to pass along information. Next, let’s dive into when the program TPM may need to dive a bit deeper into a problem.

The art of intervention

The program TPM is a force multiplier to the project TPMs, just as the project TPMs are a force multiplier to the project team. In most cases, project-level issues are delegated to the project TPM and the program TPM is informed or consulted if necessary. However, cases may arise where more involvement from the program TPM is necessary.

The program TPM is accountable for everything in the program, and this is especially true for project risks that impact the program. If a risk is close to being realized, and thus has a high-risk score, or a risk has already been realized and risk strategies are underway, closer involvement of the program TPM is warranted. This is to facilitate faster communication and not a means to take control of the project TPM. Attending project-level stand-ups to understand the day-to-day or even hour-by-hour concerns will reduce communication times and allow the program TPM to coordinate cross-projects faster if the need arises.

To facilitate quick intervention, having the project sync on your calendar will allow you to easily drop in when needed and reduce the churn of getting the invite while an issue is at hand.

Intervention should rarely be a case of taking control, but rather offering a lending hand to resolve the issue more rapidly and help identify cross-project impacts and ensure good communication with all impacted stakeholders. If cross-project communication is not required, or the issue isn’t being reported at the program level, intervention is not required. That is the job of the project TPM.

Summary

In this chapter, we learned that scope is the set of requirements, and the impact is the group of people affected by the scope. We learned how to drive clarity at the program level by discerning the scope and impact of the requirements.

We then discussed how to use the scope and impact to define boundaries around the requirements. The boundaries can make up both the boundaries of a project and the deliverables within that project. This brings shape to the program.

After that, we learned that a program should be created when sufficient impact and scope dictate that multiple projects are needed to complete the goals. We also discussed how seeing patterns and goals across existing projects may align and warrant the creation of a program to track them as a whole.

Lastly, we discussed various aspects of tracking a program through program planning, risk management, and stakeholder management. Each of these key management areas builds on the management styles used at the project level but with increased scope and impact, necessitating some change in strategies. This includes planning the composition of the program as well as the program goals and deciding which risks need to be tracked at the program level. We also dove into the various communication techniques used in managing stakeholders, such as a kickoff meeting and leadership syncs, all used to facilitate the success of the projects in the program.

In Chapter 9, we’ll focus on the career paths available to a TPM that we first introduced in Chapter 1. We’ll cover a story of both a traditional career path and an unconventional career path from fellow TPMs in the tech industry.

We’ll then dive into more specifics on the two main branches of career paths for TPMs: the individual contributor path and the people manager path. Both will include insights from across the industry about where the paths can lead you as well as the types of challenges you may face.