ProjectExecution

THE COMPTIA IT PROJECT+ EXAM TOPICS COVERED IN THIS CHAPTER INCLUDE

• 2.5: Identify methods for resolving disagreements among team members when evaluating the suitability of deliverables at each point in their evolution.
• 3.1: Identify the tasks that should be accomplished on a weekly basis in the course of tracking an up and running project.
• 3.6: Given a scenario in which a vendor requests a 2-week delay in delivering its product, explain the appropriate action.
• 3.7: Given a scenario in which there is a disagreement between a vendor and your project team, identify methods for resolving the problem.
• 3.8: Identify issues to consider when trying to rebuild active project support from a wavering executive (e.g., the need to identify the source of doubts , interpersonal communications skills that might be employed, the need to act without creating negative impact, the need to identify and utilize various allies and influences, etc.). Given a scenario involving a wavering executive, choose an appropriate course of action.
• 3.11: Demonstrate the ability to track the financial performance of a project, given the financial management baseline and data on the actual performance of the project.
• 3.22: Identify effective strategies for providing timely performance feedback to team members.
• 3.23: Demonstrate an understanding of how to effectively manage disgruntled team members so that team performance is not adversely affected.
• 3.24: Demonstrate an understanding of how to recognize individual team member performance issues and to identify effective strategies for corrective action.
• 3.25: Given an initial high-level scope, budget, and resource allocation, demonstrate understanding of the need to investigate the aspects of the project that could be modified to improve outcomes (i.e., find out what is negotiable, prepare to negotiate).
• 3.26: Given a project scenario, demonstrate the ability to resolve a resource availability (staffing) issue requiring escalation to the project sponsor and senior-level stakeholders.
• 3.27: Given a project scenario during the implementation phases, demonstrate the understanding of the need to organize and effectively run meetings.
• 3.28: Given a project team meeting scenario in which a decision must be made with imperfect information, demonstrate the knowledge of problem-solving techniques to help the team through a decision making process.
• 3.29: Given a project team meeting scenario, demonstrate the awareness of the need to provide direction and clarify work instructions to team members.
• 3.30: Given a project team meeting scenario under a situation whereby the project is behind plan, demonstrate the awareness of the need to identify, clarify, develop, and implement key strategies.
• 3.31: Given a project scenario in which intra-team communication is inadequate, demonstrate the ability to improve communication to an appropriate level.
• 3.39: Recognize potential organizational and political barriers inhibiting an effective working relationship between the IT organization and the client/business organization.
• 3.40: Demonstrate an understanding of methods to develop and maintain an effective working relationship during projects between the IT organization and the client/ business organization.

Now is where the real work begins ”project execution. You are in charge of managing the project to a successful completion.

Successful project execution involves development of your project team, performing according to the project plan, information distribution, and contract administration.

You will have relationships with a number of individuals and groups during the life of the project. All of your people-management skills will come into play as you negotiate with the sponsor, team members, vendors , functional managers, clients , users, and other internal organizations such as finance or legal.

If you talk to veteran project managers about what makes them successful, many will list the project team. Understanding how to build this temporary group into a team, making sure appropriate training is provided, and implementing a meaningful rewards and recognition plan are all challenges you face in developing a cohesive team.

Other stakeholder relationships are also critical to the success of a project. Building a good working relationship between IT and the client organization can be a challenge. You also need to continually monitor your relationship with the project sponsor. To verify that the project work is performed according to plan, you are collecting data, reviewing performance against the baselines that were set in planning, and documenting and reporting progress.

Contract administration is an important component of managing vendors. The project manager reviews vendor progress, resolves disputes between the project team and vendors, works with the vendor on the impact of delayed deliverables, and approves invoices for payment.

We will start by looking at the various aspects of developing and managing a project team.

Team Development

Managing a project team differs from managing a functional work group. Project teams are temporary, and getting everyone to work together on a common goal can be a challenge, especially if your team members are specialists in a given discipline without a lot of broad business background. As project manager, you must mold this group into an efficient team that can work together to deliver the project as defined on time, within budget, and with quality. Not an easy undertaking, especially if you factor in a combination of full- and part-time team members , technical and nontechnical people, and in some cases a team dispersed over a large geographic area.

As project manager you need to be concerned with building and managing a cohesive team, providing appropriate training to team members, and using an effective rewards and recognition system.

Building and Managing a Cohesive Team

Before we begin discussing techniques to manage a temporary team, it is helpful to look at the progressive stages that a team goes through. You may be familiar with this concept from a general management perspective, but it applies to project teams as well.

Forming The forming stage is where the team members go through the process of getting oriented to the project s objectives, the project manager, and each other.

Storming Storming is the struggle for control, power, and influence as the team members work to establish themselves in the project structure.

Norming As the project evolves and the team settles in to a routine, the norming stage brings cooperation and establishment of beneficial work practices.

Performing The last team stage is the performing stage that brings interdependence , cohesiveness, and high productivity.

It takes both time and good management to bring a team through these stages. A good starting point is a project kickoff.

Project Kickoff

If you think about past experiences you have had being involved in a new project, you can probably break down most of your concerns into these questions:

• Why am I here?
• Who are you and what do you expect of me?
• What are we doing?
• How will we do our work?

As project manager, you need to take the steps necessary to ensure that team members have answers to those questions. A good project kickoff meeting will do a lot to answer those questions and establish a foundation for your team members.

A project kickoff meeting is the best way to formally introduce team members and other stakeholders and convey the same message to everyone at the same time. Typically, you may not know all of your team members, and you may not even have had the opportunity to interview them for the positions they will fill. Not the best way to start a relationship, but in some organizations team members are provided by the functional manager with little input from the project manager.

The tone that you set at the project kickoff meeting can make or break your relationship with the team. An ideal project kickoff session is a combination of serious business and fun. Your goal is to get the team aligned around the project goals and to get the team members comfortable with each other. This is a great opportunity to begin the forming stage.

You may know project managers who dislike the idea of a project kickoff and consider it a waste of time and money, but experience proves that the results of a good kickoff meeting make it well worth the effort. There are a lot of different ways to structure a kickoff meeting. Here are some of the key components you may choose to include.

Welcome

It is a good idea to start the meeting by welcoming the team members and letting them know that you are looking forward to working with them. The welcome also gives you an opportunity to set the stage for the rest of the day. Take a few minutes to run through what participants can expect out of the meeting and what activities they will be involved in.

Introductions

A typical introduction format may include the person s functional area, brief background, and role in the project. The project manager should start the process to set an example of the appropriate length and detail. Put some thought into the information you want team members to share so that the time invested is worthwhile.

Guest Speakers

Invite the sponsor, the client, and any other executive stakeholders; it is important that the team members know them and hear first-hand their goals for the project. These people may not be able to stay for the whole session, but do your best to get them to at least make an appearance and say a few words to the team.

You may need to do some coaching here, so spend time prior to the session to communicate with the executive stakeholders regarding the message they will deliver. The client is often the best candidate to provide the business justification for the project and the link to the corporate strategy. If your client or sponsor is a dynamic speaker, you might want to schedule them for a little more time to get the troops excited about the project they are working on.

Project Overview

Covering the project scope statement is key to starting the team on the right track. A summary of the key deliverables from each of the project phases, as well as the high-level schedule and budget will help team members get the big picture and understand how they fit. The kickoff meeting is an excellent opportunity to get everyone on the same page, especially as project team members typically do not come on board at the same time. At the time you start project execution, you will probably have a combination of people who have been involved with the project since initiation and those who are relatively new to the project.

Project Manager Expectations

This is your chance to communicate how you will be managing the project and your expectations for how the team will function. Many of the team members may not know you or be familiar your management style.

This is not the place for a detailed review of a progress report template or a team meeting agenda, but is it important for the team to know whether you plan weekly team meetings, what you expect in terms of progress reports, and how they will be asked to provide input into project progress reports .

Question and Answer

One of the most important items of the kickoff session is the time you allocate for team members to ask questions. Ideally, this is a panel session so that questions can be directed to the project manager, the sponsor, the client, or other executive stakeholders, but it is just as important even if the questions are only directed to the project manager.

Real World Scenario ”Kickoff for Remote Team Members

For a project kickoff to work, it needs to include all the team members. But what do you do if part of your team is located in a different city or state?

Remote team members often feel left out, especially if the majority of the team, including the project manager, sponsor, and client is located at corporate headquarters where all of the action is.

Getting approval to bring in remote team members is a battle worth fighting, because it is so important to making everyone feel like a part of the team. If you exclude your remote team members, you are sending them a message that they are less important before the project work is even underway.

With more companies looking closely at travel related expenses, bringing in remote team members may require prior approval of the sponsor, even if the budget will cover the expense. When making your case with the project sponsor, make sure you explain the importance of this meeting and the benefits to the project. Your sponsor will be much more receptive to the idea if he or she knows what will be covered and can see that this is far more than people getting together for a free lunch .

But what if you cannot get this to happen? It doesn t mean that there is not still a way to include them.

I was on a project where we had a large group of team members in a remote state. The company was really cutting back on travel, and even though the sponsor wanted to bring everyone to the same city, he could not get approval from the CEO. But we were able to get approval for the next best thing: the sponsor, the client, and the project manager traveled to the remote city and held a separate kick-off for those people. It took extra time to do this, but this project was critical to the corporate strategy. We were able to use that day to build a sold foundation for dealing with the challenges of remote management.

Not only is this an opportunity to clarify any misunderstanding regarding the project, it is also a chance to do rumor control. Having everyone hear the same message from the same person at the same time can remove a lot of confusion.

Social Interaction

Another goal of a project kickoff meeting is to get the team members to start feeling comfortable with each other, so it is a good idea to plan activities that require interaction. A proven method to move a team forward is the ability to get team members to self disclose. When they get to this point they will tell you what is going right and wrong on your project. Social interaction will help get them to self disclosure.

This can be a tricky area to maneuver, as people have different interests and different tolerances for games and icebreakers. You can plan a scavenger hunt, a trivia game, or even a crossword puzzle based on key elements in the project plan. The point is to break the team into smaller groups and get people to start interacting with each other. This will also give you some insight into the various personalities and styles that you will be dealing with.

Monitoring Team Performance

As the leader of the project team, your role involves teaching the members of the team to take responsibility for task and relationship processes and outcomes . Through monitoring performance you should assure responsibility and accountability. To build and maintain the trust of your project team members you need to demonstrate competence, respect, honesty, integrity, and openness. You must also demonstrate that you are willing to act if there are performance problems.

Performance Feedback

Managing team member performance can be a complex undertaking. A successful project manager needs to let the people do the work they were assigned without approving every action taken. This may be a new concept for team members who are used to being micromanaged by a functional manager, or even to you as project managers. Team member performance will be enhanced if activities can be modified to fit individual needs. As long as the end result is the same and there is no impact on scope, schedule, budget, or quality, team members should be given freedom and choices in how to complete their tasks .

Although you should not micromanage team members, they do need feedback on how they are doing ”good, bad, or otherwise . Most team members perform well in some areas and need improvement in others. Even if your organization structure does not require project managers to conduct formal written appraisals , you need to take care not to get so caught up in managing the project issues that you neglect to provide performance feedback. The following are important areas of focus as you prepare to discuss performance with a team member:

• Specify performance expectations.
• Identify inadequate performance behaviors.
• Reward superior performance.
• Reprimand inadequate performance.
• Provide specific consequences for choices made.

Performance feedback should be given in a timely fashion. It is of little value to attempt corrective action on something that happened several weeks ago. The team member may not even remember the specifics of the performance in question.

Rewards for superior performance can be given publicly , but a discussion of inadequate performance should always be done privately. Berating a team member in front of others is totally inappropriate and will likely make the person angry and defensive.

We are going to take a closer look at team management scenarios that involve conflict. Before we get into a discussion of the more challenging aspects of project team management, let s take a quick look at some styles that people use to deal with conflict:

Accommodating A person using an accommodating style attempts to meet the other person s needs at the expense of their own concerns.

Avoiding Avoiding finds the person dropping out of the conflict situation; they choose to not bring the issue to the other person s attention and to not deal with the problem.

Competing A person who uses a competing style uses any actions available to satisfy his or her own needs, often at the other person s expense.

Compromising A compromising style attempts to resolve the conflict by partially satisfying the needs of both parties by having each give up something in order to reach an agreement.

Collaborating In the collaborating style, a person works with the other party to explore alternate solutions and agree on a solution that will satisfy each of their needs and concerns.

These conflict management styles can help you understand behavior you observe and must deal with when you need to correct team member behavior. Two situations that require special treatment are dealing with team member disputes and handling disgruntled team members, which we ll discuss next.

Team Member Disputes

Given the diverse backgrounds and varying areas of expertise you find in project team members, it should come as no surprise that team members will have disagreements . Sometimes people just need to have a conversation and work though the issues, but other times disputes require the intervention of the project manager.

You may be tempted to make a snap judgment based on what you see at any given point in time, but this may only exacerbate the situation. You need to get the facts and understand what is behind the dispute. If an experienced team member is trying to tell a more junior member how to do his or her work, this advice may have been unsolicited . If the junior member is completing activities according to plan, it does not matter if the approach is different than what the senior member uses. In a case like this, you may need to take the senior member aside and discuss the situation. You want to handle the situation carefully , as you do not want to alienate anyone , but you need to explain that each person is accountable for his or her own work. If the senior member has extra time, perhaps there is another person who wants and needs some guidance.

Team members may also disagree over the suitability of deliverables. Suggestions to make a deliverable better or more effective may be a sign of scope creep that can lead the project off track. You should establish and enforce a policy that any comments regarding the adequacy of a deliverable need to be stated in the context of the project scope and the project requirements. If a deliverable fails to meet the documented requirements, you have a valid issue, but if a person is just looking to add bells and whistles, you need to keep the project on track. These types of disputes can be eliminated if you define acceptance criteria for your deliverables in the planning phase. The project manager needs to act quickly to resolve these disagreements so that project time is not wasted .

Disgruntled Team Member

Few situations can poison team morale more quickly than a disgruntled team member. This can happen at any time during the project, and can involve anyone on the team.

The behavior of a discontented team member can take a variety of forms. A person may become argumentative in meetings or continually make side comments putting down the project. Even worse , this unhappy camper may spend time moving from cubicle to cubicle sharing these negative feelings about the project with other team members. When team members constantly hear statements that the project is stupid, doomed to fail, or on the cutting block, overall team productivity will be impacted.

As the project manager, you need to spend some private time with this employee to determine the cause of the dissatisfaction. It may be that the unhappy team member doesn t fully understand the project scope and how his or her contribution will lead to the project success, or at the other extreme, this could be an assignment the person did not want.

It is best to start by listening: stick to the facts and ask the person to clarify the negative comments. If the team member is repeating incorrect information, set the record straight. If he is frustrated about some aspect of the project and feels no one is listening, find out what the issue is and explain that going around bad-mouthing the project is not the way issues get resolved. If the person truly does not want to be a part of the project team or does not want to do her assigned tasks, work quickly with the functional manager or your sponsor to get this person replaced .

Developing your team and improving overall performance can also be accomplished through training.

Training

Depending on the nature of your project, another element of team development may be scheduling training for some or all of the project team members. In some companies, one of the perks associated with being assigned to do project work is the opportunity to expand a skill set or get information on new products or processes.

If you are developing a system using a new, evolving technology, the project may include sending the technical team to a class on the technology. A project manager for a new product team may provide training for the whole team on the product itself, including hands-on use of a prototype or assigning project team members to be a pilot group of users.

One of the more common types of training provided to project teams is project management training. Project management training can include a session developed by the project manager, formal training provided by an outside company, or training from an internal PMO on the standard methodologies, tools, and templates all project members are expected to use.

Team development and proper performance feedback are important, but another aspect of team development is rewards and recognition.

Rewards and Recognition

Some project managers (or maybe more frequently project sponsors) may tell you that project team members are just doing their job and should not be getting anything extra. But excellent performance is rewarded in most organizations, and project work should not be an exception.

Project teams work hard and often overcome numerous challenges to deliver a project. If your company has a functional organization structure, the project work may not receive the appropriate recognition from the functional managers. It is your job as project manager to recognize the job your team does and implement a reward system.

Real World Scenario ”Project Management 101

One of the more successful experiences we have had with project management training involved a project team in an organization that was just starting to implement the project management discipline. Based on the chaos that had been created on earlier attempts at running projects, it was clear that the team members needed a common understanding on what project management was all about.

We contracted with a professional project management training company to teach a beginner class in project management concepts. All project team members were required to attend this session.

All of the exercises associated with the class were based on the actual project the team members were assigned to. Not only did the team members gain knowledge of the project management discipline, they were able to contribute to the project while in class.

Although this took some time and money, it was well worth the effort. All team members used common definitions of terms, and it was much easier to talk about meeting requirements, the project baseline, scope creep, and other fundamental project management concepts. The success of this project resulted in the organization setting goals around various levels of project management training for the entire group.

 

A reward system is typically associated with money allocated in the project budget for the project manager to use for on-the-spot awards for outstanding performance or end-of-project merit awards. Depending on your organization s policies, rewards may be limited to merchandise or gift certificates.

If you are lucky enough to have money for a reward system, either as a direct budget line or as part of a managerial reserve, you must decide what constitutes performance worthy of receiving a reward. Anytime that you do provide an award, you should always state clearly what the person did that made you decide to make the award.

An alternate means of implementing a reward system is to reward the team as a whole, rather than individual performance. In this scenario, you are combining a reward system with ongoing team building. You can take the team to a sporting or cultural event after the completion of a particularly difficult phase. Team dinners or other celebrations to mark project completion are another popular choice. Team rewards are appropriate in situations where you have a cohesive, high-performing team with all members making a substantial contribution to the project success.

Not all project mangers have the resources to reward team members either individually or collectively, but that does not mean that superior performance should go unrecognized. One of the easiest things you can do is simply telling people that you are aware of what they have accomplished and that you appreciate their efforts.

A team member of the month concept is a frequently used recognition technique. You can create a certificate or have a trophy that is passed on to the employee who has made the most significant contribution to the project for the previous month. With a program like this, you can solicit nominees from the team.

A letter of recognition to an employee s manager, with copies to the appropriate organizational executives and the project sponsor can be a very powerful means of communicating your appreciation for an outstanding performance.

The key to rewards and recognition is to establish a program to acknowledge the efforts of your project team members, whether it involves money, prizes, letters of commendation, or a simple thank you. Whatever form your rewards and recognition program takes, you must make sure that it is applied consistently to all project team members. Inconsistent application of rewards is often construed as favoritism.

Your team is not the only group you interface with during project execution; you have ongoing relationships with all the stakeholders.

Other Stakeholder Relationships

In addition to developing the project team members , you must maintain an ongoing relationship with the sponsor, client, and other project stakeholders. Although you may not interact with these people as frequently, they are critical to project success. Lets take a closer look at a few scenarios involving other stakeholders: building a productive IT/client relationship, dealing with a disengaged project sponsor, and resolving staffing issues with functional managers.

Relationship Management with the Client

In many organizations, the IT group and its internal business clients are known for having adversarial relationships. This is not healthy for either the people involved or the project itself. If you are the IT project manager, you need to recognize and address any barriers that may be inhibiting an effective working relationship with your client.

A client may not recognize the complex application development required to produce what he or she believes is a simple product feature, but on the other hand, the IT project manager may not fully understand the business impact of this feature.

Clients have a wide range of technical background. The relationship will be much more effective if you establish the clients knowledge of the technology being used. Clients can be frustrated by technical jargon, but they can also be offended if you talk down to them. Asking a few background questions regarding the clients familiarity with the technology in question can guide your discussion to the proper level.

Some basic principles go a long way in maintaining an effective working relationship with a client:

Frequent Communication Regular updates to the client organization are a must. The us against them mentality and the political battles for control will do nothing to improve the relationship. In addition to distributing written status reports to provide the client with a roadmap of project progress, call the client to see if he or she has any questions or would like to meet with you to clarify any aspects of the project. Being proactive sends the message that you will listen to client concerns.

Team Building Client involvement in a project kickoff meeting or any team event or celebration demonstrates that you view them as a critical part of the team and goes a long way to taking down some of those political fences that may have been built between the organizations.

Gaining Consensus Just as you worked with the client to gain consensus during requirements definition in the initiation phase, you need to include the client in the problem solving and issues management. You may resolve purely technical issues, but if they impact the scope or the deliverables, client input is important. A client will not feel ownership in a solution if it was developed in an IT vacuum .

Timely Decision Making A sense of urgency is important. If you need additional information or approval to make a decision, explain the process to the client and provide a commitment as to when your decision will be made.

Managing Expectations Over the course of the project, clients may forget the specifics of requirements, assumptions, constraints, and other information obtained during the planning process. A continued review of the project progress compared to the project plan will reinforce what the client can expect from the project.

Managing by Facts Disputes between IT and client organizations can escalate quickly based on mere rumors or speculation. If you hear that a client representative is unhappy with a project deliverable, get the facts and find out what the real issues are. If the deliverable does not meet the documented requirements, admit there is a problem and work to correct the situation. If a client is asking for something that is out of scope, review the scope statement and requirements to reset client expectations and if needed, walk them though the scope change process.

Managing a Wavering Sponsor

All sorts of kinks can occur to make life challenging for a project manager. As if you dont have enough to do assembling a cohesive team and building a good relationship with your client, you may reach a time during the project where you are not getting the support you expect from your sponsor. Wavering support can manifest itself in a number of ways. Maybe your review meetings are being canceled , or the sponsor suddenly does not have time to talk about project issues. The sponsor may even indicate that you should be able to handle situations that are clearly part of the sponsor role.

A sponsor may back away from a project for a variety of reasons:

• A change in top management may be driving a new corporate strategy.
• Rumors circulating that the project is in trouble may be driving the sponsor to take a hands-off approach.
• The sponsor may have an increased workload.
• The sponsor may be working through personal problems that are taking focus off the project.

Regardless of why the sponsors commitment to the project has changed, you need to confront the problem and seek a resolution.

Identify the source of the doubts . You need to meet with the sponsor and raise the issue. I noticed that your interest and support of this project is not the same level as it was during project planning. Have all of your concerns organized and list the reasons behind your statement. Ask the sponsor if they have issues with how the project is being managed and what you can do to help correct the situation. The sponsor has a choice of two responses in this situationthey can acknowledge that something has changed or simply deny that theres a problem. Listen not only to what is being said, but what is not said, and watch the sponsors body language.

Communicate your concerns with care. No matter how you approach the sponsor, this will not be a comfortable situation, but the last thing you want to do is alienate them. Stick to the facts, choose your words carefully , and allow the sponsor time to think through a response. If you come across as criticizing, judging , or accusing, you will more than likely put the sponsor on the defensive.

Utilize allies and influences. If your sponsor denies a wavering support of the project during your meeting, but continues to be unavailable and unsupportive, what can you do next ? You may want to involve others by asking executive allies in your department or other stakeholders who may have influence on the sponsor if they know what the issue is. You can be on very slippery ground here, so make sure you choose these people carefully.

If the situation persists with no resolution, you need to determine whether you should seek a new sponsor or recommend canceling the project. If the sponsor has taken on additional job duties , perhaps sponsorship needs to be transitioned. If the waning sponsor support is instead a signal that the project is no longer viable , letting it die slowly is of no benefit to anyone .

Relationships with Functional Managers

You may have thought that dealing with functional managers are limited to the initial request for project resources. This is rarely the case, as resources that were committed during project planning may suddenly be unavailable. Overall team performance can also be impacted if a planned resource is not brought onto the team as promised or if a functional manager attempts to pull a resource off the project before the assigned tasks are complete.

In this situation, you need to work with the functional manager to try to come up with a resolution that is satisfactory to all parties. You need to know the reason a resource is being pulled from your project and how the functional manager proposes to handle the replacement. If there will be a transition period and the substitute resource can perform the tasks with no impact to the project end result, you may just want to accept the change and work at integrating the new person into the team.

Proposed staffing changes sometimes occur at very critical stages in the project. If you get a call from a functional manager in the middle of the development phase telling you the lead programmer has been assigned to a special project, the negative impact to your project could be great. You want to attempt to resolve the issue by explaining how critical the lead programmers position is and the impact of making a change at this juncture.

If the functional manager is not willing to negotiate and if the ramp-up time for a new person will delay the project, you need to escalate this situation to your project sponsor for resolution. Be prepared to review with the sponsor the consequences to the project if you lose the lead programmer and explain the actions you have taken to attempt a resolution with the functional manager. The project sponsor can work at the executive level to confirm the priority of the project and the need to maintain resource commitments.

Project execution is the phase that delivers the work results, so in addition to developing your project team and managing stakeholder relationships, you are tracking the overall project performance.

Perform According to Plan

Once the project work is underway, the project manager needs to track numerous items to make sure the project is on schedule, on budget, and delivering a quality product that meets the requirement of the scope statement. For a typical up and running project, these tasks should be completed on a weekly basis. To effectively coordinate all of this work, the project manager must collect data about the project work and compare project execution against the baselines that were established during project planning.

Collect Data

You need a lot of information to be able to accurately track project performance. You need an organized, consistent means of collecting data. Tools that can be used to assist in data collection include progress reports, an issues log, and budget reports .

Progress Reports

A lot of the data you need to collect on the project work relates to the progress of tasks on the project schedule. One of the first things that you need to establish is the format and timing of regular progress reports from your team members . With everything you need to keep track of, it is important that there is a consistency to these reports, so that you can scan them quickly to get a big picture of how the team is doing. These reports should list the tasks each team member is working on, the current progress of each task, and the work remaining.

Table 8.1: A Sample Progress Report

Task	hours worked	hours left	percent complete	notes

On most projects, you need to receive weekly progress reports from your team members to stay on top of project progress. The team should agree on when the reports are due and how they will be provided (email, paper copy, etc.).

You may find some team members who are lax in submitting progress reports. You need to stress with the team how critical it is to the success of the project that these reports be timely and accurate. You need to monitor progress reports and follow up with team members who do not submit reports. If the tardiness becomes habitual, schedule a meeting with the offender to discuss this as a performance concern.

If your project software is set up for updates to be made centrally by one person, the progress report may also be used as input to update schedule progress.

Issues

Every project will have issues that need to be resolved. In order to assure that issues are communicated and resolved, you need to develop and maintain an issues log. Various formats can be used to track project issues, and your PMO or other projects may provide an existing template.

Identify these key elements:

• What the issue is.
• How the issue affects the project.
• Who is accountable for resolving the issue.
• Current status of resolving the issue.

An issues log is often tracked using a spreadsheet, which allows for easy sorting by date or status. Figure 8.1 displays a sample log for tracking project issues.

Figure 8.1: Issues Tracking Log

An issues log can become very lengthy, especially on large, complex projects. You may opt to display only the open issues or leave issues on the log for a predetermined time period after the issue is closed.

The issues log is typically reviewed and updated during the project team meeting, which we will discuss later in this chapter.

Note

You can find a version of the Issues Tracking Log on this book s companion CD, for your own use in project management.

Spending

The other important piece of data for the project manager to collect is the amount of money spent on the project. Tracking financial data is greatly simplified if your project has a dedicated financial analyst who can access the necessary reports from the finance systems. If that is not the case, you will need to take the necessary steps to receive the official budget reports for your project.

Depending on how current your financial management systems data are, you may need to do some manual tracking as well. Many project managers review and/or approve both the weekly time reporting of the project team members and any materials or equipment charged to the project. The last thing you want to see is a $100,000 surprise that hits the official budget tracking 2 months after the fact.

The data that you obtain from the progress reports, issues log, and spending reports are all key inputs in your quest to complete the project work according to the baselines created during project planning.

Progress Against Baselines

Now you will start to see the importance of the schedule and budget baselines that you established as part of scope planning and cost planning. These documents are used as a roadmap during project execution to determine whether the project work is being completed as planned. The schedule baseline, cost baseline, and scope statement are continually compared with the actual progress of the project. If you find deviations from any of these baselines, you must determine if any action is required.

The question to continually answer is where are you in your project as of this date? From the schedule perspective, did you plan to be further along, are you ahead of schedule, or are you right on track? Do the project budget reports indicate more or less spending than you had planned based on schedule progress?

In this chapter we will discuss what items you should focus on. Analyzing deviations from any of the project baselines and controlling risk and change will be discussed in detail in Chapter 9, Project Control.

Schedule Baseline

Project team members may input task progress on a server-based project management software system or a central project administrator may complete the updates working off of the progress reports. Either way, the project manager needs to compare actual progress to the baseline on a regular basis. You may have been alerted to a potential problem by notes in the progress report or discussion from the team meeting, but you cannot assume that all existing or potential deviations from the baseline will be bought to your attention. Individual team members tend to focus on their assigned tasks rather than the impact to downstream tasks. A task that will last two extra days may not seem like a big deal, but if three other people cannot start their work until this task is done, there could be major impacts. A project manager will not have time to analyze every task that has deviated from the baseline, so particular attention must be paid to critical path tasks or tasks with multiple dependent tasks.

Evaluating Costs

Official corporate project budget reports contain budgeted dollars per task or per budget category and the corresponding dollars that were actually spent. Project budget reports compare what was planned with what has really happened from the perspective of dollars and indicate where the project has overspent or under spent. The budget report provides a basis for variance analysis.

Time reporting or invoices submitted for approval may provide an early warning that your budget report will not match plan. You want to pay particular attention to time reports that consistently exceed the number of hours a team member is dedicated to the project. Any given task estimate may not be accurate, but if a team member is working more hours than planned on a weekly basis, your salary budget is going to be overspent.

Scope Statement

Another document that tells you if you are on track is the scope statement. As milestones are reached for the completion of major deliverables, make sure these deliverables match what was documented in the scope statement.

You should be on the lookout for red flags that may indicate potential scope creep. If tasks from various team members on a particular deliverable are consistently taking longer than planned, don t wait for the deliverable to be completed to start asking questions. If scope has changed without an approved change request, you need to resolve this issue quickly.

Deliverable Sign-Off

As your project progresses, more and more tasks on the project schedule should be shown as complete. You need to be alert to any tasks that are reported as almost complete for more than one progress reporting period. This may be a sign that the team member is behind or has found the task more complex than planned. In other cases, there may be uncertainty about closing the task. A few key questions can help determine the real issue and push for task completion.

The completion of a series of tasks leads to completion of a deliverable. Pay special attention to the completion of deliverable, as they may be associated with a milestone that requires sponsor or stakeholder review or sign off. If there are any issues with a deliverable, fixes may need to be made before additional work begins, so delaying sign off of deliverables can create a chain of rework .

The acceptance of all of the project work and the associated deliverables by the stakeholders is referred to as scope verification . The data you gather is compiled and communicated to the project stakeholders.

Information Distribution

It should be obvious at this point that the project manager reviews a lot of data. Much of this data needs to be summarized and shared with others. Information distribution is the process of providing project stakeholders with the information they need when they need it. When you distribute information about the project, you are implementing your communications plan. Information can be distributed using a variety of methods , including project meetings, status reports , and formal project reviews.

Project Team Meetings

The project team meeting is the best tool for ongoing communication between the project team members , yet it is often the source of the greatest frustration and the most complaints. A successful project meeting needs to be well organized and tightly focused. A well-run meeting can be instrumental in moving a project to completion.

Leading a Meeting

Project team meetings can be the best or the worst aspect of being on a project team, depending on how the meetings are structured. You may have heard your fellow employees complain about sitting in endless meetings that accomplish nothing. A productive team meeting is an ongoing opportunity for the project manager to provide direction to the team and clarify any questions regarding completion of the project work. Successful team meetings do not just happen; they require a good deal of effort in both planning and execution. You can take a number of steps to establish a foundation for productive team meetings:

Designate a consistent day and time for the team meeting. You should obtain input from team members and determine the best time to schedule the meeting.

Stress the importance of consistent attendance. Team meetings will not be effective if key members are missing. Establishing a policy where team members will provide information in advance or send a representative if unable to attend adds emphasis to the importance of being at the meeting.

Prepare and distribute a written agenda. Team members need to know what topics to be prepared to discuss, and the time that will be allocated to each topic. Even if the team meeting topics are consistent week to week, an agenda reinforces both the structure and the need to be ready for discussion.

Start and end the meeting on time. If you schedule your team meeting for one hour , that is how long it should last. Team members need to be told, perhaps multiple times, that you will start and end meetings on time. Some people are habitually late, but delaying the start of a meeting only rewards bad behavior and punishes those who are on time. If someone arrives late and starts questioning topics that were already covered, advise them to get with you or another team member after the meeting.

Follow the agenda and keep the meeting on track. It is very frustrating to be a participant in a meeting that seems to wander from topic to topic. You developed the agenda for a reason. You can ask team members for input into the agenda prior to the meeting. If a particular subject is taking more time than planned, decide whether to remove some items from the agenda or schedule a separate meeting to allocate more time to a given issue.

Solicit participation from all team members. Some people just love to talk. You need to be aware if a few team members are monopolizing the meeting. Direct questions to individual team members to level the playing field.

Distribute meeting minutes. People will inevitably remember different outcomes to items discussed during the team meeting unless the outcome of the meeting is captured in writing. Meeting minutes should summarize the key points of the meeting, including the key elements discussed, recommendations, and action items for different team members.

Meeting Outcomes

A project meeting can be much more than just a time to update status of assigned tasks . An effective meeting can result in improved team member interaction, issues resolution, and problem solving.

Team Member Interaction The team meeting is an excellent venue to observe the interaction between team members. If there are too many surprises or people with linked tasks are clueless as to their impact on one another, you may have a group that is operating in silo mode. Team members are not expected to know every detail on every task, but there should be ongoing interaction between team members. If necessary, you may need to schedule time to review key dependencies between major deliverables.

If you perceive that intra-team communication is weak and could impact task dependencies on your critical path , you may need to take extra steps to ensure that people in charge of downstream tasks are getting the information they need regarding the progress and deliverables of any predecessor tasks.

Poor intra-team communication can be a major issue on cross-functional projects. A client representative who is writing customer manuals may need to start documentation while development and testing are still in progress, and it is essential that the writer get ongoing updates on items such as screen shots and feature functionality. If your technical team members are reluctant to interface with the client team members, the project end date could be jeopardized if the documentation is started late or requires multiple revisions due to poor team member communication. As project manager, it is your responsibility to establish the importance of effective communication between all team members.

Issues Log Updates A review of the issues log should be part of every project team meeting. This does not require a huge amount of time, as each issue is assigned to a team member for resolution at the time it is added to the issues log. You should request the responsible party(s) to review the status of a current, open issue where a promised action is in progress or should be completed. The work to resolve the issue takes place outside of the team meeting.

Problem Solving Project teams are constantly called on to make decisions with imperfect information. This can be a frustrating and scary proposition, and it is your job to lead the team members through the problem-solving process. People tend to rush into a solution, so make sure that the problem is clearly defined and there is consensus. Dedicating a short amount of time to brainstorming may uncover a solution that would not have been thought of without encouraging team input.

An example of a common problem that may be appropriate for project team discussion is delays to the project. A consistent approach to the resolving delays will make the team more effective:

• Determine the root cause of the delay.
• Identify the responsible team member.
• Develop a corrective action plan.
• Implement the corrective action.
• Track results.

Team members are not the only stakeholders who need to be informed of project progress. Status reports are another method to share project information.

Status Reports

The project sponsor, the client, and other stakeholders do not need the same level of detail regarding project progress as project team members, but they do need to be kept apprised of project progress. This is why most project communications plans include the regular distribution of a status report.

The status report can be provided via access to a shared folder, email, or even voicemail. The specific distribution method should be identified in the communications plan. The key to success is a consistent report format that paints a clear picture of the current state of the project. A typical status report will include:

• Summary of project progress compared to schedule and cost baseline.
• Completion of any major deliverables or milestones.
• Status of outstanding issues.

A more formal method for communicating information on the project is a project review.

Project Reviews

A project review is a formal presentation by the project manager or project team members to the sponsor, the client, and other executive stakeholders. While some sort of status report is produced on almost all projects, a project review is optional in nature and will vary greatly in structure and content between organizations.

Organizations that regularly conduct formal project reviews may have a set monthly or quarterly schedule. We have seen project reviews done at the executive level that cover numerous projects and span several days, with all involved project managers presenting to an executive team.

The information in a project review will be based on your organizational or sponsor needs. A review presented for just the sponsor is easier to prepare for, as you can set the agenda based on what is important to the sponsor. If the audience includes the client or other executives, you may want to solicit input from the attendees regarding expectations for the review session.

The presentation should include an agenda with time limits for each topic. Your time with these busy executives will be limited, so you will need to stay focused and to the point. Topics to consider for a review agenda include:

• Major achievements for current review period
• Budget summary
• Major issues
• Risks and mitigation or contingency plans
• Planned achievements for next reporting period

Project reviews usually include both handouts and slides, so make sure your presentation room has all of the equipment you will need. An example of a project review handout is shown in Figure 8.2. Either the project manager or project team members may be involved in the presentation. The key to success is to make sure that each presenter is clear on the information they will provide and the time allocated to the session. If project team members will be making portions of the presentation, it may be worthwhile to do a practice session, at least for the first review.

Figure 8.2: Project Review Template

Note

You ll find a sample of the Project Review Template, which you can use for your own project reviews, on the CD-ROM that accompanies this book.

When you report a project s progress to an executive body (a function you ll undoubtedly be actively and routinely involved in during your project career), you ll want to go prepared with a document that presents the important things these folks will want to know in a summary fashion. Generally speaking, unless there s some technical issue that they need to know about in order to help you make an operational decision affecting the project, you ll want to avoid anything remotely technical regarding the project. Instead, you should focus on things that are relevant to decision makers :

• Tasks you re currently working on.
• Issues that you ve encountered .
• Estimated percentage complete.
• Estimates of how closely you re following your project budget and timelines .

Some project reports also include a set of characters that help identify whether a manager should be concerned about a project element. For example, you might use an open circle to denote that everything s moving along just fine, a gray triangle to note that there s some concern for a given element and a black diamond to illustrate a major problem. The idea is to give executives something to scan that allows them to easily drill into hot spots and get more information about a key issue as Figure 8.3 illustrates.

Figure 8.3: The Executive Project Summary Worksheet

When you re reporting to a formal project review body such as a project review board (PRB), you ll take more time to elucidate detailed components of the project ”but you ll still want to avoid technical discussions. For the majority of people, you ll lose them more quickly by having a technical discussion than you ll help them. The key here is to find a way to say what you need to say without resorting to technical acronyms or expecting that people will understand what even simple terms like server and router mean.

Note

You ll find The Executive Project Summary Worksheet template on this book s companion CD-ROM, for use in your own project management.

Vendor Contract Administration

Many projects cannot go forward without the products or services from third-party sources, or vendors. If you have contracted with vendors for work on your project, you will have a role in contract administration . This is the process of tracking and verifying that the vendor meets the terms of the agreement.

Although some of the contract administration may be done through a separate procurement department, your relationship with the vendor is key to a successful project. You will need to receive progress reports from the vendor, resolve disputes between the vendor and your team members , and deal with vendor delays.

Progress Reporting

Progress reports from vendors are just as important as progress reports from your team members. Your vendor deliverables are part of your project schedule and may have dependencies with other tasks assigned to your team members.

The specifics of progress reporting from vendors should be documented in your statement of work (SOW). Communications with vendors tends to be more formal due to the nature of working from a contract, which has legal implications.

Even though the progress reporting requirements are detailed in your SOW, you need to make sure you are getting the data you need in a usable format. A written weekly report should provide a clear status on the vendor deliverables, including percent of work completed, confirmation of target delivery date, and any issues or risks that might impact delivery.

Some project managers also have a monthly meeting with the vendor to review progress and discuss any issues. The need for regular meetings fluctuates based on the complexity of the vendor deliverable and the length of time a vendor is involved on the project.

Managing Vendor Disagreements

Project team members and vendors may not always see eye to eye on how to approach a particular deliverable. This puts you in a difficult situation. The vendor has been hired because of expertise or experience in producing something you need, but the vendor deliverable has to integrate with the rest of your project. So if a team member tells you the vendor is going down the wrong path , what should you do?

You need to sit down with the team member to hear what they are really saying. You also need to hear the vendor side. The source of the friction could be any number of elements, which we will discuss in this section.

Misunderstanding on the Part of Team Members

It could be that the source of the disagreement is merely a misunderstanding. Perhaps your team members have always worked with one product; this new product behaves differently, but they re expecting the same outcome as with the old.

Misunderstanding on the Part of Vendors

Alternatively, perhaps the vendor has misunderstood what your actual intent is for the product it s going to supply. The vendor, after understanding the nature of the misunderstanding, might respond, Oh, well, Widget A won t do that, but Widget B will. Sure, you should ve gone through this discovery process at design time, but this kind of thing has a way of slipping through the cracks.

Paradigm Shift

It could be that the vendor s product is just fine for what you re trying to do, but team members have to go through a paradigm shift in order to effectively use the new product, and they simply have not yet made that leap. Think about the shift that old-school mainframe programmers might have had to make when object-oriented (OO) programming methodologies came about. In this example, you may have had several mainframe programmers who were used to thinking in top-down programming format and might ve had a hard time grappling with object-oriented code (where you put an object on a screen, then write the underlying code for that object). A paradigm shift was required. Unfortunately, especially in OO, that shift is a hard one to make, especially if you re coming from the old school of programming.

The Ego Factor

Sadly, IT is an industry that s fraught with large egos. It could very well be that one of your team members has forgotten more about the product than the vendor will ever know, and he s prepared to tell the vendor so. Managing this kind of thing may require that you use tough love tactics where you tell the team member to do things the way the vendor says they need to be done. Alternatively (and most often), you may have to replace this talented team member, because he will derail the project, by doing things his own way, more than he will help to get his tasks done. In the final analysis, it is, after all, all about tasks and their timely and successful completion that makes a project successful.

The 800- Pound - Gorilla Vendor

Some vendors have a my way or the highway attitude when it comes to their product. Some products, especially enterprise-class software, are so cumbersome that companies are forced to wrap their way of doing business around the product, rather than the product wrapping itself around the way the company does business. Additionally, some of these 800-pound-gorilla companies think nothing of calling you up, telling you that the latest revision is out, that your current version will become unsupported in a few months, and asking how soon you can be converted ”all at a substantial cost to you.

If it s apparent that this phenomenon may come into effect, project managers can benefit from heavily weighing this 800-pound-gorilla incident to see if this is somewhere they think the project should go. In other words, if you marry into a software or hardware product that s a phenomenon all unto itself, then you re stuck with that phenomenon . When you re on board the Queen Elizabeth II , you go where the captain wants you to go (unless you buy the boat).

This is a place to weigh the disadvantages of integrated systems against the advantages. Suppose that you re using an enterprise-class relational database management system (RDBMS), one that comes with its own software development environment (SDE) or perhaps even with some canned apps that may loosely fit some of the stated deliverables of your project. Should you invest your company s development environment completely in this one large offering, or should you investigate to see whether other SDEs and tool sets may do a better job ”if for no other reason than simply to avoid having all of your eggs in a single vendor s basket ? Normally, with integrated systems, you re worried about two different platforms (whether hardware or software) talking to one another. But don t forget to ask, Should I sell my soul to this company?

A very germane (and often overlooked) element of project planning is to analyze the proposed platform to make sure that you re not steering your passengers onto a ship that they will have to be aboard for many years to come. If you were not far-sighted enough to spot this in the initial planning phases, then the best you can do at execution time is to make sure that the future caretakers of the system are aware that there will be ongoing maintenance issues they ll need to routinely deal with.

Tip

Project managers who unknowingly lead companies into an unwanted marriage with an 800-pound gorilla may experience what a project management expert friend of mine lovingly calls a career-limiting move (CLM).

Platform Wars

This phenomenon is especially prevalent in the network operating system (NOS), SDE, and RDBMS camps. One person likes Unix; another won t do anything that s not Microsoft-oriented. One group loves Oracle; another thinks that Sybase is the best. Developers are really funny about stuff like this ”one talented developer will insist on using the Java language and a particular Java SDE, while another says that the best code comes from C++ and has the SDE to prove it.

Proactively, as the project manager, it s up to you to create early on a standards-based environment that utilizes the best-of-breed technologies for the given task at hand ”often regardless of one individual s personal preferences. This is a really difficult call to make. You can reduce the difficulty by going to websites that specialize in IT research, sites that can give you vendor-independent advice about choosing a product. Gartner Inc. ( www.gartner.com) and IDC Corp. ( www.idc.com) are two such companies involved in this kind of research. You can do a lot of your research for free without having to purchase a subscription to their extended services, but for heavy detail and Q&A, you ll need a subscription membership.

At project execution time, if you find that platform wars exist you have to manage them by keeping people focused on the goal of the project, and try to steer folks away from the platform religious wars.

Tip

Check first. Your company may have a subscription to one of the research groups, and you can set up conference calls with SMEs in the subject you re interested in researching .

Vendors may experience delays in completing deliverables, and you need to be prepared to handle these according to the provisions of the contract.

Vendor Delays

Some project managers mistakenly believe that just because you have hired an outside vendor to complete a portion of the project work, nothing will go wrong, and you can just sit back and wait for the deliverable to appear. This is not how it works in real life.

You may be getting ready to distribute your latest status report, when you get a call from your vendor telling you that their next deliverable will be two weeks late. What should you do now?

Meet with the vendor. You need to sit down with the vendor to get more specific information about the delay. This discussion can help you determine if there are alternative approaches to the issue that can shorten the delay, or if a portion of the deliverable can be completed as planned. You may not be able to resolve the vendor issue, but you need to make sure you have all the facts and understand what action the vendor is taking.

Involve your procurement or legal department. A vendor is doing project work based on a legal contract. If there is going to be a delay in the vendor deliverable, you need to understand the potential contractual impacts. There may be penalties or fines associated with any vendor delay, or you could even have cause to terminate the contract. You should not agree to any change in the vendor deliverable or schedule without the involvement of your procurement or legal representative.

Review impact to the overall project plan. Any time there is a delay in a deliverable, you need to assess the impact this delay will have to the project scope, the schedule baseline, the cost baseline, and resource requirements. A delay in a major vendor deliverable may create new risks that need to be added to the risk management plan.

Notify the sponsor. You need to get with your sponsor as soon as you have all the facts regarding the delay and have assessed the impact to the project plan. If the impact of the vendor delay is severe, the sponsor may choose to escalate the problem with a vendor executive.

Communicate to stakeholders. Information needs to be provided to the project team, the client, and any other impacted stakeholders as quickly as possible. Vendor delays can drive all sorts of rumors about the viability of the project, so you want to make sure that everyone has the facts.

Another difference in dealing with vendors versus employee team members is the oversight of the payments vendors receive.

Vendor Payment Process

The contract with the vendor should spell out how and when the vendor is paid. There may be a regular payment schedule or payment may be tied to completion and acceptance of specific deliverables. Although your accounting department will probably handle the actual payment of vendor invoices, the project manager may be the initial recipient of the invoice.

If you are responsible for approving payment of an invoice, make sure you understand what you are being billed for and do adequate research to confirm the payment is warranted.

If a vendor is being reimbursed based on a phased schedule of deliverables, you need to confirm both receipt and acceptance of the deliverable. Review the process and quality checks that were established to approve vendor deliverables before you approve payment.

Reimbursement of vendor personnel expenses should include receipts and an accounting of the purpose of the expense. If you are not certain of what is required, ask your accounting representative to walk you through the process.

If you are not clear on how the payment process is stated in the contract, request clarification from your procurement team. They are the contract experts, and can help you through the legal terms. If there is a difference of opinion regarding the money owed to a vendor, you will need to involve a procurement expert to work through the resolution of the dispute.

Dealing with Vendors

In this section, we ll discuss some of the methods you can use when working with third-party sources.

Communicate Effectively with Vendors

As the project progresses, you will be maintaining high-quality ongoing communications with the vendors who are engaged in your project. High-quality means that you have set up routine meetings in which you and the vendor have an opportunity to bring out issues and discuss solutions within a framework that allows for positive communications and problem-solving. If you have not arrived at consensus on what the work would be when you first started out designing your project and you did not thoroughly review the SOW, project progress meetings will clearly reveal the shortcomings as you may hit problem areas where the vendor won t go any further because they are not within the boundaries of the co-agreed-upon SOW.

In other words, you will find that most vendors are eager to work with you toward solving problems on the project within which they have proper purview. But vendors understandably get a little nervous when you re asking them to help you with something that was not clearly delineated at project creation time. This seems to be the area in which most project manager and vendor relations get into trouble.

Make Sure the Vendor Really Knows Your Needs

Be sure to carefully scrutinize the SOW. It s entirely possible that a vendor will leave out an element you specifically asked for (and that they agreed to) just because they overlooked putting it into the SOW. The SOW is a document that specifies exactly what the vendor is going to do, in return for a given amount of money. If you initially thought you had everything you needed stipulated in the SOW, but at project execution you see that there are missing elements, you re going to wind up doing some things you may have wanted the vendor to do. Or you re going to have to pay the vendor extra money to handle the extra work. This is why it s critical to understand exactly what the SOW is saying.

Real World Scenario ”Vendor Pushing Back Due to Incompletely Defined Requirements

Theresa is a project manager working on a large software-development project. The new software will replace an old legacy mainframe system.

When Theresa began the project she and the business analysts performed interviews with various business subject matter experts (i.e., people who understood the business process flows thoroughly) to determine how the new system should behave. However, due to the large geographic dispersion of the system, it was difficult to pin down certain individuals who were deemed key to the project. They were busy, or it was expensive to fly someone out to do the business interviews ”it just seemed to Theresa like it was difficult to get good quality information out of some of the individuals affiliated with the initial requirements-gathering and design efforts of the project. Hence, the information, while certainly not describable as dicey, wasn t exactly complete either. Even though Theresa submitted this as an issue, project stakeholders felt that there was sufficient information to go ahead and begin the project.

Now well into the project, some of the business subject matter experts have come back to look at what has been done so far and don t like what they see! They have asked for changes ”substantial ones ”that impact the scope of the project. Because they are deemed critical business experts, the sponsor thinks that their ideas have credibility and that Theresa need to take them into consideration. In fact, she wonders why Theresa didn t initially hear these people out.

The vendor, a good one of high reputation, is working under a contract and has worked solidly with Theresa throughout the life of the project so far. The vendor has been there for all design and construction meetings and has complied fully with every letter of what Theresa had asked them to do. The vendor is now into other development phases and does not want to go back to re-visit previous work, especially because what they have done meets the criteria Theresa asked for and the system works perfectly . The vendor is now saying that they will have to charge extra money to put in the additions being asked for.

The sponsor is insisting that they did not live up to their end of the bargain. Theresa has documents detailing the deliverables that have been signed off by all parties as well as successful phase completion documentation that was signed off.

Theresa feels as though she is in a no-win situation. She cannot ask the vendor to go back and put in the additions and corrections without being able to pay them for the additional work. The sponsor thinks that Theresa should ve gotten the straight story at design time and isn t willing to pay extra for the vendor to make the changes. She says that the vendor should assume responsibility for the changes because it s the right thing to do.

Unfortunately, there are no good solutions to this problem. You have a sponsor who is pushing the onus onto you to solve the problem and yet the vendor is pushing back on you to keep moving forward.

The recommended approach in this case would be for Theresa to set up a meeting with herself, the vendor, and the sponsor in which she lays the cards out on the table. If there are areas where she made mistakes, now is the time for her to own those mistakes so she can move forward. The primary point here is to focus on truth-telling and getting the whole story across to all sides so that the vendor can clearly hear the sponsor say that they need to help make things right and the sponsor can hear them say that they re not going to do so. This takes Theresa out of the middle of the equation and gets both sides talking. Theresa is going to be held responsible for whatever outcome is derived from such a meeting. However, it is crucial that all sides meet together to hash out and work on this one specific problem until there is a satisfactory solution for each side.

 

Additionally, you ll find that a vendor agreement isn t a set it and forget it type of arrangement. Even reputable vendors with your best interests in mind lose their way from time to time and forget to include an element you talked about. If a vendor says that they ll have a part to you on Tuesday at 9:00 A.M. by Federal Express, then you d better have your eyes open looking for that part. If you see the FedEx truck come and go, you should be on the phone asking the vendor where the part is.

Do Your Homework before Vendor Discussions

You should ignore the our product can do that statements when you re in your initial discovery meetings with the salesperson and SE. Their system might very well do that, but you should do some investigative work outside the heat of the sales presentation moment before signing on the dotted line. Suppose, for example, that you want a website software package that will calculate sales tax for anywhere in the state of California. The SE might blurt out our product can do that, knowing full well that it really can t, but if you re willing to write some code that digs into the vendor s API then it can. Unfortunately, in a sales presentation, the products usually look really, really good, so you may be inclined to accept the our product can do that at face value and not investigate further.

Unfortunately, usually it s at execution time that you find out exactly what the software will and will not do. If you ve hung everything on the initial sales meeting phrase, our product can do that, and you find out it really can t, the project execution phase is not the time to find out about it! A little pre-project research into the capabilities of the products being considered will go a long way toward eliminating this issue.

Practice Smart Negotiations

Finally, things get tacitly agreed to when it s you and the salesperson and he thinks he s closing the deal. As a general rule of thumb, the larger the sale, the more likely you re going to get a bone or two thrown your way at deal-arranging (but not necessarily closing) time. Be sure to write down those promises for later when you go into the room and close that deal. You ll actually say, OK, before we go forward, I just want to validate what you communicated to me the other day ”that you d do blah blah, and also blah blah. You ll want these commitments in writing because after the deal s closed and the salesperson s onto other accounts, it may difficult getting him back to the table to talk about those add-ons he committed to.

Tacit agreements especially play themselves out during project execution. Suppose, for example, that you and the vendor were going over a component of the project and he said, I ll do some checking and get back to you. I think I can get the company to provide you that part at no charge. You leave it at that for the moment. Now well into project execution, you need that part! Because the agreement wasn t committed to paper and agreed to by both parties, you may have a difficult time getting the vendor to do that checking and find that free part.

Tip

Be sure to understand a vendor s maintenance and support policies as well. Lots of vendors offer Bronze, Silver, and Gold support plans. What is it you re signing up for and what do you get with that? What will be the annual maintenance costs (if any) that you ll incur as a result of purchasing this vendor s software or hardware? Some vendors make their real money through support and maintenance, not necessarily the software or hardware they re selling. So be sure you understand what their complete offering is going to cost you from this time forward.

Case Study: Chaptal Wineries ”Email and Intranet

You re several weeks into the effort to bring your international winery acquisitions into the fold. France s and Australia s server and telco installations are complete. Weekly reports to Kim Cox look similar to the graphic below.

You ve approved several invoices for payment ”forwarding them back to the Chaptal finance office to cut the checks. You ve approved payments for the Australian and French telecommunications installations (after validating that the installations were up and completely operational). The internetworking gear contractors for both of these regions have been paid and you ve noted the tasks complete on the project plan.

Now you re concerned about the T1 dropping in Chile. You re beginning to wonder if maybe the internetworking contractor you retained has something misconfigured and doesn t realize it. You make a call to Metor and ask him to call the vendor to have someone else other than the contractor you ve been dealing with come out to verify the configuration. Metor s afraid that the contractor may want to charge you more money for validating the configuration, but you fax Metor the SOW and point out to him that the contractor has committed to making sure that connectivity is up 99.8 percent of the time until you ve released the vendor and okayed payment. Because the circuit has been up only about 50 percent of the time, you re clearly within your rights to force the vendor to send someone else out to validate the configuration.

Metor agrees to call the vendor and get a different technician out to check the configuration. Sure enough, the Open Shortest Path First (OSPF) settings in the router are not correct for the circuit. When the new technician makes an adjustment, the circuit comes up and stays up fulltime thereafter. At next project status meeting, you note that the task is 100 percent complete.

Summary

Project execution is an exciting time as you finally get to see results of the hard work from the Initiating and Planning phases. But just because you are executing against a well-defined plan does not mean that you can sit back and just watch the project phases complete. The project manager is very busy during this phase.

Project execution is where the people assigned to do the project work need to work as a team. Successful team development includes ongoing team building and management, appropriate team member training, and a meaningful rewards and recognition system.

Although you will spend the most time with the project team members , there are other critical relationships you must establish and maintain with the client and your sponsor.

An effective working relationship between the IT department and the business client requires the use of numerous management skills, especially consensus building and frequent communication.

The role of the project sponsor is to act as a mentor for the project manager and remove roadblocks that are beyond the authority of the project manager. If you see signs that the sponsor no longer supports the project, you need to determine the cause of these doubts and work to a satisfactory resolution, even if the ideal solution means canceling the project.

Staffing issues may arise with the functional managers who provide your human resources. You need to attempt to resolve these issues with the functional manager, but if a compromise cannot be reached and the project is in jeopardy, escalation to the sponsor may be required.

As the work on the project progresses, you need to collect data through team member progress reports , timesheets, spending requests , and the documentation of issues. The data you collect can be used as input into analysis of how the project performance compares to the schedule and cost baseline and the scope statement.

There is a great deal of project information, and distributing that information can be accomplished in a variety of means. Project meetings provide a regular point for team members to share progress, solve problems, and update issues. Status reports keep all stakeholders informed on a regular basis, while a formal project review can provide an opportunity to interact face to face with the sponsor, the client, and other executive stakeholders.

Contract administration is an additional process for those project managers dealing with vendors . Although a procurement specialist may handle much of the contract work, the project manager must work with the vendor to obtain progress reports and to resolve disagreements between the vendor and team members. The impact of vendor delays on the project plan must be assessed. The project manager also needs to be involved in the approval of payment for vendor invoices.

Exam Essentials

Identify the ongoing weekly activities a project manager performs as part of executing according to the baseline. A project manager reviews progress reports, spending reports , issues tracking logs, the project scope, the schedule baseline, the budget baseline, and the status and approval of major deliverables.

Understand the impact of a delay of a vendor deliverable to the project plan. Any changes to the project deliverables can impact the scope, the critical path end date, the budget, and the required resources. A vendor deliverable delay may add new risks to the project or create the need to establish new baselines for the schedule or budget.

Name the key components of an effective team meeting. A successful meeting has a stated purpose, a defined time limit, and a documented agenda distributed in advance. The project manager is accountable for setting a consistent day/time for the meeting, keeping the meeting on track, obtaining input from all appropriate team members , and sticking to the agenda.

Understand the various means to recognize or reward team members. Team member contributions can be recognized with monetary rewards or prizes, mention in a formal project review, a letter to executive management, or a team celebration .

Define a strategy for dealing with wavering project support from the sponsor. The strategy for dealing with wavering project support includes identifying the reason for the lack of support, determining the most effective means of communicating with the sponsor, enlisting the support of the allies , and potentially requesting a new sponsor or recommending cancellation of the project.

Recognize the components of an effective working relationship between the IT organization and the client organization. An effective working relationship requires team building, regular written and verbal communications based on the facts, joint issues management, timely decisions, and ongoing management of client expectations.

Understand that vendor relationships are critical to the process of getting your project finished. Be aware that often you come into a relationship with a vendor with one set of expectations, the vendor with quite a different set. Managing those expectations by coming to consensus and making sure that youre on top of what the vendor is going to deliver is critical to project success.

Key Terms

Before you take the exam, be certain you are familiar with the following terms:

contract administration	project review
information distribution	scope verification
progress reports

Review Questions

1. There are numerous reasons why a particular project task may not be progressing as planned. Of the following reasons for a task delay, which one is most likely to require a change to the project team composition?
   1. Team member is spending time on another assignment.
   2. Team member is ill or takes a vacation day.
   3. Team member does not have the skill set to complete the work.
   4. Team member does not understand what is expected.
2. Which of the following project manager responsibilities is not part of the project execution phase?
   1. Setting the schedule baseline
   2. Identifying, assigning, and tracking resolution of project issues
   3. Obtaining sign-off as required on major deliverables
   4. Reporting project status
3. Which of the following are components of vendor contract administration? Select the best answer.
   1. Request for proposal, statement of work, and vendor solicitation
   2. Progress reporting, vendor disputes, and vendor delays
   3. Bidders conferences, vendor selection criteria, and progress reporting
   4. Statement of work, progress reporting, and payment process
4. Which of the following is the most effective method to provide a weekly status report to your client and other executive stakeholders?
   1. The more information that you send to stakeholders, the better. Distribute detailed minutes from your weekly project team meeting to all the stakeholders.
   2. Stakeholders outside of the project team members are not concerned with the project status unless things are going wrong. You can contact them if there is an issue requiring their input.
   3. Stakeholders should be able to analyze the updates from your project management software package. A copy of the current project schedule should be sent to all the stakeholders.
   4. A status report template provides a consistency for stakeholders to quickly identify the information they need. You should include a summary of project progress, the completion of any major deliverables or milestones, and a status of any outstanding issues.
5. During a review of unit test results, two of your programmers disagree on the correctness of the deliverable from one of the units of code. How should you resolve this dispute?
   1. The programmers should take the issue to the test manager.
   2. You should ask clarifying questions to determine the specific issue surrounding the deliverable. Ask the team member disputing the deliverable to reference a specific requirement that is not being met.
   3. A separate meeting should be scheduled to conduct a detailed analysis of the code in question. The programming team and the test team should both be involved in this session.
   4. The project team members should decide who is correct. This item can be added to the agenda for the next regularly scheduled team meeting.
6. When comparing the actual schedule progress to the schedule baseline, which of the following should receive the most attention?
   1. The tasks on the critical path are the most important, as any delay in these tasks can delay the project end date.
   2. The tasks assigned to the technical team members are the most important. The marketing plan and the end- user training do not impact the development and delivery of your system.
   3. The tasks assigned to inexperienced resources are the most likely to get off track and should be closely monitored .
   4. All tasks are equally important, and you should request a detailed explanation and recovery plan for any task that is not 100 percent on track.
7. A functional manager has put you on notice that your lead tester is being pulled from the project to do a special assignment. You have asked around, but no one knows of another qualified person currently available. The timing could not be worse , as your integration testing is scheduled to begin next week. You have requested a meeting with the functional manager to discuss alternatives, but all of your voicemails and emails have been ignored. When you stopped by the functional managers office, the only response you received was a lecture on the organizational reporting structure. Which of the following would be the best next step?
   1. The functional manager has ultimate say over the resources, so the best you can do is request a replacement resource and move forward. You dont want to raise an alarm prematurely, so dont make an issue out of this unless the integration testing runs into problems.
   2. You should immediately write a letter to the functional managers department head demanding an explanation for this deliberate attempt to sabotage your project.
   3. Based on the steps you have taken and the responses you have received, resolution of this issue requires escalation. You should meet with your project sponsor to request assistance in resolving this impasse.
   4. You have done everything you can, but you need to make sure all of your attempts are thoroughly documented. When the project falls apart, you can easily put the blame on the functional manager.
8. Just prior to the weekly project team meeting you compare the latest schedule update with the schedule baseline. Based on current progress, the development phase will be completed a month later than planned. What is the best action to take at this point?
   1. You should call an emergency meeting with the sponsor and the client to advise them that the project end date has been delayed by 4 weeks.
   2. The schedule issue should be covered during the team meeting, but this is not the time to solve the problem. You should isolate the critical path tasks that are off track and identify the team member(s) accountable for these tasks. You can work separately with the responsible team member(s) to determine the root cause of the delay and develop a strategy for corrective action.
   3. This issue needs to be resolved immediately by the project team. You should discard the planned team meeting agenda and advise the team how disappointed you are that they have caused a schedule delay. You may need to extend the length of the meeting.
   4. The potential schedule delay should not be communicated to anyone ; it will just cause the team to panic. You should email the people responsible for the delayed task(s) and advise them you are confident they will find a way to meet the target end date.
9. Your system engineer has started making negative comments during your weekly team meeting. He has had a heated argument with the marketing manager and you have heard from various team members that he has become difficult to work with. What is the best course of action for you to take?
   1. You should write a memo to the system engineers functional manager and request a replacement as soon as possible.
   2. The system engineer is critical to the project, so you should give him some slack .
   3. You should confront the system engineer openly at the next team meeting. Let him know that his performance is unacceptable and that he will be replaced if there is not an immediate change.
   4. You should schedule an individual meeting with the system engineer to determine if he has issues with the project that need to be resolved. Get his perspective on how the project is progressing and how he feels about his role.
10. You are preparing for a formal monthly project review session with your sponsor and client. Which of the following is the best approach for making this an effective review?
    1. The project manager creates an agenda giving each team member an equal amount of time to provide task status.
    2. The preparation for a formal review takes valuable time that the project manager could put to better use. Assign one of the team members the task of putting together a summary of the meeting minutes from project team meetings for the last month.
    3. The project manager, with input from the project team, prepares a formal presentation that covers the following: previous months key achievements, the current month planned deliverables, actual spending compared to budget estimate, overall schedule status, and any issues that could delay the project. The team determines in advance which team member will present each aspect.
    4. The project manager creates a presentation to put the project in the best possible light. Any delays, overruns, or other issues should be downplayed, to avoid making the sponsor look bad in front of the client.
11. Choose the project component thats most important to individual team effectiveness.
    1. Project cost
    2. Project size
    3. Project schedule
    4. Project value
    5. Project budget
12. Youre the project manager for a large IT project thats going to take a year and require input from a vast array of IT technicians. Recently youve discovered that some fighting is going on between the person whos developing and implementing your security policies and a senior developer. Youve found both to be highly credible, valuable players on your team. Whats the best way to handle this situation?
    1. Call both to a meeting. Specify exactly what youre seeing happening between them. Ask for a plan from both to work out the differences. Stress the importance each of them contributes to the project.
    2. Ask the HR office to put together a meeting between you and the two fighting team members. Ask HR to work out the differences between the team members. Stress the importance each of them contributes to the project.
    3. Call both to a meeting with you and the project sponsor. Specify to the sponsor exactly what youre seeing happening between the two. Allow the sponsor to lead the group toward an amicable solution. Stress the importance each of them contributes to the project.
    4. Replace the security specialist with someone else.
13. Youre the project manager for a large IT project thats going to take a year and require input from a vast array of IT technicians. Recently youve discovered that some fighting is going on between the person whos developing and implementing your security policies and a senior developer. The senior developer argues that the security specialist has no idea what shes doing and that shes not following good quality security guidelines. He produces some documentation to back up his claims. In researching the work that each is doing, along with his documentation, you find that the claims of the senior developer, while exaggerated, are not without merit. Whats the best way to handle this situation?
    1. Call both to a meeting. Specify exactly what youre seeing happening between them. Ask for a plan from both to work out the differences. Stress the importance each of them contributes to the project.
    2. Call the security specialist into a meeting. Tell her that youve been looking at her work and that youd like some input as to why she made the decisions she made. Without including the fact that the developer brought it up, ask her why the decisions that she made didnt follow the decisions the developer might have made, were he to be in her place. If you find the rationale to be reasonable and proper, tell the senior developer that youre behind the actions of the security specialist. If not, ask her to begin meeting the standard security guidelines and illustrate with your documentation what youre talking about. Ask if there are ways that you can assist her with her work. Stress the importance of her contributions to the project.
    3. Call both to a meeting with you and the project sponsor. Specify to the sponsor exactly what youre seeing happening between the two. Illustrate the developers point with the documentation he has provided. Put the security specialist on a 30-day action plan to improve her processes. Stress the importance each of them contributes to the project.
    4. Replace the security specialist with someone else.
14. Youve recently acquired $20,000 worth of hardware from a server vendor for an activity in your project with a promise from the vendor that he will supply some additional software modules that are required at no cost. Where are these additional software modules noted?
    1. Project charter
    2. Project budget
    3. SOW
    4. WBS
15. Youre well into the project execution/controlling phases of your project. After a heres where were at overview of the current work, business experts have come back to you to complain that the product they see being built right now does not address their needs. Yet you have in hand a design document that was signed off by key stakeholders and the sponsor and denotes exactly what the vendor has delivered so far. The vendor says that to go back and make the changes recommended by the business experts will require additional funding, as the vendor sees himself on time, on budget, and within the constraints of the SOW. What do you do?
    1. After performing an investigation, present your findings to the sponsor.
    2. After performing an investigation, authorize the expenditure of the additional funds to meet the business experts needs.
    3. Do nothingthe business experts agreed to the initial design and the vendor is working according to the agreed-to SOW.
    4. Instruct the vendor that he must implement the changes at no cost.
16. Of these communication situations, which would be best suited to team-building efforts? (Select all that apply.)
    1. Schedule changes
    2. Resource loss
    3. Personality clashes
    4. Budget changes
    5. Low morale
    6. Organizational changes
    7. Project phase completion
17. Of these communication situations, which would you immediately communicate to the project sponsor? (Select all that apply.)
    1. Schedule changes
    2. Resource loss
    3. Personality clashes
    4. Budget changes
    5. Low morale
    6. Organizational changes
    7. Project phase completion
18. You are a project manager for an IT project thats in the executing phases. A vendor has notified you that a server you require for a given task in the project, a task thats on the critical path, will not be able to ship for 2 weeks. What is your course of action?
    1. Set up a meeting with stakeholders. Explain the situation; ask for an extension to the project deadline.
    2. Meet with the vendor; see if you can shorten the delay. Set up a meeting with stakeholders. Explain the situation; ask for an extension to the project deadline.
    3. Meet with the vendor; see if you can shorten the delay. Set up a meeting with stakeholders. Explain the situation; ask for an extension to the project deadline. Get extension approved through project sponsor.
    4. Meet with the vendor; see if you can shorten the delay. Set up a meeting with stakeholders. Explain the situation; ask for an extension to the project deadline. Get extension approved through project sponsor. Revise project plan.
19. Your project has taken a serious turn for the worse. While your project team is working its heart out to meet deadlines, it appears that the executive project sponsor has lost all enthusiasm for the project. Youre not sure why. The project is near death, and if you cannot clear up this problem, youre close to the point where youre going to have to kill the project. What steps should you take?
    1. Set up a meeting with the executive project sponsor. See if you can determine why the problem exists.
    2. Set up a meeting with the executive project sponsor. See if you can determine why the problem exists. If you cant get anywhere with the executive project sponsor, try to get an ally or someone with influence on the sponsor to get at the heart of the matter. Meet with the stakeholders to apprise them of the situationmaybe you can get a new sponsor appointed. If you cant get anywhere , youre better off killing the project.
    3. Set up a meeting with the executive project sponsor. See if you can determine why the problem exists. If you cant get anywhere with the executive project sponsor, try to get an ally or someone with influence on the sponsor to get at the heart of the matter.
    4. Set up a meeting with the executive project sponsor. See if you can determine why the problem exists. If you cant get anywhere with the executive project sponsor, try to get an ally or someone with influence on the sponsor to get at the heart of the matter. If you cant get anywhere, youre better off killing the project.
20. One of your senior network engineers, Marty, is absolutely insistent that the vendor whos supplying your routers is all wet when it comes to a facet of a router that hes been tasked to install. However, when you consult with the systems engineers who work for the vendor, they tell you that Marty has misunderstood the way the product works and that it works the way theyve advertised it. How do you handle this problem?
    1. Call the vendor and Marty to a meeting. Sit back and watch them hash it out.
    2. Call the vendor and Marty to a meeting. Act as arbitrator in an effort to get at the root of what the problem might be.
    3. Arrange to have some of the vendors engineers meet Marty on site to work through a sample configuration on one of the routers. That way if hes right, they can see what hes talking about; if hes wrong, hell see why.
    4. Tell Marty to listen to what the vendor has to sayafter all, they invented it.

Answers to Review Questions

1. C. A team member lacking the required skill set is almost always doomed to fail. Whatever the reason, be it a communication breakdown on the skill set required or a functional manager who simply assigned the next person in line, if you determine that a team member does not know how to complete assigned tasks , you need to consider requesting a replacement. Unless there is a lot of slack time associated with the task, it is not possible to train the person so he or she can do the work. If a team member is spending time on another assignment, you need to confirm with the functional manager the amount of time committed to your project. Confusion over project expectations can normally be clarified with a one-on-one meeting. Illness or unplanned days off are a part of project life.
2. A. The schedule baseline is set during project planning before the project work begins. This provides a method to track project progress during execution against what was planned.
3. B. During contract administration, the project manager needs to review regular progress reports from the vendor as defined in the statement of work. Disputes between the vendor and team members must be investigated and resolved. Delays to vendor deliverables need to be analyzed for impacts on the project baseline and communicated to the project stakeholders. The other components listed in this question are part of procurement planning.
4. D. A weekly status report should be distributed in a consistent format and provide the stakeholders with a snapshot of progress on major deliverables and resolution of issues. Stakeholders do not have time to read through team minutes to obtain information, and many of them may not be familiar with how to interpret a project schedule.
5. B. Disputes over project deliverables should always be resolved by referring to the data in the project plan. If a deliverable does not meet the documented project requirements, you have an issue that needs resolution. If you are dealing with a matter of personal preference, the person or group responsible for delivery chooses how to complete the tasks.
6. A. The critical path tasks will impact the project end date, and you should focus on these tasks regardless of whether they are technical or business focused. The experience level of a resource does not guarantee that the task will be completed as scheduled. Tasks not on the critical path have built-in slack, but dont forget that if these tasks slip they may become critical path. Your project management software will automatically compute critical path as progress updates are made.
7. C. A project manager should always attempt to resolve staffing disputes with the appropriate functional manager providing the resource, but sometimes you reach an impasse. If you are dealing with a resource critical to the success of the project and all your attempts have failed, it is time to escalate the issue to the project sponsor. Writing a letter to the department head will not only alienate the functional manager, it could cause repercussions for your project sponsor. Ignoring the issue will not solve anything.
8. B. The people accountable for the work need to identify the problem and work with the project manager on a solution. Involving the entire team in an issue where many members may have no expertise is a waste of valuable time. The worst thing you can do is avoid the issue; chances are it will only get worse . You should meet with the sponsor and the client only after you have more information regarding the cause of the delay and potential solutions.
9. D. In order to address the issue, you need to understand what is behind the system engineers current behavior. He may have been given additional work that you are not aware of or he may misunderstand the project goals, to name just a couple of possibilities. The situation cannot be ignored, no matter how valuable the person is, and it should be handled in private.
10. C. The purpose of a formal project review is to communicate to key executives current progress, planned progress, and any roadblocks the project may be facing . This is the group of people that can make the hard decisions as to what the priority is between your constraints.
11. D. The projects valuethat is, how important its perceived by management, stakeholders, and perhaps even the corporate body at large contributes to the teams effectiveness, simply because team members feel like theyre working toward something thats held in high esteem. No one wants to work on a project that doesnt mean much to anybody. That being said, picture yourself as a project manager for a project thats going to update the internal piping in a sewage treatment plant. Chances are the overall corporate body isnt going to recognize the importance of your work, but stakeholders certainly are aware of what youre getting done.
12. A. These are always tough situations to arbitrate. Your primary goal is to bring the two together to try to air the differences in a way thats constructive. If possible, dont meet with them in your office; instead, choose a place thats neutral to all of you. Point out that you notice some friction going on and that youre wondering what the elements of that friction might be, because its having an effect, or will have shortly, on the outcome of the project. Stress how valuable each of them is to the efforts of the project. Ask questions that dont give either other person an opportunity to blame the other. Try to find creative solutions to the problems.

    If this fails, the next step might be to consider asking HR to take a more active role, either through a team-building exercise (which could only occur on larger longer projects where team members work full-time on the project) or in individual counseling .

13. B. The developer should not be a part of the conversation. He has his own work to do and is her peer, not her supervisor. Point out that youve researched some security methodologies and illustrate where you find her work to be different than the standards youve discovered . Ask her why and try to get her rationale behind the decision. If you find the rationale to be wanting, then tell her you need for her to begin to work toward the standards youre talking about. Otherwise, let it go. Speak with the developer to tell him that youve investigated the situation and dealt with it. Ask him to try to work more harmoniously with the security specialist. Be sure you tell both what an important part they play in the project.
14. C. Tacit vendor agreements such as this need to be noted somewhere and agreed to by both parties so that you save yourself embarrassment and expense when you actually call for the promised items. The SOW would be the most logical place to insert the statements that stipulated the promised modules.
15. A. First you must get both sides of the story. You must make sure that the changes being asked for are actually really required and that they were somehow missed at requirements-gathering time. Also you need to determine that the functionality being asked for is a need to have versus a nice to have. You also need to talk to the vendor to get their impression of the situation. Finally, you prepare a report and go to the sponsor for final instructions on how to handle the situation. If the sponsor says that no additional funds are authorized, then the business experts will have to deal with the system as-is (though you may have a this project stinks issue on your hands). If the sponsor says that the changes must be made, then she has to authorize the expenses required to make those changes. You cannot simply stipulate that a vendor make changes just because its the right thing to do, and you cannot operate outside the boundaries of a jointly agreed-to SOW.
16. C, E, F. Personality clashes and low morale can be urgent situations, but not necessarily of the type that require outside intervention. Your team-building skills would be useful in solving problems in these areas. Organizational changes require quick communication from the project manager. As a rule, most people are generally sensitive to change and are asking this question: What does this mean for me? This has a tendency to disrupt working patterns, decrease efficiencies, and requires that you act as a change agentgetting people through the change, while continuing the work of your project. Additionally, its quite possible that an organizational change may directly affect your project in which case you, too, need to ask: What does this mean for the project?
17. A, B. Probably, the project sponsor will communicate to you any budget or organizational changes. Project phase completion isnt something you immediately need to communicate. Personality clashes and low morale should first be treated with team-building efforts before escalating any further.
18. D. First, you should meet with the vendor to see whether you can negotiate a shorter delay. Working with tasks on the critical path allows for very little room for finagling other tasks without consulting with the project sponsor and stakeholders. Next, you should meet with the stakeholders to apprise them of the delay. If theyre okay with the deadline extension, you should modify the project plan and obtain formal sign-off from the project sponsor.
19. B. You start by going directly to the executive project sponsor to try to get at the heart of whats going on. Careful communication techniques are required so that you dont make the problem worse than it already is. If you cant get anywhere , you should seek out an ally or an influence that might be able to find out whats going on. Barring that, it may be worth your while to take the matter to the stakeholders, though theyll probably have little power to change the sponsor of the project. Finally, if things continue to deteriorate, youll have to pull the plug on the project.
20. C. Getting vendor SEs in a room with your engineer and letting them work through a sample configuration is the best way to handle the situation. You dont have enough information to know who is right. If the vendor is wrong, youll be able to address it. Otherwise, youve provided your engineer with a great lesson about configuring this particular router. You should be there with them to make sure that the fisticuffs and name calling are kept to a minimum.