A Matter of Balance – Management vs. Technical Role
By Vicki Wrona, PMP:
Why do organizations constantly rely on their PMs to also perform key technical work on a project? Several reasons. One is reality. We are doing more with less now, and the reality is that we may not have the personnel available to assign different people to those roles. Another reason is that most projects are small enough that working within both roles is not a problem. Still another reason is because often the PM is assigned because they are a strong team member and one of the higher performing employees. Their reward is being given the opportunity of managing a new effort. During that effort, the organization cannot afford to have this superior performer NOT working on what they do best — the technical work of the project.
The trouble occurs when the project is large or complex. In this case, balancing both the management aspect (PM) and performing key SME work can be overwhelming and tough to balance, often resulting in neither being done well. Few people can be actively involved in their technical focus, or SME activity, when needed and then be able to step back and see the big picture from an unbiased management perspective.
This is true both from a time as well as a viewpoint perspective. Most people allow their SME time to overtake management time until there is a crisis, at which time they go into reactionary or fire-fighting mode to deal with the issue (often later than they should) and survive. From the viewpoint perspective, it is difficult for someone who has been deeply engrossed in one aspect of the project, such as their area of technical expertise, to step back and address issues and concerns from all areas objectively. Mere mortals cannot always do this. Yes, we have all been asked to do this and some have done it fairly well, but the larger and more complex the project, the more difficult and unrealistic the expectation.
Add to this the fact that when PMs are assigned both roles, planning takes a back seat. When this happens, there often isn’t clear understanding or definition of scope, schedule, roles, expectations, constraints, etc., compounding the number and kinds of potential problems experienced later. Without an initial definition of those various aspects of the project, it is harder to get agreement on the possible fix to allow the team to move the project forward.
Projects may be completed in this structure, but at what cost? Are team members burned out? Were there more crises than necessary? What superhuman, or brute force, effort did it take to get the effort done? Was it worth it? These are valuable questions to ask, and even better if asked first when assigning roles.
