A friend recently asked me how to recognize a good project manager. They were asking for the purposes of hiring, so I don’t think my answer was much help. I said to look at the stress levels on the project team.
The most important thing I do as a project manager is to reduce the stress on my team. This is important for my success for all the usual business reasons (better performing team, fewer mistakes on the project, lower turnover, yadda yadda yadda). But the real reason I think this is my most important task is that people deserve to work with as little stress as possible.
All too often, we are asked to accept long hours, high stress, and not enough flexibility in our jobs. It doesn’t have to be that way for most jobs. Most work can be organized such that the team can meet their goals (yes, even ambitious ones!) without crowding everything else out of their lives. When this happens, people’s lives are better. Making this happen is what I care about most at work.
How do I make this happen? There are four key things:
Make a plan that is achievable. A lot of work stress can be traced back to someone agreeing to do something that is just fundamentally impossible and then trying to force their team to deliver on a promise that can’t be met. A good project manager should be able to take the project goals and come up with a plan that can be implemented without relying on any dubious “…and then a miracle occurs” steps.
If no such plan is available, the project manager needs to communicate that, and provide alternatives for the business decision-makers to choose between. For instance, if the goal is achievable given more time for the project or more people on the project, tell people that! If the goal is not achievable with any amount of time or resources, try to identify a subset of the goal that could be achieved. Whatever you do, don’t sign yourself and your team up for an impossible mission and just hope something works out.
This does not mean that you cannot attempt to accomplish things that have never been done before or that have a high risk of failure. You can take on projects like that – but everyone needs to recognize the risks up front and recognize that failure is an option. Failing a project gracefully gives the team the chance to switch directions and work on other things rather than continuing to chase an unattainable goal.
Furthermore, I think that your best chance to succeed at big, audacious, high risk goals is to break them down into smaller, achievable steps. Often, even when the big goal proves out of reach, the team has still achieved useful smaller goals along the way and made progress that can be repurposed for a new big, audacious goal.
Understand the dependencies among the various parts of the plan. Understanding dependencies lets me respond intelligently when things change – because things always change. If I understand how the various parts of my plan depend on each other, I can think several steps ahead when an issue arises, and often I can keep the project on track.
I originally wrote this as “understand the risks and the dependencies…” but you can never be sure you understand all the risks. There is always something that will come out of left field that you never thought about. I mitigate the common risks (for instance, putting technically risky steps as early in a project as I can), but instead of trying to having a contingency for every risk, I think it is better to spend time really understanding how the various tasks in the plan relate to each other. That way, when something happens and one of the tasks gets delayed I can see how that delay will play out in the rest of the project and respond accordingly.
Communicate well. Not long ago, I joked on Twitter that my job was 90% operational details and 10% writing emails. Someone joked back “only 10%??? Lucky!” But actually, a lot of the emails I write are operational details. I’m telling people what they need to know to get our project done. 10% of my job is writing other emails!
More seriously, one of the most important things a project manager can do is make sure everyone has the information they need. This sounds obvious, but it is far from easy for a wide range of reasons, some good and unavoidable, some due to various types of corporate dysfunctions. Regardless, I see it as my job to get the team the information they need and I’ll jump through a lot of hoops to make that happen. It is also my job to make sure that decision-makers and other such stakeholders have the information they need from the team, preferably with as little disruption to the team’s work as possible. This is why I love systems like JIRA and Kanban boards – if people are keeping these systems up to date as part of doing their work, I can answer random status check questions without disrupting the team’s work.
Solve problems. This category feels like a bit of a cop out, since it is such a catch all… but solving problems is another important job I do for my project teams. Developers need something tested ASAP and the person who reported it is not available? Maybe I can find someone else and explain the issue well enough for that person to do the testing. The person who needs to do an important task has too many meetings this week and has no time to finish the technical work? Maybe I can work a deal with another project manager to get that person a temporary reprieve from a meeting or two. And so on.
Many, many problems come up on a project. A good project manager needs to be ready to think creatively to find solutions for as many problems as possible!
I’m not a perfect project manager. At various times, I fail in all of the above areas. Even when I’m doing all of the above well, my projects sometimes have rough patches. Stress happens. But one way I gauge whether or not I’m helping a team is to look around at my team members and check their stress levels. If the team seems stressed, I think about why – and if I can fix it.
Be First to Comment