Do PM's get in the way of the "getting it done"?

"Project Management is for detail freaks and road blockers"
"Why can't they just get on and get started with doing something!"
"Project Management = Microsoft Project right?"

These are slightly cynical, often unspoken (or spoken by our "I say it like it is" friends), statements of how Project Management and Project Managers are seen.  In some circles a Project Manager can be seen as a road block or handbrake, so who would want to be one or use a project process!
One of my favourite memories of a project was during a planning phase and trying to get the project scope right.  A stakeholder got a bit frustrated with the process and asked that I "stop singing and dancing and get on with it".  We worked through the process and all those involved in that project list it as a great success.
So what does it really mean to be a Project Manager?  Is it your job to stop people from getting on with the job? Or is it to plan to the n-th degree? Or is it to break out the busking shoes and guitar and do a jaunty jig? Well that all depends (except for the jaunty jig)!
If you are creating a maintenance project for an oil rig that requires absolute accuracy and completion within a 1 hour period (because that's as long as you have before the company starts losing money) then Yes you will have to plan to the most minute detail.  However, for many other projects it all depends on the questions you have to answer in order for the project to be a success.
So the first question we need to ask is; what are the things that must happen for your project be called a success!  But before you can get an answer to that question you need to know; who in the project team or the company can define what "success" means?
Lets look at an example.
Steve has been given a project to set up a new service.  Steve quickly goes about deciding that he needs to purchase a new computer system to make the new service run.  He also decides the most important thing about his project is to get it done on time.  So he sets about procuring the system and getting contractors in to get the job done.  Steve finishes his project and is promptly brought to task by his boss about his budget blow out and the fact that he didn't use technology that was aligned with the strategic vision of his company.  Why was Steve brought to task?  Because Steve's boss's version of success was a project on budget and in line with the company IT strategy - quite different to the way Steve planned and executed his project.
So first step - identify who defines a successful project and get them to set out their criteria and measures of success.  Now I'm making the bold assumption the person defining success can also balance the project tension triangle* - lets leave that for another post.
Now we know what success is for your particular project, we can establish what questions need to be answered as part of your project plan.   If success is keeping it in budget then you need to ask:

• Is the budget fixed?
• How much will this project cost?  
• What do I need to do in my planning to be confident of the cost?  
• Who do I need to talk to or involve to provide me costs or estimates?
• How much confidence do I need in my numbers - how much contingency?  Estimates or quotes?

If the success is being on time and meeting a deadline we need to ask:

• What are the tasks that are dependent on each other and how long will they take to complete?
• Do they have to be done one after the other?
• Who do we depend on and what are their time constraints?
• Are there activities that have built-in lead in buffers? e.g. recruitment
• What can run in parallel?

Answering these questions will tell you what needs to be done to form your plan for the project.
Lets look at those comments at the start, all of them have elements of truth to them, but like all generalisations (like how I just generalised?) they don't reflect reality or prove to be that helpful.
​
"Project Management is for detail freaks and road blockers"

There is a need for attention to detail but not all plans or approaches need extreme detail - as we saw at the start sometimes detail is required but sometimes not.  As for "road blockers", if you are about to drive off a cliff they are quite helpful, however road blocking simply to follow a process when it isn't strictly necessary isn't going to help.

"Why can't they just get on and get started with doing something!"

There are times when this should be the case - when all involved have a clear view of the vision, scope, benefits and success measures.  If you don't have those nailed then I strongly recommend you get them sorted...which, technically, is actually doing something!

"Project Management = Microsoft Project right?"

This is pretty common, actually often its more Project Plan = Gantt Chart.  Neither is true.
So, really, project management is actually about asking and getting answers to questions. Some questions need to be answered to plan the project, some questions are answered by doing the project.   The nature of the questions directs what level of detail and planning you  need to do. Using methodologies and techniques will help you with getting those answers or structuring your questions - Jaunty Jigs are fun but may not help in answer those questions.
* http://en.wikipedia.org/wiki/Project_management_triangle