7

Stakeholder Management

In this chapter, we’ll discuss the stakeholder management process from determining who your stakeholders are, to building a comprehensive communication plan. We’ll discuss what is different about stakeholder management in the tech industry and explore how the communication plan differs from program to project.

We’ll dive into stakeholder management in the following sections:

• Driving clarity in stakeholder management
• Managing stakeholders in a technology landscape
• Exploring the differences between a project and a program

Let’s get started!

Driving clarity in stakeholder management

Stakeholder management is the art of managing expectations. Each stakeholder has a different needed set of goals for the project, and their point of view will vary from others. The communication plan helps you draft ways to communicate that span the different needs of your stakeholders.

There are two aspects to setting up a good communication plan: defining the types of communication you need and discovering who your stakeholders are. We’ll cover the different types of communication first, as this is usually done only once at the company or team level and is reused from project to project, with only minor modifications. The list of stakeholders will vary for every project, depending on who the stakeholders are, and may require minor tweaks to the communication types.

Table 7.1 lists the different communication types that are common across the industry along with examples of recurrences, owners, and distribution methods:

Type	Goal	Recurrence	Owner	Distribution
Stand-up	Day-to-day collaboration and unblocking progress	Daily	SDE Lead	Sprint board, in-person updates, or email progress updates
Status Update	Milestone-level project status	Weekly (Every Tuesday)	Project TPM	Email
Monthly Business Review (MBR)	Leadership-level program status with key insights relevant to leadership	Monthly (3rd Wednesday of every month)	TPM Lead	Meeting and Email
Quarterly Business Review (QBR)	Senior leadership-level program status	Quarterly (3rd Wednesday of the 1st month per quarter)	PM-T Lead	Meeting and Email

Table 7.1 – Example communication plan

The names of the communication types listed here may not be the same at every company, but the concepts exist. As called out in Chapter 1, there are some instances where the written status report isn’t used at all; in those cases, the distribution method may not include sending an email, but the intent of the communication is largely the same. We’ll cover each communication type in more detail in the upcoming sections.

Stand-up

The stand-up type is used in agile, and even non-agile, settings where regular syncs are needed – often with software developers. The exact protocols used depend on the methodology being practiced, so I won’t go into detail on the specifics. However, in all cases, the takeaway for the TPM is knowing what the developers are actively engaged in and getting an up-to-date look at any blockers that they may have. Regardless of the presence of a scrum master or development manager, the TPM’s role here is to facilitate unblocking the development team, either directly or indirectly, by getting the right people involved.

The stand-up can also help you craft the status updates as you have the most current task progress as well as projected work for some amount of time (sprint, week, or other, depending on development methodology). Depending on team culture or the number of projects you are driving, you may not attend the stand-up, but an update should be produced in some form, either through updating a sprint board, or a written status summary from the developers.

Status update

Most projects will have some form of a status update, either in a written format or via a status meeting. The purpose here is to give a health check on the project at the moment in time with some projection as to the overall timeline health. The focus is on current and upcoming milestones, blockers, and risks with a high-risk score (in other words, risks that have some chance of being realized in the near future). To this end, this type of report tends to be more technical and is meant for the stakeholders that are actively working on the project itself in order to keep them apprised of what is going on around them.

The ownership of the status update is on the TPM driving the project and will include input from all stakeholders (developers, managers, PM-Ts, and so on) that are actively engaged in the project.

Monthly business review (MBR)

The MBR is a status report whose audience is the leadership. As such, the focus isn’t on the day-to-day work or issues but on the longer-term progress of the project, along with risks, issues, and milestones that are of higher impact on the project goal.

Beyond these basics, some MBRs contain learnings, highlights, lowlights, and other thought-leader types of information. Because of this, the format of an MBR tends to be company-specific, and sometimes leadership-specific, in the format and information that is expected to be included.

In all cases though, the intent is to update leadership on the longer-term and broader health of the project.

The distribution of an MBR is often in a meeting and may include an email depending on the format of the report that is used in the meeting. Some companies thrive on PowerPoint or similar slide-based tools to ingest this type of information that wouldn’t be conducive to an email, while others utilize a written report that can be used in a meeting as well as sent out.

The MBR is usually owned by the TPM, although co-ownership with a development manager, PM, or PM-T is also a possibility. This depends on the company culture and what type of resources the project has. Your company may prefer the PM-T to own this, but if one isn’t assigned to the project, it might fall back to the TPM to fill in. Filling in organizational gaps is part of what a TPM does best!

Quarterly business review (QBR)

The QBR builds on top of the MBR with a target audience of senior leadership. Not every project will have a need for a QBR, as it depends on the level of visibility the project has at that level in the company. If there is interest at the senior leadership level, a dedicated communication forum is needed to convey details with the right context.

The QBR combines all MBRs in the quarter (or the previous quarter, depending on timing) together into a single report with an emphasis on the end goals and major steps, victories, and misses in the time since the last QBR.

Communication timing

You may notice that each of these communication types builds upon the previous. The status report builds on the stand-ups, the MBR builds on the status report, and the QBR builds on the MBRs. As such, the timing of each is spaced out to allow for the collation of information into the next communication level up. In the example laid out in Table 7.1, the status reports are sent out on Tuesdays and the MBR is on the third Wednesday. So that third week allows for the weekly status report to be sent and then added into the MBR before it takes place. Since the QBR is a combination of previous MBRs, I run those on the same day of the month, and every third MBR will instead be a QBR.

This is just one way to handle timing and it will vary depending on project needs, and the behavior and expectations of your stakeholders. So, this will vary from project to project. However, I try to not send status updates on Fridays or Mondays. On Fridays, people will miss or gloss over the status before heading out for the long weekend, and in many countries, holidays land on a Monday, meaning you may not be in the office. Sending on Monday would mean that you would frequently have to send it on the next business day. Even if you stay on top of communication and let the stakeholders know, it will still feel inconsistent, so better to avoid it. These are personal guidelines that I feel are useful, but I have come across teams that require a specific day for status reports to be sent, so you’ll need to take team expectations into account.

Now that we’ve defined some potential communication channels, we need to decide which stakeholders will participate in which communication channel. To do this, we need to determine who the stakeholders are.

Defining your stakeholders

Finding your stakeholders and defining a communication plan is often depicted as a one-time, early-on process. However, like most processes in project and program management, it’s cyclical. Depending on the size of the project or company, doing this all upfront may be achievable in a single pass; however, as the project size and company size increase, this becomes something that you revisit often as new stakeholders are discovered. Here are a few ways you can go about finding out who your stakeholders are.

Requirements gathering and refinement is an opportunity to not only understand your requirements better but to determine who the requirements impact or involve, such as the owner of a service.

Talking with the stakeholders you’ve already identified will give you a different perspective on the requirements and impact. They might know of clients from their services that are impacted by the changes they must make that you aren’t aware of. Anyone impacted by the project, no matter how far down the chain or seemingly tangential they may seem, is a stakeholder.

During project execution, especially during low-level designs, details may come to light that highlight a stakeholder that you weren’t aware of. New developers may also come on and off the project, requiring updates to your list.

The more you drive clarity in your requirements, designs, and risks, the more clarity you’ll simultaneously drive in who your stakeholders are.

Stakeholder list

In Table 7.2, I’ve drafted a partial stakeholder list for the Mercury program:

Name	Alias	Department	Project	Role	Comm Type
Josh Teter	jteter	Mercury	All	TPM	N/A
Arun Ardibeddi	aardibeddi	Windows Team	Windows Rollout	SDM	MBR
Danielle Wednesday	dwednesday	Windows Team	Windows Rollout	SDE Lead	Stand-up
Bob Belkan	bbelkan	Windows Team	Windows Rollout	SDE	Stand-up
Vicky Preston	vpreston	Desktop Devices Division	Windows, macOS, Linux	VP	QBR
Cassette Santoro	csantoro	Windows Team	Windows Rollout	TPM	MBR
Artem Danyluk	adanyluk	Linux Team	Subsystem	TPM	MBR

Table 7.2 – Example stakeholder list for the Mercury program

This stakeholder list gives me enough information to know who the stakeholders are and what role they play in the project. For my projects, I create stakeholder email distribution lists for various communication needs and use this stakeholder table to ensure the lists stay updated.

This table is a snapshot of the program-level and Windows rollout project-level stakeholders. For each stakeholder, I list which communication type they will be a part of. The table lists each project as well as the program so that each project TPM can see which stakeholders are important for them as well as how they may overlap with other projects.

For instance, Vicky Preston is the VP in the desktop devices division, and her involvement is spread across the three desktop projects. So, the Windows TPM, Cassette Santoro, knows that Vicky Preston would be interested in any risks in the Windows project that may also impact those other desktop operating systems. The point is that your stakeholders can vary depending on the situation, sometimes by level (VPs may not care about a task blocker due to permission issues), but also on the context of the problem at hand and how far-reaching the problem may be.

As people come and go from the project, requirements are refined, and designs are finalized, you will keep this table up to date to ensure the right people are informed and consulted throughout the project.

Roles and responsibilities

Now that we have our stakeholders, the last component of the communication plan is the roles and responsibilities. Understanding expectations from every stakeholder in the project is important to ensure work gets done smoothly. It also helps inform natural escalation paths if a task is delayed or otherwise in trouble. Table 7.3 lists a portion of an example roles and responsibilities chart. Let’s look at it in more detail:

Step ID	Name	TPM	SDM	PM-T	Lead SDE	SDE	Bus.
1	Requirements refinement	A	C	C	C	C	R
2	Project planning	R and A	C	C	C	C	C
3	High-level design	C	C	C	A	R	I
4	Low-level design	C	C	C	A	R	I
5	Sprint planning	R or A	R or A	I	C	C	I
6	Daily stand-ups	C	C	I	A	R	I
7	Status report	R and A	C	C	C	I	I
8	MBR	R	C	A	C	(I)	I

Table 7.3 – RACI chart

There are many different styles of a roles and responsibilities chart, and like the communication plan chart, this is often static as it is referring to the role of the stakeholder, not the actual stakeholder. The style of chart used in this table is also referred to as a RACI (pronounced race-y) chart. It’s an acronym for the roles available: responsible, accountable, consult, and inform.

The responsible role is where the person or group is responsible for the step or activity. It does not mean that they are the sole contributors or owners but are the ones responsible for its delivery. For instance, the TPM may be responsible for delivering the MBR (Step 8) but will receive input from the rest of the project team.

The accountable role is similar to the responsible role, but the accountable party is who ultimately deals with the consequences of something not getting done. In this example chart, the Lead SDE is accountable for the daily stand-ups – a sort of scrum master role. They are where questions go if a stand-up does not occur or if there are questions or concerns. Another example to differentiate responsible and accountable is that the TPM is accountable for meeting a milestone, but the developers are responsible for doing the development to get to the milestone.

Tip on varying responsibilities

There can be cases where a single person is both responsible and accountable for a single deliverable. As Table 7.3 shows, the TPM is often both responsible and accountable for the project plan as well as the status report.

In other cases, the responsibility may shift depending on the project size or team dynamics. In cases where a service team runs its own sprint, the SDM may be accountable for the deliverables and the TPM is responsible for requesting the right work gets done. In some cases, the TPM may be running the sprint and is thus both responsible and accountable.

The consult role identifies the different roles that should be involved in a step but are not accountable or responsible for its completion. For example, developers are consulted during sprint planning because they help determine task estimation and capacity, but they do not own the sprint plan itself. A similar role, called participate, can take the place of consult or even leave both to differentiate a participating SME versus a non-SME.

The inform role is for all parties that only need to know of the outcome of a particular activity. In the example here, the business teams are informed about the designs, sprints, and work being done. The mechanism for informing can be the status report or meetings and does not need to be dedicated to each task.

If you have a large number of stakeholders that span many different disciplines and aspects of the project, an additional role of optional can be added, or using parenthesis around Inform or Consult to indicate optional, as you can see in Step 8 for the SDE. This is in lieu of leaving the cell in the chart blank. It allows for a stakeholder to be optional for a particular activity where their active participation is not required but they may choose to participate if it makes sense in the particular situation.

Exploring the dos and don’ts for status reports

There are many types of communication that exist, but the most common and influential is the project status report. This may be in a written form, in a meeting, or via a slide deck, but the purpose and content should largely be the same across these formats. I’ll be using a written format as it is common and the easiest to work with in a book, but the concepts are translatable to whichever format you or your company use.

First up, here’s a quick inventory of what items should be included in a status report:

• Executive summary: This is a high-level summary of the progress that is easy to digest and clearly states the trajectory of the project. The traffic-light status is included here, as well as the items contributing to the current traffic-light color the project is on.
• Project milestones: There are two schools of thought on milestones. They are either a list of predefined phases or steps that every project goes through, such as implementation, testing, deployment, launch, and post-launch, or are used as shorthand for the deliverables of the project. I use the former as it provides good metrics that can be used across all projects (such as how often a project’s deployment takes longer than expected) and separate this from the feature deliverables.
• Feature deliverables: This is a list of deliverables, usually synonymous with the top-level tasks (also called epic tasks) in a task list. This lets the stakeholders know when to expect a specific feature or group of features and varies with every project.
• Open and recently resolved issues: This is a list of issues that are currently being tracked. These are separate from the known tasks and the known risks but will include realized risks as they are currently being dealt with. I usually have a separate table where I move resolved items once they have been shown during a single status report as being resolved to reduce the size of individual tables.
• Risk log: This is a log of the risks as discussed in Chapter 6. If the number of risks is large, I usually just include the high-risk items in the status report with a link to the full risk log.
• Contact information: In case of issues or concerns, a reader of the status needs to know who to contact.
• Project description: Not everyone that is a stakeholder may remember what the project is about, especially in large organizations and email distribution lists, so including a blurb on the project helps set the stage.
• A glossary of terms: This won’t make or break a status report, but if it is included, you will receive praise. Tech companies are large, and the number of three-letter acronyms (TLAs) that are in use can quickly become daunting. Just as not everyone will know the project, not everyone knows all of the terms being used. Be kind and don’t assume.

Now that we know the basic elements that should go into a status report, here’s a list of things to consider that turn an okay status report into a great one:

• Every action must have an owner and date
• Define your traffic light and stick to it
• A non-green status must have a path to green
• Keep important details above the fold
• Format and grammar matter

Let’s go through each of these in detail.

Every action must have an owner and date

The number one rule for any status is that for every action, an owner and date must be identified. This helps ensure the right people are accountable for actions and that the stakeholders know when to expect a resolution. This conveys that you, as the TPM, are in control of the situation and are proactively engaged in all issues.

In some cases, an action item may not have a date at the time of a status report; in these cases, a date should still be supplied as a date for a date (DFD). This lets people know when to expect a concrete plan of action.

Define your traffic light and stick to it

A traffic light, in this case, is a convention of using red, yellow, and green to denote different conditions of your project. It’s easy to understand as the meaning of an actual traffic light closely matches how it is used in project management. That being said, every company is different, and even within a company, the thoughts behind how each should be used can be different. With different cultures as well as people originally from different companies involved, preconceived notions can cause confusion. For this reason, I define my usage of the traffic light status to make it clear why a project is a particular status. Let’s look at the definitions I use.

Green

The project is meeting current milestones and is on track to deliver on schedule. Some companies may need to include on budget in this status. So long as the currently agreed upon resourcing and scoping can get the project to the scheduled date, I consider it green.

Yellow

There are active issues that may impact the ability to deliver on schedule. It is not definite that the date will be missed at this stage, but it requires changes to get back on track.

For a yellow status, there is ambiguity still – it is a cautionary status and lets your stakeholders know that you are on top of the situation and being proactive to keep the project from going red.

As a note, the issues here should rarely be new or unexpected. The project risk log should include all risks that may become realized. Ideally, the yellow status will be short-lived as risks have defined strategies to deal with them.

Life does happen, and things come up, but keep this ideal state in mind so that when unexpected issues come up, you can have a retrospective to see whether they could have been expected, and then add them to your risk register.

Red

A red status means there is no current way to meet the scheduled delivery with the current resourcing and defined work. This is the status that I’ve seen the most contention in its definition in my career. If a project, left unchanged, cannot meet the due date, it is red. This does not mean that the date is impossible to meet but there is no ambiguity at this point that something must change.

Contentious topic – When to change the status color

As a TPM, my preference is always transparency on status, even when it makes you or another stakeholder look bad. It’s better to be honest and upfront than to sow distrust by reporting a watermelon status (green on the outside, but red on the inside)!

There are also cases where an event occurs, such as a risk being realized, where it may not be perfectly clear as to whether a status should change. I try and use the status definitions as my guiding principle: if a risk was successfully mitigated and didn’t impact your ability to deliver, then the status can stay green (or whatever status you are on, as it does not shift the status).

Sometimes a problem occurs and is resolved in-between status reports, but a stakeholder may wish to change the status to flag that an issue happened. This can get very political and may require some negotiation but if you use transparency as your goal, you will find a path that works for your circumstance.

A non-green status must have a path to green

Both yellow and red statuses must have a path to green (PTG). This is the set of actions that need to take place in order to get a project back on track. Just as with every other action, these require an owner and a date.

For a yellow status, the PTG is often well understood with no ambiguity, which is why the project is yellow and not red. However, there are cases where the issue’s impact isn’t well understood and requires some investigation to determine the impact and the right path forward. In these cases, yellow may be more appropriate because it isn’t yet clear whether there is a path forward. Also, DFD may be required instead of a date because the action is pending investigation. It may be tempting to put the date of the investigation’s conclusion, but the date should reference when the status will shift to green, which isn’t known.

For a red status, the PTG is often exploratory. Most paths look to understand the impact so that the right action can be determined, first focusing on scope and resourcing. You might look at adding more resources to reduce calendar time, you might de-scope or reprioritize requirements to different milestones or phases of a project. Worst case, moving the due date may be the only way to get a project on track. What this looks like depends on your company and the ability for the project’s due date to change. External drivers like a customer promise or regulation may make that option not feasible.

Keep important details above the fold

Above the fold is a concept in media that refers to information that is immediately available to the reader. The term comes from the printed newspaper where the page is folded in half on the newsstand. This made the top half of the front page visible at a glance, so this was reserved for the most important headline. The practice is still in use in newspapers today and has moved on to digital media where the content available without needing to scroll is considered to be above the fold.

The reasoning behind the delineation is that the content above the fold is the only content that is guaranteed to reach your audience. The concept is often applied to executive leadership at a company where the general consensus is that leadership will read the content above the fold and then stop reading. Even in this case, there is no full guarantee that your stakeholders will receive the information, or read it, but this puts the most critical information at the top and increases the chance of it being seen.

This means that your most important information – project status, PTG, and summary of status – must always be first and foremost in a status. Senior leadership may not need to know all of the details of how something is being accomplished, but they need to know that the project team is being proactive and has the situation under control.

Once you are below the fold, the information becomes more granular, with updates on the sprint schedule, project burndown, and risk log. This is where the team leads and development managers will get the most value in knowing what the day-to-day is like in the project.

At the bottom, you place information that is static or near static, such as the project description, project contact information, and the communication plan. The communication plan will technically change every status, as it conveys when the next status will be sent and may mention related communication dates for project MBRs, QBRs, and a stand-up schedule. Even so, I usually have this at the bottom as it is expected information and not pertinent to the status of the project. However, for critical projects, I often repeat the next status date above the fold as well.

Format and grammar matter

A consistent format that is easy to follow and understand is important. The more time that the reader has to spend in understanding what you are trying to say, the less they may spend reading in the future and just send out emails or meetings to discuss the status. When working with new stakeholders, impromptu meetings may occur as they don’t understand your writing style or the full context of the project. They may simply have a different style or way to consume information. Listen to your stakeholders and work to find ways to format your status to make your stakeholders comfortable with how the status is presented – it will save a lot of time during moments of high-stress movement in the project to not have to go over misunderstandings because the status format didn’t make sense. In the same vein, grammar matters – to an extent. I’m not suggesting that perfect Honors-English-level grammar is required, but clear and concise sentences and correct word choice can also improve comprehension among stakeholders.

Pro tip – Format ahead of time

Once I have built my project plan and found my stakeholders, I spend some time working on the format of my communications. In the same way that you line up communication schedules to have an easy flow of information, you can format your status reports to make it easier to refresh things such as milestone tables and current issues and risks. Spending time upfront to find a format that reduces day-to-day work can quickly add up in times of high churn in a project and allow you to put your effort towards more critical work.

The following is an example status report, broken up into two pictures: Figure 7.1 with information that is above the fold, and Figure 7.2 with information that is below the fold:

Figure 7.1 – Status report above the fold

The information above the fold is the most pertinent to understanding the state of the project and no additional information is needed. This includes the status color and target date for the status, the summary of where the project is at, and the PTG. Since the project isn’t green, the status conveys why the status is yellow and the PTG with an owner – Cassette Santoro as the project TPM – and the date, February 23rd, 2022. The risk log doesn’t always have to be above the fold, but in this case, it conveys high-risk items that can be relevant for upcoming status reports that shift back to yellow based on these risks. If other more important things are going on in the project, they’ll take priority here.

Figure 7.2 shows the remainder of the status report and represents the data below the fold:

Figure 7.2 – Status report below the fold

In this example, I chose a project burndown to convey the week-by-week status of the project. The dip in actual versus planned here coincides with the delay called out in this report. Over time, it will act as a visual reminder of the delays incurred. A milestone or feature list table can also be useful here. The Project Contacts section is static in this case and gives context as to who to reach out to in the project. Lastly, the communication schedule lists the next weekly status, the next MBR, and the next QBR. These dates all follow the dates laid out in the communication plan in Table 7.1.

We’ve explored the artifacts used in stakeholder management and how and when to use them, and explored the content of a good status report. Next, we’ll see how managing stakeholders in a tech world can offer up unique challenges.

Managing stakeholders in a technology landscape

Most of how you manage stakeholders is not unique – all disciplines need a stakeholder list, a communication plan, and roles and responsibilities. However, there are some aspects to working in a technology company that can add some additional constraints to how we move forward. We’ll take a look at three aspects of how managing stakeholders can be different while working in a tech environment:

• Communication systems
• Tooling
• Technical and non-technical stakeholders

Communication systems

Working for a technology company means you get to work with cutting-edge software; however, this can also be a burden. During the pandemic, many companies scrambled to update and add additional ways to communicate while workers were remote. Companies have since transitioned into a seemingly permanent hybrid model of working from home and the office, and it’s hovering around the 50/50 ratio – at least in the US.

With all of these rapid changes from fully in-person to fully remote, and now hybrid, the technology landscape of available ways to communicate has grown with a myriad of messaging systems such as Slack, Microsoft Teams, Amazon Chime, and Zoom, as well as other productivity tools such as Quip, OneNote, and Evernote. In some cases, a single company may be using multiple systems that accomplish the same or overlapping purposes. This may mean that not everyone is at the same level as to what forms of communication work for them or their team. So, adding to the list of stakeholders, their roles, and which communication types are appropriate for them, you may find that you need to track what systems are available for each stakeholder.

If your company follows a standard here, then this can be a one-time exercise, but if you are like many tech companies right now, knowing which tools to use can save a lot of churn as you move from phase to phase in the project.

Tooling

When using tools to manage a project or program, you’ll want to look into how a given tool can help in distributing the various communication plans that you need. Do this as early on in the project as you can to ensure its benefits help you as early as possible. Some tools offer built-in dashboards that can be used to build a real-time status of a project showing upcoming milestones, feature dates, overall status, and more. These can be great tools by reducing the need to craft a status, but it does mean that status is immediately and always available. If something is going wrong in a project, being able to control how the update is consumed by stakeholders can be a valuable asset to help manage expectations and keep panic and escalations at bay.

If you do use a tool though, you’ll also need to verify permissions to ensure that everyone you expect to have access does, in fact, have access. On a related note, you’ll also want to check default permissions in the cases where there are non-stakeholders that shouldn’t have access to ensure they cannot get in.

Technical versus non-technical stakeholders

In the tech world, you are building technology, but you are also in a business that needs to make money. As such, you will run into plenty of non-technical teams that are your stakeholders. In most cases, there is a business team that is driving the work being done. This highlights your superpower of the communication bridge between these worlds. If you have a lot of non-technical stakeholders, an improvised communication plan may be needed to ensure you have a format that will fit their understanding.

To do this well, you need to know your audience while drafting a particular communication. The issues you need to go over might be highly technical, but they also need to be distilled to a level of simplification so that non-technical people will be able to grasp the issue at hand. I have found that the exercise of re-articulating a problem for a different audience can bring more clarity to the problem as it forces you to look at it from a different perspective.

Exploring the differences between a project and a program

For stakeholder management and communication plans, as with most key areas of management, the difference between managing a project and a program is about scale. The number of stakeholders increases and the number of concurrent communication plans that are being utilized increases. Instead of a single stand-up, you may have at least one per project, the same goes for status reports and possibly MBRs, depending on the complexity of the project.

This isn’t to say that you, as the TPM running the program, are directly responsible for each of these communications, but you are accountable to them. If a project is falling behind on statuses, or the TPM isn’t meeting with stakeholders enough to keep them in the loop, as the program manager, you are accountable to keep the project TPM on track. Luckily, there are some additional tools you can use to help keep the program’s stakeholders happy and communications flowing freely.

Scheduling for natural accountability

In Table 7.1, I stepped out the communication schedule to allow lower-level communications, such as a weekly status report, to flow into the MBR meeting. It reduces the time running around to get up-to-date information. The same concept can be used at a program level; the level of status you care about will just start out at a higher level. Ensure each project’s MBR is published or takes place prior to the MBR for the program. If the project doesn’t need that level of visibility, then just ensure the weekly status reports are published on a day of the week that is earlier than the program MBR to give you adequate time to collate information. This may lead to a case where an issue’s status has changed between the status report and the MBR, in which case, updating the appropriate stakeholders out-of-band is important to ensure that there are no unexpected updates.

The same can be done at the program level, as the program’s status report will include details from each project, and ensuring the project status reports are sent out prior to the program will ensure a natural flow of information.

Leadership syncs

In a project, there are multiple ways you get information from daily stand-ups with your development team, to project management syncs including development managers, PM-Ts, and key stakeholders. At the program level, you still need avenues of information, but the information you need will usually be at a higher level. As you will have multiple project teams to work with, a leadership sync – akin to a scrum of scrums, where the scrum masters from various scrums teams meet to discuss each scrum’s sprint – is a concise way to get project information passed on. Bringing each project TPM into a combined forum not only keeps you informed but gives each TPM a chance to understand what else is going on in the program.

The sync should flow very similarly to a sprint stand-up. Going round robin from TPM to TPM to get a quick status on the project including any blockers or concerns is all that is needed. No doubt, if there were major issues, you would already be aware prior to this sync, so it’s really to ensure everyone is aware of the high-level progress being made as well as to ensure all cross-team impacts are well understood by everyone.

Projects tend to use the weekly status report and MBRs 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 I listed in this chapter, all of them will be utilized when working on a program.

Summary

In this chapter, we covered the artifacts used in stakeholder management such as the communication plan, stakeholder list, and roles and responsibilities. We looked at how the different communication types allow you to convey information in a specific way based on the needs of your stakeholders. We also discussed how you can discover who your stakeholders are.

We learned what elements go into making a good status report and how clear and concise language and status definitions reduce churn during the project when trying to convey a status.

We discussed the types of challenges you can face in the tech world with a highly diverse set of communication tools, along with the varying levels of technically minded stakeholders you need to communicate with.

Lastly, we explored how stakeholder management differs at the program level and how to utilize leadership syncs to collate information across multiple projects.

In Chapter 8, we’ll wrap up the section on program and project management core principles by discussing how to effectively manage a program. We’ll discuss when and how to define a program and how to track the program across all open projects.