>>Hello, I’m Jennifer Whitt, Director of ProjectManager.com.
[Music Intro]
>>Welcome to our whiteboard session today on the Idiot’s & Dummies Guide to Project
Management.
Before you make any judgments, let me share with you where this came from.
People always kid me about my stories of “back in the day,” so I’ll start with my “back
in the day” story.
Back in the day, right out of college, I worked for a company and, believe it or not, I was
a Unix system administrator.
People may not even know what that is anymore.
It was on the technology side, and it was before the term “project management” or
“project manager” even existed.
I was given by my executives my first small project.
The first word that came out of my mouth was, “Yay,” but what was in my mind was, “Oh,
no.
What’s that?
What’s a project?
What’s a small project and what’s a big project?”
After all, I was, again, a Unix system administrator and involved in very large project initiatives.
The term “small” is relative to your organization.
I’ve created my Idiot’s Guide for me, Jennifer Whitt, and I’d like to share that
with you today in case you find yourself on your first small project.
Maybe some of the tips will help.
The principle I learned through this in the beginning was from my executives once I got
my first small project is don’t spend more time, money, or effort on the project because
this was literally a small project, and once I was given this project, I was a woman on
a mission.
I really studied and analyzed this thing.
My small project was moving our group of about 15 people.
Our group was actually sitting on the raised floor in the computer room of our company.
We were moving into our new office, which was a modified hallway.
So I did have to coordinate with several other people for this big move.
What I learned from my executive, again, was not to overkill this project.
I want to share with you some of these things.
As I’m talking with many organizations, I do actually interview some CEOs.
Some of the problems that they say is on some small projects, where project managers get
a project bad rap sheet, it is for the same principle.
There are some things that are projects.
They have a beginning and an end date, and they’re producing a unique deliverable for
the organization, but they are small.
So to incorporate and do overkill on some of the project management principles and processes
is way too much.
In some organizations, a small project could be coming up with a quote if it’s an insurance
company, developing a quote for different services.
It could be a healthcare organization coming out with some piece.
Again, small is relative to one’s organization.
So the level of rigor should be appropriate to the size of the project.
Here are some of the “should dos” and some of the “don’t worry abouts.”
If you’re finding yourself maybe on some of your first small projects, these are some
of the things that I’ve found that you should do.
Number one, you should create a task list so you’ll know what has to be done in order
to get this project done.
You don’t have to worry about a Monte Carlosimulation or coming up with different things.
You do have to have somewhat of an idea of the tasks, the work that has to be done, and
the scope, but you don’t have to come up with the exact estimates in different scenarios.
Number two is to identify dependencies.
You do have to know what you have to have in order to get certain tasks done.
You may not be able to get some tasks done unless others are done before then, or you
may have to wait on certain resources or assets into the organization of the project before
you can do it.
So it’s good to identify dependencies, but you don’t have to come up with a critical
path or other contingencies.
The other one is assign people.
It’s important to know specifically who is responsible for a task, because if there
is no one assigned or if there’s an organization assigned, then the task is not going to be
done.
You need to know who to go to for specific things, so you’ll know who to report on
what’s the status, has it been done, how can I support you.
You don’t necessarily have to come up with a full-blown organization chart, resource
matrix, or even a detailed communications plan of all these people in all these elaborate
ways, because in a small project, again, relative to your organization, this is small.
This is a small effort, something that maybe it’s one person or two people or a few people.
Set due dates.
You have to know when things are going to be completed or when they’re projected to
be completed, but you don’t have to do any detailed reporting, all these elaborate, customized
reports, all the red, blue, yellow, green reports.
That can be overkill.
You do need to document the project, what’s been done, who, what, when, and where.
If it is a project, it is being funded from something in the organization, so you do need
records, whether it’s estimates, billing, or things like that.
So it’s does have to be documented, but you don’t have to go to any elaborate version
control or version control systems and all of that.
Then, you do need to track time and budget, because after all, if it isn’t within an
organization or a company, it is being paid for.
The people, whether it’s yourself and one or two people or however small your team is,
that is being paid from somewhere.
You do have to track time, and that’s associated with budget, invoices, billing, or even payroll.
You don’t have to go through any elaborate EVA analysis.
There are more things, but these are the top things that I think you should do.
Some of the top things you don’t necessarily have to worry about, again, for the small
projects.
The level of rigor should be according to the size of the project so you don’t end
up with a project bad rap sheet on your record.
If you need a tool instead of an Idiot’s and Dummies Guide to Project Management, then
sign up for our software now at ProjectManager.com.