04 Project Execution: Running the Project

Course overview

This course will delve into the execution and closing phases of the project life cycle. You will learn what
aspects of a project to track and how to track them. You will also learn how to effectively manage and
communicate changes, dependencies, and risks. As you explore quality management, you will learn how to
measure customer satisfaction and implement continuous improvement and process improvement
techniques. Next, you will examine how to prioritize data, how to use data to inform your decision-making,
and how to effectively present that data. Then, you will strengthen your leadership skills as you study the
stages of team development and how to manage team dynamics. After that, you will discover tools that
provide effective project team communication, how to organize and facilitate meetings, and how to
effectively communicate project status updates. Finally, you will examine the steps of the project closing
process and how to create and share project closing documentation. Current Google project managers will
continue to instruct and provide you with hands-on approaches for accomplishing these tasks while
showing you the best project management tools and resources for the job.

Choose the right tracking method for your project

So far, you've learned about the importance of tracking project progress. You’ve also reviewed some of the
different tracking methods used by project managers, like project plans, Gantt and Burndown charts, and
Roadmaps. This reading will explore and compare these popular tracking methods in more detail so you can
feel more confident choosing the best method for your projects.
Gantt charts
The Gantt chart is one of the most popular tracking methods and can be used for all types of projects. Gantt
charts typically live in your project plan and are updated as the project progresses.
Gantt charts are useful for:
• Helping a team stay on schedule
• Projects with lots of tasks, dependencies, and milestones
• Projects with large teams, because ownership and responsibilities are explicitly laid out visually
Asana, one of the work management software tools featured in this certification, has useful resources for
getting started with Gantt charts. Practice working with Gantt charts on your own with a free Asana trial or
by downloading a free Gantt chart template from Google Sheets or Microsoft Excel.
A guide to mapping your project timelines
Maybe you’ve heard the term Gantt chart used around the workplace or in a project kickoff meeting. The
problem is, you’re not quite sure what that is, how it helps with project management, or how to make one.
While these charts can get quite complex, the basics aren’t hard to nail. In our guide, you’ll get a clear
breakdown of what Gantt charts are, when to use them, tips for creating one, and more.
What is a Gantt chart?
A Gantt chart is a horizontal bar chart used to illustrate the timeline of a project and its tasks. This gives your
team a visual overview of project information like your project schedule, upcoming milestones, and overall
project timeline.
Each horizontal bar within the chart represents a task, and the length of each bar represents the amount of
time that step or task will take. When you zoom out to look at the full picture, these charts give project
managers and project teams an overview of what work needs to get done, who’s doing it, and when.
Gantt charts typically include the following components:
• Tasks
• Task start date
• Task duration
• Task end date
• Task owner
• Milestones
Most Gantt charts also offer additional context about how project tasks connect to each other, who they’re
assigned to, and what important deadlines and milestones are coming up. With a dynamic timeline, team
members have at-a-glance insight into what they’re responsible for and how their work impacts the project
as a whole.
History of the Gantt chart
Polish engineer Karol Adamiecki created the first iteration of a Gantt chart in 1896, which he called the
harmonogram. Adamiecki published his findings in Russian and Poli
sh, which made them difficult to access in English-speaking countries. In 1910, American mechanical
engineer Henry Gantt independently popularized a similar chart in the United States, which he devised in
order to represent how long factory workers spent on a given task. These two systems have since been
merged to create what we know today as the modern-day Gantt chart.
After tracking factory employees’ tasks, these charts became a popular way to track project schedules.
Originally, these charts were drawn on paper, which meant that whenever the schedule changed, the charts
had to be redrawn. Later, project managers used pieces of paper or blocks to represent the task bars, so
they could move them around as needed.
Gantt chart example
Studying this example of a Gantt chart is helpful for understanding how to map out a project lifecycle
effectively.
• Initial steps: The project starts with the "Identify key stakeholders" activity, which lays the
groundwork for all other tasks that follow.
• Planning phase and project launch: Tasks like "Map out dependencies" are scheduled alongside
"Define project goals," due by December 15 to indicate tasks that can occur simultaneously. While
the "Kick off project" action establishes a key milestone and planning deadline.
• Task management: Tasks such as "Measure performance against goals" and "Assign action items"
suggest a cycle of continuous evaluation and task distribution.
• Finalizing and reporting: Activities that help team members and stakeholders recognize the steps
needed as the project culminates to a conclusion include "Prepare presentation" and "Present to
leadership." While the final phases of the project are represented by tasks like "Communicate
results" and "Complete project," which concentrate on project wrap-up and outcome
communication.
While every chart will look different, this example will help you grasp the fundamentals of task sequencing
and time management critical for any successful project.
What is a Gantt chart used for?
While you can use a timeline view for a variety of projects and programs, it’s helpful to understand what
these charts are commonly used for and why:
• Build and manage complex projects: The bigger the project, the more tasks there are to manage.
Gantt charts can help project managers when scheduling projects by allowing them to easily
visualize a project and break it down into smaller tasks.
• Monitor task dependencies: Project delays happen. Visualizing work in a timeline helps project
managers automate task dependencies, which ensures that the next phase or task doesn’t start until
the previous one has finished.
• Keep track of project progress: Track progress and milestones, so you can quickly adjust your project
plan if needed.
1. Mapping out a marketing campaign
Larger marketing campaigns require a lot of team collaboration and coordination—and it’s easy to lose track
of all the moving pieces. That's why it's so important to visualize all of your work as a sequence of tasks with
assignees and details about how long each initiative will take. This way, teams don’t just know who’s
responsible for what, but also how their work impacts others or the larger goal.
2. Outlining deliverables for a client
When you show clients a timeline of all of your deliverables, you can clearly set expectations around how
long each will take. By outlining plans this way, you can give stakeholders and clients a clear idea of the
scope of your deliverables, and how long each one will take to accomplish—so they won’t just know when
you’re delivering an item, but also the timeframe in which you’ll be working on it.
3. Planning a product launch
For product launches, you might use a timeline to map out the entire plan, from ideation to launch and
beyond. By visualizing this in a timeline, you’re then able to more easily spot conflicts before you begin, see
dependencies between steps, and get a clear overview of everything that’s happening leading up to the
launch and when.
Parts of a gantt chart
Have you ever wondered what makes up a Gantt chart and how each component contributes to effective
project management? Understanding the anatomy of a Gantt chart can help you leverage its full potential in
organizing and visualizing your project timelines. Here are the essential components of a Gantt chart, each
with an example:
 • Task list: A vertical list of project tasks on the left side of the chart, serving as the foundation for
plotting the project timeline. For example, a project to develop a new website might include tasks
like "design homepage," "write content," and "code website."
• Task bars: Horizontal bars that represent the duration of each task, showing the start and end dates.
For instance, the task bar for "design homepage" might span two weeks in April, visually indicating
its planned duration.
• Milestones: Markers that signify key dates or achievements within the project timeline. An example
is marking the completion of the website prototype as a milestone, which indicates a significant
achievement in the project's progress.
• Dependencies: Lines or arrows that connect tasks to indicate the sequence in which tasks must
occur. If "write content" cannot start until "design homepage" is complete, a dependency arrow
would connect these tasks.
• Critical path: Highlights the longest sequence of dependent tasks that determine the project's
duration. In our website project, the critical path might include tasks such as "code website," directly
impacting the project's end date.
• Resource allocation: Information on which resources are assigned to specific tasks is often included
alongside the task bars. An example would be assigning a specific web designer to the "design
homepage" task.
• Dates and time scale: The top of the chart features a calendar or time scale that tasks and
milestones are plotted against to provide a temporal context. For example, the entire project might
be set against a six-month time scale from April to September. This helps stakeholders visualize the
project timeline at a glance.
Each of these components plays an important role in providing a comprehensive overview of the project's
scope, duration, and dependencies.
How to make a Gantt chart
While no two Gantt charts look exactly alike, there are some basic steps you’ll need to take to get you off
the ground, no matter what project management software you use.
1. Define the time range
Your Gantt chart should be a project with a start and end date. Think of this chart as a way to represent your
project over a timeline—your timeline needs a beginning and end point.
Tip: While all projects should have a clear end point, it’s likely that you’ll have some additional follow-up
tasks with your client after crossing the finish line, so you may need to add in some dates after the fact for
these items.
2. Add tasks with start and end dates
In order to effectively visualize your to-dos, make sure each individual task has a specified beginning and
end date—this way they can be easily visualized on a bar chart. If you don’t add task start dates, then your
tasks will show up as moments in time, which might be harder to visualize within the bigger picture.
Tip: Clear start and end dates also make it easy for your team to understand when they should begin
working on a task. By doing this, they won't be unprepared for a big project that is due tomorrow.
3. Clarify dependencies
With large projects, it’s natural to have some tasks that can’t get started until other tasks are complete. To
keep the project running smoothly and every team on the same page, you can
visualize dependencies between tasks in your Gantt chart.
In the example below, the ability to publish the product blog post is dependent on reviewing the blog post,
which in itself is dependent on drafting the blog post. Similarly, the team can’t launch the email campaign
until it’s been drafted. Drawing dependencies between these tasks will help the next team stay up-to-date
on what they’re able to start working on in their phase of the project.
4. Pinpoint milestones
Unlike most tasks in a Gantt chart, milestones are fixed points in time. Think of them as checkpoints to
signify that large pieces of work are complete. They help your team know what to prioritize and can be
great moments of celebration when they’re completed.
Tip: Milestones often take place at the end of project phases, but there’s no one single way to create
milestones for your team, especially since every team and project looks different. Examples of milestones
might look like:
• Meetings
• Project approvals
• Task starting points
• Mid-phase check ins
• Phase completion points
5. Modify work as plans change
Plans will inevitably change, which is why your Gantt chart software should be able to adapt to your needs.
Look for a tool that allows you to easily drag and drop tasks, and that automatically updates dependencies
in real time. That way, you can always keep your project on track, even as plans shift.

Gantt chart best practices

When teams first start using Gantt charts, they often encounter a few common hurdles. These challenges
can lead to miscommunication, resource misallocation, and ultimately, project delays.
However, with the right best practices in place, Gantt charts become powerful tools for improving project
visibility and team coordination. The following Gantt chart best practices are designed not just as tips but as
solutions to these common initial stumbling blocks.
Determine the critical path
Establishing the critical path of a project timeline is key to understanding the sequence of tasks that directly
affect the project's completion date. This practice involves identifying which tasks are critical (i.e., any delay
in these tasks will delay the project) and which tasks have float (i.e., can be delayed without affecting the
project timeline).
By focusing on the critical path, project managers can allocate resources more effectively and prioritize tasks
that are essential for on-time project completion.
Example
In a software development project, tasks such as requirement gathering, design, coding, testing, and
deployment are mapped on a Gantt chart to identify the critical path. It reveals that delays in the coding
phase directly affect testing and deployment timelines. However, tasks like documentation might have some
float and can be adjusted if coding needs more time. This insight enables project managers to prioritize
coding and allocate extra resources if necessary, ensuring the project remains on schedule despite potential
bottlenecks.
Use a work breakdown structure
A work breakdown structure (WBS) is a fundamental step in project planning that involves dividing a project
into manageable tasks and subtasks. When applied to a Gantt chart, a WBS helps organize tasks visually,
making it easier to monitor progress and allocate resources efficiently.
Example
Consider a project to develop a new website. By using a WBS, you would break down the project into
smaller tasks such as design, content creation, and coding. Each task would then be represented on the
Gantt chart timeline, giving team members a clear overview of the project scope that helps them
understand their responsibilities and deadlines.
Identify task dependencies
Understanding task dependencies is crucial for creating an accurate Gantt chart. Task dependencies indicate
the relationship between tasks and subtasks, showing which tasks must be completed before others can
begin. This ensures that the project flows logically and resources are allocated appropriately.
Example
For a construction project involving the building of a structure, it's essential to complete foundational
subtasks before advancing to subsequent phases, such as erecting walls. The Gantt chart efficiently maps
out these work dependencies to ensure contractors realize the importance of completing the foundation to
avoid scheduling conflicts and inefficient resource use.
Allocate resources wisely
Resource allocation involves assigning the appropriate resources, including team members, equipment, and
budget, to specific tasks. A Gantt chart with integrated resource allocation allows project managers to see
not only when tasks are scheduled but also how resources are distributed across the project.
Example
For an event planning project, a Gantt chart can show that while one team works on venue setup, another is
arranging catering. Task visualization ensures that resources are not overstretched and that tasks are
adequately staffed. This helps prevent burnout and ensures that all project aspects are covered.
Monitor progress regularly
A Gantt chart is not a set-and-forget tool; it requires regular updates to reflect the project's current status.
Incorporating dashboards into this practice provides a centralized, real-time view of project progress, task
completion, and resource allocation. Dashboards complement Gantt charts by offering an at-a-glance
summary of key project metrics, enabling project managers and team members to quickly assess project
health and make informed decisions.
Example
During a software development sprint in an agile project, if a sprint is behind, a dashboard updated
alongside the Gantt chart quickly highlights delays and resource issues. This allows for immediate
adjustments to make certain the project stays on track without extensive meetings or email updates. This
streamlined approach keeps everyone aligned and responsive to changes.
Pros and cons of Gantt charts
While these charts can be helpful, they aren’t always the best for every project. To better understand if this
type of project chart is right for you and your project vs. a timeline, here are a few considerations before
you leap into creating one.
Pros
• Get a bird’s-eye view of your project timeline: A Gantt chart is a roadmap of your project. This tool
helps you track when you should reach each milestone—and whether or not you’re on track to do
so. This type of timeline view offers a bird’s-eye perspective on your work, making it a particularly
useful tool to present to senior management or clients for a quick overview.
• See how tasks relate to each other: By adding start and finish dates to each task and drawing
dependencies, you can visualize how each piece of work affects another. This helps you identify
problems and fix dependency conflicts before you start.
• Improve team resource management: Adding an owner to each piece of work can help you see
who’s doing what and when to better manage individual workloads. Since everything is plotted out
sequentially, you’ll be able to see if an individual teammate or team has too much to do at one time,
then reassign or reschedule tasks as needed.
Cons
• More time consuming to set up: Setting up a Gantt chart can be time consuming, especially if you’re
using a Microsoft Excel spreadsheet. Even if you use a template, you might still have to make
adjustments to customize it to your team’s specific needs.
• Difficult to manage the project in the same place you planned it: Traditional Gantt charts are most
useful in the planning phase of a project. Once you’ve mapped out your work, you’ll likely need to
 use a different tool or platform to manage day-to-day activities, making it hard to know where your
team’s single source of truth is.
• Adding more details gets messy: Adding context around deadlines and collaborators to your project
plan on a Gantt chart can turn it from easy-to-view map to overwhelming sheet of chaos.

Roadmaps

Roadmaps are another common tracking method. Like Gantt charts, Roadmaps also track both individual
and project progress toward milestones. However, Roadmaps are best suited for tracking big milestones in
your project.
Roadmaps are useful for:
• High-level tracking of large milestones. Roadmaps outline the project as a whole and provide an
overall snapshot of key points—just like an actual roadmap contains points of interest and mile
markers.
• Illustrating to your team or key stakeholders how a project should evolve over time
Roadmaps can be built using different tools. You can create a Roadmap in a document (like this example).
Smartsheet has useful resources for getting started with Roadmaps. Practice working with Roadmaps on
your own with a free Smartsheet trial or by downloading this Roadmap template created with Google
Sheets.
What Is an Agile Product Roadmap?
An Agile product roadmap is a tool that details your company’s plan for achieving a strategic product vision.
It also explains how a specific product is likely to change, align with stakeholders, and bring in ROI.
Product owners use this type of roadmap to outline projected product functionality and identify potential
release dates. An Agile product roadmap can be more challenging than traditional product roadmaps
because, in an Agile environment, change happens quickly and frequently, so the roadmap must be able to
withstand these changes and evolve with the project.
What Does An Agile Product Roadmap Look Like?
An Agile product roadmap looks different from a traditional product roadmap and is usually organized by
themes, key goals and objectives, and new features.
An Agile product roadmap is typically not linear or based on specific inputs and outputs. Instead, it is
iterative and plots potential updates against more general themes and company-wide objectives and key
results (OKRs) and goals.
If you’re looking for specific, preformatted templates to help get you started, visit our article with a wide
variety of Agile product roadmap templates.
Traditional Product Roadmap vs. Agile Product Roadmap
A traditional product roadmap is a static, sequential diagram that lists short-term inputs that will achieve a
long-term output and communicate each step of the project plan.
By contrast, an Agile product roadmap is not static, but instead provides an iterative method to track
projects and communicate about overall strategy, rather than the specific steps or outputs associated with
the plan.
According to Janna Bastow, CEO and Co-Founder of ProdPad, a product management and roadmapping
software for product people, “Traditional product roadmaps map out a list of features or deliverables
against a timeline, whereas an Agile product roadmap allows the team to be more flexible. Instead of being
date- or feature-driven, an Agile roadmap is usually centered around a series of objectives.”
Additionally, she says, “Because an Agile roadmap isn’t locked to dates, but rather to goals, teams that work
in an Agile way tend to be more experimentation-driven and outperform delivery-led teams, in terms of
hitting outcomes.”
Traditional roadmaps are typically not ideal for Agile projects, as these projects are constantly evolving
while the team completes new sprints and different iterations. Instead, Agile product roadmaps focus on
outcomes rather than outputs; they are designed to showcase themes and project epics, rather than
specific features or steps.
When to Use a Traditional vs. an Agile Product Roadmap
An Agile product roadmap is best used for iterative projects that are objective-driven, while a traditional
product roadmap is most helpful for linear projects focused on specific deliverables and deadlines.
Refer to the comparison chart below to note the differences between the two types of roadmaps, so you
can decide which one is right for your use case.

Essential Elements of an Agile Product Roadmap

An Agile product roadmap includes many of the same elements as a traditional product roadmap, such as a
timeline, specific product features, and a status key for in-progress, planned, and approved projects. It also
has such components as the following:
• Strategic Themes: Instead of specific outputs, an Agile product roadmap focuses on specific themes
that represent the larger product and business strategies that will help direct the roadmap. There
may be multiple themes within a single product roadmap (for example, “Expand market share in the
Asia-Pacific region” or “Eliminate wait time when downloading our product in order to retain
customers”).
• Features: These can either be features you’re building or a hierarchy of broader feature themes
around which you will plan your features.
• Business Goals: Strategic business goals and OKRs typically drive an Agile product roadmap. This
gives team members an idea of where to focus their effort to help them achieve these goals, which
 can either be product- or business-specific (for example, “Launch a new external dashboard” or
“Increase active users by 25 percent”).
How Do You Create an Agile Product Roadmap?
To create the most effective product roadmap in an Agile environment, product owners will first need to
outline new product functionality and releases, as well as take into account resourcing and engineering
constraints, value propositions, budget, and competition.
Steps in the Agile Roadmapping Process

There are many important steps in the Agile roadmapping process to ensure you create, implement, and
review your roadmap appropriately. Follow the steps below to start creating your best, most effective Agile
product roadmap.
1. Focus on Product Goals: Before you begin drafting your product roadmap, identify all business
objectives and key performance indicators (KPIs) associated with your product goals, such as
acquiring new customers or increasing product engagement. The roadmap should be driven by the
goals of your product, rather than by the specific features required to achieve those goals (usually,
you’ll only have three to five features per goal).
2. Understand Your Product Vision: Once you understand your product goals, start to nail down the
specific vision of your product and how it will deliver value to your customers. Your product vision
should be concise and compelling. It should also be appropriately high-level; should any unforeseen
roadblocks occur, you can adjust it easily without harming your overall goals.

Bastow cautions: “Don’t just jump straight into creating a whole roadmap. Make sure you have
defined and clarified your product vision with your team first, as this provides your roadmap with
direction. Once you have a vision, work with your team to identify your objectives. After all, if you
don’t know what success looks like, you won’t know if the work on your roadmap is actually
working.”
3. Do the Necessary Prep Work: Prep work includes identifying the product strategy, which is the path
you will take to realize your product vision, as well as the steps in your actionable roadmap. Create a
product vision board to help brainstorm strategy ideas and facilitate roadmap creation. Remember,
the roadmap is a living document that will ultimately change, so anticipate those changes and allow
for lots of flexibility within your vision and corresponding roadmap.
4. Talk to Your Customers: To get the best idea of how to meet your customers needs — and
ultimately, how you should plan your product roadmap — hold candid conversations with your
customers and gain insight into their wants and needs. These conversations should take place with
both internal customers and end users.
5. Create Product Themes: Once you’ve done your prep work and talked to customers, make a
comprehensive list of the problems you’re trying to solve. These issues will then become the main
themes around which you organize your product roadmap. As you come up with these themes,
prioritize them based on the KPIs and product vision you identified in earlier steps.

Bastow reiterates the importance of this step: “[Your product roadmap] should be made up of
initiatives or, rather, problems that could be solved in order to meet your product vision. Think of
these initiatives as stepping stones — if you step on them in the right order, you’ll maximize your
chances of hitting the objectives you outlined.”
6. Determine If and How to Incorporate Time: Ask yourself if time is relevant to your product
roadmap. Typically, with internal-facing roadmaps, it’s more common to share dates so team
members can track task execution and communicate progress to cross-functional teams, such as
marketing and sales. On external-facing roadmaps, you might not want to show timelines, as doing
so could tie you to those dates. Regardless, avoid committing to specific dates throughout the
delivery of your product so as to avoid setting unrealistic expectations for both internal and external
stakeholders.
7. Determine Cost: As with any project, it’s important to determine resourcing and the labor costs,
materials, licenses, facilities, and infrastructure involved in your product development, in order to
come up with an accurate projected cost.
8. Tailor Your Roadmap to Specific Audiences: Roadmaps are supposed to communicate and align
stakeholders and team members, so pay attention to your audience and know what’s important to
 each audience. For example, you may want to show a high-level overview to your executive team,
but use a more granular roadmap showing tasks and epics with your development team.
9. Secure Buy-In: As you develop your roadmap, collaborate often with key stakeholders and your
development team, so everyone feels like they have a say and are striving toward the same goals. If
possible, leverage a Scrum master to facilitate this sort of communication among team members.
10. Understand Your Product Marketing Techniques and Timelines: Pay close attention to the features
that your product marketing team announces to the market, and maintain a user-centric outlook to
collect knowledge on what the market is looking for. Keep up with the wants and needs of your users
and update your roadmap accordingly.
11. Tell a Coherent Story: As a whole, your roadmap should tell a story about how you see your product
evolving and iterating over time. The roadmap should include specific goals that build upon each
other, with breakdowns into specific, measurable goals that you can look back on to measure
progress and success.
12. Keep It Simple: Keep your roadmap as simple and concise as possible, and avoid adding too many
details. Stick only to the goals that are most important to your product development, and avoid
showing specific user stories on the roadmap (instead, you may note those stories in the product
backlog).
13. Identify Key Metrics: Make sure that every goal on your roadmap is measurable so you can report
on its success. For example, one of your goals could be to retain active users, meaning that you could
look back on your product roadmap and identify whether your new developments affected customer
retainment.
14. Review and Adjust the Roadmap Regularly: Check in regularly with your Agile product roadmap and
review it with your stakeholders and development team as often as needed. Keep the roadmap up to
date with your product strategy, and ensure that it always reflects your organization’s larger
priorities. Since you’re working in an Agile environment, it’s important to be flexible with your plans
and stay on top of any changes that affect your roadmap.
The Agile Product Roadmap Lifecycle
An Agile product roadmap should follow the lifecycle of your product. You should update and change it as
your product roadmap evolves.
Agile Product Roadmap Starter Kit
This Agile product roadmap starter kit offers you everything you need to begin assembling your first Agile
roadmap, including a free template, a step-by-step guide on how to create a roadmap, and best practice tips
and tricks.
Agile product roadmap experts emphasize the need to focus on problems you want to solve with your
roadmap and the importance of relying on your team to help you achieve your goals.
Other expert tips include the following:
1. Don’t Assume Your First Roadmap Will Be Perfect: “Your first roadmap will not be perfect — far
from it,” says Bastow. “As a matter of fact, I like to think of the roadmap as a prototype, but for your
product strategy. Prototypes are a way to test assumptions and check that you’re on the right track.
Designers prototype their work all the time. The goal isn’t to create the perfect version straight
away, but to present your assumptions and use the prototype to encourage a healthy discussion
around the ideas presented.”
2. Focus on the Key Problems You Want to Solve: The goal of your roadmap is to map out how to solve
the problems you identified with your team. Bastow says, “Your first ‘roadmap’ can be as simple as a
few sticky notes that outline some key problem areas. Put them in the order you think is best, based
on what you currently know about the business and market.”
3. Collaborate: As mentioned previously, your first Agile product roadmap won’t be perfect, and it
won’t stand a chance of passing the sniff test if you try to create it all on your own. According to
Bastow, once you create your roadmap, “take that roadmap to other stakeholders: a colleague, a
trusted customer, or anyone with a different perspective. They will help fill in any gaps, and point out
where your assumptions might be wrong. Perhaps you learn that you need to change the order of
your steps, or you need to consider a new problem on your roadmap.”
 4. Add More Details as You Iterate: Once you’ve come up with an initial roadmap, you can start to
flesh out the details and identify specific areas you want to address. “The next version of your
roadmap would be more detailed and more robust,” says Bastow. “After several rounds of feedback,
you’ll have a lot more confidence in your roadmap, even though it probably looks nothing like the
first version.”
Why Agile Teams Need an Agile Product Roadmap
It’s important to connect the work your team is doing back to a specific roadmap in order to ensure your
team is on track and to provide context to each of the tasks within a roadmap.
Additionally, as project tools, product and project roadmaps provide people with a high-level overview of
what’s coming down the line and how to prepare, whether for the budget or resources. Specifically in an
Agile environment, a project roadmap helps to maintain visibility during the many iterations and changes
that occur as an Agile project evolves and progresses.
An Agile roadmap also can help you identify top priorities and the themes associated with them, which can
enable both you and your team to focus your time and resources on the highest-impact items.
Lastly, teams need to leverage a roadmap as a critical communication tool — to help relay the product
strategy internally as well as cross-functionally. Doing so helps get stakeholder buy-in by giving everyone a
view into project expectations.
The Benefits of Agile Product Roadmaps
You can find many benefits associated with an Agile-specific product roadmap, including the following:
• Improved team confidence in leadership’s ability to make better, more strategic decisions
• Better insurance on a product’s arrival to market by focusing on short-term iterations rather than
long-term problems
• Improved ability to answer customer’s needs by talking with the customer and getting a firsthand
look at their new requests from the product
• Better balance between short-term results, such as product releases, and long-term results, such as
overall business objectives
• According to Bastow, the ability to prioritize your roadmap and associated tasks “at the problem
level, not at the idea level”
How to Use an Agile Product Roadmap
The best way to use an Agile product roadmap is as a high-level overview of projected product releases and
improvements.
Executives can use the roadmap to gain better insight into what’s coming down the line, how work is
progressing, and where roadblocks might occur.
Development teams can use the roadmap to actually execute on the work, such as product updates and
launches. The roadmap will also give these team members better insight into the projected launch date of
each release, which in turn gives each person the ability to weigh in on how the roadmap should change as
the project progresses and evolves.
All in all, an Agile product roadmap should be shared cross-functionally so that all stakeholders and team
members are looped in on what’s going on from start to finish.
What Does the Agile Roadmapping Process Look Like in Practice?
There are many use cases for Agile product roadmaps, and each process looks a little different, depending
on the business objectives, themes, and goals. Below, find examples of different types of Agile product
roadmaps for various teams in an organization.
• Leadership Roadmap: This type of roadmap is aimed at giving senior leadership and key
stakeholders a high-level overview of the product team’s projects and progress. It provides insight
into the overall product direction, with emphasis on additional key information, such as market
share, market opportunities, and budget. These types of roadmaps are also known as objective
timeline roadmaps.
• Company Roadmap: A company roadmap focuses on sharing specific product details with cross-
functional teams, such as sales and customer success, to offer them insight into the expected
timelines for product releases and new launches. This allows them to set expectations with existing
customers and deliver on customers’ wants and needs. These roadmaps are also referred to
as release plans or release timeline roadmaps.
• Delivery-Focused Roadmap: This type of roadmap includes more specific timelines for the
development teams that are directly involved in the product development. It helps to communicate
objectives, areas of product features, the status of product development, and resourcing
information. These are very similar to sprint plans and feature timeline roadmaps.
• Customer-Focused Roadmap: Use a customer-focused roadmap to identify the features that your
customers care about the most (and, therefore, want the product team to develop). This roadmap
helps to communicate upcoming features for customer-facing audiences that sales, customer
success, and marketing teams can announce. It is sometimes referred to as a general release plan or
a now-next-later roadmap.
Examples of Agile Product Roadmaps
Below, you’ll find examples of specific Agile product roadmaps that you can use for a variety of use cases,
from developing a release plan to assigning a now-next-later status to product features and iterations.

Name of Agile
Product Description of Roadmap
Roadmap

Release Plan This type of roadmap provides an execution-level plan that specifically identifies
how you will deliver work and the associated timeline, if applicable. A release plan
provides a high-level overview of future product releases, which makes it ideal for
roadmaps that have a fixed scope, but are not necessarily time-bound.
 Sprint Plan A sprint plan focuses on specific product deliveries and is most helpful for sprint
planning. Generally, product teams use sprint plans to sync their development
teams with the upcoming work and plan sprints over a predetermined timeline so
they can properly fund and resource each sprint appropriately.

Now-Next- Use this type of roadmap to communicate task priority levels within a certain
Later timeframe. This way, teams can see the most important tasks in the “now” and
Roadmap “next” table; the “later” table shows features that might be coming down the line.

Kanban A Kanban roadmap is delivery-focused and intended specifically for development

Roadmap teams. This roadmap provides product teams with specific initiations, which are
grouped into buckets for planning, in-progress, and completed states, as well as
the product backlog.

Feature This output-driven roadmap includes a predetermined timeline for each individual
Timeline feature, which gives teams a high-level overview of how work is progressing and
Roadmap what features are set to come next. This roadmap specifically helps align
development teams with key stakeholders, so everyone stays up to date on feature
progress against specific timelines.

Objectives This roadmap offers a more specific, zoomed-in look at each objective within a
Timeline roadmap on a predetermined timeline. An objectives timeline roadmap aligns all
Roadmap parts of the organization with overall product direction and helps to communicate
the product strategy and goals for the next few weeks, months, and quarters.

How and When to Update Your Agile Product Roadmap

You should regularly review your product roadmap, usually every one to three months, depending on the
total projected length of your project, to update it as the project evolves.
Update your roadmap as often as your product plans change — keep an eye on it and make your roadmap
as collaborative as possible. This also ensures that your product teams don’t become overly obsessed with
the dates on the roadmap since dates shift and plans evolve many times in Agile environments.
Best Practices and Strategies for Agile Product Roadmaps
As you create your Agile product roadmap, remember to think of your roadmap in terms of problems you
want to solve rather than new ideas you want to explore.
Additionally, remind yourself of these best practices as you plan and iterate on your product roadmap:
• Focus on the Bigger Picture: Remain committed to the larger picture you want to build with your
roadmap, rather than on specific tasks or product developments.
 • Stay Focused on the Problem You’re Trying to Solve, and Don’t Waver: According to Bastow, doing
so will “ensure that you’re solving the right problems first, and not falling prey to all the usual biases
(like noisy customers or demanding stakeholders).”
• Don’t Treat Your Roadmap Like a Release Plan: As Bastow notes, “A release plan is a tactical, short-
term planning document that’s useful for a specific audience: usually those closest to the
engineering cycles. A roadmap is a completely different sort of artifact. It’s a strategic
communication document that shows the path you’re looking to take to meet your product vision
and allows you to sense-check your assumptions with stakeholders. It’s designed to be flexible and
have a different level of granularity than your release plan, as well as a different purpose and set of
stakeholders, so keep these documents separate.”

Burndown charts

Burndown charts are typically used by Agile Scrum teams. Burndown charts reveal how quickly your team is
working by displaying how much work is left and how much time remains to complete the work. The main
uses of a Burndown chart are to keep the project team on top of targeted completion dates and make them
aware of scope creep if it occurs. The chart should be displayed so everyone can see it and needs to be
updated regularly in order to be effective.
Burndown charts are useful for:
• Projects that require a detailed review of tasks
• Projects where finishing on time is the top priority
*Note: If you'd like to learn about Agile and Scrum, which are popular project management approaches,
check out Course 5 of this certificate, Agile Project Management.
A Burndown chart helps you, as a project manager, understand how your team works and what influences
their ability to complete tasks on time. This way, you can address issues right away, before they become
major problems. They also help you plan more efficiently for the next project by identifying potential
problem areas.
Jira is a work management software tool that has useful resources for getting started with Burndown charts.
Practice working with Burndown charts on your own with a free Jira trial or by downloading this Burndown
chart template created with Google Sheets.

Burndown Chart: What Is It & How to Use One for Agile

Time is a constraint that applies to any project, particularly to dynamic, agile projects. While some
industries are more time-sensitive than others, all industries have projects that incur many changes along
the way.
A burndown chart helps agile project management teams keep track of what’s been done, what needs to be
done and how much time is left in the project. While a burndown chart is traditionally a visual tool, it can
also act as a list that outlines the work to be done and what percentage of it is complete.
What Is a Burndown Chart?
A burndown chart is a project management chart that shows how quickly a team is working through a
customer’s user stories. This agile tool captures the description of a feature from an end-user perspective
and shows the total effort against the amount of work for each iteration or agile sprint.
The quantity of work remaining appears on a vertical axis while the time that’s passed since the beginning
of the project is placed horizontally on the chart, showing the past and the future. The burndown chart is
displayed so everyone on the agile project management team can see it and updated regularly for accuracy.
Types of Burndown Chart
There are two burndown chart variants: a sprint burndown and a product burndown. A sprint burndown is
used for work remaining in the iteration while a product burndown illustrates the work remaining for the
entire project plan.
Components of a Burndown Chart
Although the specifics can vary, it’s common to see the below sections of a burndown chart.
Axes
A burndown chart has two axes, x and y. The horizontal axis represents time while the vertical axis displays
user story points. The rightmost point of the chart indicates the start of a project or agile sprint while the
leftmost point shows its end.
Ideal Work Remaining Line
As its name suggests, the ideal work remaining line indicates the remaining work that a team has at a
specific point of the project or sprint under ideal conditions. Project managers use past data to estimate this
baseline and draft a straight line across the burndown chart. The ideal work remaining line should always
have a negative slope.
Actual Work Remaining Line
The actual work remaining line indicates the remaining work a team has at any point of the project timeline.
Unlike the ideal work remaining line, this is not an estimate, but rather a realistic depiction of the team’s
performance. The line is drawn as the team progresses and completes user stories. Actual work remaining
lines are usually not straight as teams work at different paces as projects are completed.
Burndown Chart vs. Burnup Chart
A burndown chart and a burnup chart are very similar—they have the same components, achieve the same
purpose and are used for agile project management. But there’s one major difference.
On one hand, the burndown chart keeps track of the remaining work by removing user stories from the
vertical axis as they’re completed while the burnup chart adds user stories to the vertical axis as they get
done.
How to Read a Burndown Chart
The burndown chart has several points. There’s an x-axis, which is the project or sprint timeline. The y-axis is
the work that needs to be completed in the project. The story point estimates for the work that remains are
represented by this axis.

The project starting point is the farthest point to the left of the chart and occurs on day zero of the project
or iteration. The project endpoint is farthest to the right and marks the final day of the project or iteration.
Ideal Work Remaining Line
There is an ideal work remaining line which is a straight line connecting the starting and ending points. This
line represents the sum of estimates for all tasks that need to be completed, or in other words, the scope of
the project. At the endpoint, the ideal line crosses the x-axis and shows there is no work left to be done.
This line is based on estimates and therefore is not always accurate.
Actual Work Remaining Line
The actual work remaining line shows the actual work that remains in the project or iteration. At the
beginning of the project execution phase, the actual work remaining and the ideal work remaining are the
same, but as the project or iteration progresses, the actual work line fluctuates above and below the ideal
work line. Each day, a new point is added to this line until the project or iteration is completed to make sure
it’s as accurate as possible.
If the actual work line is above the ideal work line, it means there’s more work left than originally thought.
In other words, the project is behind schedule. However, if the actual work line is below the ideal work line,
there is less work left than originally predicted and the project is ahead of schedule.

How to Use a Burndown Chart in Agile & Scrum

Agile project management relies on agile sprints to plan and execute projects. These sprints are short
iterations of work where a team accomplishes specific goals that are initially set during a sprint
planning meeting. Burndown charts are ideal for agile project managers as they allow them to keep track of
the work remaining, compare performance against a baseline and quickly determine whether they’re
behind schedule. Here are some examples of how to use a burndown chart to help you manage an agile or
scrum project.
• Create a work management baseline to compare planned vs. actual work
• Complete a gap analysis based on discrepancies
• Get information for future sprint planning meetings
• Reallocate resources and manage tasks to complete sprints on time
What Are the Benefits of a Burndown Chart?
• The obvious benefit of a burndown chart is that it provides an updated status report on the progress
of the project. Having a visual representation of this key data keeps everyone on the same page.
• Displaying a burndown chart prominently for all to see keeps everyone involved and encourages the
team to deal with issues before they evolve into problems. It should be the focal point of the
workspace so that it helps direct conversation toward the project and its progress.
• The simplicity of the burndown chart is also extremely helpful as it outlines the velocity history of
the project. Velocity is an agile term that means the total effort estimates associated with user
stories that were completed during an iteration.
What Are the Limitations of a Burndown Chart?
The burndown chart doesn’t reveal everything. For example, it only shows the number of story points that
have been completed. The burndown chart doesn’t show any changes, for example, in the scope of work as
measured by the total points in the backlog.
As a result, it can be hard to tell if changes in the burndown chart are due to completed backlog items or
because of an increase or decrease in story points. Having a burnup chart resolves this problem by having a
separate line in the graph for the overall backlog size.
However, neither a burndown nor a burnup chart offers any indication of which product backlog items have
been completed. While a burndown chart might show progress, it may not represent whether the team is
working on the right tasks. These charts are often a way to show trends rather than represent whether the
team is delivering the right product backlog items. If you’d like to prioritize project tasks, you may use an
Eisenhower matrix instead.
It Relies on Good Estimates
Another issue with burndown charts revolves around the accuracy of the ideal work line. Whether the
actual work line is above or below the ideal work line depends on the accuracy of the original time
estimates for the tasks. If a team is overestimating time requirements, progress appears on track or ahead
of schedule. But if the team is underestimating the time requirements, it will appear that they’re behind
schedule.
There’s a way to respond to this issue—incorporating an efficiency factor into the burndown chart. After the
first iteration of a project, the efficiency factor is recalculated to allow for more accuracy.

Project status reports

In this lesson, you are learning to identify and compare various types of tracking methods. This reading will
cover project status reports and how you can use them to track and communicate common project
elements in a snapshot.
Key components of a project status report
A project status report gives an overview of all of the project’s common elements and summarizes them in a
snapshot. It is an efficient communication tool to convey the latest status in one place for the team and
stakeholders.
Most status reports contain the following components:
• Project name: The project name should be specific to the purpose of the project so that the overall
goal of the project can be understood at-a-glance.
• Date: You will create project status reports many times during the course of a project’s
implementation phase. Reports can be created weekly or monthly—it all depends on the
stakeholders’ needs and pace of the project. Adding the date to each status report acts as a
reference point for your audience and also creates a history log of the project’s status over time.
• Summary: The summary condenses the project’s goals, schedule, highlights, and lowlights in one
central place for easy stakeholder visibility. Usually, the summary section will be followed by, or
grouped with, the timeline summary and the overall project status.
• Status: As you can imagine, status is a crucial piece. The status of the project illustrates your actual
progress versus your planned progress. In project management, a common way to depict this is
through RAG (red, amber, green), or Red-Yellow-Green, status reporting. RAG follows a traffic light
pattern to indicate progress and status. Red indicates that there are issues that need resolution and
that the project may be delayed or go significantly over budget. Amber/Yellow means that there are
potential issues with schedule or budget, but that the issues can likely be resolved with corrective
actions. And green means the schedule and budget are doing fine and that the project is on track.
You can use RAG to indicate the overall project status, as well as milestone status. Every project team
and stakeholder may have a slightly different perspective on what the colors mean and how urgent it
 is to escalate issues when they see an amber/yellow or red status, so it’s important to make sure
everyone understands what the different color statuses mean for your project.
• Milestones and tasks: A summary of the project’s major milestones thus far and current tasks helps
the team and stakeholders easily visualize the progress of those elements. In a project plan, you will
typically depict the tasks and milestones as ‘not started,’ ‘in progress’ or ‘completed’ at an item-by-
item level. But, in the project status report, it is common to summarize these items into two
categories to better communicate the status. You’ll use key accomplishments to detail what has
happened, and upcoming to detail what big milestones you will accomplish next.
• Issues: The issues include your project's current roadblocks and potential risks. Status reports are an
important opportunity to set expectations with your stakeholders. If your project status is red or
amber, you can flag what is preventing you from being where you planned to be. You can also use
this opportunity to state your plan to get the project back to green, and ask for any resources or help
you may need to do so. You will learn more about communicating big risks and issues in the
upcoming videos.
Project status report types
With those key elements in mind, you can format your report in a variety of ways depending on your
audience and what you need to communicate.
If you need to share a status report with your team for a project that contains multiple layers of complexity,
it may be best to format the report in a spreadsheet in order to keep track of all the moving parts.
If you simply need to communicate updates to senior stakeholders, your status report may be best
formatted as a slideshow, like the one below, containing only an overview of the most key points.

Key takeaways
To recap, project status reports are a powerful tool to:
• Improve and simplify communication across the team.
• Keep everyone, including key stakeholders, informed.
• Request more resources and support (if needed).
• Create structure and transparency by recording the project status in a centralized place.

Case study: Using risk management tools

Thus far, you have learned that risk management—the process of identifying, evaluating, and addressing
potential risks and issues that could impact a project—is a core part of a project manager's role. You also
learned about techniques to identify potential risks and address their effects, including creating risk
registers and building mitigation plans. In the following case study, we will imagine how a project manager
might utilize these tools.

The project: Paw Snacks Puppy Treats

Paw Snacks is an online retailer of tasty and nutritious pet treats. Over the course of three years, the
business has grown from a small startup to a 350-person organization. Paw Snacks wants to expand its
offerings even further by adding a new line of treats for puppies.

The issue

Six weeks before the new product line is scheduled to debut, Naja, the project manager leading the launch,
receives a frantic phone call from a manager at the commercial bakery hired to produce the treats. The
bakery manager informs Naja that the bone-shaped cookie cutters required to shape the treats have not
yet arrived. Naja knows that baking needs to start the following day in order to stay on schedule for the
launch.
Naja thanks the bakery manager for the warning and asks her teammate, Abe, to call the cookie cutter
manufacturer to check on the status of their order. Abe learns that the order is delayed due to a product
shortage and that the cookie cutters are now expected to arrive at the bakery two days after the original
expected delivery date.

Naja recognizes that this delay threatens her team’s ability to launch their product on time. Even worse, her
team doesn’t have the option to push the launch date, since the Paw Snacks marketing team has already
purchased nonrefundable advertising placements for the day of the launch. Luckily, Naja and her team are
already prepared for an issue like this one.

Planning for risks ahead of time

Months earlier, long before the team started work on the project, Naja and her team brainstormed
potential risks that could impact the project. They created a risk register, a table or chart that contains a list
of risks and is often paired with a probability and impact matrix. During the process, the team determined
that a delay in the cookie cutter order had a medium probability of occurring and would result in a high
impact on the project. Naja added the risk to the risk register and assigned Abe to create a mitigation plan,
which outlines steps to decrease the chances of a risk occurring or decrease the impact of a risk if it does
occur. This plan would indicate how the team would handle an issue if it were to materialize. The mitigation
plan was then approved by the project sponsor and other stakeholders.

Managing the issue

Now that the cookie cutter issue has occurred, Naja and Abe consult the mitigation plan for this particular
risk. In this case, Abe identified two options for handling the risk: The first option is to work with the bakery
to slightly increase the number of treats produced in order to make up for the two days they have lost due
to the cookie cutter delay. The second option is to place an order with a second bakery to help speed up
the pace of production. Naja and Abe discuss the two plans and settle on option one to avoid the work of
bringing in a second bakery.

Before moving ahead with the plan, Naja and Abe meet to brainstorm potential risks associated with the
new plan. Together, they determine that a smaller order of dog treats will likely have a minor—but
manageable—impact on the organization’s projected growth for 2021. They determine that the best course
of action is to accept the risk to avoid delaying the project further. To ensure that the project stakeholders
are aware of and comfortable with this change, Naja requests a meeting with her project sponsor to
communicate the plan, outline the minor risk to projected growth, and recommend accepting the risk. The
sponsor agrees and approves Naja’s new plan.

Naja tasks Abe with communicating the adjusted plan to the bakery manager. Though baking begins two
days behind schedule, Naja’s new plan helps ensure that the team is prepared to launch the new line on
time.
 Pro tip: While the term mitigation plan is used more often in project management, you may also hear the
term contingency plan. These terms are often used interchangeably, but there are some key differences.
A mitigation plan is a planned risk response strategy. If a project manager is able to identify the potential
known risks that impact any of the key project parameters (schedule, cost, or scope), they should make a
plan to mitigate those risks early in the project. A contingency plan, on the other hand, is mostly related
to funds the project manager keeps aside (outside of the planned project budget ) to support any of
these known risk response plans if they go beyond the planned amount or to manage any unforeseen
risks during execution.

Key takeaway

In this case study, early risk management planning enabled Naja to act quickly when an issue presented
itself at a pivotal time during the project execution phase.

By consulting an existing mitigation plan and weighing two options for moving forward, Naja and Abe
were able to make an informed decision about the best path forward. Naja also communicated the
growth-related risks associated with the plan to the project sponsor in a timely fashion.

As you manage projects of your own, issues will come up again and again. When you do the heavy lifting
of risk management planning before starting work on the project, you will be better equipped to
respond to problems quickly.

Writing an effective escalation email

In this lesson, you are learning how to communicate risks and changes to your team and stakeholders. In the
previous video, you were introduced to escalation: the process of enlisting the help of higher level project
leadership or management to remove an obstacle, clarify or reinforce priorities, and validate next steps.
There are many ways to escalate a risk, and it is important to set escalation standards with your
stakeholders before beginning work on a project. In this reading, we will focus on the escalation email, and
go over best practices for writing one.
Escalation email best practices
All projects—even those managed by experienced project managers—occasionally have problems. Your role
as the project manager is to help resolve problems and remove barriers that prevent your team from
making progress toward your goals. While many problems might be small enough to resolve within your
core team, other problems—like a major change in your budget or timeline—may need to be brought to
stakeholders for a final decision. Detailing these problems, their potential impact, and the support you need
in a clear and direct email to your audience can be an effective communication tool.
Effective escalation emails:
• Maintain a friendly tone
• State your connection to the project
 • Explain the problem
• Explain the consequences
• Make a request
Let’s discuss these five keys to writing a strong escalation email.
Maintain a friendly tone
When drafting an escalation email, you may feel tempted to get straight to the point, especially when
dealing with a stressful and time-sensitive problem. But keep in mind that it is important to address issues
with grace. Consider opening your email with a simple show of goodwill, such as “I hope you’re doing well.”
When describing the issue, aim for a blameless tone. Above all, keep the email friendly and professional.
After all, you are asking for the recipient’s help. Be sure to close your email by thanking the recipient for
their time.
State your connection to the project
Introduce yourself early in the email if you have less familiarity with the project stakeholders. Be sure to
clearly state your name, role, and relationship to the project. This helps the reader understand why you are
reaching out. Keep your introduction brief and to the point—a single sentence should suffice. If you know
the person on the receiving end of the escalation email, you can simply reinforce your responsibility on the
project before getting straight to the problem.
Explain the problem
Once you greet your recipient and briefly introduce yourself, explain the issue at hand. Clearly state the
problem you need to solve. Provide enough context for the reader to understand the issue, but aim to keep
your message as concise as possible. Avoid long, dense paragraphs that may obscure your message and
tempt the reader to skim.
Explain the consequences
After explaining the problem, clearly outline the consequences. Describe specifically how this issue is
negatively impacting the project or how it has the potential to negatively impact the project later in the
project timeline. Again, keep your explanation concise and your tone friendly.
Propose a course of action and make a request
This is the central piece of a strong escalation email. In this section, you propose a solution (or solutions)
and state what you need from the recipient. A thoughtful solution accompanied by a clear request lets the
recipient know how they can help and moves you toward a resolution.
Putting it all together
Let’s see how these best practices come together to form a strong escalation email. In the scenario that
prompts the email, Sayid, a project manager from a company that sells gift baskets, is having a quality
control issue with one of the items in a line of holiday baskets. If the issue is not rectified soon, the product
launch will have to be delayed and the company will lose money. In the annotated email example below,
Sayid explains the issue to his internal stakeholders and requests a meeting with them.
 To: knelson@graciousgiftbaskets.com, gabrielmendoza@graciousgiftbaskets.com [Your stakeholders]

Subject: [Action required] Decision needed to make progress on Holiday Scents project

Hi Karen and Gabriel,

[Keep it friendly and state your connection to the project] I hope you are doing well. As you may know, I have
been managing our Holiday Scents product line, which is scheduled to launch in October.

[Explain the problem] I would like to bring an issue to your attention. The baskets in this product line will include
scented candles, and we placed an order with Candlemakers, Inc. for 5,000 candles to be delivered to the
warehouse by Friday to prepare for our first customer shipment. To date, we have received 3,000 of the 5,000
candles. Unfortunately, many of the candles we have received so far fail to meet our quality standards. The
packaging is damaged, or the candles themselves are broken.

[Explain the consequences] This puts our customer satisfaction rates at risk. Failure to meet the quality
requirements for the candles by Friday will result in postponing the product launch by three weeks. If this delay
occurs, we will incur an additional cost of $20,000 because we will need to order a new shipment of candles and
review the quality standards of each to ensure that they meet our contractual agreements.

[Propose a course of action and make a request] I have sourced two backup suppliers that have five-star reviews
and a track record of on-time deliveries. I propose we meet with them both right away so we can onboard one of
them quickly. That way, we can avoid major delays. Are you available for a meeting tomorrow to discuss options
and come to an agreement on next steps? Please respond with the times that work best for you.

Thank you in advance for your consideration and insight,

Sayid

End of email

Key takeaway
In this example, Sayid maintains a friendly tone, clearly explains the problem and its potential
consequences, and makes a clear request of the recipients. The email is also brief and to the point.
To recap, effective escalation emails apply these five best practices:
• Maintain a friendly tone
• State your connection to the project
• Explain the problem
• Explain the consequences
• Make a request
Escalation is a useful skill for solving problems quickly, and sending a strong escalation email that applies
these best practices can help get your team the help it needs.
 Recap: Quality management concepts

You are learning to define quality in your projects. Quality is when the outlined requirements for the
deliverable are fulfilled and meet or exceed the needs and expectations of customers.
In this reading, we’ll review the four main concepts of quality management we discussed in the previous
video: quality standards, quality planning, quality assurance, and quality control.
• Quality standards provide requirements, specifications, or guidelines that can be used to ensure
that products, processes, or services are fit for achieving the desired outcome. These standards must
be met in order for the product, process, or service to be considered successful by the organization
and the customer. You will set quality standards with your team and your customer at the beginning
of your project. Well-defined standards lead to less rework and schedule delays throughout your
project.
• Quality planning involves the actions of you or your team to establish and conduct a process for
identifying and determining exactly which standards of quality are relevant to the project as a whole
and how to satisfy them. During this process, you'll plan the procedures to achieve the quality
standards for your project.
• Quality assurance, or QA, is a review process that evaluates whether the project is moving toward
delivering a high-quality service or product. It includes regular audits to confirm that everything is
going to plan and that the necessary procedures are being followed. Quality assurance helps you
make sure that you and your customers are getting the exact product you contracted for.
• Quality control, or QC, involves monitoring project results and delivery to determine if they are
meeting desired results. It includes the techniques that are used to ensure quality standards are
maintained when a problem is identified. Quality control is a subset of quality assurance activities.
While QA seeks to prevent defects before they occur, QC aims to identify defects after they have
happened and also entails taking corrective action to resolve these issues.

User acceptance testing: Goals, best practices, and management

In a previous video, you learned about different ways to measure customer satisfaction, including feedback
surveys and user acceptance testing (UAT). This reading will focus on why conducting UAT is essential to the
successful launch of any product, service, or software. We will also discuss some best practices for effective
UAT and how to manage the feedback you receive.
The goals of UAT
To recap, UAT is testing that helps a business make sure that a product, service, or process works for its
users. The main objectives of UAT are to:
 • Demonstrate that the product, service, or process is behaving in expected ways in real-world
scenarios.
• Show that the product, service, or process is working as intended.
• Identify issues that need to be addressed before project completion.
UAT simulates real-world conditions, so when the feature works as intended during the testing process, you
can be more confident that your product, service, or process will work properly once it is launched. It allows
a project team to gather detailed information about how users interact with a product, service, or process.
UAT helps the team answer such questions as: Do users recognize its purpose and uses? How do they
interact with it? How much time do users take to interact with it? Do they notice all of its features? Is the
product, service, or process accessible to everyone? UAT also allows the project team to record information
about how users feel about their experience with a product, service, or process. Through testing, the team
can learn about the emotions it evokes, identities it conveys, appeal it holds, and so on.
Best practices for effective UAT
In order to achieve these goals, UAT needs to be conducted thoughtfully. These best practices can help you
administer effective UAT:
• Define and write down your acceptance criteria. Acceptance criteria are pre-established standards
or requirements that a product, service, or process must meet. Write down these requirements for
each item that you intend to test. For example, if your project is to create a new employee handbook
for your small business, you may set acceptance criteria that the handbook must be a digital PDF
that is accessible on mobile devices and desktop.
• Create the test cases for each item that you are testing. A test case is a sequence of steps and its
expected results. It usually consists of a series of actions that the user can perform to find out if the
product, service, or process behaved the way it was supposed to. Continuing with the employee
handbook example, you could create a test case process in which the user would click to download
the PDF of the handbook on their mobile device or desktop to ensure that they could access it
without issues.
• Select your users carefully. It is important to choose users who will actually be the end users of the
product, service, or process.
• Write the UAT scripts based on user stories. These scripts will be delivered to the users during the
testing process. A user story is an informal, general explanation of a feature written from the
perspective of the end user. In our employee handbook example, a user story might be: As a new
employee, I want to be able to use the handbook to easily locate the vacation policy and share it
with my team via email.
• Communicate with users and let them know what to expect. If you can prepare users ahead of
time, there will be fewer questions, issues, or delays during the testing process.
• Prepare the testing environment for UAT. Ensure that the users have proper credentials and access,
and try out these credentials ahead of time to ensure they work.
 • Provide a step-by-step plan to help guide users through the testing process. It will be helpful for
users to have some clear, easy-to-follow instructions that will help focus their attention on the right
places. You can create this plan in a digital document or spreadsheet and share with them ahead of
time.
• Compile notes in a single document and record any issues that are discovered. You can create a
digital spreadsheet or document that corresponds to your plan. It can have designated areas to track
issues for each item that is tested, including the users’ opinions on the severity of each issue. This
will help you prioritize fixes.
Managing UAT feedback
Users provide feedback after performing UAT. This feedback might include positive comments, bug reports,
and change requests. As the project manager, you can address the different types of feedback as follows:
• Bugs or issues: Users might report technical issues, also known as bugs, or other types of issues
after performing UAT. You can track and monitor these issues in a spreadsheet or equivalent system
and prioritize which issues to fix. For instance, critical issues, such as not being able to access,
download, or search the employee handbook, need to be prioritized over non-critical issues, such as
feedback on the cover art of the handbook.
• Change requests: Sometimes the user might suggest minor changes to the product, service, or
process after UAT. These types of requests or changes should also be managed and prioritized.
Depending on the type and volume of the requests, you may want to share this data with your
primary stakeholders, and you may also need to adjust your project timeline to implement these
new requests.
Key takeaway
User acceptance testing is a powerful tool to ensure that your project outcome is desirable and successful.
Be sure to leave time in the schedule for proper testing and issue resolution.
Common data metrics for project management
There are many types of project data you can use to determine your team’s progress and efficiency, evaluate
the success of your project, and inform project decisions. While you don't need to be a data expert,
knowing how to measure, track, and evaluate the right kind of data will help you deliver the most value and
impact.
This reading will recap some of the common types of data from the previous video and introduce a few
more key data points that can help you manage projects and work with stakeholders. This reading will also
introduce a few ways to interpret the data so that you can reduce risks and make the right decisions about
your teams and projects.

The benefits of analyzing data in project management

As a project manager, you can use data daily to make better decisions, solve problems, improve
performance and processes, and understand your users.
For example, if you have data on customer buying patterns, you can identify your best-selling products, and
you'll be able to make smarter decisions when placing new product orders with your suppliers. This data will
also help you better understand your users and their preferences so you can improve your product offerings
and performance.
You can also use project team data to help you refine your processes. For example, if your team is
experiencing an issue, analyzing data from your project tracker about the number of tasks completed,
escalations, or internal process problems can help you find the source. This will allow you to make an
informed decision about where to focus your efforts to improve processes.
Through critical analysis, application, and execution, data becomes a powerful tool to guide any project in
the right direction.
Data, metrics, and analytics

Three images: Numbers grouped in a circle to represent data; a graph with rulers lining the x and y axis to
represent metrics; two people working on a puzzle to represent analytics.
Data is information. It’s the numbers and feedback available to you about different aspects of your project.
Metrics are how you measure your data. They define the important or specific information (data) you need
to know about your project, such as productivity, quality, or engagement. Once you determine your
project's metrics, you analyze the data according to those metrics to find patterns and answer questions
about your project. This process is called analytics: using data to answer questions, discover relationships,
and predict unknown outcomes.
When analyzing data, ask: What do the metrics mean to you? How do you want to use the metrics you've
chosen? Can you find patterns to make predictions about your project? Can you find ways to improve—or
optimize—certain aspects of your project? What lessons can you draw from your project's data?
The next few sections are some common categories of metrics used in project management and a brief
explanation of what they are and how they're useful to a project. Keep in mind that your use of different
metrics isn’t limited to these categories. All of your project data is interrelated. The same metric can also
provide different information when applied to different aspects of your project.
Productivity metrics

Productivity metrics typically measure progress and output over time. They allow you to track—or predict—
the effectiveness and efficiency of your project team.
To track your team's productivity over time, analyze the number of tasks or milestones completed in a
given time frame. Ask questions like, what percentage of tasks are completed on time, and how long do
they usually take? Or, if tasks were not completed on time, how much longer than anticipated did it take to
complete all the tasks?
On-time completion rates can help illustrate to clients and stakeholders how the project is progressing and
when they can expect certain deliverables to be ready. If your project's completion rates are high, it means
you're doing a good job of meeting your completion goals. If the rates are low, it means you're missing
deadlines. Analyzing data can help you make decisions about things like improving or implementing new
processes, or re-evaluating how you estimate project scope, complexity, and timeline.
Calculating duration (how long something takes) can be useful for setting and evaluating tasks and
milestones and determining if you'll meet project deadlines. Tracking task duration can improve the
accuracy of estimating a project's timeline. This data is broken down into hours, days, weeks, months, and
sometimes years.
You can also analyze current information to predict future outcomes and make projections (or forecasts)
about productivity trends, project durations, costs, performance or quality. This kind of data empowers you
to proactively manage your project and its resources and measure the accuracy of your projections over
time. For example, analyzing your team's overall performance or velocity can answer questions such as, is
the team completing its tasks and milestones? What percentage of tasks is the team finishing on time?
Predicting the future may be impossible, but building a better understanding of it and refining your method
for making projections is achievable and valuable.
Quality metrics

Quality metrics relate to achieving acceptable outcomes and can include metrics such as number of
changes, issues, and cost variance, all of which affect quality.
Changes refer to differences in any aspect of the project from what was originally planned or required.
Issues are problems that may affect task completion—and often result in a change. Track the number of
changes and issues to identify patterns, refine processes, and share information about the project with
stakeholders.
Cost or budget variance is the difference between the actual amount of money spent on a project and the
amount that was budgeted for the project. Over time, this data can help you understand how well you're
estimating budgets for your projects. A low variance means you've estimated your project budget
accurately. A high variance means you should reevaluate your estimation process. You could be under- or
over-estimating costs for your budget, or you may not be tracking expenses effectively.
Happiness and satisfaction

Project managers at Google use a sub-set of metrics called happiness metrics that also relate to quality.
These are metrics that relate to different aspects of the user's overall satisfaction with a product or service,
like visual appeal, how likely they are to recommend, and ease of use. Happiness metrics can generally be
captured with a well-designed survey or by tracking revenue generated, customer retention, or product
returns.
Customer satisfaction scores reflect user attitudes, satisfaction, or perceived ease of use. These scores
measure how well the project delivered what it set out to do and how well it satisfies customer and
stakeholder needs. Customer satisfaction scores generally represent a combined metric—the sum of several
different happiness metrics. For example, on a satisfaction survey, a customer might separately rate a
product's appearance as 6/10, ease of use as 7/10, and likeness to recommend or use again as 8/10. The
overall customer satisfaction score would then be 7/10.
You will need to determine what scores are acceptable for your project by discussing with stakeholders what
the most important aspects of the project are.
Adoption and engagement

Another set of metrics related to quality are adoption and engagement. Adoption refers to whether or not a
product, service or process is accepted and used. Engagement refers to the degree to which it is used—the
frequency of use, amount of time spent using it, and the range of use. It might help to think of these in
terms of throwing a party: your adoption metrics would reveal to you whether or not people accepted the
invitation and showed up. The engagement metrics would tell you how active they were at the party—
whether they participated in activities or interacted with other attendees, if they invited their friends to
come with them, and how long they stayed.
Adoption metrics for a product or service release, like an app, software program, delivery service, or gym
membership, would be similar to the party example. However, they can be a bit more complex if you need
to track metrics for more than one thing, like whether users make additional purchases or sign up for
premium features.
Each project will need to define its own set of successful adoption metrics, such as:
• Conversion rates
• Time to value (TTV)
• Onboarding completion rates
• Frequency of purchases
• Providing feedback (rating the product or service)
• Completing a profile
Engagement metrics tell you to what degree a product, service, or process is being used. They reveal the
frequency and type of customer interaction and participation over time. Engagement metrics might include
the daily usage rate of a design feature or tracking orders and customer interactions.
As a project manager, you're not only concerned with the end user's level of engagement. It's just as
important to monitor stakeholder and team member engagement as well. Measuring stakeholder
participation by tracking the frequency of communication, responses to emails or updates, attendance at
meetings, or level of input can give you a sense of whether or not stakeholders are finding value in the
project. A lack of meaningful engagement could put your project at risk. Stakeholders may not be aware of
changes or the overall progress of the project, and therefore the final outcome of the project may not meet
their expectations. Measuring team member engagement is vital to the success of your project because the
more engaged they are, the more productive they are, and the more likely they are to produce high-quality
results.
Ideally, you want your adoption and engagement metrics to increase or to at least meet the goal metrics
that were established with stakeholders earlier in the project. If there is no increase, or the metrics drop,
then your rates are low and therefore not as successful. Check out the resources below for a more in-depth
understanding of how and why to measure adoption and engagement.
Key takeaway
Data, metrics and analytics are all important to the success of your project. You'll need to have some
familiarity with how to collect and measure data, and how to use the data to tell you about different aspects
of your project. Depending on the project and its unique goals, some metrics will be more important than
others. It's your job to make sure you understand which metrics your stakeholders are most interested in
and what elements impact your team's ability to deliver quality results on time and within budget.

Data ethics considerations

In the previous video, you learned how to use knowledge to discern data and how signals help prioritize
data. This reading will cover the importance of data ethics and two key principles: data privacy and data
bias.
Data ethics
As a project manager, data collection and analysis will be a key part of your projects. As you’ve learned,
you’ll collect data from a variety of sources, including focus groups, interviews and questionnaires. The data
you collect will usually hold PII (personally identifiable information)—information that could be used to
directly identify, contact, or locate an individual. A lot of times, you will also need to report on the data you
collect to stakeholders, customers, and your project team. Collecting, analyzing, and sharing this data in an
ethical way is extremely important for maintaining the integrity of your organization, your projects, and your
position.
Data ethics is the study and evaluation of moral challenges related to data collection and analysis. This
includes generating, recording, curating, processing, sharing, and using data in order to come up with
ethical solutions.
Businesses apply data ethics practices so they can:
• Comply with regulations
• Show that they are trustworthy
• Ensure fair and reasonable data usage
• Minimize biases
• Develop a positive public perception
Data ethics is rooted in several principles. In this reading, we will focus on two of these principles: data
privacy and data bias.
Data privacy
Data privacy is a key part of data ethics. Data privacy deals with the proper handling of data. This includes
the purpose of data collection and processing, privacy preferences, the way organizations manage personal
data, and the rights of individuals. It focuses on making sure the ways we collect, process, share, archive,
and delete data are all in accordance with the law.
As a project manager, it is your responsibility to protect the data you collect. You can help ensure the
privacy of data collected from users, stakeholders, and others for your projects by:
• Increasing data privacy awareness. Make sure every member of your project team—plus the
vendors, contractors, and other stakeholders from outside of your company—are made aware of
your organization's data security and privacy protocols.
• Using security tools. Free security tools, like encrypted storage solutions and password managers,
can decrease your project’s vulnerability to a data breach. In a lot of applications, like ones that are
part of Google Workspace and Microsoft OneDrive, privacy settings can be adjusted to only give
access to specific individuals.
 • Anonymizing data. Data anonymization refers to one or more techniques such as blanking, hashing,
or masking personal and identifying information to protect the identities of people included in the
data. This helps protect individuals’ personal information by keeping them anonymous. Once the
information has been anonymized, it can then be used and shared freely. Types of data that should
be anonymized include names, telephone numbers, social security numbers, email addresses,
photographs, and account numbers.
Data bias
Another important data ethics practice is making sure that the data you collect does not indicate any biases.
Data bias is a type of error that tends to skew results in a certain direction. Maybe the questions on your
survey had a particular slant to influence answers, or maybe your sample group was not fully representative
of the population you want to study. Bias can also happen if a sample group lacks inclusivity. For example, if
your sample does not include people with disabilities. The way you collect data can also bias a dataset. Say
you give people only a short time to answer questions, this can lead to rushed responses. When people are
rushed, they tend to make more mistakes, which can affect the quality of their data and create biased
outcomes. As a project manager, you have to think about bias and fairness from the moment you start
collecting data to the time you present your conclusions.
Types of biases
There are different types of biases to keep in mind when setting up your data collection processes. Here are
four of the most common types of biases that could impact your data:
• Sampling bias is when a sample is not representative of the population as a whole. For example,
maybe your sample did not include people above the age of 65. Or maybe you excluded people from
certain socioeconomic groups.
• Observer bias is the tendency for different people to observe things differently. For example,
stakeholders from different parts of the world might view the same data differently and draw
different conclusions from it.
• Interpretation bias is the tendency to always interpret situations that don’t have obvious answers in
a strictly positive or negative way, when, in fact there is more than one way to understand the data.
Data that does not provide an obvious set of conclusions makes some people feel anxious, which can
lead to interpretation bias. For example, a team member might interpret inconclusive survey results
negatively, while other team members might be able to think more carefully and assess the data
from different angles.
• Confirmation bias is the tendency to search for or interpret information in a way that confirms pre-
existing beliefs. For example, you might ask only specific stakeholders for feedback on parts of your
project because you know they are the most likely to have the same perspective as you.
Each of these types of bias affect the way you collect and make sense of the data, so it is important to be
aware of them when setting up your data collection processes.
Key takeaway
According to the Project Management Institute’s Code of Ethics & Professional Conduct, “Ethics is about
making the best possible decisions concerning people, resources, and the environment. Ethical choices
diminish risk, advance positive results, increase trust, determine long term success, and build reputations.
Leadership is absolutely dependent on ethical choices."
A key way you can show your leadership skills is by exercising sound judgment when it comes to data ethics.
In order to tell a project’s data-informed story to stakeholders, project team members, and others in an
ethical way, you have to make sure you think about both privacy and bias-related concerns in how you
conduct, analyze, and share that data.

The six steps of data analysis

In an earlier video, you learned that data analysis is the process of collecting and organizing information to
help draw conclusions, solve problems, make informed decisions, and support your goals. In this reading,
we will go over the key parts of the data analysis process.
There are six main steps involved in data analysis: Ask, prepare, process, analyze, share and act. Let’s break
these down one by one.

During the Ask phase, ask key questions to help frame your analysis, starting with: What is the
problem? When defining the problem, look at the current state of the business and identify how it is
different from the ideal state. Usually, there is an obstacle in the way or something wrong that needs to be
fixed. At this stage, you want to be as specific as possible. You also want to stay focused on the problem
itself, not just the symptoms. For example, imagine you are doing data analysis for a gym that is losing
memberships. You could ask: Why do we keep losing members? But a better and more specific question
would be: What factors are negatively impacting the member experience? That way, when you set off to do
your research, you know exactly what to look for.
Another part of the Ask stage is identifying your stakeholders and understanding their expectations. There
can be lots of stakeholders on a project, and each of them can make decisions, influence actions, and weigh
in on strategies. Each stakeholder will also have specific goals they want to meet. It is pretty common for a
stakeholder to come to you with a problem that needs solving. But before you begin your analysis, you need
to be clear about what they are asking of you. For example, if your manager assigns you a project related to
analyzing the gym’s business risk, it would be a good idea to confirm whether they want you to analyze all
types of risks that could affect the gym or just risks related to weather or seasonal trends.

After you have a clear direction, it is time to move to the Prepare stage. This is where you collect and store
the data you will use for the upcoming analysis process.
Let’s turn back to our gym membership example. To collect data on the member experience, you decide to
send surveys to the gym’s members asking for feedback about their experience. To make sure you get
specific answers, you ask them to offer feedback in three distinct categories: upkeep of the facility, customer
service, and membership cost. You also leave room for them to write in a response. When you get the
member surveys back, it is important that you have an organized system for tracking and filing them.

This stage is when it is time to Process your data. In this step, you will “clean” your data, which means you
will enter your data into a spreadsheet, or another tool of your choice, and eliminate any inconsistencies
and inaccuracies that can get in the way of results. While collecting data, be sure to get rid of any duplicate
responses or biased data. This helps you know that any decisions made from the analysis are based on facts
and that they are fair and unbiased. For example, if you noticed duplicate responses from a single gym
member when sorting through the surveys, you would need to get rid of the copies to be sure your data set
is accurate.
During this stage, it is also important to check the data you prepared to make sure it is complete and correct
and that there are no typos or other errors.

Now it is time to Analyze. In this stage, you take a close look at your data to draw conclusions, make
predictions, and decide on next steps. Here, you will transform and organize the data in a way that
highlights the full scope of the results so you can figure out what it all means. You can create visualizations
using charts and graphs to determine if there are any trends or patterns within the data or any need for
additional research.
In our gym membership example, let’s say you notice 50% of the members wrote in an additional response
on the survey citing that the equipment is outdated. The survey also showed that 75% of the responses
cited “expensive membership fees.” When looking at the 50% of responses citing “outdated equipment”
and 75% of responses citing “expensive membership fees” side by side on a graph, you may be able to
deduce that these responses inform one another. Members feel like the experience just isn’t worth the
price. You might conclude that the gym should invest in new equipment if they want to keep members and
add value to the membership fee.

Once you have asked questions to figure out the problem—then prepared, processed, and analyzed the
data—it is time to Share your findings. In this stage, you use data visualization to organize your data in a
format that is clear and digestible for your audience. When sharing, you can offer the insights you gained
during your analysis to help stakeholders make effective, data-driven decisions for solving the problem.

And finally, you are ready to Act! In the final stage of your data analysis, the business takes all of the insights
you have provided and puts them into action to solve the original business problem.
Conducting a data analysis is an essential process for understanding a business’ needs and challenges and
determining effective solutions. These six foundational steps—ask, prepare, process, analyze, share, and
act—will help set you up for success!

Different ways to visualize data

Earlier, we discussed best practices for collecting and analyzing data. When it is time to present your data to
your audience, you don’t just want to tell them about your findings and what they mean, you want to show
them. Data visualization helps us organize data and turn it into information that is clear and easy for our
audience to digest.
In this reading, we will go over a variety of charts and graphs you can use to visually represent data.
Visualizing your data
Before translating your data into a chart or graph, you should be clear on what you want to show your
audience. Figure out what data you want to use and why. You might want to inform your audience about a
new trend or a valuable piece of information, or show relationships between data sets. Or maybe you need
to compare values, understand the composition of something, or analyze trends and behaviors over set
periods of time.
The type of data you have, and the information you want to show or understand, will help you figure out
the right data visualization to use. Let's go over some scenarios and discuss which charts and graphs would
be best for each.
Show relationships
A scatter plot, sometimes referred to as a scatter chart or scatter graph, uses dots to represent values for
two different variables. The position of each dot on the horizontal and vertical axis indicates values for an
individual data point. Scatter plots will sometimes have a line drawn across its center. This line is known as
the trend line and highlights the direction the points are trending towards.
Scatter plots show the relationship between data sets, and can help us understand the impact of one factor
on another. For example, the scatterplot below shows the relationship between the life expectancy of
people living in a country and how happy those people are. The first variable, the happiness score, is
reflected on the vertical axis —also called the y-axis. The second variable, life expectancy, is on the
horizontal axis —also called the x-axis. By looking at this scatterplot, we can tell that as a person’s happiness
score increases, so does their life expectancy.

Scatter plot best practices:

• Start the y-axis at 0 to represent data accurately.
Comparing values
Bar graphs use size contrast to compare two or more values. In the example below, the time of day is
compared to someone’s level of motivation throughout the whole work day. By comparing this data, we can
tell that this person’s motivation is low at the beginning of the work day, and gets higher and higher by the
end. Bar graphs are also a great way to clarify trends and identify patterns.

Bar graph best practices:

• Use consistent colors throughout the chart
• Use accent colors to highlight important data points or changes over time
• Use horizontal labels so it is easier to read
Demonstrating composition
Now let’s check out another visualization you will probably recognize—the pie chart. Pie charts show us the
composition of something. In other words, how much each part of something makes up the whole. The pie
chart below shows us all the activities that make up someone’s day. Half of it is spent working, which is
shown by the amount of space that the blue section takes up. From a quick glance at this pie chart, you can
easily tell which activities make up a good chunk of the day and which ones take up less time.
Pie chart best practices:
• Avoid including too many categories so it is easy to compare slices
• Make sure that the slice values add up to 100%
• Order slices according to their size
Analyzing trends and behaviors
Tracking trends can help us understand shifts or changes in our data. Line graphs are a great tool for visually
showing change over time, but they can be paired with other factors, too. In the line graph below, we are
using two lines to compare the popularity of cats and dogs over a period of time. Because the graph is using
two different line colors, we can instantly tell that dogs are more popular than cats. We will talk more about
using colors and patterns to make visualizations more accessible to audiences later, too. Even as the lines
move up and down, there is a general trend upwards, and the line for dogs always stays higher than the line
for cats.
Line graph best practices:
• To avoid clutter, don't show more than four categories.
• Organize highly variable data at the top of the chart to make it easy to read
Scatterplots, bar graphs, pie charts, and line graphs are common data visualizations you will use throughout
your career as a project manager. To practice creating these charts, check out this step-by-step overview for
creating charts using Google Sheets or this resource for Microsoft Excel.

Preparing an effective presentation

At various points throughout a project, you will likely be required to deliver a presentation to team
members, key stakeholders, senior leaders, or customers. Use the following tips and best practices to help
you prepare an effective presentation.
Preparation
Get clear on your goals and the purpose of your presentation.
Be clear and specific about what you want to get out of the meeting, then frame the discussion with that
goal in mind. For instance, “We need two engineers who have worked in this industry before,” instead of
“We need more resources.”
Seek input and set expectations.
Ask your manager or check with stakeholders regarding your presentation goals. Get their input and
feedback ahead of time.
• If you were invited to present, make sure you understand in advance exactly what the requestor is
hoping to gain from your presentation.
Create a delivery plan.
Identify a headline for each slide, which is the one-sentence main point that you are trying to illustrate with
that slide.
 • Create a couple of supporting points that add interest to the headline, such as anecdotes, charts,
data, etc.
• Build in signposts. These are ways to clue the audience in to where you are going and what to expect
with your presentation.
• Limit the number of slides in the main presentation. At the same time, consider creating backup
slides for potential challenges, difficult questions, trade-offs, or alternative solutions. You can hide
these backup slides at the end of your presentation if you don’t need them, or add them into your
presentation if you do.
Be mindful of your audience’s time.
Invite only participants who need to be there.
• Send the presentation ahead of time, if possible.
Develop a strategy for making your presentation memorable.
Use stories and repeat key points.
• Start with a strong intro. Spend extra prep time on the beginning. The beginning is when your nerves
are typically the highest, and delivering the introduction successfully can help you quickly gain
confidence.
Practice
Guide your audience through your presentation.
Help them notice what you notice, and transition between slides by using phrases like “Building on this
point . . .” or “As I mentioned before . . .”
Do a mock presentation with your team.
If there will be more than one presenter, coordinate what each person will cover and how you will manage
handoffs.
• Practice a question-and-answer (Q&A) session, anticipating the kinds of questions your participants
might ask so you are prepared with a quick and confident response. In addition, practice what you
will say if you are asked a question that you don’t know the answer to.
• Be prepared to run the whole meeting yourself. If a co-presenter fails to show up, are you prepared
to step in?
Schedule time to practice.
• Once you’ve outlined what you want to say, practice it—ideally in front of a mirror—or record
yourself. This may help you identify awkward phrasing that could be improved and other issues.
Be prepared for surprises.
Show that you can adapt and that you know your subject matter.
• If time runs short, can you quickly summarize the key points?
 • Can you pivot the content according to what is most important to your audience?
Presentation and pace
Get right to the point.
Identify what problem you are solving and state it up front.
• Tell the audience why you are in the room with them and what you will be covering.
• Lay down the ground rules. For example, how do you want to handle questions and comments? Will
you take them throughout your presentation or afterwards?
Check your pace.
Be mindful of clues from your audience and adjust accordingly.
Follow up
• If appropriate, send a follow up email with summary notes, action items, and time frames.
• Debrief with your manager or key audience members on what they heard from the
presentation. Ask them what went well and what could have gone better.
• Review next steps.
1) Mark as completed
2) Like
3) Dislike
4) Report an issue

Providing “air cover” to your team

As you have learned so far, project managers build teams that meet project goals in many different ways,
from delegating responsibility and prioritizing tasks to promoting trust and psychological safety.
But there is another skill great project managers have that we will cover in this reading: the ability to
provide air cover to protect their team. Air cover refers to support for and protection of a team in the face
of out-of-scope requests or criticism from leadership.
What is air cover?
A lot of what we have covered throughout this program has focused on leading and managing a project
team. Much of project management involves overseeing the work of others, but it also involves managing
the needs and expectations of those above you. Those people are your stakeholders, project sponsors, and
other leaders within your organization.
Though the needs and requests of your stakeholders are crucial to the project’s success, there may come a
time when you will need to prioritize the needs of your team over the wants of your stakeholders. This is
called providing “air cover” for your team, and it is an important part of managing a project. The ability to
effectively provide air cover requires a trusting relationship between a project manager and their
stakeholders. In this relationship, the project manager aims to demonstrate their abilities to lead a team
and communicate effectively.
There is some risk involved in providing air cover. Sometimes a project manager provides air cover and the
project team is still unable to deliver on the goals of the project. In this case, stakeholders may question the
project manager’s ability to complete projects successfully. So, when preparing to defend your team against
out-of-scope requests, be sure that you are confident in your team’s progress toward the project goal.
Providing air cover: A case study
Imagine, for example, that you are a project manager for a brand of coffee sold in supermarkets throughout
your region. You and your team have been tasked with launching three new flavors of ground coffee: vanilla,
hazelnut, and mocha.

However, well into the execution phase, your project sponsor sets a meeting with you to make an out-of-
scope request: They would like to add a caramel-flavored coffee to the product lineup. Your team is already
at maximum capacity preparing to launch the agreed-upon flavors, and a fourth flavor would add an
unreasonable amount of work and stress to your very busy team.
Let’s discuss how you might provide air cover for your team in a situation like this one.
Saying “No” without explicitly saying “No”
One way to provide air cover to your team is to say “no” to your sponsor’s request without explicitly saying
“no.”
There are a few ways to do this:
• You can gently push back with a polite explanation that their request won’t be possible to complete
under the current constraints—the scope, time, and/or cost—of the project.
• You can politely offer to get back to the stakeholder with your response. This gives you time to better
understand the request and to consult with trusted team members to lay out the benefits and costs
 of this request. And, if you are lucky, this might even give the stakeholder the opportunity to
reconsider their request or forget about it entirely.
Whether you choose to push back immediately or get back to your stakeholder with your response, it is
crucial to offer alternative solutions. Maybe the project timeline can expand to accommodate the request.
Or maybe you and your team have a strong relationship with another team at the organization that can help
fulfill the request. Whatever the alternative, brainstorming other options can help soften the blow and
provide stakeholders with new ideas.
For example, you consider telling your sponsor that the current project timeline will only allow for the
launch of three new coffee flavors, and that the launch of a fourth flavor would only be possible by pushing
the launch date back by two months. If you were to respond to your sponsor in this way, you would be both
gently refusing their request and offering them an alternative that could work for your team.
While a simple “no” response might frustrate the person making the request, gentle pushback paired with
alternative options can protect your team from new work while preserving your professional relationship
with stakeholders. If your stakeholders trust your leadership abilities and perspective, then they will be
more likely to accept your pushback and alternative solutions.
Intervening from behind the scenes
Another way project managers provide air cover for their teams is to master the challenge of delicately
intervening from behind the scenes when a stakeholder is making unrealistic requests or offering
unreasonable critiques.
Continuing with our coffee company example, you know how hard your team has been working to launch
the new products. To avoid causing the extra stress that might come with the knowledge that the
stakeholder wants to increase their workload, you avoid sharing this request with your entire project team.
This doesn’t mean you need to come up with a solution all by yourself, however. Instead of calling a team
meeting to discuss the stakeholder’s request for a new flavor, you consult with only two trusted members of
your team to help brainstorm solutions. One of these team members mentions that they know two new
flavors are slated to be added to the fall product lineup in six months, and that perhaps the caramel flavor
could be launched then instead of with the current group. This would give your team more time to work on
developing the product while still fulfilling the stakeholder’s request.
Ultimately, you bring the suggestions of adding the flavor to the fall product lineup or pushing back the
launch date of the current lineup to the project sponsor, and they accept your solution to launch the new
flavor in the fall.
Managing the expectations of your stakeholder while looping in relevant teammates on a need-to-know
basis was essential here. This allowed your team to focus on their work without the possibility of an
increased workload or an unnecessary distraction.
Key takeaway
Providing air cover for your team takes practice. It requires a careful balance of the needs of your
stakeholders and the needs of your project team. As you become more experienced in leading projects, you
will develop a stronger sense of how to manage nuanced situations like these and provide the air cover your
team needs to do their best work.

A framework for ethical decision-making

Ethical leadership is a form of leadership that promotes and values honesty, justice, respect, community,
and integrity. As the leader of a project team, you will be expected to help your team succeed by leading
with ethics. Building respect and trust with the teams you work with—from individuals to external partners
to project stakeholders—begins with practicing ethical conduct.
In this reading, you’ll gain an understanding of a common framework for ethical decision-making that can
help you ensure your actions align with the ethical standards of your organization.
Ethics within your organization
Ethics can be defined as the principles of conduct governing an individual or a group. However, there is no
single, universally-accepted grouping of ethical standards—these definitions differ based on the culture and
community at your company. In the working world, ethical standards may differ based on profession,
industry, and organization. Usually, an organization will have its own code of conduct which specifies the
standards to which it holds its employees accountable.
Here at Google, our code of conduct makes clear the expectations that we have for our employees and
board members. It is possible that the organizations you will join throughout your career will have codes of
conduct, too.
Part of the challenge of leading with ethics is ensuring that your actions align with the ethical standards of
your community, both within your organization and beyond it. In your role as a project manager, a clear
framework for ethical decision-making can help guide you to make positive decisions throughout your
project.
A common framework for ethical decision-making
The Markkula Center for Applied Ethics at Santa Clara University developed the following framework as a
helpful guide for ethical decision-making.
Recognize an ethical issue
According to this framework, you can begin to question the ethics of an issue by asking yourself questions
about the nature of the issue. Could your decision negatively impact another person or group of people?
Does the issue go beyond what is legal or efficient? From there, you can proceed onto fact gathering.
• Example: A vendor you have worked with in the past sends you a generous holiday gift shortly
before you are about to select a vendor for a particular task in your project. If you accept the gift,
would others be negatively impacted? To determine the answer to this question, get more facts.
Get the facts
Decide what you should do about the issue, and seek answers as needed. Consult with the right people to
consider all of the options available to you.
• Example: Continuing with the example above, you should check to see if your company has ethics
guidelines regarding accepting gifts from external parties. If not, consult with your HR representative
about the matter.
Evaluate alternative actions
You can evaluate alternative actions by asking yourself the following questions:
• “Which option will produce the most good and do the least harm?”
• “Which option best respects the rights of all who have a stake?”
• “Which option treats people equally or proportionally?”
• “Which option best serves the community as a whole, not just some members?”
• “Which option leads me to act as the sort of person I want to be?”
Note that your answers to these questions are subjective, and you may want to elicit the opinion of others
before deciding on an alternative action.
 • Example: In the case of the vendor gift example, the answer to the question “Which option treats
people equally or proportionally?” might be “decline the gift,” given that accepting it might influence
your decision about who to award the contract to.
Make a decision and test it
Once you have chosen an option, test it by imagining the reaction to your choice from a person whose
opinion you value.
• Example: Once you have decided to decline the gift, discuss your decision with your manager, HR
representative, or a trusted colleague.
Act and reflect on the outcome
Consider how to carry out your decision with thoughtfulness and care, and after you act, consider the
results of your decision.
• Example: Respectfully decline the vendor’s gift, noting your reason (for example, your company’s
ethical guidelines state that employees are not permitted to accept gifts valued at more than $20
from vendors or contractors).
Key takeaway
A framework like this one can help you feel better-equipped to make ethical decisions regarding your
project and team, which is a central component of ethical leadership.
Like so much of project management, ethical leadership takes diligence and practice, and it is crucial to
build this skill. As you become more comfortable leading project teams, you will strengthen your ability to
make decisions that you can feel good about. Gaining trust and respect from the people you work with can
make it easier to influence without authority. If those around you trust your decision-making, they may be
more likely to try to help you achieve project goals, even if you aren’t their direct manager.

Creating an effective influencing statement

Introductions in literature are important. Think of the opening lines of a good book—they help set the tone
for what the reader can expect going forward. Introductions are important in project management too,
especially when you are hoping to influence a stakeholder to consider and approve a new plan or idea.
In this reading, we will help you apply techniques you can use to influence others. We will take you through
the steps of creating a strong influencing statement that opens the conversation and sets you up for success
with your audience.
What is influencing?
First, let’s review what it means to influence another person. Influencing is the ability to alter another
person’s thinking or behaviors. If you have ever tried to persuade another person to understand your point
of view, then you know that influencing is easier said than done.
Conger’s four steps
In his article, The Necessary Art of Persuasion, Jay A. Conger identified four steps to effectively influence
another person to consider new ideas.
As you learned earlier, those steps are:
1. Establish credibility
2. Frame for common ground
3. Provide evidence
4. Connect emotionally
Throughout your career in project management, there will be times when you will need to influence
someone to consider an idea, approve a plan, or complete a project task. Conger’s four steps provide a
useful framework for thoughtfully approaching conversations that are important to project success and
influencing stakeholders. Let’s explore each step further before applying them to an influencing statement:
1. Establish credibility
When trying to persuade another person to listen to you, it helps to establish credibility. Ask yourself, why
should this person listen to you? According to Conger, it is best to draw credibility from both expertise and
relationships.
You can build credibility by showing a level of expertise on the topic at hand. It also helps to have “a history
of sound judgement.” If you find that you lack expertise on a subject, don’t worry! You can work to increase
your knowledge through education or research, or you can even ask an expert for help.
You can also build credibility through strong relationships with your audience and others around you.
Conger found that influential leaders tend to show their trustworthiness and willingness to do right by their
colleagues over time, and in turn, people are more likely to listen to them.
2. Frame for common ground
The next step in effectively persuading people is to frame for common ground. You can do this by making a
case for how your idea would benefit your audience, and you can determine how your ideas will benefit
your audience by gaining a strong understanding of them and what they value. Pay close attention to what
matters to your audience by listening carefully and gathering information during meetings and
conversations. Then frame your ideas based on your audience’s needs and interests.
3. Provide evidence
The third step is to provide evidence that supports your ideas. As Conger notes, though numbers are
important, the best persuaders pair numbers with vivid language. They share stories, examples, and
metaphors to help influence their audiences. Using vivid language can help bring your figures to life and
draw stakeholders’ interest to your proposal.
4. Connect emotionally
The fourth step is to connect emotionally with your audience. In this step, you illustrate that you are
emotionally invested in the idea that you are presenting. But crucially, Conger notes, you must also do your
best to determine and match the emotional state of your audience.
Applying Conger’s steps to an influencing statement
Conger’s four steps—establish credibility, frame for common ground, provide evidence, and connect
emotionally—are meant to be applied throughout important conversations with those whom you aim to
influence. But to set yourself up for success during these conversations, you can apply the four steps to the
influencing statement that sets the stage for your idea.
Let’s discuss how Conger’s four steps come together in the following example:
Carmen is a project manager at a small marketing agency. She would like to convince a human resources
director at her organization to approve a new process for onboarding new graphic design employees.
Though the company has an existing onboarding process, this process is the same for all new hires,
regardless of role. As a project manager working in the human resources department, she learns that it is
hard for newly-hired graphic designers to onboard since there are only a few people who hold graphic
design roles at the company. Carmen identifies that there is a lack of information available for new graphic
design hires to turn to for learning about procedures and software specific to their role.
Carmen would like to propose that all new graphic design hires receive a digital welcome packet containing
guidelines for installing software, processes to be aware of, and other design-specific onboarding
documents. Carmen developed a similar process in her role at a previous company, and it received a
positive response from employees. She thinks a similar process will work for her new organization too, so
she sets up time with her director to present her idea.
To influence her director to approve the new process, Carmen opens her presentation with a strong
influencing statement:
I’d like to propose a new onboarding process for graphic design hires.
(Provide evidence) In reviewing our new hire surveys, 80% of recent graphic design hires have assigned a
negative rating to our onboarding process. When I followed up with respondents, I learned that our graphic
designers lack access to relevant information that could help them acclimate to our organization faster. To
address this issue, I would like to create a digital welcome packet containing design-specific onboarding
documentation.
(Frame for common ground) I have met with leaders on the graphic design team to discuss this idea, and
they agreed that a design-specific onboarding process might help increase the productivity of new hires,
since a better onboarding process would enable them to be better prepared to take on projects in their first
few weeks on the job.
(Establish credibility) In my previous role, I designed a similar, role-specific onboarding process, which
increased our new hire satisfaction rates by 60%. I think a new process could benefit employees here, as
well.
(Connect emotionally) It can be overwhelming to join a new company. A smoother, more personalized
onboarding experience might help set the tone for the kind of support new graphic design hires can expect
from our team.
Key takeaway
In this influencing statement, the project manager:
• Provided evidence from company surveys to set the stage for her proposal.
• Framed for common ground by noting how a new onboarding process might increase employee
productivity.
• Established credibility by outlining her previous experience with launching similar processes.
• Connected emotionally by encouraging her audience to reflect on past experiences they may have
endured as a new hire.
By opening with a strong influencing statement, you can set yourself up for a successful conversation that is
more likely to persuade your audience and achieve your goals.

Principles of effective email writing

Email has long been the primary method of communication for many people in business, yet messages are
easy to misunderstand or ignore. In this reading, we will discuss four principles of effective email writing
that will help your emails to stand out, be remembered, and elicit the response you need. These principles
are:
• State what you want clearly.
• Keep the content short and concise.
• Structure your writing.
• Check grammar, punctuation, and spelling.
Principles of effective email writing
State what you want clearly
When you set out to compose an email, it is because there is something that you want from your reader.
You might want to receive a simple answer, to persuade someone of something, or to arrange a meeting.
Before composing an email, think about what you want, when you need what you want, and the best way to
get what you want when you want it.
Here are some tips on how to clearly state what you want in your email:
• Include your request in the subject line of your email.
• State your request within the first two paragraphs of your email message.
• Indicate the specific call-to-action associated with your request (for example, reply, review, RSVP).
• Write clear, concise sentences when providing details.
• Define terms. Avoid using acronyms and terminology that users may not know. Provide additional
information as necessary to avoid misunderstanding.
Keep the content concise
Make your words work for you. Remove any writing that doesn’t help to define what you want or contribute
to your reader's needs.
• Summarize the content you want to convey, and remove anything in your email that doesn’t
contribute to your goal.
• Aim to write “question-less” and “self-standing” emails. This means that the message contains
enough information to stand on its own. The reader shouldn’t have any questions about what you
want and when you want it.
• Know your audience. Some people—such as executives and other busy leadership—may not want to
read emails of more than a few sentences or click on external links for further information. Try to
tailor your emails accordingly.
Structure your writing
Structure has to do with the visual flow, or aesthetics, of your email. A well-structured email conveys critical
information to the reader quickly and allows them to scan the explanatory text—or ignore it altogether.
Here are some tips for effectively structuring your email:
• Use bullets. Bullets break up the visual flow. If you have more than one of something, consider using
bullets. Write strong action verbs at the start of each bullet.
• Use labels. Labels help guide the reader to what information is most important.
• Add hyperlinks. Hyperlinks allow readers to directly access additional information, rather than
adding lengthy details to your email.
• Write a strong topic sentence. Place the main idea of the paragraph in the topic sentence.
Check grammar, punctuation, and spelling
Grammar, punctuation, and spelling are critical. Turning grammar and spelling suggestions on in your email
application can help you quickly identify errors. Be sure to correct any errors before sending off.
Applying effective email writing principles
In order to learn how to apply these principles, let’s check out the following example email:
Issac was given the task of sending an email about the company’s annual team building retreat. Please note:
Blue, underlined text indicates a hyperlink to an external site or document.

Subject : Annual Team Building Retreat - Register Now! Team, I am thrilled to invite you all officially to the
2021 Annual Team Building Retret. As in previous years, we are taking time out to celebrate and strengthen
our team spirit—to learn from each other and to plan for the challenges ahead. Weve got something special
planned for this retreat! Beyond the staples of world-class training, fabulous working sessions, and
executive presentations, we've also arranged: An Annual Awards Dinner at the Hotel San Francisco; pre-
booked rooms for those who want to stay at the hotel after dinner; and an afternoon at Shoreline Lake with
sailing, rowing, and paddle boats available. We hope you can join us for all three excursons. Don't forget to
register and sign up per the instructions on the site. Our theme this year is Transform. We look forward to
sharing a transformational week with you all! Best, Issac Soto
This email example is not as effective as it could be. The date and location of the event are not included. The
main link Issac wants the reader to click—to register for the event—is buried at the bottom of the email.
The other links in the message are also overwhelming because there are so many. There are no bullets or
labels to help organize the information. Additionally, there are a few spelling and punctuation errors.
Let’s examine how Issac’s email could be revised to be more effective.
Subject: Annual Team Building Retreat - Register Now! Team, I am thrilled to invite you to the 2021 Annual
Team Building Retreat, October 13–15 at the Hotel San Francisco. This is an opportunity to celebrate and
strengthen our team spirit and to learn from one another as we plan for the challenges ahead. To end the
event, we will hold our Annual Awards Dinner. Sign up now! For the retreat For hotel rooms For lakeside
activities Best, Issac Soto
In this example, there is a clear, concise description of what the email is about at the very beginning of the
email. The dates and location of the event are clearly stated at the beginning of the email. The opening
paragraph is directly followed by a label in bold: Sign up now! Then, bullet points help set apart the
hyperlinks for better visibility, and the hyperlinks clearly state what the reader will access when they click.
Lastly, the grammar, spelling, and punctuation are all accurate.
Key takeaway
When you write an email, think about the people you are sending it to and what they need in order to
quickly read and correctly understand it. Remember to:
1. State what you want clearly.
2. Keep the content concise.
3. Structure your writing.
4. Check grammar, punctuation, and spelling.
Keeping these principles in mind when you draft emails will help you communicate more effectively with
your team members, stakeholders, customers, and others. It can also demonstrate your level of
professionalism and competence and inspire others’ confidence in your abilities.
 Facilitating inclusive and accessible meetings

In the previous video, we discussed how to organize an effective meeting. Recall that effective meetings
generally have four elements in common: they are structured, intentional, collaborative, and inclusive. In
this reading, you will explore the fourth element: how to make your meetings more inclusive.
Creating an inclusive environment
Inclusion of employees from different backgrounds and identities is extremely important for any
organization looking to build a strong sense of connection in the workplace. Also, when team members feel
included, they tend to want to do their best work. This is great for the organization, too. Creating an
inclusive environment can be particularly challenging in meetings because they can be intimidating for
participants. As a project manager, it is part of your job to facilitate meetings that are inclusive of all
participants and that create a sense of emotional safety and value for everyone’s active input. In order to
help facilitate inclusive meetings that feel empowering to everyone, you should put procedures in place that
are consistently followed and predictable.
• Formalize initial check-ins for the group that build understanding and ensure everyone knows
their input is needed. Create a process that consistently asks each person for an update on their
work and/or how they are doing in their daily lives. Questions should be open-ended and vary over
time to include some humor, analogies, and “finish the sentence” opportunities. As the project
manager, your modeling will set the tone for the team dynamic, so always check-in with your team
and model professionalism, vulnerability, and empathy. Popular check-ins include: “A highlight of my
week has been . . .” and “This week I have gratitude for . . .”
• Give everyone your full attention. Listen carefully to what everyone has to say and be careful not to
interrupt someone who is speaking. Body language—such as maintaining eye contact and turning
your body in the direction of a speaker—can help someone feel safe in voicing their opinion. Avoid
head shaking, looking away, or looking at your phone when someone is speaking.
• Help all participants to be heard. Solicit ideas from participants, and ask questions to encourage
participation. If someone gets interrupted, redirect everyone’s attention to that person and prompt
them to finish their thought. If someone has not spoken yet, ask them what they think. It is
important to note that, for some people, speaking up in meetings can be daunting. This can be
especially true in virtual meetings or conference calls. This is also true for people who are not the
majority in the room and may feel like they are representing an entire group of people who look,
sound, or present like them. You may also find that people who are entry-level may be nervous
about speaking up too since they are just beginning their careers. You can help people feel more
comfortable and supported by letting them know ahead of time that they will be asked to share
during a meeting so that they can prepare in advance. You can also solicit input after a meeting from
anyone who did not speak.
• Help participants feel comfortable sharing different perspectives. Encourage differing or opposing
ideas by making clear that alternate viewpoints are valued. To set the tone for this, start the meeting
by encouraging competing perspectives. Try to get at least three points of view on an issue that
 might have some variation in the room. Follow up after the meeting with a request for additional
thoughts.
• Use images that reflect the diversity of the world. In your presentation materials and handouts,
select images that illustrate diversity in race, gender, age, ability, cultural background, religion,
geographical location, and so on. The people in your images should represent diverse backgrounds
to further support inclusion, allowing everyone in the room to feel welcome and represented.

Making meetings accessible to everyone

Meetings can’t be inclusive if not everyone can fully participate. It is important to make sure that your
meetings are accessible to everyone. Accessible means that something is easily used, accessed, or adapted
for use by people experiencing disabilities. In meetings, this means that people experiencing disabilities are
not excluded from participating or understanding the information shared.
When planning your meetings, you should consider the needs of people experiencing the following types of
disabilities:
• Visual impairments and blindness
• Hearing loss and deafness
• Mobility disabilities, which means having difficulty getting around, such as people who require
wheelchairs or canes
• Neurological disorders
These tips can help you ensure that the following participants have full access to your meetings:
People with visual impairments
Presentation materials
• Use a large font size (minimum 22 points).
 • Use high-contrast colors.
• Provide alternative text descriptions for all images, pictures, graphics, tables, and so on.
• Provide low-vision or blind attendees with an accessible electronic format of the presentation.
• Provide presentation materials in an accessible electronic format to participants ahead of time.
• Describe all meaningful graphics in your presentation (such as photos, images, charts, and
illustrations).
Handouts and printed materials
• Use a large font size (minimum 18 points).
• Use black lettering on white, matte paper.
• Use a simple font and avoid compressed fonts and italics.
• Use 1.25 to double spacing between lines.
People who are deaf or hard of hearing
• Always face the person you are communicating with. This is especially helpful for audience members
who are speech readers.
• Speak clearly, at a moderate pace and volume, and allow the other person time to respond. Avoid
exaggerating, slowing your speech, or speaking loudly.
• Ask for clarification if you don’t understand something the person is communicating.
• Include all of the information presented in a spoken presentation on slides.
• Add closed captions or subtitles to videos. YouTube Help provides instructions for adding your own
closed captions to your videos.
People with mobility impairments
• Provide ample circulation space in your meeting room so that people using mobility devices can
easily pass through.
• Offer accessible seating locations throughout the room.
• For presentations, use half-round seating so that all participants may face in the direction of the
speaker.
People with neurological disorders
• Provide an agenda or task list to allow time for participants to understand content and expectations
• Make sure any video call platform you use allows closed captioning
• Be sure to record the meeting, and provide easy access to the recording to all meeting participants
• For handouts or presentations, use simple page layouts that are easy to understand and use.
 • For resource materials, break up passages of text with images, graphs, or illustrations to highlight the
context
• Avoid using presentations with moving or flickering content, or background audio that cannot be
turned off
Key takeaway
Creating meetings that are inclusive and accessible to all participants will improve your team’s engagement,
productivity, and morale.

Checklist for productive meetings

You may have attended a few meetings that you did not think were the best use of your time. Frequent and
unproductive meetings tend to have a negative impact on individual and team productivity and well-being.
In this reading, you will learn best practices for ensuring productivity before, during and after meetings.
Plenty of things can make meetings unproductive, but an internal study at Google revealed that productive
meetings have three elements in common:
1. Active participation from attendees
2. A clear and concise agenda that is followed throughout
3. The correct attendees (meaning the participants can contribute to achieving the meeting’s goal)
Follow this checklist to help achieve these aims and facilitate more productive meetings for you and your
project team:
Before the meeting
• Prepare an agenda that states the purpose and goals of the meeting, and share the agenda with
participants.
• Only invite people who need to be there and who can help reach the goals of the meeting. Make
participants’ roles and responsibilities for the meeting clear. Add non-essential participants as
optional to the meeting invitation.
• If you are working with people in different time zones, share the time zone burden by alternating
recurring meeting times.
• Evaluate the need for the meeting and cancel if it isn’t necessary. Consider whether the meeting
content can be covered via email.
• Schedule shorter meetings. Meetings tend to expand to the time allotted to them, so try to get more
done in a shorter amount of time.
• Set aside time to prepare for the meeting. Read the necessary materials, review the agenda, and
come ready to participate.
During the meeting
• At the beginning of the meeting, clearly state the meeting goals. Stick to the agenda throughout the
meeting to avoid getting derailed. For recurring meetings, review the action items from the previous
meeting to ensure accountability.
• Encourage participants to put phones and laptops away during meetings and silence notifications, if
possible.
• Practice and demonstrate active listening. Respond verbally (e.g., “That makes sense. Tell us more.”)
and non-verbally (through head nodding and eye contact) to show engagement.
• Encourage participation and give everyone a chance to speak, including remote participants. Ask
open-ended questions like, “What does everyone think?” instead of “Does everyone agree?”
• Help everyone relax and feel more comfortable by starting meetings with open-ended, personal
questions like, “How was your weekend?”
• Capture key points, action items, and decisions from the meeting, and assign action items to the
appropriate meeting participants.
After the meeting
• Recap key decisions, action items, timelines, and notes and send out to participants.
• Schedule necessary follow-up meetings with relevant context.
• Assess the need for and frequency of recurring meetings. Schedule meetings less frequently, if
possible.
Pro Tip: If you are new to the company or team, find out about and try to apply their typical meeting
practices before making any major changes.
Key takeaway
Productive meetings generally require active participation from attendees, a clear and concise agenda that
is followed throughout, and the correct attendees. Following the best practices for before, during, and after
meetings described here can help you have more productive meetings. When less time is needed for
meetings because meetings are more productive, more time can be devoted to project tasks.

Case study: The impact of skipping project closure steps

In the video, we discussed the importance of the last phase of the project life cycle: closing the project. You
learned that, in order to close a project, you must ensure that:
• All work is done.
• All agreed-upon project management processes have been executed.
• You have received formal recognition and agreement from key stakeholders that the project is done.
In this reading, we will discuss the impact of skipping important project closure steps.
Sometimes project closure is improperly conducted or never happens at all. This can have a major impact
on your organization’s overall profitability and success. Skipping the closure phase can compromise a project
that had otherwise been running smoothly. No matter how successful the project may look in its final
stages, your job as a project manager is not complete until all steps of the closure phase have been
completed.
Case study: Tilly’s Toys
In order to better understand what can happen when a project is not properly closed out, let’s examine a
possible scenario: Tilly’s Toys, a small children’s toy manufacturer, developed a new interactive piggy bank
that speaks and plays songs to help children learn number recognition, counting, and adding. Below are
several oversights that occurred as a result of not properly closing out the project.
Oversight #1: Not all of the work was completed.
What happened: When Tilly’s Toys received the final toy box from the packager, they realized that it did not
include the safety disclaimer that the toy includes small parts and should not be used by children under the
age of three. The design of this disclaimer had been included in the original Statement of Work but was
never completed.
Impact on the organization: When the missing disclaimer was discovered, Tilly’s Toys was not able to use
any of the boxes that had been created. They incurred significant costs to have the packager create all new
boxes including the disclaimer. Having to recreate the boxes also meant that they were not able to meet
their original launch date, which would have had the toys in stores before the holiday season. This oversight
cost the organization additional revenue and extended the project timeline and resources.
Oversight #2: The organization did not complete an important agreed upon project management process.
What happened: Tilly’s Toys customer, a regional chain of toy stores, required that all contractors working
on the project sign a non-disclosure agreement (NDA). The NDA stated that the contractors would not
disclose any information about the toy until its launch date. One of the educational experts contracted to
review the toy was never given this NDA. Not having received—or signed—this important form, the
contractor posted about the new toy on social media months before the toy’s launch date.
Impact on the organization: Sharing information with the public before the toy was launched was a breach
of contract between Tilly’s Toys and their customer. This breach put Tilly’s Toys at significant legal risk.
Oversight #3: Stakeholders and the project manager did not provide formal recognition and agreement
that the project was done.
What happened: Ames, the project manager, communicated with the customer throughout the toy’s
development about their objectives for the toy. After the previous oversights were rectified and Ames
assumed his team was done with the project, he released the team to work on other projects. Shortly after,
the customer sent a list of additional changes they wanted to see in the toy’s design.
Impact on the organization: Ames had to tell the customer that it was too late to implement their design
requests. The customer was unhappy and told Ames that they may consider using a different toy
manufacturer in the future.
Avoiding the impact of project closure oversights
Oversights or skipping steps in the closing phase of a project can:
• Impact the product’s or service’s scheduled launch dates.
• Put your organization at legal risk.
• Result in significant financial losses to your organization.
• Undermine your team's credibility, and yours.
• Damage your relationship with the customer or client.
All of the steps of the project life cycle—initiating the project, making a plan, executing and completing
tasks, and closing the project—are essential for a successful outcome. Unfortunately, closing the project is a
phase that too often gets skipped, which can negatively impact both the project manager and their
organization. To avoid these issues, make sure to plan for this phase just as you would any of the other
project life cycle phases.

Demonstrating project impact to stakeholders

Previously, you learned why completing the closing phase of the project life cycle is important. As we
discussed, a formal closing process is essential because improper closing may leave you at risk for
incomplete contracts and scope. It is also important to make sure that all stakeholders feel like their needs
are met and to review areas for improvements in the future.
In this reading, we will further discuss how to demonstrate the impact of your project to your stakeholders
through impact reporting. Impact reporting is a presentation or formal report prepared for key stakeholders
at the end of a project.
Highlight key performance areas
The purpose of your impact report is to show your key stakeholders the impact your project had on the
organization. Goals, objectives, budget, schedules, and key performance indicators (KPIs) need to be
determined at the beginning of your project. Your impact report should demonstrate how well you did
against those early targets. In your report, you should also answer the question: What was the problem we
were trying to solve, and how did we solve it? This will help you showcase the value your project outcome
brought to the business.
Highlight these key performance areas to demonstrate to your stakeholders how you achieved successful
results and outcomes:
• First, describe the goals and objectives you set for the project and what you hoped to have achieved
by the end.
• Then, describe how you met those objectives against your KPIs. A KPI is a measurable value that
demonstrates how effective a company is at achieving their objectives. In your impact report, review
how you defined the success of your project at the beginning, and highlight the outcomes you
achieved that demonstrate this success.
• Finally, showcase your schedule and budget performance by outlining your cost savings and
efficiencies. Demonstrate that you met the deadlines set in your project scope and that your project
was completed within budget.
Use metrics to showcase your results
Use facts and statistics to highlight the results you achieved related to the performance areas described in
the section above. Examples of common metrics you might include to demonstrate a positive impact could
include:
• Improvement in schedule performance
• Revenue growth
• Positive return on investment (ROI)
• Increased external user counts
• Increased percentage of internal users
• Cost vs. margins
• High percentage of customer satisfaction
 • Reduction in overhead
• Reduction in technical issues
• Time saved

Metrics and data points are one of the best ways to present impact. Throughout your project, collect data
and track progress in each of the areas you want to measure. If you can complement your metrics with the
appropriate visuals and tie them back to the project’s larger goals, you can quickly demonstrate your
project’s success and value.
Prepare an effective impact report presentation
An effective presentation can help your stakeholders understand your project’s impact. In order to
successfully convey all of the information you have prepared:
• Be concise. While you should share metrics that illustrate how you achieved your project goals, you
do not need to include extraneous details. For clarity, organize information by using bullet points
instead of paragraphs.
• Understand your audience. Make sure that your report does not use too much technical language or
jargon to help your stakeholders understand it.
• Use visuals. Use a digital presentation application, such as Google Slides, Microsoft PowerPoint, or
Canva to present your impact report. Add diagrams, such as charts and graphs, to illustrate your
results. Use images to add visual interest. Add icons to draw attention to information and help your
stakeholders quickly understand information.
• Describe your learnings. Discuss lessons you learned during the course of the project and any areas
you have identified for improvement.
• Keep your stakeholders engaged. Grab and keep your stakeholders’ attention by varying the way
that you present your data:
1. Show: Play videos of demos, testimonials, or case studies.
2. Storytell: Tell a story or anecdote related to the data in the report.
3. Engage: Ask for audience participation through questions, surveys, or quizzes.
Key takeaways
As a project manager, impact reporting is a great opportunity to demonstrate the impact of your project and
the value you bring to your organization. By highlighting key performance areas, using metrics to showcase
results, and preparing an effective presentation, you can impress your stakeholders and convince them of
your project’s success.