The Idiot’s Guide To Project Management
In this video, Jennifer Bridges, PMP, offers pointers on how to avoid spending more time, effort and money on a project in this back-to-basics guide to project management.
Back to basics. Jennifer noted the dos and don’ts she learned from her years of experience and through interviewing thought leaders in the field of project management.
They include how to:
- Create a task list
- Identify dependencies
- Assign people
- Set due dates
- Document the project
- Track time and budget
If you do the above, you’re no dummy, but if you don’t then people might start calling you names. Not good ones.
All joking aside, as Jennifer noted, these simple tips are, well, just the tip of an iceberg in terms of the knowledge a project manager needs to bring to the project. The size of the project impacts the importance of each of these functions.
Pro-Tip: Resources are crucial to the success of your project. Know who is responsible for what, and if no one is assigned to a task, know that task isn’t going to get done. Keep your resources allocated and keep a status on their progress.
For another checklist on the correct path to planning a project, read ProjectManager.com CEO Jason Westland’s article Quick Guide: 12 Steps to Planning a Project.
Thanks for watching!
Hello, I’m Jennifer Bridges, Director of ProjectManager.com.
Welcome to our whiteboard session today on the “Idiot’s 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 Bridges, 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. Even planing for a small project means having 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 Guide to Project Management, then sign up for our software now at ProjectManager.com.