A practical statement of what a technical project manager does

When we think of project management, we generally think about either software project managers or PMI certified folks who manage communication streams.  However, we rarely talk much about the life of a technical project manager, one of those competent folks who grew up though the technical ranks and took his place as a project leader though wit, skill, and the ability to communicate clearly to non-technical audiences.

These folks combine the often conflicting roles of technical manager, communicator, and quality assurance analyst.  They also assess technical risks, assist with technical problem solving, and cut though the layers of bull-feathers surrounding any given technical project to determine what is really going on.  Within their own technical areas they can estimate project time-lines to within hours of actual work; outside of it they can make accurate guesstimates based on years of technical experience.

More importantly, technical project managers think like IT professionals.  They understand the allure of difficult problems, the "explicit answer to the question we want to avoid" strategy IT people deploy to avoid conflict, and the need to save technical face for the team even when it would be easier to hang someone out to dry.  This allows them to get straight answers and good work out of employees non-technical project managers would classify as hopeless, negative, or uncooperative.

On any given day a technical project manager will:

  1. Write a status report
  2. Compose a dozen communications emails
  3. Help his team prioritize the latest set of technical issues
  4. Assist his team in identifying the problem at the root of several technical issues
  5. Employ one or more mitigation strategies for technical risks
  6. Pull at least one IT professional out of a tempting rabbit-hole - also known as an unrelated technical problem 

This work has to get done.  It also shades into the realm of team leaders, lead analysts, and others who might be more technically suited for specific tasks.  This creates a very confused situation, especially when technical project managers move from one organization to another.  What role do they play?  How does the technical project manager, with his technical background and grounding in IT methods, fit into a PMI process-oriented organization?  To what extent does he need to change, and to what extent is the role of the TPM simply misunderstood?

Oddly enough, I'm actually working on a book that talks about some of this in greater detail.  I'll post more about it when I've done some more research. 

Editor's Picks