PMI Authorized PMP Exam Prep: Lesson 5 Support Project Team Performance

The goal of this artifact is to provide a quick overview of lesson 5 of PMI Authorized PMP Exam Prep-Support Project Team Performance. The purpose of this document is to provide opportunity to the course participants and enable learning anywhere anytime. The idea is to provide content that reinforces all the topics covered in the class on Saturday as part of the PMP course at Education Edge.

Lesson 5: Support Project Team Performance

This lesson explores concepts and tasks related to ensuring the team is doing its best work and stays on track to achieving successful project outcomes.
Topic A: Implement Ongoing Improvements

Topic B: Support Performance

Topic C: Evaluate Project Progress

Topic D: Manage Issues and Impediments

Topic E: Manage Changes

Support Project Team Performance -Topic A: Implement Ongoing Changes

In addition to being essential for improving the quality of your team’s work, continuous improvement helps bolster overall organizational quality and outcomes for the organization. 
  • CI is one of the key principles of agile
  • Continuous improvement includes ongoing efforts to improve products, services or processes—both small, incremental improvements or large “breakthrough” improvements.
  • Continuous improvement is a business strategy that is developed at the organizational level for projects to adopt and use. It may also be implemented by an organization’s project management office (PMO).
  • The Institute of Quality Assurance definition includes improving business strategy, business results and customer, employee and supplier relationships.
Supporting the team’s performance also extends beyond the measurement tools and feedback forums and methods. Gather lessons learned constantly and/or at set times throughout the project. Apply that learning into supporting actions to improve the performance and project environment.
  • You should make sure that both lessons learned and retrospectives are being taken seriously on the team. Both are indicators of a healthy CI program.
Conduct Retrospectives
  • To keep the team performing at its best, it’s essential to continually check in on performance.
  • Retrospectives are the most important practice for gathering lessons learned from the team on how to improve and recognize success. Retrospectives occur after every iteration and at the end of every project. But they should be done properly to get the full benefit. 
  • Conducting a retrospective encourages the team to review what went well and what could have been done better. This assessment includes the work on the product, but also the processes, team dynamics and other areas that influence the effectiveness of the team.
Update processes and standards
The information from lessons learned or retrospectives at the project level can apply to the organization’s continuous improvement process, in addition to the project management processes. Escalate these lessons and evaluate them for consideration at the organizational level.
Lead with an improvement mindset

The point of CI is to keep reflecting and improving. 

Be a servant leader with others on the team:

  • Educate yourself in the contributions of notable quality theorists, including: Juran, Deming, Taguchi, Crosby and Smith
  • Encourage your team to adopt a “fail fast” mindset
  • Identify and requisition material improvements such as training, processes, hardware or equipment
  • Finally, measure the effect of any change
  • Then repeat!

Support Project Team Performance: Topic B – Support Performance

Supported team members perform better and are motivated to do their best work. You’ll need strategies to maintain support to individuals as well as the whole team. To support the project team in completing its work, you need to focus on three things:
  • Communicating the project’s objectives
  • Ensuring a fluid, healthy team environment at all times (corresponds to project management principle D)
  • Keeping the focus on delivering value (corresponds to project management principle J).
Teams are typically more productive and driven when they have clear objectives to meet. Project professionals can support the team by setting objectives collaboratively with the team.
  • Project managers and the team can determine joint objectives that are challenging, yet attainable.
  • Objective setting can be conducted at the start of a project or phase, but is commonly done throughout the project life cycle, such as in an iteration planning session in which the team sets the goals and commitments for the upcoming time period.
  • Tolerance is a quantified description of acceptable variation for a quality requirement. It applies to budget, time, quality and nonfunctional requirements.
  • With established tolerances for a project — areas within the  purview of the project manager — project managers can effectively manage certain issues and control the project without having to escalate to the project board for review and approval, for example: Project A has set a tolerance so the project manager can control issues with a budget or time variance of less than 5% but be required to escalate any variances that exceed that threshold.
Project Manager’s role in a centralized model
  • In predictive life cycles with a strong centralized model, project managers can be responsible for combining all the project planning and keeping the plans cohesive and updated throughout the project life cycle. 
  • They steer the team toward successful project outcomes.
  • This is a centralized model of supporting project performance and really is only found in predictive approaches.
  • Nevertheless, this list provides an overview of tasks that need to be completed — if not by a project manager, then someone on the team!

Feedback is crucial communication, and it should be done regularly, and in both directions — giving and receiving. Asking for feedback from your team means they know you are willing to listen to them.

Support Team Task Accountability
  • Promote accountability by empowering people to take responsibility for work. Effective project leaders empower team members. In agile teams, team members “self-organize” so they can determine the work that must be done in order to meet an objective, to identify how to perform that work and who should perform it.
  • Focus on visibility and collaboration by using task boards.
  • It is critical to have visibility on who is performing which tasks and when, to ensure effective collaboration and use of team resources. This may be tracked and managed as part of a large project schedule or, more simply, on team task boards that facilitate collaboration and promote visibility across the team.
Clearly communicate the roles and responsibilities
  • As we know, self-organizing teams made up of generalizing specialists and T-shaped team members are trusted to find their way and figure out who is doing what on the team. 
  • In predictive or hybrid project teams, project managers will assign or facilitate assignment of roles and responsibilities. 
  • A responsibility assignment matrix such as a RACI chart is the most common way of documenting roles and responsibilities on any kind of team.
  • This makes task accountability visible.
Curate Knowledge as an asset

Focusing on knowledge as a team asset is fundamental to supporting the team, but it can often be overlooked. 

Knowledge can be divided into two main types: explicit and tacit.

 Explicit knowledge: Can be codified using symbols such as words, numbers and pictures.

  • Tacit knowledge: Is personal knowledge that can be difficult to articulate and share such as beliefs, experience and insights.
  • You need to know how to manage both types of knowledge to take advantage of the knowledge, skills and experiences of the project team.
  • Although collecting and gathering explicit knowledge is relatively easy to do, there is the risk of capturing only the facts and not the context surrounding the facts. Both are important to know.
  • To manage tacit knowledge, you’ll need to create and maintain trust among those involved in the project, so they are willing to share their experiences with everyone else. By obtaining those personalized experiences of the project, the team can more fully understand and leverage the knowledge.
  • Knowledge transfer consists of connecting individuals, in person or virtually, to share tacit knowledge and collaborate.

Incorporate knowledge transfer opportunities

  • Keep your team invigorated about learning. 
  • Knowledge transfer opportunities can be among the most exciting moments for people in workplaces.
  • Communities of practice add a social dimension to learning and generate forums of expertise, new thinking and collaboration. These can be internal or external to organizations. And PMI chapters are home to many of these kinds of communities!
  • Work shadowing is fast becoming the way to transfer tacit knowledge, through practical hands-on communication. 

Support Project Team Performance- Topic C: Evaluate Project Progress

During planning, metrics, baselines, and thresholds, including test/evaluation procedures were established. Now it’s time to measure the variances of actual performance against those measures and evaluate project progress. While agile teams do not create many reports, they can opt for a hybrid reporting method to generate this more formal data output. Even if teams are empowered to use agile methods and processes, here are some contexts that might require formal reporting:
  • Highly regulated industry
  • Cultural context uses formal reports
  • A stakeholder or stakeholder group requires detailed or a formal approach
Monitor Scope
Compare scope criteria and progress evaluation method according to life cycle or development approach. 
  • In projects that use a predictive life cycle or development approach, the project manager relies on the approved scope statement, the WBS and the WBS dictionary to define the scope. 
    • Teams then measure completion against the scope baseline.
  • In adaptive projects, scope evolves from the initial product roadmap to items in a release backlog, which are further broken down into iteration backlogs. 
    • Teams continuously check user stories and the definition of done (DoD) against customer feedback and product requirements.
Scope Validation The scope is validated when the customer accepts the deliverables. The term comes from the predictive process, validate scope, but the meaning is the same in adaptive life cycles. The success criteria, determined by the customer (needs and wants) and the team (product requirements) must be in place and the team establishes a definition of ready, a definition of done, iteration reviews wherein the team and customer inspect the product, and the final acceptance criteria.
Measure Schedule Performance
There are various ways to track performance across projects. Except for the Gantt chart, which is typically used only in predictive settings, these methods of tracking performance show how the team is working compared with a baseline or an expectation and can be used in any project life cycle. In agile approaches, progress  is evaluated by comparing the total amount of work delivered and accepted with the estimate of the work to be completed for the current time period.
  • Review the completed work in the regular sprint demos.
  • Conduct scheduled reviews to record lessons learned (also known as retrospectives) for correcting and improving processes.
  • Determine the rate at which deliverables are produced, validated, and accepted in the given time per iteration.
Visualize Performance
  • Track performance and render visualizations as a powerful way of showing work contributions.
  • Reporting and displaying team progress and accomplishments is extremely important to keep the team motivated, but also for communicating to others about the work of the team.
  • Boards are used in most adaptive methods and vary by the detail included:
    • Throughput, cycle time, and lead time are more often used in a continuous flow approach
    • Velocity is the measurement used in time-boxed methods
Burndown charts, burn-up charts and task boards are key to visualizing performance.
Estimate Velocity on Agile projects
  • It’s useful to be able to estimate how much work a team can complete during a time boxed iteration.
  • Velocity may vary at the beginning of a project but should be consistent as iterations are completed.
  • Calculated by estimating the number of story points that can be completed during an iteration.
  • Velocity will be modified as additional iterations refine the number of story points delivered.
  • Goal is to achieve a constant velocity from one iteration to the next
Velocity is a unique metric to a project. It can’t be used to compare one team with another. Earned Value Management (EVM) is a technique favored by project managers and project teams to measure project progress by comparing actual schedule and cost performance against planned performance   as laid out in the schedule and cost baselines.
  • EVM can be used in any life cycle or development approach, but the next few slides show the application in predictive approaches. 
EVM Variables:
EVM involves determining three independent variables to assess and monitor project cost and schedule performance progress. These three variables are used to provide measures  of whether work is being accomplished as planned and  to forecast project cost at completion. The variables are:
  • Planned Value (PV):
    the authorized budget assigned to scheduled work. This amount is specified in the project’s cost baseline. In simpler terms, PV indicates the value of work scheduled to be done during a particular time period.
  • Earned Value (EV):
    the measure of work performed expressed in terms of the budget authorized for that work. In other words, EV is a composite measurement of both cost and time performance in relation to scheduled or planned cost and time performance.
    • EV is calculated by multiplying the percentage of work completed by the budgeted cost for the activity as laid out in the cost baseline.
      • Earned Value (EV) = % completed x Planned Value (PV)
  • Actual Cost (AC)
    : the realized cost incurred for the work performed on an activity during a specific time period. AC refers to the total amount of costs incurred while performing  work, either during completion of a scheduled activity or during the completion of a WBS component.
The most used EVM measures for schedule control  are: Schedule Variance (SV) is a measure of schedule performance expressed as the difference between the earned value and the planned value. (SV = EV – PV)
  • Positive SV indicates project ahead of schedule
  • Zero SV indicates project is on schedule
  • Negative SV indicates project is behind schedule
Schedule Performance Index (SPI) is a measure of schedule efficiency expressed as the ratio of earned value to planned value. (SPI = EV / PV)
  • SPI greater than 1.0 indicates project ahead of schedule
  • SPI = 1.0 indicates project is on schedule
  • SPI less than 1.0 indicates project behind schedule
The most used EVM measures for cost control are:
Cost Variance (CV):
The amount of budget deficit or surplus at a given point in time, expressed as the difference between the earned value and the actual cost.  (CV = EV – AC)
  • Positive CV indicates project is below budget
  • Zero CV indicates project is on budget
  • Negative CV indicates that the project is over budget.
Cost Performance Index:
measure of the cost efficiency of budgeted resources expressed as the ratio of EV to AC.
  • An CPI number greater than 1.0 indicates a project is under budget.
  • An CPI of 1.0 means the project is on budget.
  • An CPI number less than 1.0 indicates a project is over budget

Support Project Team Performance- Topic D: Manage Project Issues and Impediments

Change is inevitable, but it is rarely insurmountable. Let’s look at strategies, tools, and techniques for managing project changes! Obstacle or impediment removal. Since it is the project team who generates the majority of business value, a critical role for the servant leader is to maximize delivery by removing impediments to their progress. This includes solving problems and removing obstacles that may be hampering the project team’s work. By solving or easing these impediments, the project team can deliver value to the business faster. Although the action of problem-solving is “project agnostic,” (a term used in PMI Certification to mean applicable to any kind of project team or development approach), the terminology used to resolve problems tend to be called by unique names between predictive and adaptive teams.
  • Predictive teams use an Issue Log.
  • Adaptive teams tend to use an Impediment Log. This is likely related to the wide adoption of Scrum methods in Agile teams. 
Risks and Issues
  • A risk is generally defined as an event that might impact a project.
  • An issue is a risk that has happened and will impact the project.
  • An issue can also just happen, without a known risk being present – these kinds of issues arise from unknown factors, or “unfathomable uncertainty”. (See below*.)
Example:
Risk: A supplier might go on strike.
Issue: A supplier has gone on strike. Agile teams using Scrum methods will approach problems in this way.
  • Discovery is the first step.
  • Next is solving it.
  • The scrum master is responsible for removing the impediment and to find consensus wherever it is needed.
  • Scrum takes a “bigger picture” view of solving from the organizational goals and strategy point of view, bringing any rift into alignment using commonly held goals.
  • As they say, “strive for global optimization and not for local optimization, which is suboptimal for the whole.”

Support Project Team Performance- Topic E: Manage Project Change

A change in a project can come from anywhere, internal to the project, from the organization. A change is something that changes one of the baselines or measures The project’s attitude towards change depends on life cycle and development approach.
  • Predictive life cycles and development approaches control change to a project in a methodical way.
  • Adaptive life cycles and development approaches incorporate and expect change to be a part of normal work.
Causes of Project Changes
  • Inaccurate initial estimates: These arise from lack of experience, lack of information, or precedence, inaccurate data, excessive optimism, technological difficulties, and unreliable resources. Getting those original estimates to be as realistic and accurate as possible — if possible — makes the control process more manageable.
  • Specification changes: Project work can open new avenues of development and design that were not considered during the initial planning of the project work and scope. As new options for a product or service become apparent, customers, sponsors or the project manager may broaden the project scope to include new specifications and deliverables.
  • New regulations: As project work progresses, new governmental or industry-specific regulations may be enacted. This can be especially true for lengthy projects. If the new regulations are related to the ongoing project, project change becomes necessary. Accommodating new regulations or legislation can also mean revisiting the planning process to determine the effect the new regulations will have on resource needs, schedule durations and quality specifications.
  • Missed requirements: Many times, the requirements are understood by reviewing the documentation and interviewing the end users and policy makers.
    • However, there are times when complete and comprehensive understanding may not be possible:
    • The interviewer feels that he/she has understood the point, and the interviewee feels that he has expressed all that matters.
    • Although a requirements traceability matrix (RTM) is prepared, the same confusion might arise in a written document.
    • Prototyping is used where a demonstration of functional and/or technical requirements is done. Although all these techniques reduce the chances of missing any requirements, it cannot guarantee that every requirement is captured.
How do we manage change?
Let’s start from the bigger picture. If changes are taking place in business environment systems, it is likely they will influence what is happening in your project.  This includes things like the cost or availability of goods and resources, timings in the context of national or cultural holidays and events, even natural disasters.  Project teams need to operate with an appropriate level of awareness of what’s happening outside of the project in order to be able to handle potential impacts. Use the frameworks to continuously explore what is happening outside of your project:
  • PESTLE (political, economic, social, technical, legal, environmental)
  • TECOP (technical, environmental, commercial, operational, political)
  • VUCA (volatility, uncertainty, complexity, ambiguity)
How to Manage Change?
While predictive approaches aim to determine the bulk of the requirements up front and control changes through a change request process, adaptive approaches were created to explore feasibility in short cycles and quickly adapt based on evaluation and feedback. While you should understand the overview of each by now, let’s take a moment to discuss the “controls.” These are the interventions by project practitioners to guide or contain change so that it is manageable. Of course, our predictive processes are made for this job.
  • Use of the perform integrated change control process, the change request process, a change control board are the controls, and maintaining the project artifacts ensure change is managed.
Adaptive life cycles and approaches also have controls for change though. It is a myth that agile teams are a free-for-all and “anything goes.” There are some experimental and developmental aspects, yes, but these are still contained within a development approach with checks or “guardrails.” The key ones are:
  • The product owner role – this individual is the key decision maker for changes on the team.
  • Full participation is enabled by allowing everyone on the team to participate in refining the backlog. Everyone has a voice.
  • To ensure everyone understands requirements, teams can hold a demo. Key customer and user stakeholders, the product owner and the team can review the demo and provide feedback to ensure the changes work as intended and do not impact the workflow of the solution. This early feedback allows for adaptation, while the feedback is immediately relevant and should improve the quality of the change while reducing overall cost and risk.
  • Finally, and very importantly, iteration or sprints are closed cycles. No changes are allowed during a sprint.
Types of Change Request
The four types of change requests are: Corrective action 
  • Adjusts the performance of the project work with the project management plan
Preventive action 
  • Ensures future performance of the project work with the project management plan
Defect repair 
  • Modifies a nonconformance within the project
Scope change
  • Modifies a project baseline
Change Control Systems

An effective change control system includes the forms, tracking methods, processes, and approval levels required for authorizing or rejecting requested changes.
One approval level may be the Change control board (CCB) which handles some change requests based on the approval levels documented in the change management plan.

Manage Contract Changes

These problems are treated somewhat separately, as they are likely to be a shared responsibility with the organization—including procurement, finance and/or a functional department.

Contract Change Control System
This is the system used to collect, track, adjudicate, and communicate changes to a contract. It:
  • Might be a component of the integrated change control  system or a separate system (organizational).
  • Specifically dedicated to control contract changes.
  • Specifies the process by which project contract changes can be made.
  • Includes the documentation, dispute-resolution processes, and approval levels to authorize the changes to contract specifications.
Claims Administration
  • Claims administration is a procedure used to settle contract disputes.  
  • It includes the processing, adjudicating (deciding) and communicating any claims that are made against the contract. 
  • These can be the result of changes that are being contested, including potential constructive changes. 
  • The disagreement could be the result of the two parties being unable to agree on the compensation to cover the change, or unable to agree that a change occurred.
  • These can also be known as claims, disputes or appeals.
  • If these cannot be resolved in a timely manner, they are often referred to and handled through alternative dispute resolution (or ADR), which has been defined as part of the contract terms.
  • Settlement of any contract disagreements through negotiation is preferred over ADR.
Legal Concepts when managing disputes
When a change leads to a dispute, you’ll need to seek legal advice to ensure the terms of the contract are observed.  Remember to use your negotiation skills to reach a final, equitable settlement of all issues, claims, and disputes. Briefly, here are the legal concepts you should know, as they  relate to contracts:
  • Warranty – This is the promise, explicit or implied, that goods or services will meet a predetermined standard. The standard may cover reliability, fitness  for use, and safety.
  • Waiver – A legally binding provision in which one party in a contract agrees to forfeit a claim without the other party becoming liable, even inadvertently. 
  • Breach of Contract – Failure to meet some or all the obligations of a contract. It may result in damages paid to the injured party, litigation, or other ramifications.
  • Cease and Desist Letter – A letter sent to an individual or a business to stop (cease) allegedly illegal activities and to not undertake them again (desist). Often used  as a warning of impending legal action if it is ignored.
Related Articles
Share your love
Education Edge
Education Edge
Articles: 265

Leave a Reply

Your email address will not be published. Required fields are marked *