Project Management

Project Management Central

Please login or join to subscribe to this thread

Topics: Agile, Strategy, Talent Management
Project Manager vs Technical Project Manager
What is the difference between a Project Manager and a Technical Project Manager?
What do recruiters really mean when they say they are in need of a Technical Project Manager?
Sort By:
Page: 1 2 3 4 5 <prev | next>
Strong opinions are always expressed on this subject as we all have ideals of the quintessential project manager. To be honest, we TEND to mold this ideal based on “reflections of self” (at least I have this tendency); which is normal as we make judgments based on our personal experience/background/education/belief.

However, there is NOT a single mold that captures the ideal - on this, I hope we agree. The functional truth is that the requirements of the organization we are engaging (or attempting to engage) defines the parameters of the Project Manager, whether it be in alignment with our perception of the ideal or not.

The purist (not a negative word) or traditional role of the Project Manager with technical-PM and strong leadership skills who manages projects without having subject-domain acumen is a “strong and valid position” that works great in well-structured and stable environments. However, it may not be enough when dealing with disruptive technologies, less than stable environments, PMO immaturity, politically charged, or other exasperating environmental project characteristics.

Please understand, that I’m not saying that the traditional PM cannot manage these types of environments; I’m instead saying that the traditional PM may not be as “responsive” to managing issues in these environments than one who has acumen (what I call Architectural Awareness) in the subject domains. Ability to adapt quickly when the project-ship is in a storm is critical to organizations, especially those that are trying to transform, as the inability to quickly adapt could find the project-ship too far off course to reach the original objective.

PMI has recognized the need for PM transformation through its rollout of the Talent Triangle, PMI-PBA certification, and other current and future programs. Therefore, let’s accept the “different molds” of project managers, continually enhance our skills as PMI is directing and transform the perceptions of our profession one project at a time.

Sorry for the long comment – got excited on the subject.
| see three different views when it comes to this topic:
a) The should not be any differentiation
b) The TPM and PM differ in that the TMP performs technical tasks
c) The TMP and the PM differ in that the TMP has technical domain knowledge

My experience has always been that (c) is the most prevalent. Typically it would mean that in an IT/Dev environment the PM will understand the technical jargon and have a high-level understanding of SQL (as an example). It is not important because they have to do the work but it is important because they can make decisions much quicker (and hopefully better).
...
1 reply by Adrian Carlogea
May 20, 2019 3:40 AM
Adrian Carlogea
...
Agree with you, especially with the last part where you say that the technical knowledge is important not for doing the actual work but for taking decisions quicker.

I will add and say that a PM that has no deep technical understanding usually can't take decisions at all when in comes to issues directly related to the actual work being performed.

Such PMs, when comes to managing the project team, mainly track the progress and report it and also help solving non-technical issues for instance by escalating them. They can't provide real leadership to the team they act more like facilitators rather then real decision makers.

A non-technical PM can only manage projects in a weak-matrix environment and not because he is not given enough authority but because he lacks to knowledge to use the authority.
May 20, 2019 1:03 AM
Replying to Anton Oosthuizen
...
| see three different views when it comes to this topic:
a) The should not be any differentiation
b) The TPM and PM differ in that the TMP performs technical tasks
c) The TMP and the PM differ in that the TMP has technical domain knowledge

My experience has always been that (c) is the most prevalent. Typically it would mean that in an IT/Dev environment the PM will understand the technical jargon and have a high-level understanding of SQL (as an example). It is not important because they have to do the work but it is important because they can make decisions much quicker (and hopefully better).
Agree with you, especially with the last part where you say that the technical knowledge is important not for doing the actual work but for taking decisions quicker.

I will add and say that a PM that has no deep technical understanding usually can't take decisions at all when in comes to issues directly related to the actual work being performed.

Such PMs, when comes to managing the project team, mainly track the progress and report it and also help solving non-technical issues for instance by escalating them. They can't provide real leadership to the team they act more like facilitators rather then real decision makers.

A non-technical PM can only manage projects in a weak-matrix environment and not because he is not given enough authority but because he lacks to knowledge to use the authority.
Hi Joseph,
I second @Jatinder’s & @Ramakant’s thought. It’s just that the hiring team is giving more weightage to hire someone with technical skills who understand the technical aspect of project better, to make techno commercial sense. Since their focus of attention is more on technical aspects, quite possible other areas could be distributed among people within a team. Being technical focused comforts the team when they face technical issues and at the same time customers are put to ease who talk to one person instead of many sme. This is not a parlance used within an organization. One does not talk in the organization, are you are technical PM or function PM. What I will be focusing on for from a particular candidate. It’s as simple.
It is a really good question. I remember one of the first lessons about PMP where the teacher told that if you're a Project Manager you can manage every projects without having the technical knowledge.
However, in some of companies where I worked the persons called PM often were only like Product Manager exactly as some of you described. They called them as PM without any concern about Planning/Budget/Risk, but they were involved only in requirements collection and document approval.
In my opinion, many organization doesn't completely know what PM's role means.
I believe that a project manager is preferably have some technical expertise extent because this will help him help the team with navigating through issues and different solutions . Also unfortunately I have found that some technical team members keep their work in a dark box where you really doesn't know if this tasks really takes such amount of time .
May 19, 2019 7:33 AM
Replying to Adrian Carlogea
...
The technical PM does not necessarily have to perform any of the working activities on the project. He just needs to have the knowledge and the skills some of the team members have.

This is crucial otherwise the PM can't direct the team members, can't check and review the work being done and in the end he can't ensure the work is delivered on time.

When it comes to managing the team a non-technical PM is just a tracker and a messenger and not a real manager or leader for the team. This is not theory is something that I have noticed.
Review the work being done? I verify the work is done, I do not review it.

Reviews, inspections and walkthroughs should be done by and for the team members, not the project manager. It's not my job to review deliverables for completeness, accuracy, efficiency or adherence to standards. That would be performed by the quality control team.
...
2 replies by Keith Novak and Thomas Walenta
Jun 12, 2019 2:36 PM
Thomas Walenta
...
Exactly Stephane
Jun 12, 2019 3:54 PM
Keith Novak
...
I agree on the project output deliverables but not the plan input deliverables.

Particularly on large projects, where there has been a lot of change activity, I audit the statement of work provided by the teams to ensure that they include everything, and they are appropriate based on the contracted SOW. This is to assure that they didn't miss any major items that may have come in as part of a change request, added any additional SOW for things that are outside of scope, and ensure they aren't padding their hours.

In one position I held, we referred to the process as "Bright Light" referring to the old movies where a police interrogator would point the desk lamp into the eyes of the person they were questioning.
Jun 12, 2019 2:30 PM
Replying to Stéphane Parent
...
Review the work being done? I verify the work is done, I do not review it.

Reviews, inspections and walkthroughs should be done by and for the team members, not the project manager. It's not my job to review deliverables for completeness, accuracy, efficiency or adherence to standards. That would be performed by the quality control team.
Exactly Stephane
Jun 12, 2019 2:30 PM
Replying to Stéphane Parent
...
Review the work being done? I verify the work is done, I do not review it.

Reviews, inspections and walkthroughs should be done by and for the team members, not the project manager. It's not my job to review deliverables for completeness, accuracy, efficiency or adherence to standards. That would be performed by the quality control team.
I agree on the project output deliverables but not the plan input deliverables.

Particularly on large projects, where there has been a lot of change activity, I audit the statement of work provided by the teams to ensure that they include everything, and they are appropriate based on the contracted SOW. This is to assure that they didn't miss any major items that may have come in as part of a change request, added any additional SOW for things that are outside of scope, and ensure they aren't padding their hours.

In one position I held, we referred to the process as "Bright Light" referring to the old movies where a police interrogator would point the desk lamp into the eyes of the person they were questioning.
...
1 reply by Stéphane Parent
Jun 12, 2019 4:51 PM
Stéphane Parent
...
As do I, Keith. I was focusing my discussion on technical delivery. Obviously, project management artifacts, such as statements of works, should be reviewed, as well as verified.
Jun 12, 2019 3:54 PM
Replying to Keith Novak
...
I agree on the project output deliverables but not the plan input deliverables.

Particularly on large projects, where there has been a lot of change activity, I audit the statement of work provided by the teams to ensure that they include everything, and they are appropriate based on the contracted SOW. This is to assure that they didn't miss any major items that may have come in as part of a change request, added any additional SOW for things that are outside of scope, and ensure they aren't padding their hours.

In one position I held, we referred to the process as "Bright Light" referring to the old movies where a police interrogator would point the desk lamp into the eyes of the person they were questioning.
As do I, Keith. I was focusing my discussion on technical delivery. Obviously, project management artifacts, such as statements of works, should be reviewed, as well as verified.
Page: 1 2 3 4 5 <prev | next>  

Please login or join to reply

Content ID:
ADVERTISEMENTS

"The purpose of art: to make the unconscious conscious."

- Richard Wagner

ADVERTISEMENT

Sponsors