Project Management is about the People not the Tools

This past week I attended my local PMI monthly chapter meeting where Bob Baim gave a talk titled, “Predictive Project Management, Strategies for Avoiding the OS Phase” (Bob also has a book with the same title).

Bob (a very energetic speaker) gave us many examples of big name projects that hit the OS phase, and in many cases, they hit it again and again.  One of his take home messages was that projects do not fail, processes do, and if you do not fix them you will fail, again and again.

The following slide sums this up nicely:

You see it is not all about the tools.  To be a truly effective PM you need to be a people person and you need to be an expert in all types of communication.  Reading the PMBOK and being able to quote the page number where they talk about the WBS doesn’t mean you are an effective PM.

Josh Nankivel, from the PM Student, had a recent quote that I think sums it up nicely,

“I think many project managers tend to focus on tools and techniques far too much, and not enough on the people aspects of managing projects. By far these relational aspects of project management are the most important ones.”

Final thought on this.  Please keep in mind the people in your projects are what make your PM tools useful.  If you spend all your time with your tools you will probably be headed to the OS phase …

Project Planning Poker

Last week I attended a meeting with the group Agile Madison where our topic of discussion was determining the duration for each sprint item.  My input on this was that a plan is a strategy for the successful completion of the project and a schedule will tell us when things will be completed.  I also reviewed some ways to determine the schedule (or duration) for tasks in a project (Agile or any other type of project management methodology).  The classic PMI ones are: historical information, 3-point analysis and Monte Carlo analysis.  

The one that was introduced to the group was Planning Poker.  Here is how it works.

If you have a project with a group of developers (or testers, or data engineers) each developer is given a stack of cards that have the following on them: ?, 0, 1/2, 1, 2, 3, 5, 8, 13, 20, 40, 100, infinity.  The PM (or scrum master) reads off the sprint item and then the  developers pull out their cards on how long it should take and then they flip them over at the same time.  You may see instances where they all closely agree and other times one person is way off.  This will help them to open the channels to discuss why they picked there duration (maybe one of them had a similar task in the past and knew it was a lot more work then it was first predicted).

Why does this work?

It works because it allows you to bring together a group of experts to discuss each task and in many cases you may end up averaging the numbers to come up with your best guess as to what the reality may be.

So the next time you find yourself in a situation like this, think about pulling planning poker out of your PM toolbox.