[MUSIC] Hello, welcome to Initiating and

Planning Projects. This is our first course in our

Introduction to Project Management series. I'm Margaret Meloni and it's my honor
to lead you through this course, so I'm really glad you're here. After you compl
ete this course,
you will be able to identify the key characteristics of a project,
and identify project constraints. You will know and understand the role and resp
onsibilities of the project manager
and be familiar with the project organizational structures we
frequently use to run our projects. You will see why a project
charter can be useful and you will know the key elements
that go into a project plan. You are going to consider what causes
conflict within a project and you will gain an understanding of the difference
between authority and influence. This will help you understand
more about your role, and about how you wish to lead your team. Are you ready? L
et's jump in. We should start with the basics. And in the very beginning of
an introductory project management course, we should start with, what is a proje
ct? A project is a unique and
temporary endeavor. It has a defined beginning and end. And the purpose of the p
roject is to
create a specific product or service or to make changes to a specific product or
service. Let's consider some examples. If you have ever planned a large party or
an event, that is a project. It was a specific party for
a specific reason. It was held on a specific date and time. That means it was un
ique, temporary, and
had a defined beginning and end, and created a specific product or service. At w
ork, if your office is moved, it will
most likely be handled as a project. If your payroll system is replaced with
a new payroll system, that's a project. If your human resources department
decides to change the processes they use to recruit and interview and hire new e
mployees,
that too can be handled as a project. Now day to day operations,
they're not projects. Creating monthly financial
reports is not a project. Cleaning your house, not a project. What about paintin
g
the Golden Gate Bridge in San Fransisco, do you think that is a project? I'm not
trying to trick you. You might call it a project because
it's such a large bridge and certainly painting it must require
special effort and planning. Or you might say it's not a project
because there's a maintenance team whose job it is to paint the bridge,
and when they finish, they probably start
painting the bridge all over again. There are gonna be times when someone
you work with is going to call something a project even if it does
not fit our definition of a project. Depending on who it is, it could be
because they want this specific effort to receive the attention and
oversight that a project receives. An example of this could
be a computer refresh. Perhaps your organization has decided
that employees should have new computers every two years. Replacing them one by
one is
really an equipment upgrade. But, if all of them are replaced at once, the entir
e effort may be very
likely treated as a project. When you execute a project, you have
certain constraints that you face. A constraint is a factor which
might place limitations or restrictions on what you do or
how you do it or when you do it. For example, if your project is a party or an e
vent and it has to occur on
a specific date, that is a constraint. If your project is to purchase and
install a new payroll system, that new system has to provide
a certain functionality. Yet you do not have unlimited budget,
that's a constraint. If your project is to design and manufacture a new product,

you might
have requirements as to how much of the manufacturing can occur outside
of your country, that's a constraint. As a project manager,
you oversee the success of the project. You are using your knowledge and skills,
combined with project management tools and techniques, to ensure that
project objectives are met. You are the one who is responsible for
defining that special event or that payroll system or implementation. You help t
o ensure that
the requirements are identified, that all involved are properly represented,
and that communications are clear and well coordinated and
you lead the team to success. As we go through this course together, each area w
e cover is
another part of your domain. When we discuss managing risks, it's because you ne
ed to ensure that
your project has strong risk management. When we talk about the schedule, it's b
ecause you need to ensure that
the project has a realistic schedule. The way in which your project team is
structured really sets the tone for how you are going to work with your team. Th
ere are some specific structures
that are used by most organizations. The basis for these organizations is the Gu
ide to
the Project Management Body of Knowledge. We haven't discussed the Project
Management Body of Knowledge yet, so now we will. The Project Management Body of
Knowledge,
or PMBOK Guide, has been created for us by the Project Management Institute,
or PMI. The PMI is the global, professional
organization for project managers. The PMI created and
now updates the PMBOK Guide to promote successful project management
through standardized knowledge areas and processes, which we use to manage
our projects from start to finish. What you are learning about in this
class is based upon the recommendations of the PMI and from the Guide to
the Project Management Body of Knowledge. With that information in hand, let's l
ook
at some of those project organizations. First we will look at what is
called the Functional Organization. In a Functional Organization,
there is little to no project management. You might not be involved
as a project manager. Sometimes there can be some
project coordination involved. And that coordination takes place
between the functional departments. Now by functional, I mean groups
such as marketing, operations, finance, information technology. Each manager of
each group oversees
their part of the project. Employees working on the project may or
may not know there's a project. They just might recognize that their
manager has asked them to do something different than usual. There's probably li
mited
conversation between team members, because they do not know they are a team. And
there are probably no
project team meetings. Now we're going to look at three types
of matrix organizations, weak, balanced, and strong. The designation of weak, ba
lanced, or
strong has to do with who has more power or control over the project, the
functional manager or the project manager. And remember that functional manager
is
someone who has a responsibility over a specific area and
doesn't typically run projects. In a weak matrix, the functional
manager is in charge and he or she will probably have
the assistance of a coordinator. The project coordinator will help
maintain the schedule and the status and assist the functional manager,
but the coordinator, not gonna have any decision
making responsibility. Within the balanced matrix, there's a

recognition that having a project manager assigned will help to ensure success.
And that project manager has some
decision making responsibilities, but so does the functional manager. The projec
t manager manages the team to
stay within scope and schedule and budget. And the functional manager will make
decisions as to who does the work and how that work is to be accomplished. In a
strong matrix, the project manager
has much more responsibility and authority. But not complete responsibility and
authority. He or she still cannot
make all of the decisions. Now when we talk about
a projectized organization, this is where the project
manager is king or queen. The team is dedicated,
works on this one project, and the project manager will act
as the manager of the team. Possibly even writing
performance appraisals. So which one of these is
the best organization? Now that's a trick question. They all have their place. F
or example, the functional
organization works very well for groups who do not run
very many projects or for projects which are not complicated and
not on a tight deadline. The Matrix Organizations work well when
team members are going to be assigned to a combination of multiple projects and
also other work. And in a matrix, team members could
be assigned to quite a few projects. In a matrix situation, you as the project m
anager, most likely
you're running multiple projects. As to which matrix is best,
weak, balanced or strong? Well the PMI would ask us to consider
strong because that is where the project manager has more power. And of course t
he PMI wants to see
projects run by project managers, who are drawing upon the best practices. But s
ometimes a weak matrix is good, when
the functional manager in charge has much of the required expertise and simply
needs help with project coordination. A balanced matrix works well when it's
easy to divide decision making and responsibility between the project
manager and the functional manager. If it makes sense for the project manager
to have more of the authority and the decision making, but not all of it, then a
strong
matrix could be the way to go. Now, a Projectized Organization is
good for a very critical project, especially if time is of the essence. It is mo
re expensive,
because you take team members and put them all on one effort, and
they were doing something before, so you probably have to backfill them. But the
project gets all of the focus and
attention that's required. There really is a time and a place for
each of the project organizations. And in fact you'll find that some
companies may use a combination of all or some depending on the project at hand.
Now look at you. We started out with some basics
such as what is a project. And now you have an idea as to what
you will do as a project manager and how project teams can be structured. And we
're finishing up our first module. [SOUND]