Providing Performance Feedback to Team Members

The role of the project manager normally does not include providing formal performance reviews to team members. This is usually a responsibility of each employee’s functional manager. However, there is no question that a project manager does need to provide performance feedback to team members to let them know how they are doing and whether they are meeting performance expectations. This includes recognizing when team members meet their commitments and providing feedback to them when they are not meeting your expectations.


Telling people they are doing a good job is easy. It is harder when you have to tell a team member he or she is not meeting your expectations. When this type of conversation is appropriate, the project manager can use the following techniques:


  • Plan. This helps managers develop a framework for providing effective feedback. The manager should think ahead of time about the behavior that should be highlighted and how the manager can help the employee improve.
  • Provide examples. Vague criticism fosters anxiety. Tangible examples are required to highlight the feedback. Typically, you do not need to provide dozens of examples. Hopefully, you can make the point with a couple representative observations
  • Motivate. Use motivational techniques in the discussion. The employee is bound to be disappointed by the feedback. Look for opportunities to build the morale of the team member as well, so that they will be eager to improve.
  • Sandwich. The project manager should start the session with positive comments, then get to the feedback and finish with positive, motivating comments.
  • Allow time for feedback. The process needs to be a dialogue between the project manager and the team member. So, seek feedback from the team member and allow him or her to agree, disagree or provide their perspective.  
  • Set a timeframe for action and follow-up. The project manager should document any action items, circulate them to the team member and ensure that they are completed. Before the meeting is over, the project manager and team member should also agree on a follow-up timeframe to check progress.

Techniques for Managing a Team



Manage Project Team involves tracking team member performance, providing feedback, resolving issues, and coordinating changes to enhance project performance. The project management team observes team behavior, manages conflict, resolves issues, and appraises team member performance. As a result of managing the project team, the staffing management plan is updated, change requests are submitted, issues are resolved, input is given to organizational performance appraisals, and lessons learned are added to the organization’s database.


Management of the project team is complicated when team members are accountable to both a functional manager and the project manager within a matrix organization. Effective management of this dual reporting relationship is often a critical success factor for the project, and is generally the responsibility of the project manager.


1 Observation and Conversation Observation and conversation are used to stay in touch with the work and attitudes of project team members. The project management team monitors indicators such as progress toward project deliverables, accomplishments that are a source of pride for team members, and interpersonal issues.


2 Project Performance Appraisals The need for formal or informal project performance appraisals depends on the length of the project, complexity of the project, organizational policy, labor contract requirements, and the amount and quality of regular communication. Project team members receive feedback from the people who supervise their project work. Evaluation information also can be gathered from people who interact with project team members by using 360-degree feedback principles. The term “360-degree” means that feedback regarding performance is provided to the person being evaluated from many sources, including superiors, peers, and subordinates.

Objectives for conducting performance appraisals during the course of a project can include reclarification of roles and responsibilities, structured time to ensure team members receive positive feedback in what might otherwise be a hectic environment, discovery of unknown or unresolved issues, development of individual training plans, and the establishment of specific goals for future time periods.


3 Conflict Management Successful conflict management results in greater productivity and positive working relationships. Sources of conflict include scarce resources, scheduling priorities, and personal work styles. Team ground rules, group norms, and solid project management practices, like communication planning and role definition, reduce the amount of conflict. When managed properly, differences of opinion are healthy, and can lead to increased creativity and better decision-making. When the differences become a negative factor, project team members are initially responsible for resolving their own conflicts. If conflict escalates, the project manager should help facilitate a satisfactory resolution. Conflict should be addressed early and usually in private, using a direct, collaborative approach. If disruptive conflict continues, increasingly formal procedures will need to be used, including the possible use of disciplinary actions.


4 Issue Log As issues arise in the course of managing the project team, a written log can document persons responsible for resolving specific issues by a target date. The log helps the project team monitor issues until closure. Issue resolution addresses obstacles that can block the team from achieving its goals. These obstacles can include factors such as differences of opinion, situations to be investigated, and emerging or unanticipated responsibilities that need to be assigned to someone on the project team.

Getting a Project Back on Schedule

People that have worked on project teams know that there is a lot that can go wrong and result in a project trending over its deadline date. For instance, some of the work may be harder than originally anticipated. You may have turnover on the project that results in having to get new people up-to-speed. Sometimes you discover that activities were simply underestimated.

Regardless of how you get there, many times you will find that you are trending beyond your committed deadline date. If you discover that happening, the first obligation of the project manager is to try to determine the cause. If you look for remedies without knowing the cause, you are susceptible to having the situation re-occur over time.

What should you do after you know the cause? Should you notify the client and push the project end-date out further? Not yet. The next obligation of the project manager and project team is to try to make corrections that will get the project back on track again. If you are trending over your deadline at the beginning of a long project, you have many options available to you. If you are toward the end of the project there may be fewer options available. The following techniques can be applied to your situation. Note that this list is not in a priority order. Some techniques may work better in certain situations while others can be applied more successfully elsewhere.

Work Overtime: Everyone hates it, but one logical place to look at is overtime. If people work more hours, they can get more work done in the same amount of calendar time. Overtime may be the best option if you are close to the end of the project and just need a final push to get everything done on schedule. If you are toward the end of the project, you also may be able to issue comp-time after the project is completed. If you are still early in the project, there are probably other options that are more effective.

There may be cost implications to this option if you need to have contract resources work overtime.

Reallocate Resources onto the Critical Path: The project manager must first understand the activities that are on the critical path. After all, if the project is trending over deadline, by definition it is the critical path that is late. Once the critical path is understood, you should see if there are resources that can be moved from other activities to help with the activities on the critical path. This will allow you to get the project back on track by delaying or stretching out some work that is off the critical path. Be careful though – delaying some work may end up changing the critical path. Always make sure you double check the critical path each time you change the schedule.

Double-Check all Dependencies: Schedule dependencies represent activities that must be completed in a certain order. For instance, if you are building a house, you cannot start putting up the frame until the foundation is poured and dried. If you are trending over your deadline, these dependencies should be re-validated, since it is possible that the schedule is being lengthened by dependencies between activities that are not valid. Invalid dependencies may make it appear that activities must be performed sequentially, when they can really be done in parallel. Sometimes the scheduling software accidentally adds a dependency if you made a mistake entering the activities. Sometimes the project manager adds the dependency on purpose, but upon later review decides that the dependency does not really exist. It might make sense to have the team members review the schedule to see if they find dependencies that the project manager thinks are valid, but that they know to be invalid.

In addition to accidental or erroneous dependences, your work plan may also include discretionary dependencies. These are dependencies that you created on purpose. However you recognized that you have some discretion on where and when the dependency is placed. Discretionary dependencies should be checked to see if you can move a future discretionary relationship earlier. This will result in starting and finishing the dependent activity earlier, which can help you accelerate the overall schedule. Of course, to have an impact, you must identify a discretionary activity that is on the critical path.

The dependencies should all be double-checked to make sure you have all your facts correct before you get into more drastic measures to bring the project back on schedule.

Check Time-Constrained Activities: Time-constrained activities are those that have durations that do not change based on the number of resources applied. (For instance, you may be allocating team members to a five-day class. The class takes five days if one person attends, and it takes five days if ten people attend.) All of these time-constrained activities should be checked to validate the timeframe. Perhaps there are assumptions being made that could be changed with a different approach. For instance, if you allocated three days for a contract to reach a client, perhaps the length could be reduced to one day by paying more for overnight delivery. If you have a two-day wait for concrete to dry, perhaps the time could be shortened by renting fans to blow air on the concrete.

Swap Resources: You saw previously that the first thing you want to do when you are trending over your schedule is to try to determine the cause. One cause you may find is that you have one or more resources that are not as productive as you planned. Perhaps it is because they do not have the right skills. Perhaps it is because they are not as productive in this particular area as they are in other areas. Regardless, there may be opportunities to replace resources. In some instances, you can simply swap people who are working on different activities within your project. Other times, it may mean releasing a team member and bringing in another person. Remember that the activities on the critical path are key. You may have options to assign a more productive resource to those activities while reassigning a less productive resource to non-critical path activities. If the activities off the critical path are delayed, you may still be okay in terms of meeting your overall project deadline.  

"Crash" the Schedule: Crashing the schedule means to apply additional resources to the critical path. It’s always possible to just throw more resources on the critical path, but “crashing” also means you try to get the biggest schedule gain for the least amount of incremental costs. For instance, if one person were assigned to complete an activity in ten days, see if two people could complete it earlier. If two resources can complete the activity in five days, there may not be any incremental cost to the project, since you are applying twice the resources for half the time. However, if two people can complete the work in six days (instead of ten), you will have accelerated the schedule at an incremental cost of two work days (two people for six days versus the original ten day estimate). In this example, you could further crash the schedule by applying three resources. Perhaps now the activity would take four days, or four and a half days. Typically, the more resources you throw on an activity, the more the incremental cost will be and the less incremental time savings you will receive.

The additional resources may come from within the project team, or they may be loaned temporarily from outside the team. One of the goals of crashing the schedule is to minimize the incremental cost. However, in exchange for completing some work ahead of schedule, crashing usually always leads to some additional incremental cost to the project. If cost is not as important as the deadline, “crashing” a set of activities can result in accelerating the schedule.

Fast Track: Fast track means that you look at activities that are normally done in sequence and assign them totally or partially in parallel. For instance, in the home building example above, the house frame could not be constructed until the foundation was dry. However, if the house is large enough you may have options to fast track by starting to erect the frame on the side of the home where the foundation was poured first. The foundation will harden there first, and might allow you to erect the frame on that side, while the foundation on the far side of the home is still drying.

Another example involves designing an IT application. Normally you would not start constructing a solution until the design was completed. However, if you were fast-tracking, you would start constructing the solution in areas where you felt the design was pretty solid without waiting for the entire design to be completed. Fast-tracking usually involves risk that could lead to increased cost and some rework later. For instance, in the example of designing and constructing an application, it’s possible that the design might change before it is finalized, and those final changes may result in having to redo some of the work already underway.

A good rule of thumb is that sequential activities can sometimes be fast-tracked by up to 33%. In other words, if you are fast-tracking, you can start the second of two sequential activities when the first activity is 66% complete. There is risk involved. However, this seems to be a level of fast-tracking risk that is normally acceptable.  

"Zero Tolerance" Scope Change: Many projects begin to trend over their deadline because they are doing more work that they originally committed to. This is probably the result of poor scope change management. However, if you are at risk of missing your deadline date, the project manager must work with the client and team members to ensure that absolutely no unplanned work is being requested or worked on – even if it is just one hour – without going through proper scope change management procedures. All energy should go into accelerating the core work that was agreed to.

Improve Processes: When you look at the cause for the project trending over schedule, you may find that some of the internal work processes could be improved. The project manager should solicit team member feedback and look for ways that are within your team’s internal control to streamline processes. For instance, perhaps you have a daily status meeting that is not providing value and can be scaled back to once per week. You may also find that there are bottlenecks with getting deliverables approved.

If you find that there are delays caused by external processes, try to negotiate changes to the processes going forward – at least on a temporary basis. For example, you may find that activities are being delayed because people need to work on their yearly performance reviews. While these are important, perhaps the timing of completing the reviews can be changed to allow critical project activities to be completed on schedule. 

Regain Commitments: Sometimes deadlines are missed so often that the team no longer has a commitment to completing their work on time or within budget. This can especially happen if team members consistently miss their deadlines without consequences. Other team members wonder why they need to work hard to meet their deadlines and budget estimates when others are not meeting theirs. When this happens, work with team members to evaluate future work, re-validate estimates, and gain commitments to complete work on schedule. The project manager needs to try to refocus the team to meet the deadlines they are committing to. The project manager should go to each team member and ask for their personal commitment to do what it takes to meet their budget and schedule commitments.  

Improve Morale: The team will work harder and perform better if they do not spend time complaining and sulking. The project manager should build shared purpose, increase camaraderie and do some fun things to get people excited and happy again.

Scope Back the Work: One final option that is usually available is to look at the work remaining and negotiate with the sponsor to remove some of it from the project. If the project manager feels like some of the remaining work is not vital to the project, he or she could discuss eliminating it quickly. If the remaining work is all vital to the solution, this discussion still might need to take place as a last resort. There may be options to complete this project on-time with less that 100% functionality, and then to execute a follow-up project to complete the remaining requirements. This is certainly not the place to start getting back on schedule, but it may be your final option if all other techniques fail or are not available.

Estimating Productive Hours Per Day in a Project


It can be challenging to provide project estimates for effort hours, duration and cost. Of the three estimates, you must start off with an estimate of effort hours. Without an idea of the effort hours, you cannot accurately estimate duration or cost.

One of the key factors in converting an estimate of effort hours into duration is to determine a standard for how many productive hours of work you will experience in a typical workday. For example, if you have an activity that you estimate will take forty effort hours; it is unlikely that it can be completed in five eight-hour calendar days. There are many additional work and personal activities to factor into the estimated duration as well. Without taking these into account, it is likely that you will hit your estimates for effort hours, but run over your duration estimates. Project Manager need a "reality factor" to convert the estimated effort hours to estimated duration. You need to determine the number of productive hours per day a person is actually going to work. There are normal non-project activities that come up during the day that need to be accounted for. This includes departmental meetings, social conversations with co-workers, doctor’s appointments, sick time, administrative activities, going to the bathroom, etc. You could try to come up with the number of productive hours per day your specific team works, but it would be very tedious. A generally accepted ballpark number for average productive hours per day is 6.0 to 6.5, based on an eight-hour day.

This does not mean that in any one day a person may not be productive for the full eight hours. However, it does factor in a person’s productive hours per day over time. For instance, in a 40 hour week, one of your team members may have a one-hour department meeting, spend three hours socializing, leave two hours early one day for a doctor’s appointment, spend one hour on administrative requests, spend one hour on the phone for non-business reasons and spend one hour going to the bathroom and the break room (12 minutes per day). So, during that week the person was available for 31 hours, or six hours and twelve minutes per day.

Share with the team the scheduling assumptions that you are making and your expectations. They must take the responsibility to tell you if outside influences are making it difficult for them to spend the allotted time on the project. That will give you the input you need to change their work responsibilities or else change their availability and productivity factors.

When you have contract resources, you should also take a productivity factor into account. Even though these resources are contractors, they will still experience many of the factors that lead to a less than 100% productivity factor. For instance, they are still going to socialize a little and they still need to go to the bathroom. However, you do not expect that contract people will have the same level of non-productive time as employees. A good rule of thumb for a contract resource is 7 to 7.25 productive hours per day. This factor recognizes that the contract resources are not robots and they will not be 100% productive every day. Of course, you still need to allocate contract resources for eight hours per day and you still need to pay them for eight hours per day. However, for the purpose of your work plan, you should factor in the productivity factor as well.

For example, let’s say you have an 80 hour activity. If an employee is applied full time, it may take him or her a little over twelve days (80 / 6.5 productive hours per day) to complete the work. If a contract resource is allocated full time to this same activity, the activity duration would be eleven days (80 / 7.25 productive hours per day).

Include Project Meetings and Collaboration Time in the Estimate

Departmental and company meetings are not typically within your control and are not accounted for on the work plan or in the estimate. They may be accounted for in the estimated duration if you factor in a reduced number of available hours per day for each resource (say 6.0 or 6.5 hours per day). The reduced number of hours takes into account these types of meetings that you have no control over.

On the other hand, meetings that are project-related should be included in the work plan and should be added to the estimated effort of the project. This is because meetings of this type are within the control of the project team. The project manager can schedule these for one hour every other week or they could be scheduled every day.

Likewise, try to account for the total time required for all participants in any collaborative project-related meetings. For instance, if you are planning deliverable walkthroughs, make sure you include the time of all participants. When you are circulating documents for approval, include some review time for each person that you think will be involved. If you are planning on having review meetings at the end of each milestone, make sure to include time for each participant.

The Client May Think the Estimate is too high

After you have prepared your estimate, you may need to defend it if the client thinks that the numbers are too high. You should be able to first defend the estimate by explaining the estimating techniques you used, the process you followed and the assumptions you made. If the client still thinks the numbers are too high, or cannot afford the solution at that cost, there are a few options.

1.       Determine if the client has any additional information that would allow you to revise your assumptions and perhaps revise the estimate. For instance, if a critical end-date now has some flexibility, perhaps the estimate can be revised based on this new information.

2.       Determine whether high-level requirements and functionality can be scaled back. In many cases, the original set of features and functions is more of a wish list. After seeing a price tag, it is very possible that the client can live without certain features.

3.       If you included a high contingency to reflect a high estimating risk, ask the client for more time to gather more detail for the estimate. This may result in there being less uncertainty and risk, and allow you to reflect this as a smaller contingency.

Restructure the project to only include the detailed analysis phase. After the full analysis is completed, re-estimate the remainder of the project, based on a confirmation of exactly what is being requested. The total effort and cost may or may not be lower, but at least you will have more detailed information to back up your estimate.