What makes a Project Manager a good Project Manager? Employers struggle with this question a lot, I’m sure. They struggle with it when they’re creating a Project Management Office (PMO) and the accompanying policies, procedures, and processes. They struggle with it when their Human Resources department is putting together job postings. They struggle with it when they’re interviewing candidates and I’m sure they struggle with it the most when they weigh the candidates and try to come up with the one that they decide should become part of their organization.
On the flipside, as Project Managers – or for some, aspiring Project Managers – we also struggle with this concept as we try to analyze our own characteristics to see if we have what it takes to be a Project Manager. Do we have what it takes to organize and lead a diverse team on a successful implementation? What is it that makes a good Project Manager tick? What qualities allow someone to lead a group of talented individuals and organize their efforts to arrive at a successful solution? I’ll give you my take – in no particular order, but I’m very open to your input as I know this is not a definitive list and is really longer than 5 or 10…it’s probably more like 100.
As a Project Manager you’re trying to contain a talented group of anywhere from 2 to 50 team members, keep the project budget in order and up-to-date, create an accurate status report, and schedule meetings throughout the week. None of this is possible without a decent amount of organization skills. Oddly enough, in my daily life at home, organization skills are not my strong point. Just ask my wife. But in terms of Project Management, I tend to thrive on the need to keep all of these activities together, stay on task and keep a project team moving forward.
As a Project Manager, you may be running 4-5 projects at a time. As I’ve discussed in previous articles, the formal communication alone on each project should involve a weekly team meeting, weekly Status Meeting with the customer, and a weekly Status Report to team members and the customer. If a PM is running 5 projects, that’s 15 formal communication points to coordinate. The informal communication that happens on a project in the form of emails, phone calls and impromptu or emergency meetings with team members and the customer can add a nearly infinite amount of additional communication points to coordinate.
I was once told by one of my Business Analysts on a project that he gets more emails from me than another other Project Manager he’s ever worked with. I definitely took that as a compliment because one of my biggest fears as a PM is that with so much communication happening between team members and between vendor and client I might miss communicating a critical piece of information.
The Project Manager is the central information repository for both project teams and many times the timeliness and thoroughness of his or her communication can be critical to the success of the current tasks and the project as a whole.
During implementation, there may be time on your project when you have to play the role of negotiator. The most obvious time is when scope changes arise. Immediately, the Project Manager is thrown into the role of a negotiator as he or she has to put together an estimate with the help of his team and present that package to the customer and ‘sell’ them on the additional work that is required. Sometimes this is a tough sell to a customer who may believe that the work is really within the original scope of the project.
The Project Manager must have the confidence and initiative to stand firm on scope issues as well as the ability to have the 1,000-foot view of the project in order to see possible negotiation points in case the ‘sell’ is harder than anticipated. For example, the PM needs to be ready to offer a phased approach to a project implementation if that is needed to negotiate a scope issue. A phased implementation involving moving a portion of the project to a later timeframe or phase may save the project timeline and make the customer happy even though they have to pay for the additional effort.
One of the most important characteristics that a Project Manager must exude is confidence. A weak PM will lose control of the team, the customer, the scope, and ultimately their job. A customer will sense the weakness and either use that to take over control of the project or possibly request that the Project Manager be replaced. Skilled technical resources will never look up to their Project Manager as a competent leader if they sense they are weak, wishy-washy in their decision-making, or simply lack the knowledge to ‘pull it off.’
The Project Manager must be ready to take charge and not afraid to make tough or unpopular decisions. They also must be ready to fight for their project, their customer, and/or their team members. That could be escalating issues – including resource availability issues – to executive management in order to ensure the success of their project.
As important as confidence is, the PM must also know when to listen and rely not on their own understanding. As PMs, we are doomed to fail if we do not listen to others and look to our team and the customer for vital information and feedback as the project progresses. Too many times we end up working heads-down as we push toward a critical project deadline or milestone and miss some of the critical things going on around us. Remember, the rest of the project team also has their hand on the pulse of the project and at any given time may have more vital information than the PM to share including wise views on the direction…or re-direction…needed on the project.
In many cases, the Business Analyst is even closer to the customer and the day-to-day activities on the project and it is absolutely necessary that the Project Manager have a mutually respectful working relationship with the BA and listen carefully to their input – it may be the best information they receive throughout the project.
Well Connected in the Organization
There is no question that the Project Manager is the point person on the project team….truly for both the delivery team and the customer. Sometimes, in order to ensure forward progress on an engagement, the Project Manager will need to dig deep into their own organization to get the support needed. A well connected Project Manager will know the right individuals in the right departments like HR, Tech Support, Sales, Finance/Accounting, etc. to get the answers, support, or software fixes delivered in a timely manner to keep the project running smoothly. The bottom line is they need to know who to get what they need from and they need to know where to go to get it.
For me, having solid connections within the Accounting departments and within the Application Development group has provided me with the greatest benefits. With accounting connections, I could get billing issues resolved quickly and get the answers I needed quickly when trying to justify customer invoices or prepare project budget information for the customer. Having solid development staff connections including the Development Manager has helped ensure that I can usually get the right developer for the project without too much of a fight.
In an ideal world, there would be no problems. Even if that were the case in the real world, I believe there would STILL be problems in the IT world. Every project faces issues. If you’re a lucky Project Manager, you may only have one or two sizeable issues to resolve on a given project. If you’re unlucky, you may go through stretches where it seems like it’s a daily occurrence.
One project I was asked to jump on was going south fast. A critical processing performance benchmark could not be met and we needed to resolve why and how to fix it because moving on past this issues was not an option…it was a show-stopper. With management and customer approval, I gathered key resources from both sides into war-room typesetting at the delivery organization site so that we were physically close to key development, tech support, and infrastructure support resources during this critical effort. We spent two solid weeks together working on performance tuning, development re-work, break/fix testing, and customer testing and we finally got through it. We may have been able to eventually solve it remotely, but we had been trying that and it certainly wasn’t working fast enough. This way the customer saw the dedication and issue resolution up close and regained confidence in the delivery organization while also participating heavily in the solution.
The problem-solving characteristic in a good Project Manager forces them to change their way of thinking based on a given situation – forces them to get creative. Go to management to get what you need. If it’s important to the project, then it’s important to your executive management and to the customer and you’ll be surprised what they’re willing to do and help you with in order to resolve issues.
Do What You Say and Say What You Do
This one probably applies to any profession and just about any role a person plays, but it’s often overlooked. “Do what you say, and say what you do.” Let’s dissect the first part of that phrase first. The Project Manager should have good follow-through. The Project Manager should do what they say they are going to do. If I’m the PM and I say I’ll have something ready for team distribution by COB today, then I need to meet that deadline. If I’m going to help with system testing and I’ll run through some test cases by Friday and have feedback ready then I need to do that and meet the critical deadlines.
When the Project Manager – the leader of the team and ultimately the entire project – can’t meet deadlines and doesn’t meet their commitments, then why should the rest of the team? PMs, if you set up smoke screens and miss deadlines because you’re too busy, then the rest of the team will see that and sense that deadlines are merely suggestions. Respect will be lost and the project timelines may ultimately be affected.
Since you are in the most visible position on the project, it’s absolutely critical that both your delivery team and the customer see you doing what you say you are going to do. And if you can’t meet a deadline that you imposed on yourself, that’s usually ok as long as you own up to it and acknowledge to the team and to the customer why you missed the target. At least then you show that it’s still important by not blowing it off and turn your work in late without an explanation.
The second part of that phrase really has an entirely different meaning. “Say what you do.” Some of us have a hard time touting our own work. I’m not saying you should stand on a street corner and shout it to the world, but it’s ok to acknowledge when you’re responsible for success and certainly don’t let anyone else take the credit for your work. Be sure to give proper due to project team member efforts, but if you’re primarily responsible for a particular success, then acknowledge it – in some sort of humble way, of course.
As the PM, it’s rare that we get to take credit for anything – it’s usually team efforts or developer’s efforts, etc. So if you accomplish something notable on the project that is helping the overall effort…go ahead and take the credit. You’ll be more sought-after in the future because of it (if you consider that a good thing!).
Passion may not be one of those things that we think of when sorting out what a good Project Manager should have, but now that I mention it, it sort of fits doesn’t it? A PM with passion on a project means that PM is concerned for the effort, the budget, the timeline, the customer, the individual team members, and of course the final outcome.
I can’t think of a time on a project when having a passion for the project and its success and the success and growth of the team members would be a bad thing. Passion for success and reaching goals tends to rub off on others…imagine a whole project team with a decent amount of passion toward succeeding for the company and the customer. Show me a Project Manager with passion and I’ll show you a successful and sought-after Project Manager.
I thought that maybe I was done with this series, but I’ll probably truly never been done with it. The list can be about as long as you like it to be. I had to write more because I thought of one characteristic that really must be discussed: Stubborn.
A check on Dictionary.com yields a few definitions of stubborn…some don’t work for this article, but these definitely do:
- Fixed or set in purpose or opinion; resolute
- Hard, tough, or stiff as stone or wood
I like these – they fit with what I’m trying to get across. The successful Project Manager will not be swayed, cannot be influenced by others into moving off the course he/she has been set upon in order to achieve the goals of the project. In this case, stubbornness is definitely a good thing.
When you’re working with a very talented team of technical experts, managed by a PMO director with other influences and priorities and not intimately familiar with your project, and working with a customer who has a very different set of priorities and influences, it can be very easy to be influenced into making decisions that you wouldn’t ordinarily make. All of these individuals have their own priorities, influences and even other projects that they are working on so while listening to their input is important and necessary - allowing it too much influence over your decision-making can be costly.
As the PM, the project is yours. It’s your neck on the line and your managing all aspects of it. You may have 3-4 other projects that you are managing – that’s just the nature of PM work, but they’re all important and all of them place the target firmly on your head. You’re in the same position as the manager of a major league baseball team or any team for that matter. If the team does poorly, you’re the first one to pay for it. It is critical to stay focused, keep the original project goals and milestones in front of you and in front of everyone on both teams and stay the course.
Listen Well - Act Cautiously
Listening is always a good thing – and it’s a very important characteristic of a Project Manager. A Project Manager who doesn’t listen is stubborn in a different way and is likely a bad Project Manager – and probably won’t last long. So listen. But keep the influences of what the other team members, managers, and customers have to say in check. Develop a reputation for staying on track and managing your projects tightly. Ultimately, you’ll gain the respect of your team, your management, and your customer and they’ll trust your decision-making. If you’re wishy-washy in your decision-making and have a history of changing your mind, not being organized, and ‘flexing’ too much, you’ll never gain their trust and respect and you won’t last long on the critical projects. In fact, you’ll probably never get the high-visibility, business-critical projects assigned to you.
Fearing the Repercussions
Here’s the problem…we don’t like to give the customer bad news. We fear we’ll lose favor. We fear they’ll ask that we be replaced as the PM. We fear that it will appear as though we’re not in control. Fear, fear, fear…if we follow our fear we’ll never accomplish anything.
One thing I learned very early on working on contracts with the U.S. Department of Education is that you need to be open and honest with your customer. I found that going the honest route swiftly meant that we had two groups working on a solution because ultimately if you succeed, the customer also succeeds. It’s in their best interests to help you work through problems, timeframe concerns, and budget concerns.
A Bad Call
The only time I’ve withheld info from a customer was when I was forced to and I deeply regretted it. We never recovered from it and the project was lost. I had worked on that particular project for more than 8 months and it was canceled due to a budget overrun that could have been worked through had I been open and upfront with the customer as quickly as possible. Instead, I had to spring it on them late and was never able to regain their trust.
The best way to approach it is to realize that the customer and their project team are really just an extension of your project team. Not all projects run smoothly and certainly, not all customers are friendly and work well and play well with others. Some can drive you absolutely crazy.
But the 50% that do seem to team up with you and are working beside you every step of the way only want to see the project do well and the PM to perform successfully. It’s a joint effort. Therefore, it is almost never in any project’s best interest to keep the bad news from the customer.
Hopefully, we learn that early on in our marriages (and adhere to it most of the time!) and it plays out the same on our projects. Document the concerns and issues on the issues list put them in front of your customer on status calls and in the status reports and track them. Make it a joint effort and you stand a better chance of successful resolution and happy customer retention.
I realize this may be oversimplifying the situation. Certainly, there are some cases where it’s not necessarily in the project’s best interest to share problems with your customer immediately. But once you’ve assessed it on the delivery team side, share and work through it with your customer.