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.

Many organizations face the challenge of moving from a situation where they produce a limited number of standardized products, to a situation where they have to constantly tailor their products and innovate in order to remain competitive. These two situations require very different organizational structures. The first one is better served by a functional structure, whereas the second one is made easier by a project structure (or a matrix structure with a strong project component).

As a whole, a functional organization is best suited as a producer of standardized goods and services at large volume and low cost. Coordination and specialization of tasks are centralized in a functional structure, which makes producing a limited amount of products or services efficient and predictable. - Wikipedia

In a project organization, team members are often co-located, most of the organization's resources are involved in project work, and project managers have a great deal of independence and authority. - PMBOK 4th edition

Analyzing the situation and writing a nice diagram of the new structure represents no more than 1% of the work. The 99% remaining consists in convincing people and in making it happen. It's interesting to have a look at how different stakeholders might be involved or affected by such a transition.

Top management has to champion the transition. It is not an issue because executives and high-level managers will benefit from the change while their power will remain essentially unaffected (they are located "above" the change of structure).

Workers tend to adopt the change without too much trouble because they usually benefit from it. Indeed, when functional silos generate inefficiencies in projects, the project gets delayed and ultimately the team is subject to more pressure and frustration.

The problem usually comes from mid-level functional managers, who perceive the change as a huge loss of their power. Instead of having project managers reporting to them, they will have to support project managers by providing the required resources. Actually, it is not so much a loss of power than a refocusing on what functional managers do best: manage a pool of specialized talent and other resources.

Although project managers gain power and therefore tend to embrace the transition toward a project organization, some issues can surface. For example, in a functional structure many project managers do little more than coordination (no insult intended). They might have to be trained and coached in order to properly manage other aspects of projects, such as acquiring and developing the team, really managing budget, scope, schedule, quality, and so on. Whereas project coordination is essentially a support function for the project team, project managers have to lead the team, which requires very different aptitudes.

Moving from functional to project structure also calls for fundamentally redefining what a project is and the related processes. A project typically spans several functional areas. However, in a functional structure, each so-called project usually spawns one relatively independent project for each functional area involved, with a separate project manager. For example, the software development department will have a project manager to take care of its very own software development project, the QA department will do the same for QA, and similarly for marketing, IT infrastructure and so on. The scope of the project that should normally span multiple functional areas, along with its budget and other aspects, will similarly be chopped down in narrow functional slices (making project-wide coordination a communication hell). The project management process has to be adjusted in order to take the new organizational structure into account.

In an organization producing software solutions, the driving force behind the transition from functional to project structure is usually the software development unit. Indeed, although in truth the success of a project depends on all stakeholders and not just on the development team, the latter is widely regarded as responsible for the project's success or failure. In other words, the development team will often carry the burden of inefficiencies caused by an organization structured in functional silos.

As we can see, structure, processes, and culture are intermingled. Change one, and you have to adapt the others.

While working on Agile software development projects, we often hear that we should "avoid writing useless documentation", or "write the minimum amount of documentation".

However, teams usually fail to interpret this principle in the situation at hand. More often than not, the team only produces documentation that is strictly required to deliver the software to production. This is a case of developer myopia.

It's a matter of correctly interpreting the right amount of documentation beyond what seems obvious for developers. In other words, the documentation that should be created is not determined solely by the development team, but also by other stakeholders.

The following needs for documentation can be used as a checklist.

• Users need a user manual.
• Maintenance team needs a document that describes how the product works in order to fix bugs and make it evolve without depending on the team that developed the product.
• Teams developing or maintaining other systems need to know how to interface their systems with the product.
• IT infrastructure team needs to ensure reliable product installation and updates, to understand how to remove, start, restart, and stop the product's services, to implement application security, and to understand the systems and network requirements.
• Controllers and auditors need to assess applicable controls according to internal standards or standards such as ISO, without depending on the development team.

The more complex the organisation, the more diverse stakeholders are.

As you can imagine, it is usually after the development team is disbanded that the lack of appropriate documentation starts causing problems – big problems.

Agile doesn't remove the need for documentation, it helps optimize what documentation should be produced (as little as possible while satisfying the needs) and when (as late as possible).

Interestingly, it brings us to broaden the definition of value – a central Agile concept. If it has to be produced, then it does deliver value. Therefore, value is not just "working software", it's everything that stakeholders need.

Whether we're asked to adjust a process, redefine objectives, or restructure a team, the ability to manage changes will serve us better than hard skills in the topic.

I've found Kotter's 8-step change model a good guidance to implement changes. However, I'd like to add two ideas.

Building a case for change can involve both objective and emotional arguments, such as:

• Cost-benefit analysis
• Success stories
• Enable organisation's strategy
• Solve frustrations
• Leverage pride

The ability to make changes also depends on the ability to convince or influence others. In this area, I suggest working at both the group and the individual levels, with appropriate techniques. For example, the people we can convince with a formal presentation are very different from the people we can convince with an informal face-to-face conversation. The message that we want to convey also conditions the technique.

The "techniques" include:

• Formal presentation, larger audience and limited interactions
• Meeting with a few people, open discussion
• Spontaneous face-to-face discussion
• Discussion over lunch or coffee
• Email

It is a good idea to meet with sceptics individually, as it may help to better address their concerns in order to bring them on board. Similarly it's a good idea to include a champion (convinced person) in a meeting with people who are not yet convinced.

Just look back at your own experience to identify a situation when you were able to convince people to buy in your idea. You can guess which techniques were effective. Most of us use these "techniques" unconsciously. Great influencers naturally mix and match the techniques for great results. If you have such a person around you, try learning from him/her – it's the best way to improve this skill. Have also a look at the related topic of stakeholders management.

Wouldn't it be nice if we could make an educated guess about the Agile potential of an organisation without doing a full scale assessment? Let's look at signs that any observer can notice when spending a few hours in the workplace.

1. Detailed procedures about everything: They assume that there is a reusable recipe for any situation. They ignore that many situations are unique because needs and context change everyday. Procedures and processes are not bad in themselves, detailed directive procedures are.
2. Client out of sight: In some workplaces the client is a kind of abstraction, an entity we contact by email and the occasional meeting. Collaboration is reduced to a few key events such as capturing requirements, reporting at milestones, and validating tests results, without much else in between.
3. Coworkers out of sight: Individual cubicles with high walls, narrow corridors, and the like. Workplace arrangement significantly influences how people behave and collaborate. If it fosters individual, analytic work, don't expect much collaboration beyond the few formal meetings and emails.
4. Meeting mania: A by-product of the other points, meetings are scheduled for any reason. Most of these reasons would be better served by a brief face-to-face discussion. Unnecessary meetings introduce delays (rooms and people are overbooked) and tend to waste the time of many participants.
5. Detailed timesheets: They epitomize the belief that work can be forecast in detail. People consciously or unconsciously alter their behaviour in order for their daily work to fit in timesheets. Note that timesheets are not bad in themselves, detailed timesheets are.
6. Restricted access to internet and to personal email: Security hazard vs. work/collaboration tool. For me the choice is obvious, but apparently not for everyone.

I don't pretend this short list replaces a professional assessment, but it might provide a few hints.

How can we adopt Agile if the organisation seems at odds with Agile prerequisites?

Note that it is highly uncommon for an organisation to be just ripe for Agile. I have yet to see a workplace where Agile practices can be implemented quickly and on a full scale. In most cases, follow these simple guidelines:

• Choose scale: Identify pilot projects, teams, or organisational units
• Choose practices: Determine which Agile practices make sense and implement agile progressively
• Assess added value: Always keep in mind that Agile is not an end in itself. Assess objectively if and where it can add value.