10.6. Managing the Project Team
We've discussed how to manage and motivate a project team at length earlier in this book, so we're not going to repeat that material here. If you are new to IT project management or new to management in general, you may not feel comfortable managing a group of people over whom you have no direct authority. If that's the case, you should review earlier material on managing highly effective teams and you should seek the advice and guidance from a more experienced project manager. That said, we will discuss some of the common problems project managers run into in managing the team and we'll give you a few pointers to use to help overcome those problems.
10.6.1. Effective IT Project Management
If you don't like working with people, you're probably always going to have mixed emotions about project management. Projects don't just happen, people make them happen and the project manager's job is to ensure that those people have the time, skills, tools, and motivation needed to get the project tasks done. The job of an IT project manager is one part manager, one part communicator, one part negotiator, and one part cheerleader. To manage the project successfully, you'll need to manage people successfully. Some IT PMs just naturally work well with people, others struggle a bit. We're not going to give you a short course on management here, but we can give you a few tips to make your job as IT PM just a bit easier. Keep these principles in mind as you work with your team.
The last bullet point is particularly important because team members must be empowered, to some degree, to make decisions in order to complete tasks successfully. Have you ever called an 800 number about a problem with a credit card statement and gotten that person that says, "You are correct. This charge posted twice. However, I am not able to fix the problem." It drives most of us nuts because we're required to jump through three more hoops to get the problem resolved simply because the person to whom we first spoke did not have the authority to resolve the problem. This will drive your team members nuts as well when they face problems they know how to resolve but lack the authority to do so. A person without information cannot take responsibility. A person cannot take responsibility without authority. When someone is responsible for a deliverable but is not given the authority to get the job done, they will typically either seize authority or fail. Neither is an ideal outcome.
10.6.2. Dealing with Project Team Issues
As an IT project manager, you'll have to manage the performance of team members even when you lack the formal authority to do so. Review Chapter 4 for more in-depth information on this topic. In this section, we're going to focus specifically on issues that may crop up during the work phase of the project. As with other topics, the list is not intended to be exhaustive, but to cover some of the most common issues that arise. If you run into issues you don't know how to handle, beeline it to your HR department or your manager for some impartial advice or coaching. Whatever you do, don't let project or team issues simply slide. They tend to only get bigger and more complicated with each passing day.
If project team members fail to meet deadlines for deliverables, the project schedule will begin to slip. How much it slips obviously depends on how much each task slips and whether or not it's on the critical path. Failure to meet deliverable deadlines can indicate that team members:
Many experienced managers know that most performance issues typically boil down to two root problems: competence and attitude. If someone is incapable of completing the work, your job as IT project manager is to either reassign that task to someone who is qualified or provide the training, tools, or resources needed for the current person to complete that work. If someone is unwilling to complete the work, you have to either talk with that person to change his or her attitude or remove him or her from the team.
As the IT project manager, you may be hesitant to take action related to performance, especially if you lack formal organizational authority. However, performance problems by team members put your project at risk, so it is incumbent upon you to deal with these issues clearly, directly, and immediately. Some problems do just go away, but performance problems are usually not among them. If you're not comfortable discussing these problems with a team member, go to your Human Resources manager (or equivalent) and ask for advice and language to use in dealing with these issues. Having the right language to use to address the issue in an appropriate manner can be the biggest challenge and a good HR person can help you out.
As mentioned earlier in the book, your project processes should include a performance evaluation process (typically performed at project close out and discussed in Chapter 12). Managing performance, like managing your project, is a daily task not just something you do when closing out the project.
If team members are completing tasks below the required level of quality (performance to specifications), your project is in serious risk. You can refer back to Chapter 7 for a thorough discussion of quality, but in this section we'll discuss how team members may contribute to quality problems and what you can do to address these issues. Quality problems can be performance issues, but they can also point to process or specification issues. Your first task, then, is to determine the root cause of the quality problem. Quality problems tend to fall into one of three categories in IT project work: performance-based, process-based, or specification-based.
Performance issues can be the cause of poor quality work from team members. In some cases, the person doing the work lacks the skill or ability to do the task, in which case you have to reassign that task or provide training, coaching, or guidance. In other cases, quality issues may stem from a lack of understanding about requirements or a lack of attention to requirements. In either case, your job as IT PM is to review the requirements for the task(s) and ensure the team member has the capability and resources to complete or rework the task so it meets quality standards.
Process issues can also create quality problems if the defined process or procedure is incorrect. Some procedures may be developed at the outset of the project and may require refinement or modification during the course of the project. Other procedures may not be obviously incorrect but yield sub-optimal quality results. If you're confident the team member has the skills and capabilities to accomplish the task and understands the specifications, you may want to check the process they're using to determine if this is the root cause. The team member may be performing work in the wrong order, may be receiving work in the wrong order, or may be following incorrect procedures. For instance, if a procedure was written up for installing a disk drive in a server and it stated that the drive should be installed with power on, this may be incorrect and yield a high number of initial drive failures. The team member may faithfully follow procedure but that is what leads to the quality issue.
Many IT projects have specifications, both functional and technical, developed at the front end of the project during a feasibility study or during the definition stage. Sometimes the specifications end up being slightly off or flat out wrong. Sometimes specifications change after the project is defined, sometimes an error is made in writing the specification, and other times the specifications are correct but impossible to meet. Quality issues that stem from problems in the specifications are the most serious because they typically mean that one or more parts of the project plan will have to be revised and this almost always impacts scope, schedule, and budget (we know it will impact quality because that's what prompted the action in the first place).
Teams often experience communication problems at one point or another. We all know people who are excellent communicators and others who have difficulty stringing together a coherent sentence. Good communications are crucial for a successful project as you and the team try to manage many moving parts. If the team is having difficulty communicating, look for root causes. One of the important elements we discussed at length in Chapter 4 was differences in styles. People with different work styles communicate very differently and this can lead to frustration and miscommunication. Someone from Marketing might naturally talk more and speak in "big picture" terms while someone from Engineering is busy worrying about exactly what the Marketing person means because it's not quantifiable or because it seems vague. These kinds of style differences can be managed, but it takes a good team leader to recognize these problems and address them. Often the best course of action in these situations is to use active listening skills, paraphrasing speaker's messages and acting almost as a translator so your team can find that middle ground. Also keep in mind if you're communicating across electronic links (phone, video conferencing) and across time zones and cultures that extra attention must be given to team communications.
10.6.3. Dealing with Project Team Meeting Issues
Having an agenda can help keep the meeting on track, but someone (that is, you, the IT project manager) has to manage the meeting. In some companies, the task of moderating or facilitating the meeting rotates so that each team member has a turn at running the team meeting. In other cases, if you have someone on the team who's good at facilitating meetings, you may ask him or her to be the team meeting moderator on a permanent (for the project) basis. A well-run meeting can help avoid many of the problems we'll discuss next so it's worthwhile to learn to run an effective meeting or to find someone who is good at it. Your HR department may offer classes, tips, or coaching on running effective meetings and it's a great skill to have.
Even if you're great at running meetings, some problems will probably crop up. While there's no standard set of problems, here are a few you might encounter and what they might indicate.
10.6.4. How to Deal with Interpersonal Issues
Entire books have been written on this topic, so we can only point you in the right direction here. As stated earlier, your HR department can be a great resource for guiding you through the process of dealing with a wide range of personnel type issues. Of course, don't go marching into HR thinking you can dump your problems on their doorstepnot so. They're there to guide and coach you, not to do your job for you. When dealing with team issues, you should start at the top and work your way down. What that means is that you should not get involved with or be concerned about interpersonal issues that do not impact your project's goals, objectives, and deliverables. The most advisable course of action with interpersonal issues is for you to take each party aside individually and discuss the problem candidly. Find out what that person is willing to do differently to improve the situation. Do this with each person involved. Then, set a meeting with all parties to discuss the problem and the agreements you've forged. By discussing the issues individually, you give each person the opportunity to safely vent their frustrations without adding fuel to the fire. By gathering everyone together after that, you bring people back together to recreate their relationships based on their agreements. If this all sounds a bit too touchy-feely for you, remember that if your team doesn't work well together, your project may fall apart. If you're not comfortable doing these things, get some assistance from your HR department. Whatever you do, don't ignore these kinds of issues because they will eventually affect everyone on the team, not just the offending parties.
If a person refuses to acknowledge his or her part in the problem or if they're unwilling to change, you might consider removing them from the project team because interpersonal issues can pull a team apart quickly. Of course, that's in the ideal worldin the real world you may not have the authority to remove someone from the project. However, if the problem puts the project in jeopardy, you should have a serious discussion with your project sponsor and encourage him or her to allow you to replace one or more people on the team. If the project is worth doing, it's not worth putting in jeopardy because of one or two unruly or incorrigible people.
10.6.5. Finishing Project Work
The exit point from the project implementation or work phase is the project closeout. We'll discuss closing out the project in Chapter 12. The deliverable from this stage is the entire set of project deliverables as well as an up-to-date project plan showing the baseline and actual-to-date information. The deliverables and project plan are depicted in Figure 10.6 and are the output or result of this phase of the project. There may be additional data that you add, revise, or update during the close-out phase and we'll discuss that in Chapter 12. Before we head into Chapter 12, we'll discuss some of the more technical project tracking methods in Chapter 11 as well as common project problems and how to address them.
Figure 10-6. Deliverables from this Phase