This is a rant. Hopefully it also presents some elements of solution.

Some work environments are more demanding than others in "administrative" duties. Sometimes it's even less than obvious to identify people and activities that actually produce value. I have worked in organisations where an inordinate amount of time and energy is dedicated to project management. Worse, an absurdly high proportion of people are actually called project managers, project coordinators, and the like (note: I was sometimes part of them).

We have reached a point where project management is constantly reinventing itself and expanding its responsibilities, to such a degree that it's starting to cripple organisations. Activities of project managers, project coordinators, project controllers, project management officers, team leaders, and related functions eat a huge chunk of the total effort. It sure does generate a lot of work for project managers. Actually, who is not, at least in part, project manager nowadays? The problem is that it's a vicious circle. The more complex project management becomes, the more resources it requires, and therefore the more complex it tends to become as newcomers want to "improve the process".

Now that I've shared my concern (in a rather blunt fashion), let me try to put project management in its original context.

1. Project management is a means, not an end

If we take a look at industry-specific methodologies or production processes (such as the software development process), we notice that they categorize project management as one of the supporting processes. What does that mean? Project management exists for the sole purpose of organizing people and processes so that they deliver results. In other words, project management does not produce any direct value. Rather, it enables core processes and teams to produce value. We infer that we should do the least project management possible while supporting the processes and teams appropriately. In costing jargon, project management costs can be categorized as overhead.

I observed that most project managers and organisations do not understand this aspect. Typical symptoms are:

• The effort to produce project management artefacts often exceeds the benefits of having these artefacts.
• The project's success and the project manager's skills are evaluated against conformance to a standard rather than against client satisfaction (the standard applied being usually unrelated with client satisfaction).

2. Management is second to leadership

If you look back at your experience in order to remember project managers (or whatever their title was) who left a good impression both on you and in terms of achievement for the organisation, I bet it was not because of how good they were at producing coloured progress charts or how well they mastered MS Project. It's probably more along the lines of how they could translate the business objectives in actions, motivate team members, understand stakeholders from various fields, and earn the respect of all. In short, leadership.

When dealing with a project manager, I'd rather have a good leader than a good manager. Indeed, not only is leadership more critical than management to the project's success, but on top of that project management techniques are much easier to learn than leadership aptitudes. (see for example the 16 project manager traits, by Marios Alexandrou)

If you recognize that your organisation is plagued with this problem – namely over-managing projects – let's look at three changes that can help bring back project management to its rightful place.

1. Transform you project managers into project leaders or coaches: the goal is to make sure project managers work with and for the team (remember, they are supposed to support the team), and not the other way around. In this sense, leadership and coaching skills are more useful than project management techniques. More than skills, it’s a question of attitude.
2. Establish meaningful metrics: metrics influence how people behave. If they are not aligned with the desired results, then desired results will not happen. Meaningful metrics should reflect what really defines project success according to stakeholders (not just the client). In particular, understand that traditional metrics such as blindly respecting budget, schedule, and scope are flawed (the three constraints are often infamously referred as "the iron triangle"; read Scott Ambler's article Something's gotta give).
3. Trim you project management process by removing anything that doesn't clearly add value. Alternatively, configure your project management process in order to better take various types of projects into account. The process should adjust, for example, to project size (scope, budget, team), criticality, and degree of risk. In other words, the amount of conformance requirements should depend on project characteristics, risks being the main one. When facing a new challenge or a new conformance regulation, examine aggressively whether simplifying the processes and structure might not be a better solution than adding yet one more layer of process. It often is, but it takes insight to notice it and courage and power to implement it.

As an endnote, I believe that Agile practices have a lot to offer to help balance people vs. processes, as well as project needs vs. conformance requirements.