PROJECT INITIATING AND PLANNING

Lecture 2.1
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 complete 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 responsibilities 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? Let'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 project?
A project is a unique and temporary endeavor. It has a defined
beginning and end. And the purpose of the project is to
create a specific product or service or to make changes to a
specific product or service.
1

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 unique,
temporary and had a defined beginning and end, and created a
specific product or service.
At work, 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
employees, 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 painting 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 going to 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
2

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 entire 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 event, 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 to 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.
3

As we go through this course together, each area we cover is

another part of your domain. When we discuss managing risks,
it's because you need to ensure that your project has strong risk
management. When we talk about the schedule, it's because 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.
There are some specific structures that are used by most
organizations. The basis for these organizations is the Guide 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 look at some of those project organizations.
First, we will look at what is called the Functional Organization.
4

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 and 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 limited 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, balanced, 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
5

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
going to 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 project 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. For example, the
functional organization works very well for groups who do not
6

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 manager, 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 the PMI wants
to see projects run by project managers, who are drawing upon
the best practices. But sometimes 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 more 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
7

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.