Executing the Project

Overview

This chapter opens the Executing phase of the project life cycle. Executing is where the work of the project gets done. We've talked about the work, planned for the work, and described what the work will look like, and now it's time to do the work.

You can't complete a project without people, so we'll spend considerable time in this chapter talking about project team development, negotiating and problem solving, and your roles and responsibilities as the project manager, including motivation techniques.

We'll also talk about progress reporting and who gets what types of information. The chapter will conclude with a discussion of taking corrective actions to keep the project on track.

In this chapter, you will learn:

Assembling the Team

One of the most important activities you'll perform as a project manager is managing and leading the team. You've created the Planning documents and gotten approval for the budget, but you will have difficulty keeping the project on task and on time without a smoothly running team. And guess who's responsible for putting the team together and keeping team members motivated? You guessed it, the project manager.

Projects exist to create a unique product or service, and they require the cooperation of a team of folks to do the work accurately and completely. Aside from the robots on Star Wars and those found on some factory floors, most project teams will be made up of people. And here's the tricky part: Team members are people and all people come preloaded with personalities, biases, work ethics, abilities, and so on. It's your job as the project manager to manage these folks and channel their energy into getting the work of the project completed.

One of the activities that will help your team function effectively is team building. Team building starts in the project Planning phase when you begin to assemble some of the key team players, and it continues throughout the life of the project. Team-building activities help improve your team's performance and keep team members motivated. Team-building activities can be elaborate or simple. You could consider throwing pizza parties as team-building activities or taking the team out to a ball game one afternoon. You could hire consultants to come in and host team-building activities or take the entire team offsite to a rope course or similar team-building activity. There are many books available on team-building activities, and it's beyond the scope of this book to go into all the possibilities. I encourage you to engage the help of consultants who are specialists in this area or read some books on the topic. Engage your team, encourage participation and open communication, and find out what motivates them to perform at their best. (We'll discuss motivation a little later in this chapter.)

We've already identified the types of skills needed to complete the work of the project in Chapter 6, "Planning and Acquiring Resources." We've also assigned some of the key individuals to the project team and used their expertise to help create the project schedule, determine estimates, and so on. Now it's time to identify all the other team members and bring those folks together and get them started on the work of the project. We've already covered how to negotiate for team members and the importance of assuring their availability for the time you've scheduled them on the project schedule. Let's take a look at what happens when you get all these people together in the same place.

Project Team Kickoff Meeting

Now it's time to get everyone together in a room and get the work of the project started. The kickoff meeting with the project team includes those folks who are going to do the work of the project. This is a different meeting than the project kickoff meeting we talked about after the charter was signed. That meeting included the stakeholders, the project sponsors, etc. This meeting is for your project team.

The purpose of this meeting is to lay the groundwork for the project. Not only will you inform the group of the goals of the project at this meeting (among other things), you'll be setting the example for what's to come in future meetings. Start this meeting off by sending out an agenda ahead of time. Let everyone know you intend to start promptly, that you'll be requesting them to participate in the meeting, and that you're sticking to the agenda.

At the first meeting, allow time for all the team members to introduce themselves and spend a minute or two describing their role on the project. You will take it from there and discuss the following information:

It's critical that this first meeting convey the information shown in the list above and that the team members understand what you've told them. Ask them for feedback and ask them to confirm that they understand the project goals.

It's also important that team members understand from the get-go what you expect out of these meetings. Don't let them carry you down rabbit trails, but do allow time in your regularly scheduled team meetings to discuss status, problems, and what they expect to accomplish during the next time period before you meet again.

Now that everyone has been introduced, it's time for them to start working together. Once they do, they'll progress through several stages of team development, which we'll look at next.

Four Stages of Team Development

The process of team development and team building seems very simple—bring a diverse group of people from inside and outside the organization onto the same team and get them to work together in the most effective and efficient way possible. While this is easier to say than it is to do, there are ways to make it happen.

One of the first things to recognize when working with your project team is that they'll progress through several stages of development. These stages occur with any group of people who work together, and it doesn't matter whether the people know each other or not. In fact, many times your project team members will not know each other prior to working on the project. You'll want to make certain that you hold project team meetings to allow the team members time to get to know one another and to progress through the stages working as a group. It's important for you as the project manager to understand these stages so that you can help them progress to the most effective stage of development. Let's take a look at the four stages of development.

Stage One: Forming The forming stage occurs when all the team members have been brought together and introduced. Here they'll be told about the project objectives, the tasks they've been assigned, and the expectations the project manager has regarding the project and the team. At this point team members are asking themselves several questions, including:

During this stage of team development people will be somewhat reserved. They'll usually be polite and have a formal business approach communication style. Teams progress through this stage rapidly.

Stage Two: Storming The storming stage is where the team starts to realize what the work of the project entails. The team members become more comfortable around one another and start challenging one another for position and status within the team. Then the sparks start to fly. Conflicts arise about the task assignments, and team members start asking these types of questions:

You'll know you've entered the storming stage when conflicts start to occur.

We'll discuss some conflict-resolution techniques in the next section that you can use to help the team work through these issues. Remind the team of the project goals and keep everyone centered on those goals. Conflicts aren't bad in this case; they're actually necessary to get the team into the next stage. Team members need to get a feel for where they stand, where the extent of their responsibility lies, and how they'll accomplish their tasks working with the other personalities of the team, and that usually involves some tussles. Questioning and conflict help clarify the goals of the project for everyone on the team, not just the person in conflict, so encourage your team members to ask questions and discuss conflicts openly. But you won't progress to the next stage until the team has resolved the conflicts.

  Note 

Some teams never progress out of the storming stage. It's difficult to manage a team in this stage, and it could have a negative impact on the project if relations are particularly nasty among team members. Consider replacing team members who are not cooperating or are the cause of unnecessary conflicts if the team doesn't seem to be making any progress.

Stage Three: Norming The norming stage is where the team starts to calm down, settle in, and do the work of the project. They know what's expected of them, and they have accepted and understand the goals of the project. The team members are comfortable with one another and with their own positions within the team, and they'll exhibit affection and familiarity with one another. Conflicts subside, and the team members confront the project concerns and problems instead of one another. And they make decisions jointly, getting input from all the team members.

Continue to hold team meetings, especially during this stage, because team members can fall back into the storming stage if left to their own devices. Monitor each team member's participation, and encourage the team to continue to remain focused on the project's goals and alert you of any problems as soon as they arise.

Teams in the norming stage are efficient, functioning teams. If your team has progressed to this stage, they'll likely be productive and work effectively toward meeting the project goals. But they still aren't performing at their absolute best— that happens in the next stage.

Stage Four: Performing The performing stage is the most mature stage of all the development stages. The team functions in the most productive and effective ways possible. They support one another, they monitor themselves, and they achieve great things in this stage. Teams that operate in the performing stage are almost unstoppable.

However, not all teams make it to this stage. If you're lucky enough to manage one or two teams during your career that are functioning in this stage, you'll never want to work any other way. There's a harmony and a synergy among the team members and in their relationship with you that cannot be duplicated.

This stage cannot be forced. It happens because team members have mutual respect for one another and for you and are fully dedicated to the goals of the project. They've accepted the project as their personal responsibility and hold themselves accountable for doing the job well.

The most effective teams perform at stage four. As we stated, you can't force this stage on the team. There are some things you can do as the project manager to help the team progress to this stage, though, including communicating effectively, asking team members for input, and using effective conflict-resolution techniques. Each of these ideas is recapped below.

Communicating effectively Schedule regular team meetings and individual meetings with each team member. Encourage them to bring concerns and problems to the meetings. Be certain to inform the team of anything that impacts them directly as soon as possible.

Soliciting input Ask team members to participate and contribute. Teams that feel they have some control over the project and project decisions will be more productive than those that feel they have no control. The project manager can give them decision-making authority over day-to-day activities to help encourage support and buy-in.

Resolving conflict effectively Encourage the team to try to resolve their own conflicts as they arise. Whatever they cannot resolve on their own should be escalated to you. Encourage the team members to voice their concerns and attempt to reach mutual agreements concerning alternatives whenever possible. Remember to start by getting all the facts, and then examine the facts for possible solutions.

Effective Team Characteristics

Effective teams are those that function in the norming or performing stage of team development. They're energetic and enthusiastic about the work of the project, and they become good problem solvers. Effective teams are a joy to work with and will amaze you with their creativity. Encouraging individual participation, maintaining an open-door policy, and engaging the team in team-building activities will go a long way toward making your next team a smoothly running team. We'll talk more about the project manager's role in team development in a later section. Some of the characteristics of effective teams are shown here:

Dysfunctional teams operate with the opposite characteristics of effective teams. This is not the kind of team you want on your next project. Be aware of the warning signs of dysfunctional teams shown below:

I've had the experience of working with both types of teams, and the effective team is much more fun to work with. Successful project results happen because of the energy and focus the team pays to the project goals. Problems are resolved effortlessly, and everything just seems to click. Dysfunctional teams, on the other hand, take up all of your time and all of your energy, and there is little benefit in return. Sometimes you have no choice but to tough it out with the team you've been given, even if it is dysfunctional. If you're working with a dysfunctional team, my best advice to you is to get your team into team-building activities and open up the lines of communication. Also consider whether your team members are misplaced. Do they need training? Have they been asked to perform tasks they aren't prepared to work on? Do they have the resources they need to perform the task? If team members don't feel as though they're prepared to handle the tasks they've been given, or they don't feel like they're a valuable part of the team, they'll likely take on "don't care" attitudes, which leads to dysfunctional teams.

  Note 

A poor attitude is like the common cold. Once one member of your team catches it, they all catch it. You'll want to cure or help prevent a poor attitude before other team members catch it.

You can help prevent and correct your team's dysfunctional behavior by following the guidelines outlined in the next few sections of this chapter.

Negotiation and Problem Resolution Techniques

One of the things I can promise that you'll encounter on your next project is problems or conflicts, that is, unless you're working on the project all by yourself. But even then, you have the customer to consider, and where there's a customer there's a person. Where there are people, there'll be differences of opinion, differences in communication skills, and differences in needs, goals, and desires.

Conflict happens when one person's needs, goals, or desires differ from another's. (This can happen at the corporate level also, not just the individual level.) Sometimes, conflicts are easily resolved by simply meeting with the person or people who have an issue and discussing the situation and possible alternatives until a reasonable resolution is reached. Other times it's not that easy.

The most likely areas that will require problem-solving skills or negotiation are the project schedule, resource assignments, issues regarding contract elements or price, issues regarding your or another's authority and responsibility, and problems surrounding the use of business or technical processes. An example of this last one might be the project management methodology you'll use for the project. Someone may challenge the process you're using or the way you're implementing the processes of the chosen methodology that will require negotiation to resolve.

Every good project manager will have to use problem-solving and negotiation techniques; it's guaranteed. Good communication skills and good problem-solving skills go hand in hand, so you'll want to fine-tune these skills and include them in your project management tool bag. There are several techniques you can use to negotiate and resolve project issues, and we'll touch on a few of those here. If you're interested in digging into this area further, there are books devoted to the topics of problem solving and negotiating.

Start at the Beginning

The time to start solving problems is when they first begin to arise. Tackling your problems early on will many times be enough to keep them from escalating into out-of-control octopuses. Problems, like octopuses, can have many arms, and just when you think you've taken care of one of those arms, another one will grab you from behind when you're not looking!

When it's evident that you have a problem or an issue on your hands that's going to require negotiation, you should first document the problem. Define the issue, in writing, detailing as much as you can. Break it down into smaller parts, and try to focus on the problem, not the symptoms of the problem. Defining the problem, and asking the other party to do the same, may bring to light a miscommunication or misunderstanding that's easily cleared after everyone understands what the real issue is.

In addition to documenting the problem, document the assumptions about the problem. This is another potential problem area. If you assume that I need a certain employee from your department for six months starting June 1, and I assume that I need that employee starting next week, we might discover that there isn't a problem after all. We both understand, or assume in this case, something different, and the issue is easily resolved.

Next, document your proposed solutions. These can be ideas at this point and not full-fledged plans for detailing all the aspects of the solution. The point is to start thinking about how the problem can be resolved. Offering solutions to the other party shows that you're willing to work together toward a resolution and aren't going to camp on the "it's your problem" approach. Early in my career I had a manager who would not allow me to approach him with a problem unless I had at least one suggestion for a resolution to the problem. I remember wondering at the time what the company paid him to do, but this technique of thinking through problems and coming up with possible alternatives before confronting someone has helped me come to quick resolution many times.

  Note 

Documenting the problem, your assumptions about the problem, and possible alternatives will help prepare you for the face-to-face meeting and will keep you focused on the issues at hand during the discussions.

After documenting the problem, assumptions, and possible solutions, arrange to meet with the people you're having the conflict with to discuss the problem face to face. I recommend doing this on neutral territory; in other words, meet with them in a conference room or even an offsite location, not in your office. If there is a potential for this meeting to get a little heated, consider using a mediator. A mediator should be someone who is not involved in the conflict and has nothing to gain from the outcome. The mediator will keep the meeting on track, make sure everyone understands the issues at hand, and ensure that everyone has the chance to state their side of the problem and any proposed solutions. Day-to-day project issues you'll encounter won't usually require the use of a mediator, but it is an option if you're having difficulty reaching a resolution that's agreeable to all the parties involved.

mediator

Acts as a third party to negotiate settlements between two or more parties involved in a dispute. The mediator should be a disinterested party with nothing to gain from the outcome of the decision.

Allow each party to discuss the problem from their perspective and to offer alternative solutions. Make sure everyone gets an equal opportunity to state their case. After each person has had the chance to describe the problem from their own perspective, switch roles and let the first person describe, in their own words, what they believe the problem is from the second person's point of view. This is a lot like the listening technique I described in Chapter 2, "Developing Project Management Skills," where you paraphrase what you heard the speaker say so that you're sure you understand what was said. Restating the problem from the other person's perspective might also lead to quick resolution.

Problem solving and negotiation takes practice. Don't worry that you'll lack opportunity, however. The project management arena will give you lots of chances to perfect your problem-solving skills. I believe the most important factor in problem solving is accurately and thoroughly defining the problem. Don't jump to conclusions too quickly though; allow alternative solutions to surface so that all the possibilities can be explored.

Before we leave this topic, we'll look at the five different methods of conflict resolution.

The Five Approaches to Problem Resolution

PMI recognizes five approaches to problem resolution, and I think you'll agree that these cover the range of possible behaviors from all the participants. If you can spot people using these techniques during your next confrontation, you can help steer them toward a successful resolution by keeping everyone in the problem solving technique (the last one described in this section) as much as possible.

Forcing Forcing is when one person, the King or Queen, says, "This is the way it's going to be," and all the subjects agree. The subjects may go away mumbling under their breath that this was the dumbest idea they've heard in a long time, but they publicly agree for fear of losing their head. Forcing happens whenever one person forces their decision on others. Usually the person doing the forcing is someone in power, but not always. Lead technicians and highly skilled employees whom management is in fear of losing can sometimes wield this power. Decisions made using the forcing technique aren't necessarily the best decisions, but they are usually permanent ones because, after all, the boss is the boss and what she says goes.

Forcing typically creates an atmosphere of strife and an "us versus them" mentality. I recommend that you use this technique only when it's absolutely necessary. That means that resolution cannot be reached any other way, so you, or your executive manager, are forced to make the decision and impose it on the group.

Smoothing This technique involves some sleight of hand. You've probably heard the opening line for this technique in meetings you've attended. It goes something like this: "I don't understand what everyone is so upset about. This isn't a big deal. You have all blown this way out of proportion…." After the person who started this is finished with their very convincing speech, everyone in the room looks at one another and wonders why this was such a big deal. As a result, everyone quickly comes to a resolution, only to go back to their desks later in the day and begin thinking about what happened. They'll realize that the real issue was pushed under the carpet and the problem still exists. At the next meeting, the issue will surface again, and the problem-solving merry-go-round will start again unless someone recognizes what's happening and shifts the group to the problem solving technique.

Compromise Compromise is where both parties agree to give up something to reach a solution. On the surface, this may sound like a good technique, but if neither party is enthusiastic about the decision that was reached, they may drag their feet or even change their mind later in the project. Neither side wins or loses in this situation. However, if both parties are committed to the compromise and the solution, it can be a workable technique.

Withdrawal This technique never results in resolution because one of the parties picks up their toys and goes home. They may physically get up and leave the meeting, or they may check out emotionally, but either way they're not participating in finding a resolution. This is probably the worst of all techniques because no lasting resolution can be reached when one party refuses to cooperate.

Keep in mind that this isn't the same thing as leaving a meeting when one party becomes hot-headed and out of control. I know a project manager who got into a tangle with a key stakeholder in a public meeting and walked out. The key stakeholder decided that he was going to take out all his problems on the unsuspecting project manager and proceeded to vent all kinds of nasty things, using some colorful language. The project manager looked the stakeholder squarely in the eye and said, "This meeting is over. When you're ready to act like a professional, call me," and then left the meeting. I wish I could tell you that this never happens, but it does. It isn't an everyday occurrence, but sometime during the course of your career you'll find yourself across from someone like this. Never subject yourself or your team members to the irate ranting of stakeholders. This is a case where it is okay to ask them to knock it off or leave the meeting.

Problem solving This technique is the best technique for reaching a resolution. It's also known as confrontation. The idea behind this technique is that one correct solution exists for the problem, and it's the team's responsibility to dig out all the facts and find that solution. Many times, the act of finding all the facts will reveal the solution. This is the process I described in the opening of this section. Document the problem, let the facts reveal what's really going on, and then work together to come up with a resolution everyone can live with. This is the technique you should use most often.

  Note 

The problem solving technique is the most-often-used technique by project managers for conflict resolution.

When you're in the midst of problem solving or decision making, you should keep the number of lines of communication in mind. (We talked about that in Chapter 2.) Ideal group sizes are between five and eleven people—anything more than that and you run the risk of not being able to make a decision or of making inaccurate decisions.

Remember that conflict resolution involves communication and listening skills as well. You'll find that your work as a project manager encompasses these areas more than anything else you'll do. Good communication skills and excellent project planning techniques are the keys to successful projects. Now let's examine what project managers need to know about effective team development.

Project Manager s Role in Team Development

Project managers have a tough job. Since projects exist to create a unique product or service, every new project they undertake puts their reputation on the line. Even when the projects are similar in size and scope to projects they've worked on in the past, they're still a different animal with different risks, outcomes, and project teams. Every new project has the potential to succeed or fail, and every team has the potential to be an effective team functioning at the performing stage or to be a dysfunctional team.

One of your roles as project manager includes motivating your team members and encouraging the most effective performance from your team as possible. Everyone likes to be recognized for a job well done, and recognition is one of the motivators that drives people and teams to perform at their best. In the next section, we'll look at what motivates team members and how to appropriately reward the behaviors we'd like to see repeated.

Rewarding Experiences

Why do people do the things they do? How do we encourage positive behaviors, outstanding performance, and team collaboration from our team members? Get out your magic wand…what, you don't have one of those? Then the next best thing is to learn some of the basic theories of motivation, including how to reward and recognize team members to help drive your team to perfection. We'll start with a definition of motivation.

Motivation

Motivation is the reason we do the things we do. Motivation is what encourages people to work more efficiently and to produce better results. Project teams that are highly motivated will quickly progress to the performing stage of team development. Team motivation is partly derived by giving the team members clear expectations, clear procedures, and appropriate rewards for their efforts. Teams that receive these things will outperform teams that don't every time.

Motivation is the result of some type of incentive that drives us to perform, and the incentive comes in two forms: intrinsic motivators and extrinsic motivators. Intrinsic motivators are personal things internal to the individual that drive them to perform. For example, some people are naturally driven to achieve. It's a personal matter for them to be the best they can be and perform at their best all the time. They receive personal satisfaction from doing the best job they can. There isn't anything external that drives them to perform like this; it comes from inside.

intrinsic motivators

Motivators that are specific to an individual or are derived from within the individual to spur them to perform.

Extrinsic motivators are typically external to the individual and are usually material in nature. Promises of bonuses, raises, stock options, vacations, and so on are examples of extrinsic motivators. The person performs the task for the benefit of receiving something they perceive has value.

extrinsic motivators

Incentives that are external to the individual such as money, gifts, and rewards that spur them to perform.

Rewards and recognition are types of extrinsic motivators. Let's look at some examples.

Rewards and Recognition

Rewards and recognition at both the individual level and the team level are important team motivators. They are a way for the project manager to encourage desirable behavior and performance from team members.

Rewards and recognition should be in proportion to the accomplishment or achievement. I used to have a boss who had this saying written across the top of his office white board: "Never confuse activity with accomplishment." I don't know the author of this saying, but the message is clear. Being busy isn't the same thing as being productive. You may have team members who put in long hours and seem to have a flurry of activity going on around them all the time. That doesn't mean they're productive. You should gauge the productivity of all team members according to their task assignments, the goals associated with those assignments, and their due dates and budget constraints if they apply. Other softer skills apply as well, such as innovative problem solving, good communication skills, team participation, and so on.

Linking Rewards to Performance

You always want to link rewards to the desired performance. Perhaps your project is time constrained. If so, you'll want to reward team members for meeting the key deliverable dates. If you reward employees for bad behavior (don't laugh, I've seen it happen), you'll get more of that bad behavior, and you'll soon find other team members repeating that bad behavior.

Let's say you've made it clear that the project is time constrained and that you intend to reward employees for meeting key dates. Kit is a team member who consistently meets her dates on time or earlier than scheduled. Linda consistently misses her dates by a day or two, sometimes longer, because of poor work habits. However, you're a really nice project manager so you let Linda's dates slide, granting her a grace period time and again. When the other team members catch on to what's happening, they don't take their due dates seriously.

They've learned that the rewards are not linked to the performance you've specified (meeting key dates) because due dates are extended when their work is late. Be certain the performance you're rewarding is the performance you want to see more of in the future, and make sure to reward consistently and without showing favoritism every team member who performs accordingly.

You'll also want to make certain that the reward is realistic. Let's say you promised your team members bonus checks of ten thousand dollars at the end of the project, provided it's delivered earlier than scheduled while still meeting all the project and quality requirements. If the team members know up front that there is no way the company could afford or ever would reward their employees with bonus checks like this, the promise of a bonus does nothing for them. In other words, the motivator is useless. It has no impact on their performance because they know they aren't going to receive it. However, let's say that your company is known for generously rewarding employees on past projects for a job well done. Then the reward is realistic and team members will work with the expectation that the reward will be granted if they meet the criteria.

  Note 

Recognize achievements, even small ones, with appropriate rewards. Recognizing employees with rewards that are linked to performance is a powerful motivator.

You'll have to use your own judgment when determining what rewards are appropriate. Base your judgment on the cultural atmosphere at your organization, past rewards, and the complexity of the accomplishment. For example, at one organization, meeting a milestone earlier than planned may have the project manager handing out gift certificates for a latte at the local coffee shop, while another organization may approve of your giving out gift certificates for a dinner at a nice restaurant.

The important thing here is that you don't give someone a reward that far surpasses the achievement or effort they expended. Ten thousand dollar bonus checks may be perfectly appropriate for a two-year project that's expected to bring in millions in revenue to the company and was completed four months ahead of schedule. Bonus checks of this size probably wouldn't be appropriate for delivering a small project with minimal benefits to the company.

Be aware that your company policies may limit the types and amounts of rewards you can give. If policy dictates that you can give no more than one hundred dollars per employee per project, you'll have to work within that limit. It doesn't mean that you should hold back rewards because you think they're too small or don't measure up to the level of effort the employees expended.

Recognition and reward are good motivators even if the reward is small. The fact that you took the time to thank the employees and recognize them means a lot.

If you work in an organization that prohibits monetary rewards, consider some of these ideas to use as rewards. These are good rewards to use for small achievements that you want to recognize as well:

  Warning 

When publicly recognizing individuals, consider preferences and cultural differences. Some people do not like to be recognized in front of others and would prefer that the project manager approach them one-on-one. Others love to have the attention of the group lavished on them. Be aware that some cultures do not encourage individual recognition, so these folks may find it difficult to accept a personal reward.

Employee Recognition

Having employees recognize one another's accomplishments or acknowledge the help they've received from someone else is another good motivation technique. There are several ways you can set this up. Employees can nominate each other via a form or e-mail that explains what the recognition is for and how the team member helped them. The project manager can announce these once a month in team meetings and congratulate each person for their participation and help. Or you could use a designated object, like a trophy, a decorative shoe, a stuffed animal, etc., to represent a job well done. The idea here is that employees recognize outstanding performance by presenting one another with the trophy and a note that describes the accomplishment. The recipient of the award holds on to it for a set period of time, perhaps a month, and then they must pass it on to another team member in the fashion they received it.

Rewards and recognition can be used to help influence employee behavior and to encourage team members to perform at their best. If you're not particularly good at rewarding and recognizing team members yourself, consider appointing someone else with this duty so that it doesn't get swept under the carpet altogether. There are dozens of books available on motivation and employee behaviors if you're really interested in learning more about this topic. As the project manager, you have to win the respect and trust of every new team you lead, and that takes time. If you're a great project leader, your reputation will precede you, but it isn't a guarantee that folks on the new team will instantly respect and trust you. They need time to form their own opinions.

Leadership is granted to project managers by default—they've been appointed by an executive sponsor to lead the project. But it doesn't mean that they are a leader or that team members will respect their leadership. Project teams typically have informal leaders as well. You'll want to firmly establish yourself as the leader of the project or else the informal leaders will have all the control behind the scenes. We'll talk about how to do that in the next section. But before we get into some specific things you can do to win the respect and trust of your team members, let's look at the different forms of leadership power.

Leadership Power

Project managers, leaders, senior managers, team members, and others use power to influence others to do things or perform tasks in specific ways. Each of us uses different forms of power at different times depending on our personality, personal values, and the company culture. You don't have to be in a position of power to be a leader. Teams may have informal leaders who wield a lot of power. Conversely, a senior manager who waves a magic wand over some unsuspecting team member and says "Poof, you're a project manager!" does not make that person a leader.

There are several different types of leadership power. We'll explore each of them and their characteristics in more depth below.

Reward power We talked about rewards and recognition in a previous section. Reward power is the ability to grant incentives or bonuses to team members who perform their job functions well. Team members respond to this type of power by performing the desired behaviors for the reward (provided the reward is realistic and is linked to the performance, as explained earlier).

Punishment power Punishment power involves the use of penalties or consequences as a threat for not performing up to expectations. This is the kind of power we talked about way back in Chapter 1, "Building the Foundation," when the ruler of the kingdom picked a "volunteer" to act as the project manager. The volunteer accepted the role out of fear of some dreadful form of punishment that, fortunately, project managers don't have to face today. Sometimes good project managers will be required to use punishment power when team members are out of line or not performing the duties of their job. Work with your manager and human resources department to determine how to appropriately use this type of power in your organization.

Expert power This type of power comes about as a result of a person's knowledge, or perceived knowledge, of a subject. The person being influenced believes the expert knows what they're talking about and will go along with the direction and decisions made by the expert because of their knowledge. Special skills and abilities are another way people receive expert power. Be careful with this one because some people come across as experts because of the confidence they show when they speak about the subject or what their body language conveys, but they aren't experts at all. They may have book knowledge but no hands-on knowledge. If you have doubts about what someone like this is telling you, especially if they're providing technical leadership or advice on your project, get a second opinion.

Referent power Referent power is the power team members give one another because of the respect they have for the individual. One member of the team may be highly respected and trusted by the others and as a result is given referent power by their teammates—when this person voices an opinion, the others listen. Project managers who are held in high regard by the project team receive referent power from the team members. Project managers who have referent power are powerful indeed, because they have the most loyal of all project teams and the members will do most anything the project manager asks of them.

I've had the opportunity to operate under each of these types of power, and referent power is by far my favorite form of leadership power. Referent power isn't something you can manufacture. It happens as a result of the rapport you have with the team and their respect for you and your abilities.

Gaining Trust and Respect from Team Members

Have you ever worked in an organization where almost all the people working within one department seemed to be unhappy, disgruntled, and particularly critical of others? I've witnessed this phenomenon a couple of times in my career, and I've come to attribute this to two factors: the leader at the head of the department and lack of communication from and to the leader, which goes back to the leader at the top. The common denominator here is the leader. Team members emulate the behavior they see coming from you. So it's important for you to set the example you'd like your team members to follow. If you're typically critical of others, have a poor customer service attitude, and never listen to team member input or suggestions, you can expect your team members to act the same way. If you treat your team members with respect and value their input and participation on the project, they will likely treat you and others the same way.

Examine your own organization to see if this isn't true. Departments or teams with dynamic leaders who value their employees, communicate well, have strong customer service ethics, and are good decision makers are usually the ones with the teams that are the most productive and satisfied with their work. When new team members who have sour attitudes are introduced into teams like this, they don't usually last long and will leave on their own accord. It's no fun to have sour attitudes by themselves, so they move on.

There are several things you can do to gain the respect and trust of your team members. A nice benefit of gaining respect and trust of your team members is motivation. Teams that respect their project managers will usually be motivated to perform their best because of their respect for you. Let's look at some of the tactics you can put into practice today to help build trust and respect with your teams.

Do what you say you will do. You've probably heard this one a thousand times but it's worth repeating. Nothing builds trust and respect faster than doing what you said you would do. If you're the forgetful type, write the promise down. Make an appointment on your calendar to give yourself the time or to remind yourself to complete the promised action. This goes hand-in-hand with follow-through. When someone brings an issue to you and you agree to handle it, do just that and get back to the person with a response.

Lead by example. As stated earlier in this section, team members will mimic your behavior. Act the way you'd like to see your team members act.

Communicate and then communicate some more. We covered communication skills in Chapter 2. Pay particular attention to the active listening skills. Don't do all the talking. Get input from your team members and consider their suggestions. If they aren't good suggestions, and some of them won't be, still thank them for their input and ask them to keep the ideas coming.

Maintain an open-door policy. This one goes with communication. If team members find you unapproachable or hard to talk to, they won't be eager to alert you of problems or issues on the project. Let folks know that you encourage them to talk with you, and then make yourself available. (Remember the "do what you say you'll do" action item!)

Be honest. Being honest builds credibility with your team members, and they'll quickly develop respect for you as a leader when they find out you are a truth teller. Sometimes being honest means that you have to deliver bad news. That's okay. Don't sugarcoat the bad news. Lay out the facts for the team, let them know the alternatives being considered, and ask them for their input if appropriate. And by all means, keep confidences. If your team members feel that everything they tell you is going to make the rounds at wildfire speed, you'll end up being the last to know of problems and issues on the team.

Be on time. When you set up meetings, start them on time. When you agree to attend meetings others have set up, show up on time. This shows a respect for others' time. Some managers think showing up late to meetings makes them look important because others have to wait on them. On the contrary, it makes others feel as though they aren't valued by the manager and causes frustration and resentment. If you consistently wait for all team members to show up at the meeting before starting, you're rewarding the wrong behavior. In other words, the folks who were there on time are punished for showing up on time by having to wait for the latecomers because you won't start the meeting until they get there. Reward the folks who showed up on time by starting on time. The latecomers will quickly learn to get to the meeting at the scheduled time or risk being embarrassed by coming in late.

Clearly define the goals of the project. Project team members who have a firm understanding of the goals of the project are more likely to be committed to the project, and team members who are committed to the project are more productive than those who are not.

Clearly define team member roles. This ties back to communication; make sure every team member knows and understands their role and responsibilities on the project. Let them know what measures you'll use to gauge their performance, and give them feedback often.

Hold team members accountable. This sometimes means that you'll have to play the heavy and discipline team members or dismiss them. This doesn't negate all the other tactics listed in this section. Be honest, communicate expectations with your team members, and when they don't measure up, hold them accountable. It's beyond the scope of this book to go into all the possibilities for disciplining and releasing employees. Before things ever get to this point, I strongly urge you to work with your manager and your human resource department to find out how you go about disciplining employees. You should always document unwanted employee behavior, but if you wait until the last minute when you're at the breaking point with the person, you won't recall the kind of details you're going to need to justify your action. Start documenting as soon as you start having problems, and contact human resources.

Most of these things are second nature to those folks who have natural project management and leadership abilities, but it never hurts to refresh your options for team building. Put these ideas into practice with your next project team

Professional Responsibility

Part of your responsibility as a project manager is to ensure the integrity of the project management process and your own personal integrity. To have personal integrity means that you abide by an ethical code. If you're thinking of becoming a certified project manager through PMI for example, you'll be required to adhere to their code of conduct. Most of the things you'll find in the code of conduct are intuitive, but again, it never hurts to refresh your memory.

Regardless of whether you are certified or ever intend to be, there are some personal integrity goals that you should always strive for, including keeping the organization's interests at the forefront as opposed to your own personal interests, eliminating all possibilities of conflict-of-interest situations, and acting professionally. Let's look at each of these areas in a little more depth.

Personal Gain

Your own personal gain should never be a factor in project decisions or when working with your customers or stakeholders on project issues. Truthfulness and integrity should be reflective not only of your own professional experiences but of the circumstances of the project as well.

You should never consider your own personal gain or bettering your own position by compromising project deliverables or milestones. For example, if you've been promised a bonus for finishing the project earlier than scheduled, it would be inappropriate to skip tasks or only partially complete the tasks in order to make it look as though the project was completed early. This would be putting your own personal gain over the best interest of the project. Not only does it show a lack of integrity on your part, but actions like this could also cost you your job.

Personal gain doesn't have to be monetary. For example, a stakeholder may promise you a promotion if you sway the selection committee or if you make sure that their interests in the project are dealt with in specific ways. Working toward your own promotion instead of keeping the integrity of the project process and the product of the project as your top priority would call your personal integrity into question.

Conflict of Interest

A conflict of interest occurs when personal interests are put above the interests of the project or when you use your influence to cause others to make decisions in your favor regardless of the impact on the project. Conflict-of-interest situations can occur with friends, family members, vendors, stakeholders, or anyone else who has an interest in the project. Keep in mind that any circumstance where the possibility for abusing the situation exists can also be considered a conflict of interest. For example, suppose one of your family members works for a consulting company that will be bidding on the project you're managing. This is a conflict of interest because you could potentially share information with that family member that other bidders don't have access to thereby using your relationship for personal gain. Even if you don't share the information, the situation is still considered a conflict of interest because the possibility for sharing information exists. The best thing to do in this case is to let your project sponsor know the situation, don't share information that isn't available to all the bidders, and decline to participate as a selection committee member.

conflict of interest

A potential for personal gain where personal interests are at odds with the best interests of the project outcomes.

Vendor gifts are another potential area for conflicts of interest. Check with your organizational policies before accepting any gifts from vendors. Most organizations have dollar limits on the gifts, meals, and other items vendors can give you. If you're starting or are in the midst of a bidding process and you're part of the selection committee or have influence over the selection committee, don't accept any gifts from any vendors, including lunches. This can be misconstrued as a conflict of interest by other vendors and call your integrity into question.

  Tip 

If you're in doubt regarding whether to accept a gift, you're better off to decline it than put the project at risk. Not only do you put your own reputation on the line in these situations, but you could put the entire project in jeopardy. Vendors who feel that other vendors were given unfair advantages or who can pin you with a conflict of interest can protest the winning bid and delay the start of the project for weeks or months.

Stakeholder influence can also be a cause of conflict of interest. For example, stakeholders may have an interest in one particular vendor and may try to convince you or bribe you with offers of favoritism or promotion if you'll choose the vendor they recommend. Always opt to make decisions with the objectives of the project in mind and not your own, or someone else's, personal interests.

Not only should you not accept gifts, favors, or promises of personal gain from others in exchange for favorable decisions, you should not offer gifts or promises to others to sway their decisions.

Act Professionally

Everyone in the business world is required to act in a professional manner. That involves all the things we've talked about so far and includes controlling yourself and your reactions to situations you'll encounter on a day-to-day basis. You've probably heard this before, but I'm going to remind you of it one more time—the only thing you truly have control over is your own reactions to situations. You cannot control what others will do or say, but you can control your own reactions to what they do and say. When that unruly customer or stakeholder decides to vent on you, take the upper road and remain calm. Practice active listening, ask some clarifying questions, and let them know that you'll research the issue and get back with them. If they're especially up in arms, ask if you can schedule a meeting with them at a later time to go over the issues, and drop the topic until everyone has had a chance to cool down.

Here are some of the things you should keep in mind when working on any project:

  Note 

Team members represent you and the project. They should act professionally at all times, and it's your job to ensure that they do. If team members are acting out of turn, coach them regarding the standards of conduct you expect. Make sure you're leading by example so that they witness the standards of conduct you expect in action.

Progress Reporting

We're going to shift gears a bit and talk about another important area in the Executing phase of the project, progress reporting. Project managers are responsible for reporting on the progress of the project. In order to do that, you'll need information from the team members, vendors, and other key personnel on the project. There are two ways to gather this information, formally and informally.

Make it a habit to walk around during the day and chat informally with team members to keep yourself up to date on where things are. Remember that body language can tell you a lot. Get to know your team members and build that trust level so that they feel comfortable telling you what's up. Stay alert for signs that trouble may be brewing, and often ask the team how their work is going.

Who Gets What?

The communications plan we talked about in Chapter 4, "Defining the Project Goals," outlines who should receive information about the project, what type of project information they get, and how often they get it. During the Planning stage, however, you may not have identified all the information the stakeholders want to see now that the project is under way.

Aside from the regular status reports, stakeholders may request information regarding schedule changes, scope changes, variance reports, resource usage, revised cost estimates, quality measurements, and so on. As the project manager, you'll have to produce the information they've requested. It's a good idea to ask the stakeholders requesting the new reports a few questions to keep yourself from spinning your wheels producing information they don't find useful. Ask them to describe the purpose of the report, what specific types of information they're looking for in the report, how often they'd like to have the information reported, and who should get the information. I'd suggest setting up a time to meet with the key stakeholders to fine-tune the details after you've come up with a draft of the report.

Don't forget to update the communications plan to include the new report and who gets copies of it. Well, you knew it was coming. I've never worked on a project yet that did not require status reports, so let's get to it.

Status Reports and Action Logs

I recommend requiring your team members to send status reports to you on a weekly basis in written form. This is the best method of collecting project status and gives you a way to condense and consolidate the information for the stakeholder meetings we'll talk about shortly.

Many project management software programs have status-reporting features built in. If you're not using one of their tools, you could use a form like the one in Figure 10.1 below. Use this template to build you own status reports. E-mail the forms to your team members and set a date and time the status report is due, and then hold them accountable for getting the information to you on time.

Most of these sections are self-explanatory. Section two refers to reporting on scheduled dates for tasks or deliverables. For example, if you have task due dates coming up within this reporting period, list the tasks here showing their due dates and their actual completion dates or refer readers to the project schedule if there are too many tasks to list here.

You should take each of your team members' reports and create one overall project status from their combined information. Once you've consolidated all the status reports into one, you could use this form to report status to the project team during your team meetings. It's important for the team to know that the project is making progress because it will keep them motivated and committed to the goals of the project. You should start off every project team meeting with an updated status and also note any progress on the project schedule as well. Report to the team when milestones are met or deliverables are completed. You might want to consider having celebrations when important milestones or deliverables are met to keep the team motivated and get them focused and enthused about the next set of deliverables.

Consider keeping a copy of the project schedule in a place where the team can see the progress that's being made. As tasks are completed, check them off or highlight them. You could use the network diagram to note progress as well. Tape up a copy on the wall in the project team meeting room. Everyone can see the progress at a glance as you check the boxes on the network diagram that have been completed.

I recommend adding one additional report to your status updates when reporting at project team meetings and stakeholder status meetings called Action Items. These are issues, problems, or questions that need to be researched and resolved. Track action items and report on them at every meeting. Let those who are responsible for action items know that you're going to ask for the status of their action items at the meeting (or before). This report should contain the elements shown in Figure 10.2 below.

As your action items are resolved, roll them off this report onto a separate list to keep for reference purposes. I like to keep resolved items on the current status report for two weeks (or two reporting periods) and then roll them off to an archived list. As always, keep a copy of the action item log in the project notebook. This can be a great tool to use for future projects when you're identifying constraints, risks, and tasks.

Stakeholder Status Meetings

You'll want to hold status meetings with the key stakeholders, sponsor, and customers on a regular basis as well with your project team. Set up your stakeholder status meetings at regularly scheduled times, just like the project meetings. Send out an agenda before every meeting. What you report during these meetings depends on the complexity of the project and the makeup of your stakeholder group. At a minimum, you'll want to report on the following project items:

You could use the status report shown in Figures 10.1 and 10.2 to report to the stakeholders if the project is small in size. Otherwise, you could use a milestone chart like the one we talked about in Chapter 5, "Breaking Down the Project Activities." This shows the progress of the milestone delivery dates and shows, at least in a high-level view, whether the project is progressing as expected.

Leave time at the end of the meeting for questions. If you don't know the answers, don't bluff. Let them know you'll research the answer and get back to them, and then follow through.

Taking Corrective Action

One of the functions of the Executing phase of the project is taking corrective action. Things do go wrong on the project, and it's the job of the project manager to take the right actions to keep the project on track. Corrective action includes any actions taken to keep the project in line with the project plan. These might include reducing the scope, changing the schedule, adding or reassigning resources, and other similar actions.

corrective action

Any action taken to ensure that the product of the project meets the requirements of the project as described in the scope document.

Perhaps you're working on a project that requires parts for the hardware you're building to be manufactured to certain specifications. When the first shipment of parts arrives, you discover that they're a half an inch too small. You notify the vendor of the problem and ask them to correct the process and send new parts in the specified size. Another example of a corrective action might include rearranging equipment delivery dates so that the project tasks stay on schedule. Any action you take to keep the project on track with the project plan is a corrective action.

Corrective actions are outputs of the Controlling process (which comes after the Executing process), but remember that they're inputs into the Executing process. We'll talk about the Controlling processes in the next chapter.

Terms to Know

Review Questions

1. 

Name the four stages of team development.

____________________________________________________________

2. 

At what stage of team development do team members struggle with conflicts and questions regarding their position or status on the team?

____________________________________________________________

3. 

What are some of the things you can do to prepare for conflict resolution meetings?

____________________________________________________________

4. 

What are the five approaches to problem solving, and which one should project managers use most often?

____________________________________________________________

5. 

Describe the two types of motivators.

____________________________________________________________

6. 

Why is it important to link the reward to performance and to make the reward realistic?

____________________________________________________________

7. 

Which of the four types of leadership power is a result of a person's specialized knowledge or abilities?

____________________________________________________________

8. 

Suppose you're in the midst of receiving bids for work on an upcoming project. Your favorite vendor contact, whom you've used many times in the past, offers you and your family tickets to box seats at the upcoming ball game. The box seats include a catered dinner. You decline, explaining to the vendor that this could be construed as what?

____________________________________________________________

9. 

What types of project information will stakeholders normally want updates on during the course of the project?

____________________________________________________________

10. 

Corrective actions are an output of what project process?

____________________________________________________________

Answers

1. 

The four stages of team development are forming, storming, norming, and performing.

2. 

The storming stage is where conflicts arise and team members struggle with one another to determine position or status within the team.

3. 

Documenting the problem, your assumptions about the problem, and alternative solutions will help you prepare for face-to-face meetings where negotiations or problem resolution must take place.

4. 

The five approaches to problem solving are forcing, smoothing, compromise, withdrawal, and problem solving (also known as confrontation). Problem solving is the technique project managers should use most often.

5. 

Intrinsic motivators are things that are internal or specific to the individual that drive them to perform. Extrinsic motivators originate from outside the individual and include things like bonuses, stock options, and so on.

6. 

Rewards linked to desired performance will produce more of that behavior in the future. The reverse is true also. If you reward bad performance or behavior, you'll get more of it in the future. Rewards should be realistic or they lose their power to motivate.

7. 

Expert power comes about as a result of a person's knowledge of a subject or as a result of specialized skills they have. The other types of leadership power are punishment power, reward power, and referent power.

8. 

In this situation a conflict of interest would have occurred if you had accepted the tickets from the vendor. You'd have experienced a personal gain while allowing the vendor to influence you to make a decision in their favor regarding the project work.

9. 

Stakeholders require status updates on the progress of the project, and status usually includes updates on work completed this period, project schedule updates (changes, dates that were met, and dates that were missed), project issues, budget updates, and change requests.

10. 

Corrective actions are an output of the Controlling process but an input to the Executing process.

Related

Категории