Leadership optimize

Don't wait to address performance problems on a project

Managing people is one of the core responsibilities of a project manager. It's also one that's uncomfortable for many. Dealing with problem people is one of the difficult aspects of managing team members.

Most project managers have had to deal with performance problems on a project at one point in their careers. Such issues are usually uncomfortable adventures for the project manager. This uncomfortable feeling usually has two causes:

  • The project manager is usually not the functional manager of the team member and therefore does not have total authority for personnel management.
  • The project manager usually doesn't have the right level of experience or training to effectively deal with people problems.

In fact, many experienced personnel managers will tell you that dealing with performance problems are the hardest aspects of their job. It's even more problematic for a typical project manager.

The first reaction of many project managers is to ignore a performance problem and hope that it goes away. It's possible that the situation will take care of itself, but unfortunately, this usually isn't the case.

A project manager's second reaction is typically to recognize the problem but try to determine whether the project can still complete successfully in spite of the performance problems. Again, sometimes that may be the case, but ignoring the situation rarely works.

After all, the nature of a performance problem is that a person is missing deadlines and commitments. (If the person were meeting end dates, the team member still might be causing problems -- but not of a performance nature.)

Of course, people can miss a deadline for a variety of reasons, and that alone doesn't raise the situation to the level of a performance problem. A "performance problem" occurs when a team member is repeatedly late, delivers at an unacceptable quality level, or chronically misses other expectations.

If a project manager believes a team member is having performance problems, the first reaction should be to meet with the team member one-on-one. In this discussion, the manager can discuss his or her perceptions of the employee's behavior and its effects on the project. The discussion should remain fact-based, and the project manager should have a number of examples of when the team member missed expectations.

This discussion needs to be two-sided. One of the benefits of the first meeting is that the manager can share concerns, and the employee has a chance to tell his or her side of the story.

You never know how these first discussions will progress. Sometimes they're difficult and don't accomplish what you hope. However, in many cases, the team member agrees with the project manager and offers reasons for missing expectations.

Once you better understand the causes of the problems, you may be in a better position to help fix them. For instance, there may be some skill gaps that you can use training or mentoring to address. There may also be some personal problems that may require special accommodation on the part of the project manager.

In many cases, the fact that a meeting is necessary will be enough to motivate the team member to do better in the future. The meeting should end with some concrete follow-up commitments for addressing the problem. This could include actions from both the project manager and team member.

If the project manager and team member can agree on some follow-up actions, then you might consider the meeting to be a success. If you can't agree on a common set of follow-up activities, then further escalation up to the functional manager may be necessary. 

Managing people is one of the core responsibilities of a project manager. It's also one that's uncomfortable for many. Dealing with problem people is one of the difficult aspects of managing team members.

One of the best strategies for managing people problems is to address them early before they escalate. If you can successfully address a problem early, it may save you much more aggravation and pain associated with having to deal with a chronic problem later. 

Want more information about managing successful projects? Automatically sign up for our free IT Project Management newsletter, delivered each Wednesday!

15 comments
rajatdhameja
rajatdhameja

Managing the team's performance without being in a formal position to manage team members (functional manager's jurisdiction) is challenging for a project manager. In my experience, a simple method that has worked is by way of asking individuals for their assistance / input / brain storming for get the job done. Ofcourse this should begin early in the project to increase degree of compliance as deadlines approach. Rajat Dhameja

jennylo19
jennylo19

My institution hired 'consultant' as project manager while at the same time using mid level Analyst as real project manager. It is really fustrated because both reasons mentions above - project manager is not the functional manager or may not have the experience to manage personnel.

tuomo
tuomo

After my years in this field I find this a very funny subject - did any read the the "The Mythical Man-Month"? Most of the times I find in my projects that the managers are there just because they are managers - no idea what or how should be done but they have a timelines? Now - I don't say that there aren't any human performance problems but my advice is, deal with it! It isn't as difficult as you would think, some in your group are willing to take more responsibility and they know who and where can do what, listen them. If they say that there is a need for more resources - just do it, forget the company policy or whatever if you want the project to be successful. And don't fire even a slacker in middle of the project if you don't have the consensus of the team, it would only bring the the performance down everybody waiting who is next.

donstrayer
donstrayer

Make it about teamwork. Avoid calling people on the carpet at first. No matter how gently you try to do it they're going to see it as a threat and it's likely to become an adversarial relationship. Instead, talk about "our" problems not meeting deadlines, quality criteria, or whatever. Don't point out how the poor performer has failed. Ask how the poor performer can help. Ask for advice. Have talks with several different team members, not just the poor performer, so he doesn't feel singled out. If the poor performer gets defensive that's a sure sign he knows he isn't doing his best. If that happens, be diplomatic. It's a team problem. Most people really do want to a good job, will get the message, and often will start to turn things around. If they do, thank them for their efforts, no matter how small, and encourage them to keep it up. If they don't, then it's time to start presenting facts about personal performance, ask what's causing the problem, and escalate to the next level of management and/or HR if nothing changes.

Jerry Collins
Jerry Collins

This they call matrix project management and it stinks. A Project Manager will never completely succeed at matrix management of a team. We are nothing but a scape goat for management's "under performers". When they don't meet the deadline/expectation it is always our (PM's) fault, so I don't really believe matrix management works. My belief comes from many years of trying different methods and attempting to be really open minded about matrix management and make it work, but I have never seen it truly work.

Tony Hopkinson
Tony Hopkinson

that's a good idea. I notice that yet again, the donkey to pin the problem on is not a management one. It could be his problem with them, it could be that problem with them.... Repeatedly late, repeatedly given impossible deadlines? Not an acceptable quality, yeah right. Defined by who, couldn't be anything to do with the poor gowk trying to meet his impossible deadlines either could it. My recomendation for a PM going to see a developer about a performance problem. Don't assume that it's theirs. Try not to even give that impression. All you'll do is alienate someone you need onside and seeing at it wasn't him, you still have a performance problem somewhere. Developer's missing deadlines is far from rare, doing it because they are having a domestic with the missus or because they are arses, is something I've seen about twice in twenty + years of team development.

Ay Caramba
Ay Caramba

These are some good initial steps, and certainly the ones that I have encouraged my PMs to take when experiencing problems with team members. While occassionally the problems stem from a team member that is unwilling to pull his/her weight, or due to a needed training issue, I find that more frequently it is due to an overallocation issue. In such cases, escalation to the functional manager is sometimes effective, but I would say that I have seen a less than 50% success rate with these kinds of overallocation problems. I wish I could say that I have a "magic bullet" solution to such a circumstance, but the reality is that most organizations with which I have worked have similar problems, yet have trouble recognizing that it is one that needs their attention. Sure, I can get most managers to admit that folks are overtaxed and that the organization should be re-focusing its efforts on a smaller subset of the most strategically-alinged projects. However, guiding the executive layer of management to the same conclusion tends to be a challenge. It seems that without some way to effectively manage a project portfolio and an overall view of organization resource allocation, PMs will continue to struggle with underperforming team members. Solve the "too many projects, too few resources" problem" and I think that PMs will find they have fewer performance issues. This, I think, would allow them to put the techniques in this article to work for the more severe, yet solvable, HR problems.

Ay Caramba
Ay Caramba

Matrix project management posesses many of the shortcomings that you mention, but it can, and usually does work quite effectively. While most PMs dream of "owning" the team and having full responsibility and authority over it, the reality is that most organizations don't find that type of structure to work within their environment. Matrix project management does have the advantage of being very nimble, with teams able to form and dissolve almost immediately. There are no HR processes to go through to assign people from one group to the next, and you have a better ability to split a team member between multiple projects (which provides with a wonderful amount of flexibility if the resource is not overallocated). This gives the parent organization the ability to respond to both internal and external factors in a quick manner. While matrix project management may be much more challenging for the project manager, it is often the solution that works well for most organizations. That said, for large, strategic projects, I think that there should be more willingness for companies to set up fully-dedicated teams responsible to the PM, ensuring that said project remains a priority...at least for the project team. What I see you describing is a sick culturre, not necessarily a failure of matrixed project management.

Locrian_Lyric
Locrian_Lyric

There can be any number of reasons an individual can be late that has nothing to do with his skill dedication or performance. Some questions to ask: What are his dependancies? How heavy is his workload? How high a priority is *this* project to his boss? Are any of his dependencies late? and last of all, but most important: Is the person missing 'real' deadlines? Let's face it, many deadlines are just lines in the sand drawn for no other purpose than to have them. If he's missing those kind of deadlines, but nothing else is a problem, this isn't either.

donstrayer
donstrayer

This discussion concerned addressing performance problems early, before they become severe. Try to bring the poor performer around by appealing to his sense of teamwork and responsibility rather than enumerating his failings, of which he's probably well aware. If you were referring to an idiomatic expression I used... George Bernard Shaw said that we are two peoples separated by a common language.

Tony Hopkinson
Tony Hopkinson

peg thinking of the standard situation as a team. Team implies single goal, inter- accountability and above all cohesiveness. Breaking and forming teams isn't nimble, it's no buy in, no ownership, no accountability, no interest. Exactly what you had to deal with before someone called it a team to hide the real problems. Call it a mob, or a bunch or something, get the real problem out front. The people you need to do x get naff all out of it and have other demands on their time from people with power over their environment.

Jerry Collins
Jerry Collins

Thank you! Very well said. I just have never seen it really work and over the years have seen many "sick cultures", but do appreciate your input.

Tony Hopkinson
Tony Hopkinson

Are you telling me other demands on teams members are irrelevant to the project? That there are none ? That your job is succesfully manage the documentation of why it failed? That all your people are multi-skilled, you never suffer from a resource shortage, all the business priorities are clearly set and are not allowed to change. I'm talking about the REAL world, admittledly world = Sol 3, just in case you are from a different planet. I work in software development, software development never completes, it some times dies unfulfilled, but it's never ever finished, so of course project team is effectively perpetual. You can set deadlines and phases and versions and goals and such, but they are just management conveniences. I've never worked anywhere where wht you suggest has worked, a few places it's been attempted, but reality kicked it in the nuts before it got off the ground. I can may be see it working in some specific organisations, geared up to execute projects, (or at least their part of them), can't see it working in any standard business that does rpojects as added value as opposed to core business.

Ay Caramba
Ay Caramba

I'm having a hard time following your reply, and am not entirely sure if it is in direct reply to my "I disagree" post earlier, but based on what I understood from your comment I would say that you are describing the shortcomings of matrixed organization management. I would agree that under such a structure, it is difficult to assign ownership and accountability. However, I'm talking about matrixed PROJECT management, which quite frankly, is the normal mode of operation for the vast majority of organizations that I've worked with. And since, by definition, a project is a temporary endeavor, forming and dissovling teams is a normal part of the process. Being able to do so quickly simply makes an organization that much more competitive. An organization with perpetual project teams is a sign of poorly defined scope and a project manager that is lacking in either sponsor support or project management skill.