On Project Management: Competency or Career Path?
Many engineering and R&D oriented companies have 3 technical career paths: individual technical professional, management, and project/program management. With respect to project management, however, many of our clients struggle with whether to treat project management as a competency or a career path, or both. We had this debate at length at Microsoft, and it was an issue when I did similar work for Pratt & Whitney and Bayer. It is a topic that stirs much interest and some controversy, and, as with many similar topics, there is no right answer. The “correct” answer ultimately is matter of strategic business direction and what core capabilities you are trying to grow.
Microsoft engineering leaders believed project management was a core competency, something all technical people had to master. Sure, there was a career path that emphasized project management– we called it “Program Management” – but the competencies in that path entailed much more than project management. Program Managers at Microsoft– the term originated with Boeing to describe the role ultimately responsible for an entire aircraft development program — “own” the whole product or product line, from requirements definition to design through project management, testing and release to market. This entails, effectively, determining what gets built and why, when, and to some extent, how and by whom. Program Managers (in theory at least – the role was interpreted differently from division to division) are the major – though not the only – interface between a product development team and other key partners like testing, marketing, and design. In other engineering organizations, these responsibilities are often part of the engineering manager role, or are distributed among senior architects and product management.
Building project management “muscle” was important to Microsoft (and P&W and Bayer) because strategically the company wanted to make sure all engineers were accountable for their part of the schedule, and because the fear was that by making project management “someone else’s job” , schedule and dependency ownership (etc.) would be diminished. So hence at Microsoft we had a dedicated Program Management career path as well as project management competencies for every technical path.
So how you think about this question at your company is a matter of strategic business direction. Here are some pros and cons of establishing a distinct project or program management (PM) career path:
- Grow deep expertise: With a project or program management path the company can clearly and directly invest in growing deep skills in this area from entry level to senior. Competency expectations – at least within a career model or career framework – are clearly delineated and can be systematically developed over time.
- Role clarity: Responsibility for schedules and dates and dependencies (etc.) can be clearly assigned and communicated across all functions. It is clear who is responsible for what.
- Recruitment: You can more easily attract and retain people who have interest and expertise in this career because how to progress is clear.
- A home for Six Sigma. Roles that specialize in “lean” transformation or Six Sigma can naturally become part of the PM discipline and career path.
- Talent mobility and agility: With a PM path you can readily move talent across business and regions because domain expertise is usually not the most important requirement. What matters is functional competency expertise, which is eminently transferable across product lines and businesses.
- Enable business and culture transformation. Because people can move into these roles from other internal business and regions, PM roles can be useful in many talent and leadership development applications. For example, PM roles can be targets for high potentials as part of a multi-year HiPo development scheme. And cross-pollinating talent across business units is an important way to drive culture change.
- Not my job. Ironically, with a dedicated PM role/path other engineers don’t pay as much attention to schedules or risks or dependencies – the basics of project management – believing these are responsibilities of the PM.
- Skill atrophy. For the same reason, you run the risk of diminishing PM skills across the rest of the engineering workforce. And by having project management defined as a dedicated career path, you don’t build leaders with this competency in other disciplines.
- Manager roles become smaller. A defined PM role and path makes the engineering manager role smaller because this role is now either not accountable, or less accountable, for project tasks, schedules and resources. Project managers often control most of the key decisions on schedule, budget, dependency, etc., which leaves the engineering manager mainly responsible for personnel review and development, a role many engineering managers feel is not that attractive.
- Decision making is more complicated. Decisions such as who is responsible for how resources and time are to be allocated by project, and how conflicts are handled (etc.) become more complex. Complexity can be mitigated by good group process, communication and collaboration, to be sure, but many engineers do not take naturally to these kinds of skills, so resourcing and time allocation conflicts sometimes can bog projects down. Ironically, a dedicated PM role and career path increases the need for good communication and “contracting” between managers and PMs.
Ultimately, the decision cuts to what is strategically important to the business and what capabilities and competencies therefore need to be optimized over the long term. For example, if the business strategy demands closer integration and synchronization across product lines, a dedicated PM role and path may be instrumental to mitigating and managing the myriad dependencies that come with that. Or, if better talent integration and a more cohesive culture across divisions and business units is a strategic imperative for the company, the benefits of a dedicated PM career path may outweigh the cons.