This task, “1.3 Support Team Performance”, deals with how we assess team member performance, support team development, give feedback and verify improvements. It is in the People domain and is team focussed. However, since there is no comparable “Measure Project Performance” task in the Process domain, we will also address general project tracking in this discussion.
The “Support” word in the “Support Team Performance” is significant and emphasizes the critical role project managers play in creating high-performing teams. Project managers do more than plan, direct, and dispassionately measure performance like you might evaluate a vehicle’s speed and fuel consumption. Such non-invested observation will be reflected back as weak, non-committed team output. Instead, planning, care and effort must be invested to support team performance.
Culture and Empowerment
Performance is the product of the skills, attitudes, tools and processes used by the team. From these attributes, the team attitude, in terms of cooperation, problem-solving and motivation, plays the most significant role in determining project outcomes.
We can have the best tools and processes in the world, but without a cooperative, driven team, we are unlikely to be successful. In contrast, many underfunded, poorly equipped groups have built incredible products and services with hard-working, motivated teams. By far, people are the most significant factors, so getting these factors correct, or at least optimized given our constraints, is well worth investing in.
In task 1.2 Lead a Team, we looked at the motivational benefits of empowerment and psychological safety. We also investigated servant leadership and the role of protecting the team from interruptions. By engaging team members in planning, estimation, risk management and decision-making, we increase commitment to shared outcomes.
Teams need access to project and work information to collaborate and communicate effectively. They also need to access co-workers and other stakeholders (for instance, customers, vendors, specialists) to ask questions, share information and work successfully.
The original agile way of designing workplaces to facilitate teamwork was to use small teams and colocation. Working with small teams and breaking large initiatives into multiple small teams allows everyone to sit together and communicate face-to-face. This is a quick form of communication that also allows emotion and body-language to be easily conveyed and detected. It is easier to spot if someone is confused or disengaged than if communicating via emails or documents.
Colocation helps create open, unfiltered debate. Without the barriers of video conferencing, email or telephone, team members can more easily get to the heart of the issue with direct communication. This helps resolve confusion, conflict and build a strong commitment to decisions.
A downside of face-to-face communication is the cost of physical colocation. Talent, clients and customers tend to be geographically distributed. Now that digital marketing quickly reaches the entire world, business is increasingly global, making collocated teams problematic. With the advent of low-cost video conferencing, many of the benefits of face-to-face communications can now be achieved via technology.
Organization’s work from home responses to COVID-19 accelerated the adoption of video conferencing and remote collaboration tools. Now, most organizations are practiced in using remote collaboration tools. These tools include video conferencing but also incorporate discussion threads, document management systems, project repositories and group facilitation tools.
1.3.1 Appraise team member performance against key performance indicators
Key Performance Indicators (KPIs) are metrics designed to track important things we care about. The trouble is many organizations track metrics because they are easier to collect (number of change requests received) than what they really care about (customer satisfaction.)
Software projects have a particularly bad reputation for tracking things that might initially seem reasonable but, in practice, create unintended consequences. The number of lines of code written per week by a developer may seem like an appropriate way to track progress; however, it has terrible results. It leads to code-bloat (long-winded code that is hard to maintain) and does not reward simplification and refactoring that aims to clean-up code, make it tighter and easier to sustain. It also does not incent collaboration between team members. Why go and help Bob if that will only increase his code line count and worsen mine?
Instead, we need to watch out for some common metric problems:
- Misleading Observations – Some misguided observations can lead us astray if we do not understand the bigger picture and how things work. For a long time, people believed stars came out at night and planets and the sun revolve around the earth because this is how things appeared. Metrics with a faulty view of how things work will not help us track and respond.
- Hawthorne Effect – The act of measuring something makes people take notice and adjust their behavior. For instance, publicly tracking hours-worked is likely to result in people working long hours, leading to burnout, mistakes and quickly consumed budgets. We should try to create metrics aligned to the end-goal – such as completed projects, happy stakeholders, etc.
- Lagging metrics – When making decisions and steering a project, an imperfect view of the future is more useful than a perfect view of the past. Auditors and accountants may want to know exactly what was spent last month, but it is more beneficial for project managers to understand that the remaining scope is likely to take 7 months to complete, not 6 months as planned, and we are likely to be 10-15% over budget. Leading metrics such as trends and projections are more useful than lagging metrics.
- Lack of cooperation – When people are measured individually, they may not be incented to help others be successful since this will raise the group average and may diminish their own relative performance. So rather than measuring at the individual level, measure performance at the aggregated team level. This will encourage cooperation and knowledge sharing.
Metrics are like fire; they make good servants but poor masters. We do not want to become a slave to creating time-consuming metrics. Instead, we want metrics that serve our purpose of helping steer the project forward.
The acronym SMART stands for
- Specific – Targeted on a singular attribute, not vague or too broad. E.G. Mean-Time-to-Failure not Good-Quality
- Measurable – Quantifiable to objectively evaluate progress. E.G. In days and hours rounded to half an hour.
- Achievable – The metric should be possible. Metrics are not stretch goals they should be attainable. Some organizations use “Assignable” for the A of SMART and specify who will do it. Either way, practical metrics with identified roles help make metrics achieve and assignable.
- Relevant – Something we care about that relates to the objective at hand. E.G. it is better to track features-delivered-and-accepted-by-the-client than just features-developed since some of these developed features may get rejected by the client.
- Time-bound – Specify when the results will be delivered.
Useful metrics should not take a long time to track or calculate. Instead, metrics should be self-generating and straightforward. Ideally leading, future-focussed and relevant to the end-goal.
We use assessments to check the health of the project, diagnose problems and track project performance. Some other reasons for appraising team performance include:
- Measure and improve skills and competencies
- Increase team cohesiveness
- Solve issues
- Surface and resolve conflicts
- Improve team interactions and performance
Some techniques for appraising performance include
- Observe and measure KPIs
- Compare performance to goals
- Asking questions to team members
- Evaluate team performance
Actions that may come from team performance assessments include:
- Provide positive and negative feedback
- Create training plans
- Provide training
- Remove underperforming team members or reassign their work
These points are shown below:
In section “1.2 Lead a Team,” we saw how establishing a clear vision is essential for cementing commitment and encouraging forward progress within the team. Without a clear vision, like driving in fog, we slow down, unsure of what lies ahead. Objectives act as interim goals or stepping stones towards the final vision. Teams with clear objectives are more productive and driven than teams without them.
Project managers should collaboratively set objectives with team members to create consensus and commitment towards common goals. Objectives should be first created near the beginning of the project but then also updated and evolved throughout the project’s execution.
Objectives and Key Results (OKR)
Companies like Google, Walmart, Twitter and ING bank popularized Objectives and Key Results(OKRs). They are now used by many organizations because they are simple, flexible and goal-oriented. Typically set every quarter, they do not get stale and help link team goals to organizational objectives.
OKRs are simple and have only two components: the Objective and the Key Result. They often take the form of:
I will [Objective] as measured by [this set of Key Results].
Here is an example:
Objective: Become the market-leading online dating site
- Key Result #1: Acquire 800K new customers this quarter.
- Key Result #2: Increase marketing share by 20 percent.
- Key Result #3: Reduce subscriber attrition by 45 percent
While simple in structure, there are some principles to follow.
OKRs describe both What will be achieved and How it will be measured.
Objectives are small, memorable qualitative descriptions of what we intend to achieve. They should be inspirational and engaging; teams can get creative and build exciting objectives.
Key Results are quantitative metrics measured to track progress towards the Objective. Each Objective should have between 2-5 Key Results that are numeric. “If it does not have a number, it is not a Key Result.” – Marissa Mayer, Google
Another example could be:
Objective: Become the most trusted dating site
- Improve Net Promoter Score from 30 to 50.
- Increase referrals to over 60%
- Increase renewal rates from 65% to 80%.
- Reduce non-matched cancellations from 15% to 5%
OKRs suit agile teams since they are visible, lightweight, and regularly updated.
The regular rhythm of creating, tracking then replacing OKRs keeps them fresh and engaging for teams while retaining support with organizational targets. Changing OKRs frequently also reduces the chance of misuse or gamification that might be counterproductive.
1.3.2 Support and recognize team member growth and development
One of the best ways to motivate team members is to take an interest in their professional development. When we can build elements for their growth into the project plan, they now have a personal investment as well as a professional one towards making the project successful. This may take the form of approving related training, making time for self-study, or creating an opportunity to try a new role or skill in a safe, controlled environment.
The short timeframes of agile iterations make for ideal test cycles. Maybe someone wants to try out a new role for a couple of weeks or lead a small group. Timeboxed iterations are ideal for running experiments and provide natural opportunities to review what worked, what did not and make decisions for future iterations.
Timeboxed experiments are not unique to agile. The regular cadence of agile iterations make experiments natural, but there is nothing to stop hybrid and traditional projects from adding timeboxed experiment cycles to their plans along with the regularly scheduled tasks. Setting up a, say, monthly, continuous improvement workshop that discusses ideas to try and runs experiments can be worked into most project plans. Regularly engaging team member’s viewpoints is a great way to increase their involvement and, therefore, commitment to the project’s success and organizational progress.
In the book “Measuring and Managing Performance in Organizations,” author Robert Austin, makes three key observations:
- “You get what you measure.”
- “You get only what you measure, nothing else.”
- “You tend to lose the things that you can’t measure such as insight, collaboration, and creativity.”
The first point is referencing the Hawthorne Effect. The second point says that if you do not measure things, they might not get done. The third point explains that we need to be careful that our measurements do not discourage desirable behaviors like collaboration.
Agile expert and author Mary Poppendieck explains how Nucor Steel measured and promoted collaboration and creativity through a process known as measuring up. Nucor Steel is one of the few U.S. steel manufacturers making a profit and generally good labor relations. They attribute much of their success to their incentive-based pay scheme based on productivity.
The critical component of their pay-scheme is that plant managers are not paid based on how well their plan performs but on how well their plant and other plants perform. This may sound unfair, how can they influence how other plants perform? Well, through collaboration, sharing ideas and cooperation. Similarly, departments are measured across several departments, teams across all teams, and individuals based on the whole team results. This rewards collaboration and cooperation that would otherwise be difficult to measure and encourage.
On software projects, defects could be traced back to individual programmers who introduced them, but rolling them up to an entire team is often a better way to go. It promotes information sharing, mentoring and helping each other out.
Team Stage Specific Support
As teams progress through the Tuckman stages of Forming, Storming, Norming and Performing they will likely have different growth and development needs. To begin with, in the Forming stage they may need more support understanding scope, direction, priorities and developing ground rules. Later this may transition to conflict resolution and developing team norms. Finally, we hope the team will reach the Performing stage and can be supported with challenging the process and improving delivery capabilities.
Throughout all stages of team development, project managers should be looking for opportunities to build team member capabilities and promote teamwork. Some of the ways they can do this include:
Communicate effectively – Make sure everyone knows what the long term, medium-term and short term goals and objectives are. These are reflected through the project vision – See “1.2.1 Set a clear vision and mission”. Also, through release plans or quarterly objectives, the product backlog or work breakdown structure.
Foster collaboration – promote and reward team members helping each other to achieve objectives and deliver results. Pairing and Mobbing
Develop trust among the team – Create psychological safety, demonstrate the desired behavior of admitting when you do not have all the answers, and asking for help.
Promote collaborative decision-making and problem-solving – Acknowledge team members are closer to the execution of the work than most project managers. So we should engage their insights and perspectives in the decision-making and problem-solving process.
Promote continuous improvement – Challenge the status quo, encourage small scale experimentation, constant improvement and knowledge sharing.
1.3.3 Determine appropriate feedback approach
Project managers are expected to track, report and help steer all aspects of a project’s performance towards success. This involves selecting and employing the appropriate tools to provide timely stakeholder feedback.
While early and continuous feedback is emphasized in agile approaches, it is essential to any project environment. As old adages warn us:
- “Projects get late, one day at a time.”
- “A stitch in time saves nine.”
- “Some things are best nipped in the bud.”
In other words, we need to be proactive with monitoring and acting on issues. This includes providing feedback, both positive and negative.
Beware of Stale Sandwiches
Some organizations use outdated and inappropriate feedback mechanisms — the annual or quarterly review with your boss in one example. Due to the infrequency of such events, they become a big deal and can lose context. This is true for both the boss who has to think of things to give feedback about, and the recipient who has to prepare a ‘defense’ recalling goals met and new objectives for the next period.
Offering feedback in a sandwich format of saying something positive, then something negative, but following up with something else positive is not the most effective way to explain issues or invoke change. This praise sandwich format does not fool anyone, and most people are still processing the negative filling to even notice the second positive wrapper.
An example would be telling someone: “You are prompt and committed, but several people have reported they find you prickly and difficult to collaborate with, but everybody agrees your technical work is excellent.”
Feedback sandwiches are hard to swallow, and the only thing that could make them worse is to couple it with infrequent feedback of quarterly or annual reviews. These are stale sandwiches, the worst kind.
From Sandwiches to Wraps
Management 3.0 author, Jurgen Appelo suggests ditching praise sandwiches and adopting what he calls Feedback Wraps instead. It is a great concept that addresses the main issues that explain why nobody really likes praise sandwiches.
One issue is that once people get used to receiving praise sandwiches, they tend to filter-out the two elements of praise and focus only on the criticism – missing valuable positive feedback. Also, these sandwiches often miss the context that frames the feedback. Nor does it really explain the facts or feelings that are critical components of useful feedback. Finally, helpful feedback needs to explain the impacts of events and actions to show why they are significant.
The feedback wrap fixes these problems and incorporates the missing components. They are structured as follows:
- Describe the context – Start by describing the context to explain the situation.
“I would like to talk to you about the customer demo today.”
- List the observations – Provide observations with examples and instances, without accusations or finger-pointing.
“The way you answered Bill’s question about when the unit will be functional seemed very abrupt, and I could see he was taken aback. He did not ask any more questions after than, and he normally asks lots.”
- Express your emotions – Let the person know how you feel about the facts. This creates more awareness of the impact of the facts, without blaming anyone.
“I felt bad for him since he has been a vocal supporter of the project and does not understand all the technical work remaining.”
- Sort by value – explain our needs because the receiver may not realize what is important to us.
“It is important that we keep the business representatives on our side; they help us secure funding and remove roadblocks.”
- End with suggestions – Allow the person to determine what needs to be done to close the gap between needs and facts, and offer a suggestion or two to move things forward.
“When the business asks questions, even uninformed ones, try to show appreciation for their interest and answer them courteously.”
When providing feedback, sooner is usually better than later. Solving problems closer to their source prevents other, similar issues from developing. There is also less chance of people forgetting what happened or having different recollections of events.
Continuing the handheld food theme. As we evolve from praise-sandwiches to feedback-wraps we should consider TACOS as an acronym to help remember some important attributes of effective feedback.
T – Timely. Provide feedback as close to the event occurring as possible. Don’t save it up for a quarterly or annual review.
A – Appropriate. Some acts that deserve praise or negative feedback are minor and should be treated that way. Others more significant that might warrant extra ceremony or rigor. Don’t use a one size fits all approach.
C– Context. Explain the context and how plus why the issue/event/act was important.
O – Observations. Describe the facts and impacts without blaming or finger-pointing.
S – Suggestions. Recommend some options for moving forward, so people see solutions not just problems.
Get Agreement on the Outcome
After delivering feedback with suggestions, be sure to state what the expected actions are. We must have an agreement before the discussion can be closed. This does not necessarily mean that we are always right and the team member must change – sometimes we may not have had all the facts, and some compromises are needed. However, do not downplay the performance expectations if the overall project performance is suffering. Then follow up on an action plan to ensure the feedback has been applied.
Providing feedback to remote team members is even more difficult because we miss some of the ability to emphasize an appropriate tone, see how people react and intervene if things start to go adrift. Unfortunately, this means remote team members often receive less frequent feedback, so it is more likely to be old and stale.
Kevin Eikenberry and Wayne Turmel, authors of “The Long-Distance Leader” have the following tips for remote coaching and feedback.
- Communicating through technology creates mental and social obstacles that do not exist face-to-face. Assume positive intent from people, but be prepared to be wrong.
- Make sure job expectations are crystal clear.
- Use your webcam to communicate visual and non-verbal cues
- Check-in, don’t check-up. Schedule regular events for support and direction setting.
In addition to people-based feedback, teams should always be looking for feedback on their evolving product and process. Frequent verification and validation reduces the amount of scrap and rework necessary. Defects, errors and omissions should be found as close to their source of introduction as possible. This reduces the impact of building on top of faulty work.
Projects achieve this regular feedback through testing and other quality assurance processes. Inspections and reviews are also valuable. Phase gate reviews are often accompanied by assessments to test fitness for the project to move to the next phase. This may include meeting proof-of-concept criteria, a certain amount of scope completion, or a comparison against a baselined metric.
Agile projects typically have a product demonstration at the end of every iteration. The Sprint or iteration demo shows new work to sponsor, business and customer representatives. People discuss their impressions, clarify any questions, and hear a brief review of what is planned next. Getting regular feedback from these stakeholders is invaluable for navigating high-change environments.
The same ideas apply to the processes teams use. Frequent inspection, discussion and experimentation can improve how we work together and interact with other groups and stakeholders. Agile retrospectives are also held at the end of every sprint/iteration and gather feedback and insights on the processes being used.
After discussing possible changes or experiments for teams to run for an iteration or two, the team decides which ideas they want to take forward. The ongoing inspection, feedback and adaptation of process allows teams to adapt and improve. It is also an empowering way of working – knowing if something is not right, the team is trusted to improve it.
While retrospectives are built into agile approaches, there is nothing to stop hybrid and traditional teams from adding retrospectives or review-meetings to their planned work. There may not be the same freedom to change process. Some environments are regulated for safety or compliance reasons, but getting together and reviewing what can be improved is usually a valuable and appreciated use of people’s time if the constraints are explained.
Performance Tracking Tools
Switching from tracking team member performance to tracking project performance opens the topic of metrics and reporting further. For the PMP exam, practitioners are expected to understand and apply various commonly used project reporting techniques. We will list the basics and provide links for further information. You should know how to create and interpret them all.
Commonly used Agile Metrics
- Throughput metrics
- Cycle time
- Burndown charts
- Burnup charts
- Information radiators
Traditional project metrics
- Work performance reports
- Variance analysis reports
- Quality reports
- Earned Value Management
- Gantt Charts
1.3.4 Verify performance improvements
It is all very well setting the stage for high performance and reporting on performance, but we also need to follow through and make sure we are producing and improving. Fortunately, well-designed metrics such as Objectives and Key Results (OKR) and Goal Question Metrics (GQM) allow us to check.
Performance reviews, retrospectives and frequent project reporting provide plenty of opportunities to check how things are coming along. We can design OKRs and GQMs to incorporate the “20% decrease in cycle time”, or the “15% increase in field test satisfaction” we need to verify improvements. It’s then a case of reporting on progress against these targets.
Trust but verify
Setting goals is admirable, but people get busy, issues arise, and targets can quickly get forgotten. So, even though we trust people, it is necessary to follow up. Making metrics visible is a great way to keep them in people’s minds. We can use the Hawthorne Effect to our advantage and create big visible charts of metrics we care about.
Deliverables and Tools
- RACI Matrix
- Management by Objectives
- Team Performance Assessments
- Performance Reports
- Task boards
- Performance tracking tools
- Information radiators
- Burn charts
- Earned value
- Throughput metrics
- Cycle time
- Value stream map
- One-on-One Discussions
- 1.5 Ensure Team Members and Stakeholders are Adequately Trained
- 1.6 Build a Team
- 1.7 Address and Remove Impediments, Obstacles, and Blockers for the Team
- 1.11 Engage and Support Virtual Teams
- Article: Smart Metrics
- Article: The five team leadership principles for project success
0 of 3 Questions completed
You have already completed the quiz before. Hence you can not start it again.
Quiz is loading…
You must sign in or sign up to start the quiz.
You must first complete the following:
0 of 3 Questions answered correctly
Time has elapsed
You have reached 0 of 0 point(s), (0)
Earned Point(s): 0 of 0, (0)
0 Essay(s) Pending (Possible Point(s): 0)
Congratulations! You scored 100% and won the Support Team Performance badge.
(Must be logged in to be awarded badges)
See your achievements
|Table is loading|
|No data available|