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.

1. Building trust within your team

Diagram of a team.

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.”

2. Engaging your stakeholders to get them what they really need

Generic bar chart of exceeding goals.

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.”

3. Making project risk management an organic exercise

Diagram of PM with check list of 3 generic risks.

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.”

4. Understanding the Environment

Diagram of PM's environment.

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.”

5. Applying LEAN Principles

Diagram of 5 LEAN principles

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.”

Understanding the Basics

What are the skills of a project manager?

1. Building trust within your team. 2. Engaging your stakeholders to get them what they really need. 3. Making project risk management an organic exercise. 4. Understanding the environment. 5. Applying LEAN principles

About the author

Miroslav Anicin, Serbia
member since July 2, 2018
Miroslav has led teams and departments with 50+ members through Agile transformation at telco, bank, and other organizations, and has led up to five concurrent teams with as many as 35 developers on their path out of troubled eCommerce projects and on their way to becoming great Scrum teams. He loves a challenge and looks forward to working with new clients and on new projects at Toptal. [click to continue...]
Hiring? Meet the Top 10 Freelance PMI Project Managers for Hire in April 2019


Paul-Henri van Essche
Miroslav, congratulations on a succinct and well-written post. Good "Project Management" is often such a broad and elusive subject, and you nailed it with this overview. In addition, it got me thinking: the way you're describing it, good project management has many parallels with a well-run everyday life! If we as project managers applied these five principles to our personal lives, adapted a little of course, we might well benefit, as might our families and friends. Firstly, building trust is an easy one, the benefits of trust within a family are obvious. What is less obvious is the need to work on that sometimes, so this is a good reminder. Engaging stakeholders is a further stretch, but think of the quality of engagement we should have with our friends, our community, and external parties we value and rely on such as our doctor or motor mechanic, not to mention those that rely on us. Thirdly, Organic Risk Management is patently applicable - you can’t always be on the lookout for your kids as they grow up, their own risk management skills are essential and contribute to the better functioning of the whole family. Environmental understanding is again clear, all family members, especially children, have different and evolving needs, to the extent that your parenting approach will definitely need to evolve over time. Lastly Lean Principles: this one would take a little longer to analyse properly, so I put this analogy to you in the meantime: imagine a family preparing a major annual holiday dinner, each with skills and a part to play. Overly heavy planning and control with kill the fun, and damage the quality of the result. But a Lean approach, with its adaptability and flexibility, leveraging the pull of excitement and the desire to please with perfection, will make for greater participation, a ton of enjoyment, and no doubt a sumptuous meal. Therefore, I propose the following corollary to your article: Projects are Life, Life is a Project. Arguably not in every single way, but I think we could all benefit from that reflection. Going one step further, a project team becomes a kind of family, and often needs similar nurturing skills. A close-knit and trusting team will invariably produce good results. Warmest regards.
Carlos Ponce
I believe that these are all excellent qualities for a project manager, but also for just surviving in life. It’s a tough world to live through, but when you're able to share a positive attitude and lift people's spirits, and when other people have trust in you then it's definitely a great day!
jason knight
Well written Miroslav. One thing I would like to add is communication awareness and asking the right questions. A project manager needs to be not just an excellent communicator, but also understand the communication preferences of all relevant stakeholders as well as be aware of their communication style. In addition, asking the right questions often times flushes out requirements that would be otherwise missed, leading to scope creep later on. For example, we were working on developing a new section of our client's website and it absolutely had to be delivered by the end of the sprint. I also served as the scrum master and during one of our scrums towards the end of the sprint I noticed one of my developers was being more quiet than usual, he wasn't saying much when I asked him questions. I approached him the next day to ask what was going on as I could sense something was up that he didn't want to tell the client. Turns out he was going to be writing code right up to the code freeze, so he did not have time to create/import all the content associated with the new section and he was worried. I told him to show me what he needed done, and I would work on it when I had time. I was up late every night that week entering everything into the CMS in order to get the work done in time. if I would not have known my developer well enough, he probably wouldn't have told me until it was too late and the project would have been late. Rolling up my sleeves to help him get the work done also created a stronger sense of trust between us as well, he knew I had his back and busted his butt for me.
@Miroslav, I have to disagree with your assessment on a couple of levels. The first one being that we should NOT be conflating what is known today as "Agile" but is nothing more than the "trial and error" methods used by early humans more than a million years ago to tame fire or 6,000 years ago to invent the wheel and which around the 12th Century was named the "Scientific Method" and which served us well bringing us the telephone (Bell), the light bulb (Edison) and penicillin (Fleming) to name a few of the many thousands of NEW PRODUCTS this trial and error method has delivered and continues to deliver. To make it easier to understand, if we step back a bit, there are three generic "methods" or "approaches" any organization can employ to "acquire, procure, construct, develop, maintain, upgrade, expand upon and eventually dispose of, organizational assets. (both new and existing PRODUCTS or SERVICES) When we look at it from an ASSET MANAGEMENT perspective, the three generic delivery options are: 1) Operations- This is a well tested and proven option, appropriate when the SCOPE of work and OBJECTIVES are very well defined AND there is little or no change expected or tolerated. Been in use successfully since the Industrial Revolution and is now being automated using robots and autonomous machines. 2) Projects- This is a well tested and proven methodology, appropriate when the SCOPE of work and OBJECTIVES are fairly well defined (75%+) AND some percentage of change can be expected and tolerated. As evidenced by the Pyramids of Giza, the Great Wall of China, the Cathedrals of Europe up to today's Burj Khalifa, this method or process has been around for 5,000 years. This is not as advanced as operations but technology is starting to be used, including the use of drones, autonomous machines and facial recognition. 3) "Trial and Error" or the "Scientific Method" or "Agile"- This is also a well tested and proven methodology, appropriate when the SCOPE of work and/or the OBJECTIVES are not well defined and in fact may not even be fully known or knowable. In this approach, change is not only tolerated but expected as an integral part of the process. As noted earlier, this "trial and error" method has been around for over a million years and there is ample evidence that it does work. Here too we see evidence of automation, in the form of self programming robots and self maintained machines. My concern or issue or challenges are if all three of these "asset delivery systems" have been in place for hundreds, thousands or even 10's of thousands of years, why are we STILL doing such a poor job of being able to use them to produce "successful" outcomes? We know the PROCESSES, we know the TOOLS and TECHNIQUES, and today many of the tools and techniques have been AUTOMATED. So why so many failures? My hypothesis, which is backed up by research from NASA's Glenn Butts and Prof. Bent Flyvbjerg is there is no ACCOUNTABILITY. That IF we were to hold project SPONSORS and project MANAGERS legally and financially ACCOUNTABLE for their decisions, we would not see the large numbers of projecct failures that we see. That until we see project managers and project sponsors, in handcuffs doing the perp walk on CNN's nightly news, we are NEVER going to see projects delivered on time, within budget, in substantial conformance to the technical requirements and substantially fulfilling the purpose for which they were undertaken. And with that accountability has to go formal authority to MAKE DECISIONS as you cannot have ACCOUNTABILITY unless there is commensurate AUTHORITY.
PS @Miroslav, for organizations such as PMI, IPMA, APM etc, what we are urging them to do is follow the lead of the Society for Corporate Compliance and Ethics (SCCE) who have adopted a model code of ethics where, if you look at paragraph 1.4, would require project managers and project sponsors to be much more assertive in reporting and preventing misfeasance, malfeasance and non-feasance, to the point of submitting their resignation. (See bold highlighting below) "If, in the course of their work, CEPs become aware of any decision by their employing organization which, if implemented, would constitute misconduct, the professional shall: (a) refuse to consent to the decision; (b) escalate the matter, including to the highest governing body, as appropriate; (c) if serious issues remain unresolved after exercising “a” and “b”, consider resignation; and (d) report the decision to public officials when required by law. Commentary: The duty of a compliance and ethics professional goes beyond a duty to the employing organization, inasmuch as his/her duty to the public and to the profession includes prevention of organizational misconduct. The CEP should exhaust all internal means available to deter his/ her employing organization, its employees and agents from engaging in misconduct. The CEP should escalate matters to the highest governing body as appropriate, including whenever: a) directed to do so by that body, e.g., by a board resolution; b) escalation to management has proved ineffective; or c) the CEP believes escalation to management would be futile. <b>CEPs should consider resignation only as a last resort, since CEPs may be the only remaining barrier to misconduct. A letter of resignation should set forth to senior management and the highest governing body of the employing organization in full detail and with complete candor all of the conditions that necessitate his/her action. </b> In complex organizations, the highest governing body may be the highest governing body of a parent corporation. Right now, with APM having gotten Privy Council to recognize project management as a "profession" let's see if there are any legal actions filed for malpractice in the UK against anyone who holds APM's "professional" level designation.
comments powered by Disqus
Free email updates
Get the latest content first.
No spam. Just great articles & insights.
Free email updates
Get the latest content first.
Thank you for subscribing!
Check your inbox to confirm subscription. You'll start receiving posts after you confirm.
Trending articles
Related Expertise
About the author
Miroslav Anicin
Project Manager
Miroslav has led teams and departments with 50+ members through Agile transformation at telco, bank, and other organizations, and has led up to five concurrent teams with as many as 35 developers on their path out of troubled eCommerce projects and on their way to becoming great Scrum teams. He loves a challenge and looks forward to working with new clients and on new projects at Toptal.