Random Acts of IT Project Management

Project Management for Information Technology

Why the Role of Project Manager is Different

Posted by iammarchhare on 8 May 2009

Earlier I posted about “Why Being a Project Manager is Different” to differentiate PMs from managers.  However, from discussions with some companies over the past 2 – 4 weeks, I have come to the conclusion that many companies just don’t know what a project manager does.

In essence, project management is “the application of knowledge, skills, tools and techniques to project activities to meet project requirements.”  In my article, “What is software project management”, I point out that “Project requirements are the necessary deliverables of the project. Requirements are the answer to ‘what are we making’? [sic]”

Not only does the PM put together a plan that enables an end product, but the PM is also responsible for controlling the cost, schedule and scope of the project itself.

You would think that would be obvious, but you would be wrong.  How do you tell if an ad for a job or a consulting gig is looking for something else?  While any and all of these might be legitimate under certain circumstances, they should be red flags that lead you to question what is meant by them (because there is a good chance the company may not know what they are really looking for):

“Hands on” project manager: What does “hands on” mean?  I consider myself pretty “hands on” because I run the project.  I question people’s timesheets.  I ask them why things are taking so long.  I interfere and get them help if needed.  I do EVM calculations whether you ask for them or not (because it helps me do my job).  Do you want me to code?  Then you are not looking for a PM.  One thing I learned in the Army is that a supervisor doing the work distracts the supervisor from getting the job done right.  If you want a project lead, then why not ask for a project lead?  By the way, unless it is a series of very short projects, the team will almost surely eventually fail doing it that way.  You will still need someone keeping an eye on the forest while your “PM” is looking at the trees!

“Technical” project manager:  This one is similar.  However, it can be legitimate if you have junior people that directly report to you.  If you are wearing both the resource and project manager hats, then you will need extra time for mentoring/coaching, training, etc.  I’ve done this role, and it can be quite fulfilling as long as the organization backs you in both capacities.

Project/Program manager: This one actually may become the wave of the future.  Of course, the caveat is whether or not the company understands the differences and similarities in the roles.  In general, though, there is a larger push for project management to lead into program management.  Some “Sr Project Manager” roles are actually a type of program/project manager amalgam.  I throw this in as a caution that you probe to see if the organization you are getting ready to get involved in knows what the role means.

Implementation project manager:  I sort of hesitated adding this one, as it is a legitimate role on very large projects.  The problem is that I’ve seen it applied to very small projects, and it usually is not justified.  The main question to ask: Are there PMs overseeing the design and construction phases of the project?  If the answer is “No”, then this role is nothing more than someone to blame when everything hits the fan.  2 other important questions to ask are: “Who is responsible for testing and how are the bugs found in the field after implementation tracked back?”, and “Does this role also take over the maintenance phase of the product?”  The former probes into if there is feedback to the correct team (the ones coding).  The latter question tells you if it truly is a project management role, because maintenance never ends until the product support does.  Remember, projects come to an end, even while the product lives on.

I’m sure there are others that are out there.  These were just the ones that particularly stood out for me.  I’d be happy to hear what others may have been encountered.

Advertisements

3 Responses to “Why the Role of Project Manager is Different”

  1. […] In essence, project management is “the application of knowledge, skills, tools and techniques to project activities to meet project requirements.”  In my article, “What is software project management”, I point out that “Project requirements are the necessary deliverables of the project. Requirements are the answer to ‘what are we making’?”……[read entire article] […]

  2. […] to what I posted before that, while a technical project manager can be a legitimate role, but that companies often don’t understand what they are really looking for when they look for a “project manager”.  If you want someone […]

  3. […] it comes back to different interpretations of “hands on”.  Like I discussed in the post “Why the Role of Project Manager is Different”, “I consider myself pretty ‘hands on’ because I run the project.  I question people’s […]

Sorry, the comment form is closed at this time.

 
%d bloggers like this: