Conspect
Conspect
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.
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.
In this phase, ask questions to help set the foundation for the project, such as:
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.
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
/////////////////////////////////////////////////////////////////////////////////////////////////////////////
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?
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.
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:
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.
ORGANIZATION’S CULTURE
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
Processes
Values
To provide a welcoming environment where our employees become our family and
our guests become our friends
Values
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:
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.
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.
Benefits
SMART goals
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
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.
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
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.
Key results:
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:
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
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
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
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
Here’s how I plan to keep people informed; does that work for you?
me to find?
resistance?
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
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.
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.
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.
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
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.
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.
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.
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
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.
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.
2. Crashing
What if you need to rush an activity because of an early deadline?
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
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.
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
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:
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
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.
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:
**********
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.
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:
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.
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:
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.
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.
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.
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.
/////////////////////////////////
https://www.pmi.org/learning/library/effective-strategies-exploiting-opportunities-7947
////////////////////////////
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:
RISK ASSESSMENT
Types of risk
time risks,
budget risks,
scope risks
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.
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.
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.
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.
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.
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.
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?
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
Hide example
Example
Task
Description
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
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
Hide example
Example
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
Hide example
Example
Issue
Description
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
Hide example
Example
A budgeting spreadsheet can help a project manager log costs over time
and compare them against the actual budget.
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.
/////////////////////////////////////////
////////////////////////////////////////////////
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.
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.
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.
////////////////////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.
///////////////////
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.”
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.
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 . . .”
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?
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?
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
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.
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.
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.
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.
One way to provide air cover to your team is to say “no” to your sponsor’s request
without explicitly saying “no.”
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.
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.
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).
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:
………………………………………………………………………………………………………….
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.
Plenty of things can make meetings unproductive, but an internal study at Google
revealed that productive meetings have three elements in common:
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.
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.
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 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.
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.
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
\
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 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:
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.
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.
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 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:
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.
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.
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.
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:
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.
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:
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
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.
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.
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:
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?”
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.
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.
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.
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.
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.
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.
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.
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 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.
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.
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.
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.
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.
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]
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?
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.