Communicate your needs clearly at the beginning of the project and continue to

communicate on a regular basis throughout the project to keep track of progress,

stay aware of potential issues, and convey any project changes or new
requirements.

The project timeline is initially created in the project planning stage, but needs to
be flexible and may need to be adjusted as the project progresses. If you
communicate with your vendor enough you will be aware of any delays the timeline
needs to take into account.

The deliverables are also decided upon in the project planning stage. They are
what you expect to get back from the freelancer as the project progresses and at
the end of the project. Be sure to keep track of these throughout the entire project.

There are many project management tools available online to help you manage
and keep track of the work that is being completed on your project!
Project Management 101
By Jason Kalra

Introduction
There are those people who are born Project Managers.

And there are those people who achieve Project Management.

And then there are those people -- a surprisingly large number of people -- who have professional
project management expectations thrust upon them. It is this third group of noble people who will find
a nice, safe home within Project Management 101. I understand your pain. Please, have a seat. Would
you like some tea? A cookie perhaps? Maybe something to break?

There is no widespread consensus, from within either the scientific or philosophical worlds, as to how
this thrusting of project management actually happens. One moment you're standing there with your
hands in your pockets staring at a motivational picture of people rowing or maybe climbing something,
and the next moment *BAM* you find yourself at the epicenter of a vortex that bystanders are
referring to as 'that project'.

And they're looking to you for direction, advice, input, and feedback which you're only too happy to
provide, except for one important item:

They haven't actually provided you with the necessary foundational understanding of the concept of
project management.

This is not a particularly nice thing for "them" to do, and it's reasonable to assume that none of the
people in those pictures rowing that boat or climbing that thing would thrust project management upon
you with such reckless abandonment. But what can you do?

Well, here's what you can do: read this course on Project Management 101, where we'll right this
grave injustice to your sense of competence and human dignity, and learn about the basics of project
management so that you can approach your challenge with the confidence that you are entitled to as a
professional.

The goal of this course is thus to impart an overall understanding of project management through a
focus upon basic concepts, definitions, tools, strategies, processes, and phases.

This course embraces students from any professional background, including those that may not work
in a project environment but would simply like an introduction to the subject. So, whether you work in
human resources, training, cake decorating, exorcisms, automobile repair...and so on, students will find
the lessons in this course relevent. This is because project management is an approach to achieving a
goal. As such, students will be able to adapt the generalized knowledge and principles that this course
offers to fit within their unique and specific workplace project needs.
Lesson 1: What is a Project?
In this opening lesson we'll look at the definition of a project.

Welcome!
Hello!

If you've made it this far, then chances are that you experience some kind of response to the term
project management.

Maybe you have a physical response, such as running away and hiding beneath your desk (this is
nothing to be ashamed about, by the way).

Maybe you have an emotional response, such as a sudden, overwhelming desire to laugh, or cry, or
both at the same time.

Maybe you have a kind of mystical response, where upon hearing the term you hearken back to your
primordial self, and for one brief (yet infinite) moment, you are at one with the universe Itself.

Regardless of where you fall within this spectrum, we can all feel part of a shared knowledge
experience -- a community of learners, if I may -- that is connected by a common interest in project
management.

Isn't the Internet simply amazing for bringing us together like this? For all of its twisted applications,
online education really is one of the most astounding applications of this technology.

Ok, ok. I'll stop that. I just get all choked up sometimes. I’m just glad you’re here (project management
can be a bit lonely at times).

While each of us brings a unique approach to the topic of project management, our collective purpose
is to learn about its fundamental basics. So why don't we start that journey right now, with a look at
just what, in fact, is this thing called a project?

To answer this, we'll look at two introductory definitions, and then identify the core ideas that are
contained within them.

Shall we begin?
Lesson 1: What is a Project?

Definition of a Project 1: Temporary

Let’s take a look at the first idea that leaps out of the definition of a project: a project is temporary.

What does temporary mean when specifically applied to the definition of a project? With help from
James P. Lewis, we know that it means this:

A Project is something that has a specific start date and a specific end date. This start and end date
must be understood, and accepted, by the people in charge of the project.

If I were you, I'd immediately wonder this: hey, that seems nice….IN THEORY, but in reality, things
aren’t that neat and tidy. A lot of things that are referred to as projects have a general start date, and a
general end date. And sometimes they just kind of blur together into what seems like an endless array
of little projects.

If this sounds like something you’re thinking, then don't get mad at me (yet). I understand completely.
I often face the same challenge.

But even though we may sometimes (or often) work in a project-world where things don’t have a
conveniently stated start and end date, your job (if you choose to accept it) as a Project Manager is to
strive for this kind of organizational control. It may take a great deal of effort for you to actually
accomplish the deceptively simple task to determine the start and end dates of your project, but as a
Project Manager, that is one of your biggest tasks. So file the concept of temporary under “U” for
useful or “N” for necessary, and refer to it often.

In other words, the next time you're asked to manage a project, work hard to persuade the person
asking you to admit what the start and end dates are going to be. Or better yet, if at all possible, tell
that person that you'll tell them what the start and end dates should be once you've learned more about
what the project is trying to accomplish. Wouldn't that be nicer?
Definition of a Project 2: Unique
The second component of the definition of a project (after temporary) is that they are unique.

This doesn’t mean that any given project cannot have key similarities to other projects. In fact, a smart
(e.g. employed) Project Manager will actively search for similar projects to the one she/he is poised to
work on in order to see what some of the risks and realities might be.

What it does mean, however, is that the process to create your project is unique, and therefore, the
product of the project (the thing the project creates) is subsequently unique. This is distinct from a
program, which often uses an existing process and duplicates it over and over to produce a replicated
product. An assembly line is an example of a program, while building a skyscraper is an example of a
project.

Are you having fun yet?

Don’t answer that; not until we get to our third component of the definition of a project: a process that
performs. This one is a little tough, so stand up and get a coffee first. I’ll wait for you here.

Dum de dum…. stangers in the niiiiiightttt……

Definition of a Project 3: Progressive
Elaboration
So we've looked at two of the three basic components of our definition of a project:

1. Temporary

2. Unique

Now let's look at the third piece via James P. Lewis:

A project is the result of a multi-task job that performs something specific (i.e. a goal).

Ok. What does this mean?

Well, essentially it means that between the start and end dates of your project, the unique thing that
your project does involves a series of interconnected processes that performs in a progressively
elaborative way to achieve a specific goal.

Progressive elaboration means that you keep creating, modifying, and building upon the raw
ingredients of your project, in an organized way, in order to achieve the project's specific goal (also
referred to as the product of the project).

Think of the perverbial lemonade stand. Your goal is to make wads of cash selling it on the street to
crazed Project Managers. You start by buying some lemons. Then you take those lemons and, through
progressive elaboration, you cut them open like there's no tomorrow. And then you squeeze them into
another raw ingredient that you've procured: a pitcher. And then you add water to the pitcher, sugar,
and ice. Then you take yet another item you've procured, a big wooden spoon, and you stir the contents
of the pitcher. Then you pour it into YET ANOTHER item that you've procured, a glass, and sell them
to Project Managers for $800 dollars a piece.

As you can see, the items we procured in this example -- lemon, pitcher, glass, spoon, ice -- were all
elaborated upon to move us through our project until we reached our goal of selling lemonade.

A typical project outside of the sordid lemonade underworld is a tad bit more complex than this, but
the fundamentals are the same regardless of whether you're building a bridge or a house. You take your
procured items and progressively elaborate them towards achieving the goal of the project.

Sounds easy, huh?

mhahahahhaahhahaha

Actually, it isn't that difficult. Or to state this another way, it can be made much easier if you have a
basic understanding of what some of those processes that you have to manage actually are. We'll look
at those processes in our next lesson.

For now, let's wind things down a bit (we've covered a lot of stuff), and summarize what we've learned
in our next step.
Summary
From our definitions of the word project, we have plucked out three key ideas that we need to file
away in our permanent memories:

1. A project is temporary.

2. A project is unique.

3. A project is the result of a multi-task job that performs something specific (i.e. a goal). It
is progressive elaborated.

Now that we've got this rolling through our heads (and, in my humble opinion, know more at this early
stage about project management than a lot of people who are paid to be Project Managers), let's look at
some questions for consideration

The Imaginary Project Manager: Part 1

At the end of each lesson, we will take a light-hearted look at an odd little term or phrase that has
found a home within the culture of Project Management. What makes these terms fun, is that, well,
nobody really knows what they mean. Some people simply like to use them when referring to project-
based things in order to look a slight bit smarter than they might actually be.

The term for our first lesson is Ramp-Up.

Apparently, this term implies linking one part of a project to another, as in we really need to work on
that Human Resource Plan so we can ramp-up to Phase 4 of the project.

Bizarre!
Lesson 2: Fundamental Project Concepts: Part 1
In this lesson, we'll look at the basic elements that make up a typical project.

Welcome!
In our first lesson, we started to build our foundation for understanding project management by
looking at the basic definition of a project. Standing upon this solid base, we can now launch ourselves
into this lesson with a discussion of the basic elements and concepts of project management.

Before we do that, though...

We should keep in mind (maybe not in the front of your mind, but off to the side somewhere) that the
elements we cover here do not represent all of the kinds of things that you'll find in a project.
However, these are the basics, and if you find yourself working in a project world where most of these
things are present, then you're going to have more good professional days during that project than bad
ones.

Our second lesson together will therefore look at the following project elements and concepts:

• Project Management

• Project Processes

• Project Life Cycles

• Project Management Systems

Let's roll!
Lesson 2: Fundamental Project Concepts: Part 1

Project Management
I promise that I am not being unnecessarily stuffy by subjecting you to a section devoted to an
explanation of project management.

Really, I know that you know what a project is, and I also know that it will not take a gigantic leap of
inferential logic to figure out that project management is, in fact, managing a project.

But this basic understanding might not capture the heart of what project management is about; and
since that is the reason why we’re all here in this course, I feel we should dive further into this
definition. We can do this with a little help from our friends, the Project Management Institute and
James P. Lewis:

The PMBOK offers a solid definition of project management with:

Project management is the application of knowledge, skills, tools, and techniques to

project activities to meet project requirements.

James P. Lewis fleshes this definition out a little more with:

Project management is the planning, scheduling, and controlling of those activities that
must be performed to achieve project objectives.

There are two basic parts to this definition which we can play with here: process and objective.

Process: Project management requires coordinating a series of processes, which typically include
planning, scheduling and controlling.

Objective: Project management manages those processes towards the achievement of the specific goal
of the project.

As we can sense, the goal of the project (what it wants to do) is directly linked to its processes (how it
wants to do it), and vice-versa. And the dynamic interrelationship between the what and the how of a
project is the essence of project management.

Keep the above description in mind always, and it will serve you well for a couple of reasons.

Firstly, it will help you steer your project and keep it focused.

Secondly, and rather interestingly, this description will really help you explain just what it is you do.
You may know it, and some other project insiders may know it, but all the people who will populate
your project may know you as the Project Manager, but kind of look at you funny, wondering what
you get paid for. Just tell them the above, and feel the harmony and affection blossom.
Lesson 2: Fundamental Project Concepts: Part 1

Project Processes
In our last section, we referred to something called project processes in our definition of project
management. But just what are those processes?

Why, I'm glad you asked.

Project processes are roads, highways, alleys, and sidewalks that provide direction for whatever
activity is taking place.

Now. Just what on earth does that mean?

In a nutshell, the project processes are the ways by which the various project deliverables are achieved
(deliverables are like baby-goals that support the mother-goal, we'll define deliverable later on in this
lesson).

Project processes are thus organizing tools for Project Managers. Each activity that goes into any
project will work to help the project progressively elaborate towards its goal. The project management
team will thus determine how each activity helps the project move forward by slotting each activity
into its appropriate group of project processes.

What are those project processes? The PMBOK suggests five process groups:

• Initative Processes: authorizing the project or phase.

• Planning Processes: defining/refining objectives.

• Executing Processes: carrying out project activities.

• Controlling Processes: ensuring the project is on track.

• Closing Processes: formally ending the project or a phase.

The project management team thus looks at each activity and asks: where does it fit on this list?.

And of course, you have every right to ask: who cares where it fits? What is the point of all this?

The point is that, as an organizing tool, the project processes tell the project management team how
each activity is helping the project.

Think of the processes as a football league, each with a different uniform.

 • Initative Processes: red uniforms.

• Planning Processes: green uniforms.

• Executing Processes: blue uniforms.

• Controlling Processes: white uniforms.

• Closing Processes: black uniforms.

The project management team assigns each activity a uniform, and can thus tell -- without having to
waste time figuring this out during the project delivery -- how each of those activities are helping the
project move ahead.

Let's go back to our happy lemonade stand. Let's say that one of the activities in this project was to
check the quality of the lemonade. The activity is called: check quality of lemondade, and the project
management team gives it a white uniform, because it is in the controlling phase of the project.

So by listing all of the activities beneath their umbrealla project process heading, the project
management team can make sure that they are doing what needs to be done in order to help the project
move forward.

A little confusing, I know, but give it some time and it will start to make more and more sense as you
read and experience more in the field.

We've covered a lot here, and we're well on our way to really grasping what project management is all
about. Let's continue this momentum with a look at the Project Life Cycle.
Project Life Cycles
Thankfully, learning about the Project Life Cycle (PLC) is a little bit easier than learning about Project
Processes. This seems only fair, don’t you think?

But just what are those cycles? Well, we just came from looking at processes, so right now on our
stage, here's that dazzling foursome that has been exhilirating Project Managers across the globe with
their unique brand of organized music...ladies and gentlemen, James P. Lewis' Four Cycle PLC! (wild
applause and mild hysteria/fainting)

FOUR-PHASE PLC :

1. Concept: marketing input, feasibility studies, surveys of competition.

2. Planning: determining the appropriate way to achieve project goals.

3. Execution: carry-out activities to achieve project goals.

4. Close-Out: wind-down project and conclusion.

And why, you might ask, is knowing about each cycle in the PLC so important?

A Project Manager (and his/her team) must always know what cycle of the PLC the project is in,
because that knowledge tells everyone just where the heck they are in the project: are we at the
beginning, in the middle, at the end? Is it over? Can I go home now? And so on...

You can sense the echo here of the previously discussion on project processes. As a result of this echo,
things can get a little confusing (knowing what is a process, and what is a cycle in the PLC). So let's
unconfuse you before you get confused:

• Processes refer to groupings of activities in the project. You want to know what process your
activity falls within so you can determine what role that activity is playing on the project.

• PLC cycles refer to where, in terms of time, you project is at any given moment. You want to
know what phase of the PLC your project falls within so you can accurately approach see
where your project is in (is it still a baby? Going through puberty? Old age?).
Lesson 2: Fundamental Project Concepts: Part 1

Project Management Systems

The word system is a very useful word, and enjoys a great deal of airtime in our language. Think of
such festive terms as solar system, ecosystem, transit system, digestive system, and so on.

Thanks to its popularity, most of us have a general understanding of the concept of the word system
already, and I promise I won't spend eons of time deconstructing the definition for us here.

However...

We should clarify what the concept of system means when placed next to the concept project, because
as Project Managers, we need to have a solid understanding of how concepts adapt and change when
they are brought into our project world.

James P. Lewis draws on years (and tears) of project management experience and puts forth seven
components that comprise a Project Management System (which we shall not reduce to an acronym).

1. Human Component. Dealing with "people issues", such as interpersonal communications,

negotiating, motivating, team-building, and of course, politics.

2. Cultural Component. Values, beliefs, attitudes, behaviours, and traditions of the project
environment.

3. Organizational Component. Managing authority, responsibility, and accountability.

4. Methodological Component. The "tools of the trade", such as software which keeps track of
schedules, budgets, and resources.

5. Information Component. Capturing information about the project, as well as storing

information for use by future projects.

6. Planning Component. Ah, the plan. The plan tells you what you're doing. It is therefore fairly
helpful (not unlike, say, your brain or heart).

7. Control/Management Component. Being able to actually manage the project requires having
control over how things get done.

Before we move ahead, I'd like to throw out an additional note on #7. This doesn't mean that Project
Managers are control freaks. Truly, the best ones I know are very good with sharing power and
responsibility (they come as a pair or not at all). But there must be an enduring element of control
throughout the project. If you don't like the word control, you can use the word management; in this
context, they mean the same thing.

Moving ahead...
It is critically important that these seven components are seen as part of a system; that is, changing one
or more component(s) will have an effect on one or more of the other component(s).

To put this another, somewhat more pragmatically: if one of these components is not adequately
supporting the project in the way it needs to, then the project will suffer because of this.

Fortunately, solid projects rely on a team of people (of which the Project Manager is just one key
member) who help keep this system in good health by managing the components of a system.

So don't feel overwhelmed by the vastness of these components that make up a Project Management
System. However, don't take them lightly, either, because a Project Manager who narrowly focses on
one component will soon find themselves scrambling to restore balance to this system.

And that's not a fun thing to do, believe me. In fact, it's about as far away from fun as you can get while
project managing.

But most Project Managers fall into this downward spiral simply because they didn't know that a
Project Management System of interrelated components existed. But you know that, now, and it will
keep you out of misery for years to come!
A Few Words...
I'd like to take a very small pause in our learning at this time.

Some of you may have reached a point in this class where you’re thinking:

Well, look here Jason. Thanks for everything so far, but when I started this class I felt
pretty comfortable with my understanding of project management, and now that I’m not
even through the second lesson in this course, I feel like I know even less.

Please believe me: I empathize completely with you. All of this information can seem overwhelming
and even a little academic; after all, in the real world, do you really need to know about the seven
components of a Project Management System? Or do you really really need to know about project
processes and PLC cycles?

I know you can guess my answer: YES YES YES!

Why (why why)? Well, because if you know about the fundamentals of project management, then you
are better equipped to manage your project. If you lack this foundation, you lack the kind of
confidence, competence, and satisfaction that you deserve to experience. Even though your current
project world may not give you the opportunity to (for example) really reach out and manage all seven
components of the Project Management System, you should still know what they are and strive to
achieve them. This will lead to: better projects, and better experiences for you as a Project Manager.

Thank you for letting me say this. I'm here until Friday... don't forget to tip your waiters and
waitresses, they work hard... and hey, check out the cash bar...

Now let's go ahead and summarize the important ideas we've covered in this class, and also look at
some questions for reflection.
Summary
We've covered some very big, and very important things in this lesson, including an overview of the
following concepts:

Project Management: Made up of two components.

• Process: Project management requires coordinating a series of processes, which typically

include planning, scheduling and controlling.

• Objective: Project management manages those processes towards the achievement of the
specific goal of the project.

Project Processes: A way to organize project activities in terms of how it is helping the project
achieve its ultimate goal.

PLC's: The creation-to-conclusion timeline that the project travels upon.

The Project Management System:The family of interrelated components which work together to
support the project.

In our next lesson, we'll continue looking at some more key concepts that you'll find helpful and useful

The Imaginary Project Manager: Part 2

This Lesson's phrase is: forward compatable

Perhaps you've heard this odd little phrase from time to time? In my experiences, its most frequent
appearance is made by an overpaid person in reference to an activity that, once completed, will help
ensure that the project remains on or ahead of schedule.

For example:

We really need to ask Johnson's team to work overtime this month so we can ensure that
the activities remain forward compatable.

...okey dokey...
Lesson 3: Fundamental Project Concepts: Part 2
In this lesson, we'll continue our coverage of the basic concepts of project management.

Welcome!
We've made our way through a lot of territory together, and there's a lot of new information competing
for prime real estate in your memory. This is a good feeling; it's kind of like love, brain-style.

Our journey in this third lesson will take us through these additional basic project management
concepts:

• Milestones

• Deliverables

• Stakeholders

• Baselines

• Project-Based Organizational Structures

And as always, we'll wrap things up with:

• Summary and Discussion

• The Imaginary Project Manager

Follow meeeeeeee....
Lesson 3: Fundamental Project Concepts: Part 2

Project Milestones
There are many fun terms and concepts which live in the project management universe. We'll look at
five fundamental ones here.

Why have I selected only five? Well, its a little bit arbitrary on my part. Really, in my experiences,
these are the five biggies. Knowing these will help you navigate some of the project management
world with flair and confidence.

With that being said, as we move forward in this lesson (and in the remainder of our course), please do
keep in mind that we're only covering the some of the basics here. Doubtlessly, your list of known
project management terms concepts will grow as your immerse yourself in the role.

The first concept we want to look at is the milestone. PMFORUM, a wonderful website devoted to
project management-related information, offers a truly gifted glossary which explains milestone
nicely:

A point in time representing a key or important intermediate event in the life of a project. A
milestone should be capable of validation by meeting all of the items prescribed in a
defining checklist as agreed with the stakeholders.

We can sense two two basic elements of this introductory definition: key event and validation.

Key Event: Milestones give your project team a kind of little "hello there, notice me for some reason"
flag at specific points in the project. What points? Well, that all depends (sorry, but it does). Milestones
typically represent important project events, such as the completion of a phase or the creation of a
prototype. They break up the project into little chunks, and give the team a chance to focus on some of
the smaller goals along the way. Milestones are not activities in themselves; they do not require
resources, cost money, or take time. They are just little flags that say HELLO. Think of them like little
stickies that you put in a textbook to remind you of important parts of the book.

Validation: This part of the concept of milestone is less well-known, but equally as vital to understand
the concept. Determining what is, and what is not, a milestone cannot come simply from the twisted
mind of the Project Manager. Rather, the team should work together to identify what those milestones
should be. Otherwise, when you actually reach a milestone, there may be key people on the project
team that have no idea why it's a milestone. This doesn't mean that you have to take a democratic vote
every time you think something should be viewed as a milestone; that would be wholly impractical,
and furthermore, you aren't paid to do that. Rather, you will want to flesh out the milestones with, at
least, your senior project team and any other key members involved in that key event.
Lesson 3: Fundamental Project Concepts: Part 2

Deliverables
Related to the concept of a milestone, and easily one of the most frequently heard words in the project
universe, is deliverable.

Deliverable is one of those really, really great words. You can use it all around your life, at the grocery
store, at the beach, wherever you take your bad projectized self. The PMBOK introduces this concept
very nicely:

A deliverable is a tangible, verifiable work product such as a feasability study, a detail

design, or a working prototype.

A deliverable thus is something tangible, measurable, and lives outside of the head of the Project
Manager in the world of physical things. One of the easiest ways to grasp the essense of deliverable is
to note the word deliver, which implies that something is produced and given to someone else (like
delivering a pizza).

Deliverables are therefore the little pizzas that your project gives to you, and the rest of your team.

So what's the big difference between a milestone and a deliverable? HUH?

Well, a milestone has a symbolic purpose and is not a physical creation (and therefore can represent
things that are not tangible, such as hitting the 3 month mark of the project).

A deliverable, on the other hand, defines the class of tangible(i.e. physical) products that the project
produces on its path towards achieving its ultimate goal. As a result, a project will have significantly
fewer milestones than deliverables.

You might be wondering if a milestone can be a deliverable? Absolutely.

For example, let's say that one of your agreed-upon and accepted milestones is 3 months down the
road, and represents the recruiting of a Project Management Assistant (remember that milestones are
not activities in themselves, but simply represent special activities in the project). This hiring of a
Project Assistant is also a deliverable: at the 3 month mark, the project activities have led to the
production of a tangible product: the Project Management Assistant.

This means that many of your milestones will in fact be deliverables, but many of your deliverables
will not be milestones. Milestones are used to flag key events. Each time your project produces a little
pizza is not a key event. Some of the pizzas will be really important, and those will be a milestone. But
don't make every deliverable a milestone, or your team will think you've gone mad and with good
reason.
Lesson 3: Fundamental Project Concepts: Part 2

Stakeholders
Ah yes. Stakeholders.

A lot of people don't like this word. I know of one person who will not let me use it. I think it might be
because this word is used a lot, all over the place. This is because a stakeholder is, as defined by
PMFORUM:

One who has a stake or interest in the outcome of the project.

Errr...

Yes, I agree. Wouldn't this make hundreds, thousands, perhaps even millions of people a stakeholder?.

Well, yes. Technically, it would. For example, if your project was creating a new kind of car that relied
on mango instead of gasoline, then if you want to get technical, then all of these people who might buy
one would be part of the stakeholder group.

But why do you want to get technical?

All you need to know is that a stakeholder is a person, or more typically a group of people (represented
by a person or a team) that has a vested interest in what your project is doing. This can include the
person who pays for the project (a.k.a. the Project Sponsor), the various sub-contractors who help
produce deliverables in pursuit of achieving the goal of the project, or the customer(s) who will receive
the product of the project (e.g. your mango car stakeholders).

I think the reason a lot of people (particularly those not involved in project management) dislike the
word stakeholder so much is because it is one of those words that finds its way to the tip of your
tongue ahead of a lot of other words. For example:

Evil Movie Theater Manager: I'm sorry sir, but you cannot bring your own popcorn
machine into the theater with you.

You: Are you mad?! Have you no consideration for your customers? Who are you to make
this decision? Who are the other stakeholders.

As you can see, bringing a popcorn machine into the theater isn't really a project, nor does it take place
inside of a project environment, and hence, a lot of civilians come to learn of the word via this kind of
emotional, public display.

So I would advise you, as a friend, to use this word sparingly. It is for the greater good.

Why do you need to know who your project stakeholders are? This is one of the most important
questions you will ever need to answer. Your project stakeholders are like various agents that represent
different pieces of the project. Sometimes, your project stakeholders will have a shared view of how the
project should be managed. Often, though, you will have various stakeholders who would like to see
different aspects of the project enhanced, other changed, and others removed entirely. Your challenge as
the Project Manager is to manage the expectations of these stakeholders, which will sometimes
compete with each other.

Oh, sorry, did I mention that to be a project manager you have to be an extremely good politician?
Well, you do.

This introductory course to project management cannot teach you how to manage stakeholder
expectations, nor exploit the positive aspects of politics on your project (yes, there really is such a
thing). James P. Lewis' book touches upon this, as does the AMA Handbook of Project Management.

Given the scope of this introductory course in project management, all I'd really like to convey here is
the basic idea of what a stakeholder is, and to really emphasize the fact that as a project manager you
will spend a great deal of time managing the expectations (reasonable and unreasonable) of these
stakeholders.
Lesson 3: Fundamental Project Concepts: Part 2

Baselines
Project management language can seem so odd sometimes that when we come across a term that is
starkly straightforward, it is not unusual to pause and look for some kind of hidden meaning.

Behold the term: baseline. It really does mean the line at the base of something.

Line at the base of what, though? Well, that depends on what you're measuring. If you're looking at
how much cash you've spent, then you'd be looking at the cost baseline, or if you want to see how
much time you've spent on something, you'd consult the schedule baseline.

PMFORUM's glossary gets us on our way to understanding what baseline means:

A planning and control instrument in the form of a summary of attributes such as quantity,
quality, timing, costs, etc, that establishes a formal reference for comparison and
verification of subsequent efforts, progress, analysis and control. Can be for project,
business or technical management control.

Oooooooook.

Let me elobrate by way of mythic tale.

Let's say ORK, a proud caveman, decides he wants to carve 3 drawings on his cave, per day, for 40
straight days.

ORK decides to create a schedule. Since he expects to carve 3 drawings per day for 40 days (for a total
of 120 drawings), he notes all of this data down on his schedule. His schedule tells him not only how
many drawings he's planned to have carved by the time he's done (120 in total), it also tells him how
many he'll hit at the halfway point (60 drawings in 20 days), and any other point between when he
starts his project, and when it is planned to end (which will be 40 days from the start date).

Once ORK is ready to start his project, he looks at his schedule and baselines it. That is, he freezes it
and names it the schedule baseline.

Now let's fast forward 20 days. ORK has been busy drawing on his cave walls. At the end of day 20,
he counts his drawings and sees that there are 65.

Stay with me, this is going somewhere.

This data has project management-related meaning to ORK because he can compare what is happening
in reality to the baseline. In other words, he can see that according to his schedule baseline, he thought
he'd complete 60 drawings by day 20. But in reality, he's at 63.

By being able to reference the schedule baseline, ORK was able to see that he is ahead of schedule.
Is this good? Maybe, maybe not. Maybe ORK is ahead of schedule because he is spending more
caveman money than he had anticipated (a look at realty vs. the cost baseline would tell him if this
were the case). Or maybe he is ahead of schedule because another activity (such as painting each
drawing a nice banana yellow) was not taking place, and was therefore artifically speeding up the
drawing part of the project (but neglecting the painting part).

Checking reality against the baseline thus tells the Project Manager if things are devitating from what
was originally forecasted. If they aren't, then that's fine. But 99.9% of the time, something will deviate,
and it's the Project Managerand her/his team who will decide what course of action (if any) should be
taken.

A final note, most baselines are created at the outset of the project and remain stable for the entire life
cycle. However, there are some extreme cases where something so unexpected (either negatively or
positively) has happened to the project that renders the original baseline useless. When this happens,
sometimes the project team will be forced to rebaseline whatever things it had originally baselined
(cost and/or schedule). In other words, the first baseline was so totally whacked, that it made no sense
to compare things to it anymore, and so a new standard had to be created.

Rebaselining is a rare occurance (thankfully), and is almost always a last resort contingency for a
project that is spiraling out of control due to an unforeseen event.
Lesson 3: Fundamental Project Concepts: Part 2

Projectized Organizations
Our next challenge is to take a look at this strange beast called The Projectized Organization.

Actually, this beast isn't that strange at all, but becomes strange due to the fact that, by virtue of having
the word project in its title, people refer to any organization that does project-work as a projectized
organization. And this is, as you can guess, not the case.

So let's clarify this little confusion right now with a help from the PMBOK. A projectized organization
is one in which project members (those people formally assigned to work on a specific project) are
often collocated. Because of its modular design (think of pieces of lego that can detach and re-attach
somewhere else), projectized organizations devote most of their resources to project work, and Project
Managers enjoy a great deal of authority, responsibility, and in some cases, free coffee.

Projectized organizations thus derive their name from the fact that they are built to do project work;
people can be re-assigned to projects swiftly, accounting systems are in place to track labour and
resource costs efficently, and Project Managers are given both the authority, and the responsibility, to
manage virtually all aspects of the project.

Sounds like the perfect place to work, huh? Well, it can be if you're a Project Manager and there is
enough work to sustain continuous project-related work. But it can also be a very volatile place to
work, and a real miserable place for those that don't enjoy extremely fast-paced, deadline oriented
workplaces.

Perfect projectized organizations don't really exist in nature (not unlike a perfect vacuum or a perfectly
good Made for TV Movie). But organizations that emphasize their projectized-ness (err..) certainly do
exist, usually in the IT and constructions fields, but other places as well (such as educational
consulting).

So as to round our our understanding of organizational structures, I'd also like to touch upon two other
flavors of organizations in which Project Manager's: functional organizations and matrix
orgnaizations.

Functional organizations reflect the hierarchial structure that has dominated organizational charts for
the last few centuries. This is the structure in which each person is placed on a pyramid, and reports to
a very clear and visible supervisor/manager, who in turn reports to a Vice President, who in turn
reports to a person who you've never met in person or heard from, yet spends a great deal of time
wearing dark blue pin-striped 3-piece suits and having their portrait painted while they practice
looking astonishingly inanimate. Project Managers who work in these types of organizations typically
have little authority and power, and often have to wrestle with functional managers (e.g. the Vice
President of something or other) in order to have resources devoted to the project.

Of course I'm being colorful here, functional organizations are not nightmares for Project Managers,
but one of the challanges that a Project Manager will face in this environment is receiving enough
attention "from the top" paid to their project. It's a great idea, in these situations, to have a Project
Coordinator, which is simply a person at an executive level who will fight for your project to obtain
the resources it needs (including coffee).

Matrix orgnizations try and synthesize aspects of the projectized and the functional organizations. I
use the word try not facetiously, but rather pragmatically: sometimes it works, sometimes it doesn't.
Two types of matrix organizations exist, weak ones and strong ones. Weak ones lean towards the
functional world and thus don't route a lot of authority to Project Managers, while stronger ones lean
towards the projectized end of the spectrum and route more power to the Project Manager.

Lesson 3: Fundamental Project Concepts: Part 2

Summary
We've covered yet another massive amount of territory, and we should all feel pretty good about the
fact that we now know the following very important things:

Project milestones represent key events in the life of a project. They do not represent an activity, or
require any resources. They are symbolic, and need to be accepted by your stakeholders.

Deliverables are the tangible, objective outputs that your project creates as it moves towards achieving
its goal.

Stakeholders are people, groups, organizations, and other entities that have a vested interest in the
outcome of your project. Manging the expectations of these stakeholders is a critically important job of
the project politician-- I mean, manager.

Baselines are snapshots of budgets or schedules which help you determine if you're on track, or if a
deviation has occured.

Projectized organizations are structured to route authority, responsibility, and resources to Project
Manager's and project-staff.

The Imaginary Project Manager: Part 3

This lesson's strange phrase is stretch the envelope.

This bizarre little insult to the english language seems to emerge, almost exclusively, from the mouths
of people who have an astoundingly small understanding of project management, and would much
rather be on a golf course or shooting something that eats plants. Perhaps you've heard something like
this?

Well, you see here, what we need to be doing is stretching that envelope to make sure we
maximize our total potential and maintain our forward compatability with regards to our
overall value structure and quality management systems.

ow.