IntroductionWelcome| 00:04 | Hi! I am Bonnie Biafore, and this is
Project Management Fundamentals.
| | 00:08 | This course teaches you how to
manage your projects more effectively
| | 00:12 | from beginning to end.
| | 00:14 | We'll begin by taking a closer
look at the general concepts of
| | 00:17 | project management.
| | 00:19 | I'll then take you through defining a
project, starting with identifying the
| | 00:22 | problem to solve and how
you are going to solve it.
| | 00:26 | Next, we'll discuss planning your project.
| | 00:28 | We'll take a look at identifying the
work that needs to be done, building a
| | 00:33 | schedule, and defining the ground
rules for how you run your project.
| | 00:38 | Finally, I'll provide tips for
launching your project and monitoring and
| | 00:42 | controlling its performance so that
you stay on time and within budget.
| | 00:47 | Having the proper tools in your
project tool box is critical to running
| | 00:51 | a successful project.
| | 00:52 | I'll introduce you to these tools and
how to use them effectively in Project
| | 00:57 | Management Fundamentals.
| | Collapse this transcript |
| Using the exercise files| 00:00 | If you are a member of the lynda.com
Online Training Library, or if you are
| | 00:05 | watching this tutorial on a DVD-ROM,
you have access to the exercise files that
| | 00:10 | accompany this title.
| | 00:11 | The exercise files are worksheets that
you can use as you view this course to
| | 00:16 | note important concepts or terms
that you would like to remember.
| | 00:20 | There is also a section for you to make
note of topics or terms that you would
| | 00:24 | like to research outside
the scope of this course.
| | 00:28 | Now, let's get started.
| | Collapse this transcript |
|
|
1. Exploring Project ManagementDefining a project| 00:00 | In this chapter, we are going to
define what a project is, talk about general
| | 00:05 | approaches to project management, and discuss
the skills and tools necessary to manage them.
| | 00:10 | First, let's define what a project is.
| | 00:13 | A project is a unique endeavor that has
a specific goal, a beginning and an end,
| | 00:19 | and usually a budget.
| | 00:21 | Let's break this
definition down into its components.
| | 00:24 | First, each project is unique.
| | 00:27 | Say you have the blueprints for a house design.
| | 00:30 | You might think that the work is the
same every time you build that house, but
| | 00:35 | each construction project is just that,
a project. Where you build the house or
| | 00:40 | the weather can make a big
difference in each construction project.
| | 00:44 | A big snow could delay excavation,
require careful concrete pouring, or a
| | 00:49 | modification to the roof
structure to handle snow loads.
| | 00:53 | So each new construction project is unique.
| | 00:55 | Second, a project has a
specific goal to accomplish.
| | 01:01 | Maybe the project is supposed to
solve a problem, like reducing costs in your
| | 01:04 | company or take advantage of an
opportunity, like repurposing your company's
| | 01:09 | product to increase sales.
| | 01:11 | The project has a specific goal.
| | 01:14 | Third, the project has a beginning and an end.
| | 01:18 | If a project seems to go on forever,
it could be doing just that, because you
| | 01:22 | haven't defined the goal clearly enough.
| | 01:25 | The goal of the project is crucial for
identifying when the project is done.
| | 01:29 | Fourth, most projects have budgets.
| | 01:33 | Most of the time you think about money
when you hear the word budget, but you
| | 01:37 | are likely to face other constraints
on projects, such as resources or time.
| | 01:42 | Finally, it's important to note
that a project is not operations.
| | 01:47 | Operations is work that is the same day
after day, producing the same results.
| | 01:51 | For example, I was in charge of the
technical support group at a software company.
| | 01:57 | Every day our team opened
and closed support requests.
| | 02:01 | Each support request was unique, but we
basically performed the same tasks day after day.
| | 02:07 | This was operations.
| | 02:09 | However, besides my operational work,
I was given the task of modifying our
| | 02:14 | systems and taking advantage of our
international offices so that we could begin
| | 02:19 | providing 24-hour technical support.
| | 02:21 | I was given a specific goal, a
beginning and end date, and a budget.
| | 02:27 | This was clearly a project.
| | Collapse this transcript |
| Defining project management| 00:00 | Many project managers get their start
because they are good at making things
| | 00:04 | happen, but project management is
more than showing off your organizational
| | 00:08 | skills and supervising others.
| | 00:10 | Project management can be summed up
as answering a few crucial questions.
| | 00:16 | The first question you have to
answer is, what problem are you solving?
| | 00:21 | The best route to a successful project
starts with knowing what you are trying to do.
| | 00:26 | The second question is, how are
you going to solve this problem?
| | 00:30 | Whether you are solving a problem or
pouncing on an opportunity, you might have
| | 00:35 | to choose from several possible strategies.
| | 00:38 | The next question is, what is your plan?
| | 00:42 | You need a plan for getting the project done.
| | 00:45 | You have to identify the work to be done
in detail: how long the work takes, the
| | 00:49 | resources you need, and how much they cost.
| | 00:53 | The next question is, how
will you know when you're done?
| | 00:57 | Clearly defined objectives and
requirements are the first step, but you also
| | 01:02 | need to define success criteria,
quantifiable, measurable results that show
| | 01:07 | that the project is complete, like a
certificate of occupancy for a house or a
| | 01:11 | sales increase of twenty percent.
| | 01:14 | At the end of the project, you
can answer the last question:
| | 01:18 | How well did the project go?
| | 01:20 | This important step is often skipped.
| | 01:23 | What worked well, what didn't, and why?
How could work have been done better?
| | 01:29 | Throughout this course, we'll be
looking at how to answer these crucial
| | 01:32 | questions to increase the likelihood
of success for your project and the ones
| | 01:36 | you work on in the future.
| | Collapse this transcript |
| Understanding what it takes to be a project manager| 00:00 | The perception most people have about
project managers is that they are really
| | 00:04 | organized and good at getting things done.
| | 00:06 | Project managers actually
utilize a whole slew of skills.
| | 00:10 | First, project managers learn
technical skills specific to project management,
| | 00:16 | like what goes into a project plan,
how to build and fine-tune a project's
| | 00:19 | schedule, and how to measure progress
with tools like earned-value analysis.
| | 00:23 | Then there is business expertise.
| | 00:25 | As a project manager, it is up to you
to make sure your project delivers value.
| | 00:31 | You want to make sure that the project
achieves the goals and objectives that
| | 00:34 | you identify during project planning.
| | 00:37 | You also need to understand
your organization's business,
| | 00:41 | what it does and what it considers important.
| | 00:44 | One of the most important things
in a project manager's toolbox is
| | 00:47 | interpersonal skills.
| | 00:49 | Projects typically use people from
different groups, departments, and even
| | 00:53 | different companies.
| | 00:55 | You are the leader of this team,
so it's your job to motivate your people.
| | 00:59 | Strong leadership could be the
most important characteristic.
| | 01:03 | You must inspire your people, guide
them to do the right things, and motivate
| | 01:08 | them to give their best.
| | 01:10 | Does project management sound
like something you want to do?
| | 01:13 | If so, this course will
help you improve your skills.
| | 01:17 | Once you know your own strengths and
weaknesses, you can develop a plan for
| | 01:21 | building up your skill set.
| | Collapse this transcript |
| The five processes of project management| 00:00 | Project management can be categorized
into five major processes to help guide a
| | 00:05 | project successfully from beginning to end.
| | 00:08 | Here is how the Project Management
Institute classifies these activities.
| | 00:13 | Initiating is all about getting
the commitment to start a project.
| | 00:16 | Basically, we answer the questions, what
problem are you solving and how are you
| | 00:21 | going to solve this problem?
| | 00:23 | Planning is where you figure out how
you are going to perform the project.
| | 00:27 | We answer the questions, what is your
plan and how will you know when you are done?
| | 00:32 | The next two steps involve
putting your plan into action.
| | 00:36 | The executing process
starts with launching a project.
| | 00:39 | You bring your resources on board,
introduce them to one another, get them
| | 00:43 | settled in, and explain the
rules you'll use to run the project.
| | 00:47 | Monitoring and controlling a project
is your ongoing responsibility to see
| | 00:51 | whether the project is going according
to plan and if it isn't, you work out
| | 00:55 | ways to get it back on track.
| | 00:57 | The closing process is short but important.
| | 01:00 | You get the client to officially
accept that the project is complete.
| | 01:04 | You document the project performance,
gather lessons learned, close contracts,
| | 01:09 | and help resources move on
to their next assignments.
| | Collapse this transcript |
| Traditional vs. agile project management| 00:00 | In this video, we are going to
examine two common approaches to
| | 00:03 | project management.
| | 00:05 | We will also discuss how to identify
which method makes sense for your project.
| | 00:10 | We previously talked about the five
main processes in project management.
| | 00:14 | When each process occurs one after
another, it is known as traditional project
| | 00:19 | management, or the waterfall approach.
| | 00:21 | Traditional project management works
well when a project is relatively familiar,
| | 00:26 | the goal and solution are easy to
identify, scope and deliverables are clear,
| | 00:30 | and you use familiar technology or tools.
| | 00:33 | Because the project is a known quantity,
you can define it clearly and build a
| | 00:37 | plan for completing it.
| | 00:39 | Then you execute the project and
perform the usual activities to make sure the
| | 00:43 | work is done and the goal is achieved.
| | 00:46 | With many projects today, you don't
know what the solution looks like,
| | 00:49 | so you have to figure it out as you go along.
| | 00:52 | This type of project
requires a different approach.
| | 00:55 | Agile project management goes through
iterations to get closer to and eventually
| | 01:00 | reach a successful outcome.
| | 01:01 | For example, you might know the
project goal, such as replacing a financial
| | 01:06 | system, but your customer doesn't
have his procedures and requirements
| | 01:09 | documented in any way.
| | 01:11 | In this case, you can iterate within
the project management processes to get
| | 01:16 | closer to what he wants.
| | 01:18 | In the initiating and planning
processes, you define the overall goal for the
| | 01:22 | project and build an
overall plan to achieve that goal.
| | 01:26 | With agile project management, you
also define what you are trying to achieve
| | 01:30 | with each iteration and develop a
detailed plan for the work in that iteration.
| | 01:36 | The executing process is often easier
in agile projects because they typically
| | 01:41 | use small teams of highly skilled
people who work in the same location.
| | 01:45 | These conditions make it much
simpler to get everyone on board.
| | 01:49 | With agile project management, you
monitor and control the project more closely
| | 01:54 | and communicate faster and more frequently.
| | 01:57 | Finally, each iteration has its
own closing process for accepting its
| | 02:02 | specific deliverables.
| | 02:03 | Then when the final iteration is
accepted, you can complete the other closing
| | 02:08 | activities, such as closing contracts.
| | 02:10 | You will determine which approach,
traditional or agile, makes sense during
| | 02:15 | the initiating process of a project once you
know whether or not your solution is clear.
| | 02:20 | We'll discuss the initiating
process in the next chapter.
| | Collapse this transcript |
| Exploring project management software options| 00:00 | In this video, we will examine some of
the software options available on the
| | 00:04 | market that can make your job
as a project manager easier.
| | 00:07 | Scheduling software comes in
a variety of shapes and sizes.
| | 00:11 | With the simplest projects some people
uses spreadsheet to map out who works
| | 00:15 | out on what, day by day.
| | 00:17 | However, for more complex projects,
the most well-known desktop project
| | 00:22 | management programs are Project and Primavera.
| | 00:25 | Both of these programs come with a ton
of features for setting up and managing
| | 00:29 | a project's schedule.
| | 00:30 | Other project management programs
cost less but still offer impressive
| | 00:35 | toolkits, for example,
FastTrack Schedule, OpenProj, and @Task.
| | 00:40 | When you think about all the documents
you produce during the life of a project,
| | 00:44 | you quickly realize that a word
processing program is an essential part of your
| | 00:48 | project management software.
| | 00:50 | Although every project is unique,
projects still share a lot of similarities,
| | 00:54 | so it's a good idea to build document
templates so you don't have to start
| | 00:58 | from scratch every time.
| | 01:00 | A spreadsheet program is another must-have
for all kinds of calculations and analysis.
| | 01:05 | For example, you can put together a
spreadsheet to analyze the risks your
| | 01:09 | project faces and figure out
which ones you should keep an eye on.
| | 01:13 | A presentation program like PowerPoint
is useful when you have to communicate
| | 01:17 | project information at a high level or
when you want to include information from
| | 01:22 | a variety of other types of documents.
| | 01:24 | Because a project usually has a team of
people working on it, you need some kind
| | 01:28 | of tool for collaborating with others.
| | 01:31 | Basecamp and Microsoft SharePoint
are just two of the web-oriented
| | 01:35 | collaboration tools you can use to
share files with others, keep track of
| | 01:39 | issues, or even manage your workflow.
| | 01:41 | If you work on very large projects or
in an organization that runs dozens or
| | 01:46 | even hundreds of different projects at
the same time then you should consider
| | 01:50 | enterprise project management software.
| | 01:53 | Enterprise-level software provides
tools that allow you to find resources with
| | 01:57 | the skills you need and see which
resources are available when you need them.
| | 02:01 | It helps you track risks, issues, and
other information, and even build document
| | 02:07 | libraries so team members can
easily find information they need.
| | 02:11 | We've only briefly touched upon
some of the software options available.
| | 02:15 | I recommend you consider the
following in your decisions:
| | 02:18 | the culture and work environment of
your organization, costs, the number of
| | 02:23 | projects you manage, and their complexity.
| | Collapse this transcript |
|
|
2. Initiating a ProjectInitiating a project| 00:00 | The purpose of the initiating process is
to obtain commitment to start a project.
| | 00:05 | You want the customer or management team
to be able to make an informed decision
| | 00:10 | whether to move to the planning process
without spending a lot of money or time.
| | 00:15 | During the initiating process you
identify the problem the project is supposed
| | 00:19 | to solve and you gather more
information to define the project.
| | 00:24 | This information is presented in a
document known as a project definition
| | 00:28 | or project summary.
| | 00:30 | In many instances, you as project
manager may be assigned to the project
| | 00:34 | after it's been approved.
| | 00:36 | In this chapter, I'll be sharing with
you the key elements of a project summary.
| | 00:40 | I will also discuss identifying
project stakeholders and how to present your
| | 00:44 | project summary to them to obtain approval.
| | Collapse this transcript |
| Writing a problem statement| 00:00 | In the first chapter of this course I
explained that every project has a specific goal.
| | 00:05 | The goal of a project is to accomplish
something, like solve a problem or take
| | 00:09 | advantage of an opportunity.
| | 00:11 | This goal drives every decision in
the project, so you want to sure you
| | 00:15 | accurately describe the
underlying problem or opportunity.
| | 00:19 | You do this by putting together a
document called a problem statement.
| | 00:24 | A problem statement clearly defines the
problem that you are attempting to solve
| | 00:28 | or the opportunity you are
attempting to take advantage of.
| | 00:32 | It doesn't have to be a long-winded
affair. If you spell out what the problem is
| | 00:36 | in one sentence, all the better.
| | 00:39 | Let's look at some examples.
| | 00:41 | Our company has three hundred employees
and needs another hundred people.
| | 00:45 | The current office space
can handle up to three hundred and twenty people.
| | 00:50 | The problem statement is,
| | 00:52 | we don't have enough
space for all our employees.
| | 00:55 | And one more example. We have new
products that customers don't know about; our
| | 01:01 | sales have been declining.
| | 01:03 | The problem statement is, we are
losing sales to our competitors.
| | 01:07 | Defining a problem can be a challenge
because people often jump straight to solutions.
| | 01:13 | Solutions describe the end result of a
project, not the beginning motivation.
| | 01:19 | For example, end results would be, we need
a new building, or we need to increase sales.
| | 01:26 | These are not problem statements, but solutions.
| | 01:29 | One way to backtrack from a proposed
solution to the original problem is to ask why.
| | 01:35 | Why do we need a new building?
| | 01:37 | Why do we need to increase sales?
| | 01:39 | Don't be afraid to ask why more than once and
then probe for more detail as the story unfolds.
| | 01:46 | You can use the answers to get to the
bottom of the problem and start uncovering
| | 01:50 | more specific objectives for the project.
| | 01:52 | The problem statements would be, we
don't have enough space for projected growth,
| | 01:58 | or we are losing sales to our competitors.
| | 02:01 | Write a problem statement for the
project you are working on. Keep it simple.
| | 02:06 | Make sure you are not writing a
solution statement. Don't be afraid to ask why
| | 02:11 | and other questions until you have a
clear and simple statement that defines the
| | 02:15 | underlying reason for your project.
| | Collapse this transcript |
| Defining project goals and objectives| 00:00 | In the last video we defined the problem
that our project is attempting to solve.
| | 00:05 | Now that the problem has been defined,
we need to describe what the project is
| | 00:09 | supposed to achieve.
| | 00:11 | We do this by defining a project goal.
| | 00:14 | A project goal is the high-level
target that states the end result that the
| | 00:19 | project will achieve.
| | 00:21 | The goal should be a simple statement
and easy for everyone to understand. That
| | 00:25 | way you can use it to get buy-in and
guide the team to a successful conclusion.
| | 00:30 | For example, host a corporate sales event.
| | 00:34 | Objectives further define the goal
by fleshing out specific details.
| | 00:40 | Identifying objectives is important
because they help define the scope, your
| | 00:45 | approach, and the success
criteria you have to meet.
| | 00:48 | Business objectives are often
strategies or tactics that support your
| | 00:53 | organization's goals.
| | 00:54 | For example, reduce the return rates on orders.
| | 00:59 | Financial objectives are all about money.
| | 01:01 | Your organization might require that
projects deliver a fifteen percent return on the money
| | 01:06 | invested in the project.
| | 01:08 | Quality objectives specify
how good results must be.
| | 01:12 | For instance, if your project is
supposed to increase customer satisfaction, you
| | 01:17 | might want to increase the number
of customer satisfaction ratings.
| | 01:21 | Projects can have technical objectives.
| | 01:24 | For example, you might want to use
tough machines that can withstand
| | 01:28 | harsh environments.
| | 01:30 | Another category of objectives
is a catchall called Performance.
| | 01:34 | For instance, your project might need
to finish by a specific date, such as your
| | 01:39 | company's product release date.
| | 01:41 | Now that we have discussed several
categories of objectives, let's talk about
| | 01:45 | how to document objectives well.
| | 01:48 | Specific objectives are clear, so
there is no misunderstanding about what you
| | 01:53 | are supposed to achieve.
| | 01:54 | For example, host an event that reaches eighty percent of
our customers and costs no more than $80,000.
| | 02:04 | Vague objectives are bad because
you probably won't get what you want.
| | 02:08 | Be specific when you write your objectives.
| | 02:11 | Measurable objectives eliminate any question
as to whether or not they have been achieved.
| | 02:17 | For instance, you can use ratings from
surveys to measure customer satisfaction.
| | 02:23 | Realistic objectives spell out what
you can do with the resources available.
| | 02:28 | Setting challenging objectives can
motivate people, but your team might give up
| | 02:32 | if they think the objectives are impossible.
| | 02:34 | Time-related objectives
identify when they can be achieved.
| | 02:39 | For example, a new product might need to be
available in stores before the end of the year.
| | 02:45 | For time-related
objectives, set a clear target date.
| | 02:49 | Using the problem statement you wrote
earlier, now write the project goal that
| | 02:54 | states the end result that
the project will achieve.
| | 02:57 | Keep it short, simple, and
easy for everyone to understand.
| | 03:01 | Then write your objectives, keeping
them specific, measurable, realistic,
| | 03:07 | and time-related.
| | Collapse this transcript |
| Choosing a strategy| 00:00 | Once you know the goal and objectives
for the project, you are likely to find
| | 00:04 | that there is more than one
possible strategy from which to choose.
| | 00:08 | In this video, we will examine how you
can evaluate alternative strategies and
| | 00:13 | select the right solution.
| | 00:15 | First, I recommend that you assemble a
small group of people familiar with the
| | 00:19 | project to brainstorm strategies.
| | 00:22 | The brainstorming group should read the
problem statement, the goal, as well as
| | 00:26 | the objectives, and then begin
generating possible strategies.
| | 00:31 | This should be a free flow of ideas.
| | 00:34 | The point is to get as many ideas
written down as possible before you begin
| | 00:38 | criticizing or evaluating the strategies.
| | 00:42 | Once you have a significant number of
strategies written down, you will need to
| | 00:46 | begin evaluating those ideas.
| | 00:49 | You can use a decision
matrix to compare your options.
| | 00:52 | First, the group should ask, how
well does this strategy satisfy the
| | 00:57 | project objectives?
| | 00:59 | One way to quickly shorten the list of
contenders is to check whether a strategy
| | 01:03 | satisfies all the must-have objectives.
| | 01:07 | If a strategy doesn't satisfy one of
your must-haves, you don't have to fill out
| | 01:11 | the rest of the values for that strategy.
| | 01:14 | Next, for the strategies that passed
that first hurdle, rate the performance
| | 01:19 | for each objective.
| | 01:20 | If some objectives are more important than
others, you can increase their weighting.
| | 01:26 | The strategy with the highest
overall rating is most likely your winner.
| | 01:30 | Second, the group should ask,
is this strategy feasible?
| | 01:35 | Strategies that use new technology
or unproven methods might not work.
| | 01:40 | If feasibility could be an issue, a
feasibility study can explore whether this
| | 01:45 | strategy will work without
committing too much time or money.
| | 01:49 | Third, ask, are the risks
of this strategy acceptable?
| | 01:54 | You won't know all the risks at this
stage of a project, but you can perform an
| | 01:59 | initial risk analysis to see whether
any risks are so significant and likely
| | 02:04 | that you don't want to proceed.
| | 02:06 | Fourth, ask does this strategy
fit the culture of the organization?
| | 02:12 | Trying to force a strategy that doesn't
fit with the culture is a losing battle.
| | 02:18 | You won't get the commitment you
need from management or team members.
| | 02:22 | Remember, the strategy you choose
has to satisfy most, if not all, of the
| | 02:27 | project objectives.
| | 02:29 | Once you select a solution from the
alternative strategies, the details of your
| | 02:33 | project will start falling into place.
| | Collapse this transcript |
| Gathering requirements| 00:01 | The goal, objectives, and solution for a
project identify what you are trying to
| | 00:05 | achieve and the general
approach for getting there.
| | 00:09 | Requirements provide the details
of what the outcome must look like.
| | 00:15 | They are the specific needs of the project.
| | 00:18 | Gathering requirements is important,
because if you miss true requirements,
| | 00:22 | the customer won't be
satisfied with the project results.
| | 00:26 | On the other hand, if you include
requirements that aren't really necessary, the
| | 00:30 | project will probably take longer
and cost you more than it should.
| | 00:34 | For the corporate sales event, one objective
is to showcase both new and existing products.
| | 00:41 | One of the requirements could be to
include all the selling points that the
| | 00:45 | sales team identifies in each presentation.
| | 00:49 | Another requirement could be to use the
organization's brand terminology in all presentations.
| | 00:55 | These requirements are
both necessary and detailed.
| | 00:59 | Gathering requirements can be challenging.
| | 01:02 | Sometimes customers know what
they want and sometimes they don't.
| | 01:06 | Customers and stakeholders often mix
wish-list items with true requirements.
| | 01:12 | Another hazard is people who aren't
stakeholders often append their requirements
| | 01:17 | onto your to-do list.
| | 01:20 | As the project manager, you have to
distinguish between true requirements
| | 01:24 | and faux requirements.
| | 01:26 | There are several techniques
for gathering requirements.
| | 01:30 | Each technique has its pros and cons.
| | 01:33 | The best choice of
technique depends on your project.
| | 01:36 | If your current project is like one
that's been done in the past then try
| | 01:40 | reusing existing requirements.
| | 01:43 | To do this, you will need
documentation from that project.
| | 01:47 | Determine whether some features have
become obsolete or new ones have cropped up.
| | 01:52 | Another way to flesh out
requirements is to build a prototype.
| | 01:56 | A prototype is usually a quick and rough
model that your customers use to test out an idea.
| | 02:02 | A prototype is great if your
customers aren't quite sure what they want.
| | 02:06 | Business process modeling and use
cases are examples of methodologies for
| | 02:11 | gathering requirements
about processes and systems.
| | 02:15 | You may have to train people on
the methodology first or hire people
| | 02:20 | experienced with the tools.
| | 02:22 | If your project involves several groups,
you can hold requirements meetings with
| | 02:27 | representatives from each group to
discuss their requirements for the project.
| | 02:32 | These meetings not only help identify
requirements but offer the advantage that
| | 02:37 | you may also obtain buy-in
from the departments that attend.
| | 02:41 | You might want to hold separate
meetings for different audiences, such as the
| | 02:45 | business team and the IT department.
| | 02:47 | In some cases you might have one group
attend to listen to what other groups need.
| | 02:53 | If you are working on a project to
revamp how people work, you can work with
| | 02:57 | the end users directly.
| | 02:59 | One approach is to conduct observations--
in other words, watch what people do in
| | 03:04 | their day-to-day activities.
| | 03:07 | To make sure you get the requirements right,
write them up and review them with the workers.
| | 03:12 | You can also interview people.
| | 03:14 | It's a good idea to put together specific
questions for the first round of interviews.
| | 03:18 | That way you ask everyone the same
questions and don't leave anything out.
| | 03:24 | A second round of interviews can help
clarify and refine the requirements.
| | 03:27 | With your goal in mind,
document your requirements by writing
| | 03:32 | detailed statements of what must
be accomplished in the project to
| | 03:35 | satisfy the objectives.
| | Collapse this transcript |
| Understanding deliverables and success criteria| 00:01 | People expect to get
something when a project is done.
| | 00:04 | These results are called deliverables.
Put simply, deliverables are the products
| | 00:10 | or services that are delivered.
| | 00:13 | Deliverables can be tangible, like a
building, software, or a new employee. Other
| | 00:19 | times deliverable are more
abstract, like a new service.
| | 00:24 | During the planning process
deliverables help you define the project scope,
| | 00:28 | which basically means what is
and isn't included in the project.
| | 00:33 | Once your project gets underway,
deliverables then help you measure progress.
| | 00:39 | Write down what the
deliverables for your project are.
| | 00:43 | Begin with the end deliverables,
which are the goods or services that your
| | 00:46 | project delivers at the end of the project.
| | 00:49 | For example, for our corporate sales
event an end deliverable would be print
| | 00:54 | one thousand sales brochures to
be handed out at the event.
| | 00:58 | Next, document your intermediate deliverables.
| | 01:02 | These are items or services that are
delivered during the course of the project.
| | 01:05 | For instance, if an end deliverable
is print one thousand sales brochures, an
| | 01:11 | intermediate deliverable would be
sign a contract with the printer company.
| | 01:15 | Keep in mind, the customer
doesn't necessarily receive
| | 01:19 | intermediate deliverables.
| | 01:21 | Whenever possible, try to define
deliverables that can be accomplished in the
| | 01:25 | timeframe between status reports.
That way you can evaluate progress based on
| | 01:30 | the deliverables
completed since the last report.
| | 01:33 | If a deliverable is too big,
you could go months without really knowing
| | 01:38 | where things stand.
| | 01:39 | Break up your
deliverables into manageable pieces.
| | 01:42 | So now that you have defined your
deliverables, how do you know that the
| | 01:47 | deliverables you receive are what you wanted?
| | 01:50 | You need some way to measure them.
| | 01:53 | Success criteria are definitions of success.
| | 01:56 | Some are easy to figure out, like sign
vendor contracts or the certificate of
| | 02:02 | occupancy for a building.
| | 02:05 | Other criteria are not so
easy and can be subjective.
| | 02:09 | Therefore, to be effective, write success
criteria that are clear and quantifiable.
| | 02:15 | For the sales event, you might write
success criteria that indicates the number
| | 02:20 | of customers who will attend,
| | 02:22 | the number of products that will be
sold at the event, or a target rating on
| | 02:26 | a survey about how likely attendees are to
purchase your products in the near future.
| | 02:32 | Identify the end deliverables for your
project. Then identify any intermediate
| | 02:38 | deliverables you expect to receive.
| | 02:41 | Once you have deliverables
documented, define success criteria that are
| | 02:45 | clear and quantifiable.
| | Collapse this transcript |
| Identifying assumptions and understanding risks| 00:00 | It's important that you protect
your project plan by indentifying
| | 00:04 | assumptions and risks early on.
| | 00:07 | Let's start with assumptions.
| | 00:09 | An assumption is something that someone
takes to be true without confirming it.
| | 00:14 | Different people can make different
assumptions and if those assumptions aren't
| | 00:18 | brought into the open,
someone will end up disappointed.
| | 00:21 | For example, if you assume that the
marketing department is going to send
| | 00:26 | invitations to customers and marketing
assume sales will do that task, everyone
| | 00:32 | could find out too late that nobody
sent the invitations and customers don't
| | 00:36 | know about the event.
| | 00:38 | Assumptions can be tricky because
people often don't realize they are
| | 00:41 | assuming something.
| | 00:43 | The key is to get assumptions out in
the open. That way you can make sure
| | 00:49 | everyone is on the same page.
| | 00:51 | Think about uncovering unspoken
assumptions as you work through every step
| | 00:56 | of the project plan.
| | 00:57 | Ask questions about what people expect, what
they envision when they think about the project.
| | 01:04 | Don't be shy about asking more than once.
| | 01:08 | Uncovering unspoken assumptions
is almost like being a detective.
| | 01:12 | You ask again and again to
see if the story changes.
| | 01:17 | First, ask people to describe the
results they expect from the project.
| | 01:22 | Ask them to describe project success.
This helps identify objectives that
| | 01:27 | may have been unspoken.
| | 01:29 | If the list you end up with
outstrips the budget or resources you have
| | 01:33 | available, you can negotiate
with the team to rein it in.
| | 01:37 | Let's now discuss risks.
| | 01:39 | A risk is a situation or event with
some probability of occurring that might
| | 01:44 | negatively affect your project.
| | 01:47 | Risks are events that may or may not arise
but will cause problems if they do occur.
| | 01:53 | Early on in a project spend some time
identifying risks that could affect the
| | 01:58 | project, mainly so the management
team can make an educated decision about
| | 02:03 | whether or not to invest in the project.
| | 02:06 | If you identify numerous risks
and several are quite worrisome, it might
| | 02:11 | be better to forgo the project for another one.
| | 02:14 | Document assumptions and risks as you
flesh out what your project is about.
| | 02:20 | That way the customer or the
management team can consider all the pros and
| | 02:24 | cons of the project before they decide
whether to give it approval to proceed
| | 02:28 | to planning.
| | Collapse this transcript |
| Creating a scope statement| 00:00 | After you document requirements and
deliverables, create a scope statement so
| | 00:05 | that what the project is
going to do is crystal clear.
| | 00:08 | The project scope actually describes
the boundaries of the project. That is,
| | 00:13 | what is included in the scope of the
project and just as important, what isn't included.
| | 00:19 | A scope statement helps you evaluate
whether a project is doing what it should,
| | 00:24 | no more and no less, and whether the
budget and other aspects make it worthwhile.
| | 00:30 | Here is an initial scope
for the corporate sales event.
| | 00:34 | As you can see, the scope statement
covers the work and deliverables for which
| | 00:39 | the team is responsible.
| | 00:41 | Your scope statement can also include
an out-of-scope section that indicates
| | 00:46 | work that is not the responsibility of the team.
| | 00:50 | Suppose the trade show organizers take
care of running electrical service and
| | 00:54 | delivering your shipment to where your
booth is located on the trade show floor.
| | 00:59 | In that case, you can define the scope
so your team knows what they do and what
| | 01:04 | the trade show people do.
| | 01:06 | The out-of-scope section is a good
place to document assumptions about what is
| | 01:10 | outside the boundaries of your project.
| | 01:13 | A scope statement also helps to
prevent a project from expanding.
| | 01:17 | Scope creep is the name for this
well-known hazard in the project world.
| | 01:22 | Customers and team members alike might
come up with this one little thing to add
| | 01:27 | to the project, but those little things
add up and before you know it, the scope
| | 01:32 | is expanded beyond your budget, beyond
your resources, and past the due date.
| | 01:38 | With a clear scope statement,
you know what's within scope.
| | 01:42 | If someone wants to add something,
you can discuss the impact to decide whether
| | 01:46 | or not it make sense.
| | 01:47 | Because a scope statement defines the
boundaries of a project at a high level,
| | 01:53 | you also need a change-management
process to control the smaller change
| | 01:57 | requests that come in.
| | 01:58 | We'll cover the change-
management process in the next chapter.
| | 02:03 | Sometimes members of your team end up
expanding the scope without you knowing
| | 02:08 | about it. Perhaps a programmer adds
the feature that she is sure the customer
| | 02:12 | would want even if it isn't in the requirements.
| | 02:15 | When you assemble your project team,
emphasize the importance of the scope and
| | 02:19 | the project objectives.
| | 02:21 | Revisit your objectives and deliverables
and use them to write a scope statement
| | 02:27 | that identifies what is and is not
within the scope of your project.
| | 02:32 | Then review your assumptions and if
necessary, add items to what is within scope
| | 02:38 | or out of scope for your project.
| | Collapse this transcript |
| Identifying stakeholders| 00:00 | The term stakeholder means someone who
has a stake in the outcome of a project.
| | 00:05 | This includes the customer, the
departments affected by the project, and even
| | 00:09 | the people who work on project tasks.
| | 00:12 | Sometimes it can be challenging to
determine who the stakeholders are for your project.
| | 00:17 | First, let's identify major stakeholder roles.
| | 00:21 | The project customer is the person
or group who has a problem to solve.
| | 00:26 | The project customer brings
three crucial things to a project.
| | 00:29 | First, the customer funds the project;
| | 00:32 | second, the customer has a lot to say
about what the project will do; third, the
| | 00:39 | customer approves
deliverables from start to finish.
| | 00:43 | The next stakeholder role is project sponsors.
| | 00:46 | Sponsors are people who want to see
the project succeed and have enough
| | 00:50 | formal authority to help make that happen,
like an executive who believes in the project.
| | 00:55 | A sponsor can help prioritize objectives,
talk to stakeholders who aren't being
| | 01:00 | supportive, and suggest
improvements to the plan.
| | 01:03 | The third type of stakeholder
is a functional or line manager.
| | 01:08 | Functional managers run
departments and are accountable for achieving
| | 01:11 | their department's goals.
| | 01:13 | They also manage the people in their
departments, who are the very same people
| | 01:17 | you need for your project.
| | 01:20 | Finally, team members are also stakeholders.
| | 01:23 | While they are assigned to your project,
their jobs depend on their assignment
| | 01:27 | and on how well they perform.
| | 01:29 | Now that you have identified your
stakeholders, how do you work with them effectively?
| | 01:34 | First, you need to know what
motivates your stakeholders and how they are
| | 01:38 | connected to your project.
| | 01:40 | You can store information in a
stakeholder analysis document.
| | 01:44 | Start by including the department,
business unit, or company the
| | 01:48 | stakeholder belongs to.
| | 01:50 | Determine who the stakeholder listens to.
That can help if you need to explore
| | 01:54 | ways to deal with an issue with a stakeholder.
| | 01:57 | Identify the project objectives that the
stakeholder cares about, and their priority.
| | 02:03 | That way you know who to talk to
if an issue comes with an objective.
| | 02:08 | Finally, document the stakeholder's
contribution to the project, so you know
| | 02:12 | what to expect from him, or who
to turn to for things you need.
| | 02:16 | Remember, stakeholders are
crucial to the success of your project.
| | Collapse this transcript |
| Obtaining approval| 00:00 | Now that the project is defined, you
need to get approval from the stakeholders
| | 00:04 | to proceed to planning.
| | 00:07 | Obtaining approval is important,
because you need commitment from project
| | 00:10 | stakeholders to make a project a success.
| | 00:14 | Once you have the initial project
summary, you might think about getting
| | 00:17 | approval by mailing or emailing a
packet to stakeholders and asking them to
| | 00:21 | sign on the dotted line.
| | 00:22 | I do not recommend you do this.
| | 00:25 | The problem with that approach is that
people don't read through the packet.
| | 00:29 | They might sign their names, but if
they find something they disagree with
| | 00:32 | later, their commitment disappears
and you are back where you started.
| | 00:38 | A face-to-face sign-off
meeting is more effective.
| | 00:41 | Schedule a meeting
specifically for obtaining approval.
| | 00:45 | The agenda for the meeting is straightforward.
| | 00:47 | First, review the project summary that
you have put together to make sure that
| | 00:51 | the stakeholders agree with it.
| | 00:54 | If any issues come up, deal with them
right then and there. Or if the issues
| | 00:58 | are big enough, you might have to reschedule
the sign-off and go back to rework the documents.
| | 01:04 | Once everyone agrees, ask them all to sign
a signature page to indicate their approval.
| | 01:09 | If you can't get everyone in the
same room, a video conference or
| | 01:14 | conference call works too.
| | 01:16 | Ask people in other locations to
transmit their signatures to you by fax, email,
| | 01:21 | or snail mail if necessary.
| | 01:24 | Signing a project summary isn't
like signing a legal document.
| | 01:27 | You are probably never going to come back to
your stakeholders and say "But you signed this!"
| | 01:33 | What's important is that the
stakeholders understand what the project is
| | 01:36 | about and buy into it.
| | Collapse this transcript |
| Writing a project charter| 00:00 | Now that the project is approved, the
final step of the initiating process is
| | 00:05 | writing a project charter.
| | 00:08 | Project managers don't have the
kind of authority that managers in a
| | 00:11 | structured organization do.
| | 00:13 | Projects managers' authority lasts as
long as the projects they manage and
| | 00:18 | applies only to those projects.
| | 00:21 | For that reason it's important that
people understand what a project manager
| | 00:25 | is authorized to do.
| | 00:27 | A project charter is the vehicle for doing that.
| | 00:31 | Typically, your project sponsor
publishes the project charter to formally
| | 00:35 | announce the project and to communicate
the responsibilities and authority that
| | 00:40 | you have as the assigned project manager.
| | 00:44 | The typical project charter
includes the following items:
| | 00:48 | the name of the project; the purpose of
the project--a one-sentence summary of
| | 00:52 | the goal and objectives will do--
| | 00:55 | the name of the project manager;
the project manager's responsibilities,
| | 00:59 | including a brief description of
the work the project manager does;
| | 01:03 | the extent of the project manager's
authority; and the specific work the
| | 01:07 | project manager has authority to perform, such
as requesting resources or signing contracts;
| | 01:14 | a formal declaration of the sponsor
support for the project. Think of this
| | 01:19 | declaration as a power of attorney
given to the project manager by the
| | 01:23 | sponsor or customer.
| | 01:25 | When the project charter is ready to
go, the project sponsor distributes it to
| | 01:30 | everyone affected by or in
some way involved in the project.
| | 01:34 | Unlike the project approval meetings,
the publication of the charter can be via
| | 01:38 | email or the preferred
method in your organization.
| | 01:42 | Once you have approval to start
planning the project and your authority
| | 01:46 | as project manager is common
knowledge, you are ready to begin the
| | 01:49 | planning process.
| | Collapse this transcript |
|
|
3. Planning a ProjectPlanning a project| 00:00 | During the planning process, you
identify the work that must be done, who is
| | 00:04 | going to do it, how long everything
will take, when things will happen, and
| | 00:08 | how much it will cost.
| | 00:10 | You also plan how you'll run the
project, such as how you'll communicate, manage
| | 00:16 | change and risk, and ensure quality.
| | 00:19 | All of this information goes into
documents that together represent the project plan.
| | 00:25 | You use the plan once the project work
gets started: to direct the people working
| | 00:30 | on your project, to keep track of how
the project is going, to correct course if
| | 00:35 | need be, and to communicate
with team members and management.
| | 00:39 | In this chapter, I'll be sharing with
you the components of a project plan, and
| | 00:43 | because a project schedule is a key
component of your plan, Chapter 4 is devoted
| | 00:49 | to how you build one.
| | Collapse this transcript |
| Understanding work breakdown structures| 00:00 | After you get the go ahead to start
planning your project, the first thing you
| | 00:04 | do is identify the work that has to be done.
| | 00:07 | A work breakdown structure, or WBS, is
the tool you use to divvy up project
| | 00:12 | work into bite size pieces so you can plan,
track, and manage your project effectively.
| | 00:19 | Creating a WBS helps the
project in several ways.
| | 00:22 | First, it's easier to estimate the
time and cost for smaller chunks of work.
| | 00:27 | Second, it's easier to
assign work to team members.
| | 00:32 | Third, by breaking work into smaller
pieces you build checkpoints into your
| | 00:36 | project that allows you to measure progress.
| | 00:39 | A WBS contains two kinds of tasks:
summary tasks and work packages.
| | 00:45 | First, summary tasks are the higher-level
tasks that summarize project work in some way.
| | 00:52 | Summary tasks can describe each process
of the project, including planning the
| | 00:56 | event, preparing the materials, making the
arrangements, and finally holding the event.
| | 01:02 | The number of levels of summary
tasks depends on the size of the project.
| | 01:06 | A few levels is probably
enough for a small project.
| | 01:11 | With a large or complex project, such as
developing a new airplane, you could have
| | 01:16 | many levels of summary tasks.
| | 01:18 | Second, work packages are the lowest-
level tasks that spell out the details of
| | 01:24 | the work that needs to be done.
| | 01:25 | In our example, under preparing
materials, work packages would include creating
| | 01:31 | sales materials, creating
presentations, and printing materials.
| | 01:35 | The work breakdown structure is
the key to planning out a project and
| | 01:39 | managing it effectively.
| | 01:41 | Now that we understand what a WBS is
and how it's structured, let's look at
| | 01:46 | how you build one.
| | Collapse this transcript |
| Building a work breakdown structure| 00:00 | In the previous video I defined what a
work breakdown structure is. Now I am
| | 00:05 | going to explain how to build one.
| | 00:07 | The best way to build a WBS is to
start at the top and work your way down.
| | 00:12 | By top, I mean the top level of summary tasks.
| | 00:15 | For larger projects, you might work as
a team to identify the top couple of
| | 00:19 | levels of summary tasks. Then the team
can split off into smaller groups to break
| | 00:24 | down the work for the summary tasks.
| | 00:27 | At the end, everyone gets back together to
review the results and correct any issues.
| | 00:32 | Start by using the scope statement
and deliverables to identify the top-
| | 00:36 | level summary tasks.
| | 00:37 | For example, since the sales event
scope includes attending trade shows and
| | 00:43 | producing new sales materials, you add
summary tasks to cover those. Next break
| | 00:49 | down the work that makes up
each of the summary tasks.
| | 00:52 | This is where intermediate
deliverables come in handy for identifying lower-
| | 00:56 | level summary tasks and work packages.
| | 00:59 | For example, the sales project
includes deliverables for signed contracts.
| | 01:04 | Add tasks to prepare,
negotiate, and sign the contracts.
| | 01:09 | The question you might be asking at this
point is, how much breakdown is enough?
| | 01:14 | One approach is to break down project
work to match the frequency of your
| | 01:18 | status reports, so you have measurable
progress and completed tasks for every status report.
| | 01:24 | The rule of thumb most project managers
use is to shoot for work packages that
| | 01:29 | take between eight and eighty hours to complete.
| | 01:32 | You can use the following test to
determine whether you have broken work down
| | 01:36 | to the right level.
| | 01:37 | Time and cost are easy to estimate,
status is easy to measure, task durations
| | 01:43 | are shorter than your reporting periods,
and the detail is at the level that you
| | 01:47 | can and want to manage.
| | 01:49 | Different parts of a project might
require different levels of decomposition.
| | 01:54 | One part of the project might include more
work, so you break it down to three levels.
| | 01:59 | If another part of the project is
simpler, you might need only two levels.
| | 02:03 | Finally, don't worry about the
initial organization of your WBS.
| | 02:08 | You can review it later on to see
whether you want to rearrange tasks.
| | Collapse this transcript |
| Defining work packages| 00:00 | Now that you have built a WBS, you need
to make sure your team understands it.
| | 00:05 | A short name in a WBS typically
isn't enough to tell people exactly what
| | 00:10 | they are supposed to do.
| | 00:11 | To make sure your team knows what to
do, create work-package documents that
| | 00:16 | describe the work
identified in the WBS in detail.
| | 00:20 | The level of detail you include in the
work-package document depends on things
| | 00:24 | like how familiar the work is and
perhaps the experience of the person
| | 00:28 | assigned to the task.
| | 00:29 | For example, a work-package document
might include a checklist of things to do,
| | 00:35 | which helps a less experienced person
understand their assignment but serves as
| | 00:39 | a remainder for a more experienced individual.
| | 00:43 | You don't have to include every iota
of detail in the work-package document.
| | 00:48 | If the specifics of the work are
described somewhere else, you can refer to the
| | 00:51 | other document that contains the information.
| | 00:54 | A work-package document does
more than describe the work;
| | 00:58 | it also identifies how you know the
task is complete and whether it was
| | 01:02 | completed correctly.
| | 01:04 | For some tasks you can include the
corresponding deliverable and success
| | 01:08 | criteria in a work package document;
otherwise, write up a description of what
| | 01:14 | you will have when the task is
complete and what it should look like.
| | 01:18 | Finally, you have probably figured out
that you, the project manager, don't know
| | 01:22 | enough about every aspect of the work to
produce these detailed descriptions for every task.
| | 01:28 | Turn to the people who helped you
build the WBS, team leaders for the groups
| | 01:32 | that will work on the project, or other
knowledgeable people to help fill in the details.
| | 01:37 | If you get the details right, your
team is more likely to know exactly what to do.
| | Collapse this transcript |
| Building a schedule| 00:00 | A WBS identifies the work people
have to do to complete a project, but it
| | 00:05 | doesn't tell you how long the work
will take, or when it can be performed.
| | 00:09 | To do that, you need to turn
your list of tasks into a schedule.
| | 00:14 | First put the tasks into the right
sequential order, that is, you have to specify
| | 00:20 | which tasks have to finish before
other task can start, which tasks start or
| | 00:25 | finish at the same time, and so on.
| | 00:27 | For example, you can't load
computers with sales presentations until the
| | 00:32 | presentations are complete and working properly.
| | 00:35 | To get tasks into order, you specify the
dependencies, also called links, between
| | 00:40 | tasks in your project.
| | 00:42 | The most common is finish to start,
but you can choose from several types
| | 00:46 | of dependencies, as I will
explain further in the video "Creating
| | 00:50 | dependencies between tasks."
| | 00:52 | Second, you need to estimate
the time each task will take.
| | 00:56 | The time estimates you put together for
each task and the order in which tasks
| | 01:00 | occur help determine how long
the entire project will take.
| | 01:05 | Reasonable estimates are key to
figuring out when a project can finish.
| | 01:08 | You have to estimate as accurately as
you can, because underestimating and over-
| | 01:14 | estimating both lead to project problems.
| | 01:17 | Third, you need to identify the people on
your project team and assign them to tasks.
| | 01:22 | With the estimated hours and the
people assigned to do the work, you can
| | 01:25 | calculate the task's duration.
| | 01:28 | Finally, take into account
other constraints, such as deadlines.
| | 01:33 | If your initial schedule doesn't quite
do what you want, you can tweak it in a
| | 01:36 | number of ways, whether you are trying
to shorten the schedule, cut costs, or
| | 01:41 | assign available people.
| | 01:43 | The schedule is one of the most
important aspects of your project. It tells
| | 01:47 | you how long the project will last
and when you need the people who will do the work.
| | Collapse this transcript |
| Identifying resources| 00:00 | As project manager, you should
understand every person's role and
| | 00:04 | responsibility on the project.
| | 00:06 | Likewise, your team members should know
the chain of command and understand their
| | 00:10 | own personal role and
responsibilities within that chain.
| | 00:14 | First, create a responsibility matrix.
| | 00:17 | A responsibility matrix spells out
who can make or approve decisions, the
| | 00:23 | groups performing work, and which groups need
to be consulted or informed of what's going on.
| | 00:29 | A responsibility matrix includes
four categories of responsibility.
| | 00:33 | R means that a group is
responsible for performing work.
| | 00:37 | I represents inform, which
means a group gets information.
| | 00:41 | C means that you consult a
group about decisions; however,
| | 00:46 | they aren't accountable
for the decision that's made.
| | 00:49 | A is for accountable, which means
the group makes or approves decisions
| | 00:55 | and delegates work.
| | 00:57 | Next, review the responsibility matrix
with stakeholders during planning and work
| | 01:02 | out any disagreements before work gets started.
| | 01:06 | If part of your project doesn't have an
owner, talk to the stakeholders and your
| | 01:09 | project's sponsor to determine
owners of the orphaned areas.
| | 01:14 | If you use resources from other
organizations, such as with outsourcing,
| | 01:18 | subcontracting, and partnering
arrangements, document how all these groups
| | 01:23 | contribute in the responsibility matrix.
| | 01:26 | Next, create a project organization chart
which shows the hierarchy and reporting
| | 01:32 | structure for people involved
with, or working on, a project.
| | 01:36 | Your project organization chart
identifies the chain of command so you know who
| | 01:41 | to talk to if you need to
escalate a request or decision.
| | 01:45 | Finally, identify the type and number of
skilled team members the project requires.
| | 01:51 | A skills matrix is a tool you use
to determine these requirements.
| | 01:55 | To build a skills matrix first
examine your work packages and identify the
| | 02:00 | skills the package requires.
| | 02:02 | Second, create a matrix with your
project tasks in rows and the skills you
| | 02:08 | need in the columns.
| | 02:09 | Third, check boxes in the matrix
when tasks require a specific skill. The
| | 02:16 | number of checked boxes for a skill helps you
identify how many people you need with that skill.
| | 02:22 | Fourth, estimate the labor cost of the project.
| | 02:26 | To do this, assign a typical pay rate to
each skill. Then multiply the number of
| | 02:32 | people by the pay rate.
| | 02:34 | This will give you an estimate
of the labor cost for the project.
| | 02:37 | You now have an idea of the type and
number of skilled team members your project
| | 02:41 | requires, as well as an
estimate of the labor costs.
| | Collapse this transcript |
| Building a project budget| 00:00 | Most projects boil down to money: making
it, saving it, or at the very least, staying
| | 00:06 | within a budgeted amount.
| | 00:08 | The total cost of a project, that is,
the budget, is almost always important.
| | 00:13 | As a project manager you estimate the
total project cost by calculating the cost
| | 00:19 | to complete all the work.
| | 00:20 | In some cases, you present that budget
to management and they decide whether the
| | 00:25 | project makes financial sense.
| | 00:28 | In many instances, however, you
receive a target cost from the management
| | 00:32 | team. Then it's your responsibility to
figure out how to plan the project to
| | 00:37 | stay within that budget.
| | 00:38 | Now that you understand your role in
building a budget, it's time examine the
| | 00:43 | costs that make up a project price tag.
| | 00:45 | First, labor costs are usually
a big part of a project's cost.
| | 00:50 | If you hire vendors or contractors, their
charges go directly into your labor costs.
| | 00:55 | Including employee costs is important,
because they contribute to whether a
| | 00:59 | project makes financial sense.
| | 01:01 | For employees, you use the burden
cost, that is, salary and employee benefits,
| | 01:07 | which you can obtain from
your human resources department.
| | 01:10 | Second, projects could use other
types of time-based resources, such as
| | 01:16 | equipment or office space that you rent.
| | 01:18 | Include these equipment and other
time-based costs in your calculations.
| | 01:23 | The third type of cost is material
cost, such as the paper you use to print
| | 01:28 | sales materials or the
construction materials for a building.
| | 01:31 | Finally, be sure to include other types
of ancillary costs that don't fit in the
| | 01:36 | previous three categories.
| | 01:38 | For example, travel, training
expenses, and registration fees fall into
| | 01:44 | this catch-all category.
| | 01:46 | Money is almost always a
consideration with projects.
| | 01:49 | You might need to know only whether the
price tag is within your budget, or you
| | 01:54 | might have to show that the project
delivers the financial benefits your
| | 01:57 | organization expects.
| | Collapse this transcript |
| Identifying risks| 00:00 | Every project faces risks.
| | 00:03 | If you don't plan for how you will
deal with them, you end up putting out
| | 00:06 | fires, which can cost your project time and
money and increase the pressure on your people.
| | 00:12 | A risk management plan is the tool you use
to plan for the risks you might encounter.
| | 00:17 | With the risk management plan in
place, you've already decided how to
| | 00:21 | respond when risks become reality, so you are
ready to make informed and prudent decisions.
| | 00:27 | To build a risk management plan, first
identify the risks your project faces.
| | 00:33 | Risks you are aware off are called
known unknowns, such as cancelled flights
| | 00:38 | or mis-routed shipments.
| | 00:40 | To help you get started, here are
some examples of things that can
| | 00:43 | introduce risk to projects.
| | 00:46 | Technology might not work the way it's
supposed to, cost more than you expect,
| | 00:50 | or not show up when you need it.
| | 00:53 | Team members located in different areas
can increase risk, such as delays due to
| | 00:58 | time zone differences, miscommunication
due to different languages or cultural
| | 01:03 | differences, or lack of teamwork
because remote team members can't develop
| | 01:08 | effective working relationships.
| | 01:10 | Lack of detail, such as specifics on
deliverables, due dates, or who will work on
| | 01:16 | your project, can lead to all sorts of problems.
| | 01:20 | Limited options, such as needing
people with rare skills, increase risk,
| | 01:25 | because you don't have alternatives if
a problem arises. Work with everyone on
| | 01:30 | your team to identify risks.
| | 01:32 | Talk to the experts from different parts
of the project about the risks they foresee.
| | 01:37 | Ask key people on the project what they
think. Ask other project managers about
| | 01:42 | risks from similar projects.
| | 01:44 | Fill out a risk information form with
you know about each risk you identify.
| | 01:49 | Document specifics about the risks, for
example, which tasks are affected, what
| | 01:55 | objectives are in danger, what
the consequences are, and so on.
| | 02:00 | Up until now, we have covered
identifying the risks we can anticipate, but what
| | 02:04 | do you do about the risks that you
can't foresee? Called unknown unknowns,
| | 02:09 | these risks come from situations
that are so out of this world that they
| | 02:13 | never occur to you.
| | 02:14 | For example, prior to the invention of
the personal computer, manufacturers of
| | 02:19 | typewriters probably didn't foresee
the risks to their business. Because you
| | 02:24 | can't identify these risks, you handle
them by setting aside contingency funds
| | 02:28 | for dealing with them, like
having an insurance policy.
| | 02:32 | Contingency funds are a commonly used
method for responding to small risks and the
| | 02:37 | unknown unknown risks you can't foresee.
| | 02:40 | The question is, how much should you set aside?
| | 02:43 | Many companies use a percentage of the
project budget, but the percentage used
| | 02:48 | is typically based on past experience.
| | 02:50 | Now that you have identified risks
your project may face, you need to evaluate
| | 02:56 | those risks and determine how you
plan to respond to them if they occur.
| | Collapse this transcript |
| Creating a risk management plan| 00:00 | After you identify risks, the next step
in developing a risk-management plan is
| | 00:05 | to assess each risk you have identified.
| | 00:08 | To assess risks, you ask two questions.
| | 00:12 | What is the likelihood that the risk will occur?
| | 00:16 | For example, if a tradeshow takes place
in Denver in March the likelihood of bad
| | 00:20 | weather and cancelled flights is high.
| | 00:23 | The second question is, how big
is the impact if it does occur?
| | 00:27 | For example, if bad weather prevents
your sales team from arriving the impact on
| | 00:32 | your sales event is significant.
| | 00:35 | Ask the same people who helped
you identify risks to assess their
| | 00:39 | probability and impact.
| | 00:41 | After you assess all the risks,
the next step is to prioritize the risks and
| | 00:46 | decide which ones you will manage.
| | 00:48 | If you use low, medium, and high, you
might decide to manage risks if they are
| | 00:54 | medium or high in either probability or impact.
| | 00:58 | The next step in a risk-management
plan is to decide how you will respond to
| | 01:03 | each risk in your plan.
| | 01:05 | Here are some risk responses you can use.
| | 01:08 | The easiest option is to
simply accept the consequences.
| | 01:12 | That's fine for risks with
low probability and the impact.
| | 01:16 | Another option for less significant risk is
to use contingency funds to address the issue.
| | 01:23 | Avoiding risk is another option.
| | 01:25 | For instance, changing the project scope
to remove the risky part of the project,
| | 01:30 | or flying the sales team
out several days in advance.
| | 01:34 | Mitigating risk means taking
steps to reduce the consequences.
| | 01:38 | For example, you can ship backup computers to
the tradeshow in case some of them don't work.
| | 01:44 | Transferring risk simply means handing
off the risk to someone else, like you do
| | 01:49 | when you purchase insurance.
| | 01:51 | When you choose your responses,
make sure they aren't overkill.
| | 01:55 | If the impact of a schedule delay is a
$500 late fee, it doesn't make sense to
| | 02:00 | spend $5000 to prevent the delay.
| | 02:03 | The final step in a risk-management
plan is defining how you will monitor risks
| | 02:08 | and measure responses.
| | 02:10 | You create a risk log with
information about each risk you plan to manage.
| | 02:15 | This log summarizes your plan for the risk.
| | 02:19 | A description of the risk, the events
or circumstances that trigger the risk,
| | 02:24 | the response you've chosen, who will
monitor the risk, and the result you expect
| | 02:29 | from the response if you have to use it.
| | 02:32 | You create a risk-management plan during
the planning process. Then you implement
| | 02:38 | that plan once the project is underway.
| | Collapse this transcript |
| Setting up a communication plan| 00:00 | Good communication is crucial
to the success of a project.
| | 00:04 | If you project is large and complex,
with people working around the globe, good
| | 00:08 | communication is even more important.
| | 00:11 | During planning you put together a
communication plan that helps you get the
| | 00:15 | right information to the right
people in the most effective way.
| | 00:19 | First, identify your audiences, that
is, who needs to know about the project?
| | 00:25 | The responsibility matrix is a good
place to look to find your audiences.
| | 00:30 | Second, define what your
audiences need or want to know.
| | 00:34 | Management stakeholders typically care
most about a project achieving its goals.
| | 00:39 | During planning you
communicate the project plan to do that.
| | 00:44 | While the project is underway, you
communicate progress, how much you've spent,
| | 00:48 | and the overall project results.
| | 00:52 | The project sponsor is more tightly
connected with the project, so you'll
| | 00:56 | probably communicate with the
sponsor more often and perhaps use frequent
| | 01:01 | face-to-face meetings.
| | 01:02 | Functional managers initially need to
know the skill sets, when you need them,
| | 01:07 | and the other things like cost constraints.
| | 01:10 | When people are on assignment,
these managers want to know whether the
| | 01:14 | assignments are going according to
plan and how long their people are going to
| | 01:17 | be on the assignment.
| | 01:19 | Team members need to know what they are
supposed to do and ideally how that fits
| | 01:24 | into the big picture.
| | 01:25 | As they complete assignments, they
also need to know what's on deck.
| | 01:29 | Finally, the last part of a
communication plan is how you distribute
| | 01:34 | information to your audiences,
| | 01:36 | that is, how often information is exchanged,
how it's sent, and the format you use.
| | 01:43 | Face-to-face communication is good for
brainstorming, getting to know people,
| | 01:47 | and discussing sensitive topics.
| | 01:50 | If your team is dispersed
geographically, email, conference calls, and
| | 01:55 | videoconferencing are indispensible.
| | 01:58 | Documents are good when you have to
send a lot of information or people need
| | 02:02 | time to digest the information they've received.
| | 02:05 | You define your communication plan
during the planning process. Then once the
| | 02:10 | project is underway, you implement
that plan, so your audiences get the
| | 02:14 | information they need as
efficiently as possible.
| | Collapse this transcript |
| Developing a quality management plan| 00:00 | When you plan a project, you also have
to consider the quality stakeholders want
| | 00:04 | from the project's
deliverables or final product.
| | 00:08 | You develop a quality plan in order to
help your project meet that quality standard.
| | 00:13 | For a project, quality translates into
meeting the customers' requirements, and
| | 00:18 | delivering on time and within budget.
| | 00:21 | If your project includes deliverables
or products, quality also means those
| | 00:25 | products are deliverables
conform to specifications.
| | 00:29 | A quality management plan is
made up of three processes.
| | 00:33 | First, identify the quality
standards for deliverables.
| | 00:37 | For example, the quality plan might
include the acceptable tolerance for the
| | 00:42 | dimensions of the final product or
the acceptable number of defective
| | 00:47 | products in a batch.
| | 00:49 | Keep in mind that the goal is for
quality to meet the standards you set.
| | 00:54 | Obviously you don't want
quality that's below standard.
| | 00:58 | The customer won't be happy, might ask
for additional work to deliver the right
| | 01:02 | results, or simply may refuse to pay.
| | 01:05 | However, you don't want quality
that's higher than required either, because
| | 01:09 | other aspects of the project can
suffer, such as the schedule lengthening
| | 01:14 | or costs expanding.
| | 01:16 | Second define a quality assurance plan,
that is, document how you will demonstrate
| | 01:22 | that the quality standards have been met.
For example, you might spot test the
| | 01:27 | products coming off the production
line to statically determine the number of
| | 01:32 | defective products in a batch.
| | 01:34 | Although it isn't a separate quality
process, you can also plan your project to
| | 01:39 | prevent defects in the first place.
| | 01:41 | For example, you might opt for a
simpler design that makes it easier to
| | 01:47 | manufacture a product and thus reduces
the number of defective products that
| | 01:52 | come off the assembly line.
| | 01:54 | Finally, the quality control process
is how you will monitor and measure the
| | 01:59 | quality of your results.
| | 02:01 | Inspections go by a number of names:
review, walkthrough, and audit to name a few.
| | 02:08 | The bottom line is that you examine or measure
results to see if they meet the standard set.
| | 02:13 | Continuous improvement is a
big part of quality management.
| | 02:17 | If you find quality issues, you also
analyze the problems to see how to prevent
| | 02:22 | them, or at least reduce their frequency.
| | 02:24 | For example cause-and-effect diagrams,
also called fishbone diagrams because of
| | 02:30 | their appearance, help identity factors
that could lead to problems, which in
| | 02:34 | turn helps you figure out
ways to prevent the problems.
| | 02:38 | Another tool is a Pareto diagram, which shows
how many defects are generated by each cause.
| | 02:44 | The diagram lists the causes by the
number of defects they generate, so you can
| | 02:49 | address the causes that
produce the most defects first.
| | 02:53 | During the planning process, you define
the quality standards that are required,
| | 02:57 | how you will measure quality, and how
you will determine that the results meet
| | 03:01 | the quality standard you set.
| | 03:03 | Once the project is underway, you
begin monitoring and measuring results and
| | 03:08 | evaluating whether they meet
the quality standards you set.
| | Collapse this transcript |
| Setting up a change management plan| 00:00 | One at a time, requests for changes can
seem small, but those small changes add up
| | 00:05 | and can completely derail
your project's schedule and budget.
| | 00:09 | Changes are unavoidable, so the
only solution is to manage them.
| | 00:13 | First, you have to know the items that
you want to control, such as the project's
| | 00:17 | scope, requirements, or the entire project plan.
| | 00:21 | The versions you control
are called baseline documents.
| | 00:25 | For example, if you have an improved
list of requirements for the project,
| | 00:29 | that's your baseline.
| | 00:31 | If new requirements are suggested, you
can use your change management process to
| | 00:35 | decide whether or not to
add them to the project plan.
| | 00:39 | Keep in mind you don't use change
management on draft versions of documents.
| | 00:44 | When stakeholders sign off on them,
that's when they go under change management.
| | 00:48 | Next, you need a group that reviews change
requests and decides whether to approve them.
| | 00:54 | This group is called a change review
board and is usually made up of key
| | 00:58 | stakeholders, such as the customer,
functional managers, and team leads.
| | 01:03 | Then you need to define a change management
process to use when someone requests a change.
| | 01:09 | Here is one example of a
change management process.
| | 01:12 | The first step is submitting a
change request. A standardized change
| | 01:16 | request form that people fill out
makes it easier to evaluate changes,
| | 01:21 | because each request has the
information the review board needs to evaluate
| | 01:25 | and make decisions.
| | 01:27 | Typically, a change request form
includes details about the requested change,
| | 01:31 | the reason for the change, the business
justification, and the results it should produce.
| | 01:38 | In the second step, the change review
board reviews submitted change requests.
| | 01:43 | The board may reject the change request,
they might ask the requester to provide
| | 01:47 | more detail or revise and resubmit it,
or they may accept the change request.
| | 01:53 | If the board accepts the request
it moves to the evaluation step.
| | 01:58 | In this step someone has to evaluate
the impact of the change. As project
| | 02:02 | manager, you can assign this
task to someone on your team.
| | 02:06 | The evaluator looks at different ways
to handle the request and determines the
| | 02:10 | impact of each alternative.
| | 02:12 | The result of the evaluation is a
change request impact statement, which
| | 02:16 | outlines the alternatives and their
impact. It might include a recommendation
| | 02:20 | for how to proceed.
| | 02:22 | The fourth step is when the impact
statement comes back to the review board.
| | 02:26 | If the board approves the impact
statement, you add the request to the project
| | 02:30 | plan. Whether the decision is yes or
no, be sure to notify the person who
| | 02:35 | requested the change.
| | 02:37 | If necessary you perform a
fifth step in which you update the
| | 02:41 | baseline documents.
| | 02:42 | For example, your project's schedule
might need new tasks added or deadlines
| | 02:47 | extended for specific tasks.
| | 02:50 | Finally, you track where
change requests are in your process.
| | 02:54 | You can use a change request log to
record the status of submitted change requests.
| | 02:59 | As a requests works its way through
the steps, you update the log with who is
| | 03:03 | in charge of the request, the impact estimate,
current status, and at the end, actual impact.
| | 03:10 | You don't have to send every
change request through the change
| | 03:13 | management process.
| | 03:14 | I recommend you set thresholds so team leads
can decide what to do with smaller requests.
| | 03:20 | Finally, it's also a good idea to have a
process for emergency changes that need
| | 03:26 | a rapid decision between
meetings of the change review board.
| | Collapse this transcript |
|
|
4. Building a Project ScheduleEstimating| 00:00 | Estimating time and cost accurately is
important because those estimates affect
| | 00:04 | your project's schedule and budget, which
in turn could determine whether it makes
| | 00:08 | sense to run the project.
| | 00:10 | If your estimates are low, a project
might get approved when another project
| | 00:14 | would deliver better results.
| | 00:16 | In addition, low estimates make
meeting expectations almost impossible.
| | 00:21 | If you estimate too high, a
worthwhile project might not be approved, or a
| | 00:26 | project could take longer and cost more
because people tend to take the time and
| | 00:30 | money you give them.
| | 00:31 | Estimating accurately is
challenging because estimates are nothing more
| | 00:35 | than educated guesses.
| | 00:36 | There are two things you
estimate in projects: time and cost.
| | 00:41 | For time, you need to estimate hours of
work, because labor costs are based on
| | 00:46 | the amount of the time people work.
| | 00:48 | In addition, other time-based resources
affect your cost, such as how long you
| | 00:53 | rent equipment or lease office space.
| | 00:55 | Second, you estimate costs that
aren't time-based, like materials you need
| | 01:00 | or travel required.
| | 01:02 | Having reliable people to
assist in estimating is crucial.
| | 01:05 | Typically, you work with a
project planning team made up of people
| | 01:09 | knowledgeable about the project.
| | 01:11 | This planning team helps you
develop your initial estimates.
| | 01:14 | Another option is to hire outside
experts to help you with estimating.
| | 01:19 | Later on, during the executing process,
you can obtain more accurate estimates
| | 01:24 | from the people assigned to do your
project work. They understand what has to be
| | 01:28 | done, know how long it will take them
based on their experience, and they are
| | 01:32 | more motivated to live up to
the estimates they have made.
| | 01:36 | When possible, base your estimates on the
results from similar projects that are complete.
| | 01:41 | If that isn't possible, there are
several techniques you can use for estimating.
| | 01:46 | With parametric models, you calculate
work and cost based on some measure, such as
| | 01:51 | the number of square feet for construction.
| | 01:53 | It's a pretty easy approach
because you can enter your numbers into a
| | 01:56 | spreadsheet or program and get a quick answer.
| | 01:59 | The disadvantage is that you can only
build a parametric model when you have
| | 02:02 | many similar projects in your database.
| | 02:05 | The program evaluation and review
technique abbreviated to PERT uses the best,
| | 02:10 | worst, and most likely
results to estimate a project.
| | 02:14 | It's a good approach if a project is
unfamiliar or has a lot of uncertainty.
| | 02:18 | Estimators think about what can go
wrong or right with tasks, which helps
| | 02:22 | produce better estimates.
| | 02:24 | The delphi technique counts on
several heads being better than one.
| | 02:28 | First, you ask several experts to
produce estimates independent of one another.
| | 02:33 | You then share the results with the
group, keeping the estimates anonymous.
| | 02:37 | You keep them anonymous, as you don't
want anyone to be influenced by the
| | 02:41 | reputation or authority of a co-expert.
| | 02:44 | You then ask each expert to estimate again.
| | 02:47 | Repeat this step a few more times and
then use the average of the last round as
| | 02:51 | your final estimated value.
| | 02:53 | You can estimate from the
top down or the bottom up.
| | 02:57 | Top-down estimating is effective for
large projects or early rough estimates.
| | 03:02 | You estimate phases or major
components and then break those estimates into
| | 03:06 | smaller pieces until you
get to individual tasks.
| | 03:10 | Estimating from the bottom up means you
estimate each task and then add them up,
| | 03:15 | until you have the
estimate for the entire project.
| | 03:18 | For large or complex projects, add
time for complexity, communication,
| | 03:23 | interactions, travel, management, and so on.
| | 03:26 | There is no good rule of
thumb for how much to add,
| | 03:29 | so you have to base your
increases on experience.
| | 03:32 | On the other hand, watch out for people
adding time to their estimates as a safety margin.
| | 03:37 | The best way to prevent these
issues is to set aside time and money
| | 03:41 | that everyone can share.
| | 03:42 | Contingency funds can be used if a task needs
more people to finish on time, for example.
| | 03:47 | You can use contingency time too.
| | 03:50 | In fact, critical chain project
management includes time buffers to help deliver
| | 03:55 | projects in less time than you could otherwise.
| | 03:59 | Consider the project you are working
on and decide which estimating method
| | 04:03 | makes the most sense.
| | 04:04 | Then identify the people
who can help you estimate.
| | 04:08 | Finally, ask management to set aside
contingency time and money so you can be
| | 04:12 | proactive for resolving problems that arise.
| | Collapse this transcript |
| Creating dependencies between tasks| 00:00 | A key part of building a schedule is
getting tasks in the right order. When
| | 00:04 | one task can start or finish is often
controlled by the start or finish of other tasks.
| | 00:09 | For example you have to create your
sales documents before you can print them.
| | 00:13 | By linking tasks, you turn a list of
tasks into a sequence that defines when
| | 00:18 | your project work will occur.
| | 00:20 | A task dependency is when one task
controls the timing of another task.
| | 00:25 | Because each task has a start and finish,
there are four types of task dependencies.
| | 00:31 | Finish-to-start
dependencies are the most common.
| | 00:35 | The finish of one task
controls when the other task starts.
| | 00:39 | For example, you have to finish a flight
reservation before someone can get on the plane.
| | 00:45 | With a start-to-start dependency, the start
of one task triggers the start of the other.
| | 00:50 | When the tradeshow starts, your sales
teams starts their presentations in the booth.
| | 00:56 | A finish-to-finish dependency means
the finish of one task controls the
| | 00:59 | finish of the other.
| | 01:01 | When the sales team finishes working
on their presentations, the graphics
| | 01:05 | department finishes their work on the materials.
| | 01:08 | Start-to-finish dependencies don't
occur very often. The start of one task
| | 01:14 | triggers the finish of another,
| | 01:16 | so in this case the task in
control occurs after the one it controls.
| | 01:21 | For example, the start of the
trade show breakdown determines when sales
| | 01:26 | presentations end, no matter
how interested the customers are.
| | 01:31 | You can figure out which type of
dependency to use by asking a few questions.
| | 01:36 | Which task controls the other? That tells you
which task is the first one in the dependency.
| | 01:43 | Does the start or finish date of the
first task control the second task?
| | 01:48 | That identifies whether the
dependency begins with the start or finish.
| | 01:52 | Does the first task control the
start or finish of the second task?
| | 01:57 | That identifies whether the second
half of the dependency is start or finish.
| | 02:02 | Task dependencies put tasks into sequence
so you can build your project's schedule.
| | 02:07 | Now that you are aware of the
different types, try to identify all the task
| | 02:11 | dependencies in your project.
| | Collapse this transcript |
| Understanding work, duration, and units| 00:00 | By understanding the relationship
between work, duration, and units, you can
| | 00:05 | assign people to work on tasks to
get the schedule the way you want.
| | 00:10 | Work, also called effort, is the number
of hours or days someone works on a task.
| | 00:17 | Duration is the length of time between
when a tasks starts and when it ends.
| | 00:22 | So, let's say you estimate that it
will take ten hours of work to print and
| | 00:27 | assemble sales packets to
be handed out a year event.
| | 00:31 | If you spend two hours per day,
then the duration is five days.
| | 00:35 | If you spend five hours per
day the duration is two days.
| | 00:40 | The work stays the same,
but the duration varies.
| | 00:44 | The term for the percentage of time a
person spends on a task is often called units.
| | 00:50 | In the project world, units are based on a
typical workday--eight hours in a lot of cases.
| | 00:55 | So when someone works full time,
eight hours a day, units are 100%.
| | 01:01 | Now let's look at what happens if
you work only two hours per day.
| | 01:05 | Two hours out of a possible
eight hours is 25% of each workday.
| | 01:11 | It's like you take a workday
and divided into four pieces.
| | 01:14 | So for your one workday task it's going
to take four pieces of the task to make
| | 01:20 | one full day's worth of work. Because
you work 25% of each day, you now have a
| | 01:26 | task four days long,
| | 01:28 | so your duration is four days.
| | 01:31 | If you assign more than one person to a task
you still change the units, but in this
| | 01:36 | case the duration of the task decreases.
| | 01:39 | For example, start with the same one-day task.
| | 01:44 | If you assign two people to the task,
they can each work at the same time.
| | 01:49 | That's like taking the one day and
dividing it into two half-day tasks.
| | 01:55 | By assigning two people to the task,
the duration shortens to half a day.
| | 02:00 | Then there are tasks that don't get
shorter no matter how many people you assign.
| | 02:05 | Meetings are the classic example.
| | 02:07 | A one-day meeting is one day,
whether three people attend or ten.
| | 02:13 | Because of the relationship between
duration, work, and units, you can assign
| | 02:17 | people in different ways to
make the schedule do what you want.
| | Collapse this transcript |
| Using milestones| 00:00 | Milestones get their name from the past,
when people placed stones by the side
| | 00:04 | of a road to mark each mile.
| | 00:07 | In projects, milestones do a similar job,
but they show progress and other key
| | 00:11 | project points rather than distance.
| | 00:14 | First, milestones are great as the first
and last tasks in your project's schedule.
| | 00:19 | By starting a project with a milestone,
you can easily reschedule the project
| | 00:24 | start date just by moving the
starting milestone to a later date.
| | 00:28 | The last task in a project's
schedule is almost always a milestone.
| | 00:32 | By looking at the final milestone, you
can tell whether the project is on time,
| | 00:36 | late, or ahead of schedule.
| | 00:38 | Second, milestones are great for
highlighting progress you've made in between
| | 00:43 | the project's start and finish.
| | 00:44 | When all the work leading up to that
milestone is done, you have the satisfaction
| | 00:49 | of marking off another milestone as complete.
| | 00:52 | Third, if you are waiting for someone
to deliver something, add a milestone
| | 00:56 | to flag that delivery.
| | 00:57 | Fourth, use a milestone to flag decisions
that determine what happens next in a project.
| | 01:04 | Or use a milestone for an approval
that determines when the work after
| | 01:08 | the approval can start.
| | 01:10 | Remember, milestones don't have any
duration, so you can add as many as you
| | 01:14 | want to your project without affecting
the amount of work or the duration of
| | 01:18 | the project.
| | Collapse this transcript |
| Making a realistic schedule| 00:00 | It's important to make your project's
schedule realistic so your project's actual
| | 00:04 | performance is as close as
possible to what you planned.
| | 00:08 | First, assign people to tasks using
the actual number of hours they work on
| | 00:12 | your project in a day.
| | 00:14 | People don't work 100% of
their time on their project tasks.
| | 00:18 | Other activities chew up time, such as
attending department meetings, filling
| | 00:23 | out timesheets, training, or time off.
| | 00:25 | Even walking across campus or
riding the elevator uses up work time.
| | 00:29 | So do your best to estimate the
actual number of hours people work.
| | 00:33 | Second, assign part-time workers using
the amount of time they are available.
| | 00:38 | Part-time workers don't work as many
hours in a week as fulltime workers,
| | 00:42 | so you have to increase task duration.
| | 00:45 | Third, adjust task hours based on
how fast the assigned workers are.
| | 00:49 | For example, if someone is a whiz with
building presentation on a computer, she
| | 00:54 | won't need as much time to build the
slide shows as someone who can't type.
| | 00:58 | Fourth, don't assign someone to work
on more than three tasks at a time.
| | 01:03 | Multitasking negatively affects productivity.
| | 01:06 | Switching between tasks means a person has to
switch focus, which introduces a small delay.
| | 01:11 | If a person is in great demand and
you have to assign him to several tasks,
| | 01:16 | adjust those assignments to
reflect his decreased productivity.
| | 01:20 | As you assign people to project tasks,
think about all of the factors that affect
| | 01:25 | people's productivity.
| | 01:26 | The closer you model your resource
assignments to reality, the easier it will be
| | 01:31 | to keep your project on time.
| | Collapse this transcript |
| Understanding the critical path| 00:00 | The critical path is a sequence of tasks
in your schedule with the longest duration.
| | 00:05 | The critical path is important because
any delay on that path delays the finish
| | 00:10 | date of the project.
| | 00:11 | Just as significant, you can shorten the
project's schedule if you can figure out
| | 00:15 | how to shorten the critical path.
| | 00:17 | So what makes tasks critical?
| | 00:20 | Put simply, they don't have any slack.
| | 00:23 | In project management, slack is also called float.
| | 00:26 | Just like a string without slack,
critical tasks have no leeway to move without
| | 00:31 | affecting the schedule.
| | 00:32 | For example, the develop handouts,
print handouts, and ship materials tasks all
| | 00:38 | occur one after the other, with no slack.
| | 00:41 | If any of these three tasks are
delayed, the finish date of the project
| | 00:45 | moves later in time.
| | 00:47 | Conversely, if a task has slack,
it can start later without delaying the
| | 00:52 | tasks that come after it.
| | 00:53 | For example, the print biz cards task
could delay as much as eight days before
| | 00:59 | it delays the project finished date.
| | 01:01 | Now let's look at how you
identify whether or not a task has slack.
| | 01:06 | A task has two sets of start and finish
dates that bracket when the task can occur.
| | 01:12 | The early start and early finish are
the earliest possible dates the task can
| | 01:16 | start or finish based on its
dependencies with other tasks.
| | 01:20 | For example, the print biz cards task
can start as early as August 10th and
| | 01:26 | finish on August 16th.
| | 01:29 | The late start and late finish are the
latest possible dates the task can start
| | 01:34 | and finish without delaying tasks that follow.
| | 01:37 | The late start and finish dates
are August 22nd and August 26th.
| | 01:43 | That means the task has eight working days
of slack and is not on the critical path.
| | 01:49 | On the other hand, if the early and
late dates are the same, there is no slack.
| | 01:54 | That's why print handouts
is on the critical path.
| | 01:58 | The good news is that you don't
have to perform these calculations.
| | 02:02 | When you use project scheduling
programs, they take care of figuring out the
| | 02:06 | critical path for you.
| | Collapse this transcript |
| Understanding the critical chain method| 00:00 | The critical chain is a slightly
different take on the critical path.
| | 00:04 | Using the critical chain approach, you
might be able to deliver your project
| | 00:08 | earlier then you would otherwise.
| | 00:10 | In addition, critical chain
techniques help you prevent delays in the
| | 00:14 | project finish date.
| | 00:15 | First, the critical chain approach
schedules tasks to occur as late as possible.
| | 00:21 | One benefit of doing this is you
don't spend money on the project until
| | 00:25 | you absolutely have to.
| | 00:26 | Because of this type of scheduling, you adjust
the schedule by moving tasks to occur earlier.
| | 00:33 | Second, critical chain focuses on
resource limitations to identify the
| | 00:37 | important tasks to manage.
| | 00:39 | That's because resource constraints
are often the toughest ones to deal with.
| | 00:44 | You start by scheduling the tasks with
the most limited resources, so you use
| | 00:49 | those people as effectively as possible.
| | 00:52 | Third, the critical chain uses buffers
to give a project breathing room, so it's
| | 00:57 | less likely to delay past its finished date.
| | 01:00 | The critical chain approach is like
adding shared time to the project.
| | 01:04 | Each task doesn't get its own time
buffer; instead, sequences of tasks share
| | 01:10 | a buffer. That way only the tasks that
actually need extra time use some of the buffer.
| | 01:16 | You apply a couple of
different types of buffers.
| | 01:19 | First, you add buffers at the
end of each sequence of tasks.
| | 01:23 | Second, you add a project buffer at
the end of the project to protect the
| | 01:27 | overall project finish date.
| | 01:29 | The critical chain approach helps deliver
projects on time or earlier than expected.
| | 01:35 | If you are interested in using this
method, I recommend you research it further
| | 01:39 | to learn how to put its
techniques into practice.
| | Collapse this transcript |
| Shortening a schedule| 00:00 | Stakeholders often ask you to
deliver projects earlier than the first
| | 00:04 | finish date you calculate.
| | 00:06 | In this video, I'll describe two
techniques for shortening your schedule:
| | 00:10 | fast-tracking and crashing.
| | 00:12 | With fast-tracking, you overlap tasks
that should occur one after the other.
| | 00:16 | Fast-tracking is fairly simple to do,
because you just overlap two tasks with
| | 00:21 | finish-to-start dependencies.
| | 00:23 | For example, if you want to finish
sales presentations more quickly, you can
| | 00:28 | schedule the graphic designers to
start designing graphics before the sales
| | 00:32 | people finish writing sales content.
| | 00:34 | The best tasks to fast-track
are tasks on the critical path.
| | 00:38 | That's because you shorten the project's
schedule when you shorten the critical path.
| | 00:43 | In addition fast-track the
longest tasks on the critical path.
| | 00:47 | They decrease the duration, while
introducing the fewest numbers of risks and
| | 00:51 | changes to the schedule.
| | 00:53 | The disadvantage is that
fast-tracking increases risk.
| | 00:56 | When you overlap tasks, work that's
already complete could be affected by a
| | 01:01 | decision that comes later, or
by the way other work is done.
| | 01:04 | For example, if the sales team makes
a major change in the concept for the
| | 01:09 | presentations, some of the
graphics work might have to be redone.
| | 01:13 | The second technique, crashing,
increases the cost of your project, because this
| | 01:19 | technique means you spend
additional money to shorten the schedule.
| | 01:23 | Usually the increased cost is for
additional people you put on your tasks.
| | 01:28 | Apply crashing to tasks on the
critical path. You don't want to spend money
| | 01:32 | shortening tasks that don't
shorten your overall schedule.
| | 01:36 | The key to successful crashing is
finding the alternative that shortens the
| | 01:41 | schedule the amount that you
need for the least amount of money.
| | 01:45 | First, you start with the
least expensive tasks to crash.
| | 01:49 | Then you crash tasks with higher price
tags, only until you've shortened the
| | 01:53 | schedule by the amount you need.
| | 01:56 | A crash table makes it easy to
see which tasks you should crash.
| | 02:00 | A crash table includes how much it
costs to crash each task on the critical
| | 02:04 | path, and the duration you
eliminate by crashing them.
| | 02:07 | Crash the tasks with lowest crash cost per week.
| | 02:11 | If tasks have the same crash cost
per week, crash the longer tasks first.
| | 02:15 | That way you crash the fewest number of tasks.
| | 02:19 | You can take crashing only so far.
| | 02:21 | At some point, adding more people
won't shorten the duration, because people
| | 02:25 | start interfering with one and another.
| | 02:27 | New people are often less productive
than existing team members until they
| | 02:31 | get up to speed and they slow down the existing
team members who have to help them get oriented.
| | 02:37 | Whether you fast-track or crash, keep in
mind that the critical path can change.
| | 02:43 | Some tasks might become non-critical
and others may turn into critical tasks.
| | 02:48 | Be sure to review the critical path
after every adjustment to make sure the next
| | 02:53 | task you work on is still on the critical path.
| | Collapse this transcript |
| Documenting a baseline| 00:00 | Once the customer and stakeholders have
approved the project plan, it's time to
| | 00:04 | save your project baseline.
| | 00:06 | A baseline is a collection of your
approved documents, budget, and schedule.
| | 00:10 | Your baseline is important because you
compare your progress to the baseline, to
| | 00:14 | see how the project is doing.
| | 00:16 | Everything that you include in the plan
baseline goes under your change control
| | 00:20 | process, so that any changes the
baseline show up as change requests.
| | 00:24 | How you save the baseline
depends on what you are saving.
| | 00:27 | First, save the baseline version of your
plan documents in your project notebook.
| | 00:32 | Then, as something changes, you flag
those changes in a revision of the
| | 00:36 | corresponding baseline document.
| | 00:39 | Second, baseline the values in your
project schedule. Project scheduling
| | 00:43 | programs typically provide a
feature for saving a baseline.
| | 00:47 | The baseline includes the approved
values for start and finish dates, task
| | 00:51 | duration, work, cost, and so on.
| | 00:55 | As you record your progress or make
changes to your schedule, the program can
| | 00:59 | compare the current values to the
baseline values, to show any differences.
| | 01:04 | After you save the project baseline,
you are ready to use it evaluate progress
| | 01:08 | and project performance.
| | Collapse this transcript |
|
|
5. Running a ProjectRunning a project| 00:00 | The executing process is like launching a
boat: the project finally gets underway.
| | 00:06 | The executing process starts with
lining up the people and other resources you
| | 00:10 | need to perform the project.
| | 00:13 | Once you get team members on board,
you help them get familiar with their
| | 00:17 | assignments in the overall project environment.
| | 00:20 | You also set up a place to store project
information and save a baseline of your
| | 00:24 | plan that you will use to
compare with actual performance.
| | 00:29 | Monitoring represents collecting
data about where the project stands.
| | 00:33 | Since projects never stick to the
plans you so carefully prepare, you have to
| | 00:37 | figure out how to respond to the
changes, surprises, and problems that arise.
| | 00:43 | Controlling is when you implement course
corrections to get your project back on track.
| | 00:48 | In this chapter, we'll discuss what
goes on during the executing process.
| | 00:53 | I will also talk about how to
monitor your project and share methods for
| | 00:57 | bringing a project back on
track if it diverges from your plan.
| | Collapse this transcript |
| Executing a project| 00:00 | The executing process starts when the
project plan has been approved and project
| | 00:05 | work can finally begin.
| | 00:07 | The first step in the executing
process is usually procurement.
| | 00:12 | You might work with a core team for
the initiating and planning processes,
| | 00:16 | but executing is when you bring on the
rest of the team and acquire equipment
| | 00:20 | and materials the project requires.
| | 00:23 | If team members come from within your
organization, procurement might be as
| | 00:27 | simple as telling your in-house
team that it's time to report for duty.
| | 00:32 | For resources outside your organization,
the procurement process includes a few
| | 00:37 | additional steps: solicitation,
evaluation, selection, contracting, and
| | 00:44 | ongoing management.
| | 00:46 | Solicitation often begins with a request
for proposal, abbreviated as RFP, which
| | 00:52 | is a typical way to ask
vendors for proposals or bids.
| | 00:56 | An RFP describes the services or
resources you need, when you need them, and your
| | 01:01 | budget for the work.
| | 01:02 | It's a good idea to include the
criteria you will use to select a vendor, so
| | 01:08 | companies can decide whether or not to bid.
| | 01:11 | In addition, include instructions and
the deadline for submitting a proposal and
| | 01:16 | the date you will announce your decision.
| | 01:19 | Once you have all the vendors' proposals
or bids, you hunker down and evaluate the
| | 01:23 | responses using the criteria you
identified. Then you select the winner.
| | 01:29 | The selection process depends on the
size and complexity of the project.
| | 01:33 | Evaluation and selection might be as
easy as filling in a spreadsheet with
| | 01:37 | ratings and choosing the
vendor with the highest score.
| | 01:40 | For large jobs, you might whittle the
submissions down to a short list of vendors
| | 01:45 | and ask each vendor in the second round
to prepare a more detailed presentation,
| | 01:50 | or demonstrate what they have to offer.
| | 01:52 | Contracting is when you prepare and
sign a contract for the resources you need.
| | 01:57 | A contract can be short and
sweet or long and complex.
| | 02:00 | It all depends on the project and the work.
| | 02:04 | Contracts usually include a
statement of work, terms and conditions,
| | 02:08 | deliverables, deadlines, and the price.
| | 02:12 | Contracts typically fall into several
categories. Fixed price contracts work
| | 02:17 | when your project is well defined.
| | 02:20 | This type of contract places the risk
on the vendor, because the vendor is paid
| | 02:24 | a fixed amount, no matter how much
time the work takes or how much it costs.
| | 02:29 | Time and materials contracts pay for
the time worked and expenses incurred.
| | 02:34 | The project accepts most of the risk,
so it's common to include a not-to-exceed-
| | 02:39 | a-value clause, so there
is a limit on the price.
| | 02:43 | A cost plus contract is like time and
materials with the addition of penalties
| | 02:47 | or rewards based on the vendor's performance.
| | 02:50 | And with a retainer, you agree to
pay for a specified amount of time and
| | 02:54 | define the work as you go.
| | 02:57 | Once you have your team assembled, hold a
kick-off meeting to introduce all the players.
| | 03:02 | The project's sponsor and customer
can describe the mission and get
| | 03:05 | everyone motivated.
| | 03:07 | You can review the project plan with
the team and explain how things will work,
| | 03:11 | such as how to communicate or
how change requests will be handled.
| | 03:16 | During executing, you also designate a
repository for information, generated while
| | 03:20 | you are running the project.
| | 03:22 | Although it's usually electronic, this
repository is called a project notebook.
| | 03:27 | Projects produce a mountain of
information: your project plan,
| | 03:31 | specifications, reports, and so on.
| | 03:35 | Many people need access to these files,
so be sure to set your project notebook
| | 03:40 | up where team members can get to it.
| | 03:43 | One last item before you dive into work:
establish a baseline for your approved
| | 03:48 | project plan and other project documents.
| | 03:50 | You can save baselines in your
project management software or save baseline
| | 03:55 | versions of plan documents.
| | 03:57 | That way as the project progresses, you
can measure any variance between your
| | 04:01 | plan and what actually happens.
| | Collapse this transcript |
| Understanding team dynamics| 00:00 | Developing your project team into a
finely tuned machine is important because
| | 00:05 | you will get more productivity from
your people and higher-quality results.
| | 00:10 | Bruce Tuckman's forming, storming,
norming, and performing is one model that
| | 00:15 | describes the typically
phases that teams go through.
| | 00:18 | The first team stage is called
forming, because the individuals are just
| | 00:23 | starting to form into a team.
| | 00:25 | They aren't yet sure of their goal as a
team, and they don't know who does what.
| | 00:30 | During the forming stage, you have
to define the team's goals clearly and
| | 00:35 | give them direction.
| | 00:37 | Like other youngsters, teams in
the forming stage tend to resist and
| | 00:41 | challenge authority,
| | 00:42 | so be prepared to answer their
questions and earn their respect.
| | 00:46 | Storming is the second stage. As
team members start to work out the
| | 00:51 | relationships with each other,
power struggles often occur.
| | 00:55 | Storming teams have difficulty making
decisions because of disagreements.
| | 01:00 | At the same time, those
disagreements lead to communication, which helps
| | 01:04 | members grow as a team.
| | 01:07 | When a team is storming, you have to
help the team members stay focused on their
| | 01:11 | goals and help them make the decisions.
| | 01:14 | After the storm is over, you finally have a team.
| | 01:18 | Teams don't always reach the performing
stage, but if they do, it's pretty impressive.
| | 01:24 | They know what they are supposed to
accomplish, who is supposed to do what, and
| | 01:28 | they often get things done very
quickly, all without any help from you.
| | 01:33 | You only have to step in if the team asks.
| | Collapse this transcript |
| Managing team resources| 00:01 | As a project manager, you have to
motivate the people who work on your project.
| | 00:05 | In this video I'll share with you eight
methods you can use to strengthen your
| | 00:09 | working relationships and
motivate your team members.
| | 00:13 | First, communicate roles and
responsibilities clearly to your team members.
| | 00:19 | You can build your relationships
with your team members by helping them
| | 00:23 | understand what they are
responsible for and what you expect of them.
| | 00:26 | Second, give people
specific and achievable goals.
| | 00:32 | Challenging, though achievable
goals can be very motivating.
| | 00:37 | Team members usually dig deeper to
respond to the challenges you set.
| | 00:42 | Third, provide support and help
remove obstacles that get in the way.
| | 00:47 | If your people can't resolve issues or
remove obstacles, help them in any way you can.
| | 00:54 | That way they can focus on the
work that they are supposed to do.
| | 00:57 | Fourth, respect your people.
| | 01:00 | They are crucial components to your
project, because project work wouldn't
| | 01:05 | get done without them.
| | 01:07 | Being respectful builds good
relationships, motivates your people, and helps you
| | 01:12 | get the best your team has to offer.
| | 01:14 | Fifth, provide feedback quickly.
| | 01:19 | Providing positive reinforcement helps
build rapport and ensures that people do
| | 01:23 | more of what works well.
| | 01:25 | If someone does something wrong, jump
in quickly to explain what they should be
| | 01:30 | doing in a tactful way.
| | 01:33 | Sixth, consistently tell the truth.
| | 01:35 | You'll earn people's trust by telling
the truth, even if they don't like what
| | 01:39 | they hear. If you can, explain why you are
making the requests or decisions that you do.
| | 01:45 | Seventh, communicate
regularly with team members.
| | 01:50 | Status and lessons-learned meetings are
great ways to find out about what people
| | 01:54 | are doing and how well they are doing it.
| | 01:57 | And of course, comparing their
progress on their assignments to the baseline
| | 02:01 | shows whether there are as
productive as they should be.
| | 02:05 | Finally, handle people
problems quickly if they do come up.
| | 02:10 | The answer could be as easy as telling
someone what they are supposed to do or
| | 02:13 | explaining the effect they are having on others.
| | 02:16 | It is important to be upfront, while at
the same time being tactful and respectful.
| | 02:22 | If it turns out that someone
isn't qualified to perform his or her
| | 02:25 | assignments, you can consider adding
time or money or finding other people to
| | 02:31 | help or even take over.
| | 02:33 | In this situation, look at your work
packages and request to functional managers
| | 02:38 | to make sure you define them clearly.
| | 02:41 | If you have to replace someone, work with
the functional manager to get someone else.
| | 02:45 | If you can't replace the person,
you might have to reset stakeholders'
| | 02:49 | expectations for schedule,
budget, scope, or quality.
| | 02:54 | Leadership is one of the most
important characteristics of a project manager.
| | 02:59 | By using the techniques described in
this video, you can build effective working
| | 03:03 | relationships and motivate your people.
| | Collapse this transcript |
| Gathering data| 00:00 | Once work begins on your project, you
need information about what's been done
| | 00:05 | and what's left to do, so you can see whether
your project is progressing the way it should.
| | 00:10 | The data you need depends on what the
customer and other stakeholders consider
| | 00:14 | important. Because schedule and budget
usually top the list, information about
| | 00:19 | hours worked and money spent are givens.
| | 00:22 | First, find out when tasks actually start.
| | 00:26 | A task can take the work hours you
estimated, but if it starts two weeks late,
| | 00:30 | it could delay your project.
| | 00:32 | Second, gather actual work hours,
or in some cases, actual duration.
| | 00:39 | Tracking hours work is more effort,
but you get a better picture of task
| | 00:43 | progress and the labor
costs associated with the work.
| | 00:47 | Third, ask how much work
or duration still remains.
| | 00:52 | These values not only tell you how much
longer a task will run, but also whether
| | 00:57 | or not your original estimate was on target.
| | 01:00 | If possible, set up an automated way to
obtain the information you need about
| | 01:05 | tasks, such as through email, a web
form, or an enterprise-wide project-
| | 01:11 | status reporting tool.
| | Collapse this transcript |
| Evaluating progress| 00:00 | Once you've collected data from
your team, you can evaluate your
| | 00:03 | project's progress.
| | 00:05 | You have to look at your project from
several angles to uncover problems and
| | 00:09 | figure out what to do about them.
| | 00:12 | First, examine the project's schedule,
because delays can lead to other problems.
| | 00:17 | Compare the current
schedule to your original plan.
| | 00:21 | Looking at a Gantt chart helps you see
whether tasks are ahead of, behind, or
| | 00:26 | right on schedule, and by how much.
| | 00:28 | For example, by showing your original
baseline schedule with bars in one color
| | 00:34 | and your current schedule with another color.
| | 00:37 | Variance values tell you the exact
difference between your baseline and
| | 00:41 | your current schedule.
| | 00:43 | It's helpful to home in on problem tasks.
| | 00:47 | If you use a scheduling program, there
are often filters and views that provide
| | 00:51 | early warnings of delays.
| | 00:53 | Next, look at cost. Cost issues can
arise if tasks take more hours to complete,
| | 01:00 | but cost increases can also occur due to
higher resource costs or paying overtime.
| | 01:06 | Cost variances show the difference
between your baseline costs and the
| | 01:10 | current scheduled costs.
| | 01:12 | If you want some practical tips for
how to evaluate progress using Microsoft
| | 01:16 | Project, check out Chapter 8,
Viewing and Sharing Project Information in
| | 01:22 | my Project Essential Training course,
here on the lynda.com Online Training Library.
| | Collapse this transcript |
| Understanding earned value analysis| 00:00 | Earned value analysis evaluates how
much a project has earned based on work
| | 00:05 | that's been completed.
| | 00:06 | In other words, a project
earns value by completing work.
| | 00:11 | You'll truly appreciate earned value
when you understand how basic project
| | 00:16 | measures can be deceiving.
| | 00:18 | Suppose 50% of your project's
duration has come and gone and 50% of the
| | 00:23 | budget has been spent.
| | 00:25 | Sounds like things are right on track.
| | 00:27 | However, if only 25% of the work
is complete, you have a problem.
| | 00:33 | You have to finish 75% of the work, but
with only 50% of the duration and with
| | 00:39 | 50% of the money left.
| | 00:42 | There is a good chance that won't happen.
| | 00:44 | Earned value analysis can uncover
problems like that because of the way it looks
| | 00:49 | at work and cost over time.
| | 00:51 | It presents your schedule
and budget in monetary terms.
| | 00:56 | That means you see all aspects of your
projects performance in the same units.
| | 01:00 | Of course, costs are in monetary terms,
but you measure work in terms of money
| | 01:06 | by calculating how much it costs
for people to perform the work.
| | 01:11 | Earned value analysis is
based on three measures.
| | 01:15 | First, you measure planned value.
| | 01:18 | That's how much you plan to spend to
complete the work scheduled through the status date.
| | 01:24 | You might hear it called
budgeted cost of work scheduled.
| | 01:28 | Second, earned value is the amount of
money you've earned by completing work.
| | 01:34 | You may hear earned value called
budgeted cost of work performed.
| | 01:40 | The third key measure is the
actual cost for the completed work.
| | 01:44 | Looking at these values in a graph
makes it easy to see whether your project is
| | 01:48 | on schedule and within budget.
| | 01:51 | Here is how you read an earned value graph.
| | 01:54 | First, time is along the horizontal
axis and cost is on the vertical axis.
| | 02:01 | Second, you want to see
earned value above planned value.
| | 02:05 | That means you've completed
more work than you planned.
| | 02:09 | In others words, the task or
project is ahead of schedule.
| | 02:13 | In this example earned
value is below planned value,
| | 02:17 | so this project is behind schedule.
| | 02:21 | Third, you want to see
actual costs below earned value.
| | 02:25 | That means you have actually spent less for
the work you've completed than you estimated.
| | 02:31 | In this project, actually cost is above
earned value, so the project is also over budget.
| | 02:37 | Earned value analysis includes more
measures that are helpful for evaluating
| | 02:41 | your project's performance that I
haven't described in this video.
| | 02:45 | If you are interested in using
earned value measures on your projects, I
| | 02:49 | recommend that you
research this tool in more detail.
| | Collapse this transcript |
| Reporting on progress| 00:00 | As project manager, you are always
communicating what's going on to other people,
| | 00:05 | like team members who do work or
stakeholders who want to know status.
| | 00:09 | To make sure that you tell people what
they need to know when they need to know
| | 00:13 | it, you have to set up a reporting system.
| | 00:17 | A good reporting system provides
accurate and meaningful information in a timely
| | 00:22 | fashion without making data collection a burden.
| | 00:26 | During the planning process
you created a communication plan.
| | 00:30 | In that plan you identified your
audiences and determined how you were going to
| | 00:34 | communicate with them.
| | 00:36 | Now that you are putting the plan into
action, first gather the information you
| | 00:41 | need from your team.
| | 00:43 | The most common frequency is once a week.
| | 00:45 | For example, you ask your team for
status midday on Fridays and then produce
| | 00:51 | reports for that week's accomplishments.
| | 00:54 | Then produce and distribute reports to
the audiences you identified and using
| | 00:59 | the methods you chose.
| | 01:00 | For example, status reports
usually cover what's happened:
| | 01:05 | the work that was scheduled, work
that was completed, and work that didn't
| | 01:10 | go according to plan.
| | 01:12 | Report any variances and
how you plan to correct them.
| | 01:16 | In addition, report problems or
issues, along with the steps you plan to
| | 01:20 | take to resolve them.
| | 01:23 | For the management team you might
prepare a cumulative status report that shows
| | 01:27 | what's happened up through the status date.
| | 01:30 | That helps management focus on
the big picture of the project.
| | 01:34 | You can produce additional
reports if they ask for details.
| | 01:39 | Dashboards have become popular
because they show information graphically and
| | 01:43 | make it easier to see what's going on.
| | 01:45 | For example, you can flag
progress with stoplights.
| | 01:49 | A green light says everything is fine,
a yellow light shows a small variance,
| | 01:55 | and a red light indicates a larger problem.
| | 01:57 | Now that you are using your
communication plan, your audiences may ask for
| | 02:02 | different information, a different
schedule, or different communication methods.
| | 02:07 | Don't hesitate to adjust your
reporting system to ensure that your project
| | 02:12 | communication is as effective as possible.
| | Collapse this transcript |
| Understanding financial measures| 00:00 | In this video I'll explain some of
the more common financial measures
| | 00:04 | organizations use to
evaluate project performance.
| | 00:08 | That way as you run your
project you can make sure you're meeting
| | 00:12 | management's expectations.
| | 00:14 | Financial calculations for projects
are known as capital budgeting analysis.
| | 00:18 | These measures look at the return
on the money invested in a project.
| | 00:23 | You need to know how much a project
costs, how much the project saves or earns,
| | 00:29 | and when money flows in or goes out.
| | 00:33 | After you build your project's schedule, you
have the information on costs and their timing.
| | 00:39 | The income and its timing usually
come from whoever proposes the project.
| | 00:45 | The payback period is how long a
project takes to earn back the money invested.
| | 00:50 | The project cost $100,000 and it
brings in sales of $10,000 per month,
| | 00:56 | so the payback period is ten months.
| | 01:00 | The payback period looks better for
projects that generate money early on.
| | 01:06 | Another potential problem is that
payback period assumes that the project makes
| | 01:10 | money long enough to pay back the money spent.
| | 01:14 | Net present value, or NPV, is more
accurate measure, because it uses the
| | 01:20 | time value of money.
| | 01:22 | The buying power of money decreases
over time because of inflation, which is why
| | 01:27 | money in the future is
worth less than money today.
| | 01:31 | You set a target rate of return and
NPV uses costs and the income to calculate
| | 01:37 | whether your project meets, exceeds,
or falls short of the target return.
| | 01:43 | Another financial measure is internal
rate of return, or IRR, which shows the
| | 01:49 | annual return, taking into
account the time value of money.
| | 01:53 | It's like the annual percentage
yield you earn in a bank account.
| | 01:56 | If the IRR exceeds your target
return, the project makes financial sense.
| | 02:02 | Keep in mind IRR is great when the
direction of money switches only once.
| | 02:07 | For example, when you have expenses
during the project and then income after that.
| | 02:14 | But if cash flows switch back and forth
between positive and negative, you might
| | 02:18 | get the wrong answer.
| | 02:20 | Due to the scope of this course, I've
briefly touched on financial measures.
| | 02:25 | If this is a topic that interests, you I
highly recommend you do more research.
| | Collapse this transcript |
| Communicating effectively| 00:01 | As a project manager, you have to
communicate with people at all levels, from the
| | 00:05 | customer and the management team
to the people who do project work.
| | 00:09 | Communication isn't just
telling someone something.
| | 00:12 | It's about getting a message across so
the other person understands it and often
| | 00:17 | does something with it.
| | 00:19 | Good communication skills help you and
your team gets more and better work done.
| | 00:25 | First, it's up to you to get your point across.
| | 00:29 | Start by telling your audience
why your message is important.
| | 00:32 | That gets their attention
so they receive your message.
| | 00:35 | Second, get to the point.
| | 00:39 | That way you get through, even if your
time is limited or your audience has a
| | 00:43 | short attention span.
| | 00:45 | Third, tailor your message to your audience.
| | 00:49 | This means focus on what is relevant to your
audience and use terms that they understand.
| | 00:54 | Fourth, be positive and proactive.
| | 00:58 | If you have to discuss a problem, state
the problem and then your plan to handle it.
| | 01:04 | Here are some tips for improving communication.
| | 01:08 | Listening is as important as talking.
| | 01:11 | When you are the audience, pay full
attention to the person talking to you.
| | 01:15 | No cell phones, no text messages, no emails.
| | 01:18 | It's tough, but worth practicing.
| | 01:20 | You'll get a lot more done.
| | 01:23 | Watch for unspoken communication.
| | 01:26 | In person, watch body
language and facial expressions.
| | 01:29 | On the phone, listen for
intonations in someone's voice.
| | 01:33 | Choose face-to-face meetings for
difficult, delicate, or crucial information, so
| | 01:38 | you and your audience can receive spoken
and unspoken messages. Keep an open mind.
| | 01:45 | Conversation or meetings are a waste if you
aren't going to listen to what other people say.
| | 01:51 | To improve understanding, paraphrase what
you've heard or ask the other person to do that.
| | 01:56 | By putting the information in your
own words, you demonstrate that you
| | 02:01 | do understand and you give the other person
a chance to correct you if you misunderstood.
| | 02:07 | Finally, use email effectively.
| | 02:10 | It's fast and easy, but
it presents challenges too.
| | 02:14 | Like other communication, take time to
write a clear and effective message.
| | 02:19 | It saves time and reduces
back-and-forth email volleys.
| | 02:23 | Use informative subject lines.
| | 02:26 | If you are asking for action and have a
deadline, include those in the subject.
| | 02:31 | Start with the point.
| | 02:33 | Start with what you want and what's
important and then backfill with the detail.
| | 02:38 | A good email is like a newspaper
article which presents key information in
| | 02:42 | the initial paragraph.
| | 02:45 | Proofread your messages.
| | 02:47 | Spelling or editing mistakes and
grammatical errors can radically change the
| | 02:51 | meaning of a message.
| | 02:52 | Confirm that your emails arrive.
| | 02:55 | If you don't get a response, follow
up with another email, call, or visit.
| | 03:01 | Be careful with humor, because
it doesn't work well in email.
| | 03:05 | Use humor only with people you know
well and let people know you are doing it.
| | 03:10 | Remember, good communication is
something that you have to work at constantly,
| | 03:15 | but by doing so, you and your
team will work more effectively.
| | Collapse this transcript |
| Running meetings effectively| 00:00 | Meetings chew up time and energy that
people could be using to get project
| | 00:04 | work done, and because meetings include
several people, they rack up costs more
| | 00:09 | quickly than other work. But sometimes
they are the best way to work and communicate.
| | 00:15 | So if you do hold a meeting, make it count.
| | 00:18 | The first step to a productive meeting is
to know what you are trying to accomplish.
| | 00:22 | Identify the purpose of the meeting
and the results you are trying to obtain,
| | 00:27 | such as approval to move
forward or to resolve an issue.
| | 00:29 | Second, create an agenda.
| | 00:32 | You can use an agenda to
make sure you cover every item,
| | 00:37 | keep the discussion on topic,
and to finish for meeting on time.
| | 00:41 | On your agenda list the topics to
discuss. Include your time estimate for
| | 00:47 | each topic. The more people you have in a
meeting the harder it is to get things done.
| | 00:53 | The third step is to limit the
attendees to the people you need to
| | 00:57 | accomplish your goal.
| | 00:58 | Fourth, give attendees a chance to prepare.
| | 01:04 | Schedule the meeting when it works
for the attendees and send the meeting
| | 01:07 | invitation ahead of time.
| | 01:09 | Fifth, start and finish meetings on
time, even if all attendees aren't there.
| | 01:17 | Don't backtrack when people show up late.
| | 01:20 | Sixth, facilitate the meeting
to keep everyone focused on the
| | 01:23 | meeting's objectives.
| | 01:26 | As project manager, you
have lots to do in a meeting.
| | 01:29 | If possible, ask someone
else to be the facilitator.
| | 01:34 | The facilitator kicks off the meeting
with a brief introduction, the purpose
| | 01:38 | of the meeting, the agenda topics, the
attendees, and the ground rules for interaction.
| | 01:44 | Seventh, take good meeting note.
| | 01:47 | How else will you know decisions you've
reached, action items you've identified,
| | 01:52 | and who is responsible for them?
| | 01:54 | During a meeting, you can document
points on a white board or a flipchart.
| | 01:59 | If possible, appoint someone to take notes.
| | 02:03 | After the meeting, you can edit the
notes, call out action items, who is
| | 02:07 | responsible, and when items are due.
| | 02:11 | Distribute the notes to attendees
and anyone else who needs to know.
| | 02:15 | Finally, if you would like to further
explore this topic, I recommend you watch
| | 02:20 | Dave Crenshaw's course Effective
Meetings in the online training library.
| | Collapse this transcript |
| Getting a project back on track| 00:00 | A project is a balancing act trying
to maintain equilibrium between scope
| | 00:05 | schedule, cost, and quality,
and sometimes other measures.
| | 00:10 | In this video, I'll discuss how to make
changes when this project goes off course.
| | 00:15 | First, consider solutions you can authorize.
| | 00:20 | You can proceed with your
changes without asking for permission.
| | 00:23 | For example, if you shuffle task
assignments to complete work more quickly or at
| | 00:29 | lower cost, you don't affect
anyone outside the project.
| | 00:33 | You can reassign without
waiting for someone to say okay.
| | 00:37 | Second, if you don't have enough
authority, asks stakeholders for approval.
| | 00:42 | Options like lengthening the schedule,
increasing the budget, or reducing scope
| | 00:47 | typically require approval from the
customer, stakeholders, or management team.
| | 00:53 | If you ask for permission, be ready to
present one or more recommendations, along
| | 00:57 | with the pros and cons of each one.
| | 01:00 | You also have to be ready to answer
questions about the solution you recommend
| | 01:05 | and the other solutions you
considered, but ruled out.
| | 01:09 | Finally, if your organization runs a
portfolio of projects, you might have to go
| | 01:14 | beyond your project stakeholders.
| | 01:16 | For example, if you need people from
other projects or contingency funds, you
| | 01:21 | will probably have to go to the management
team to ask for the people or money you need.
| | 01:26 | No matter how well you manage your projects,
you'll have to make changes from time to time.
| | 01:32 | By managing your projects well, you'll
have a better chance of receiving the
| | 01:36 | support you need from
stakeholders or management.
| | Collapse this transcript |
| Managing change, risk, and quality| 00:00 | During the planning process, you
created plans for how you would manage
| | 00:04 | changes, risks, and quality.
| | 00:07 | Now that the project is in progress,
you perform the steps in those plans to
| | 00:11 | manage changes, handle the risks
that occur, and control quality.
| | 00:17 | First, when change requests come in,
follow the steps in your management plan to
| | 00:23 | determine whether you
should add them to your plan.
| | 00:26 | Remember, you add every change request
that's made to a change request log so
| | 00:31 | you can track the request, whether
it's denied by the change review board or
| | 00:36 | approved, and add it to your plan.
| | 00:39 | When you developed your risk
management plan, you identified the risks to
| | 00:43 | monitor and the response
you would use to handle them.
| | 00:47 | Now that the project is under way, you
or someone you delegate keeps an eye on
| | 00:51 | each risk you are tracking and
regularly updates risk status.
| | 00:56 | Sometimes risks go away as the
project progresses and you can close them.
| | 01:02 | Other times unexpected risks occur.
| | 01:05 | If a risk occurs, launch the response
you chose in your plan. Then track the
| | 01:11 | results of that response.
| | 01:14 | You also perform activities to measure
quality and evaluate the level of quality
| | 01:18 | your project is delivering.
| | 01:20 | Those activities depend on the project.
| | 01:23 | If quality isn't at the level you
require, determine how to improve it.
| | 01:28 | If results are of the required quality,
review your processes to see if you can
| | 01:33 | achieve that quality more easily.
| | 01:36 | Remember, managing change, risk,
and quality isn't a one-time effort.
| | 01:42 | While your project is running,
continuously watch for change request, monitor
| | 01:46 | risks, and measure quality.
| | Collapse this transcript |
|
|
6. Closing a ProjectClosing a project| 00:01 | When you complete your project's
deliverables you might think the project is
| | 00:04 | finished, but you have several
activities to perform before you can even
| | 00:08 | call the project done.
| | 00:10 | The most important part of the closing
process is getting the customer to agree
| | 00:15 | that the project completed successfully.
| | 00:16 | Second, you document the
lessons learned during the project.
| | 00:22 | You can improve the performance of
future projects by identifying what worked
| | 00:26 | well, what didn't, and how
things could have been done better.
| | 00:31 | Third, you produce final documentation
and a closeout report for your project.
| | 00:36 | Finally, it's time to close the contracts,
archive your project information where
| | 00:42 | others can get to it, and see your
project team off to their next assignments.
| | 00:48 | In this chapter, I'll describe each
of these activities in more detail.
| | Collapse this transcript |
| Gaining customer acceptance| 00:00 | Obtaining customer acceptance is
absolutely essential, because without acceptance,
| | 00:05 | you simply aren't done.
| | 00:07 | During initiating and planning you
should have documented your deliverables and
| | 00:12 | defined success criteria that
are both clear and quantifiable.
| | 00:16 | You used the success criteria
developed during planning to design acceptance
| | 00:20 | tests, which demonstrate whether the
deliverables do what they're supposed to.
| | 00:25 | You also worked with the customer and
other stakeholders to document acceptance
| | 00:29 | procedures for running your tests.
| | 00:32 | For example, a software project might
include features to speed up a business
| | 00:37 | process. To measure success, you set up a
test environment that mimics production
| | 00:42 | and then run test cases to evaluate
whether the software decreases processing
| | 00:47 | time by the required amount.
| | 00:49 | After you successfully complete
the acceptance tests, hold a brief but
| | 00:54 | important signoff meeting to get the
signatures you need from the customer and
| | 00:58 | any other stakeholders.
| | 01:00 | Obtaining customer acceptance is a
huge milestone and worthy of a celebration,
| | 01:05 | but you have a few more steps before
you can complete the closing process.
| | 01:09 | The rest of the videos in this
chapter explain what's still left to do.
| | Collapse this transcript |
| Documenting lessons learned| 00:00 | Learning lessons from what goes well
and what could have gone better is a great
| | 00:04 | way to improve your performance in the future.
| | 00:07 | With those lessons in hand, you focus on
repeating your successes and improving
| | 00:12 | on your less-than-stellar performance.
| | 00:15 | In this video, I'll share with you
several techniques you can use to coax this
| | 00:19 | crucial info out of your team members.
| | 00:22 | Then you document the lessons you
identify for the benefit of future projects.
| | 00:27 | First, schedule time for
regular lessons-learned sessions.
| | 00:32 | Don't wait until the end of the
project to ask about lessons learned.
| | 00:36 | By then your team members have
already forgotten a lot of them.
| | 00:40 | Set aside time in the agenda of your
status meetings to ask team members for
| | 00:44 | lessons learned, or schedule dedicated
meetings for the topic every few weeks.
| | 00:50 | Second, keep lessons-learned
sessions positive and productive.
| | 00:56 | Start with what went right. Ask each
person for a tip or technique that helped
| | 01:01 | them in their work, such as what saved
you the most time recently or what was the
| | 01:06 | gnarliest challenge you
solved and how did you do it?
| | 01:09 | Then progress to lessons
from the problems people faced.
| | 01:13 | Pose questions about
problems in a positive light.
| | 01:16 | For example, how can we make the sales
presentations more compelling, or what
| | 01:22 | would you do differently next time?
| | 01:25 | Ask team members to talk about
themselves. That way it's easier to prevent
| | 01:29 | people from blaming others.
| | 01:31 | Third, give people the
opportunity to be open and honest.
| | 01:36 | Try scheduling meetings without
managers to see if people will share
| | 01:40 | information more freely.
| | 01:42 | Consider including an anonymous
method for submitting lessons learned, such
| | 01:47 | as a suggestion box.
| | 01:49 | This approach can be helpful for
sensitive issues or when people are afraid to
| | 01:53 | admit mistakes for fear of losing their jobs.
| | 01:56 | Fourth, document lessons learned.
| | 02:00 | I suggest you put them in your
project notebook, but you can also set up a
| | 02:05 | repository so everyone in your
company can learn what you already know,
| | 02:08 | for example, a web page with frequently asked
questions, tips and tricks or a knowledge base.
| | 02:16 | By making lessons learned an
important part of your process, you give
| | 02:20 | your organization and yourself the
opportunity to learn and grow with each
| | 02:25 | new project.
| | Collapse this transcript |
| Preparing a close-out report and archiving| 00:00 | Part of the closing process is
preparing a closeout report, which is like a
| | 00:05 | final status report.
| | 00:07 | A closeout report is important
because it sums up the project in a concise
| | 00:12 | informative document: what the project did,
how it did it, and how well it went.
| | 00:18 | The first item in a
closeout report is the bottom line.
| | 00:22 | Was the project a success?
| | 00:24 | You might the think the answer is
simple yes or no; instead, summarize the
| | 00:28 | quantitative results you achieved.
| | 00:31 | Second, include the final cost of the
complete project, because stakeholders
| | 00:36 | typically care about this value.
| | 00:39 | Depending on the stakeholders, you might
include cost for major portions of the
| | 00:43 | project, cost variances, return on
investment, and other financial measures.
| | 00:50 | Third, document the delivery dates for
the entire project and key milestones.
| | 00:56 | If the project was significantly early
or late, include the variances from your
| | 01:01 | original dates and the reasons.
| | 01:04 | That helps publicize ways to
improve estimates on future projects.
| | 01:09 | Fourth, summarize any significant changes.
| | 01:13 | For example, if the project didn't
deliver everything on the scope statement,
| | 01:18 | include the scope that was and wasn't delivered.
| | 01:22 | Next, consider including information
you want to share with others, such as
| | 01:27 | lessons learned or significant risks
and issues, and how you handled them.
| | 01:33 | For risks, describe how you
handled them and the results.
| | 01:38 | You can also point out risks that
occurred that weren't identified in the
| | 01:42 | initial risk management plan, so
others don't miss them in the future.
| | 01:47 | Finally, end with a section about
the effectiveness of your project
| | 01:51 | management practices.
| | 01:53 | Similar to lessons learned, you can
describe what worked well and how you would
| | 01:57 | plan and manage it differently in the future.
| | 02:00 | That way other projects can
benefit from your experience.
| | 02:04 | It's important to archive
detail about your project.
| | 02:08 | Archiving information
electronically makes it easier to find later on.
| | 02:13 | There is no need to store shelf
after shelf of ring binders or a leaf-
| | 02:17 | through page after page.
| | 02:19 | Once you prepare your closeout report
and tuck your project information away in
| | 02:24 | its archive, you're ready for closure.
| | Collapse this transcript |
| Closing contracts and accounts and transitioning| 00:00 | At the very end of a project, you have a
few pesky but important details to tie up.
| | 00:06 | First, close the contracts you signed.
| | 00:09 | If your project included a contract
with the customer, signatures on the
| | 00:13 | customer acceptance form are a key to
agreeing that the contract is complete.
| | 00:19 | Depending on the contract's terms, you
might have a few other things to do, such
| | 00:23 | as support the project's deliverables
or perform a follow-up in a few months.
| | 00:29 | If you set up contracts with vendors
or contractors, confirm that the other
| | 00:33 | parties did what they were supposed to
do. Then you perform the steps to close
| | 00:38 | those contracts as well.
| | 00:39 | Second, close the accounts you
used to build the project costs.
| | 00:45 | For most projects you keep the
financial books open for a short time, usually a
| | 00:50 | few months after the project is
complete. That way it's easy to process
| | 00:55 | follow-on expenses, such as support.
| | 00:58 | One way to prevent erroneous charges is
to close all the accounting codes except
| | 01:03 | for the ones related to
the follow-up activities.
| | 01:06 | As project manager, help your people
transition to their next assignments.
| | 01:11 | The best way to do this is to give
functional managers advanced notice that their
| | 01:16 | people will be available.
| | 01:18 | Then the managers can find new
assignments and plan the transitions.
| | 01:23 | If your project has another group that
picks up where your project team leaves
| | 01:28 | off, you have to perform that transition too.
| | 01:31 | For example, a manufacturing group
that builds a product or the support team
| | 01:37 | that answers customers' questions
needs to know a lot of information from
| | 01:41 | your finished project.
| | 01:43 | Finally, your project truly is complete
and your assignment as project manager
| | 01:49 | is over. Now it's time to
move to your next project.
| | Collapse this transcript |
|
|
ConclusionWhat's next?| 00:00 | In this course I've covered the
major processes of project management and
| | 00:04 | explained many techniques for
managing projects effectively;
| | 00:08 | however, there are many sources of
information you can explore to learn more.
| | 00:13 | Here are a few books I recommend.
| | 00:16 | My book, Successful Project Management:
| | 00:18 | Applying Best Practices and Real-World
Techniques with Microsoft Project, covers
| | 00:23 | both project management and how to use
Microsoft Project and other programs to
| | 00:28 | perform many of your day-to-day tasks.
| | 00:31 | It comes with examples and templates you
can download to use on your own projects.
| | 00:36 | I also recommend Project Planning,
Scheduling and Control by James P Lewis. It's
| | 00:42 | engaging, easy to read, and
filled with useful information.
| | 00:46 | Making Things Happen by Scott Berkun
is a practical and pragmatic guide to
| | 00:52 | getting the right things
done in the right way. Mr.
| | 00:55 | Berkun offers plenty of real-world
examples from his career of managing projects.
| | 01:00 | The Project Management Institute is a
not-for-profit organization that advocates
| | 01:05 | the project management profession.
| | 01:07 | PMI has several levels of
certification, such as the project management
| | 01:12 | professional, or PMP.
| | 01:14 | To obtain your certification you have
to have a number of hours of experience,
| | 01:19 | complete accredited training,
and pass a certification exam.
| | 01:24 | Prince2 is another project
management methodology, which originated in
| | 01:28 | the United Kingdom.
| | 01:30 | The Prince2.com web site
includes links for training options.
| | 01:34 | You can also become
certified in this methodology.
| | 01:38 | Many colleges and universities now
offer certificates and degrees in
| | 01:42 | project management.
| | 01:44 | You can find accredited degree
programs in project management on the Project
| | 01:48 | Management Institute web site.
| | 01:51 | I recommend that you apply the skills
you've learned from this course and then
| | 01:55 | in a few months, come back and watch it again.
| | 01:58 | You'll find that becoming a successful
project manager is a learning experience
| | 02:02 | that can last a lifetime.
| | Collapse this transcript |
|
|
