Being a top PM makes you stand out and if you are recognized as being a top PM, you will be in high demand. Stakeholders will trust you more, they will want to work with you, and they will listen to your advice more. Whatever it is you are helping to build, top PMs are always in demand in organizations around the globe. This is a list of some key qualities of top project managers. Hopefully, they will help you to become one or check if you already have these habits at your disposal.
)
Trust is an important aspect of every team. It is frequently talked and written about, but rarely seen in action when it comes to running a project. The importance of trust in the project management process has even been recognized by a variety of different Project Management organizations.
The International Project Management Association has just included sections about trust in their ICB4 certification which is the global standard for individual competencies in project, programme and portfolio management.
Similarly, Scrum’s Three Pillars of Empiricism have long been based on the idea that trust is one of the three most important factors to uphold the empirical project control. The same trend of building trust is present in LEAN and other traditional project management methodologies. If this has been such a pressing topic for so long, what are the main blockers preventing PMs from establishing real trust within their teams?
One of the most recurring answers to this question is “blame culture.” A key in achieving trust culture is migrating away from this culture and instead shifting every mistake to a learning opportunity.
In order to make this a reality, PMs should facilitate the right environment of transparency and comfort within their teams, since most people perform much better in the environment where team members are able to express themselves and make mistakes.
A top PM teaches their team these principles by example by living alongside them, encouraging to share their mistakes, and turning them into examples for learning. Top PMs realize that showing humility and vulnerability is a sign of strength. Especially when it comes to admitting to your own mistakes, it’s often true that people tend to become defensive or shift blame. Explaining that you made a mistake and why can make you feel vulnerable, but if you openly admit and analyze these mistakes, this habit will help others to avoid it in the future and will help everyone to build trust and open up about their slip-ups. For example if you overpromise a key stakeholder to finish a milestone earlier than it is possible, because of lack of technical depth you had of that subject, be ok with admitting your mistake to the team, and letting them know you misestimated things rather than blaming them for not delivering the technology as fast as you wanted. This can inspire others to open up and build stronger connections with you and their teammates.
Understand your team members: their capabilities, fears, frustrations, what they like or don’t like, and how they interact with other people. When team members feel that they are valued, they will deliver value more easily. Find ways to motivate your team with the task at hand instead of forcefully pushing them towards your objectives. To do so, clearly outline what success looks like for the project and project team roles and responsibilities, but then let them be experts in their fields. Expect your team members to tell you what needs to be done. Listen to them, decentralize decision making to empower your team, but be prepared for making hard decisions when necessary.
After all, your team is there for you to engage with. Too many PMs make mistakes of diving straight into writing tasks and taking too much of that responsibility by themselves. This sometimes happens due to the lack of trust and understanding within those teams. When you have your team’s trust make sure they get involved in scoping out work, writing users stories and in general giving you advice on the matters they feel are important.
Top PMs realize that their team is their best asset, and will take each opportunity to build strong relationships with them. Be negotiator and facilitator, but before everything, be one with the team. They need to feel as though you are working with them and not for someone above. This is a precursor to some of the more technical tips in this article, as, without this trust, your project will likely run into a series of problems.
Key Takeaway: “It’s ok to show that everyone makes mistakes. Share your mistakes when you make them, show your team you are on their side, and make the trust within your team a priority.”
)
As a PM, you are probably well aware of the fact that a lot of software projects end up delivering something other than what the stakeholders wanted or needed. This problem is due to many different factors and it has spawned a whole set of new methodologies trying to solve this problem.
However, even in the era of Agile development, we still sometimes fall into the trap of building the wrong thing. Stakeholder analysis is essential but often starts with the wrong question. Without asking the question, “Why are we doing this?”, many projects are initiated and incorrectly defined, falling into the trap of building towards a solution that never addressed the real business need.
In conjunction with “why,” top PMs must ask a follow-up of, “to whom?” Which stakeholders are we supporting, in order to deliver the solution, to cover their “why?”
Here is where a top PM recognizes an important distinction. The solution can be defined as an output or deliverable, but a top PM understands that any solution itself will not necessarily cover the original business need. For example, if the stakeholders think their business need is to implement an ERP system, then the PM has to help them to uncover the real business need behind using a solution such as ERP. The ERP itself is a solution, not a business need.
Recognizing the true business need requires a deep understanding of the context and stakeholders, their attitudes, power or influence level, interest level, their impact on the project, the project’s impact on them, their concerns, and of course, what will they accept as a project’s success.
Thus, in order to make projects more successful in achieving their purpose﹣creating solutions which impact business goals﹣project manager responsibilities expand past the solution creation itself, to where solutions go live, in clearly measuring whether the value actually produced aligns with the expected objectives in the goal definition.
PMs should always keep in mind that the real benefits of delivering the project throughout the entire process have to be aligned to the real business needs, goals, and objectives.
Too often, the business goals are forgotten in the midst of development and requirement changes. Often, projects end up delivering functional products, that solve some, but not all real business needs that initially prompted the development of the product in the first place. This can be prevented if stakeholders are managed right and presented with product iterations often.
Top PMs also recognize their role in leading the project, and thus do not expect stakeholders to communicate all requirements at the outset of the project. They understand that some stakeholders do not always know how to articulate their needs, and it is their role to help stakeholders articulate their needs, from requirements elicitation, through to project delivery. It’s also important to remember that during the requirements elicitation process we have to elicit not only requirements from the stakeholders but their concerns as well.
For example, in less mature organizations an interesting paradox often happens at the beginning of new projects. During the project initialization phase, the development team expects stakeholders to clearly identify all the requirements and needs for the solution to which they will develop. At the same time, stakeholders expect the delivery team to provide accurate estimations in both time and cost.
However, at the very onset of project scoping, there is too much uncertainty to nail down these estimations - and in doing so, there is danger in creating unrealistic estimations. At times, stakeholders include as many requirements as possible, to accommodate for the uncertainty of a currently less tangible solution. Meanwhile, the delivery team provides a very approximate estimate for the unknown.
The result of this will most likely be a solution which will only get 20% of its full requirements utilized by the stakeholders. The rest will be developed with no clear goal in mind making the project over-budget and also over-schedule.
Luckily, top PMs know precisely how to engage stakeholders and guide them through each step of the VUCA (volatility, uncertainty, complexity, and ambiguity) world of their project. Project managers are able to break down the project into more tangible increments and engage stakeholders while actively creating and reviewing learnings throughout.
The key takeaway here is: “The solutions are built to solve the business need, PMs need to make sure this goal is not missed when the project gets created. Make sure that your stakeholders want to build the right things, by engaging with them to address their core needs and concerns.”
Most projects have a set of generic risks that are brought up at the beginning of project initialization.
Almost every project starts with these generic risks, including users resistance to change, lack of resources, and immature technology to name a few. Top PMs engage their teams to identify not only the common risks but instead the most pressing and unique risks, such that risk identification is a reflex throughout the project lifecycle, not a menial task at the beginning of the project.
In recognizing risks, top PMs also look to their collaboration with key stakeholders, who often explicitly or implicitly define risk in their requirements and concerns. Great PMs understand that this process happens from the requirements elicitation step all the way through to the entire project life cycle, and regard this as an asset to defining risk throughout the process.
Expert PMs also trust their teams and also recognize their expert knowledge as a source of risk mitigation. In order to empower team members to proactively spot risk, the PM empowers their team to take ownership of the project and actively participate in risk identification and management.
In practical terms, the third question during a daily standup, “What is getting in your way?” reflects more prudent responses as a team is empowered to contribute to the project’s success. Of course, some blockers may be temporary or removed immediately following the scrum, however, some are potential candidates which may grow into substantial risks. Team members need to be encouraged to identify these potential risks and their inclusion should be celebrated rather than look down upon even at the end of the project lifecycle.
Risk recognition is also not as simple as stating the risk and proceeding forward. Risk recognition should be regularly assessed, in terms of probability, severity, and a metric that is sometimes forgotten: proximity. The latter metric allows for the team to define the right action items, whether it be “Do nothing until next risk recognition step” or something more tangible should the risk be more proximate. What is important to recognize here is that top PMs understand how to make risks actionable, as any risk is unhelpful if they are unmanaged. Additionally, the list of action items should not only be reactive but also proactive in nature, ultimately informing a Risk-Adjusted Product Backlog.
In short, a top PM recognizes that regardless of experience or authority, they are not and should not be the single source for risk recognition and management. Stakeholders, their team, and other important project contributors should be involved in risk recognition and management not only during early stages but also regularly through the project life cycle. This is important because there is very little use of risks that have been identified at the start of the project but have not been managed ever since.
The key takeaway here is: “To achieve successful project management, the whole team should be responsible for identifying risks. The risk discovery has to be a continuous process that happens throughout the whole lifetime of a project.”
A top PM should not begin a project like a bull in a China shop. Instead of forcing a methodology or project approach, the project manager should perform an in-depth analysis of the environment, formal structure, informal structure, culture, habits, tools, capabilities, and organizational assets at hand. Only then he can start the journey of change.
While any PM understands that the projects they’re undertaking will have an impact on the organization, top PMs recognize that the organization similarly has an impact on their projects.
Instead of a flawed, one-size-all mentality, top PMs tailor their approach by understanding their environment. In doing so, they’re better able to recognize the most pressing business needs, how organizations will adapt or accept a solution, adoption, and which changes will be made to the solution to achieve the right fit in delivering objectives.
While tailoring an effective project management approach, top PMs have to possess an in-depth understanding of different methodologies, not only of different PM approaches but of business analysis methodologies, change management frameworks, enterprise architecture frameworks, and other useful analysis methods. This gives a PM the ability to find the best-suited solution for the company at hand to deliver the project they are undertaking.
For example, if you are starting a project in an extremely rigid hierarchical organization, where there is a lot of different approval levels, the best approach may be a blended or hybrid project management approach. You may carry out a structured requirements elicitation phase, with the requirement approvals done in advance and then dividing the project into stages with formal stage gates. In parallel, the PM could set up Agile-like iterative execution within the development teams to capture the best practices of the iterative development, despite running a more traditional project.
In summary, top PMs will respect company culture, while respectfully proposing new approaches and coaching organizations in improving their project management practices. They recognize that many organizations are at different points of maturity and readiness for change, and see it as an opportunity, rather than a threat, to positively impact each company’s ability to implement project management best practices.
The key takeaway here is: “Project Managers should not blindly push their own agenda, but should adapt to the organizations’ ways of working, and deliver the change slowly if needed.”
Top PMs know that the journey matters as much as the goal. At times, the project journey is made especially cumbersome by a process which defines how things should be done. This could take form in unnecessarily heavy templates, pointless meetings, or distracting peripheral that hinders the journey, but it’s your responsibility as PM to make sure these hindrances impact your team as little as possible.
Top PMs should identify more efficient and effective processes for the team, drawing from agile project management principles, well defined in LEAN methodology.
A popular misconception is that LEAN is suited only for manufacturing, which is simply not true. LEAN project management methods can enhance every project and every process. It is not simply a cost reduction program, but rather a way of thinking and acting for your team.
The benefits of applying LEAN principles is well summarized by a quote from the CEO of Toyota, Katsuaki Watanabe: “Brilliant process management is our strategy. We get brilliant results from average people managing brilliant processes. We observe that our competitors often get average (or worse) results from brilliant people managing broken processes.”
A top PM with a bias for eliminating unnecessary project noise and work will naturally drive the process toward LEAN principles. A top PM should work tightly with a Product Owner, their team and relevant stakeholders to help them streamline and specify their needs and the expected value as a response to those needs.
It is also useful to look beyond LEAN for borrowing the best PM practices for your project. For example, only PRINCE2 methodology possesses an obligatory task of capturing lessons learned during the starting phase of the project. This captures all the lessons learned from the previous projects, rather than writing a document at the end of the project that will seldom get used by others when initiating a new one. It’s important to not be afraid to change up the process to eliminate the unnecessary steps and focus on the ones that add real value.
This is a good opportunity, to help and reshape processes, or to help the team pick the right ones from the start. These clear performance indicators should be shared transparently with all involved to define a clear guide of project success.
The key takeaway here is: “Finding the right solutions is as important as having a correct streamlined process for delivering those solutions.”
)