Is it beneficial to the Project Manager (and the entire project) if project team members have been exposed or completed some level of Project Management training?

In practice team members in a project work directly with relevant stakeholders and usually it is not the PM the one who tells them what to do, not even at a very high level. Most PMs work as facilitators ensuring the communication between stakeholders is efficient. So I think the analogy between the PM and the military commander is not appropriate in most cases.

Regarding team members trained in project management I think this is an important factor for the success of the project especially when the PM has no good domain knowledge.

For example you may have some team members working directly with the customer. The customer may be asking for things that are not on the scope and if the team members don't know much about project management they may be working on those items without raising a change request.

The PM should be managing the scope but many times since they don't get into the details of the work they may not be aware that things that are not on the scope have been requested. The team members are much more aware of this fact but if they have no project management training they may not care and may just do what the customer tells them to do.

I have seen a project that delivered successfully but produced a big loss because the scope was not properly managed and the team members just did what the customer was asking them to do without caring if the work item was or not on scope. In the end the customer refused to pay for the additional work change requested had not been raised.

I actually am a fan of ensuring that everyone involved with contributing to or supporting projects has a fundamental understanding of the discipline. If we expect that PMs should have sufficient technical domain expertise to be effective, why shouldn't team members understand "something" about what we do?

Kiron

Your experience is very different than mine in the stakeholder communication regard. I'm not saying it's right or wrong however as businesses vary widely, merely that it's different.

As a PM, one of my very top functions is acting as a filter for information. Most team members do not communicate directly with anyone but with other teams where their product level work directly interfaces with another internal team. This is necessary for a few reasons.

- With many internal and external organizations, each with multiple team members contributing, the communication channels would be unmanageable. People wouldn't know who to talk with. Some people would be overwhelmed with emails and calls. Information would be different from many sources. I sometimes attend 5+ hours of meetings and then spend the next few hours disseminating accurate information to the right people before I can work on my own deliverables.

- Not everyone is allowed to talk to all the stakeholders. Talking with customers and suppliers often involves a dedicated representative from a customer or supplier facing organization. It is easy for misunderstandings, or people not knowing where the boundaries of their authority ends to request things or commit to things that have significant contract/cost implications. If they can talk directly, that rep still needs to be part of the conversation which results in another resource bottleneck.

- Not everyone has the skillset or perspective to talk to all the stakeholders. If fiance asked for cost estimates from 10 groups, they'd get 10 different formats, many of which unusable. Team members may not understand the scope of what their desired change impacts so my job is to review it and identify everyone else involved. Executives don't want to listen to 10 X 40 minute presentations on the progress of a project, so I summarize all the inputs into 10 minutes with key points highlighted.

This is where communication skills on my end become critical. I have to make sure that the right people get the right information in a very consistent and accurate way. When something comes up, the top level stakeholders come directly to me, to go talk to everyone else and either give a consistent direction, or to figure out what is going wrong so that we can go fix it.

Beneficial yes, required no.

I think it would be better to give an example because I don't think I was clear enough.

Imagine a software implementation project (including development) that got to the User Acceptance stage. A group of real users are testing the software before it goes live and either accepts it or rejects it. During testing the users raise defects against the software.

Who can deal and fix those defects? The project team of course. In order for this to work there is no other way than the team members or some of them to directly work with the users, sometimes even with the sponsor. Obviously the direct interaction would be limited to User Acceptance tests and the PM can be involved as a facilitator.

Not all the defects raised by the users are really defects, users may raise defects for several reasons such as:
- lack of training, the user does not know how the functionality should work and raises the issue as a defect
- the design or the User Story failed to capture some real life scenarios
- the software works as designed/configured but the users realize that this is not what they wanted (even if they were involved in the requirements gathering process)
- the software works as designed offers the right functionality but the users want additional functionality.

Determining which are real defects and which are not can only be done by the team members that have deep understanding of the functionality. Usually PMs don't have such understanding as they don't go too deep into the details.

If the team members have no project management knowledge they may end up pleasing the users and solving all of their problems even if they end up adding new functionality. This could lead to the project going over budget and there isn't much the PM can do about it as he does not understand in details the issues raised by the users.

If the team members do have some basic project management knowledge then they can advise the PM on the situation so he can raise it with the sponsor. The sponsor or someone on his behalf can then decide what to do, extend the budget, remove some requirement, etc.

Hope is clearer now. :)

Adrian,
I understand much better. I see your example as applying to specific types of projects, I'll provide an example of how not all projects work that same way.

Let's say I'm managing the development of a new electonics system that will be marketed to many different airline customers. We want most of that to be identical regardless of who purchases it, but each customer can customize their UI for usability preferences and branding.

The system consists of electronics boxes, monitors, wiring to connect the electronics, structure to support the hardware, cooling for the electronics, an operating system common to all customers, and unique software for their UI.

Most of that is invisible to the end customer and they don't get a say. For most teams, their "customer" is a system architecture team, or some other design team who drives their specific requirements. Wiring alone will have many different teams depending on whether they create schematics, or determine how to route wires in an existing vehicle and most people can't even figure out which group to contact based on the names from an org chart.

In that case, I may have an end customer requesting changes that can potentially impact other customers. Other changes may be in-work that impact what our end-design will look like or conflict with our plan. Regulatory changes come in that apply to some but not all teams. The testing facility wants to move dates around to re-prioritize their own work. The electronics vendor wants to change things that involve interfaces to one or more teams.

Most of the people requesting changes don't know who all they actually impact. The various team leads and PM coordinate together and know the overall plan, but most of the people doing detailed design work don't. They don't have the overall knowledge of what going on with other projects or how it might affect them.

Since those project team members have a very small view of what is going on and are task driven, most of what is going on from the PM side is irrelevant to them. They primarily need to understand their discipline, and that they don't change the plan unless it comes in writing from the right authority.