How does a PM differ from a TM?
There are enough questions posted about the need of TM being a PM and PM also being a TM.
The confusion arises because of the misunderstanding of the roles and responsibilities of a PM. A PM is supposed to plan, manage and control the different aspects of a Project namely, Scope, Time, Cost, Quality, Risk, Human Resource and Communications (as per the PMBOK). So if we go by this standard also technology is not involved.
Taking it to the next level, a PM has to do all these project related responsibilities with the help of a "Team", and a Project Team according to me should be complementary to the PM and vice-versa. This team infact should have people expert and experienced in the technical aspects of the project (a Tech Lead, technical people like developers or testers or QA engineers etc).
As a combination these two (PM & Team) should work towards delivering the project successfully. You take any one out and the project is a disaster. Similarly you reverse the roles (a PM doing the Technical things; and the Team planning and managing the Project Scope, Risk, HR, Time, Cost Communication etc), and the project again will be a disaster.
2 comments:
I love this. Whenever I suggest that technical knowledge might not be a prerequisite for success as a PM, people trot out the "small project argument." Please go back and look at my original post. The small project PM is often called on to function as an individual contributor. In that role (PM plus team member), they obviously need technical skills to perform their work as a team member. That does NOT mean that their performance as a PM is enhanced in any way by their technical skills.
And Jim reinforces my point when he notes that the PMs for the 777 and the Step Pyramid probably had INDUSTRY knowledge. There is a huge difference between having industry knowledge and having technical knowledge. For example, I understand the baby-birthing industry, but I couldn't make a baby if my life depended on it.
I absolutely agree that knowledge of the industry and/or technology is useful. The questions are really this:
-- Is it necessary in advance? Or can I pick it up while functioning as PM?
-- Why can't I rely on my technical experts? If they don't respect me, then they don't belong on my team.
I have led project teams where I knew absolutely NOTHING about the domain or the technology and been successful. I know several others who have done the same. We are clear PROOF that technical skills are NOT necessary even though they may be desirable.
You might not need "technical skills" in particular field the project involves, but you better have "people skills" and ability to be quick learner and respect the skills of the people (ALL THE PEOPLE) you have working on project. You may or may not be their boss. You may be the project manager on the same level as the people working directly on project. To be a good project manager, it takes more than just calculating time, schedule, budget, milestones, inspection, QA, production/release, post-mortem, and so on. Although you might not know specifically how code is written, you should understand the capabilities of a programmer. Although you might not know specifically how to control a cement mixer or how to calculate tensile strength of concrete, it helps if you understand how long it takes for cement to dry and set. In fact, if you neglect how long it takes for cement to dry and set (and if you refuse to listen to those who are pouring the cement when you schedule your project), you will have major mess.
Project managers should know metrics of many different facets of their project. The time and materials for metal-working, the time for foundation pouring, the total areas and cubic feet of concrete needed, the number of software iteration cycles needed, and so on. Do not neglect time required to write reports or user documentation--the writers are "technical experts" in their fields as well. Most good writers know their metrics for documentation projects as well as carpenters can look and calculate board feet and time-to-build, or cement workers know the cubic feet required and setting time for the poured concrete. One of my friend who is writer for software company is frequently frustrated because when project schedules are developed, the PM caters to the engineers and technicians, but never asks the writers on how long it will take to write the manual. The sales people are allowed by management to agree to ridiculously tight deadline to "get the sale", the software people cut corners on testing to meet deadline, but don't allow time for the writers to access the development and final forms of CLI or GUI to get screenshots or code validation for the documentation. Then, at last minute, someone changes the look of the GUI--oh, only minor change in code to move button and correct spelling error. Only one or two lines of code have changed. Easy for programmer. Except that GUI screenshot is a major one that ripples throughout document--maybe 200-300 instances. Maybe 150-200 pages need changeout of GUI screenshot with the accompanying text changed to fit it as well. What is easy for programmer to fix, becomes nightmare for tech writer. Especially if this happens close to deadline. This is why my writer friends jokes about freezing the code by shooting a programmer.
As PM, you should kick off project with a meeting with EVERYONE working on the project--engineers, technicians, writers, biologists, chemists, scientists, foremen, managers, estimators, accountants (and so on--depending on what kind of project it is... obviously different staff for building a dam or highway than if building an aircraft, a power plant, or a piece of software). If the project is a commercial venture, get the sales and marketing team in the meeting as well so they understand what will be done and so the team can understand what customer want. Have regular update meetings--address all the various components and potential things that may throw off schedule. Be aware of unexpected problems that might happen--have contingency and backup plans available--because things will usually get screwed up. Hear and relate to the science team, the accounting team, the estimators team the writing team, the production team, and the warehouse team. You may not have the expertise or "technical skills" in the individual components of the project--but you better have the people skills and quick learning ability to make this whole thing come together.
Post a Comment