Please login or join to subscribe to this thread
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).
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.
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 .
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.
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.
Please login or join to reply