You ‘feel’, based upon what? Do you really think I care about process when I’m knee-deep in the mud, trying to get the people around the table for a major problem just discovered; at the same time listening to a team-member who has personal problems; while trying to get to grips with the latest change request the customer has asked?

“most of us do not deliver massive scale projects”

Really? Did you check lately? Who is ‘us’ anyway? Can you substantiate ‘most’ by any number? Do you really think people that are organising a birthday party are visiting this site for some Howto tips?

Sorry about the rant. I tried to be funny before, but your reply just got my blood boiling. This post just doesn’t make any sense. I sincerely hope the ‘Hut’ updates its quality criteria.

The title and content is intentionally simplistic more to drive home the point that really underlies the whole thing which is essentially that I feel PM has become a focus for process rather than the end result i.e. the delivery of a successful project to the end customer. We have created a plethora of PM practices and principles around PM that essentially are often not required for the bulk of projects that are run out in the business world. The point Steven made is correct - most of us do not deliver massive scale projects. We deliver far smaller pieces of work which are equally important to the customers we are delivering for.

Of course all of the other things are important - change control, risk management, budgetary discipline etc, but the degree of management of those items needs to be in perspective to the scale of the project.

A to-do list, while inflammatory in nature, can be as complex as you want/need it to be. It can be a 1500 line gantt chart in MS project with multiple dependencies or it can be a note-book with the half dozen things that need to be done to get a small piece of work done. The to-do list can be your risks - what are they (the list), what do we need to do about them (if anything) and if anything (by when) dates.

I was not trying to belittle/insult the PM industry in the slightest. I have spent nearly 18 years in the IT/Telecoms world heavily involved in projects and am well aware of both what project management is and the purpose it serves.

The projects that went well were when the PM/PMO focused on the end-game/customer with a greater emphasis than those who succumbed to complex and intense processes and the need to have the internal machinations of that process fulfilled regardless of what was happening in terms of delivering and satisfying the customer.

The trick is to get the process to serve the project, not the other way around i.e the project not the process is the end result.

I hope that clarifies the point that was being made.

Best to you all
Barney

If as the author says PM is just a list with end dates, then let me educate the author. PM is the ability to create the list in the first place, understand what order the list must go in in order for the end result to happen, and knowing what to do when things on the list go bump, while keeping the whole end date in check. It is also knowing which items on the list are most critical to the end result.

Alastair Cockburn has a theory/hierarchy of use cases in software development that applies to PM, also. Who needs what; how do they get it; what can go wrong; and what do you do about it. A lot of PM is about asking and answering those four questions.

However, I have to disagree that project management is only to-do lists with deadlines. I think a lot more has to go into project management to make it successful, such as incorporating communication and collaboration around all tasks and projects. When team members work together on projects, the outcome is much better than what just one person could have done by checking off a task on their to-do list.