10 keys to being an effective project manager
We often record lessons learned at the end of a project to learn what we can improve upon as a team during future projects. What I am attempting to do in this article is often some of my own lessons learned as a project manager and provided some of my own keys to managing projects successfully. These are my own experiences and views reflecting my approach as a project manager. As I will mention in the article, what works for me may not work for you, but I hope that it provides at least a couple of times that might be helpful. Without further ado, my 10 keys for successful project manager are as follows:
You must be the most organized person on the project.
This should really go without saying, but unfortunately I’ve been involved in organizations where this isn’t the case. If the project manager can’t provide stakeholders with an on the spot or ad hoc update on the project, there is a serious problem. As I mentioned in a previous post, things like sending out meeting notes within 24 hours of the meeting (I almost always do this the day of) and sending out status reports on a designated day are the bare minimum that we should do as project managers. Another key item is sending out meeting agenda prior to meetings so that meetings don’t go off the rails. As I will get into in another key point later in the post, if the project manager isn’t organized, how can you expect that the team will be organized and that the project will be organized?
Listen to the team.
As the leader of the project, regular and frequent communication is going to be required and expected. This includes things like leading and facilitating meetings. While the team looks to the project manager to lead in these situations, that doesn’t mean that the project manager should be the one doing all of the talking. Instead, I try to facilitate and get the team to talk. I then listen (very rarely interrupting) and take notes. When the person is finished talking, I may ask a follow-up question. The point is that the information we need as project managers to be able to update project materials and to provide information to stakeholders is possessed by the team. If the team isn’t given an opportunity to speak on the status of their project work, you aren’t going to have the information. My personal style is that I listen to even the fine details that the team provides and then can provide a high level or detailed summary of it depending on the stakeholders I need to convey the message to.
When I first started doing consulting work, I went to a meeting with a potential client and showed them a detailed waterfall style project approach in Powerpoint. The potential client’s eyes started to glaze over and I quickly realized what a mistake this was. I certainly wasn’t suggesting this would be the approach for their projects, but was trying to show that I had a plan for approaching projects that had substance to it. It was clear based on their questions that the particular approach shown in the slides was not one that they felt was well suited to their projects. Certainly, my intent was only to use this as an example of past work and past approach, but once you put something like that in front of people they understandably go by what they see. Needless to say, I didn’t get engaged on that project and haven’t heard from that potential client since. In retrospect, I should have done what I do now which is to explain to people that once I have information on the project I can describe the approach I will plan to take and what tools I will use. For example, if someone brings me a web development project, I’m not going to pitch them the waterfall approach. However, that is not to say that it absolutely has to be a pure textbook Scrum approach either. I look at the traditional project tools and the Agile tools as a giant toolbox and then I pick the tools based on the client’s project. I keep an open mind until I hear what the client needs and then I start to ask pointed questions to validate the best approach. I don’t go into the initial engagement process thinking that I am going to approach a project a certain way. The above statements are not to say that you don’t have to be process oriented. You absolutely do and the structure that a process oriented approach provides is one of the primary reasons (I will touch on some others below) that companies are willing to invest money in having experienced professionals manage projects. The point is within that process oriented approach that you need to be adaptable based on what the project calls for.
Whether you are in an internal facing role or external, it is important to resist the urge to tell people what they want to hear over the truth. If a customer asks you for 3 straight weeks if the project go-live is on track for a particular date and you tell them that it is, they are going to expect the team to deliver accordingly. If you then don’t deliver after telling them everything was on track, then they likely will be less understanding (and rightfully so) than if you had told them 3 weeks ago that there were some risks or issues that could threaten the delivery date. Yes, things go sideways at the last minute, but even in that case, as project managers we need to have the long view and see those things coming. We need to be able to tell the customer up front that XYZ is a risk. I always say, “I’m very honest and sometimes it gets me in trouble.” One of my former colleagues would often tell me that he found that some of the senior technical leads on his team to be too honest with clients. To an extent, he had a point, but highlighting potential risks and issues that arise as the team moves closer to project implementation/go-live/release is imperative. Delivering bad news is never easy or fun, but my experience has been that people are a lot more understanding when you are transparent and proactive about it.
Depending on the organization, you may or may not (such as in a matrix organization) have authority of project team members. Even if you don’t have authority of those team members, you will still hold them accountable to their commitments as far as project tasks. However, you lose credibility if you don’t maintain that same standard. If project status reports are due on Fridays by 5pm and you send them out on Mondays at 9am, then you are submitting late work. If you show up for meetings late or don’t show up to meetings early enough to ensure the projector is working, why should anyone else on the team come to the meeting fully prepared? There are 8,444,777 courses on leadership and what you should say, but one of the most understated forms of leadership is through action. If you show up on time, well prepared, and are on your game, then everyone else will feel the need to bring their “A” game as well. Again, if you aren’t doing the things that you want the team to do, it’s going to be harder to demand that accountability from them. This includes taking responsibility for things going wrong even when you feel it isn’t your fault. This comes with the territory and is part of being a good leader. Andy Reid, who was the head coach of the NFL’s Philadelphia Eagles for 14 years and now coaches the Kansas City Chiefs took a ton of criticism for always answering press conference questions where a reporter asked him to assign blame by saying, “I have to do a better job” or “I have to put the players in a better position to succeed.” As a fan and as a reporter, this annoyed a lot of people. However, Andy Reid is revered by his players and they go out and consistently play hard for him knowing that he has their back.
When I took a PMP prep course over 6 years ago, the instructor started off the course by saying, “We are all here because we are type A personalities.” For starters, this depends on what you consider to be the traits of someone with a “Type A” personality. However, as I alluded to above when talking about how important it is to listen, you need to be yourself. I have worked in a number of different PMOs and I can tell you that all of the project managers I have worked with had different styles. Some had a very aggressive style while others had a more subtle style (not to say it is a passive style by any means). I have seen both styles work really well and both styles fail. There seems to be a belief among some in the project management community that you have to have a very aggressive approach to managing projects, but if you don’t have an aggressive personality, that isn’t going to work for you. To be clear, I am not suggesting that you don’t have to be completely on top of things because you absolutely do, but there is a way to do that so it doesn’t greatly deviate from who you are as person. I have found that when someone is acting in a way that is not consistent with their normal personality that it shows.
Be respectful, professional and compassionate.
Along the same lines of what I mentioned above, I had a colleague a few years ago who had a very aggressive approach. That project manager was highly regarded by management and had been in the role with the company for many years. However, that project manager was working with a team who had a lot of other production/lights on responsibilities and for that reason some project dates slipped. The team advised the project manager of the challenges, but the project manager continued to press the team to meet the dates discussed. Eventually, the team just tuned out the project manager and started communicating their challenges and new timelines to senior management directly. I tell that story to make that point that you have to understand especially in a matrix organization like the one described above what challenges your team members are facing and be compassionate. You can’t drop the hammer all the time or just as in the situation above it loses its effectiveness. When you show people that you understand their challenges and are respectful of that, you have a much better chance of being shown that same respect and being given consideration for your responsibilities as a project manager.
Be meticulous with record keeping.
If you have read my other posts, you know that I am big on note taking and record keeping. As I’ve mentioned in those posts, the reason for this is because there have been numerous times where someone asks me a question months later and it gives me a paper trail of all project discussions and events. I take my notes after meetings and put them in the project plan within the project management software or will put them in my own personal task management system to ensure that I follow-up. As I mentioned in my meeting management post, some project managers feel that meeting notes are beneath them, but I think the value of them especially on projects with longer durations is greatly underestimated. Whether it is meeting notes, project management sub-plans, or making sure the project management plan is fully up to date with all late tasks being addressed, all project records need to be up to date.
In the same vein as the above point, I can’t emphasize how important this is. A company has a project manager to ensure that things don’t slip through the cracks. This means that if a key stakeholder says during a meeting, “I really think that we need to consider moving this deliverable up due to new contractual requirements” that you record it, put it in the project plan or at least the issues log, and follow-up with the appropriate parties on it. I would much rather follow-up on something and have someone tell me, “That’s okay. It’s not a major issue anymore” than have them come back 8 weeks later and say, “Why did you guys do that? I told you it was going to be a problem.” I consider follow-up one of our paramount responsibilities as project manager’s and one of the reasons company’s are willing to invest the money in having an experienced project manager lead projects.
I’ve been accused by colleagues and clients of being overly communicative. If that is the worst thing someone can say about me as a project manager, I’ll take it. This is a point that has become a bit of a cliche when reading articles on project management, but the fact is that if you aren’t communicative as a project manager people aren’t going to know what is going on. Additionally, they aren’t going to know what they are supposed to do and when they need to do it by. Communication isn’t just about sending out emails and talking to people in meetings, but knowing what to communicate, how often to do it, and when to do it. Despite popular opinion, I don’t believe that there is a single right way to do it. In many cases, you can simply ask the customer and stakeholders what their communication preferences are. However, even if I am provided with guidelines, I will read the situation and communicate accordingly. You will find that some stakeholders require and/or prefer more communication than others. You will find that some team members need to be checked in with more often than others. However, my view is that it is always better to be told that I am being overly communicative rather than having a stakeholder say that they have no idea what is going on with a project because they haven’t heard from me. As part of communication, it is also important to be available. We all get tons of emails and some people really hate emails. However, as project managers, we need to use the communication medium that stakeholders prefer. I have clients who prefer text message, others who require Slack for communication, another client who prefers using the app WhatsApp, and many who I communicate with via email. I always tell clients that if you don’t hear back from me within a couple of hours (during business hours, but the reality is whenever I am awake) to call me. I take a lot of pride in responding to emails/Slack messages/text messages promptly. In some cases, this can be within a couple of minutes, but I am always sure to respond quickly as I think top notch communication is a paramount part of the role as a project manager.
In conclusion, if you’ve made it this far, I thank you for reading and truly hope that you found this post helpful and valuable in highlighting some of the key things that guide my daily work as a project manager.