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.

Last week I had the pleasure to present La Gestion de Projets Agile (Agile Project Management), in French, at PMI Montreal chapter. I was impressed that close to 200 people showed up, making it the most popular PMI Montreal event this year so far. The main purpose of the presentation was to explore how PMBOK and Agile can be combined, particularly in large organisations/projects subject to compliance and conformance needs.

Speaking about Agile in a PMI event is bound to trigger some irrational reactions. After all these years Agile has been around, some people still feel the urge to take sides. But overall comments were contructive and I was pleased to meet with many knowledgeable people in the attendance. Agile is a big player now.

Gestion de Projets Agile V1

Risk management is a critical part of project management. However, in the real world, it's simply not cost-effective to manage risks thoroughly over all aspects of the projects. Similarly, when configuring the project management processes, we have to determine which areas deserve more attention than others. The more risks in a given area, the more controls we need.

When initiating a project, I always thought it would be great if we had some kind of guidelines as to what areas we should focus on based on the characteristics of the project. Indeed if we look at a project management method such as PMBOK, RUP, or Prince2, we notice it's rather exhaustive, if not abstract, compared to our specific needs. The task of customizing the method according to our needs can be daunting. Hence the idea to look at how risks affect different project management areas based on characteristics. More generally, the characteristics typically translate into increased workload, higher occurrence of changes, and of course increased risks.

For example, a project with a large team might require more work in managing communications, schedule, costs, human resources, and execution, while a project with high technical complexity will require special attention to manage quality, schedule and costs.

The following table summarizes my first thoughts on the subject.

* Relatively to team's experience.

Low indicates that the area deserves some specific attention. High indicates that it requires great attention. Otherwise (no indication), the are doesn't deserve any special attention.

Today is your first day on a consulting mission to assess software development practices. Okay, you have experience, you know a bunch of methodologies, and you are familiar with standards, but what would be your very first actions as a newcomer who doesn't know anyone or anything in this organization?

Tough spot.

Here's a hint: it's all about people.

At first sight it may seem surprising that the success of assessments and audits depends more on the ability to relate with people than on the knowledge of methodologies or standards. Although the later is important, it doesn't matter how good you are at it if you can't create good relationships with people. Indeed, to assess you need information, and to collect information you need people to collaborate with you - willingly.

With this in mind, let's see what steps we can take to start this mission.

Meet with the sponsor to ensure commitment and understand the mission

• Gain understanding of the business objectives behind the assessment.
• Establish the scope of the mission, including what has to be assessed and what will not be assessed.
• Identify the stakeholders and how to access them.
• Agree on the deliverables and on the planning.
• Determine the mission's constraints, such as deadline and costs.
• Summarize the meeting with a document, ideally a project charter.

Pitfalls:

• Don't assume that the description of the mission you received beforehand is accurate, even if it is detailed.
• Be ready to challenge the sponsor's assumptions. The sponsor might have a preconceived idea of the assessment process and even of the result. Kindly remind him that you have been called to perform an independent review, not to find evidence for predefined results.
• Avoid stretching the scope based on what you discover. If the assessment points to issues beyond the scope, report this finding to the sponsor.
• Don't confuse the official organization's structure (titles and functions) with the way people interact in reality (roles, influence, and informal channels of communication). Create your own view of the structure and analyze how stakeholders interact with each other.

Meet with the stakeholders to create a sound foundation for collaboration

You have to defuse resistance. The second you step in, the resistance bomb starts ticking. In order to avoid having to overcome resistance later on, take the initiative to communicate.

• Explain why the assessment has been requested.
• Explain how the assessment will be carried out.
• Emphasize the opportunity for improvement and personal development that the assessment will create.
• Make sure that everyone understands that the assessment's objectives are to improve results, not to evaluate people. All information collected are anonymous.
• Be part of the team. Use "we" and "us", not "I" and "you".
• Handle questions.
• Summarize the meeting with a document and send it to all stakeholders to demonstrate willingness to collaborate and transparency.

Pitfalls:

• Don't base your communication on emails or documents. Written communication is used to prepare (for example to present a meeting's agenda) and to report (for example to summarize a meeting's conclusion), not to create trust or enable collaboration. No amount of documents can replace an in-person kick-off.
• Don't communicate without prior consent from the sponsor. Review the content with him beforehand.
• Don't introduce yourself as being called by executives. It will create suspicion and hinder the collection of information.
• Don't provide too much details. Keep it simple. Provide some additional details when answering questions.

Identify the sources of information required to perform the assessment

• Break down the mission's objective in subgoals in order to list the information you will need, then identify people who can help you with each category of information.
• Focus on people as the primary source of information.
• Contact each person individually to personalize communication and to confirm the person's roles and availability to help with the assessment.
• Ask for help to locate documentation.

Pitfalls:

• Don't trust documentation. Documents are seldom current, and what they describe seldom reflects reality.
• Be wary of people who systematically send you documents to avoid meeting with you in person.
• Don't waste your time parsing the files by yourself to find documentation. Ask stakeholders for help.

Be accessible

• Provide your contact information.
• Set up your office among the team. If you have a separate office, keep the door open.
• Be available.

Pitfalls:

• Don't become overly friendly. It might compromise your objectivity and your credibility.

There is a confusion between the terms audit and assessment. Actually I was confused by these two words until not so long ago, so I figured it might help to shed some light on this ambiguity.

An audit is a process to verify the conformance of an entity to a given standard. It consists in gathering evidence of conformance or nonconformance. Therefore, it results in a success or a failure with regard to the scope of the audit. Verification and inspection are synonyms of audit.

Example of audit: Verify that the project management practices comply with a set of best practices defined by an instance of the Project Management Body of Knowledge (PMBOK).

An assessment, on the other hand, evaluates the efficiency and/or effectiveness of an entity and results in a measure of its performance with regard to the scope of the assessment. The goal of the assessment is to gain understanding in order to formulate a recommendation to improve the entity's situation. Appraisal and evaluation are synonyms of assessment.

Example of assessment: Evaluate the CMMI level of an entity.

Note that both audit and assessment can use the same base material, such as a given project management methodology, but their goal and the way they use the reference material will differ.

We can also distinguish audits from assessments by looking at:

• Attribution: An audit might explicitly point at specific people or groups of people as the cause for noncompliance (attribution). An assessment does not evaluate individuals (non-attribution). Of course, the result of an assessment might still be used to infer responsibility for failure or low scores.
• Fault: Whereas an audit results in a success or a failure (fault), an assessment usually provides a score that does not express success or failure (no-fault). With an assessment, one can freely decide which score constitutes a success or a failure if they want to, but this is done to identify the areas that should be improved and not to judge people.

As you can see, the difference doesn't lie only in the goal and in the process, but also in the mindset.

Additionally, we have to mention that the two words audit and assessment generate very different reactions. Audit is associated with distrust and punishment whereas assessment is often seen as an opportunity for improvement. Unfortunately I have personally witnessed audits disguised as assessments. Instead of resulting in a healthy improvement plan the results have been used to blame people and terminate projects.