Оглавление

Course1.......................................................................................................................................................5
3 Strong organizational skills...................................................................................................................5
Recognize efforts....................................................................................................................................6
The project life cycle................................................................................................................................7
Initiate the project..............................................................................................................................7
Make a plan........................................................................................................................................8
Execute the project.............................................................................................................................8
Close the project.................................................................................................................................8
What is a PMO?.......................................................................................................................................9
What are the functions of a PMO?...........................................................................................................9
Strategic planning and governance.......................................................................................................9
Best practices.....................................................................................................................................10
Common project culture.....................................................................................................................10
Resource management........................................................................................................................10
Creation of project documentation, archives, and tools.......................................................................10
Understanding an organization’s culture.................................................................................................10
Ask questions.........................................................................................................................................10
Atmosphere........................................................................................................................................11
Policies..............................................................................................................................................11
Processes............................................................................................................................................11
Values................................................................................................................................................11
Listen to people’s stories........................................................................................................................11
Take note of company rituals.................................................................................................................11
The Family Java culture.........................................................................................................................12
CHANGE MANAGEMENT.......................................................................................................................13
Course 2....................................................................................................................................................14
Intiation.....................................................................................................................................................14
Scenario.................................................................................................................................................14
cost-benefit analysis (CBA).........................................................................................................15
This technique is useful during the feasibility study to determine if the project is worth taking.
..............................................................................................................................................................15
Costs................................................................................................................................................15
Benefits...........................................................................................................................................16
SMART goals......................................................................................................................................17
how they will do it, whether it's possible, why it’s important when they will get it done.............17
OKRs......................................................................................................................................................18
 Scope.....................................................................................................................................................19
Scope creep...........................................................................................................................................19
Triple constraint........................................................................................................................................20
Scenario.................................................................................................................................................20
Success Criteria..........................................................................................................................................21
Stakeholders..............................................................................................................................................21
Document each stakeholder’s roles and needs....................................................................24
RACI chart.................................................................................................................................................26
Resourses..............................................................................................................................................26
Course 3....................................................................................................................................................27
Planning....................................................................................................................................................27
Кick-off meeting....................................................................................................................................27
Kick-off meeting best practices..............................................................................................................27
Task and milestones..............................................................................................................................28
WBS.......................................................................................................................................................29
Project Plan...........................................................................................................................................29
CASE......................................................................................................................................................30
Bad planning..........................................................................................................................................30
Case.......................................................................................................................................................31
Planning fallacy......................................................................................................................................31
Planning fallacy refers to faulty predictions about how much time you need to complete a
task.......................................................................................................................................................31
CAPACITY PLANNING.............................................................................................................................32
FLOAT....................................................................................................................................................32
CRITICAL PATH.......................................................................................................................................32
Step 3: Create a network diagram.......................................................................................................33
Estimates from team.............................................................................................................................35
Creating a project plan.........................................................................................................................36
Managing budgeting and procurement.................................................................................................37
Project budgeting best practices.............................................................................................................38
Direct costs.......................................................................................................................................39
Indirect costs....................................................................................................................................39
Tips for the procurement process.....................................................................................................43
Tips for initiating...................................................................................................................................43
Tips for selecting....................................................................................................................................43
Tips for contract writing.........................................................................................................................43
Tips for controlling................................................................................................................................44
 Tips for completing................................................................................................................................44
Common procurement documentation............................................................................................44
Navigating procurement challenges..................................................................................................45
RISK MANAGEMENT.................................................................................................................................46
Types of risk...........................................................................................................................................50
Types of dependencies...........................................................................................................................50
Finish to Start (FS).............................................................................................................................50
Finish to Finish (FF)...........................................................................................................................50
Start to Start (SS)...............................................................................................................................50
Start to Finish (SF).............................................................................................................................51
Dependency graphs................................................................................................................................51
Managing single point of failure risks..............................................................................................52
Case study: Using mitigation strategies to manage single point of failure risks.......................................52
Avoid.................................................................................................................................................52
Minimize...........................................................................................................................................52
Transfer............................................................................................................................................52
Accept...............................................................................................................................................52
COMUNICATION....................................................................................................................................53
Best practices for building a communication plan........................................................................53
Tips for creating your communication plan............................................................................................53
Identify, identify, identify...................................................................................................................53
Document and develop.......................................................................................................................54
……………………………………………………………….............................................................................................55
Tip..........................................................................................................................................................55
Tell to interview about your desire to study . і проекти дають цю можливість..................................55
COURSE 4...............................................................................................................................................56
Choose the right tracking method for your project.......................................................................56
Gantt charts................................................................................................................................................56
Roadmaps..................................................................................................................................................56
Burndown charts........................................................................................................................................56
Project status reports...........................................................................................................................57
Key components of a project status report..............................................................................................57
Project status report types.......................................................................................................................58
Dependencies........................................................................................................................................59
ROAM........................................................................................................................................................60
Escalation................................................................................................................................................60
Writing an effective escalation email................................................................................................60
Escalation email best practices...............................................................................................................60
Maintain a friendly tone.....................................................................................................................61
State your connection to the project....................................................................................................61
Explain the problem...........................................................................................................................61
Explain the consequences...................................................................................................................61
Propose a course of action and make a request...................................................................................62
Putting it all together..........................................................................................................................62
 Course 1
TEST

1 Which of the following best describes why there is increasing demand for project
management roles in today’s job market?

Project management roles are designed to adapt to changes and handle new processes as they
come up.

2 What are the core job responsibilities of project managers?

The project manager is responsible for planning, organizing, managing tasks, budgeting,
controlling costs, and other factors to help keep the project within budget and on time. 

3 Strong organizational skills

 Planning and scheduling software (templates, workflows, calendars)

 Collaboration tools (email, collaboration software, dashboards)
 Documentation (files, plans, spreadsheets)
 Quality assurance tools (evaluations, productivity trackers, reports)

4 How did the project manager remain flexible in the project?

When the client requested to change the theme of the retreat, the
project manager had to stay flexible. They worked with teammates to
get the necessary changes in place quickly.

5 How might you influence this situation without authority?

Talk to your co-worker about the overall schedule for the retirement party, and explain to them how
selecting a venue as soon as possible is critical to the success of the overall event and will
determine what the date of the party will be. Midweek, consider sending your co-worker a gentle
reminder about their end of week commitment and ask how it's coming along.
 RISKS
For example, what if someone on your team gets sick or decides to quit? Are you able to replace
them within the company? If not, can you hire an independent contractor? Come up with a list of
people who may be able to join your team if one of your team members becomes unavailable.

SCENARIO

A co-worker is responsible for researching and providing you with a list of potential
venues for a retirement party. For the last three weeks, they have been telling you they
will complete the list by “the end of the week (EOW).” When you check in with them at
the beginning of each of the weeks, they tell you they didn’t get around to completing it
but that it will be done by the current week.

Solution:

Ask your co-worker about their current workload and see if there is anything you can do
to free up their schedule. You can also offer to get someone else to help them, if
needed.

Midweek, consider sending your co-worker a gentle reminder about their end of week
commitment and ask how it's coming along.
 Recognize efforts

Sometimes, when you work with cross-functional teams, there are certain skills that get
recognized more than others. A mechanic could get accolades for coming up with the solution to
a problem within the project, while the finance member who sourced the funding might be
forgotten. As a project manager, it is your job to make sure that each member of your
cross-functional team recognizes the value of their efforts each step of the way. You have
learned the importance of building relationships with stakeholders, and building relationships
with your cross-functional team members is just as important. Learning what makes your team
members feel supported, giving and taking feedback, and being mindful of each individual's
background, personal identifiers, and work style can help mediate some of the differences among
team members. 
 CASE

Imagine that a project manager has just begun working on a project for a trucking
logistics company. The customer wants to see a proposal as soon as possible, but it is taking the
project manager longer than expected because he needs more input from stakeholders and the
project team. What should the project manager do to turn the project into a success?

Ask the customer for more time to consult with stakeholders and the project team to deliver
an accurate cost and timeline proposal.

The project life cycle

Initiate the project

In this phase, ask questions to help set the foundation for the project, such as:

 Who are the stakeholders?

 What are the client’s or customer’s goals?
 What is the purpose and mission of the project?
 What are the measurable objectives for the team?
 What is the project trying to improve? 
 When does this project need to be completed? 
 What skills and resources will the project require? 
 What will the project cost? What are the benefits?

Make a plan

In this phase, make a plan to get your project from start to finish. 

 Understand risks

 Create a detailed project plan. What are the major milestones? What tasks or deliverables
make up each milestone? ( Які завдання чи результати складають кожен milestone?)
 Build out the schedule so you can properly manage the resources, budget, materials, and
timeline. Here, you will create an itemized budget.
Execute the project

In this phase, put all of your hard work from the first two phases into action.

 Monitor your project team as they complete project tasks. 

 Break down any barriers that would slow or stop the team from completing tasks. 
 Help keep the team aware of schedule and deliverable expectations.
 Address weaknesses in your process or examine places where your team may need
additional training to meet the project’s goals.
 Adapt to changes in the project as they arise.

Close the project

In this phase, close out the project.

 Identify that your team has completed all of the requested outcomes. 
 Release your team so they can support other projects within the company.
 Take time with your team to celebrate your successes!
 Pass off all remaining deliverables and get stakeholder approval.
 Document the lessons you and your team learned during the project.
 Reflect on ways to improve in the future.

////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
LEARN MORE ABOUT FACILITATION
/////////////////////////////////////////////////////////////////////////////////////////////////////////////

Which project management methodologies should you use?

https://www.teamwork.com/project-management-guide/project-management-
methodologies/

……………………………………………………………………………………….

MATRIX STRUCTURE

https://www.pmi.org/learning/library/matrix-organization-structure-reason-evolution-1837

/////////////////////////////////////////////////////////////////////////////////////////////////////////////////
What is a PMO?

A Project Management Office, or PMO, is a group within an organization that

defines, sets, and helps maintain project management standards and processes
throughout that organization. It often acts as a coordinated center for all of the
organization’s projects, helping them run more smoothly and efficiently.

An organization’s project managers may operate within the PMO itself or within
other departments. At Google, for example, there are project managers who work
in a PMO focused on operational excellence, but there are numerous project and
program managers in other departments throughout the organization, as well.

What are the functions of a PMO?

PMOs offer guidance and support to their organization’s project managers. They
share best practices, project statuses, and direction for all of the organization’s
projects while often taking on strategic projects themselves. The main functions of
a PMO include:

Strategic planning and governance

This is the most important function of a PMO. This involves defining project
criteria, selecting projects according to the organization’s business goals, and then
providing a business case for those projects to management. 

Best practices
PMOs help implement best practices and processes within their organization. They
also share lessons learned from previous successful projects. They help ensure
consistency among their organization’s projects by providing guidance about
processes, tools, and metrics.

Common project culture 

PMOs help set common project culture practices by training employees about
optimal approaches and best practices. This helps keep project management
practices consistent and efficient across the entire organization. 
Resource management
PMOs are often responsible for managing and allocating resources—such as
people and equipment—across projects throughout the organization based on
budget, priorities, schedules, and more. They also help define the roles and
responsibilities needed on any given project. PMOs provide training, mentoring,
and coaching to all employees, but project managers in particular. 

Creation of project documentation, archives, and tools

PMOs invest in and provide templates, tools, and software to help manage
projects. They also play an important role in maintaining their organization’s
project history. Once a project closes, they archive all of the documents created
during the project for future reference and to capture lessons learned.

ORGANIZATION’S CULTURE

Understanding an organization’s culture

As a project manager, it is important to understand your company’s culture, especially
because it could affect the projects you work on. Some aspects of an organization’s
culture that are directly related to how you will manage projects are communication,
decision-making, rituals, previous management styles, and values. To learn more about
a company’s culture and how it applies to you as a project manager, you can: 

Ask questions
You can learn about an organization's culture by asking questions of management and
peers. It can be helpful to ask these questions in the interview phase to better
understand the company’s culture before accepting a position. You might want to ask
questions about:

Atmosphere

 What is the company’s dress code? 

 How do people typically share credit at this company? 
 Is risk-taking encouraged, and what happens when people fail?
 How do managers support and motivate their team?
 How do people in this role interact with customers and users?
 When and how do team members give feedback to one another?
 What are some workplace traditions?
 What are some of the ways the company celebrates success?
Policies

 What are the policies around sick days and vacation?

 Does the company allow for employee flexibility (e.g., working from home, flexible
working hours)?
 What policies are in place that support employees sharing their identity in the
workplace?

Processes

 What is the company’s onboarding process?

 How do employees measure the impact of their work?

Values

 What are the company’s mission and value statements?

 How might the person in this role contribute to the organization’s mission?
 How does the organization support professional development and career growth?

Listen to people’s stories

Listening to what current employees have to say and how they portray the company will
give you great insight.

 What were employees' experiences with similar projects in the past? 

 What can they tell you about key stakeholders and customers? 

Take note of company rituals

Rituals can be powerful drivers of culture. They engage people and help instill a sense
of shared purpose and experience. 

 How are birthdays and holidays celebrated? 

 Do employees generally eat lunch at the same time and in the same place? 
 Watch employee interactions: Observing how employees interact can help you
tailor your interaction style to the company norm. 
 Are employee interactions more formal or informal in nature? 
 Are ideas solicited from employees in different roles? 
 CASE

The Family Java culture

Mission

 To provide a welcoming environment where our employees become our family and
our guests become our friends
Values

 To create a place where everyone is welcome

 To always give our best and hold ourselves accountable for the results
 To treat others with respect and kindness

Avi was excited to begin his role as a project manager at The Family Java. He had
asked questions about the organization’s culture during his job interview and was
told about the company’s people-first approach.
He also asked for suggestions and guidance based on what had been done at the
company in the past

Before beginning his first project, Avi planned a team lunch to get to know everyone
at The Family Java. Then, he scheduled one-on-one meetings with each of his team
members to learn more about their working style and professional goals. He also asked
how he could help support and remove any barriers for them.

CHANGE MANAGEMENT

https://www.prosci.com/change-management

https://www.prosci.com/resources/articles/change-management-at-the-project-level

https://docs.google.com/presentation/d/
1YMVERX1vBsknCjbCtsKFmHgWWZxFcO5A3urvWbWXKbs/template/
preview?resourcekey=0-_V7hj-KwQu75EI2Y9qpsTw
 Course 2
Intiation
Six key components of project initiation:

 Goals

 Scope

 Project deliverables

 Success criteria

 Stakeholders

 Resources

Scenario
Imagine you are a project manager at an educational software company. You’re assigned a new
project to develop a digital grading platform for a local high school. Before beginning the project, you
meet with teachers, school administrators, the school IT department, and the district superintendent
to discuss the project and get their input. 

During these meetings, you organized your thoughts by writing down project key components that
the stakeholders have requested. Your notes on the key components are:

 $150,000 maximum budget  

 Team: can add one member from the school IT department  
 Platform should allow teachers to enter grades and allow students/parents to view grades  
 Need full teacher buy-in at high school: 100% adoption within next nine months   
 Project should focus only on the digital grading platform and NOT impact other digital platforms (ex.
attendance, school lunch payments)  
 Overall, the school is seeking a platform for digital grading

Question 1
Which of the key components is the project’s goal? Write one sentence.

To launch a digital grading platform for the high school and get full teacher adoption

Question 2

Which key component outlines the project’s scope? Write one sentence.

Creating the digital grading platform and not updating other digital platforms the school uses such as
attendance or meal payments.
Question 3
Which key component is the project deliverable? Write one sentence.

A platform for teachers to enter grades and students to view their grades.

Question 4
Which key component outlines the project’s success criteria? Write one sentence.

100% of teachers adopt the digital grading platform within the next nine months

Question 5
Who are the project stakeholders? Write one sentence.

Stakeholders are people who have an interest in, or are affected by, the completion of a successful project:
teachers, students, parents, school administrators, school IT department, and the district superintendent

Question 6

Which key components outline the resources you will have at your disposal for the project?

Resources generally refer to the budget, people, and materials available to complete the project. In the
scenario, it’s the budget of $150,000 and the member from the school’s IT department.

 Cost-benefit analysis (CBA)

This technique is useful during the feasibility study to determine if the

project is worth taking.

For our cost-benefit analysis example, we’ll do an assessment of a

project that involves delivering a product as its main goal.

Costs

 Direct costs: These are all the costs that are directly related to
the manufacturing of the product. Such as materials, equipment,
labor, etc.
 Indirect costs: Other expenses that are not directly related to
the product such as rent, utilities, or transportation costs.

 Intangible costs: Any other costs that are can’t be quantified,

such as the brand damage if the market doesn’t respond
positively to the product.

 Opportunity costs: The loss of opportunities that occurs when

a decision is made instead of another. For example, you could
have chosen to manufacture a product that could have been
more profitable than the one you chose to make.

 Costs of potential risks: Any project is susceptible to a variety

of risks. You should always consider that you might have
unexpected costs at some point.

Benefits

 Direct Benefits: The measurable benefits in monetary value

that you get from the project. In this case, the revenue, sales
and profit obtained from your product.

 Indirect Benefits: Benefits that you can perceive but not

necessarily measure such as increased brand awareness.


 SMART goals

how they will do it, whether it's possible, why it’s

important when they will get it done

SMART goals are specific, measurable, attainable, relevant, and time-bound. Metrics, such as

figures or numbers, make goals measurable. The accuracy of metrics are confirmed with points of

reference, called benchmarks.

 Specific: The objective has no ambiguity for the project team to misinterpret. 
 Measurable: Metrics help the project team determine when the objective is met.
 Attainable: The project team agrees the objective is realistic.
 Relevant: The goal fits the organization’s strategic plan and supports the project charter.
 Time-bound: The project team documents a date to achieve the goal.

explain what makes goal SMART by answering the following questions:

1. What makes the goal specific? Does it provide enough detail to avoid ambiguity?
2. What makes the goal measurable? Does it include metrics to gauge success?
3. What makes the goal attainable? Is it realistic given available time and resources?
4. What makes the goal relevant? Does it support project or business objectives?
5. What makes the goal time-bound?Does it include a timeline or deadline?

Example:

You set a goal to complete a Google Career Certificate. You can measure the success
of this goal because after completing the entire program, you will receive a certificate—
a tangible outcome.

Now, let’s determine how to make the remaining elements of this goal SMART. In this
example, your specific goal is to attain a Google Career Certificate. You can make this
goal attainable by deciding that you will complete one course per month. This goal is
relevant because it supports your desire to make a career change. Finally, you can
make this goal time-bound by deciding that you will complete the program within six
months.

OKRs
OKR is an acronym for objectives (what?) and key results (how?). Objectives define what needs to

be achieved and describe a desired outcome. Key results define how the project team knows

whether or not they have met their objective.

As a project manager, OKRs can help you expand upon project goals and further clarify the
deliverables you’ll need from the project to accomplish those goals. Project-level OKRs help
establish the appropriate scope for your team so that you can say “no” to requests that may get in
the way of them meeting their objectives. You can also create and use project-level OKRs to
help motivate your team since OKRs are intended to challenge you to push past what’s easily
achievable.

OBJECTIVE: Delight our company customers

Key results:

 Interview 20 customers per month and get feedback

 Achieve an NPS of 9 from our customers
 Increase customer retention to 98%
 Achieve a product engagement of 80% WAU

Scope
The scope provides the boundaries for your project. You define the scope to help
identify necessary resources, resource costs, and a schedule for the project.
 Taking the time to ask questions and ensure that you understand the scope of the
project will help reduce expenses, rework, frustration, and confusion.

Make sure you understand the who, what, when, where, why, and how as it applies to
the scope.

Scope creep
Scope creep includes changes, growth, and uncontrolled factors that affect a project scope at any
point after the project begins. Scope creep is a common problem, and it's not always easy to control.

Here are some best practices for scope management and controlling scope
creep:

 Define your project’s requirements. Communicate with your stakeholders or customers

to find out exactly what they want from the project and document those requirements
during the initiation phase. 
 Set a clear project schedule. Time and task management are essential for sticking to your
project’s scope. Your schedule should outline all of your project’s requirements and the
tasks that are necessary to achieve them.
 Determine what is out of scope. Make sure your stakeholders, customers, and project
team understand when proposed changes are out of scope. Come to a clear agreement
about the potential impacts to the project and document your agreement. 
 Provide alternatives. Suggest alternative solutions to your customer or stakeholder. You
can also help them consider how their proposed changes might create additional risks.
Perform a cost-benefit analysis, if necessary.
 Set up a change control process. During the course of your project, some changes are
inevitable. Determine the process for how each change will be defined, reviewed, and
approved (or rejected) before you add it to your project plan. Make sure your project
team is aware of this process.
 Learn how to say no. Sometimes you will have to say no to proposed changes. Saying
no to a key stakeholder or customer can be uncomfortable, but it can be necessary to
protect your project’s scope and its overall quality. If you are asked to take on additional
 tasks, explain how they will interfere with the budget, timeline, and/or resources defined
in your initial project requirements. 
 Collect costs for out-of-scope work. If out-of-scope work is required, be sure to document
all costs incurred. That includes costs for work indirectly impacted by the increased
scope. Be sure to indicate what the charges are for. 

Triple constraint

Scenario
Imagine you are a User Experience (UX) Program Manager at a small design agency. You are asked to
manage an 8-week project for $800,000 USD. The project includes conducting field research and
synthesizing results. As the final deliverable, your agency will create a research report and facilitate a 3-
day workshop. You need to align with the client’s Vice President (VP) of Design, Ria. Luckily, you have a
team of five teammates to work on this project together!

Situation 1

During the scoping of this project, Ria says her budget maxes out at $650,000 USD—she can’t
afford the $800,000 USD that this project will cost. What are some proposals you can provide to Ria
to reduce the budget? Think of the Triple Constraint and remember that one constraint will always
have the priority. So if the budget is a constraint, what areas might Ria adjust to reduce project
costs?

Reduce the scope: Maybe you can convince Ria to have a 1-day workshop instead of a 3-day
workshop. This will help trim the budget. 

Reduce the time: If you can deliver just the research report presentation instead of a 3-day
workshop, you can trim the budget by shaving-off the three workshop days. This also reduces the
time you need to prepare for the workshop.

Situation 2

Recruiting for field research will take a week longer than expected. However, Ria told you that the
project end date is a hard deadline. What can you do?

Increase the budget: If you can increase the budget and add an additional field researcher, you
could complete the research faster and meet the hard deadline.

Cut the scope: If you can eliminate sections in the research report, you could save time. Or, similar
to the example above, cut the workshop to a 1-day workshop to meet the deadline
 Situation 3

After the stakeholders agree on the project scope, Ria finds out that her CEO wants more
information in the research report. She asks you to include details on the market opportunities for
new product ideas, technical constraints, and design considerations. How do you manage this
additional scope?

Decrease the time: If you can cut the depth of the initial market research, you will shave a few days
off the project. This will allow additional time to work on the information on new products at the end
of the project.

Increase the cost: If Ria can agree to increase the project budget to accommodate her CEO's
request, you can add additional team members to work on the expanded scope and meet the
existing project timelines.

Success Criteria

 Evaluating user engagement with the product 

 Measuring stakeholder and customer satisfaction via surveys
 Tracking user adoption of the product by using sales data

Stakeholders

Internal stakeholders
 These stakeholders are coming from within the house!!! Internal
stakeholders are people or groups within the business, such as team
members, managers, executives, and so on.

External stakeholders

External stakeholders are — as you can probably guess — people or

groups outside the business. This includes customers, users,
suppliers, and investors.

Let’s review the key steps in the stakeholder analysis:

1. Make a list of all the stakeholders the project impacts. When generating this list, ask yourself:
Who is invested in the project? Who is impacted by this project? Who contributes to this
project? 
2. Determine the level of interest and influence for each stakeholder—this step helps you
determine who your key stakeholders are. The higher the level of interest and influence, the more
important it will be to prioritize their needs throughout the project. 
3. Assess stakeholders’ ability to participate and then find ways to involve them. Various types of
projects will yield various types of stakeholders—some will be active stakeholders with more
opinions and touchpoints and others will be passive stakeholders, preferring only high-level
updates and not involved in the day-to-day. That said, just because a stakeholder does not
participate as often as others does not mean they are not important. There are lots of factors that
will play a role in determining a stakeholder’s ability to participate in a project, like physical
distance from the project and their existing workload.
 Рисунок 1 power grid

Tips for gaining key stakeholder buy-in include: 

 Clearly mapping the work of the project to the goals of the stakeholder.
 Describing how the project aligns with the goals of the stakeholder's department or
team.
 Listening to feedback from the stakeholder and finding ways to incorporate their
feedback into the project's charter where appropriate.

short
For key stakeholders, this might involve meeting up for a
face-to-face interview or conversation where you
discuss things like:
 What their definition of project success looks like

 Any concerns or reservations they have about the project or its

outcomes

 What their expectations for the project are

 What impact a positive or negative project outcome would have

on them
  Whether there are any anticipated conflicts of interest with other
stakeholders that you need to be aware of
 What role would you like to play within this initiative/project?

 Here’s how I plan to keep people informed; does that work for you?

 What can I clarify for you?

 Who else do you recommend I reach out to about this initiative?

 What information or insights do you have that might be challenging for

me to find?

 Where do you see me getting support for this initiative? Facing

resistance?

 What additional thoughts/questions do you have?

Document each stakeholder’s roles and needs

All that work you did identifying your stakeholders and their individual
needs in relation to your project? Put it to good use by compiling it into
a shared, accessible document to make sure you have a record of
everyone’s role and responsibilities and keep you all on the same
page.

Creating a stakeholder register for your project helps you to keep track
of a long list of people and priorities. With a definitive document you
can update, edit, and consult as your project progresses, you can
ensure that you’re always driving the project in the right direction and
keeping the right people informed at the right times.

Even if I think I've identified everyone (all stakeholders), at the end of every
conversation I ask, ‘Is there anyone else you'd recommend I connect with?’

If you haven't received an in-depth debriefing on the project, read the scope
document for the project. It likely will either explicitly list stakeholders or help
you deduce who the main stakeholders will be, such as types of end users
with an IT project. If someone else wrote the scope document, talk with that
person to ensure you're on the same page in terms of which stakeholders are
most critical. As humans, we are prone to make assumptions for sake of
efficiency, so you need an intentional mindset and process to reliably identify
stakeholders.

As the project sponsor, the Director of Product has a high level of influence on the project.
They are invested in the project’s success, but not involved on a day-to-day basis, so their
interest is medium. You should communicate with them regularly, but not daily, to ensure they
are satisfied with project progress.
 RACI chart
R: Responsible: who gets the work done

A: Accountable: who makes sure the work is done

C: Consulted: who gives input or feedback on work

I: Informed: who needs to know the outcome

If you are wondering if you should use a RACI chart on your project, it is a good idea to evaluate the
complexity of the effort. For example, if you have a very small project team with a small amount of
stakeholders, clearly defined roles, and a short timeline, introducing a RACI chart could possibly
slow down the project. However, larger projects, or even projects that involve a large number of
stakeholders, could greatly benefit from a RACI chart.

Resourses
Your project resources include things like the budget, people, and materials. As a project
manager, remembering that your resources are dependent on one another is key to
understanding the function of each resource and determining how to manage all of them. Take
the time to interview stakeholders and potential team members about what resources they think
they will need in order to deliver the project. They may have an idea of materials they require
that you may not have accounted for within the budget, for example, or can identify people with
expertise that would make them an asset to the project team. 
 Course 3
Planning

Why?

Кick-off meeting
a kick-off meeting is the first meeting among the project team, stakeholders, and
the project sponsor at the start of a new project or new project phase. The purpose
of a kick-off meeting is to ground everyone in a shared vision, ensure they
understand the project’s goals and scope, and make sure that they are all on the
same page about their roles and responsibilities on the project.

Kick-off meeting best practices

 Set the right time. Choose a meeting time that works for everyone. Be mindful of time
zone differences. 
 Set the right length. Choose an appropriate meeting length—no more than one hour.
You don’t want to waste people’s time, but you also don’t want to run out of time. Kick-
off meetings work best when you first share key information and then spend any
additional time on questions and team building.
 Invite the right people. Be strategic about including the appropriate people. The goal is
to invite attendees who play a role in the development and execution of the project,
such as all team members, stakeholders, and the project sponsor. You don’t want to
leave anyone out, but you also don’t want to invite people who shouldn’t be there.
 Designate a notetaker. The discussion that takes place during the meeting is important. It
is critical that you document any feedback, changes, or questions asked by attendees. If
you are leading the meeting, designate someone else to take notes before the meeting
starts. You can also use tools like Chorus Notetaker, Google Keep, Google Docs, or
Microsoft OneNote.  
 Set the agenda. To recap what we discussed in the video, a kick-off meeting agenda
should generally include: introductions, the project background and purpose, project
goals and scope, roles and responsibilities, the collaboration process and project tools,
what comes next (expectations and action items), and time for questions and
discussion.
 Share the agenda. Prior to the meeting, share the agenda with attendees via email and
identify speakers for each topic. By sending the agenda in advance, everyone will have
an idea of what to expect, time to prepare for anything they may need to present or
discuss, and time to generate questions or ideas.
 Stick to the agenda. During meetings, discussions can sometimes go off topic or take
longer than expected. As a project manager, it is your job to keep the meeting on track
by redirecting discussions to the items on the agenda. 
 Follow up after the meeting. After the meeting, make sure to send out a meeting
summary featuring the meeting notes and any action items.

Task and milestones

 A project task is an activity that needs to be accomplished within a set period of time
and is assigned to one or more individuals for completion. The work of a project is
broken down into many different project tasks. 
 A project milestone is an important point within the project schedule that usually
signifies the completion of a major deliverable. Milestones are significant checkpoints
in your project, and keeping track of them helps ensure that your project is on schedule
to meet its goals.

Here are some things to avoid when setting milestones: 

 Don’t set too many milestones. When there are too many milestones, their importance is
downplayed. And, if milestones are too small or too specific, you may end up with too
many, making the project look much bigger than it really is to your team and
stakeholders.  
 Don’t mistake tasks for milestones. Remember that milestones should represent
moments in time, and in order to map out how you will get to those moments, you need
to assign smaller tasks to each milestone.
 Don’t list your milestones and tasks separately. Make sure that tasks and milestones can
be visualized together in one place, such as a project plan. This will help ensure that
you are hitting your deadlines and milestones. 

WBS
A WBS is a deliverable-oriented breakdown of a project into smaller components. It’s a tool that sorts
the milestones and tasks of a project into a hierarchy, in the order they need to be completed. 

The main reason for a work breakdown structure is to make a project more manageable and
quantifiable by breaking up the work into smaller tasks.

Not every breakdown of project deliverables can be classified as a

WBS. For it to be called a work breakdown structure, it must have
certain characteristics:

 Hierarchy: The WBS is hierarchical in nature. Each “child” level exists

in a strict hierarchical relationship with the parent level. The sum of all
the child elements should give you the parent element.

 100% rule: Every level of decomposition must make up 100% of the

parent level. It should also have at least two child elements.

 Mutually exclusive: All elements at a particular level in a WBS must

be mutually exclusive. There must be no overlap in either their
deliverables or their work. This is meant to reduce miscommunication
and duplicate work.

 Outcome-focused: The WBS must focus on the result of work, i.e.

deliverables, rather than the activities necessary to get there. Every
 element should be described via nouns, not verbs. This is a big source
of confusion for beginners to WBS.

There are a few heuristics you can follow for determining work
packages:

 8/80 rule: A common rule of the thumb is that each work package
must be no longer than 80 hours and no less than 8 hours in total
length. If it is longer, decompose it further. If it is shorter, think of going
up by one level.

 Reporting period: Another common rule is to limit each work

package to a single reporting period. If it takes longer than one
reporting period (monthly, weekly, etc.), to accomplish, decompose it
further.

 Use nouns: You should be able to describe each work package with

a noun or an adjective. To break it down further, you’ll need to use
verbs. For example, “bike seat” is a noun describing a work package.
If you break it down further, you’ll need to use verbs like
“cut foam”, “stitch leather”, etc.

WBS helps you to:

 Estimate the cost of a project.

……..Параметрична оцінка……..
Метод є доволі схожим з попереднім, проте передбачає формування оцінки на основі
окремого параметру, наприклад — рядках коду, сторінках дизайну, діалогових вікнах,
таблицях бази даних і т.д. Якщо ми знаємо (з попередніх проектів), що на створення
дизайну однієї сторінки необхідно витратити три робочі дні, а новий проект передбачає
необхідність створення 20 сторінок, з цього можна зробити висновок, що на весь дизайн
знадобиться 60 днів.

 Establish dependencies.
 Determine a project timeline and develop a schedule.
 Write a statement of work (or SOW, one of your other acronyms).
 Assign responsibilities and clarify roles.
 Track the progress of a project.
 Identify risk.

WBS dictionary

What is a WBS dictionary? A WBS dictionary is formatted like the

hierarchical structure, but it includes a brief description of each work
package. When documenting a project, a WBS dictionary is often
included in addition to a visualization of the WBS. 

Project Plan
Project scope and goals, the Work Breakdown Structure (WBS), the budget, and management plans
are all important components of your project plan. They help define how basic project plan elements—
including tasks, milestones, people, documentation, and time—will be structured and utilized in your
project. However, no one project plan will be the same.
A project plan contains links to all of a project’s documentation and serves as a roadmap for the
team throughout the project. The central artifact in a project plan is the project schedule. 

Time estimation is a prediction of the total amount of time required to  complete a
task. 

Effort estimation is a prediction of the amount and  difficulty of active work

required to complete a task. 
 Effort estimation differs from time estimation in that effort quantifies  the amount
of time it will take a person to complete work on a task.  On the flip side, time
refers to the overall duration of the task from  start to finish. That includes inactive
time. 

Here's an example. 
The effort estimation for painting a wall might be 30 minutes, 
but time estimation might be 24 hours. 
That's because in addition to the 30 minutes of active painting time, 
there are also 23 and a half hours of inactive drying time. 

There's a helpful tool called a buffer that you can use during the planning phase
to protect against inaccurate effort estimates.

A buffer is extra time added to the end of a task or a project to account for unexpected
slowdowns or delays in work progress.

Buffers are important because they can provide some leeway,

just in case your time and effort estimates turn out to fall a bit short.
With a buffer, you can add extra time into your schedule, and
your project shouldn't fall off track when task delays inevitably arise.

CASE
Bad planning
Kendra sensed the project timeline was problematic right from the start of the project. Instead of
gathering information to support her concerns and sharing it with management, she decided to keep
the issue to herself. She moved faster towards the goal instead of slowing down and planning the
project thoroughly. 

Thorough and careful planning with her team could have helped Kendra identify
problems and solutions in advance, such as:

 Elimination of tasks. It is possible that all of the tasks initially listed didn’t need to be
completed. There may have been unnecessary work added in, and the team could have
completed the project without it.
 Increased team size. Kendra could have addressed the potential schedule risk by
requesting more resources early on in the project rather than trying to execute without
the necessary resources.
 Streamlining of activities. There may have been some tasks that could have been done
in parallel, or at least not in sequential order. 

Key takeaway
Be realistic when estimating time and effort for a project. Take the time to carefully
evaluate potential risks and the impact on the work, and talk to your team members
about these challenges. Don’t be afraid to escalate potential concerns to management.
Optimism is a trait of a great project manager and leader, but it can adversely affect
your projects when it comes to time estimation.

Case
Consider the following scenario: You are to oversee the project for a new textbook release for the fall
semester. You’ve done something similar before, so you feel confident speaking with the
stakeholders, project sponsor, and faculty director. You assure them the project will meet the 6-
month deadline.

Around three months into the project, you notice that your writers consistently miss the writing
deadlines you assign. Then you learn that a printer upgrade may delay printing the text books.
Unfortunately, you forgot to include this delay in your time estimation. Now you have to tell the
stakeholders that the project may not launch in time for fall.

What might you do differently next time to improve the outcome of this situation?

Before the project launch, the project manager should speak to the writers to more accurately
determine how long it takes to do their tasks.

The project manager might identify the printer technology as a task that is out of the team’s
control and add a task buffer. Additionally, when the project manager first learns about the printer
issue, they should immediately update the time estimation and inform stakeholders.

The project manager can also look towards potential time saving activities, including: eliminate
tasks, increase the team size to get more work done and meet the deadline, and streamline any of
the activities in order to complete them in parallel with other tasks.

All-in-all, it’s important to perform time estimation, effort estimation, and add buffers to build realistic
plans for reaching the project goal and ultimately, success!

Planning fallacy
Planning fallacy refers to faulty predictions about how
much time you need to complete a task.
The planning fallacy describes our tendency to underestimate the amount of time it will take to
complete a task, as well as the costs and risks associated with that task, due to optimism bias.
Optimism bias is when a person believes that they are less likely to experience a negative event.
CAPACITY PLANNING
Capacity refers to the amount of work that the people or resources 
assigned to the project can reasonably complete in a set period of time.

Capacity planning refers to the act of allocating people, and resources to project tasks. 
And determining whether or not you have the necessary resources required to complete
the work on time. During this process, you might find that you need more resources to
speed up the project timeline, like a second web developer, or a third writer.

Capacity planning allocates people and resources to project tasks and determines whether
you have the resources to complete the work on time.

FLOAT
Another best practice for capacity planning4, and creating a critical path 
includes identifying if a task has float, also sometimes known as slack. 

Float refers to the amount of time you can wait to begin a task before it impacts 
the project schedule, and threatens the project outcome.  
These are high priority tasks that have low to no wiggle room. This helps reinforce what
is, and what is not on your critical path. For instance, tasks on the critical path should
have zero float, meaning there is no room for delays. 
And tasks that do have float are not a part of the critical path. 

CRITICAL PATH
the critical path refers to the list of required project milestones you must reach to complete the
project schedule, as well as the mandatory tasks that contribute to the completion of each milestone.
You can think of the critical path as a framework that tells you, the project manager, where you are,
where you are headed, and when you will get there. 

How to create a critical path

Step 1: Capture all tasks 
When you first start working on your project schedule, you will capture all of the tasks
associated with the completion of the effort. Remember to use the key planning documents you
have created to get you to this point, such as your work breakdown structure (WBS). The
main goal in this step is to make sure that you aren’t missing a key piece of work that is required
to complete your project. When creating a critical path, focus on the essential, “need to do”
tasks, rather than the “nice to do” tasks that aren’t essential for the completion of the project.
Step 2: Set dependencies 
 Now that you have captured all of your critical tasks in list form, arrange those tasks in
order of completion by identifying dependencies. To determine dependencies, figure out
which tasks must be completed before other tasks can start. For example, you can’t
paint the outside of a house before the house is built, so the task of framing the walls
must come before the task of painting them. Identifying dependencies is key to a
successful project schedule. 

To figure out dependencies for each task, ask:

 Which task needs to take place before this task?

 Which task can be finished at the same time as this task?
 Which task needs to happen right after this task?

Step 3: Create a network diagram

One common way to visualize the critical path is by creating a network diagram.
Network diagrams, like the example below, sequence tasks in the order in which they
need to be completed, based on their dependencies. These diagrams help visualize:

 The path of the work from the start of the project (excavation) to the end of the project
(flooring)
 Which tasks can be performed in parallel (e.g., HVAC and plumbing) and in sequence
(e.g., plumbing then insulation)
 Which non-essential tasks are NOT on the critical path

Step 4: Make time estimates

After determining tasks and dependencies, consult key stakeholders to get accurate
time estimates for each task. This is a crucial step in determining your critical path. If
your time estimates are significantly off, it may cause the length of your critical path to
change. Time estimates can be reviewed and updated throughout the project, as
necessary. 
 Step 5: Find the critical path 

Now that you have your estimated durations for each task, add that information to your
network diagram:

If you add up the durations for all of your “essential” tasks and calculate the longest
possible path, you can determine your critical path. In your calculation, only include the
tasks that, if they go unfinished, will impact the project’s finish date. In this example, if
the “non-essential” tasks—like landscaping and driveway pavement—are not
completed, the house structure completion date will not be impacted. 

You can also calculate the critical path using two common approaches: the forward pass
and the backward pass. These techniques are useful if you are asked to identify the
earliest and latest start dates (the earliest and latest dates on which you can begin
working on a task) or the slack (the amount of time that task can be delayed past its
earliest start date without delaying the project).

 The forward pass refers to when you start at the beginning of your project task list and
add up the duration of the tasks on the critical path to the end of your project. When
using this approach, start with the first task you have identified that needs to be
completed before anything else can start. 
A forward pass is when you move forward through your network diagram to identify early start
and early finish dates.
 The backward pass is the opposite—start with the final task or milestone and move
backwards through your schedule to determine the shortest path to completion. When
there is a hard deadline, working backwards can help you determine which tasks are
actually critical. You may be able to cut some tasks—or complete them later—in order
to meet your deadline.  
A backward pass is when you count back from an end result to identify late start dates
and late finish dates.

 How to Use the Critical Path Method for Complete Beginners

 Critical Path Method: A Project Management Essential


Rare is the project that goes according to plan. You will invariably have
delays, scope changes, and client demands that will force you to hasten
some activities and delay others.

The Critical Path Method includes several measures to deal with such
contingencies:
1. Fast Tracking
Fast tracking is the process of running multiple activities on the critical path
in parallel in order to reduce overall project time.

Fast tracking is only possible for activities which don't have "hard"
dependencies, i.e. they don't depend completely on their predecessors to
start.

For example, you need to dig the foundation before you can build the walls
of a house. But while you're doing the digging, you can also buy bricks and
mix the cement.

Thus, while "build walls" is dependent on "dig foundation", you can run "buy
bricks" and "mix cement" in parallel to digging the foundation.

Obviously, fast tracking requires additional resources. It can also impact

overall quality since you're distributing resources to multiple tasks.
Good resource management will come in particularly handy in situations
where you need to run activities in parallel.

2. Crashing
What if you need to rush an activity because of an early deadline?

In such a situation, you can allocate additional resources to the activity to

bring it to completion faster.

This process is called 'crashing'.

Crashing is useful in activities which:

1. Benefit from having additional resources, i.e. follow a linear relationship
between resources and time to completion.

2. Can utilize resources from activities with high floats. Since there is
significant "slack" in these activities, you can delay them without
jeopardizing the project

Crashing is generally not recommended barring emergencies since it can

impact activities on and outside the critical path. If you have to do it,
however, divert resources from high float tasks, not those on the critical
path.

Negotiating effectively can help you influence a team member to make your project
their priority, by collaborating to find an outcome that works for everyone. 
For example, let's imagine that the website designer estimates it will take them 
two weeks to mock up the website design for review. But perhaps you were hoping that 
the estimate might be closer to one week. To arrive at an estimate that works for both
you and the designer, you might gently challenge the estimate by asking follow-up
questions. Perhaps you'd ask if their estimate includes mocking up designs for multiple
pages. If so, you might ask if the designer is able to share one or two pages with you 
 sooner than their proposed deadline. By asking questions, you can determine if their
estimate is flexible, or if you need to bring in an additional designer to support the
schedule. By negotiating effectively with your teammates, you can create a sense of
shared ownership over the project outcomes and create a schedule that aligns with
everyone's workload.

///////tip
Заохотити людину зробити якомога більше завдань: створити візуальний список з
конкретною кількістю завдань. І людина може бачити свій прогрес, та скільки ще
залишилося. (Чим менші списки, тим краще)
////////

Empathy refers to a person's ability to relate to the thoughts and feelings of others. 
Practicing empathy at work can be a very effective way to build trust with your team. 
Your teammates are humans, and each person can only do so much. When you're
discussing estimates with the team, you might practice empathy by asking each person
about their workload, including work outside of your project and the overall work-life
balance. 

Creating a project plan

Regardless of what tool you use, be sure to include this key information: 

 Task ID numbers or task names: You might end up with dozens, hundreds, or even
thousands of tasks in a project. Assigning a task ID or name makes it easy to find and
reference a task when communicating with team members and stakeholders. 
 Task durations: A task duration is the amount of time you estimate that task should take.
Adding task durations to your project plan helps you organize and prioritize the tasks in
the project to help ensure you hit your goal on time. 
 Start and finish dates: Including start and finish dates for each task helps you track
whether you are progressing on time or not. 
 Who is responsible for what: Including each team member’s role and responsibilities
helps promote clarity and efficiency. As a best practice, assign an owner to each task,
as well.
 Managing budgeting and procurement

A project budget is the estimated monetary resources needed to achieve the

project's goals and objectives.
You break the budget down by milestones, which are important points within the
project schedule that indicate progress and usually signifies the completion of a
deliverable or phase of the project, and list activities and tasks alongside their
associated costs.
Budget creation takes place in the initiation phase of your project. Keep in mind
that the budget will be adjusted as needed throughout the lifecycle of the project.
 
It's important not to go over budget and cost the company extra money, 
and it's equally important not to be under budget either 
since that might affect the company's budget for the next year.
Let's dig a little deeper into the effects on a company when a project goes under
budget. Even though it seems like going under budget would be a project
manager's dream, it actually isn't. If you go under budget, it's an indicator of less
than satisfactory project management. Going under budget indicates that you may
not have done a good job at initially estimating. Going under budget could also
indicate that you could have spent more money on the project, meaning that you
could have possibly had extra resources or better quality output, and it may mean
that the budget for future projects will be slashed. The company may figure that
since you did this project under budget, you'll be able to do future projects under
budget too, so that's not a totally desirable situation to be in either. The best option
is to adequately account for, adapt, and manage your budget with that risk in mind.

 There are several factors to consider when creating a budget, including resource

cost rates, reserve analysis, contingency budget, and cost of quality. You'll need to
determine resource cost rates. 
Resource cost rates are exactly what they sound like, the cost of a resource. Some
examples of resources are labor, tools, equipment, materials, and software. You'll
want to ask yourself, how much will each of these resources cost the
company? Sometimes a project can be derailed because the project manager didn't
adequately include funds for reserves or buffers. 
Performing a reserve analysis will help you account for any buffer funds you
may need. A reserve analysis is a method to check for remaining project
resources. In performing a reserve analysis, you'll review all potential risks to your
 project and determine if you need to add buffer funds. These funds are necessary
because new costs that you didn't originally foresee will arise. 
This is also known as contingency budget. Contingency budget in the context of
project management, is money that is included to cover potentially unforeseen
events that aren't accounted for in a cost estimate. The purpose is to compensate
for the uncertainty that occurs in cost and time estimates, as well as unpredictable
risk exposure.
 The cost of quality refers to all of the costs that are incurred to prevent issues
with products, processes, or tasks. The cost of quality includes prevention
costs, appraisal costs, internal failure costs, and external failure costs. 
Once you've applied these factors, resource cost rates, reserve
analysis, contingency budget, and the cost of quality into your budget, you can
estimate what your project might cost. 

Project budgeting best practices

Here are a few tips to consider when creating your project budget:

 Reference historical data: Your project may be similar to a previous project your
organization has worked on. It is important to review how that project’s budget was
handled, find out what went well, and learn from any previous mistakes.
 Utilize your team, mentors, or manager: Get into the habit of asking for your team to
double check your work to give you additional sets of eyes on your documents.
 Time-phase your budget: Time-phased budgeting allows you to allocate costs for project
tasks over the projected timeline in which those expenses are planned to take place. By
looking at your tasks against a timeline, you can track and compare planned versus
actual costs over time and manage changes to your budget as necessary.
 Check, check, and double check: Make sure that your budget is accurate and error-free.
Your budget will likely require approval from another department, such as finance or
senior management, so do your best to ensure that it is as straightforward to
understand as possible and that all of your calculations are correct.

Direct costs
These are costs for items that are necessary in order to complete your project. These
costs can include:

 Wages and salaries of employees and contractors 

 Materials costs
 Equipment rental costs
 Software licenses 
 Project-related travel and transportation costs
 Staff training

Indirect costs
These are costs for items which do not directly lead to the completion of your project but
are still essential for the project team to do their work. They are also referred to as
overhead costs. These costs can include:

 Administrative costs
 Utilities
 Insurance 
 General office equipment 
 Security

A baseline budget is an estimate of project costs that you start with at the beginning of your
project. Once you have created a budget for your project and gotten it approved, you should
publish this baseline and use it to compare against actual performance progress. This will give
you insight into how your project budget is doing and allow you to make informed adjustments.

 
What's the best way to start making a project budget?

You'll find that as you get further along in the process, there are various resources
and tactics that you can use to make sure you aren't overestimating or
underestimating. You'll use techniques like researching historical data, leveraging
experts, the bottom-up approach, confirming accuracy, and setting your
baseline.
For starters, you can always review past projects that are similar to yours to get an
idea of what your project could entail. We refer to that as referring to historical
data. This way, you can find out what past project managers did right and wrong.
To leverage something means to use it to its maximum advantage. Leveraging
experts means gathering their insights to do something more effectively. Reaching
out to colleagues who worked on a similar project in the past will be a great
resource for you as an entry-level project manager. If you're asking someone
outside of your company for advice, be sure to avoid sharing any confidential
company information with them.
Another approach to take is the bottom-up approach. This means thinking about 
all the parts of a project from the beginning to the end, including making a list of
every material, resource, contract worker, or anything that comes with an
associated cost, and adding all of that together. You should also ask the vendors
you are thinking of working with for quotes, so you can get a rough estimate of
how much their work will cost. 
After you've created your budget with these resources, you'll want to double-check 
everything to confirm accuracy. Of course, the work doesn't stop once you've
created the budget.
Next, you'll have to set the baseline. Your baseline is the dollar amount that you'll
use to measure against, to find out if you're on track or not, and to measure the
success of your project. Once you've set your baseline, you'll have to revisit that
number and adjust it to match where the project is currently. Making adjustments
in real-time is something 
you have to do a lot as a project manager.
______________________________________________________________
You'll need to factor in unexpected costs that may come up later on. Be
sure to leave yourself with some buffer room. We've chosen to account
for 5% of the overall project budget as our buffer. This is a standard
practice and depending upon how much detail you know about the project
already, you can raise or lower your percentage for reserves.
_____________________________________________________________

How can you tell if you're staying within your budget or not?c

Monitoring the budget is crucial for a project manager to enforce accountability in

terms of spending.

Milestones are a metric for tracking progress in the project. 

Milestones are a great opportunity to re-review the budget 
 to identify if anything needs to be reset or revisited throughout the project. 
That said, milestones can act as a checkpoint for budget management and 
payment. 

Fixed contracts are usually paid for when certain milestones are reached, 
whereas time and materials' contracts are usually paid for monthly based on 
the hours worked and other fees associated with the work, like travel and meals. 
As you monitor your budget, you'll want to be on top of cost control. 

Cost control is a practice where a project manager identifies factors that might 
impact their budget and then creates effective actions to minimize variances.

Invoice - a list of things provided or work done together with their cost,

for payment at a later time:

If you are given a pre-allocated budget, it is important to work with your customer to
set expectations on scope and deliverables within the allocated budget. To deliver a
great product within your allocated budget will require detailed planning.

A pre-allocated budget should also be routinely monitored to ensure the amounts you
have budgeted are sufficient to meet your costs. Be sure to carefully track all expenses
in your budget. Regularly match these expenses against your pre-allocated budget to
ensure you have sufficient funds for the remainder of your project.

Another budgeting pitfall you should try to avoid is underestimating the total cost of ownership
(TCO) for project resources. TCO takes into account multiple elements that contribute to the
cost of an item. It factors in the expenses associated with a product or service over its lifetime,
rather than just upfront costs. 
Scope creep is when changes, growth, and other factors affect the project’s scope at any
point after the project begins. Scope creep causes additional work that wasn’t planned
for, so scope creep can also impact your budget. 

There are several factors that can lead to scope creep, such as: 

 A vague Statement of Work (SoW)

 Conversations and agreements about the project that aren’t officially documented
 Unattainable timeframes and deadlines
 Last-minute asks from priority stakeholders
 CAPEX (capital expenses) are an organization's major, long-term, upfront expenses,
such as buildings, equipment, and vehicles. They are generally for assets that the
company will own and keep. The company incurs these expenses because they believe
they will create a benefit for the company in the future. 
 OPEX (operating expenses) are the short-term expenses that are required for the day-
to-day tasks involved in running the company, such as wages, rent, and utilities. They
are often recurring.  

**********
Sometimes, a project hits a snag and incurs additional expenses. One way to prepare for
unplanned costs is by using contingency reserves. Contingency reserves are funds added to
the estimated project cost to cover identified risks. These are also referred to as buffers.
While contingency reserves are used to cover the costs of identified risks, management
reserves are used to cover the costs of unidentified risks. For example, if you were
managing a construction project and a meteor hit your machinery, you could use
management reserves to cover the costs of the damage. 

Contingency reserves are an estimated amount, whereas management reserves are

generally a percentage of the total cost of the project. To determine a project’s
management reserves, you can estimate a percentage of the budget to set aside. This
estimate is typically between 5–10%, but the amount is based on the complexity of the
project. A project with a more complex scope may require higher management
reserves. Note that the project manager will generally need approval from the project
sponsor in order to use management reserves.

EVM (Earned Value Management)

https://uk.myservername.com/what-is-scalability-testing

Tips for the procurement process

Procurement means obtaining all of the materials, services, and supplies required to
complete the project. You have just learned about the procurement process in project
management. To recap, there are five steps in the typical procurement process:

1. Initiating: planning what you need to meet your project goals

2. Selecting: deciding which supplies and vendors to use
3. Contract writing: developing, reviewing, and signing contracts
4. Controlling: making payments and maintaining and ensuring quality
5. Completing: measuring your success
Tips for initiating 
While planning your project, figure out which materials, resources, and supplies you will
need to get the job done. During this step, you will decide which items will be internally
procured and which items will be externally outsourced. Once you’ve decided which
items you need to outsource, compare each of those items specifications, components,
quality measurements, standards, and characteristics with your project’s requirements.
You may find that some of the items have features you don’t need. If you can identify
those unnecessary features, you will know exactly what you want and don’t want in an
item, possibly reducing your total cost. 

Tips for selecting 

Now that you have outlined what you need for your project, you need to determine
vendors to source these items. Research and assess various vendors and suppliers,
and try to find out if your preferred vendors have a reputation for delivering quality work
on time. After you’ve identified your preferred vendors and suppliers, interview them to
learn more about their products and services. If possible, make site visits to see exactly
how each vendor runs their business in person. 

Tips for contract writing

Contract writing requires excellent attention to detail, so pay close attention to the
inclusions and exclusions in the vendor’s offer. There may be some items included in
the vendor’s price that you can provide in-house at low or no additional cost. For
example, the vendor’s offer may include charges for storing materials, using certain
equipment, or labor. These are all things that you may be able to provide from your
organization’s resources, so you can opt to save costs with the vendor on those items
by using in-house materials and resources. 

Sometimes, the vendor may write the contract. In this case, checking carefully for clarity
and accuracy ensures that you know exactly what you are getting from the vendor.
Whether the contract is written by you or by the vendor, you will almost always want to
consult with a legal and compliance team to ensure that everything in the contract is
ethical and legal.

Tips for controlling

The procurement process isn’t over when the contracts are signed. The next step is to
ensure that the work is being done according to the terms of the contract. You will need
to periodically review the performance and quality of each vendor. When
communicating with vendors, remain professional but firm to ensure that all project
requirements are being fulfilled and that all major milestones are being met on time and
at cost. 

Building and maintaining a good relationship with your vendors benefits the team and
the overall project. This relationship will make it easier to make adjustments and
contract revisions if the need arises. Taking certain measures, like conducting regular
check-in meetings, will ensure that the work is being completed according to plan. 
 Tips for completing
In the completing step of the procurement process, you will measure the success of
your procurements. Ask yourself:

 Were the materials created good quality? 

 Were there any issues with labor contracts? 
 How were your relationships with vendors? 
During this step, it is also important to document any lessons learned. It is likely that you
will be involved in another project similar to this one in the future. Take notes about how
the procurement process went so you can use this information on a future project. 

There are differences in procurement in the context of Agile versus traditional. 

Agile procurement management is often more collaborative, with both the project team
and the end supplier than traditional approaches. There is a heavy emphasis on the
relationship between these parties. The whole project team plays a larger role in
identifying what needs to be procured. Rather than featuring contracts that are based
on fixed deliverables, Agile procurement management tends to have a living contract
that can be adapted based on the evaluation of the project.

Common procurement documentation

In the initiating phase, a project manager will create a nondisclosure agreement,
otherwise known as an NDA. 
In the selecting phase, a project manager creates a request for proposal, or an RFP. 
In the contracting phase, a statement of work or an SOW is created. 

NDA
The first important document is a nondisclosure agreement, also known as an NDA. 
NDA is a standard within a lot of companies, and it's best practice to ask external contract
workers to sign an NDA. The purpose of an NDA is to keep confidential information within 
the organization. 
RFP
Then we have a request for proposal or an RFP, a document that outlines the details 
and requirements of an organization's project to be passed on to vendors. RFPs are used to solicit
bids from vendors so that you can then select which vendor might be the best for your
project. An RFP is widely used within different departments in a company and across various
industries. An RFP typically includes an overview of the project, the desired outcomes,
and goals, budget, deadlines, milestones, and contact information so each vendor can get back to
you with a detailed proposal of how they plan to tackle the job. When creating an RFP, make
sure to add the following headers to your document. The overview. Treat this section like a
general summary. What is thepurpose of this project? What problems will it solve? What new
doors will it open for the company? Your goals. What are some measurable results you can aim
to achieve throughout the process? Next is the scope of work. What are the specifics of the
project? How are you going to achieve those goals and make sure the project launches
successfully? Then include milestones. Make sure to highlight the key milestones your project
will include. Lastly, include submission requirements, like, "Please submit the RFP as a
presentation and include three prototypes," as well as the questions you'd like the vendor to
answer as part of the process. This helps you properly assess potential vendors.

SOW
Lastly, there's a third important document called a Statement of Work, or an SOW. 
An SOW is sent after the vendor is selected and evolves as the project goes on.

A statement of work is a document that clearly lays out the products and 
services a vendor or contractor will provide for the organization. 
An SoW also provides a description of the contractor's needs and requirements 
to properly perform the agreed-upon services. 

The project manager is tasked with developing the SoW but often asks for input from
subject matter experts ( SMEs) for technical expertise that the project manager may not
have. 

Navigating procurement challenges

1. As a project manager, you are about to hire a new vendor; however, there are terms in the
contract you are unfamiliar with. Who should you contact to better understand the contract?

A member of the legal team

2. Which of the following should a project manager do to ensure an ethical procurement?

Make sure that various stakeholders adhere to governmental policies and adequate corporate social
responsibility.
You’ll want to involve the appropriate stakeholders if you need their decision on a tricky ethical
decision. You should also know your company’s business requirements, seek out the code of ethics
for your profession, and if necessary, consult with an SME.
3. What are some potential ethical risks project managers need to be aware of?

Bribery or corruption

One form of corruption is when a vendor seeks to reduce the competition for a contract during the
bid through bribery or other means.

Interaction with state owned entities

Any relationship with a government that is based upon inappropriate relationships that limit
competition is unethical.
 Sole-supplier sourcing
Sole-sourcing keeps outside vendors from bidding on a project.

RISK MANAGEMENT
Risk management is the process of identifying and evaluating potential
risks and issues that could impact a project. It's not a one-time exercise; it's
something that you'll need to do regularly to address potential risks. Risk
management is a crucial part of the planning process by giving you an
understanding of what could go wrong with your project. 

Risk management life cycle

1. Identify the risk. The first phase of the risk management process is to identify and
define potential project risks with your team. After all, you can only manage risks if you
know what they are. 
2. Analyze the risk. After identifying the risks, determine their likelihood and potential
impact to your project. Serious risks with a high probability of occurring pose the
greatest threat.

3. Evaluate the risk. Next, use the results of your risk analysis to determine which risks
to prioritize.

4. Treat the risk. During this phase, make a plan for how to treat and manage each risk.
You might choose to ignore minor risks, but serious risks need detailed mitigation plans.

5. Monitor and control the risk. Finally, assign team members to monitor, track, and
mitigate risks if the need arises.

An opportunity is a potential positive outcome that may bring additional value to a

project. You can use the same tools and techniques that you use in risk management—
identify, analyze, evaluate, treat, and control—to add potential opportunities to your risk
management plan. You need to know what to do if things go wrong, but you should also
make plans to seize opportunities.

/////////////////////////////////
https://www.pmi.org/learning/library/effective-strategies-exploiting-opportunities-7947
////////////////////////////

Inherent risk is the measure of a risk calculated by its probability and

impact. Measuring the inherent risk gives us a method for understanding a
risk. Inherent risk is also determined on a high, medium, and low scale.

Fishbone diagrams—also known as Ishikawa diagrams or cause-and-effect diagrams

—were developed by Japanese organizational theorist Kaoru Ishikawa in the 1960s to measure
 quality control processes in the shipbuilding industry. Fishbone diagrams are a visual way to
look at cause and effect. They are called fishbone diagrams because they have a similar shape
to a fish skeleton. 

Identifying risks and measuring their potential impact on a project can be a complex
task. You can help visualize these issues by creating fishbone diagrams. To recap, the
steps to create a fishbone diagram are:

 Define the problem

 Identify the categories
 Brainstorm the causes
 Analyze the causes
Once you’ve developed a fishbone diagram to help find a problem’s root cause and
measure its potential impact on the project, you can then move on to determining how
to mitigate the risk. 

RISK ASSESSMENT
 Types of risk

time risks,
budget risks, 
scope risks

Another source of risk to be aware of are dependencies. A dependency is a

relationship between two project tasks, where the start or completion of one depends on
the start or completion of the other. In other words, dependencies are like links that
connect one project task to another.

There are two types of dependencies: internal and external. Internal dependencies

refer to dependencies within the project that you and your team have control over. For
example, you'll need to secure approval on a website design before development can
begin. On the other hand, external dependencies are dependencies that you have no
control over.
Types of dependencies  
Finish to Start (FS)

In this type of relationship between two tasks, Task A must be completed before Task B
can start. This is the most common dependency in project management. It follows the
natural progression from one task to another.

Example: Imagine you are getting ready to have some friends over for dinner. You can’t
start putting on your shoes (Task B) until you’ve finished putting on your socks (Task
A). 

Task A: Finish putting on your socks. →Task B: Start putting on your shoes.

Finish to Finish (FF)

In this model, Task A must finish before Task B can finish. (This type of dependency is
not common.)

Example: Earlier in the day, you baked a cake. You can’t finish decorating the cake
(Task B) until you finish making the icing (Task A).

Task A: Finish making the icing. →Task B: Finish decorating the cake.

Start to Start (SS)

In this model, Task A can’t begin until Task B begins. This means Tasks A and B start
at the same time and run in parallel.

Example:  For dinner, you are making pasta. You can’t start cooking the pasta (Task B)
until the water starts boiling (Task A).  

Task A: Start boiling the water. →Task B: Start cooking the pasta.

Start to Finish (SF)

In this model, Task A must begin before Task B can be completed.

Example:   One of your friends calls to tell you he’ll be late. He can’t finish his shift (Task
B) and leave work until his coworker arrives to start her shift (Task A). 

Task A: Your friend’s coworker starts her shift. →Task B: Your friend finishes his shift.

Dependency graphs
 Managing single point of failure risks

A single point of failure is a risk that, if it were to materialize, could cause a significant amount
of disruption to your project and could even shut it down. You should plan for these risks early
on in the project. 

Case study: Using mitigation strategies to manage single

point of failure risks
Avoid  

This strategy seeks to sidestep—or avoid—the situation as a whole. In the Office Green
example, the team could avoid this risk entirely by considering using another seed that
is widely available in several locations.

Minimize  

Mitigating a risk involves trying to minimize the catastrophic effects that it could have on
the project. The key to minimizing risk starts with realizing that the risk exists. That is
why you will usually hear mitigation strategies referred to as workarounds. What if the
Office Green team decided to use both the original South American supplier and
another supplier from a neighboring country? More than likely, the change in taxation
and regulation wouldn’t affect both companies, and this would provide Office Green
some flexibility without having to completely eliminate their preferred supplier.

Transfer 

The strategy of transferring shifts the responsibility of handling the risk to someone else.
The Office Green team could find a supplier in North America that uses the seeds from
several other South American countries and purchase the seeds from them instead.
This transfers the ownership of South American regulatory risks and costs to that
supplier.

Accept 

Lastly, you can accept the risk as the normal cost of doing business. Active acceptance
of risk usually means setting aside extra funds to pay your way out of trouble. Passive
acceptance of risk is the “do nothing” approach. While passive acceptance may be
reasonable for smaller risks, it is not recommended for most single point of failure risks.
It is also important to be proactive and mitigate risks ahead of time whenever possible,
as this may save you from having to accept risks.

 
A risk management plan is a living document that contains information
regarding high-level risks and the mitigation plan for each of those
risks. This plan helps ensure that teammates and stakeholders have a
clear understanding of potential problems and a plan to address them
should they occur. Risk management is an ongoing practice that
you'll take part in throughout the planning and execution of a project.
 COMUNICATION
Good effective communication is always clear, honest, relevant, and
frequent, but not too frequent. 

Best practices for building a communication plan

In the previous video, you learned how to develop a basic communication plan. You
also learned how to document who needs to be involved in project communication, how
to communicate with them, why you are communicating, and how often that
communication should occur. 

In this reading, we will reinforce the top tips to keep in mind when creating a
communication plan to ensure that it is an effective tool for you and your project team.

Tips for creating your communication plan 

Identify, identify, identify
Before you begin creating the plan, answer these questions to ensure that you have all
of the relevant information:

 Project stakeholders: Have you created a RACI chart or stakeholder map of all your
stakeholders? Who is your audience? Who will need to be informed at different points
during the project life cycle? 
 Communication frequency and method: When and how often should you check in with
your stakeholders? What methods of communication do they prefer? How much detail
does each stakeholder need? 
 Goals: What is the goal of your communication? Do you need a response? Are you
trying to encourage engagement or simply providing an update? 
 Barriers: Are there any time zone limitations? Language barriers? Do some
stakeholders require time to reply or respond (e.g., an executive)? Are there any privacy
or internet access issues? 

Document and develop

Choose a tool or template to document all of your communication needs, and begin
developing your plan. Once you understand the basic elements (stakeholders,
communication methods, goals, and barriers), it’s time to work out the details! Here are
some tips:

 Add a column for notes. Project management is not one-size-fits-all, and there are a lot
of pieces that need to be tracked. For instance, if you are reaching out to a senior
leader or executive, do you need to copy anyone else on the email? If a stakeholder is
out of office or unavailable on certain dates, do you have a backup plan? Add notes to
set reminders and any additional relevant details.
 Use formatting to highlight any key details in the plan. Is there a launch announcement or
an urgent decision needed for the project to move forward? Highlight these pivotal
elements in a different font color or size to stress their importance.
 Ensure that the team can access your document. Share the plan with your team. Allowing
your team to review the document ensures that they are aware of the plan and gives
them a chance to offer feedback. Sharing the document also serves as an extra check
to make sure you aren’t missing any crucial pieces.
 Test your plan. If you are sending a team-wide email or link, send a test email to
yourself or a colleague. If you are planning a virtual presentation, be sure to test the
visual, audio, and other technical aspects in advance. That way, you can minimize any
technical problems.  
………………………………………………………………
Tip
Tell to interview about your desire to study . і проекти
дають цю можливість
 COURSE 4
Choose the right tracking method for your project
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 charter 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
 New to Gantt charts? Start here.

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
 Everything you need to know about Project Roadmaps

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
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 help article: Learn how to use burndown charts in Jira software
ProjectManager.com article: Burndown Chart: What Is It & How Do I Use It?

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.
Dependencies

Dependencies are the links that connect one project task to another, 
and as we mentioned, they're often the greatest source of risk to a project. 
Two or more project tasks may have a relationship with one another in which 
the completion of one task is reliant on the initiation of another task, and 
vice versa. 

 
Mandatory dependencies are tasks that are legally or contractually required. 
For instance, when that construction company finishes the demolition and 
starts the rebuild, they'll first have to pour a concrete foundation and 
then have it inspected by the city to ensure it meets 
their standards before the construction company can continue to build. 

Lastly, discretionary dependencies are defined by the project team. These are

dependencies that could occur on their own, but the team saw a need to make those
dependencies reliant on one another. 
For instance, the construction company may be using concrete from a new supplier
and want to run a test, pouring a portion of the foundation to get a better estimate of the
total amount of product they'll need to complete the foundation, rather than buying too
much or too little product up front. The task of pouring a portion of the foundation comes
first, because the team needed more information before making a decision. 
 ROAM

Escalation
 
On top of several other tasks, it's a project manager's responsibility to resolve problems 
and remove constraints that are a detriment to the project's success.
 One way to do this is to escalate. 
Escalation is 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. Escalation may seem to have a negative connotation, but that's not the
case in project management. In project management, escalation should be
encouraged, used often, and even celebrated.

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.
 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 the 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 considering the project as done.
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. 
Common data metrics

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.

Project management metrics are an effective way to evaluate the progress of a

project. Measuring your project progress against specific factors helps clarify the
management process. 

These metrics in project management can also help guide the objectives of a

project, giving teams the ability to track performance and make improvements as
needed. 

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?

Milestone
Description

A milestone is a productivity metric. Milestones are important points

within the project schedule that indicate progress and often signify when a
team completes a deliverable or phase of the project.

Hide example
Example

A project manager might use a tool like Smartsheet to visualize where

milestones fall within a project timeline.

Task
Description

A task is a productivity metric. Project managers assign tasks to project

team members for them to accomplish within a set period of time.

Hide example

Example
Work management software like Asana can help project managers create
and assign tasks. They can also generate reports to track their team’s
productivity over time.

Projection
Description

A projection is a productivity metric. This metric helps you analyze

current information to predict future outcomes.

Hide example

Example

A project manager might use a spreadsheet and its built-in charting tools
to analyze current productivity data and make projections about future
productivity trends.

Duration
Description

Duration is a productivity metric. A project’s duration is the total time it

takes to complete a project from start to finish. Duration can also be used
for tasks.

Hide example
Example

Project management software can help project managers monitor the

duration of a project alongside certain milestones.

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.

Number of changes
Description

Number of changes is a quality metric. Changes show any

inconsistencies from the initial requirements of the project.

Hide example
Example

A project manager might use a tool like a change log or a spreadsheet to

measure the number of changes from stakeholders and look for areas to
improve communication.

Issue
Description

An issue is a quality metric and is known as a real problem that may

affect the ability to complete a task.

Hide example
Example

Project management software like Jira and Workfront can generate reports
that help project managers track both the number of issues and the team’s
ability to resolve them quickly.

Cost variance
Description

Cost variance is a quality metric and illustrates the difference between

the actual cost and the budgeted cost.

Hide example
Example

A budgeting spreadsheet can help a project manager log costs over time
and compare them against the actual budget.

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.
 /////////////////////////////////////////

A Comprehensive Guide To Project Management Metrics

Data-Driven Project Management: The 4 Most Important Data Points to Look At
Project Analytics: Benefits, Challenges and First Steps
Project Analytics to Improve Project and Portfolio Decision Making
Project Management Metrics
Productivity Metrics: Why They’re Important & 4 Examples

////////////////////////////////////////////////

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!

////////////////////tip

Even if a stakeholder has to leave early, give your presentation exactly as you
rehearsed it.

------ If a stakeholder has to leave early, you may have to shorten the presentation or
rearrange your main points. Prepare and practice before presenting so you can be
flexible if an unexpected event requires you to alter it.

///////////////////

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.
Five factors that have an impact on team effectiveness by
google

Psychological safety refers to an individual's perception, of the consequences of

taking an Interpersonal risks. In other words, they believe it's safe to take risks
within their team and they don't risk being labeled as ignorant, incompetent,
negative or disruptive. On teams with high psychological safety, teammates feel
comfortable taking risks around fellow team members, seeking differing opinions
and resolving interpersonal conflict when it comes up.
For example, on my team at Google, we like to say be direct and kind. We've
worked really hard to build a team culture, in which we can hold one another
accountable while maintaining a shared space that is safe, secure, and peaceful.
What I found is that, when opportunities to take risks do arise, like pitching an out-
of-the-box idea to my directors, for example, this culture of mutual respect, has
already laid the groundwork to get direct feedback without frustration or worrying
that I might embarrass myself. And that's been invaluable in maintaining a high
level of psychological safety for the team.
Next, we have dependability. Google's researchers explain it this way.
On dependable teams, members are reliable and complete their work on time.
Creating a dependable team requires the combination of setting, negotiating and
meeting expectations. Yes, your team needs to meet the expectations set for them.
You have to be able to clearly communicate expectations and ensure that the team
feels comfortable negotiating with you when needed.
For example, it's likely that a person on your team works on two or more projects
with competing deadline.
If they're afraid to share their own constraints with you, then their work on both
projects might suffer. Alternatively, if they come to you with their concerns and
open understanding and negotiation around priorities could help ease their burden.
Next, we have a structure and clarity.
Structure and clarity refers to an individual's understanding of job expectations,
knowledge of how to meet those expectations and the consequences of their
performance.
Each team member has a clear sense of their individual role, plans and goals. And
they have a sense of how their work affects the group.
You as the project manager, can help foster a sense of structure and clarity on the
team. For example, if a project structure in tracking are sloppy, unorganized and
incohesive, then the team's output is likely to be sloppy, unorganized and
incohesive. This can cause tension within the team.
Alternatively, if you diligently engage in project tracking, your team will have
clarity, feel more united and will be able to effectively collaborate.
Meaning also impacts team effectiveness. Google's researchers defined meaning in
this context, as finding a sense of purpose either in the work itself or in the results
of that work. For example, your teammates might find meaning in supporting
themselves financially, helping the team reach its goals or wanting their products
to reach a new community of users.
And finally, we have impact. Our researchers define impact as the belief that the
results of one's work matters and creates change. It can be challenging for people
to notice how their work can shift an entire ecosystem forward. Part of your role as
the project manager, is to help individual teammates identify how they drive
impact both within the team and beyond it. Project tracking can be a helpful tool
for visualizing progress and impact.
Leading high-functioning teams

In addition to communicating and listening to the wider team, it's also your
responsibility to regularly connect with individual teammates. You do this by
gaining an understanding of communication styles and by asking people on your
team how they prefer to communicate. What's important to know is that everyone
communicates differently. For example, I might make small talk with colleagues
who I know enjoy it. Or I might get straight to the point with colleagues who
prefer not to chat.

In addition to showing empathy for my team, I also like to create motivation by

recognizing a job well done through public forums. Like in a meeting or a group
email.
Recognition tells people that they're doing the right things, and motivates them to
keep up the good work. Be sure to recognize good work, and not just heroic
efforts.
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.
Team development and managing team dynamics

Tuchman's first stage of team development is the forming stage. At this point
everything feels shiny and new. Individuals on the team are just getting to know on
another, and they're eager to make a good impression. And typically they're excited
for the work to begin. During this stage, you as a project manager should clarify
project goals, roles, and context about the project. People are seeking guidance and
it's your job to provide that guidance.
The second stage of team development is the storming stage, this is where things
get a bit trickier. As people settle into their roles and the work on their project
begins, the people on your team are interacting more and maybe disagreeing a bit.
This is where feelings of frustration might emerge. Individuals might take issues
with certain processes they feel are inefficient, or other teammates they disagree
with, especially when the team is navigating tasks that are much more complex
than they first appeared. It makes sense, right? If you're working closely with a
new group of people for the first time, there's bound to be some interpersonal
conflict. Teammates might disagree on time, and effort estimations, vary in their
levels of independence, or prefer to prioritize certain tasks over other equally
important tasks. As the project manager, it's your job to focus on conflict
resolution. Listen as the team addresses problems to solve and share insights on
how the team might better function as a unit.
After storming comes Tuchman's third stage, the norming stage. At this point, the
team has resolved some of its internal conflict by establishing new norms. Like
processes and workflows that make it easier for everyone to get things done. The
team feels better equipped to work together efficiently and effectively. You, as the
project manager should codify the team norms, ensuring that the team is aware of
those norms and reinforce them when needed. For example, if you've agreed to
discuss solutions to issues during weekly team meetings, ensure that your weekly
agenda budgets time for this topic each week.
Tuchman's fourth stage is the performing stage. During this time, the team
works together relatively seamlessly to complete tasks, reach milestones and make
progress toward the project goal. In the performing stage, you as the project
manager should focus on delegating, motivating and providing feedback to keep up
the team's momentum.
The fifth and final stage of team development is the adjourning stage. In this
stage the project is wrapping up and it's time for the team to disband. It can be a
bittersweet time for the team and you might want to mark the end of the project
with a celebration.
You as the project manager should set up time to celebrate the final milestones and
success of the project as a group. And be sure each member of your team knows
what's next for them.
Ethical and inclusive leadership
A common framework 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).

Steps to effective influencing

Leadership expert, Dr. Jay A Conger identifies the steps to effective influencing as:
1. Establish credibility
2. Frame for common ground
3. Provide evidence
4. Connect emotionally 

The first step to effective influencing is to establish credibility. During this step, you make the
case for why your audience should listen to you. According to Dr. Conger, credibility comes
from two sources, expertise, and relationships. You need to demonstrate to your audience that
you're an expert on a given topic, whether that's through professional experience, extensive
research, or something else, and you need to demonstrate relationship credibility by establishing
that you're honest, trustworthy, and someone who they want to work with. To establish
credibility, you might kick off your Office Green email by greeting the recipient by name, then
writing something like,
"I'm Elita, a lead project manager at Office Green. Your colleague, Alex, passed on your contact
information. Alex and I worked together to launch new services at Office Green before she
joined your organization."
In these opening lines, you've established expertise, credibility by introducing your role at office
green and by suddenly highlighting that you've launched new services in the past. To
 demonstrate relationship credibility, you've established that you and the recipient have a shared
contact who has worked closely with you in the past and can vouch for your trustworthiness and
emotional intelligence.
The second step is to frame for common ground. In this step, you'll make the case for how
your idea can benefit your audience. To determine this, you'll need a strong understanding of
your audience and their values. In essence, what about your idea will appeal to them, and how
will they stand to benefit from agreeing to your idea? In our Office Green email, you might
establish that you've researched their organization extensively and believe that this new service
might align with their current offerings. For example, you might write something like this,
"We're launching a service to provide top clients with desk plants and we'd like to explore a
bundle offering to pair high-quality chocolate with each plant order. I've admired your
organizations push in recent years to work with other lifestyle and wellness brands and I think
there may be a great opportunity for us to collaborate." In this portion of the email, you've
established that you've done your research on the organization and that their previous
partnerships indicate that working together might be a great fit.
The next step is to provide evidence. In this step, you'll make your case through hard data and
persuasive storytelling. Numbers aren't strong enough on their own. They need stories to live in
them up. In our Office Green email, you might appeal to your recipient with a line like,
"We recently surveyed clients to gauge interest in this kind of offering, and your brand came up
again and again." In this example, you provided evidence through the results of client surveys
which showed overwhelmingly positive brand recognition for our shared audience.
The last step is to connect emotionally. In this step, you'll demonstrate to your audience that
you're emotionally committed to your idea and you'll do your best to match their emotional state.
In our Office Green email, you might demonstrate an emotional connection by tapping into their
brand ethos. For example, you might write something like, "We've been following your profile
on Instagram and love your posts on chocolate's connection to living a well and balanced
lifestyle. Perhaps we can discuss combining forces to bring this message to an even wider
audience," and then you end your note with a friendly closer, something like, "If you're
interested, I'd love to connect and share what our partner program is all about."
………………………………………………………………………………………………………..
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
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 with hearing impairments 
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. 

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.

Common types of project meetings

 CLOSING THE PROJECT
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.
COURSE 5

AGILE

Agile-маніфест розробки програмного забезпечення

Люди та співпраця важливіші за процеси та інструменти
Працюючий продукт важливіший за вичерпну документацію
Співпраця із замовником важливіша за обговорення умов контракту
Готовність до змін важливіша за дотримання плану
The 12 principles of the Agile Manifesto

\
VUCA

Volatility refers to the rate of change and churn in a business or situation. In a volatile project,
you would discuss how the next disruption to your operations is always right around the corner.
Or it feels like things never have time to settle into a normal rhythm.
Uncertainty refers to the lack of predictability or high potential for surprise. In an uncertain
environment, it would be difficult to create plans for the future that we're not based on a large
number of assumptions that could turn out to be incorrect.
Complexity refers to the high number of interrelated forces, issues, organizations, and factors
that would influence the project. For example, if one product being worked on relied on diverse
and global suppliers, that would add to the complexity of the project.
Ambiguity refers to the possibility of misunderstanding the conditions and root causes of events
or circumstances. A project that suffered from ambiguity would have difficulty pinpointing the
causes of project delays, making it difficult to design mitigation plans to reduce the risks.
SCRUM
https://scrumguides.org/scrum-guide.html
Understanding Scrum Team roles
Each Scrum Team member plays a vital role in the project’s success. In order to help a
project get to the finish line, you will need to understand what each of these roles entail.
In this reading, you will learn how the responsibilities of the Scrum Master, Product
Owner, and Development Team differ from one another.

The Scrum Master

 One key responsibility of the Scrum Master is to help the team understand and follow
Scrum theory. More specifically, according to the Scrum Guide, “The Scrum Master is
accountable for establishing Scrum as defined in the Scrum Guide. They do this by
helping everyone understand Scrum theory and practice, both within the Scrum Team
and the Organization. The Scrum Master is accountable for the Scrum Team’s
effectiveness. They do this by enabling the Scrum Team to improve its practices, within
the Scrum framework.” The Scrum Master makes sure that important meetings occur,
like the Daily Scrum. In the same way that a coach would be aware of the game clock,
the Scrum Master is tasked with making sure that the meeting is kept within the
appropriate timebox. A timebox is a Scrum concept that refers to the estimated duration
for an event.

The Scrum Master acts as a coach to the Scrum Team—they encourage the team to
build the product in the time frame. They also support the team by creating a
collaborative environment so the project’s goals are achieved. The Scrum Master’s
duties include: 

 Coaching the team members in self-management and cross-functionality

 Helping the Scrum Team focus on creating high-value Increments that meet the
Definition of Done (an agreed upon set of items that must be completed before a project
or user story can be considered complete)
 Causing the removal of impediments to the Scrum Team’s progress
 Ensuring that all Scrum events take place and are positive, productive, and kept within
the timebox (a Scrum concept that refers to the estimated duration for an event)

Scrum Master vs. project manager 

The role of the Scrum Master is sometimes confused with the role of the project
manager. While the two roles share related skills and qualities, they are very different
roles.

A Scrum Master is responsible for helping the team understand Scrum theory and
practice. They ensure Scrum events take place and help the team focus on delivering
value by removing impediments. But unlike a traditional project manager, they do not
take on the management of changes in scope or priorities. Additionally, Scrum Masters
do not maintain traditional project artifacts like Gantt charts.  

The Product Owner

According to the Scrum Guide, “The Product Owner is responsible for maximizing the
value of the product resulting from work of the Scrum Team. How this is done may vary
widely across organizations, Scrum Teams, and individuals.” Product Owners maximize
the value of the product by representing and expressing the voice of the customer
throughout the project duration. A product isn’t useful to its customers if that product
doesn’t fulfill their expectations and meet their needs. The Product Owner’s duties
include:

 Developing and explicitly communicating the Product Goal

 Creating and clearly communicating Product Backlog items (The Product Backlog
contains all of the features, requirements, and activities associated with deliverables to
achieve the goal of the project.)
 Ensuring that the Product Backlog is transparent, visible, and understood

Product Owner vs. project manager

In traditional project management, scope management is the primary responsibility of
the project manager. But in Scrum, the definition and management of product scope
falls to the Product Owner. Conversely, the Product Owner isn’t responsible for team
performance—they aren’t considered to be a manager. The project manager leads the
project team to meet the project’s objectives and oversees tasks and progress.

There are also similarities between the Product Owner and project manager roles. For
instance, both roles are tasked with stakeholder management. This means they both
must practice and facilitate effective communication among team members and
stakeholders.

Additionally, in many companies—including Google—the definition of product or

solution scope is the responsibility of a separate role called a product manager. So, it is
important when joining any new company to discover how that company approaches
the area of product definition, requirements development, and user research to
understand what they consider to be the domain of the project manager. 

The Development Team

The Development Team, also referred to as Developers, is made up of the people who do
the work to build the product. According to the Scrum Guide, Developers are “the
people in the Scrum Team that are committed to creating any aspect of a usable
Increment each Sprint.” Their responsibilities include: 

 Creating a plan for the Sprint, the Sprint Backlog (the set of Product Backlog items that
are selected to be completed during the upcoming Sprint)
 Instilling quality by adhering to a Definition of Done
 Adapting their plan each day toward the Sprint Goal
 Holding each other accountable as professionals
 Executing sprints by designing, building, and testing Product Backlog items in
increments
An important aspect of the Development Team that is worth highlighting is that they are
cross-functional, meaning that you will have team members who are specialists in
different disciplines. In a software team, that might mean having a web developer, a
database developer, and a user experience specialist. In a marketing team, that might
mean having writers, editors, search engine optimization specialists, and business
analysts. 

The roles working together

The Scrum roles fit together, and each brings their unique qualities, skills, and
responsibilities jointly to lead to successful Scrum projects. It is crucial for everyone on
the team to understand their role and how they work together to deliver value to their
users and customers. When the team has this shared understanding, they can better
support each other during the practices of Scrum. 

Necessary traits for each role 

Overall, you will want people on your team who are interested in constant collaboration
and improvement. More specifically, it is great to have team members who value
feedback, bring energy and fun to the team, and can admit and learn from their
mistakes. Let’s look at what traits each team member should exhibit:

The Product Owner should be able to confidently provide the team with general
direction, requirements, and objectives for the project but will allow the team to
determine how to accomplish these goals. Your team will want a Product Owner who
promotes the product vision and prioritizes the product backlog to maximize the value
for the customer. In order to deliver on this, the Product Owner should be organized and
have strong communication skills.

The Scrum Master should have strong leadership skills that enable them to be efficient
facilitators and negotiators who know how to resolve conflict. Your team will want a
Scrum Master who aims to effectively coach the Development Team, facilitate events,
and eliminate distractions that may impede the team’s progress. 

When it comes to the Development Team, you will want individuals who remain focused
on completing deliverables and producing a superior final product. Since the team is
self-organizing and cross-functional, you will want people who are eager to work
together and not afraid to compromise for the greater good of the product. 

///////////////////////////////
https://www.infoq.com/articles/great-scrum-team/
/////////////////////////////////////
 The components of user stories and epics
In the previous video, we introduced user stories and epics. User stories are short,
simple descriptions of a deliverable told from the perspective of the user. Creating user
stories helps the team develop a solution that is always centered around the user’s
needs and overall experience. 

You also learned that epics are a collection of user stories. Think of the concept of user
stories in terms of books or films. A story is one single narrative, while an epic is a set of
several related, independent stories. Each story tells a specific chronicle, while an epic
gives a high-level view of the overall arc. 

User stories
The driving factor behind every Scrum project is putting the customer first. User stories
are a key component of ensuring that customers are satisfied with the product. A team
writes a user story from the perspective of the user. Not only do user stories provide
insight into what goals the user wants to achieve, but they enable collaboration, inspire
creative solutions, and create momentum by giving the team a small win when the
stories are developed. 

When writing user stories, you will need to include the following components: 

 User persona. What is your user like? What is their relation to the project? What goals do
they have? 
 Definition of Done. This refers to an agreed upon set of items that must be completed
before a user story can be considered complete. 
 Tasks. What are the key activities needed to complete the user story?
 Any feedback already provided. If you are adding features to an existing product and you
have already received feedback from customers on a past iteration, make sure to
consider this feedback.  

I.N.V.E.S.T. 
Recall from the video that your user stories should meet the I.N.V.E.S.T. criteria: 

 Independent: The story’s completion is not dependent on another story.

 Negotiable: There is room for discussion about this item.
 Valuable: Completing the user story has to deliver value. 
 Estimable: The Definition of Done must be clear so that the team can give each user
story an estimate. 
 Small: Each user story needs to be able to fit within a planned Sprint.
 Testable: A test can be conducted to check that it meets the criteria.

Let’s imagine you are working on a project for a local library. The library hopes to launch
a website so that customers can read reviews before they check out books from the
branch. The typical template for a user story looks like this: As a <user role>, I want this
<action> so that I can get this <value>. Therefore, an example user story for this situation
might read: As an avid reader, I want to be able to read reviews before I check out a book
from my local branch so that I know I am getting a book I am interested in.
 Epics
An epic’s purpose is to help manage related user stories. In this post, Mike Cohn, the
inventor of the term “epic” as it relates to Scrum, describes epic as a “very large user
story”—one that could not be delivered within a single iteration and may need to be split
into smaller stories. The team should discuss together and reach a shared view of how
to write and capture their user stories and epics. Keep in mind, epics are just larger user
stories that are there to help organize the project. 

Let’s imagine you are creating user stories and epics based on the previous example.
User stories may include customers wanting to read reviews of books on the website or
wanting to add books to their cart. These user stories could fall into the “website
creation” epic. 

Another user story could be that customers want to walk into the library and easily find
the non-fiction section. This would fall under the “organization of the physical space”
epic.

So rather than those various user stories appearing in a list together, they are organized
into sections, or epics.

It’s important to note that while the Product Owner can write user stories and epics, a
Developer can also write them as long as the Product Owner remains accountable for
the Product Backlog item.

Agile effort estimation techniques

There are all kinds of techniques to use when estimating effort in an Agile way. Effective
relative effort estimation leads to successful and predictable sprint outcomes, which
leads to a successful project overall. Generally speaking, the main steps to Agile
estimation are the same, even if the specific approach varies. Some examples of Agile
estimation techniques are: 

 Planning Poker™
 Dot Voting
 The Bucket System
 Large/Uncertain/Small
 Ordering Method
 Affinity Mapping

Planning Poker™
This particular method is well-known and commonly used when Scrum teams have to
make effort estimates for a small number of items (under 10). Planning Poker is
consensus-based, meaning that everyone has to agree on the number chosen. In this
technique, each individual has a deck of cards with numbers from the Fibonacci
sequence on them. The Fibonacci sequence is where a number is the sum of the last
two numbers (e.g., 0, 1, 2, 3, 5, 8, 13, and so on). 
Sometimes, Planning Poker decks also include cards with coffee cups and question
marks on them. The question mark card means that the person doesn’t understand
what is being discussed or doesn’t have enough information to draw a conclusion. The
coffee cup card means that the person needs a break.

The Planning Poker strategy is used in Sprint Planning meetings. As each Product
Backlog item/user story is discussed, each team member lays a card face down on the
table. Then, everyone turns their card over at the same time and the team discusses the
estimates, particularly when they are far apart from one another. By first hiding the
estimates, the group avoids any bias that is presented when numbers are said aloud.
Sometimes, when hearing numbers aloud, people react to that estimate or the estimator
themselves, and it changes what their initial thought may have been. In Planning Poker,
teams can easily avoid that bias.

Dot Voting 
Dot Voting, like Planning Poker, is also good for sprints with a low number of Sprint
Backlog items. In Dot Voting, each team member starts with small dot stickers, color-
coded by the estimated effort required (e.g., S=green, M=blue, L=orange, XL=red). The
items or user stories are written out on pieces of paper placed around a table or put up
on the wall. Then, team members walk around the table and add their colored stickers
to the items. 

The Bucket System

The Bucket System is helpful for backlogs with many items since it can be done very
quickly. In fact, a couple hundred items can be estimated in just one hour with the
Bucket System. The Bucket System is an effective strategy for sizing items because it
explores each item in terms of pre-determined "buckets" of complexity. Keep in mind
that these buckets are metaphorical; this strategy doesn't require the use of actual
buckets, and instead uses sticky notes or note cards as buckets.

In this technique, the team starts by setting up a line of note cards down the center of
the table, each marked with a number representing a level of effort. Then, the team
writes each item or user story on a card. Each person draws and reads a random item, 
then places it somewhere along the line of numbered note cards. There is no need to
discuss further with the team. If a person draws an item that they do not understand,
then they can offer it to someone else to place. Additionally, if a person finds an item
that they think does not fit where it was placed, they can discuss it with the team until a
consensus about a more accurate placement is reached. Team members should spend
no more than 120 seconds on each item.  

Large/Uncertain/Small 
Large/Uncertain/Small is another quick method of rough estimation. It is great for
product backlogs that have several similar or comparable items. 

This is the same general idea as the Bucket System, but instead of several buckets, you
only use three categories: large, uncertain, and small. Starting with the simpler, more
 obvious user stories, the team places the items in one of the categories. Then, the team
discusses and places more complex items until each is assigned to a category.

Ordering Method
The Ordering Method is ideal for projects with a smaller team and a large number of
Product Backlog items. First, a scale is prepared and items are randomly placed
ranging from low to high. Then, one at a time, each team member either moves any
item one spot lower or higher on the scale or passes their turn. This continues until
team members no longer want to move any items. 

Affinity Mapping
Affinity Mapping is useful for teams that have more than 20 items in their Product
Backlog. 

A best practice is to conduct this technique using sticky notes placed onto a wall,
whiteboard, or table. Each sticky note features a different user story or item. Using
sticky notes allows the team to move user stories around in order to group them by
similar theme, group, and pattern. The team begins by placing one sticky note on the
board. Then, the team takes the next sticky note and discusses whether it is similar to
the first item. Based on the team’s assessment, the second sticky note is placed in the
first group or into its own group. 

After all of the items are grouped (there should be anywhere from 3–10 groups total),
the team gives a name to each group that represents the general theme of the items.
Then, the groups are prioritized by importance so that the team knows which items to
tackle first. 

Characteristics of effective estimation

Regardless of which technique your team chooses, there are several important
characteristics the techniques share that lead to effective estimation:

 Avoids gathering false precision of estimates. In Scrum, assigning rough estimates results
in more accuracy across the project. Therefore, if the team focuses on identifying
relative estimates—rather than a team having a lengthy debate about whether a task
will take seven or 10 days of work—the team saves time and avoids potentially missing
deadlines.
 Avoids anchoring bias. Many of these techniques (e.g., Planning Poker) keep the initial
estimate private, which allows team members to form an independent opinion on the
estimate before sharing their thoughts with the team. This prevents a known
phenomenon called anchoring bias, where individuals find themselves compelled to put
forth estimates similar to others in the room to avoid embarrassment. 
 Promotes inclusivity. These group estimation techniques not only lead to better
estimates but also help the team develop trust and cohesiveness.
 Leads to effort discovery. Estimating in these dynamic ways can help the team uncover
strategies to get items completed which might otherwise not have been revealed.
 T-shirt sizes and story points
In the previous videos, you learned about T-shirt sizes and story points—the two most
common units used to help teams estimate user stories in Agile projects. In this reading,
we will explore the processes of estimating user stories in these units. 

As a recap, relative estimation means to compare the effort estimated for completing a
backlog item to the effort estimated for another backlog item. Doing this instead of trying
to determine exactly how long a task will take allows your comparisons and estimates to
be more accurate relative to one another.

T-shirt sizes
At first, T-shirt sizes may seem like a somewhat unusual way to measure an item or
user story. But when you think about assigning estimations to items based on sizes
(e.g., XS, S, M, L, XL, XXL), it is actually very helpful and easy. Some of the benefits to
using this technique are that it is quick, well understood by Agile experts, and a good
introduction for teams who are just learning relative estimation.

So what does the process of assigning T-shirt sizes entail? There are several specific
techniques a team can try, but each generally follows these steps. The team: 

 Agrees on the chosen scale and metrics to be used.

 Identifies at least one anchor backlog item. That item will be assigned a T-shirt size.
Some teams will choose two anchor items—one at the top of the range and one at the
bottom of the range.
 Sorts through the remaining backlog items and agrees on T-shirt sizes for each of
them. 

Story points
Using story points as the estimate unit is a little more advanced than T-shirt sizes, but it
is essentially the same concept. This method is good for experienced teams. When
using story points, teams usually use the Fibonacci sequence. As a reminder, this
sequence comes from adding the two previous numbers in the sequence together. For
example, 1 + 2 = 3 and 2 + 3 = 5. The important thing to notice about this sequence is
that, as the list continues on, the numbers spread further apart from each other.
Because of this, story points provide more accuracy and specificity than T-shirt sizes. 

So what does the process of assigning story points entail? There are several specific
techniques a team can try, but the basic steps are the same as with T-shirt sizes. The
team: 

 Agrees on the permitted points values. Some teams cap the size at a certain number,
like 21. Some teams decide to jump from 21 to 100 as the next larger value. This is a
team decision.
 Identifies at least one anchor backlog item and agrees to assign it a points value. Some
teams will choose two anchor items, one at the top of the range and one at the bottom
of the range.
 Sorts through the remaining backlog items as a team, agrees on an estimate for each
item, and captures it in the backlog management system. 

Best practices
Some best practices, regardless of the technique you use, include:

 Asking the Product Owner questions about the user story or item to ensure that there is
enough information to estimate it.
 Discussing divergent estimates from various team members so that everyone has a
chance to understand how to implement the item.
 Agreeing on the final T-shirt sizes or points value and capturing it in the system.
 If certain items fall into the larger T-shirt size or story points value range, discussing
whether it makes sense to break them down into smaller pieces before moving on.

Releasable Increment versus Minimum Viable

Product
You have learned that the Product Increment is what is produced after a given Sprint
and is considered releasable. The Scrum Guide states that “An Increment is a concrete
stepping stone toward the Product Goal. Each Increment is additive to all prior
Increments and thoroughly verified, ensuring that all Increments work together. In order
to provide value, the Increment must be usable.”

Potentially releasable product increment

Potentially releasable (or shippable) Product Increment is a handy way for teams to think
about the desired result of a Sprint. The goal for every Sprint is to result in a completed,
tested, ready-to-ship addition to the product or solution. This doesn’t mean the product
will actually ship to customers—that is why they use the word “potentially.” Consider, for
example, building an application for finding and adopting pets. Three features on the
product backlog could be: 

1. Presenting information about available pets

2. Rating potential matches based on adopters
3. Allowing user to contact the adoption center

It doesn’t make sense to ship any one of those features in isolation, but finishing a
potentially releasable Product Increment is helpful because it enables the team to see
one feature in its entirety rather than to work on bits and pieces of all three features with
none of them actually completed. With a potentially releasable Product Increment, you
will create a complete, working, tested implementation of one feature in a single sprint.

Having a potentially releasable Increment also allows the team to get early feedback on
the product, ensure that the work is high quality, and have the opportunity to respond to
change. You should always focus on a potentially releasable product increment as your
sprint goal.
 Definition of Done
A related term is the Definition of Done. The Definition of Done is a formal description of
the state of the potentially releasable Product Increment and what it means when it
meets the quality measures required for the product. It is the team’s agreed-upon
requirements for any backlog item that is considered “done.” In software projects, teams
often decide that “done” means the software has been completed, reviewed, and has
passed testing. In a non-software project, a Definition of Done may be a document
including a legal review with approval or a formalized closeout report. The important
part of figuring out your team’s Definition of Done is to have an explicit, shared
understanding of what being “done” entails.

But how do you know when a solution is shippable or releasable? In a Scrum Team, it is
ultimately the decision of the Product Owner to ensure there is value before releasing
an item. To determine this, they may consider a few things: 

1. Is the increment complete? 

2. Will it bring value and does it meet quality measures? Has it been well-tested? 
3. Is it usable by the end user? Can we use their direct or indirect feedback to improve
future versions of the product?

Comparing Releasable Product Increment to Minimum

Viable Product
As you learned in the previous video, a minimum viable product (MVP) is a version of a
product with just enough features to satisfy early customers. Eric Ries, an entrepreneur
and author, coined the term in this guide and defined an MVP as “that version of a new
product which allows a team to collect the maximum amount of validated learning about
customers with the least effort.” In other words, gathering insights from an MVP enables
quicker feedback from users than developing a full-featured product that may not be
100% tested or secure. Some examples of an MVP could be a landing page for your
website or a “buy now” button that doesn't do anything other than register that someone
has clicked it. A minimum viable product is a package of features that may take several
sprints to develop, but every sprint’s goal is to produce a product increment. To
differentiate between a potentially releasable increment and a MVP, let’s take our
example of the online pet adoption app and the three features we discussed previously.
We noted that each of these features on their own wasn’t a useful release of the
solution. However, the Product Owner may decide that the MVP for this user experience
is to implement these three requirements for cats only. By reducing the scope of the
MVP, the Product Owner is able to release the solution into the marketplace and collect
feedback from the users who wish to adopt cats. This feedback will be valuable not only
for the cat adoption process but for any type of pet adoption in future iterations of the
product. 

Key takeaway
 So can a releasable increment be an MVP? Yes!  Does it always have to be an MVP?
Not necessarily. A Scrum Master or Product Owner is always making sure that the team
is building potentially releasable increments of the solution or product. Then, the
Product Owner uses those product increments and business insights to determine what
will make up a valuable and viable release of the product to their customers. This is
based on both user value delivered and the ability to gather feedback that will
continuously improve the product.

Sprint Retrospectives: Pitfalls and best practices

Throughout this program, we have discussed retrospectives. Retrospectives are an
integral aspect of project management, especially true when it comes to working in
Scrum. As we mentioned in the previous video, retrospectives are one of the five Sprint
events in Scrum. In this reading, you will learn some best practices to implement and
pitfalls to avoid when conducting Sprint Retrospectives. 

Sprint Retrospectives
As a refresher, retrospectives are workshops or meetings that give project teams time to
reflect on a project and brainstorm potential future improvements. In the Scrum
framework, Sprint Retrospectives occur at the end of each Sprint, which is usually every
one-to-four weeks. 

Sprint Retrospectives are a key practice that supports the Scrum theory and values.
They are a critical moment to inspect and adapt to the outcomes produced within the
Sprint timebox. Retrospectives occur much more often in Scrum than in traditional
project management,  so it is important to consider some best practices and pitfalls to
avoid to help make them engaging and productive for the entire team.

Product roadmaps: Benefits, pitfalls, and best practices

As you learned in the previous video, roadmaps are an important part of any long-
running project. In this reading, we will summarize the benefits of and best practices for
developing a product roadmap, as well as highlight some of the pitfalls you might
encounter. 

You may see different types of roadmaps as you continue your project management
career. Each team or company may interpret the roadmap slightly differently. Here are
some of the various types:

 Project roadmap
 Product roadmap
 Value roadmap
 Lean roadmap
 Agile roadmap
 Roadmaps are often represented visually and many try to fit the roadmap on one page
so that reviewers can notice the big picture of the product timeline.

The benefits of developing and maintaining a product roadmap are numerous:

 Clarifying the sequence of deliverables 

 Showing teams how their efforts relate to the north-star vision. In other words, their
ultimate goal. 
 Showing stakeholders the incremental value that will be achieved over the course of the
project (rather than reviewing it as one big delivery at the end)
 Helping stakeholders roughly understand the layout of the work behind the deliverable
There are also some pitfalls around roadmaps to avoid:

 Letting stakeholders think the roadmap is set and unchangeable. This may cause
stakeholders to impede teams’ ability to adapt in response to new information, as well
as put a lot of pressure on teams to achieve deadlines no matter what it takes.
 Spending too much time fine-tuning delivery dates versus keeping them rough and
improving specificity as the dates get closer
 Putting all the work into creating the roadmap rather than producing the deliverables 
Here are some best practices to help you get the most from your roadmaps:

 Make it highly noticeable to the team and refer to it frequently.

 Clearly indicate the highest priority items.
 If possible, clearly indicate the highest value items.
 Make it visible to your wider stakeholder group so that they can use it for their planning. 
 Conduct regular reviews of the roadmap with sponsors, stakeholders, and the team to
ensure that it is still providing the blueprint for the project.
To learn more about some best practices for building product roadmaps, check out this
article: Product Roadmap First Principles

Key takeaway
Roadmaps are important for any well-managed project, but they are especially useful to
Agile teams. Having a shared roadmap about what the team is delivering over a longer
time period is an important way to connect the work that the team does on the sprints
with the broader vision for the project. This helps the team stay motivated through the
rough patches and leads to a great sense of accomplishment as roadmap deliverables
are achieved. 

Pitfalls
 Avoid too many gimmicks. There are many fun games and exercises that can be used
by a Scrum Master when facilitating a Sprint Retrospective. However, not all teams
enjoy this style. Consider using these exercises only occasionally or when the team
asks for new ways of doing retrospectives.
 Try not to only focus on the negative. Not only is it necessary for the team to recognize
what’s not working well, it is also important to highlight where they exceeded
expectations. This ensures that the team both avoids failures and repeats successes as
well.
 Avoid changing processes after each retrospective. It is okay to keep a new process in
place for a few Sprints before deciding whether it was useful or not. You can always
make note of opportunities for change, but try to wait a few Sprints before implementing
new changes.

Best practices
 Ask open-ended, probing questions. Ask questions that require thoughtful discussion
rather than a yes-or-no answer. For example, ask, “How could we have better achieved
our Sprint Goal?” rather than “Did we achieve the Sprint Goal?””
 Consider diverse styles of communication and participation. Make it easy for all team
members to contribute their ideas and feedback. For example, not everyone feels
comfortable speaking up in a large group. Try things like starting the retrospective with
silent reflection by journaling or putting the team into pairs before starting a larger group
conversation.
 Cover the many aspects of the Sprint when conducting a retrospective.
1. The productivity and efficiency of the team
2. The scope and understanding of the definition of done
3. Communication and interactions within the team
4. Stakeholder communication
5. Progress towards more long-range release plans
 Consider reflecting periodically on Scrum theory and values by asking specific questions.
For example, ask, “How could the team become more transparent?” or “How did we
abide by our Scrum values in this Sprint?”

Interpreting velocity: Dos and Don'ts

In the previous video, we defined velocity as “The measure of how many points the
team burns down in a given Sprint on average.” Velocity measures the amount of work
a single team can be expected to complete during an iteration. When we refer to story
points, we are referring to a unit of measurement that expresses the estimated effort
required to implement that Product Backlog item. These story points are calibrated and
decided on by the team.

Calculating velocity
As described in the video and readings, estimating effort can be done in a variety of
units. Most often in Agile teams, story points or T-shirt sizes are used to estimate effort.
If you use T-shirt sizes, your team will map those sizes to a numeric value for the
purpose of calculating a team velocity. 

When your team begins running Sprints or iterations, they won’t be able to accurately
determine velocity because they will have no historical basis on which to calculate an
average number of points completed in a Sprint. In their very first Sprint, your team will
make a rough guess as to how many items they can complete just to get started. Once
a few Sprints have been completed, your team will have a good measure of their
velocity, and they will use that number to determine which items to include in their Sprint
Backlog. This should be easy to do if your team has a properly prioritized and estimated
backlog to work from. As you will recall from the videos, this process is called backlog
refinement.

Using velocity for good 

When interpreting velocity, it is important to keep a few things in mind. You may feel
inclined to share velocity with members outside of your team or to use velocity as a
performance or comparison metric. You may also feel inclined to use it to determine a
projected delivery date. However, some Agile experts warn against these practices.
Let’s discuss why. 

Velocity can be helpful for individuals outside of the Scrum team, but when sharing it
with non-team members, be very careful. Since velocity is different for every team, a
stakeholder may not have enough context to interpret it. Be sure to share relevant
supporting materials to help add context. A good example of this is sharing the velocity
with a corresponding date range and visualization that indicates trends over time. There
may be dips and spikes in velocity that draw insights and encourage improvements in
future projects. 

It is natural for individuals to want to quantify performance through data, but it can be
detrimental for a team to feel that kind of pressure within their Sprints. There may be
executives, sponsors, or stakeholders that want to use velocity as a performance
metric, but this will only hurt the team by encouraging tactics like intimidation. If the
team is worried about their velocity making it seem like they are underperforming, the
team’s culture can become harmed as a result. 

If you are leading a few different Scrum teams, you may be tempted to compare the two
teams’ productivity based on their velocity. You may have the impulse to check which
teams are completing the most story points per iteration. However, the weight of
different story points is subjective because they are created by the team. One team may
consider a story to be five points, but another team might consider it to be closer to
three points. Therefore, judging productivity solely on velocity isn’t accurate or fair.
Additionally, velocity is not a measure of value. One team’s velocity might differ from
another team’s, but this variability is fine as long as both teams are delivering value to
your stakeholders.

Using velocity to estimate the delivery date of a project spanning numerous Sprints can
be tricky. Velocity can be used as a pressure point by external stakeholders who want
to set a date for their product launch. Velocity can also create false expectations and a
harshly competitive culture when the team doesn’t hit the estimated dates. Projecting
deliverable dates is harmful because it can take a team several Sprints to really
understand what they are capable of delivering in each iteration. Also, if you map out
too many dates in advance, you aren’t able to account for the changes and issues that
will arise. Therefore, make sure you are being careful not to use the estimated delivery
dates as commitments. 
 How to Combine DevOps and Agile 
 Agile vs DevOps: What's the Difference?
 The Convergence of Scrum and DevOps

Scaling Agile
In the preceding videos, we’ve covered how to run a Scrum team of up to nine team
members. But what do you do if your team is larger than that? Or if the size of the
product or solution is so large that multiple teams are required to do the work? In this
reading, we will explore five frameworks that scale the Agile approach to address the
needs of large initiatives or solutions: Scaled Agile Framework (SAFe), Scrum of Scrums,
Large Scale Scrum (LeSS), Disciplined Agile Delivery (DAD), and the Spotify Model.

Scaled Agile Framework (SAFe)

The most popular scaled framework is the Scaled Agile Framework or SAFe. SAFe is a
Lean-Agile scaling framework that draws heavily on concepts from Kanban, Scrum,
Extreme Programming (XP), DevOps, and Design Thinking methodologies. SAFe puts
the goal of delivering value above all else—the first principle of SAFe is “take an
economic view.” The framework organizes all work and teams into “Agile Release
Trains” based on value streams; for example, sales. The SAFe framework is mature
and provides detailed guidance on all elements of using SAFe, but some elements are
more critical than others. Be sure to check back to the Agile principles and values in the
manifesto to be sure you are preserving agility. 

SAFe, like most Agile practices, is founded on a set of core values:

 Alignment: Synchronize the planning and execution of SAFe activities at all levels of the
organization. 
 Built-in Quality: Build quality into all stages of solution development. 
 Transparency: Make execution activities visible at all levels to build trust among teams
and across the organization. 
 Program Execution: Focus on working systems and business outcomes. 
 Leadership: Model the values and principles of SAFe. 
Read this article to learn more about the core values of SAfe.

Scrum of Scrums
Scrum of Scrums is a technique for integrating the work of multiple, smaller Scrum
teams working on the same project or solution. Coordination among teams is critical to
ensuring the deliverables from each team can be integrated into one larger, cohesive
deliverable. 

Scrum of Scrums involves the following elements:

 A group of at least 12 or more people divided into Scrum Teams of five to ten people
each 
 Scrum of Scrums meetings, which are held once a week, twice a week, or daily. These
meetings follow the same format as a Daily Scrum meeting but focus on the Scrum
team. In these meetings, you’ll discuss questions like: “What did the team do
yesterday? What problems occurred, if any, that are negatively affecting your team?
What does your team want to accomplish before we meet again? Is your team blocked
from moving forward on any tasks?”
 A Scrum Master or designated “ambassador” for each team that participates in the
Scrum of Scrums meetings and a Scrum of Scrums Master who focuses on the overall
Scrum process across multiple teams 
 Sprint Planning, Sprint Review, and Sprint Retrospective meetings 
Beyond these very basic guidelines, there is no official framework or methodology to
implement Scrum of Scrums. Scrum of Scrums assumes that teams have a good
working understanding of Scrum and are able to apply the scaling principles to how they
work. Building on this knowledge, they design and iterate their own approach to
coordinate multiple teams working on the same product. 

Large-Scale Scrum (LeSS)

Large-Scale Scrum (LeSS) is a framework that aims to maximize the Scrum team’s ability
to deliver value and reduce waste in larger organizations. LeSS grew out of more than
600 experiments that expanded the practice of Scrum to larger groups. 

LeSS includes ten principles for applying the value, elements, and overall purpose of
Scrum across an organization. These principles were designed to create more
customer- and collaboration-focused teams. LeSS teams prioritize learning,
transparency, and customer needs. The ten LeSS principles are:

1. Large-scale Scrum is Scrum: Apply the values and principles of Scrum to a larger team. 
2. Empirical process control: Inspect, adapt, and learn from experience to improve
processes. 
3. Transparency: Ensure clarity and accessibility across a project. 
4. More with less: Create only necessary processes, roles, artifacts, and waste when
scaling. 
5. Whole-product focus: Think holistically about the product, making sure that all the parts
serve the whole.
6. Customer-centric: Keep the customer’s needs and values at the heart of your process.
7. Continuous improvement towards perfection: Improve the product—and your process—
during every single Sprint. 
8. Systems thinking: Think about the system as a whole; Don’t get lost in the details. 
9. Lean thinking: Seek continuous improvement, aim for perfection, and respect people.
10. Queuing theory: Embrace the Lean principles of “flow,’ manage queue size,” and
“minimize multitasking” to keep delivering value. 
The LeSS toolkit provides two frameworks—one for up to about 50 people (called Basic
LeSS) and one for 50–6000+ people (called LeSS Huge). More information on the LeSS
frameworks can be found at less.works.

Disciplined Agile Delivery (DAD)

Disciplined Agile Delivery (DAD) is a hybrid approach that combines the strategies from
various Agile frameworks, including Kanban, LeSS, Lean Development, Extreme
Programming, Agile Modeling, and more. DAD guides people through the process-
related decisions that frameworks like SAFe and Scrum of Scrums leave open. DAD
helps you develop a scaled Agile strategy based on context and desired outcomes. 

DAD is organized into four “layers”:

1. Foundations discusses the principles, guidelines, Agile concepts, roles and team
structure definitions, and Way of Working (WoW).
2. Disciplined DevOps ensures that solutions are delivered to customers effectively and
safely, with data and security management always at the forefront.
3. Value Streams ensures that solutions are aligned with the organization's business
strategy, connecting customers, sales, and portfolio management to the framework.
4. Disciplined Agile Enterprise (DAE) connects the industry marketplace with corporate
governance and larger enterprise activities.
Project managers wishing to implement DAD can read more about the framework in this
article: Going Beyond Scrum.

The Spotify Model

Another approach you may encounter is the “Spotify Model,” which we discussed in a
previous reading. It is important to note that Spotify’s model is not a true Agile
framework. There is no standard guide on how to implement it. The model began as a
description of how Spotify overcame the challenges of scaling Agile. By focusing their
efforts on culture, team autonomy, communication, accountability, and quality, they
increased their agility over time. Spotify’s approach has had a huge impact on
workflows and team structures across the tech world. Some of the key components
include:

 Squads: Like Scrum teams, Squads are autonomous teams of 6–12 people working
toward the same outcome. All Squads include a coach (similar to a Scrum Master) and
a Product Owner.
 Tribes: When multiple Squads work on the same feature area, they form a Tribe of 40–
150 people. Each Tribe has a Tribe Lead who fosters collaboration and coordination.
 Chapters: Squads may be autonomous, but specialists (e.g., JavaScript developers)
should still align across an organization. Chapters establish best practices and, where
necessary, set standards. 
 Guilds: Any group of people interested in a certain topic can form a Guild, where people
with shared interests can come together as a community. 
While some organizations have had success with this model, be aware that it evolved
from Spotify’s already significant Agile experience. It is the product of extensive
introspection and adaptation and draws heavily on the company’s culture of trust,
transparency, and autonomy. Therefore, the value of Spotify’s approach to scaling is not
in team names like Squads and Tribes but in how they developed practices that
supported and served their organizational culture. To learn more about the Spotify
Model, check out this video from Henrik Kniberg.

Best practices for scaling Agile

No matter which framework you choose, it’s important to keep a few basic principles in
mind:

 Treat scaling models like SAFe, Scrum of Scrums, LeSS, etc., as general frameworks,
not instruction manuals. 
 Different situations require different solutions. It’s okay to mix and match elements from
multiple frameworks, as long as you apply the principles and values of the Agile
Manifesto.
 Don’t try to scale without prior Agile experience. Going straight from Waterfall to scaled
Agile can be risky without a knowledgeable guide.
 Finally, and most importantly, don’t scale if it isn’t necessary. The larger your team, the
more complex and difficult your project becomes. 

Key takeaway
Scaling Agile can be as simple as putting two Scrum teams together into a Scrum of
Scrums configuration or as sophisticated as training an organization of thousands in the
SAFe framework. When you have a large team or a big deliverable that requires
multiple workstreams, think about how you can scale to suit your situation. Remember
that you can modify SAFe, LeSS, and other scaled frameworks to meet the needs of
each project. Make sure your team understands Agile principles before you try to scale
since scaling inevitably introduces more waste and complexity.
Interview
COURSE 6

Initiation

A project charter is a formal document that clearly defines the project and outlines the necessary
details to reach the project's goals. The project manager creates the charter during the initiation phase,
which is the first phase of the project life cycle.

The project charter:

- helps you organize vital project information,

- create a framework for the work that needs to be done, and

- communicate those details to the necessary people.

The project charter contains key information about a project,  like the summary, goals,
and deliverables, scope.

Misalignment occurs when stakeholders are not in agreement about the details of the project.
It can happen between the project manager and any stakeholder at any stage of the project,
and is a common cause of project failure. 

Question 3
How does a project charter act as an alignment tool?

Addresses misalignments and documents when and how stakeholders resolve them

Lays out project details to ensure the team is working toward the outcomes all stakeholders expect
Question 1
What is the purpose of a project charter?
- Defining the project and outlining the necessary details in a clear, succinct format can ensure
that all project stakeholders agree on what a successful project looks like.

-Providing vital project information in a well-organized and skimmable format ensures that more
senior stakeholders who may not have time to read all of the details still have visibility into the
project and an opportunity to provide feedback on the plans.

-Аcts as a useful reference throughout the project. The project charter is a living document
which should be continually updated so that all members of the team and senior stakeholders
have a central location to refer to about the project.

To facilitate alignment, you present the charter to stakeholders and confirm agreement.
This is essential, as misalignment among stakeholders about project details is a
common cause of project failure.

SMART goals

The SMART method helps you make your goals more specific by making them measurable. For
example, if your stakeholder wants to increase company profits, ask, "By how much?" Do they
want to increase profits by five percent? By 30 percent? Adding numbers and figures to your
goal makes it a lot easier to know when you've achieved it.

If you're having trouble making a goal measurable, research how others in your industry quantify
success. This is called benchmarking, which refers to evaluating success against the standard.
For example, there are lots of ways to measure success in the restaurant industry. You might
search online for information using queries like "How do restaurants measure success?"

SMART goals are also attainable, which means that the goal is challenging but not impossible
to reach. Ask yourself and the team, "Can it be done?" Do you have the time, resources, and
people available to complete the goal on time and within budget? If not, you'll need to make
some changes to your goals.

And all project goals should be relevant. Ask yourself, "Does it make sense for us as a company
or as a project team to pursue this goal?" One best practice for determining the relevance of your
project goals is to notice how closely your project goals align with the wider goals of your
company or organization.
A stakeholder's influence is related to how much power they have and how much their actions
affect the project outcome.

Interest refers to how much the stakeholder's needs will be affected by project operations and
outcomes.
 Stakeholder management: Tips and takeaways
Stakeholder management is the process of maintaining good relationships with the
people who have the most influence on your work. Efficiently managing stakeholders is
an integral part of every project because it encourages good communication, teamwork,
trust among members, and so much more. Without effective stakeholder management,
a project is less likely to be successful. Read on for some tips and best practices for
effective stakeholder management.

Stakeholder management during project initiation

 Identify all the stakeholders at the beginning of your project or initiative. Get everyone
involved as early as possible to set clear expectations, responsibilities, and boundaries.
Identifying your stakeholders early on gives them ample time to voice any concerns they
may have about the project or their role within it. If they feel a sense of ownership from
the beginning, your stakeholders may be more likely to embrace their roles, give
appropriate input, and help remove barriers to allow the project to move forward.  
 Keep the project vision clear. The project vision describes the need the project is
fulfilling. It is important to have a clear, specific project vision because, as we have
learned, stakeholders may apply pressure to increase the requirements, shorten the
timeline, or cut resources. Ensuring that stakeholders have agreed upon the vision—
and, more specifically, what "done" looks like—provides clarity for everyone involved
with the project. Including highly-influential stakeholders in the strategic planning
processes will make sure that all team members are aligned with project vision. 
 Equip your stakeholders with user-friendly resources at all times. This could mean
creating a one-pager (a one-page document that provides an overview of your project)
or weekly status report with the latest information and links to the main project artifacts.
It may also mean ensuring everyone has access to necessary documentation. 

Stakeholder management throughout the project life cycle

As you work your way through the project life cycle, you will have to maintain good
relationships with all of your stakeholders to ensure they are satisfied and contributing
to the team. The following strategies can help you get to know your stakeholders’
interests, concerns, and communication preferences and enlist their help throughout
your project’s life cycle:

 Find out what stakeholders care about and why. Ask your stakeholders: What are your
most important priorities and goals? What role would you like to play in this project?
How will this project support you and your most important priorities?
 Adjust your communication frequency and approach based on stakeholder roles and
preferences. Tell your stakeholders: Here’s how I plan to keep you informed—does that
work for you?
 Enlist the help of senior stakeholders when necessary. Ask your stakeholders: Who else
do you recommend I reach out to regarding this project? 
 Once stakeholders have a vested interest, bring project problems to them. Ask your
stakeholders: How would you handle this situation? What solutions come to mind?
 Negotiating scope with stakeholders
Even after you’ve established the project’s scope, some stakeholders may want to
discuss adjusting it. They may feel that the project’s current scope will require too much
work with too few resources, that the timeline isn’t realistic given the scope, or that the
project requires additional tasks and objectives. When your stakeholders ask to revisit a
project’s scope, you should meet with them so they can raise their concerns. Knowing
how to effectively facilitate scope negotiations will allow you to reach solutions that are
suitable for everyone. 

Tips for navigating scope with stakeholders

 Understand motivations. Before your discussion, consider each stakeholder's
motivations for wanting to adjust the project’s scope. Some of those motivations are
budgetary (such as wanting to reduce the project’s costs), some are interpersonal (such
as wanting more time to complete tasks), and some are related to personal career goals
(such as maintaining their current position or striving for a promotion). Understanding
your stakeholders’ motivations can help you work together to find a compromise. 
 Set the scene. Start the discussion with a reflection on why you are meeting. Remind
your stakeholders why you are engaged in this project, and assure them that you all
share a common goal.
 Listen first. Hear what your stakeholders have to say before you present your views.
This will demonstrate your desire to understand the other party’s perspective.
Acknowledging their point of view may make it easier for them to accept your
suggestions or solutions when their ideas or opinions differ from yours.
 Ask questions to define goals. Be thorough and ask as many questions as you feel
necessary to understand what the stakeholder wants. This might include getting them to
define their customer or business goals. Strive for getting specific, measurable details
from your stakeholders, so that later, you’ll be able to determine whether you’ve
successfully met their goals. Eliciting language that is measurable (rather than
subjective or unclear) will help you define goals. An example of a specific, measurable
goal could be: “We want to cut the amount of time it takes customers to sign up for our
newsletter by at least 30 percent.”
 Explain the “why” before the “what.” When attempting to persuade stakeholders—or
anyone, for that matter—to see things your way, explain the reasons for your request
before describing what you want. For instance, start by explaining the value that could
be added to your company or project by defining scope in a certain way. If stakeholders
understand where you’re coming from first, they’re more likely to grant your request
when you ask for it.
 Do not oversell. Sometimes it’s best to state your case and give others some time to
respond. After you have presented your reasons, position, and request, withdraw
slightly to give your audience time to process what you have said. Think of your silence,
in this situation, as a sign of respect for your stakeholders; it shows them you want to
hear from them. And, if they are quiet for a while, it means that you have stimulated
thought.  
 Be creative. Working to find alternative solutions can quickly turn a heavy negotiation
into an inspiring team effort. To find real solutions to negotiation stalemates, think
creatively about all the aspects of the project. You may find that there is more than one
solution to differing opinions. 
 Do not make it personal. Always focus on what is good for the project. If personal
considerations enter into the discussion, reframe the conversation by bringing up
objective facts.
 Seek a win-win outcome. Finally, consider what it will take for the other side to be
satisfied. Then, try to identify a way to ensure you are satisfied as well. There will be
times when one party may have to compromise more than the other,  but a mutually
beneficial agreement (an agreement that benefits all parties involved) should always be
the goal. The next reading will cover strategies for achieving mutually beneficial
agreements with stakeholders.

Achieving a win-win outcome

In the last reading, you learned about effective ways to negotiate a project’s scope with
stakeholders. The goal when negotiating with stakeholders should always be achieving
a win-win outcome, or a mutually beneficial agreement. This is an agreement that
benefits all parties involved. Mutually beneficial agreements aren’t only for internal
stakeholders, though. They are an important part of the process for negotiating with
vendors, contractors, suppliers, and more. 

Best practices for reaching a mutually beneficial agreement

 Share information. Sometimes in negotiations, one or both parties might think they need
to withhold information in order to not give too much away. This isn’t very effective,
though. It is best to strive for open lines of communication, where each party shares
their worries and preferences. For instance, if your team’s last supplier provided you
with low quality products, you might voice this as a concern so your expectations
around quality are clear. 
 Ask questions and listen actively to responses. Just like you shared your concerns and
expectations, you can ask the other party questions to clarify what their concerns and
expectations are. That way, both parties will have shared all the necessary information
to achieve a mutually beneficial agreement. 
 Propose multiple options whenever possible. In negotiations, presenting only one option
or solution can set you up for failure because the other person might think your first offer
is the only one. If the other party rejects all of your proposals, ask them to communicate
which one they like best, as that may point you in the direction of finding a solution that
works for everyone.
Planning
A project plan is useful for any project, big or small, since it helps you
document the scope, tasks, milestones, budget, and overall activities in order to
keep the project on track. At the center of the project plan is the project schedule.
The schedule is your guide for making time estimates for project tasks,
determining milestones, and monitoring the overall progress of the project. One of
your main jobs as a project manager is to identify all of the project tasks, estimate
how much time each task will take, and track each task's progress. So how do you
go about adding tasks and milestones to the plan for the very first time? The first
thing I do is review the goals and deliverables in the project charter. Then, I make
a list of all the items that have tasks or milestones associated with them. As a
reminder, milestones are important points within the schedule that indicate
progress. They usually signify the completion of a deliverable or phase of the
project. And project tasks refer to activities that need to be accomplished within a
set period of time. They're assigned to different members of the team according to
each person's role and skills.

Tips for defining project tasks

The process of identifying project tasks and defining them is one that requires practice.
Breaking tasks down into workable parts is challenging because you have to decide
which tasks may require additional subtasks and which tasks do not. For instance, if you
are managing a cross-country move, you do not need to break down the task of
unloading boxes from the car into which box should be moved first. However, you may
need to break down the movers’ tasks into smaller, more detailed steps. As you
progress in your career, you will get better at breaking tasks down. In the interim, here
are some guidelines to help you improve this very important project management skill. 

Define project tasks in one or two sentences

When writing descriptions of project tasks, keep them to one or two sentences long. If
you find that a certain task description needs to be longer than one or two sentences,
this indicates that the task is complex and could be broken down into smaller tasks or
that it may need further clarification.

Look at project task dependencies

When looking at how you might break certain parts of the project down into tasks,
consider task dependencies, or what has to be completed or handed off from one person
to another before work on each task can begin. Identifying dependencies can help you
decide how much a task needs to be broken down. For instance, if you are managing a
project that includes an awards ceremony and one of the tasks is to set up the stage,
the dependencies for this task could include getting estimates from an audiovisual (AV)
contractor, procuring necessary equipment, and constructing the stage backdrop.

Enlist help from team members

It is often helpful for your team to be involved in the task breakdown process. You might
have a meeting where you discuss each broad goal or major task with the team. This
way, team members can present varying perspectives as they work together to break
down tasks. For example, if someone on your team has had experience on a similar
project, they may suggest a certain task actually be broken down into three different
tasks. 

Define project tasks by the amount of time they will take to

complete
Defining project tasks by the amount of time they’re expected to take will reveal any
especially lengthy tasks. If a task is expected to take a long time, it could indicate that
there are additional subtasks that need to be defined. Identifying tasks by time is helpful
for scheduling other tasks or events around the longer tasks. This strategy also helps
you determine appropriate milestones, as milestones are often the culmination of a
series of tasks. Acknowledging the completion of a large and lengthy task is also a great
way to celebrate success, learn from the process, and keep the project on track.

Identify project tasks by their “done” factors

Begin with the end in mind: What does it mean for the task to be considered “done”?
From there, you can work backwards to see if you’ve missed any steps and identify
checkpoints for completion along the way.
The three-point estimating technique
Estimating is a crucial aspect of project management. Project managers are expected to
accurately estimate essential elements of the project, such as costs, scope, and time.
There are many different estimation techniques that can be used, depending on what
aspect of the project needs an estimate. Estimation techniques allow project managers
to provide better forecasts to stakeholders and clients and more accurately budget the
funds and resources they need for project success. 

The three-point estimating technique can be used to help determine the most realistic
time estimate for a task. It uses optimistic, pessimistic, and most likely calculations,
meaning calculations are based on the “best case” (optimistic), “worst case”
(pessimistic), and most probable scenarios. 

Three-point estimation
In this technique, each task receives three estimates: optimistic, most likely, and
pessimistic. Each of these three estimates is then associated with the corresponding
amount of time that task is expected to take.
The three-point estimating process
For each task, add a duration estimate in each category: optimistic, most likely, and
pessimistic. You can get these estimates by doing research on the task or by asking a
task expert. As a best practice, add notes about the conditions that determine each
estimate.
Determining a final estimate
To determine your final estimate—the estimate you’re going to use in your project plan
—examine the optimistic and pessimistic timing, then compare it with the most likely
timing. Consider the conditions that are likely to exist while the task is being completed.
Does it seem reasonable that the most likely time can be met? If your team has never
completed this task before, or if dependencies for the task are unknown, then the final
estimate should be closer to the pessimistic estimate. If your team is familiar with the
task and you’re able to confirm the conditions for an optimistic estimate, then the final
estimate can be closer to the optimistic estimate. Alternatively, simply use the most
likely estimate, especially if the difference between the optimistic and pessimistic
estimates is minimal (a few hours or no more than one or two days). A good practice is
to build in a “buffer” that accounts for risks that are likely but still keeps the project
progressing at an efficient rate.

Three-point estimation formulas

Some projects will require you to calculate specific numeric values for task time
estimates. There are many online resources that provide more instruction for how to
calculate estimates, but we’ve provided two popular formulas: the Triangular Distribution
and the Beta (PERT) Distribution.

For each formula: E is Estimate (the final estimate you’ll assign to the task), o =
optimistic estimate, p = pessimistic estimate, and m = most likely estimate.

The Triangular Distribution

The weight of each estimate in this equation is identical, which means the most likely
case does not affect the final estimate more than the optimistic or pessimistic estimates.
The Beta (PERT) Distribution
The Beta (PERT) distribution is a weighted average. The most likely estimate receives a
multiplier of four, while the overall divisor is increased to six. 

This method takes into account that the most likely case is more likely to occur, so it’s
given more weight. The added weight is reflected in the multiplier of four.

Placing more weight on the most likely estimate increases the accuracy of the estimate.
In most cases, the Beta (PERT) Distribution has been proven to be more accurate than
three-point estimating and is often used to calculate both cost and time estimates.
 Negotiating with empathy

Empathy is the ability to understand and feel what others are feeling. It's
when you make the effort to imagine yourself in the other person's
position and experience things from their perspective.
This has a negative impact because it demonstrates the manager's lack of trust
and confidence in the people they oversee. 

You might ask the person how long a particular task took them on a
previous project, rather than suggesting a time frame to complete a
similar task. Another way to show empathy is to periodically repeat
what you think the other person said. Noticing you restate their message
in your own words will encourage them to confirm their intent and will
ensure you understand what they're communicating.
Another strategy for practicing empathy is recognizing buffering. A
team member might add a buffer to their time estimate for a task without
communicating why they added the buffer. Ask them up front if they've
included a buffer to account for holidays, sickness, childcare, or
emergencies. This can demonstrate your empathy for their situation and
can also help you get a more accurate estimate. Encourage them to open
up about this extra buffer by assuring them that you want an honest
answer, even if it's not ideal.
Defining quality standards
Quality means making sure that you deliver what you say you will and
that you do so as efficiently as you can. Quality standards are the
requirements and specifications that your product or service must meet
in order to be considered successful by your organization and the
customer. There are lots of resources that can help you determine the
standards for your project, including project documents like the business
case and charter, conversations with experts and stakeholders, and
industry research. Some common categories of established quality
standards from various industries include functionality, design, safety,
ease of use, productivity, and effectiveness.

It's important that your standards are objective and measurable so you can clearly
identify that the standard has been met. As you have conversations and conduct
your research, you might notice stakeholders referring to a general category, like
ease of use, without providing specifics. As the project manager, you should aim to
get specific details by asking, "What would be a sign that the tablets are easy to use
or hard to use?" You might get a response like, "It shouldn't take longer than 20
seconds to place an order," or "Returning customers report that it's faster to use the
tablet versus placing an order with a server."\

Let's consider a few questions to ask yourself when considering various standards.
If standards are related to productivity and effectiveness, you might want to ask
questions like, "Should the existence of the tablets change anything about how the
front of house staff works? Does it make them faster or allow them to serve more
tables at one time?" If standards are related to customer satisfaction, you could ask
questions like, "How would the tablets ideally impact the customer's experience?
What would you want the customer to do or say as a result of using the tablets?"
By asking yourself or your task experts these kinds of questions, you can narrow
down the standard that you're aiming to make objective and measurable.
Quality assurance consists of reviewing processes to evaluate a project. Beta testing
is one QA method to help you evaluate and measure how well your project is meeting its goals.
Other examples of QA include internal checklists and feedback surveys.

Retrospectives: Encouraging participation

Before the meeting, try preparing a few examples of tasks or processes you know
you could have handled better. If you know that you made a mistake on a project
task, say it out loud. For example, maybe you made a paperwork error that slowed
down tablet delivery by two business days. Be honest about your mistake and talk
about how you'll avoid similar errors going forward. When you admit to your own
mistakes, you make it okay for the rest of your team to share their mistakes too.

EXAMPLE
Peta: Hi everyone! Thanks so much for taking the time to debrief about the tablet test
launch. We’re one step closer to the official launch! Before we begin our discussion, I
just want to say that I want everyone to feel like they're in a safe space here. Please
feel free to share whatever you need to in order to help us improve this process. Ok!
Does anyone want to start with what they observed as a success and what they
observed as an opportunity for improvement?

[long pause]

Alex: I think it went well.

Peta: Can you tell us a little bit about what you think went well?
Alex: Well, maybe someone else could go?

[long pause]

Peta: I could certainly go first. I think some of our successes were that we got all the
tablets installed, working, and had a chance to test them out! And that, in general,
everything went pretty well. The customers got the hang of the tablets, the tickets went
through, and the payments worked for the most part. I know personally, though, that our
table turn rate didn’t see much improvement, which was one of our goals. But we can
certainly focus on that going forward and brainstorm ways to improve efficiency. Who
wants to add anything?

[long pause]

Peta: Ok, if no one will jump in, why don’t we do this. Let’s go around and jot down
some ideas on the whiteboard about what went well and what can be improved. Gilly,
do you want to start?

Retrospectives: Addressing negativity

Determine how you'll set the tone of the meeting. Meeting props can help with this. For example, you
might hand out an even number of green and red index cards to each participant and ask attendees to
write successes on the green cards and challenges on the red cards. Passing out green cards might
subtly encourage the team to think of successes in addition to challenges.
Writing emails to stackeholders to escalate a problem

Closeout report
The closeout report is a great opportunity to compile all links and documentation
into one place, a practice we like to call: good project hygiene. The closeout report
is also a time for reflection on your team's performance, and it helps your team
ensure every task was completed. A closeout report confirms the project is done,
summarizes deliverables, success metrics, feedback, lessons learned and next steps
and serves as a reference document for the organization. If a follow up project is
required or a similar project is initiated, having these artifacts in one place will
help these future projects run smoothly and should another similar project occur,
future project managers will be set up for success if they have meticulous
information on past projects.