Please login or join to subscribe to this thread
I think you hit the nail on the head when you said that the credibility (or lack thereof) which folks place on the title has a lot more to do with their personal experiences to date than with any formal roles & responsibilities documentation or value propositions/statements.
I've always felt that the elevator pitch for our profession was bringing predictability to uncertainty when implementing change, but that looks great on a bumper sticker or coffee cup and won't change hearts and minds the way personal experiences will.
This is why it is so critical that each PM wearing that title strive to overcome any such perceptions so that stakeholders are left with positive impressions.
Sad as it may be my personal experience is that what most people are looking for to justify PM value is "let me do that for you" and "don't worry about it, I'll get it done for you". As we know what engages people is the simple "what's in it for me". All the hard/soft/squishy skill a PM might have is of little consequence for the average stakeholder if they do not hear that they can relax while somebody gets it done.
Your elevator pitch “bringing predictability to uncertainty when implementing change,” in my opinion, encapsulates the quintessential qualities of a project manager. I say this, as the following statements would characterize such a PM:
- They are “Strategic Change Agents.”
- They are “Accountable for Project Success” and “Empowered,” as one cannot truly be an implementer of change without these qualities.
- They have “Domain-Focused Business Management Skills” (i.e., a degree of), as one would not have much ability to bring predictability to uncertainty without knowledge of the engaged domains.
Unfortunately, these three (and other) points always seem to create controversy due to one’s underlining “world view of project management,” hence the narratives that skew our value.
I think Project Manager is defined by what a person with that title is authorized or empowered to do rather than what one is supposedly held responsible or accountable for. Many PMs are told they are responsible for 'project delivery' and are portrayed as such to stakeholders however when you drill down you find that there is little, if any, underlying authority to make it so. When considering a PM assignment my question is always - "what authority will I have to make things happen?"
You very quickly recognize if you are in fact a PM versus administrator, conduit, or figurehead.
In my view, a PM needs to be “Accountable” and “Empowered” as they are mutually inclusive, that is, they cannot exist independently of each other – at least in the quintessential sense of the role. Stated differently, there is almost always a collision of responsibility that leads to mayhem when these two qualities “are viewed as” or “treated as” mutually exclusive.
I like to say:
- If it is unclear whether you are directing or wearing the reins of a project, then bite down as there might be a “bit” of truth to your concern.
However, not always the reality. This situation is especially problematic when the team, and other stakeholders, know that the PM has very limited authority. "Let us know" and "Can you check and confirm" becomes the response to most decisions, direction and instruction.
Having the authority to meet the responsibilities does not mean the PM is omnipotent. (S)he has to be accountable to the team, the stakeholders, the project and the corporate hierarchy FOR THE RESULTS of the decisions.
This leads to something that has been discussed here at least a million times and that is the subject matter expertise of the PM.
Projects may have cross-functional teams but usually there are relevant lines of work for each project. If the PM is not a good expert in one of those lines of work then he/she would be perceived more like a tracker, reporter, facilitator and not a real leader. The level of formal authority he has can't change this fact too much.
In my opinion true leadership does not mean engaging others to make decisions and perform the work. The leader must use his/her own expertise to make the decisions or review and validate the proposed decisions made by others. This does not mean that the leader must be the best worker it means that the leader needs a good mix of technical and managerial knowledge and skills.
On another note, Subject Matter Experts (SMEs) tend to be very focused on their subject (discipline), sometimes blind to the challenges of others with a feeling of discipline importance and priority. One of the leaders function is to integrate the SMEs so that the outcome is not skewed towards one discipline, ie; the structure is perfect but the mech/elect/instrumentation/IT is substandard.
Personally I would be concerned if I was a mechanical SME on a project where the PM (leader) is the structural SME. Seems there would be motivation and opportunity for bias, at least the perception of bias.
Ideally the PM has a better chance of success if (s)he has a technical background versus strictly managerial. However, I am not convinced that this is essential for project delivery.
While the PM's subject matter expertise is not essential for the project delivery this attribute is very important for the way the PM is being perceived by others. And that's true especially for the team members but also for the other stakeholders.
I am saying this from experience, if the PM is not an expert in a relevant line of work for the project then he is not going to be perceived as a leader by the project team members. Also the project sponsor and the business users would often bypass him and would go directly to the real decision maker.
Regarding delegation, with all due respect, I don't agree with your definition, but I admit that I may be wrong. For me delegation is only when you are responsible for doing something you can do it yourself but you choose to ask someone else to do it on your behalf.
I will try to give an example:
Imagine a software project where you have, among others, a PM, a software architect and some developers. When the software architect is making software architecture decisions he will not need any delegation from the PM. The PM may ask the architect to make those decisions but since this is not his responsibility this is not really delegation. Asking someone to do a work is not always delegation.
If the PM asks the Software Architect to attend on his/her behalf a meeting with the stakeholders regarding the management of the project then this is delegation.
Delegation is also when the software architect asks a developer to make some architectural decisions on his behalf.
Delegation is not mandatory. A PM can delegate nothing and still the technical decisions may be taken by relevant SMEs and not by himself.
The discussion that is occurring here aligns to the point of my question, that is, we all have different perceptions of what a project manager “is,” based on our interaction with resources of that title. In fact, your perception of a PM appears to be what I stated, A) a schedule tracker, B) a communication relayer, and C) a manager in name only. Hence, the image problem we have in our profession.
- A traditionally chartered project manager is empowered by executive management and acts in proxy of them. Thus, your statement that a project sponsor or business user would go around them to the “real decision maker” flies against accountability principles. To that point, a business user taking that route in my world would be making a CLM (i.e., a Career Limiting Move).
- As it relates to delegation: When an empowered and accountable PM executes their project plan (regardless of how the plan was created), he/she is delegating those tasks to their team. That is the nature of an accountable position. I understand that principle seems inequitable, but it’s a functional reality in most organizational structures.
Adrian, I have worked in the software industry for four decades and very much understand your thoughts and opinions regarding project managers, architects, technical project leads, and the like. I’m a business and IT architect who is also a project manager – and proud of it. However, I recognize from experience and the wisdom of the profession that being both at the same time is problematic.
Your experience is entirely valid and understood, but I would like you to consider is that the project managers you have experienced, or at least the ones you have described, are functionally acting as project coordinators or administrators and not the traditional (PMI based) project manager.
Please login or join to reply