How to Cheat at IT Project Management

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.

• Share information Information is power, so share information with your team. You will empower them to do their jobs and you will develop a two-way trust that can help when the going gets rough. If you can't share certain confidential information, tell them that rather than side-step the issue. Otherwise, share as much information as is reasonable and prudent. Hoarding information will eventually hogtie the project.

• Find ways to motivate It's often argued that you can't really motivate anyone, they have to motivate themselves. That said, there are things you can do that will inspire others to do a good job for your project. Find ways to let people on the team know that their contribution is meaningful and appreciated. Let them know you understand their situation (if they're working overtime to get the job done, etc.). Thank people for small and large contributions to the project. Find ways to align project work with people's work personalities (see earlier chapters in this book for more detail).

• Remove obstacles One of the ways a manager can inspire commitment and hard work is to be committed to removing as many obstacles as possible for the project team. If team members are having difficulty gaining access to a room needed to set up a lab, take that task on yourself. Make it happen and let the team continue to work on their project tasks. If you see your job as IT PM as the person responsible for removing the roadblocks to success, you'll do your project and your team a great service. Don't take on everyone's battlescertainly team members will have to deal with their own issues, but do work to remove obstacles that impact your project when appropriate.

• Don't take it personally Whether someone does a good or bad job, whether they're early, on time, or late, don't take it personally. Most of the time, work performance issues are unrelated to the IT project manager (and unrelated to the project itself sometimes). As a manager, you have to develop a bit thicker skin. Continue to focus on the outcome. Continually ask yourself, "What outcome do I want and will this action help me get the outcome?" If the answer is no, stop. If the answer is yes, continue. Focusing on behavior, results, and outcomesnot personalitieswill help you manage the project and your team.

• Foster cooperation, not competition We live in a competitive world and many companies encourage competitioneither implicitly or explicitly. On a project team, however, competition is usually a negative force causing people to withhold information, hoard resources, and generally work as individuals rather than as a team. You pull together a project team because you need the project work to be greater than the sum of its parts. If that wasn't the case, you wouldn't need a team at all and you could simply hire contractors to do work and be done with it. Most projects require problem solving, innovation, and other skills that are greatly enhanced by team membership. Look for ways to encourage team members to cooperate and only reward cooperative (not competitive) behavior. Some competition may be fine if done in the spirit of making the project better, but don't let it rule the team.

• Foster exceptional project work performance In order for individuals on the project team to do a good job, they must have five things:

  • A clear understanding of the purpose, goals and objectives for the task (or project).

  • A plan for how to achieve the goals and objectives.

  • The skills, resources, and time to do the job.

  • Feedback on performance.

  • A clear understanding of his or her authority to make decisions and take corrective action to deal with variances to the plan.

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.

10.6.2.1. Deliverables

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:

• Have too much work to do

• Have run into a problem completing the work

• Lack the skills required to complete the work

• Lack the motivation to complete the work

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.

10.6.2.2. Quality

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.

10.6.2.2.1. Performance

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.

10.6.2.2.2. Process

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.

10.6.2.2.3. Specifications

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).

10.6.2.3. Communication

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.

• Team members miss project team meetings

  Problem: People miss scheduled meetings either because something unexpected came up or because they are purposely avoiding the meeting. In the latter case, they may be skipping the meetings because they feel the meetings are not productive or because they are scheduled at a time that is difficult to break away.

  Solution: Make sure your project team meetings are short and to the point. Make sure you have an agenda going in and that you stick to the agenda. Team members can socialize before or after meetings, but don't let the meeting itself turn into a schmooze-fest. Make sure meetings start and end on time and accomplish their objectives. Talk with missing team members one-on-one to determine the reason for the team member's absence.

• Team members arrive late or are ill-prepared for team meetings

  Problem: Team members may arrive late or be ill-prepared because they occasionally run late or because they are not placing a priority on these meetings. They may simply have too much work to do to arrive on time or to be prepared, but these should raise warning flags for you. If they have so much work they cannot arrive on time and prepared, they may not be giving their attention to your IT project (assuming they have multiple priorities and projects, which most people do).

  Solution: Again, if the meetings are well-run, people are less likely to arrive late or ill-prepared. If the meeting starts on time and covers the agenda items, people are more likely to attend and be prepared because they know they will be called upon to discuss their data. Many project teams produce a status report based on the outcomes of the previous meeting, which helps keep everyone on the same page. If a team member is ill-prepared, talk with him or her one-on-one to determine if there is a misunderstanding about what is expected for team meetings. If they have too much work on their plates, you need to work with them to find a solution that will allow them and your project to be successful.

• Team members bicker during team meetings

  Problem: Team members seem to disagree on everything during team meetings. They cannot come to consensus and some seem to play devil's advocate just for fun.

  Solution: This problem can occur when team members represent different corporate interests such as Marketing and Engineering. If the root cause appears to be a difference of perspective, you might assign the opposite point of view to the team members and ask them to argue "the other guy's" case. This often helps people see things from the other's point of view and helps bridge gaps. You might also schedule an additional meeting to hammer out these differences so things can move forward. Make sure you stick to the meeting agenda and request (require) that team members discuss things in a positive framework.

• Team members do not participate in team meetings

  Problem: Team members come to meetings but do not participate or participate minimally. When called upon they reply with "I don't know" or "I'm not sure" or "I have no opinion." This is sometimes caused by people feeling the meeting is a waste of their time or that the meeting is a hostile environment in which to interact. Other times it is caused by people feeling nervous talking in front of a group or they may simply be shy and not assert themselves in the conversation.

  Solution: Make sure the meeting is effective and also make sure you foster a positive communication style. Ask people to focus on behaviors and tasks, not personalities. If a team member is simply not comfortable talking in the group, draw him or her into the discussion at points where their expertise would be useful. Make sure to call upon team maters who are not voluntarily talking. Ask open-ended questions that require a longer response than "I don't know" to get all team members participating.

• Team members interrupt, talk too long, meander

  Problem: Team members interupt each other or don't stay on topic. Interrupting others can be a sign of poor manners, excitement, or lack of awareness. Regardless of the root cause, you should encourage team members to be respectful of others and that means allowing others to finish their thoughts or statements. On the flip side, there seem to be people who seem to be unaware that they talk non-stop. These folks can go on and on and say little, if anything, of importance. Oddly, the best way to manage these people is to interrupt because otherwise they will dominate a conversation, often without even meaning to do so. However, the person to interrupt should be the moderator or team meeting leader.

  Solution: One of the jobs of the moderator is to make sure the meeting stays on track so the moderator can and should politely interrupt people who go on and on. If everyone understands the role of the moderator, they are less likely to take offense if they are interrupted. Finally, you can hold "stand up meetings" where there are no chairs in the room. This can facilitate focused communication and information sharing and provide a needed change of position for people who sit all day long.

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.