Chapter 1- get to know project management

Deliver successful projects

Selecting transcript lines in this section will navigate to timestamp in the

video
- How do projects get started? When someone has a problem to solve or
an opportunity to pursue. We all want our projects to be
successful. Organizations want to enjoy the benefits that those projects
produce. And as project managers, we look forward to our next
project with opportunities to learn about new industries or manage
projects around the world. Delivering a project successfully is more
than writing up and handing out to-do lists. Your job, as project manager,
is an on-going balancing act between project scope and the
time, resources, and budget you've been given. To make things more
interesting, people will ask for changes mid-stream, risks will become real
issues, and work never goes according to plan. So you have to continually
correct course pretty much until the project is done. In this LinkedIn
Learning course, we'll use a case study to explore how to manage project
successfully. We'll look at how to start a project the right way and then
put together a comprehensive plan for running it. I'll guide you through
keeping your project on track from start to finish. You'll get chance to
practice what you learn with the exercises at the end of almost every
movie and with end of chapter challenges. With these techniques under
your belt, you'll be able to meet stakeholders expectations and handle the
changes that inevitably arise. I'm Bonnie Biafore. I'm a project manager,
consultant, and trainer and I've been helping people manage projects for
years. If you're ready to find out how satisfying it is to deliver projects
successfully, join me in my project management foundations course at
LinkedIn Learning.

What you should know

Selecting transcript lines in this section will navigate to timestamp in the
video
- You don't need to know anything about project management before you
start this course. It works either as an introduction to project
management for beginners or a refresher if you've been
managing projects for a while. In this course we're going to follow a
project through the project management life cycle. So for the next few
hours you're going to be a project manager for the Breslin Regional
Hospital. The hospital is adding a new cancer wing and improving its
facilities. Thanks to government grants and generous donations from
several donors. You'll be managing a project to replace the system and
processes for scheduling patients into rooms throughout the hospital. The
goal is to improve the hospital's scheduling capability and maximize the
use of facilities. A more complete description of the case study is available
in the exercise files.

What is a project?
Selecting transcript lines in this section will navigate to timestamp in the
video
- Before we talk about how to manage projects, let's make sure we're all
on the same page about what a project is. Here's a formal definition. A
project is a temporary endeavor that has a unique goal, and usually a
budget. That's a start, but what does it really mean? Let's begin with
temporary endeavor. Unlike day to day operations, a project has a definite
beginning and end. If a project is implementing a new system, the project
is done when you successfully hand it over to operations. What if a project
seems to go on forever? It could be that you haven't clearly defined what
you're trying to accomplish. That brings us to the project goal. A project
produces a unique result, which could be a product, service, or other
outcome. In the case study we're using for this course, a hospital is
implementing a new scheduling system. Lots of organizations implement
scheduling systems, but each one has its own set of objectives,
constraints, and issues. Maybe the hospital struggles with staff shortages.
Or perhaps a big pain point is scheduling equipment along with the skilled
staff and rooms needed to operate it. You could be upgrading the
scheduling system to improve results and level of care. Finally, most
projects have budgets. Most of the time, you think money when you hear
the word budget. In projects, you'll probably face other constraints as
well, like how many resources are available. A project isn't the same as
operations, which represents work that's the same day after day,
producing the same results. Admitting patients into the hospital
represents operational work. Patients may show up with different medical
issues, but the people at the front desk follow the same procedures, and
use the same forms to admit them. Introducing a new scheduling system
into the hospital, on the other hand, is a project. It will have a specific
beginning, it ends when the system is up and running, scheduling hospital
resources. It has a unique goal to solve the hospital's scheduling issues,
and it has a budget, both in money and resources time. Over your
lifetime, you've probably worked on lots of projects, both at work and at
home. A project is a temporary endeavor with a unique goal, and usually a
budget. Using those characteristics, think about what you've done over
the past several months. Identify the projects you've worked on during
that time by identifying the project's timeframe, what made the project
unique, and its budget. In the exercise files, you'll find a list of the work
I've done recently, tagged either as projects or operations.

What is project management?

- Lots of project managers get their start because they're good at making things
happen. But project management is more than showing off your organizational skills
and supervising others. It means applying knowledge, skills, tools and techniques to
achieve your project's objectives. Project management can be summed up as
answering a few crucial questions. The first question you have to answer is, what
problem are you solving? Clearly defining what the project is supposed to
accomplish is a big step toward making it a success. Legendary baseball manager
Yogi Berra's off-kilter take on it is, "You've got to be very careful "if you don't know
where you're going, "because you might not get there." The second question is, how
are you going to solve this problem? Whether you're solving a problem, or pursuing
an opportunity, you might have to choose from several possible strategies. Once
you've picked your approach, it's time to flesh out your solution, gathering
requirements, identifying deliverables, and defining project scope. The next question
is, what's your plan? A big part of project management is planning your project. You
have to identify the work to be done, in detail. How long it might take, the resources
you need, and how much they cost. With that info in hand, you can build a schedule
of when work should occur. While you're at it, you also need to spell out how you
want things to happen in your project, like communication, managing changes, and
so on. Some projects seem to go on forever, but eventually someone will pull the
plug if it doesn't finish. That's why you also have to answer the question, how will you
know when you're done? Clearly defined objectives, requirements, and deliverables
help answer that question, but you can eliminate uncertainty by defining success
criteria, quantifiable, measurable results that show that the project is complete, like a
certificate of occupancy, for construction, or increased productivity measurements
after a system is implemented. When you get to the end of the project, you're ready
to answer the last question, how well did the project go? This important step is often
skipped, because everyone is so ready to move on to the next deal. You really need
to take time to review the project. What worked well, what didn't, why? How could we
have done better? Project management boils down to answering several questions
about your project, what problem are you solving, how are you going to solve it,
what's your plan for getting the project done, how can you tell when you're done, and
how well did the project go?

What it takes to be a project manager

- Most people see project managers as really organized and good at getting things
done. But project managers also use a wide variety of skills and knowledge to
complete projects successfully. First, there are technical skills specific to project
management, like what goes into a project plan, building and fine tuning a project
schedule, reading a Gant chart, using the critical path and measuring performance.
Then there's business expertise. It's up to you to make sure your project delivers
value. You need to understand your organization's business, what it does, and what
it considers important. That way, you can see how your project fits in and you can
make good decisions to ensure that your project is successful. Problem solving is
another important skill. Projects never, and I mean never, go according to plan. Your
job is to figure out how to achieve project objectives and meet the schedule and
budget while working around the problems that arise. One of the most important
things in a project manager's toolbox is interpersonal skills. Projects may use people
from different groups, departments, and even different companies. You're the leader
of this group so it's your job to help everyone work as a team to get the project done,
and done well. The most important characteristic of a great project manager is strong
leadership. You want to inspire your people, help them become a true team, guide
them to do the right things, hold them accountable, and motivate them to give their
best. Does project management sound like something you want to do? This course
will help you figure out what you need to know so you can build a plan for developing
your skills.

The project management life cycle

Selecting transcript lines in this section will navigate to timestamp in the

video
- [Instructor] Project management can be categorized into five groups of
processes that help guide a project successfully from beginning to
end. Here are project management's five process groups according to the
Project Management Institute. Initiating is all about getting the
commitment to start a project. To get that commitment, you start
by defining the project. What's the project supposed to
accomplish? What's the scope? What's a rough estimate of the resources
needed, and the cost? You also identify the project stakeholders, and
make sure they agree on what the project is. From there, you ask for
approval to proceed. Planning is where you figure out how you're going to
perform the project. In essence, planning answers the questions, what are
we going to do? How are we going to do it? And how will we know when
we're done? When the plan is complete, it's time to get approval to launch
the project. The next two areas involve putting your plan into
action. Executing starts with launching a project. You bring your resources
on board, get them settled in, and explain the rules you're using to run
the project. After that, everyone jumps in to put the plan into
action. Monitoring and controlling a project means checking, what's going
on in the project, and how that compares to what you planned. If the
project is sliding off track, you take action to get it back on course. Finally,
there's the closing process. This part is short, but important. You get the
client to officially accept that the project is complete. You document the
project performance, gather lessons learned, close contracts, and help
resources move on to their next assignments. Those are the five process
groups that represent the project management life cycle. Put these
processes into action consistently, and your projects will run more
smoothly.

Traditional vs. agile project management

Selecting transcript lines in this section will navigate to timestamp in the
video
- [Instructor] Let's examine two common approaches to project
management, and how to choose the right one for your projects. When
each project management process group occurs one after another, it's
known as traditional project management, or the waterfall approach,
because the processes flow from one to the next. Waterfall project
management works well when the project goal and solution are clearly
defined, and the scope and deliverables are clear-cut. Because you
understand what needs to be done, you step through each process group
once from start to finish. The more you know about the project, the better
the waterfall approach works. Simple projects with very little uncertainty
are great candidates, because you know what needs to be done and how
to handle issues that arise. With familiar technology, your team can be
productive, because they know the potential problems and how to work
around them. If teams have worked on similar projects in the past, they
can be more productive because they understand the work and know how
to prevent or resolve common problems. With many projects today, you
don't know what the solution looks like, so you have to figure it out as you
go. This type of project requires a different approach. Agile project
management goes through iterations, sometimes called sprints, to deliver
partial, yet production-quality solutions at regular intervals. With this
approach, the customer gets value from the project sooner. In addition,
the customer's feedback on what's been delivered so far can help improve
the overall solution. The customer has to be more involved than in
traditional projects. Project teams tend to be smaller, more experienced,
and able to work without much supervision. During initiating and planning,
you define the overall goal for the project and build a plan to achieve that
goal. With agile project management, you then develop detailed plans for
each iteration. Executing is easier because you work on one iteration at a
time. And small independent teams of highly-skilled people make it easier
to get the work done. Another characteristic of agile projects is that you
monitor and control them more closely, and teams tend to communicate
faster and more frequently. Finally, each iteration has its own closing
process for accepting its specific deliverables. When the final iteration is
accepted, you can close the entire project. You'll determine whether the
traditional or agile approach makes sense during project initiation, once
you know whether or not your solution is clear.

How organizational structure affects projects

Selecting transcript lines in this section will navigate to timestamp in the video

- [Instructor] Organizations can be structured in several ways from the classic

functional hierarchy where each person reports to only one supervisor, to a matrix
where people report to both functional managers and project managers, to a
projectized organization where most of the people work on projects. Each of these
structures affects how projects are performed. In a functional hierarchy, projects
aren't the priority, making it difficult for projects to succeed. Project managers have
almost no authority. A functional manager is typically in charge of things like the
project budget. Resources are hard to come by because they report to functional
managers, not the project manager. Even the project manager and other project
management staff have to split their attention between the project and their regular
work. The second type, matrix organizations are still functional hierarchies, but they
support projects more than pure hierarchies do. They can be weak, balanced, or
strong depending on how much emphasis they put on projects. In a matrix, project
managers have some authority to make decisions. Resources assigned to projects
report to two managers, their functional manager and the project manager. In a
strong matrix, the project manager and project admin staff work full-time on projects.
Projectized organizations are all about projects. This third type makes it easier for
project managers to produce results. Project managers have almost complete
authority over their projects, including the budget. Resources are dedicated to
project work and report to the project manager. Project managers and project admin
staff also work full-time on project work. Organizational structure has a big influence
on how projects are performed, how much a project manager can do, and how easy
it is to make projects successful. Using these characteristics, determine which
structure your organization uses.

How organizational culture affects projects

Selecting transcript lines in this section will navigate to timestamp in the video

- Organizational culture is a set of factors that guide people's behaviors and

decisions within an organization. Things like shared values, beliefs, assumptions,
habits, and language. Let's talk about how organizational culture affects projects.
The organization's mission and vision shape the organization's culture. Projects that
support the company mission are likely to get more attention and resources. When
you're faced with a tricky decision, you can use the mission to determine the best
thing to do. Leadership and authority are also a big part of organizational culture. If
management defines clear goals and then delegates responsibility to employees,
that approach will also work in your projects. On the other hand, if authority isn't
handed out often, you need to work with management to get things done and build
their trust in you at the same time. Another aspect of culture is the organization's
work environment. With a positive environment, people are motivated to get things
done. And gathering lessons learned is relatively easy, because employees are used
to providing input and striving to improve. In a negative environment, you're probably
going to have to spend a lot of time managing your team. Some cultures believe in
following the rules no matter what. Other cultures nurture innovation, expecting
employees to try new approaches, question what's been done before, and come up
with better methods. You don't have to follow the rules in a rules-based culture, but if
you're thinking about breaking rules, it's important to know which ones you can
break. And also think about what you'll do if your non-standard approach doesn't
work. Does your organization put results ahead of procedures or vice versa? That is,
is it better to follow the rules, even if you don't achieve the objective or can you do
whatever it takes as long as you deliver the desired results? A project's goal is
always to achieve its objectives. But it's important to know where the boundaries are
in making things happen. Change management can be effected by organizational
culture. If the organization is risk-averse, change management might include multiple
rounds of review and require approval from several people. On the other hand, if
change is viewed simply as life in the project management world, change
management might be a lot simpler. With people working in locations around the
country or the world, you also need to consider the cultures of your team members.
People may react differently to situations or communicate differently based on the
norms of their cultures. For example, in some cultures, people are taught not to show
weakness, and that behavior could be interpreted as arrogance by people from other
cultures. Culture has a strong influence on how things happen within projects and
how decisions are made. To increase your success, you need to manage your
projects taking cultural factors into account.

Project management software options

Selecting transcript lines in this section will navigate to timestamp in the video

- [Narrator] Software tools can make your job as a project manager a little easier.
Let's talk about types of software and how you can put it to use managing projects.
Scheduling software comes in a variety of shapes and sizes. For most projects, you'll
want scheduling software to help you build and manage your project schedule. There
are lots of tool out there such as Microsoft Project, Oracle Primavera, LiquidPlanner,
Smartsheet, Wrike, Asana, and more. Most scheduling tools these days work in the
cloud to make collaboration easier. When you think about all the project
management documents you produce, it's no wonder that a word processing
program is essential. Because project documents are laid out similarly from project
to project, you can build document templates. That way you don't have to start from
scratch every time. A spreadsheet program is another must have for calculations and
analysis. Besides being handy for budgets and other financial calculations, a
spreadsheet can help analyze project risks and prioritize which ones you should
keep an eye on. A presentation program like PowerPoint or Prezi, is useful for
communicating project information at a high level. Or when you want to include
information from other types of documents. Because a team of people work on a
project you need some kind of tool for collaborating with others. Basecamp, Asana,
and Microsoft SharePoint, are a few cloud-based collaboration tools you can use to
share files with others, keep track of issues, or even manage your workflow. If you
work in an organization that runs many large projects at the same time you should
consider enterprise project management software. Enterprise level software provides
tools that allow you to find resources with the skills you need. And see which
resources are available when you need them. It helps you track risks, issues, and
other information and even build document libraries, so team members can easily
find information they need. We've briefly touched on some of the software options
available. If you're researching software to use consider the following in your
decisions. Your organizations culture and work environment, software budget, the
number of projects you manage, and their complexity.

Challenge: Organization

Selecting transcript lines in this section will navigate to timestamp in the video

(upbeat music) - [Narrator] An organization's structure and culture can present

benefits and challenges to any project. The exercise files for this chapter include a
summary of the Brislin Hospital culture and organization. There's also an
organization chart for the hospital. Take 20 to 30 minutes to answer these questions.
Once you've had a chance to complete this challenge, take a look at the solution to
see how I answered these questions.
Chapter 2 – first things first

Initiate a project

Selecting transcript lines in this section will navigate to timestamp in the video

- Initiating a project is about getting commitment to move forward. In other words, the
customer or sponsor says yes to the project and gives the go ahead to start
planning. Typically, the first step in project initiation is to assign the project manager
who guides the project through the rest of the initiation process. Sometimes the
project manager is assigned after the project's been approved. If you find yourself in
this situation, be sure to review what was done during initiation and complete any
activities that were skipped or left unfinished. The customer or sponsor should make
an informed decision whether to approve the project. That's why initiation boils down
to defining the project. You identify the problem the project is supposed to solve and
gather information about the project, objectives, requirements, deliverables, and
more. Once you have an initial project definition, it's time to prepare the project
charter. This document formally authorizes the project and describes the authority of
the project manager. Throughout this chapter I'll describe the key elements of a
project definition and what goes into a project charter.

Identify project stakeholders

Selecting transcript lines in this section will navigate to timestamp in the video

- [Narrator] As project manager, you need to know who has a stake in the outcome
of your project. They're called stakeholders. They include the customer, project
sponsor, departments involved with the project, and people who work on project
tasks. You need to know what they expect from the project and how they contribute
to it. It's vital to understand stakeholders' importance, influence, and interest in the
project. That way, you can build relationships with influential stakeholders and make
sure they're satisfied with project results. Let's start by identifying major stakeholder
roles. The project customer is the person or group with a problem to solve. For the
hospital scheduling project, the COO oversees scheduling, so she is the customer.
The project customer brings three crucial things to a project. First, the customer
funds the project. In the hospital, the CEO oversees the overall budget for the new
cancer wing and operational improvements. But the hospital's COO is in charge of
the budget for the scheduling project. Second, the customer has a lot to say about
what they project will do. Third, the customer approves deliverables from start to
finish. The next stakeholder role is project sponsor. The sponsor is someone who
wants to see the project succeed and has enough formal authority to make that
happen, like an executive who believes in the project. For the scheduling project, the
COO is also the project sponsor. She wants to see it succeed because she believes
effective scheduling not only improves patient care and medical results but also
produces better financial results. Her position gives her enough authority to
champion the project. A sponsor can help prioritize objectives, talk to stakeholders
who aren't being supportive, and suggest improvements to the project plan. The third
type of stakeholder is a functional or a line manager. Functional managers run
departments and are accountable for achieving their department's goals. They also
manage the people in their departments who are the ones you need to staff your
project. Team members are also stakeholders. While they're assigned to your
project, their jobs depend on their assignments and may depend on how well they
perform. Finally, there are departments or people who affect the project, and there
are departments or people who are affected by it. Both of these groups are project
stakeholders. For example, the project will affect how hospital facilities are
scheduled, so the facilities department is a stakeholder in the scheduling project. As
a project manager, you need to know a lot about stakeholders in order to keep them
happy. The first step is knowing who they are.

Analyze project stakeholders

Selecting transcript lines in this section will navigate to timestamp in the video

- [Instructor] It can be challenging to figure out who the stakeholders are for your
project, which ones are most important, and the best way to work with them. That's
where the stakeholder analysis document comes in handy. You can store
information there as you identify stakeholders and learn about their part in your
project. Identifying stakeholders and their part in the project doesn't happen all at
once. You'll figure all that out over the course of defining the project. First, you need
to know how your stakeholders are connected to your project and what motivates
them. Start by including the department, business unit, or company the stakeholder
belongs to and their position in the organization. Next, determine who the
stakeholder listens to. That can help if you need to figure out how to deal with that
stakeholder. You can ask that person how to handle the stakeholder, or ask them to
help directly. Identify the project objectives that the stakeholder cares about and how
they prioritize those objectives. That way, you know which stakeholders to talk to if
an issue comes up with an objective. Categorize each stakeholder by their influence
and interest in the project. That helps you prioritize stakeholders so you can manage
the time you devote to working with them. Finally, document the stakeholder's
contributions to the project, so you know what to expect from them, or who to turn to
for things you need. For practice, use the stakeholder analysis spreadsheet included
with this course. Fill in information about the stakeholders for one of your own
projects. In addition, the exercise files include a filled-out stakeholder analysis
spreadsheet for the hospital scheduling project. Keeping stakeholders happy can be
overwhelming and time-consuming if you don't know what they want and how they're
involved in your project. That's why analyzing your project stakeholders is a key task
during project initiation.

Identify the project goal

Selecting transcript lines in this section will navigate to timestamp in the video

- The first step toward project success is finding out what the customer really wants.
The project goal is the end result that the project wants the customer to deliver. A
goal is something like a problem to solve, or an opportunity to take advantage of. It
drives everything that happens in the project, so you want to make sure you've got it
right. You start by putting together a problem statement that clearly defines the
problem or opportunity. It doesn't have to be a long-winded affair. If you can fit in to
on sentence, all the better. Developing a problem statement can be challenging,
because people often jump straight to solutions. Solutions describe the end result,
not the initial motivation. In the hospital project, suppose the COO tells you that the
hospital wants to implement a new scheduling system. That's an end result. One way
to backtrack from a solution to the original problem or opportunity is to ask why?
Why do we need a new scheduling system? Don't be afraid to ask why more than
once. You can use the answers to get to the bottom of the problem, or even uncover
more specific objectives for the project. For example, you ask the COO why she's
considering a new scheduling system. She says, "Hospital resources seem to be
"either jammed up or sitting idle." When you ask why that happens, she explains that
most procedures require specific equipment, staff qualified to perform the procedure,
and often, a specific room to accommodate the equipment. The current scheduling
system and processes don't take all that into account. The equipment might be
scheduled, but the technician isn't available. Or the scheduled room can't handle the
equipment. In addition, the hospital has received grants and donations to fund
improvements to address these issues. The problem statement for this project might
be, "Hospital resources aren't being utilized efficiently "because scheduling doesn't
ensure "that the necessary equipment, staff, "and facilities are available. "Funding is
available to address scheduling issues." With a problem statement in hand, you can
find the project goal, that is, the end result the project will deliver. The goal should be
simple and easy for everyone to understand, that way, you can use it to get buy-in,
and guide the team to a successful conclusion. For the hospital project, the project
goal might be, "The project will deliver scheduling improvements "so hospital
resources can be scheduled efficiently. "The project will take advantage of funding
available "for productivity and technology enhancements." Knowing where you're
going is the best way to start a project. Try writing a problem statement and goal for
the project you're working on, using the template included in the exercise files.

Define project objectives

Selecting transcript lines in this section will navigate to timestamp in the video

- [Narrator] Once you define the project goal, you can flesh it out by identifying more
detailed objectives. They help define the project scope, the approach you choose,
and the success criteria you have to meet. Business objectives support your
organization's goals. For example, increase market share to 25% or provide world-
class health care. Financial objectives are all about money. Think increasing revenue
by 15% or cutting costs by 10%. Quality objectives specify how good results need to
be. The hospital might want to decrease staff infections by 80% or decrease
readmittance by 75%. Projects can also have technical objectives. These are similar
to technical specifications for equipment. The hospital might want mobile equipment
that can be used in the hospital, an ambulance, or at a remote emergency site.
There's also a catch-all category called performance. Your project might need to
finish by a specific date. The hospital has to use the government grants before they
expire. Now let's talk about best practices for documenting objectives. One way to
define clear objectives is to use SMART criteria. Specific objectives are clear so
there's no misunderstanding about what you're supposed to achieve. For example,
increase revenue by 15%. With vague objectives, you probably won't get what the
project customer had in mind. Measurable objectives make it easy to see whether or
not they have been achieved. For example, the hospital can measure the decrease
in readmittance or revenue increase. With qualitative measures, you might use
survey responses such as a minimum patient satisfaction rating of 4.5 stars.
Achievable or realistic objectives spell out what you can do with the resources
available. Challenging objectives can motivate people but your team might give up if
they think the objectives are impossible. Time-related objectives identify when they
need to be achieved. Be sure to set a clear target date. For example, the
government grants must be used by December 31st, 2020. Now that the project goal
and objectives are identified, you work with the appropriate stakeholders to perform
a benefit analysis. That way, you can validate that the project aligns with the
organization's mission and strategy and delivers the expected value to the business.
Project objectives help flesh out the project goal and define project scope, approach
and success criteria. The Exercise Files include an objectives template and a
description of what the hospital wants to achieve. Use them to list and categorize the
hospital's objectives.

Choose a strategy

Selecting transcript lines in this section will navigate to timestamp in the video

- You're likely to find that there's more than one way to achieve your project goal and
objectives. Let's look at how you can evaluate alternative strategies and select the
right solution. First, bring together a small group of people familiar with the project to
brainstorm strategies. As a group, read the problem statement, goal, and objectives,
and then begin generating possible strategies. Brainstorming should be a free flow of
ideas. The point is to get as many ideas written down as possible before you begin
evaluating them. Once you've identified possible strategies, you evaluate them. A
decision matrix helps you compare the options. First, the group should evaluate how
well each strategy satisfies the project objectives. One way to quickly shorten the list
of contenders is to check whether a strategy satisfies all the must-have objectives. If
a strategy doesn't satisfy one of your must-haves, you don't have to fill out the rest of
the values for that strategy, like option four in this example. Next, rate the
performance for each objective. When some objectives are more important than
others, increase their weighting. The strategy with the highest overall rating is most
likely your winner. For the top strategy from the decision matrix, the group then asks,
"Is this strategy feasible?" For example, strategies that use new technology or
unproven methods might not work. If feasibility could be an issue, a feasibility study
can explore whether the strategy will work without committing too much time or
money. Next, consider whether the strategy's risks are acceptable. You won't know
all the risks at this point. You can perform an initial risk analysis to see whether any
risks are so significant and likely that a different strategy makes more sense. Finally,
consider whether the strategy fits the culture of the organization. Trying to force a
strategy that doesn't fit with the culture is a losing battle. Believe me, you won't get
the commitment you need from management or team members. Evaluating
alternative strategies helps you pick the right solution for your project. Practice by
using the decision matrix in the Exercise Files to evaluate strategies for the hospital
scheduling project.

Gather requirements

Selecting transcript lines in this section will navigate to timestamp in the video

- [Narrator] Now that you have the project goal, objectives and strategy identified, it's
time to describe specifically what the project must deliver, known as requirements.
Getting requirements right is crucial. If you don't identify a project's true
requirements, the stakeholders won't be satisfied with the project results. And if you
include requirements that aren't necessary, the project will probably take longer and
cost more than it should. For the hospital scheduling project, one objective is
rescheduling procedures decreased by 75%. One requirement for the scheduling
system might be simultaneously schedule staff, equipment, and facilities required for
a procedure. Another requirement could be search for a next time slot that all
selected items are available. These requirements are both necessary and specific.
You can expand them to provide even more detail. Gathering requirements can be
challenging. Stakeholders might describe their requirements incorrectly or provide
inconsistent or contradictory requirements. They might leave out requirements they
need or include nice to haves. Sometimes people who aren't stakeholders try to
squeeze their requirements into your project. In addition, stakeholders often balk at
committing the time it takes to define requirements. There are several techniques for
gathering requirements. Interviews are one approach. The key is to interview the
right people and come with a list of questions. If your project involves several groups,
try brainstorming sessions or focus groups with representatives from each group to
discuss the requirements for the project. These meetings may help you obtain buy-in
from the departments that attend. Another approach is to observe how people work.
In other words, watch what people do in their day-to-day activities. To validate the
requirements, write them up, and review them with the workers. Questionnaires and
surveys are another way to get requirements from stakeholders. Build these
documents carefully so the questions don't influence the answers people provide. If
documentation or results already exist, you can identify requirements by analyzing
documents or reverse-engineering products. Next, you need to analyze the initial
requirements to make sure they make sense.

Identify project deliverables and success criteria

Selecting transcript lines in this section will navigate to timestamp in the video

- [Instructor] Put simply, project deliverables are the results that a project delivers. To
determine whether deliverables are what they're supposed to be, you need some
way to measure them. Those measurements are called success criteria.
Deliverables can be tangible. Like a building, a new product, or a new service. They
can also be more abstract. Like improved results. Say, a decrease in reported errors.
Deliverables help you define the project scope, which basically means what is and
isn't included in the project. Deliverables then help you measure progress while your
project is underway. To document project deliverables, start by listing the end
deliverables. That is, the results your project delivers at the end of the project. For
example, one end deliverable for the scheduling project would be new scheduling
system and processes launched. Next, document intermediate deliverables, which
are delivered during the course of the project. An intermediate deliverable for the
scheduling project would be to sign a contract with the scheduling system vendor.
Keep in mind the project customer doesn't necessarily receive intermediate
deliverables. For example, you might have an intermediate deliverable for
completion of initial system testing that the customer doesn't have to approve. Try to
define deliverables that can be accomplished in the timeframe between status
reports. That way you can evaluate progress based on the deliverables completed
since the last report. Now that you've identified your deliverables, how can you tell if
the ones you receive are what the stakeholders want? You guessed it. You need
quantifiable criteria you can measure them with. Success criteria are definitions of
what success looks like. Some are easy to figure out, like signed vendor contracts,
or the certificate of occupancy for a building. Other criteria are not so easy, because
they're subjective. To be effective, write success criteria that are clear and
quantifiable. For the scheduling project, you might define success for increased
customer satisfaction as a four out of five rating on customer surveys.
Identify project assumptions and risks

Selecting transcript lines in this section will navigate to timestamp in the video

- [Instructor] Another aspect of defining a project is to identify project assumptions

and risks. Let's start with assumptions. During project initiation, there's a good
chance you won't have all the information you really need. Don't worry. You can
make assumptions about that info so you can move ahead with the project. Later
when the project picture becomes clearer, you can revisit your assumptions and
modify them if necessary. For example, with a scheduling project, you won't know
how much system customization is needed until you choose the vendor, and that
could affect how many in-house resources you'll need, which could affect how long
the project takes. You get the idea. You might assume that the system won't require
much customization. From that, you estimate that you'll need three in-house IT
resources, and they'll need a month to finish their part of the project. Assumptions
can be tricky when people don't realize they're assuming something. In that case,
they assume something is true without confirming it. Different people can make
different assumptions. If those assumptions aren't brought into the open, someone
will end up disappointed. For example, say that you assume that the system vendor
is going to load data into the database and the system vendor assumes your internal
IT group will do that task. If that assumption isn't identified, the system might miss an
important deadline. The key is to get assumptions out in the open. That way you can
make sure everyone is on the same page. Think about uncovering unspoken
assumptions as you define and plan the project. Ask people what they expect and
what they envision when they think about the project. Don't be shy about asking
more than once. Now let's look at risks. A risk is a situation or event that might occur
that could affect your project positively or negatively. What makes a risk a risk is that
it's uncertain. Early on in a project, spend some time identifying risks that could affect
the project, mainly so the management team can make an educated decision about
whether or not to invest in the project.

Prepare a project scope statement

Selecting transcript lines in this section will navigate to timestamp in the video

- [Narrator] After all the work you put into defining your project, it's time to get that
project definition in writing. Project scope is the culmination of your definition work. It
describes the boundaries of the project, what is included in the scope of the project,
and just as important, what isn't included. It's important to get the project scope in
writing. Otherwise, you're bound to run into scope creep. That isn't some weird guy
who casts furtive glances at your project scope. Scope creep is when stakeholders
ask questions like: Can you do this one thing? We forgot to ask for this. Can you add
it to the project? And you say yes without running the change through your change
management process. The other reason you want project scope in writing is to
remind stakeholders what they agreed to at the beginning of the project. If someone
says, "I thought you were going to do X, Y, and Z," you can go back to the scope
statement and show them that those items are out of scope. If they really want those
things in the project, you can use change management to add them. A scope
statement is a document that spells out the project scope. Everything you've done
during project initiation feeds into this document, the goal and objectives,
deliverables and success criteria, assumptions, risks, and constraints. Here's what is
within scope for the hospital scheduling project. Your scope statement also includes
an out of scope section that shows what the project doesn't include. For example,
the scheduling project doesn't include an update to the system used to assign staff to
work shifts. Scheduling resident rooms in the hospital and rehabilitation wing is also
out of scope. Keeping scope under control is one key to a successful project. Use
the scope statement template in the exercise files folder to create a scope statement
for the hospital scheduling project.

Create a project charter

Selecting transcript lines in this section will navigate to timestamp in the video

- [Narrator] Is the project definition done? Check. Is the scope statement ready?
Check. Now you're ready to get approval to move into planning your project. You
also put together a project charter that officially authorizes the project and publicizes
it to the world. The whole point of defining a project is to give the project customer or
management team the info they need to approve the project. The review process
varies from organization to organization. Typically the customer compares the
project information to acceptance criteria that align with the organization's goals.
There are three possible outcomes from this review. The project is approved to
proceed to planning, it's denied, or it's sent back for rework. When the project is
approved the final step in initiation is to create and distribute a project charter. This
document authorizes and publicizes the project. Here's what typically goes into a
project charter, the name of the project, the purpose of the project, a short summary
of it's goal and objectives will do, a high-level project description, which may include
things like high-level success criteria, requirements, scope, risks, assumptions, and
constraints, a milestone schedule, cost estimate, and list of stakeholders.
Remember, you'll flesh out all of these components once you start planning your
project. You also include information about the project manager, the projects
manager's name, the project manager's responsibilities, including a brief description
of the work the project manager does. The extent of the project manager's authority,
and the specific work the project manager has authority to perform, such as
requesting resources or signing contracts. Finally, the charter includes a formal
declaration of the sponsor's support for the project. Think of this declaration as a
power of attorney given to the project manger by the sponsor or customer. You might
wonder why a project charter describes the project manager's authority.

Challenge: Project charter

Selecting transcript lines in this section will navigate to timestamp in the video

(upbeat electronic music) - [Narrator] For this challenge, review the hospital
organization chart and the scope statement from chapter two exercise files.
Remember that the project charter should include information about the project
manager's authority, and the support that the project sponsor provides. The exercise
files include a challenge that poses several questions about the project charter for
the Brisland Hospital scheduling project. Take 20 to 30 minutes to answer those
questions. After you've completed the challenge, take a look at the solution to see
what I came up with.
Chapter 3 – develop a project

Project planning overview

Selecting transcript lines in this section will navigate to timestamp in the video

- A big part of project management is planning out your project in detail. You begin
by identifying the work that must be done. To make the project easy to manage, you
break the work down into bite size pieces. Once you have your list of tasks, you can
start estimating who's going to do the work? How long each task will take, and how
much they'll cost. Figuring out when things happen requires some special
techniques. To build a schedule, you have to take into account factors like how tasks
depend on one another. How much resources are available to work on tasks.
What is a work breakdown structure?

What is a work breakdown structure?

Selecting transcript lines in this section will navigate to timestamp in the video

- [Instructor] After you get the go ahead to plan your project, the first thing you do is
identify the work that has to be done. Even small projects can have lots of tasks.
That's why project managers use a diagram called a Work Breakdown Structure, or
WBS to organize work. You use it to divvy up project work into manageable pieces
so you can plan, track, and manage your project. Creating a WBS helps manage the
project in several ways. First, it's easier to estimate time and cost for smaller chunks
of work. Say the sponsor wants to know how long the whole project will take. You
can't come up with the good answer off the top of your head. It's a lot easier to think
about how long smaller parts of the project will take. After you estimate the small
chunks, you can add them up to get an estimate for the entire project. It's also easier
to assign work to team members. By breaking work into smaller pieces, you'll have
built-in checkpoints to measure progress on the project. A WBS contains two kinds
of tasks, summary tasks and work packages. Summary tasks are the higher-level
tasks that summarize work in some way. Summary tasks describe parts of the
project. They could represent phases or deliverables or even work done by different
groups in your organization. In our scheduling project, the WBS is organized by
deliverable. How many levels of summary tasks depends on the size of the project. A
few levels are enough for a small project. If a project is large or complex, you might
have several levels of summary tasks. Work packages are the lowest level tasks in
the Work Breakdown Structure. They spell out lowest level project deliverables and
the detailed work needed to deliver them. In the scheduling project, the summary
task to configure the system server might have work packages to activate modules,
set options, and add software links. Breaking your project down into manageable
pieces helps you plan and manage your project effectively.

Build a work breakdown structure

Selecting transcript lines in this section will navigate to timestamp in the video
- The best way to build a work breakdown structure, or BWS, is to start at the top
level of summary tasks and work your way down. Work with your team to identify the
WBS. You're less likely to forget work that needs to be done, and the team is more
likely to buy into the project. As a team, you identify the top few levels of summary
tasks. Then you can have smaller groups break down the summary tasks into
smaller chunks. At the end, everyone gets back together to review the results and
correct any issues. If the full team isn't onboard yet, work with your initial team to
brainstorm the WBS. Then you can revise and add more detail to the WBS later as
others join the project. Start by using the scope statement and deliverables to
identify the top level summary tasks. For example, the scope for the scheduling
project includes redesign scheduling processes, a new scheduling system,
documentation, and training. So you add summary tasks to cover all of those. Next,
break down each of the summary tasks into smaller pieces. Intermediate
deliverables come in handy for identifying lower level summary tasks and work
packages. For example, the scheduling project includes a deliverable for a signed
contract with the system vendor. Let's add tasks to obtain proposals, select the
vendor, negotiate terms, and sign the contract. You might wonder, how much break
down is enough? Most project managers shoot for work packages that take between
eight and 80 hours to complete. Work packages are the lowest level tasks in the
WBS and represent the work that needs to be done. Consider breaking down work to
match the frequency of your status reports. That way, you have measurable
progress and completed tasks for every status report. Here's some tests to
determine whether you've broken work down to the right level. Time and cost are
easy to estimate. Status is easy to measure. Task durations are shorter than your
reporting periods. The detail is at the level that you can and want to manage.
Different parts of a project might require different levels of decomposition. One part
of the project might include more work, so you break it down to three or four levels. If
another part of the project is simpler, you might need only two levels. Don't worry
about the initial organization of your WBS. You can rearrange it later as you learn
more about the project. Building a WBS from the top down works well because you
can use the scope statement and deliverables to get started. For practice, try
building more of the scheduling project's WBS based on the project scope and
deliverables.
How to create work packages

Selecting transcript lines in this section will navigate to timestamp in the video

- [Instructor] A short task name in a WBS isn't enough to tell team members what
they're supposed to do. To give your team the info they need, create work package
documents that describe the work that needs to be done in detail. The level of detail
needed in the work package document depends on things how familiar the work is
and the experience of the person assigned to the task. For example, a work package
document might include a detailed description of the work for a less experienced
person. For someone more experienced, a checklist of things to do might be enough.
If the specifics of the work are described somewhere else, you can refer to the other
document that contains the information. A work package document does more than
describe the work, it also identifies how you know the task is complete and whether it
was completed correctly. For some tasks, you can include the corresponding
deliverable and success criteria in a work package document. Otherwise, write up a
description of what you will have when the task is complete and what it should look
like. As project manager, you won't know enough about every aspect of the work to
produce these detailed task descriptions. Turn to the people who helped you build
the WBS, team leaders for the groups that will work on the project or other
knowledgeable people to help fill in the details. Work packages help your team
members deliver what they're supposed to. For practice, try defining a work package
for the schedule training task that appears in the scheduling system WBS.

Estimate time and cost

Selecting transcript lines in this section will navigate to timestamp in the video

- The two questions you get hit with most often about a project are how much time
will it take and how much will it cost? Estimating accurately matters because your
estimates could determine whether it makes sense to run the project. You start by
estimating time because it affects both project schedule and cost. You also estimate
costs that aren't time-based like materials and ancillary costs like travel. During
initiating and planning, you might work with a core planning team to develop initial
estimates. During project execution, you can get more accurate estimates from the
people assigned to tasks. They understand what has to be done and know how long
it will take based on their experience. Plus, they're usually motivated to live up to the
estimates they provide. Estimates don't have to be perfect right off the bat. For
project selection, an estimate that's plus or minus 75% might be good enough. As
you learn more about the project during planning, your estimates grow more
accurate, ideally to plus or minus 10%. There are several techniques you can use for
estimating. If you have similar projects that are already complete use them as a
foundation for your project estimate. With parametric models, you calculate work and
cost based on some measure like the number of square feet for construction. This
technique works when you have data from many similar projects. If a project
represents uncharted territory for your organization, consider bringing in experts who
are familiar with the work, like consultants or vendors. The Delphi Technique counts
on several heads being better than one.

How to choose the best estimate

Selecting transcript lines in this section will navigate to timestamp in the video

- [Instructor] Project estimates are a lot like your morning commute. You need to
choose an estimate that gives you a good chance of getting where you need to be
when you need to be there. On some days, your commute is a breeze. Maybe 30
minutes. Most days, let's say it's 45 minutes. But an accident can turn it into an hour.
For your commute you choose a drive time that gives you some wiggle room so you
get to work on time. The same approach works equally well for your project
estimates. You probably decide when to leave for work informally. We're going to
look at a similar, yet rigorous approach to choosing estimate values for your project.
If you were to graph the probability of your commute times, it would look like a Bell
Curve with your average drive time at the peak. A Bell Curve is also known as a
normal distribution. And it has properties that help you choose a safe estimate to
give your customer. First, on a Bell Curve, 50% of the possible values are less than
the average, and 50% are greater. That means the average value gives you a 50-50
chance of your results being equal to or less than your estimate. Think about it. If
you give your customer your average estimate, you're as likely to fail as you are to
succeed. I wouldn't stake my career on those odds. On the other hand, the worst
case estimate gives you the highest chance of success. However, that number is so
high your customer might cancel the project. You probably know that customers are
prone to ask, so high your customer might cancel the project. You probably know
that customers are prone to ask, "What's the best case scenario?" "What if
everything goes right?" Don't fall for this trap. Suppose you give the customer your
best-case estimate. Say, six months. And you describe everything that has to go
right to finish the project in six months. This is what they'll hear. Blah blah blah blah
six months. And you've set up your project to fail. We've eliminated the best, worst,
and most likely values. You're probably wondering what number you should use for
your estimate. The answer is about halfway between the average and worst-case
values. Let's go back to the Bell Curve and pick the value halfway between the
average and worst-case values. Without getting into the mathematical details, that
gives you an 86% probability of your results being less than or equal to that number.
That's a good chance of success, and the value is easy to calculate. Plus, you can
tweak your value higher to reduce the chance of missing the deadline. Just like you
would leave extra early if you're going to a job interview. And if you're trying to win a
project, you might choose a smaller value. Even though the risk of failure is higher.
The bottom line is, choose the estimate that provides an acceptable probability of
success. For practice, use the information in the exercise files to determine the time
estimate you would give the hospital's COO.

Create a resource management plan

Selecting transcript lines in this section will navigate to timestamp in the video

- [Instructor] Part of planning is to identify and document project roles and

responsibilities, who reports to whom, and the skills needed to do the project work.
That's where the resource management plan comes into play. This plan also
includes a staffing plan, which describes everything about how you'll staff the project.
You start with a responsibility matrix. This document spells out who can make or
approve decisions, the groups performing work, and which groups need to be
consulted or informed about what's going on. A responsibility matrix includes four
categories of responsibility. R means a group is responsible for performing work. I
represents Informed, which means a group gets information. C means that you
consult a group about decisions. However, they aren't accountable for the decision
that's made. A is for Accountable, which means the group makes or approves
decisions and delegates work. During planning, review the responsibility matrix with
stakeholders and work out any disagreements. If part of your project doesn't have an
owner, meaning someone accountable for that area, talk to the stakeholders and
your project sponsor to identify who is accountable for that area. You might have
outsourcing, subcontracting, and partnering arrangements. Don't forget to add these
groups and how they contribute to the responsibility matrix. The second part of a
resource management plan is a project organization chart. It's like a regular org
chart, except it shows the hierarchy and reporting structure for people involved with
the project. That way, you know who to talk to if you need to escalate a request or a
decision. Third, identify the skills the project requires and how many people you
need with those skills. A skills matrix helps you figure this out. To build one, take a
look at your work packages and identify the skills each package requires. Then
create a matrix with your project tasks in rows and the skills you need in the
columns. Add checkboxes in the matrix when tasks require a specific skill. Then you
estimate the number of resources you need with each skill. You can even multiply
that number by the average pay rate to estimate the labor cost. Finally, it's time to
develop the detailed staffing plan. Identify where you plan to get resources. Are they
in-house, outsourced, or contracted? When do you need resources? Identify any
training they need and document resource-related processes, getting team members
on board, handing out assignments, getting status updates, and releasing them from
the project when their work is done. A resource management plan documents who
does what, who reports to whom, the resources you need, and how you'll manage
them. As an exercise, use what you know about the project so far to complete the
responsibility matrix in the exercise files. Then, using your responsibility matrix, draw
up a project organization chart.

Build a project schedule

Selecting transcript lines in this section will navigate to timestamp in the video

- [Instructor] A WBS identifies the work needed to complete a project. But it doesn't
tell you how long the work will take or when it can be performed. To do that, you
need to turn your list of tasks into a schedule. First, put the tasks into the right
sequence. You add dependencies or links to tasks to identify which tasks have to
finish before other tasks can start, which tasks finish at the same time, and so on.
For example, the task Build Specs has to finish before Review Specs can start.
Likewise, Review Specs has to finish before Approve Specs can start. We'll look at
dependencies in detail later in the course. For now, the most common dependency
type is finish-to-start. Next, you add the time you estimate each task will take. Time
estimates and task sequence help determine how long the entire project will take.
Third, you assign the people on your project team to tasks. With the estimated time
and people assigned to do the work, you can calculate the task duration. Finally,
take into account other constraints like deadlines and when resources are available.
If your initial schedule doesn't work, you can tweak it in various ways, whether you're
trying to shorten the schedule, cut costs or even out people's workloads. The
schedule is one of the most important aspects of your project. It tells you how long
the project will last and when you need the people who will do the work.

Develop a project budget

Selecting transcript lines in this section will navigate to timestamp in the video

- [Instructor] With most projects, money is important, whether you're trying to make it,
save it, or stay within a budgeted amount. Project cost is one of the three key
constraints you need to manage and the project budget is your starting point. The
project budget should be a realistic estimate of the cost to complete the project work.
If your estimate is unrealistically high, the project could be canceled. If the estimate
is too low, the project will cost more, which usually means it won't deliver the
financial benefit it's supposed to. You estimate all the costs associated with
completing the project work, including labor, materials, and other costs, like travel.
You can start with rough estimates for the first few levels of your work breakdown
structure. Then create more accurate estimates as you learn more about the project.
Labor cost is usually a big part of a project's cost. That is, what you pay people who
work on the project. If you hire vendors or contractors, their charges go directly into
project labor costs. For employees, you typically use the burdened cost. That
includes salary and employee benefits. You can get burdened rates for roles from
your accounting or HR department. Projects might use other types of time-based
resources. Think equipment or office space that you rent. These costs go into your
calculations, too. Then there's material cost. The hospital scheduling project could
include a new server or training guides and documentation notebooks. Finally, be
sure to include other types of costs that don't fit in the previous three categories. For
example, travel, training expenses, and fees. Have you ever gotten into a cash
crunch when you didn't have enough money on hand to pay expenses? Projects can
run into cash flow problems, too, which is why you figure out when project expenses
will occur. When you assign resources and other costs to the tasks in your projects
schedule, you'll get a rough idea what your cash flow looks like. Let's say
management has money allocated for the project, like the grants and donations
earmarked for the hospital scheduling project. If your cost estimate is higher than the
allocated amount, you have to look at ways to reduce the project cost. You might
eliminate nonessential expenses or find less expensive resources, maybe cut scope.
In the hospital scheduling project, management allocated $850,000. The estimate,
including contingency, is $950,000. You might consider working with less
contingency funds, ask for more money, or dive in to find ways to cut the total cost.
The project budget is the cost target you aim for as you manage a project. For
practice, think about what you can do about the $100,000 that exceeds the amount
that management has allocated for the scheduling project.

Identify risks

Selecting transcript lines in this section will navigate to timestamp in the video

- [Instructor] You've already put a lot of planning into your project. The next step is to
plan for what could go wrong because you know something will. Instead of asking for
an adrenaline rush why not identify what could go wrong, so you can plan ahead for
dealing with issues. Let's start with risks you're aware of. They're called known
unknowns. Things like weather delays, or resources being unavailable. Let's look at
some examples of things that can introduce risk to projects. Technology, it might
cost more than you expect, not work the way it's supposed to or not show up when
you need it. A widely dispersed project team can increase risk. You could have
delays due to time zone differences, miscommunication from different languages or
cultures or lack of teamwork because remote team members haven't developed
effective working relationships. Lack of detail like specifics on deliverables, due
dates or who will work on your project can lead to all sorts of problems. Limited
options like people with rare skills increase risk because you don't have easy
alternatives to apply if a problem arises. Work with everyone on your team to identify
risks. You can ask experts for different parts of the project about the risks they
foresee. Ask key people on the project what they think and ask other project
managers about risks from similar projects. Fill out a Risk Information Form for each
risk you identify. Include as much detail as you can, which objectives are in danger?
What events can cause the risk to occur? What the consequences are? Who owns
the risk? And so on. Up until now, we've talked about risks we can anticipate but
what do you do about the risks you can't predict? These are called unknown
unknowns. They come from situations that are so unlikely that they never occur to
you. You're unlikely to have to deal with such a significant unknown risk but you will
encounter unknown risks at some point and you need to plan for them. How? By
setting aside contingency funds and time for dealing with them. The question is, how
much should you set aside? Many companies use a percentage of the project
budget, like 15%. But the percentage is typically based on past experience. To
minimize the effect of risks, you first have to identify the risks that your project faces.
Try to identify several risks that the hospital scheduling project might face. For an
extra challenge, use the Risk Information Form in the exercise files to document the
risks.

Create a risk management plan

Selecting transcript lines in this section will navigate to timestamp in the video

- [Instructor] A risk management plan documents which risks you're going to worry
about and how you plan to handle them. First, identify which risks warrant managing.
Start by evaluating how likely they are and how serious their impact would be. Rate
risks by probability and impact using a scale of one to five, where one is unlikely or
not serious, and five is highly likely or extremely serious. Then multiply the
probability and impact to calculate a risk score. It makes sense to manage risks that
are at least fairly likely and serious. That means you need to plan for any risk with a
score of nine or more. For example, suppose older hospital computers are very likely
to be incompatible with the new scheduling system, new computers increase the
budget so the impact is very serious. The risk score is 25, so you'll definitely need to
manage it. Risk one's probability and impact are both medium. It's score is nine and
you need to plan for it. Risk four is fairly serious but it isn't likely. It's score is three,
so you won't plan for it. Next, you plan how you'll handle each risk. The goal of a risk
response is to plan the actions you would take to reduce adverse consequences a
risk might have on your project. Here are some risk responses you can use: the
easiest option is to accept the consequences. That's fine for risks with low probability
and impact. Avoiding risk is another approach. For instance, changing the project
scope to remove the risky part of the project. Mitigating risk means taking steps to
reduce the consequences or impact of the risk. For example, by running a feasibility
study, you'll have a better idea whether a scheduling system will meet the schedule,
budget and other objectives. Transferring risk means handing off the risk to someone
else, like when you purchase insurance, this reduces risk but doesn't eliminate it.
Insurance might relieve costs, it won't eliminate other factors like time delays. Make
sure your responses aren't overkill. If a schedule delay triggers a $500 late fee, it
doesn't make sense to spend $5,000 to prevent the delay. Remember, contingency,
time and funds can be used to handle risks that have no other response, or to handle
risks you didn't identify upfront. The final step in a risk management plan is defining
how to monitor risks and measure responses. Create a risk log to summarize the
risks you'll manage. For each risk include a description of the risk, the events or
circumstances that trigger the risk, the probability and impact, the response you've
chosen, who will monitor the risk, the result you expect from the response if you
have to use it, and finally, the risk status. Keep your risk plan up-to-date as the
project progresses. Some risks become less likely as time passes, other risks may
be introduced because of project changes. Risks occur so you track what caused
them, their impact and whether your responses are working. A risk management
plan helps protect your project from things that can go wrong. For practice, fill out
more of the risk log in the exercise files.

Set up a communication plan

Selecting transcript lines in this section will navigate to timestamp in the video

- [Narrator] If you've ever heard Abbott and Costello's "Who's On First" skit, you
know how hard it can be to get your point across. The success of a project depends
on good communication. That's why you set up a communication plan, the right
people, getting the right information at the right time and in the right way. You start
with your audiences. Who needs to know about the project? The responsibility matrix
is a good place to look to find your audiences. Second, what do your audiences need
or want to know? Management stakeholders care about a project achieving its
objectives. Early on, you give them the project plan so they can see how you're
going to deliver. Later on, they want to know about progress, how much you've
spent, and the overall project result. The project sponsor is tightly connected with the
project. You'll probably communicate with the sponsor more often, maybe in face to
face meetings. Functional managers initially need to know the skillsets you need,
when you need them, and other things like cost constraints. Once people are on
assignment, these managers want to know when their people will be done. Team
members need to know what they're supposed to do. They're more likely to buy into
the project if you tell them how their work fits into the big picture. As time passes,
they also need to know what's coming up next. The last part of a communication plan
is the how: how often, the methods you use, and the format. Face to face
communication is good for brainstorming, getting to know people, and discussing
sensitive topics. If your team is dispersed geographically, email, conference calls,
and video conferencing are indispensable. You know that stakeholder management
is all about getting and keeping stakeholders' support for your project. The
communication plan helps by spelling out how you're going to communicate with
stakeholders to keep them onboard and happy. A communication plan helps ensure
that people get the information they need in the most effective way. To solidify your
understanding, set up a communication plan for the hospital scheduling project.
Develop a quality plan

Selecting transcript lines in this section will navigate to timestamp in the video

- [Narrator] Project success actually means meeting objectives, not exceeding them.
Quality management includes processes to make sure that a project satisfies it's
objectives and requirements. A quality management plan is your roadmap to meeting
objectives. Project quality translates into meeting the customers requirements and
delivering on time and within budget. With deliverables in products, quality also
means conforming to specifications. A quality management plan has three
components. First, there's the quality standards for deliverables. For a product the
quality standard might include the acceptable tolerance for it's dimensions, or the
acceptable number of defective widgets in a batch. For the hospital scheduling
project, one quality standard might be that the scheduling system meets all the
required scheduling functions. Keep in mind that the goal is to meet the quality
standards. Obviously, you don't want quality that's below standard. The customer
won't be happy. They might ask for additional work to get it right, or simply refuse to
pay. This might surprise you, you don't want quality that's higher than required. Why,
because other aspects of the project can suffer like a later finish date, or higher cost.
The second part of the quality management plan is a quality assurance plan. This
spells out the processes you use during the project to ensure that the final results
meet the quality standards. For the scheduling system, reviewing requirements and
designs falls into this category. You might also test software functions as they're
developed. Finally, you plan for quality control which means how you measure and
monitor quality in the final deliverables. The bottom line is that you examine or
measure results to see if they meet the standard set. For the scheduling project the
final acceptance test would measure whether the processes and system achieve
their objectives. For the hospital's new cancer wing you would do a walkthrough to
confirm that the construction has been completed correctly. Continuous improvement
is a big part of quality management. If you find quality issues, you analyze the
problems to see how to prevent them, or at least reduce their frequency. Cause and
effect diagrams are also called fishbone diagrams, because they look like a fish
skeleton. They help identify factors that could lead to problems. Those factors can
help you figure out ways to prevent the problems. Another tool is a Pareto diagram.
This shows how many defects are generated by each cause. That way you can
address the causes that produce the most defects first. By developing a quality
management plan you can ensure that your project meets it's quality objectives. For
practice, identify potential quality assurance processes, and quality control measures
for each of the project objectives.

How to set up a change management plan

Selecting transcript lines in this section will navigate to timestamp in the video

- [Narrator] The government tax code started out so simple. But a deduction here, a
new rule there, and now we have the complicated tax returns of today. You know
changes are going to happen, so the only solution is to manage them. A change
management plan helps you add important changes into your project while keeping
out the ones that don't make sense. First you identify what you want to control like
the project scope, requirements, and the schedule. Or perhaps the entire project
plan. The versions you control are called baseline documents. The list of project
requirements approved by the stakeholders is your baseline. If new requirements are
suggested, you use your change management process to decide whether or not to
add them to the requirements list. You also need a group that reviews change
requests and decides whether to approve them. It's called the change review board
and it's usually made up of key stakeholders. Then you define a change
management process. That's what will happen when someone requests a change.
The process your organization chooses depends on things like the company culture
and project size. Here are the typical components of change management
processes. The first process is documenting and submitting a change request. Use a
standardized change request form that requesters fill out. It's easier to evaluate
changes because each request has the information the review board needs to make
decisions. Include details about the requested change, the reason it's needed, the
business justification, and the results it should produce. Next, someone has to
evaluate the request and estimate its impact. As project manager, you can assign
this task to someone on your team. The evaluator determines whether the change is
needed. If it is, the person evaluates whether the suggested approach is correct or if
an alternative would be better. The evaluator estimates the effort and cost the
change would require, the impact on the project, and whether it introduces risks.
Third, the change review board reviews evaluated change requests. The board might
accept or reject the change request. They also might ask for more detail or revisions.
Be sure to communicate the decision to the person who requested the change. For
approved requests, you update the baseline documents to reflect the change. For
example, your project schedule might need new tasks or deadlines extended.
Finally, track where change requests are in your process. A change request log
shows the status of submitted change requests, who's in charge of the request, the
impact estimate, current status, and at the end, actual impact. Consider setting
thresholds so team leads can decide what to do with smaller requests. That way,
your change management process isn't overwhelmed with small items. Also, create
a process for emergency changes that need a rapid decision between meetings of
the change review board. A change management plan helps you include changes
that make sense in your project while protecting your project from being
overwhelmed with unnecessary changes. To solidify your understanding of change
management, draw a flow chart of the change management processes the hospital
might use.

How to plan procurement

Selecting transcript lines in this section will navigate to timestamp in the video

- [Instructor] Even with homemade chicken soup you don't make everything from
scratch. Imagine how long it would take and how much it would cost if you had to
raise your own chickens, vegetable and wheat and make chicken stock and noodles.
The same goes in the project world, procuring products services and skills can be a
lot quicker than trying to do everything yourself. When you purchase items from
outside your organization, you need to plan how you're going to do that. You
guessed it! That's what a procurement plan is for. First you identify what you need to
purchase. Maybe you need people with specific skills or you need more people than
your organization has. Or the project requires products and materials. Second, you
document your procurement processes. Who handles procurement? Is it the
purchasing department, the project or team or a combination of the two? The plan
describes criteria for choosing vendors, the selection process, types of contracts you
use and how you manage those contracts. Fortunately, you usually don't have to
invent all these processes. Most organizations already have procurement processes
in place. Talk to your purchasing department or finance group to find out how it's
done. Third, you describe your make or buy decision process. Basically, how you
you decide whether to use in-house products or services, or procure them. To make
an informed make or buy decision, it's important to understand your needs. Make
sure your requirements are clear and then prioritize them. That way it's easier to pick
products that meet your requirements, plus you can resist bells and whistles you
don't need. You have to see if a product that meets your needs is available. If it is,
evaluate how it matches up with your requirements. Before you finalize your
decision, consider the pros and cons of making versus buying. If your project is on a
tight timeline, buying is probably the right choice. The last part of the procurement
plan is a list of potential vendors who offer what you need, to purchase. Describe
how you researched vendors and contractors and the criteria for developing the list.
Procurement planning helps you make smart decisions about whether to purchase
products and services, and if you do, which products and services to procure. As an
exercise, identify some of the criteria you might use to choose the scheduling system
vendor.

Processes for procuring resources

Selecting transcript lines in this section will navigate to timestamp in the video

- [Instructor] For initiating and planning, you might work with a small core team.
Before you begin executing project work, you bring on the rest of the team and
acquire needed equipment and materials. If team members come from within your
organization, procurement might be as simple as telling your in-house team it's time
to start your assignments. For resources outside your organization, the procurement
process has a few more steps: solicitation, evaluation, selection, contracting, and
ongoing management. These steps can take time so be sure to leave room in your
schedule for performing them. Solicitation often begins with a request for proposal,
abbreviated as RFP. It's a typical way to ask vendors for proposals or bids. An RFP
describes the services or resources you need, when you need them and your budget
for the work. Include the criteria you plan to use to select a vendor so companies can
decide whether or not to bid. Don't forget to include instructions and the deadline for
submitting a proposal, and the date you'll announce your decision. Once you have all
the vendor's proposals or bids, you hunker down and evaluate the responses using
your criteria. How you select the winner depends on the size and complexity of the
project. Evaluation and selection might be as easy as filling in a spreadsheet with
ratings and choosing the vendor with the highest score. For large jobs, you might
whittle the submissions down to a shortlist of vendors and ask each one in the
second round to prepare a more detailed presentation, or demonstrate what they
have to offer. For example, in the scheduling system project, you might ask the top
two candidates to demonstrate their systems and show how features satisfy project
requirements. Contracting is when you prepare and sign a contract for the resources
you need. Contracts usually include a statement of work, terms and conditions,
deliverables, deadlines, and of course, the price. Contracts fall into several
categories: fixed-price contracts work when your project is well defined. This type of
contract places the risk on the vendor because the vendor is paid a fixed amount no
matter how much time the work takes, or how much it costs. Time and materials
contracts pay for time worked and expenses incurred. The project accepts most of
the risk, so it's common to include and not to exceed value to limit the price. A cost-
plus contract is like time and materials with the addition of penalties or rewards
based on the vendor's performance. With a retainer, you agree to pay for a specified
amount of time and define the work as you go. Complete procurement steps early
enough so the resources you need are available when work begins. For example, if
your project requires materials with long lead times, you'll need to start procurement
early. After you award contracts, you don't sit back and relax. While project work is
underway, you manage those contracts, monitor the vendor performance and
manage any changes. For practice, think about which type of contract you would use
for the scheduling system and why.

How to obtain approval to proceed

Selecting transcript lines in this section will navigate to timestamp in the video
- Now that you have a plan for the project, you need to get the stakeholders to
approve the plan so you can start work. Getting approval is important because you
need stakeholders' commitment to make the project a success. You might think
about getting approval by mailing or emailing a packet to stakeholders and asking
them to sign on the dotted line. I don't recommend that approach, here's the
problem. People probably won't read through the plan. Sure they might sign their
names, but later if they find something they disagree with, their commitment
disappears and you end up back to planning. A face-to-face sign-off meeting is more
effective. Schedule a meeting specifically for getting approval. The agenda is straight
forward. First, present the project plan to make sure that the stakeholders agree with
it. If issues arise, deal with them right then and there. Or, if the issues are big
enough, you might have to reschedule the sign-off so you can rework the plan. Once
everyone agrees, ask them all to sign a signature page to indicate their approval. If
you can't get everyone in the same room, a video conference or conference call
works, too. Ask the people in other locations to transmit their signatures to you by
fax, email or even snail mail. Signing a project plan isn't like signing a legal
document. You're never going to go back to your stakeholders and say, "But you
signed this." What's important is that the stakeholders understand what the project is
about and buy into it.

Challenge: Change

Selecting transcript lines in this section will navigate to timestamp in the video

(upbeat music) - [Instructor] At this point in the hospital scheduling project, you have
created drafts of several planning documents. But in the project world, things
change, and this project is no exception. The government has launched a major
initiative in cancer research. Part of this initiative is using a common scheduling tool
for all cancer treatment facilities. Brisland Hospital's new cancer ward will have to
use the government's scheduling tool. Instead of the solution that your project will
implement for the rest of the hospital. In the exercise files, there's a change request
submitted by the project manager and approved by the project customer. This
change means that you'll have to revise some planning documents. For this
challenge, take 20 to 30 minutes to identify which planning documents you need to
revise. And at a high level, what you would change. After you work through your
solution, look at the files I would revise in response to this request.
CHAPTER 4 – build a project schedule
PUT TASKS IN SEQUENCE

Selecting transcript lines in this section will navigate to timestamp in the video

- [Instructor] A big part of building a schedule is getting tasks in the right order.
Mealtime goes a lot better when you cook dinner before you eat it. By putting tasks
in order, you turn your WBS into a sequence that defines when project work should
occur. In the project management world, network diagram is the name for the
diagram that shows the sequence of tasks. Each task appears in a box with the task
name, and perhaps other task info. Arrows drawn between boxes shows how the
tasks are linked. Even if you build the sequence by putting sticky notes up on a
whiteboard, you're creating a network diagram. The links between tasks aren't just
about which task starts first. A task dependency is when one task controls the timing
of another. The task in control is called a predecessor, and the one being controlled
is the successor. Each task has a start and finish, so there are four types of task
dependencies. Finish-to-start dependencies are the most common. The finish of one
task controls when the other task starts. For example, you have to analyze the
current scheduling processes before you can start designing new ones. A finish-to-
finish dependency means the finish of one task controls the finish of the other. For
example, the dev team finishing the scheduling features controls when they finish
testing the features, with a small delay to test those last bits of customization. Start-
to-start means that the start of one activity triggers the start of the other. This
dependency type can cause trouble if the predecessor takes longer than it's
supposed to, as shown here. If writing takes longer, the reviewing task looks like it
finishes before writing does. That would mean either some writing isn't reviewed, or
the reviewers have to wait until the writing is done. In this example, the correct logic
is actually finish-to-finish. With a finish-to-finish dependency, if the writing finish date
is delayed, so is the finish date for reviewing. An example of a true start-to-start
dependency is pouring concrete and troweling it. Because concrete hardens with
time, the start of pouring concrete controls when troweling starts. Start-to-finish
dependencies don't occur very often. That's a good thing, because they can be
confusing. The start of one task triggers the finish of another. So the task in control
occurs after the one it controls. Consider the shifts at a retail store. The first shift
can't finish until the clerk for the second shift shows up. You can figure out which
type of dependency to use by asking a few questions. Which task controls the other?
That tells you which task is the predecessor. Does the start or finish date of the first
task control the second task? That identifies whether the dependency begins with
start or finish. Does the predecessor control the start or finish of the successor? That
identifies whether the second half of the dependency is start or finish. Adding task
dependencies to your tasks in a network diagram gets your project tasks into
sequence. Now that you know all the dependency types, build a network diagram for
the tasks in the partial WBS in the exercise files.

HOW TO ASSIGN RESOURCES TO TASKS

Selecting transcript lines in this section will navigate to timestamp in the video

- [Instructor] Your project tasks are in sequence and you've estimated their durations.
The final piece of your scheduling puzzle is how many people work on each task and
when they're available. With that info, you can see how long tasks take and when
they should occur. You assign resources only to work packages, the lowest levels in
your WBS, because they represent work that must be done. Summary tasks roll up
work from lower levels, so you don't assign resources to these tasks. Milestones
don't have duration, so it doesn't make sense to assign resources to them either.
What happens when you assign resources to work packages depends on whether
you estimate task duration or work. Let's say you estimate duration and assign the
number of resources you expect to get. Your scheduling tool will calculate the work
those resources can perform in that duration. Let's say you're expecting two vendor
resources full time to design scheduling features. The task duration estimate is two
weeks. Two people working full time for two weeks is 160 hours. On the other hand,
if you estimate work, your scheduling tool uses the work estimate and the resource
allocation to calculate the task duration. Some tasks don't get shorter no matter how
many people you assign. Meetings are the classic example. A four-hour meeting is
four hours long whether three people attend or 10. When resources are available
also affects when work occurs. For example, your schedule might show the
equipment installation starting on November 9. If your IT folks are wrapping up
another installation and the team won't be available until November 18th, guess
what? You have to delay that task in your schedule to when the resources are
available. Don't forget to assign other types of resources you need like materials,
equipment and ancillary costs. With all resources assigned, you finally get a good
idea what the schedule looks like. To practice, work through the assignment exercise
in the exercise files.

LEARN TO USE MILESTONES

Selecting transcript lines in this section will navigate to timestamp in the video

- [Narrator] Milestones get their name from the past when people placed stones by
the side of a road to mark each mile. In projects, milestones do a similar job, but they
show progress and other key project points rather than distance. They show when
you've completed key tasks or portions of a project. And they make it easy to see
how much you've completed and when it finished. Milestones are great as the first
and last tasks in your project schedule. By starting a project with a milestone, you
can reschedule the project's start date just by moving the starting milestone to a later
date. By looking at the final milestone, you can tell whether the project is on time,
late, or ahead of schedule. Milestones also help highlight progress you've made in
between the project's start and finish. When all the work leading up to that milestone
is done, you have the satisfaction of marking off another milestone as complete. If
you're waiting for someone to deliver something, add a milestone to flag that
delivery. Finally, use a milestone to flag decisions that determine what happens next
in a project. Or use a milestone for an approval that determines when the work after
the approval can start. Milestones help indicate progress in a project. When you link
them to work tasks, you can also use them to reschedule portions of a project. For
practice, add milestones to the Network Diagram in the Exercise Files.

MAKE A REALISTIC SCHEDULE

Selecting transcript lines in this section will navigate to timestamp in the video

- [Instructor] It's important to make your project schedule realistic so tasks occur as
close as possible to the dates you planned. One way to build reality into your
schedule is to estimate task duration based on the hours people work on the project
each day. People don't work 100% of their time on project tasks. People don't even
work 100% of every workday. Things like staff meetings, paperwork, training, and
time off chew up work hours. Even walking across campus uses up work time. So do
your best to estimate the number of hours people typically work. Another dose of
reality is adjusting estimated task hours based on how fast the assigned workers are.
For example, if someone is a whiz at getting computers connected to the network,
you can change the task work hours to reflect her productivity. Third, to keep people
productive, assign resources to work on no more than three tasks at a time.
Switching between tasks means a person has to switch focus, and that introduces a
small delay each time. When resources are in demand and you have to assign them
to several tasks, adjust those assignments to reflect their decreased productivity.
When you make adjustments like these, add a note to your schedule to document
the change and the reason why. That way you'll know what to do if other changes
come up in the future. The closer you model your resource assignments to reality,
the easier it will be to keep your project on time. Complete the assignment exercise
in the exercise files to practice assigning resources to tasks.

UNDERSTAND THE CRITICAL PATH

Selecting transcript lines in this section will navigate to timestamp in the video

- The critical path is the longest sequence of tasks in your schedule. Why is the
critical path so critical? Because any delay on that path delays the finish date of the
project. Just as important, if you can figure out how to shorten the critical path, you
can shorten the project schedule. How do you tell which tasks are on the critical
path? Simple. They don't have any slack, also known as float. Just like a string with
no slack, critical tasks can't move without affecting the project finish date. In this
simple example, the System and Training tasks occur one after the other with no
slack. If any of these tasks are delayed, the project finish date moves later in time.
On the other hand, if a task has slack like the Reports task here, it can start later
without delaying the tasks that come after it. The Reports task could delay by a few
weeks before it delays the project finish. Let's look at how you tell whether or not a
task has slack. A task has two sets of start and finish dates. The early start and early
finish are the earliest possible dates the task could start or finish based on its
dependencies with other tasks. You calculate these with what's called a forward
pass. That's where you start at the project start date and use task durations and
dependencies to calculate when they finish. For example, the Reports task can start
as early as October 26 and finish on November 27th. The late start and late finish
are the latest possible dates without delaying tasks that follow. You calculate these
dates by working backwards from the end of the project. You got it, the backward
pass. The late finish for the Reports task is December 18th, so working backwards,
the late start is November 16th. The task has several weeks of slack, so it isn't on
the critical path. Critical tasks have no slack. In other words, the early and late dates
are the same. That's why the Training task is on the critical path. The good news,
you don't have to perform these calculations. When you use project scheduling
programs, they calculate the critical paths for you. The critical path is the place to
look when you want to keep your project on time or deliver it early. To test your
understanding, calculate the late dates for the task in the exercise and use them to
identify the critical path.

UNDERSTAND THE CRITICAL CHAIN METHOD

Selecting transcript lines in this section will navigate to timestamp in the video

- [Instructor] Critical chain is a slightly different take on the critical path. It can help
you deliver your project earlier than you would otherwise, and helps prevent delays
in the project finish date. The critical chain approach schedules tasks to occur as late
as possible. One benefit of doing this is that you don't spend money on the project
until you absolutely have to. If you have to adjust the schedule, you move tasks to
occur earlier. Critical chain also focuses on resource limitations to identify the
important tasks to manage. That's because resource constraints are often the
toughest ones to deal with. You start by scheduling tasks with the most limited
resources. So you use those people as effectively as possible. It's like filling a bucket
to the brim by putting the biggest rocks in a bucket first, followed by smaller rocks
and finishing up with sand. The critical chain approach uses buffers to give a project
breathing room. That way, delays aren't as likely to delay the finish date. What do
these buffers do? They're like adding shared time to the project. Each task doesn't
get its own time buffer. Instead, sequences of tasks share a buffer. That way, only
the tasks that actually need extra time use some of the buffer. You apply a couple of
different types of buffers. First, you tack buffers onto the end of each sequence of
tasks. Then, you add a project buffer at the end of the project to protect the overall
project finish date. The critical chain approach helps deliver projects on time, or
earlier than planned. For practice, go ahead and add buffers to the portion of the
project provided in the exercise files.

HOW TO SHORTEN A SCHEDULE

Selecting transcript lines in this section will navigate to timestamp in the video

- [Instructor] Stakeholders can be an impatient bunch. You estimate when the project
will finish, and more often than not, they ask if you can deliver it sooner. Or maybe
your project gets delayed and you need to make up time. Let's look at a few
techniques for shortening the project schedule. Fast-tracking means you overlap
tasks that normally occur one after the other. Let's say you want to finish design
more quickly. You can have some folks start designing software features before the
system design is complete. Fast-tracking is simple. You just add an overlap to two
tasks with finish-to-start dependencies. The best tasks to fast-track are the longest
tasks on the critical path. Remember, you shorten the whole project when you
shorten the critical path. Fast-tracking the longest tracks on the critical path shortens
the schedule and also introduces the fewest number of risks and changes. Which
brings us to the disadvantage of fast-tracking. It increases risk. For example,
changes to the system design could result in redoing work on the software design.
The second technique, crashing, means you spend additional money to shorten the
schedule, like paying for more people or expedited delivery of key materials. The
critical path is still the place to look for tasks to crash. Think about it. Why would you
spend money to shorten tasks if they aren't going to shorten your schedule? You
also want the alternative that shortens the schedule the amount you need for the
least amount of money. Start with the least expensive tasks to crash, and move onto
tasks with higher price tags. Remember, you crash tasks only until you shorten the
schedule by the amount you need. A crash table makes it easy to see which tasks to
crash. It shows the cost to crash each critical task, and the duration you eliminate by
crashing them. Choose the tasks with the lowest crash cost per week. If they have
the same crash cost per week, crash the longer ones first. That way, you crash the
fewest tasks. You can take crashing only so far. At some point, adding more people
won't shorten the duration, because people start getting in each other's way, and on
each other's nerves. New people take time to get up to speed and they can slow
down existing team members who have to help them get oriented. Keep in mind, you
review the critical path after every adjustment. An adjustment could change the
critical path. You want to make sure the next task you work on is still on it. The third
method for shortening a schedule is to cut project scope. If the tasks for deleted
scope are on the critical path, cutting scope shortens the schedule. Fast-tracking,
crashing, and cutting scope help shorten the project schedule. Each has its pros and
cons, so choose the method that makes the most sense for the project at hand. Look
at the schedule in the exercise files. What techniques would you use to shorten the
scheduling project, and which tasks might be involved?

DOCUMENT THE BASELINE

Selecting transcript lines in this section will navigate to timestamp in the video

- [Instructor] Once the stakeholders have approved the project plan, it's time to
define your project baseline. The baseline is a collection of the approved project
documents like requirements, the schedule, budget, spread sheets, and more.
Basically, everything you want to control with the change management process. With
baseline documents, you can compare actual project performance to the baseline to
see how the project's doing. Because the baseline is controlled by the change
management process, any changes to baseline documents show up as change
requests. How you define the baseline depends on what you're defining. First, save
the baseline version of plan documents. If something changes, you flag those
changes in a revision of the corresponding baseline document. Next, baseline the
values in your project schedule. Project scheduling programs typically provide a
feature for saving a baseline. The baseline includes the approved values for start
and finish dates, task duration, work, costs, and so on. As you record progress or
make changes to the schedule, the program will show any variances from the
baseline. Once you document the project baseline, you're ready to use it to evaluate
progress and project performance. For practice, what documents would you include
in the scheduling project baseline? And where might you store these documents to
make them easy to access?