Approved change requests come about as a result of the change request status updates output of the Perform Integrated Change Control process. (We'll cover this process in Chapter 10, "Measuring and Controlling Project Performance"). Change requests are approved or denied during this process, and once the decision has been made, approved changes come back through the Direct and Manage Project Execution process for the project team to implement.

Approved changes might either expand or reduce project scope and may also cause revisions to project budgets, schedules, procedures, project management plans, and so on. Change requests can be internal or external to the project or organization. For example, you may need to make changes because of a new law that affects your project.

There are several enterprise environmental factors to consider when performing this process, including the company culture and organizational structure, the facilities available to the project team, personnel guidelines and hiring practices, risk tolerance levels, and project management information systems.

Like many of the other processes we've covered, historical information from past projects, organizational guidelines, and work processes are some of the organizational process assets you should consider when performing this process. In addition, measurement databases and issue and defect databases can be used in this process to compare past projects to the current project and to capture information about the current project for future reference.

During Direct and Manage Project Execution, you'll gather and record information regarding the outcomes of the work, including activity completion dates, milestone completions, the status of the deliverables, the quality of the deliverables, costs, schedule progress and updates, and so on. Deliverables aren't always tangible. For example, perhaps your team members require training on a piece of specialized equipment. Completion of the training is recorded as a work result. Capabilities required to perform a service that's described in the project management plan are also considered a deliverable. All of this information gets used during the Performance Reporting process, which I'll discuss during the Monitoring and Controlling processes.

Executing and Monitoring and Controlling are two process groups that work hand in hand. As you gather the information from work results, you'll measure the outputs and take corrective actions where necessary. This means you'll loop back through the Executing processes to put the corrections into place. The PMBOK® Guide breaks these processes up for ease of explanation, but in practice, you'll work through several of the Executing and Monitoring and Controlling processes together.

Work performance information concerns gathering, documenting, and recording the status of project activities. The types of information you might gather during this process include some of the following:

Work performance information becomes an input to a few of the Monitoring and Controlling processes where you'll perform further analysis on the data. It's important that you document this information so that when you get to the Monitoring and Controlling processes, you don't have to backtrack.

As a result of working through activities and producing your product, service, or result, you will inevitably come upon things that need to be changed. Changes can also come about from stakeholder requests, external sources, technological advances, and so on. These change requests might encompass schedule, scope, requirement, or resource changes. The list really could go on. Your job as project manager, if you choose to accept it, is to collect the change requests and make determinations about their impact on the project.

Implementation of change requests may incorporate two types of actions: corrective actions or preventive actions. They may also require defect repairs. Each of these topics are described next.

I'll discuss change requests more in the coming chapters as well. Change requests are an output of several processes, including the Direct and Manage Project Execution process and the Report Performance process in the Monitoring and Controlling process group. Remember that Executing and Monitoring and Controlling outputs feed each other as inputs. And in this particular case, approved change requests are an input, and change requests are an output of the same process.

I told you the Executing process group is about performing the work of the project, and in order to do that, you need resources. You'll look at two processes, Acquire the Project Team and Develop the Project Team, in the next few sections.

Interpersonal skills are often referred to as soft skills. Soft skills include such things as leadership, influence, negotiation, communications, empathy, and creativity. For example, it's important for you as the project manager to have an understanding of your project team members' attitudes and opinions about their work. Bad attitudes, like the saying goes, are contagious. It doesn't mean the person who has the attitude is bad, but if you're paying attention to your team members and taking the appropriate amount of time to listen to their legitimate concerns and issues, and taking action on them, you can go a long way toward stemming bad attitudes.

Soft skills can be learned but in my experience are more often inherent in project managers' personalities. But just because certain soft skills may not be in your nature, it doesn't mean you can't observe this behavior in others and incorporate them into your management techniques.

One other issue to consider regarding this tool and technique is that you'll have resources from other departments who have assignments on the project that you're responsible for overseeing. For example, the finance department and the marketing department might have assigned project activities, and as the project manager, you'll manage their progress. This implies that you'll need general knowledge management skills to understand what the assignments entail and strong leadership and negotiation skills to influence the departments to stay on schedule.

Training is a matter of assessing your team members' skills and abilities, assessing the project needs, and providing the training necessary for the team members to carry out their assigned activities. Training can sometimes be a reward as well. In the software industry, programmers seek out positions that offer training on the latest and greatest technologies, and they consider it a benefit or bonus to attend training on the company dollar and time. If you know early in the Planning processes that training is necessary, include the details of this in the staffing management plan. During the course of the project, you might observe team members who need training, or they might ask for training. Update the staffing management plan with this information.

Many times, project teams consist of folks who don't know each other. They aren't necessarily aware of the project objectives and might not even want to be a part of the team. The project manager might not have worked with the people assigned to the project team before either. Sound like a recipe for disaster? It's not. Thousands of projects are started with team members and project managers who don't know each other, and those projects come to a successful completion. How is that done? It's a result of the project manager's team-building and communication skills.

The project manager's job is to bring the team together, get its members all headed in the right direction, and provide motivation, reward, and recognition to keep the team in tip-top shape. This is done using a variety of team-building techniques and exercises. Team building is simply getting a diverse group of people to work together in the most efficient and effective manner possible. This might involve events organized by the management team or individual actions designed to improve team performance. There are entire volumes on this subject, and it's beyond the scope of this book to go into all the team-building possibilities. The exam tends to focus more on the theories behind team building and the characteristics of effective teams, so that's what you'll spend your time exploring.

Dr. Bruce Tuckman developed a model that describes how teams develop and mature. According to Tuckman, all newly formed teams go through five stages of development:

Tuckman originally devised this theory using the first four stages of development. Based on later research by Tuckman and Mary Ann Jensen, a fifth stage of development was added called adjourning. You may see this model referred to as the Tuckman-Jensen model in other literature, and you might want to tuck that piece of information away for the exam. You've probably seen this model elsewhere, but since these stages might show up on the exam, you'll want to memorize them. Take a brief look at each of them:

According to Tuckman, leaders adapt their leadership styles as the teams develop maturity and progress through the development stages. For example, early in the forming stage, leaders take on a direct style of leadership. As the team progresses, their leaders will employ a coaching, participating, and then delegating style of leadership to match the level of development the team has achieved.

You'll now take a closer look at focusing your team members throughout these stages of development, along with some of the characteristics of effective teams.

Ground rules are expectations set by the project manager and project team that describe acceptable team behavior. For example, one of my pet peeves is team members who interrupt each other. In this case, one of the ground rules is one person speaks at a time during a meeting. Another ground rule might be reporting potential issues as soon as the team member becomes aware of them. Outlining ground rules like this helps the team understand expectations regarding acceptable behavior and increases productivity.

Team members are often in the same physical location—for example, the same office building or meeting space. This tool and technique is called co-location. Co-location enables teams to function more effectively than if they're spread out among different localities. Many times on large projects, the project manager will make provisions in the project budget to bring the team together at the same location. (It's difficult, but not impossible, to manage project team members who are not physically located together.) One way to achieve co-location might be to set aside a common meeting room, sometimes called a war room, for team members who are located in different buildings or across town to meet and exchange information.

Multiple locations can also be a big time waster for you as the project manager and for your team members. If some team members are located in one part of town and another set of team members are located across town, you'll find yourself in the car (or the bus) driving back and forth to make face-to-face contact and get status updates. Conducting team meetings also becomes a hassle as one set of team members or the other must drive to another location (or both to a central location) to have a meeting.

Our busy, conflicting schedules and differences in location don't always allow for face-to-face communication, so email is the next best thing. I'm a huge email fan—it's one of my favorite forms of communication. Email can keep the information flowing when you aren't able to meet in person, and it can even help take the heat out of conflicts that might escalate if you were meeting one on one. However, email cannot reveal tone of voice, facial expressions, or body language. Sometimes those nonverbal cues are more important than what's being said. If you don't know your team members or stakeholders well, I recommend meeting with them personally whenever you can. Once you've established good relationships with them, you should be able to balance the use of email and personal interactions and know when it's time to call a face-to-face meeting. In reality, it's often difficult to get your team together physically. A good solution in lieu of having people relocate is videoconferencing or conference calling. Team members scattered across the country all have access to the telephone, and it's relatively easy to find a time everyone can meet over the phone. Videoconferencing is the best option if it's available because it allows intonation and nonverbal behaviors to be part of the communication process.

I have quite a bit of ground to cover with recognition and rewards. As I said earlier, you could see several exam questions regarding team building, so dig out all your favorite memorization techniques and put them to use.

Team building starts with project planning and doesn't stop until the project is completed. It involves employing techniques to improve your team's performance and in keeping team members motivated. Motivation helps people work more efficiently and produce better results. If clear expectations, clear procedures, and the right motivational tools are used, project teams will excel.

Motivation can be extrinsic or intrinsic. Extrinsic motivators are material rewards and might include bonuses, the use of a company car, stock options, gift certificates, training opportunities, extra time off, and so on.

Intrinsic motivators are specific to the individual. Some people are just naturally driven to achieve—it's part of their nature. (I suspect this is a motivator for you since you're reading this book.) Cultural and religious influences are forms of intrinsic motivators as well. Reward and recognition—a tool and technique of the Develop Project Team process—are examples of extrinsic motivators. We'll look at them next.

Recognition and rewards are an important part of team motivation. They are formal ways of recognizing and promoting desirable behavior and are most effective when carried out by the management team and the project manager. You should develop and document the criteria for rewards, especially monetary awards. Although rewards and recognition help build a team, they can also kill morale if you don't have an established method or criteria for handing them out. Track who is receiving awards throughout the project. For example, if you have consistent overachievers on the team, you could kill morale by consistently rewarding the same one or two people repeatedly. It could also be perceived that you're playing favorites. If team members believe the rewards are win-lose (also known as zero-sum) and that only certain team members will be rewarded, you might end up hurting morale more than helping. If you find yourself in this position, consider team awards. This is a win-win because all team members are recognized for their contributions. Recognition and rewards should be proportional to the achievement. In other words, appropriately link the reward to the performance. For example, a project manager who has responsibility for the project budget and the procurement process and keeps the costs substantially under budget without sacrificing the results of the project should be rewarded for this achievement. However, if these responsibilities are assigned to a functional manager in the organization, it wouldn't be appropriate to reward a project manager who was not the one responsible for keeping the costs in line.

Team members should be rewarded for going above and beyond the call of duty. Perhaps they put in a significant amount of overtime to meet a project goal or spent nights round-the-clock babysitting ill-performing equipment. These types of behaviors should be rewarded and formally recognized by the project manager and the management team. On the other hand, if the ill-performing equipment was a direct result of mistakes made or if it happened because of poor planning, rewards would not be appropriate, obviously.

Consider individual preferences and cultural differences when using rewards and recognitions. Some people don't like to be recognized in front of a group; others thrive on it. Some people appreciate an honest thank-you with minimal fanfare, and others just won't accept individual rewards as their culture doesn't allow it. Keep this in mind when devising your reward system.

There are many theories on motivation. As a project manager, it's important to understand them so that you can tailor your recognition and rewards programs to take into account the reasons people do what they do. You might encounter questions on these theories on the exam, so we'll discuss their primary points in the following sections.

Observation and conversation is another one of those tools and techniques that is self-evident. To assess team member performance, you have to observe it. I hope you've also learned how important communication is to the success of the project. This includes communicating with your team members. I know project managers who are reticent to engage their teams in conversation unless it's official project business. I've even known project managers who instructed their administrative assistant to give a specific direction to another team member. It's difficult to understand a team member's attitude or viewpoint toward the project if you're communicating through someone else. Establish an open door policy with your team members and live up to it. The benefits are so great that it's worth a few minutes a day of chitchat to establish that feeling of trust and camaraderie. If your team perceives you as open, honest, and willing to listen, you'll be the first person they come to when issues arise.

Project performance appraisals are typically annual or semiannual affairs where managers let their employees know what they think of their performance over the past year and rate them accordingly. These are usually manager-to-employee exchanges but can incorporate a 360-degree review, which takes in feedback from just about everyone the team member interacts with, including stakeholders, customers, project manager, peers, subordinates, and the delivery person if they have a significant amount of project interaction. I'm not a fan of 360-degree reviews because it makes most nonmanager types uncomfortable. "I don't want to rate my peer" is a typical response. I also find 360-degree reviews are biased. At best you'll get a response like this: "Oh, Ken is great, just great. No problems—a good guy." Or you'll get exactly the opposite if the person you're speaking with doesn't like the team member you're reviewing. Performance appraisal should be a bit more constructive than this. Nonetheless, understand the 360-degree concept for the exam.

No matter what type of appraisal is conducted, project managers should contribute to the performance appraisals of all project team members. You should be aware of potential loyalty issues when you're working in a matrix organizational structure. The team member in this structure reports to both you (as the project manager) and a functional manager. If the project manager does not have an equal say, or at least some say about the employee's performance, it will cause the team member to be loyal to the functional manager and show little loyalty to the project or project manager. Managing these dual reporting relationships is often a critical success factor for the project, and it is the project manager's responsibility to assure that these relationships are managed effectively.

Performance appraisal time is also a good time to explore training needs, to clarify roles and responsibilities, to set goals for the future, and so on.

I said earlier in this chapter that if you have more than one person working on your project, you have a team. Here's another fact: if you have more than one person working on your project, you'll have conflict.

Everyone has desires, needs, and goals. Conflict comes into the picture when the desires, needs, or goals of one party are incompatible with the desires, needs, or goals of another party (or parties). Conflict, simply put, is the incompatibility of goals, which often leads to one party resisting or blocking the other party from attaining their goals. Wait—this doesn't sound like a party!

There are six ways of resolving conflict that might show up on the exam:

During the Manage Project Team process it's important to note that, as in any situation, you'll want to deal with conflict as soon as it arises. According to the PMBOK® Guide, when you have successfully resolved conflict, it will result in increased productivity and better, more positive working relationships.

Most conflicts come about in the Manage Project Team process as a result of schedule issues, availability of resources (usually the lack of availability), or personal work habits. When project team members are having a conflict, address them first in private with the person who has the issue. Work in a direct and collaborative manner, but be prepared to escalate the issue into a more formalized procedure (potentially even disciplinary action) if needed.

If conflicts exist between the team members, encourage resolution between them without intervention on your part. The best conflict resolution will come about when they can work out the issues between them. When that isn't possible, you'll have to step in and help resolve the matter.

Remember that solid ground rules and established policies and procedures will help mitigate conflict before it arises.

The issue log is a place to document the issues that keep the project team from meeting project goals. These can range from differences of opinion to newly surfaced responsibilities that need to be assigned to a project team member. Each issue should be recorded in the log along with the person responsible for resolving it. You should also note the date the resolution is needed.

We talked about interpersonal skills in the Develop Project Team process, but you should know for the exam that the PMBOK® Guide points out three types of interpersonal skills used most often in this process. They are leadership, influencing, and effective decision making. We've already covered leadership and influencing. Effective decision making concerns making decisions in a timely manner and making decisions that reflect and support the goals of the project. Effective decisions should bring about a good result for the project, the stakeholders, and the team members. They also help you take advantage of opportunities and minimize negative risks. As project managers, and good leaders, we have a responsibility to put the good of project and the organization over our own needs, so use sound judgment when making decisions.