The PM could do it all as a supervisor, coordinator, and contributor, but this depends on the project’s focus and the resources they have at their disposal. Within the constraints of their organization, they can do much more.
Contributor to the Product Vision: an anecdote
In several projects, I have acted as the supporting product manager to a key product manager usually when the key product manager’s main contribution is a very high-level concept of what they would like built. In effect, such a vision is so high-level that there is no way to execute on the vision at all without properly describing and breaking down that vision into understandable parts, including defining the outcomes desired. I was in effect a technical product manager in that I could transform the idea into a technology solution, and the person I was reporting to or was obligated to deliver results to was in effect a client or sponsor that was not expected to understand how to execute on their vision. I was the person “on the ground”. Different product managers may have different visions on their level of contribution required, so there is no single rule on how product management should work and how the project manager may take on any product-related responsibilities.
As a person, I am often among the stars, but when I am working on a project, I stay grounded because I understand that execution requires understanding the stars while creating traceability back to the earth. That is what I have done for my clients. The further out they are, the more work I have done either on my own or with business analysts to define and break down what they want. It is critical to be able to work with a vision in a structured manner to manage scope.
Leader of the People: an anecdote
Before they can manage expectations, the PM must first be able to understand the people they manage as well as the people they may interact with outside of the project team. By understanding the behaviors and motivations of each stakeholder (whether internal or external), the PM can determine how to utilize project team members and interact with senior stakeholders. A part of empathy that I did not experience until setting up my own business was what drove the people that I hired.
Before I dove into the PMBOK®, I didn’t need to know these technical terms for being a relatable and empathetic human being, but I will admit it is helping me to structure my thoughts better. I learned through hiring and firing how to care about people before caring about my own small business, and it was a costly yet very rewarding exercise.
Getting the balance between management and leadership techniques was not a cakewalk for me in my initial experiences as I lacked structure. I used both techniques but did not know when to optimize them. For example, there were times when I would focus on maintaining the status quo to get the job done without considering how this would prevent my team from developing. I lost some people this way. There were other times when I would focus on R&D that would help projects long-term, but this created a risk leading to slower delivery.
Managing Expectations
All of the moving parts at the people level are following some sort of expected process regardless of whether it is the optimal one for achieving delivery. This is a major reason why PMs monitor and control the project’s activities, firstly to ensure nothing is occurring that would contradict another stakeholder’s expectations, but also to ensure that what was expected is refreshed, adapted, and communicated as needed.
Managing expectations is like managing promises. If I make a promise, I should keep it. So if I communicate information that gives a senior stakeholder an expectation about delivering a certain set of scope on time, then I should have checked with the delivery team beforehand that they can meet that expectation. Once the senior stakeholder has that expectation, it’s my job to manage daily activities with the team so that their expectations are continually managed to meet the senior stakeholder’s expectations.
In an agile execution approach, the work might be carried out in iterations. If the team runs into a roadblock and cannot deliver what they expected, I will need to have planned for that risk in advance, and I should have communicated to the senior stakeholder that such a roadblock could have happened. Whether I’ve done that will usually depend on whether I could have known about that risk (either due to my experience or if it was a truly unique and improbable situation in the circumstances).
Maneuvering Madness
Understanding the culture of an organization enables a PM to know how politics and power can be used to achieve outcomes. There are several forms of power referenced in the Guide, but I will go over the ones that I have observed or related to more often than the others:
- Positional – determined in relation to someone’s formal position, indicating a level of authority
- if a VP has input to provide about a project’s status, and they have the authority to affect what happens next on the project, it’s important for the PM to recognize when others have this power to be able to exert their influence onto an authority when needed to achieve goals
- at the same time, within a project team, the PM can refer to their authority when suggesting that certain team members should execute certain tasks
- Situational – when power is acquired due to a unique incident
- if there is a production incident, the PM might have the authority to require operational engineers (system administrators or DevOps in the software application context) to start or stop certain systems
- where the PM lacks this power, they could exert their influence onto a senior stakeholder such as a VP to make certain decisions; this is important especially when the PM has more technical knowledge (and therefore has more Expert power) than the VP in the circumstances
- Guilt-based – when others are led to believe they have an obligation or a duty to execute
- “we’re running out of time, we’re going to miss the deadline” – this is a mixture of power being utilized here, but the PM may have to apply Persuasion, Pressure, and possibly Coercion to help push the delivery of a task, but at what cost?
- likewise, if a VP reminds the PM that they signed up for satisfying the customer’s business needs at all costs, it may signal a need that vacation should not be taken if the PM is unable to delegate their tasks
Acting with Integrity
Although there are times on projects when it is important to exercise influence and power, I have found it equally if not more important to act with integrity – never to compromise the trust the stakeholders have in me, and if I make any promises, to keep them unless an exceptional circumstance arises that makes it impossible to keep the promise.
I weigh the upside and downside of “letting things fail”. While it is important to delegate ownership to motivated leaders or to take excess work from a higher-up, I make sure to manage risk first and foremost. If for any reason I have knowledge about an area a higher-up should have had, but they acted upon not having that knowledge in a way that could trickle down to the project level, I will capture it regardless of whether it was delegated to me, adapt it to suit our project (if possible), and push it back into the process. The same goes for subordinates – if there is an overflow, then I determine what the cost of failure is, and I’ll lend a hand to keep things afloat if needed. To me, part of integrity includes not compromising others’ reputations, so this can take a lot of work, but I believe it’s part of good leadership.
If risks are managed properly, the PM can maintain their and others’ integrity by keeping processes smooth without carrying out any unexpected actions. Letting things fail is an option only if it’s easy to pick things back up without causing unnecessary strain. If it’s the only option available to bring a project back to sustainability, then I would vote for it.
Keeping Eyes on the Prize
Integration Management ensures all of the gears of the project management machine are running, and while a good PM will keep them running, their focus should be on utilizing a few skills that are not in the Guide’s standard, but are in my own standard:
- energy
- dynamism
- flexibility
The good news is, the Guide covers the need for continuous prioritization, being attentive to the project’s key constraints, being flexible, and being able to filter out key details from various types of artifacts and communication. For me, it requires using those three skills I called out in order to be effective at achieving these needs.
By keeping priorities up to date with a focus on accounting for the project’s critical success factors, I can optimize all of my activities and that of my team members towards getting the prize.
Questions that might pop up: technical project management, PM expectations
Which project element is least relevant to technical project management skills?
A. Budget
B. Schedule
C. Sponsorship
D. Risk
Recall earlier that I wrote about competing interests and objectives. One of those answers is not equivalent to a Knowledge Area, and one of them is just closely related to an existing Knowledge Area. I think that is a good enough hint.
Which statement is least accurate? Project managers should be able to:
A. Apply strategy towards maximizing the project’s business value
B. Explain the project’s strategy, mission, goals, products, competition, etc.
C. Be aware of relationships with other people to get things done
D. Take on responsibilities of unavailable team members during an incident
For other mock questions, read more posts from this tag. To learn more about my stories and my experiences as a project manager, get in touch. I have scratched only the surface in this post (and in the previous one).
Featured Photo by Kace Rodriguez on Unsplash