Managing Project Teams (MANCOSA Elective) Summaries — Project Team Leadership, Communication, and Performance Management (MNG 0001 / MPM 305 / PMP-Style Notes)

Managing project teams is one of the most practical, exam-relevant competencies in project management: it combines leadership, planning, communication, conflict management, motivation, and performance control. In the MANCOSA elective context (often aligned with project management and team leadership outcomes), the focus is on how teams are formed, directed, supported, and measured so that project goals are achieved efficiently and ethically. This study guide consolidates core concepts, tools, and common exam themes into a cohesive set of notes you can apply to scenarios typically used in MANCOSA, Unisa, and CUT-style assessments.

1) Project Team Fundamentals in MANCOSA & Allied PM Modules (What “Managing” Really Means)

1.1 Understanding the “project team” vs the “project stakeholders”

A common exam pitfall is confusing the project team with stakeholders. A project team is the set of people who carry out the project work and are responsible for producing deliverables (or enabling activities like analysis, engineering, coding, training, procurement, and implementation). Stakeholders are anyone who affects the project or is affected by it—this includes sponsor(s), customers, users, suppliers, regulators, and community groups.

Key distinction (exam-friendly):

• Team members: do the work; manage tasks; deliver outputs.
• Stakeholders: influence expectations, resources, approvals, and acceptance criteria; need communication and engagement.

In scenario questions, when learners are asked “Who should be involved in developing the WBS/work plan?” the answer usually points to the project team and subject matter experts, not all stakeholders. Stakeholders may be consulted, but they are not always the people executing detailed task breakdown.

1.2 Team roles and responsibility clarity (RACI in team management)

Managing project teams begins with clarity of roles. Even when teams are technically skilled, projects fail when accountability is vague.

A widely used tool is RACI:

• R = Responsible (does the work)
• A = Accountable (ultimate owner/approval)
• C = Consulted (two-way input)
• I = Informed (one-way updates)

Practical example (consistent, scenario-based):
A project to implement a new student registration system in a university environment might involve:

• Registrar’s office (process ownership)
• IT developers (technical build)
• Data migration specialists (data cleansing/mapping)
• Quality assurance (testing)
• Operations/Training team (change management)

A typical question might ask: “Who is accountable for approving the training materials?” The likely answer is the Operations/Training team lead (Accountable), with project manager often being accountable for overall project approvals and deadlines, and various stakeholders consulted on content accuracy.

Why this matters:
RACI reduces conflict, minimizes rework, and supports performance evaluation—because if “everyone is responsible,” then nobody is accountable, and performance reviews become unfair.

1.3 Team formation approaches: functional, matrix, and project-based structures

Team structure strongly influences how management is performed.

1. Functional structure
   People report to functional managers (e.g., head of IT, head of finance). The project manager may have limited authority.
2. Matrix structure
   People report to both functional manager and project manager. Authority varies by matrix type:
   • Weak matrix: functional managers dominate
   • Balanced matrix: shared authority
   • Strong matrix: project manager dominates
3. Projectized structure
   Team members report mainly to the project manager. Control and coordination are usually easier.

Exam angle:
When asked “Why is it difficult to control schedules in a weak matrix?” the answer is tied to the dual reporting lines and potential resource priority conflicts.

1.4 Norms, team culture, and psychological safety

Modern project management emphasizes not only “process,” but also team climate. Team culture influences:

• willingness to raise risks early
• how openly issues are discussed
• speed of decision-making
• how conflicts are resolved

Psychological safety (team members feel safe to speak up) is especially important when:

• requirements are unclear
• technical uncertainty is high
• deadlines are tight

A practical classroom-style scenario:
If a team member discovers a requirement error but fears blame, they may hide the issue until late. Psychological safety encourages earlier escalation, which reduces rework.

1.5 Leadership competencies: directing, coaching, and enabling

Project team management uses three overlapping leadership behaviors:

1. Directing: clarify tasks, priorities, deadlines, and expected outputs.
2. Coaching: support capability building, provide feedback, and encourage improvement.
3. Enabling: remove barriers, ensure resources are available, and support collaboration.

In exam questions, if a project manager provides only instructions without removing obstacles or addressing performance gaps, the team may comply but productivity declines. If a project manager only coaches without clarifying deliverables and decisions, execution stalls. The best answers show balanced leadership.

1.6 Basic HR planning for project teams: roles, skills, and availability

In the early phase, project managers develop:

• resource requirements: skills, estimated hours, timing
• availability constraints: vacations, other assignments, recruitment lead times
• training needs: gap between required skills and existing competencies
• engagement plan: when resources join and exit the team

Even at a summary level, exam questions often expect you to connect resource planning to performance:

• if critical roles are missing, the team cannot deliver
• if resources are over-allocated, quality suffers
• if training is delayed, deliverables slip

1.7 Typical exam-style themes and how to answer

MANCOSA-style summaries often reward structured, theory-to-scenario reasoning. Common themes include:

• selecting the correct tool (e.g., RACI vs stakeholder register)
• diagnosing causes (e.g., conflict due to unclear scope vs lack of motivation)
• choosing the right intervention (e.g., coaching vs escalation)

High-scoring pattern:
Use a “problem → cause → management action → expected impact” structure.

Example:
Problem: missed milestone.
Cause: unclear acceptance criteria.
Action: hold a requirements/acceptance workshop and update acceptance criteria, responsibilities, and communication plan.
Impact: fewer rework loops, smoother approvals.

2) Planning and Directing Project Teams (Work Allocation, Agreements, and Communication Structures)

2.1 Work allocation through WBS, task descriptions, and acceptance criteria

A project team can only perform well if work is well-defined. Two connected mechanisms are:

• Work Breakdown Structure (WBS): breaks the project into manageable deliverables and work packages.
• Task descriptions and acceptance criteria: define what “done” means for each work package.

Acceptance criteria are often where projects fail. If they are not explicit:

• deliverables may technically be completed but not accepted
• stakeholders reject outputs late
• teams rework, causing schedule and budget overruns

Mini-case scenario (typical exam scenario):
A team develops a “module” for a learning platform. The sponsor says, “It must support reporting,” but does not specify:

• which reports
• frequency (daily/weekly)
• export format (CSV/PDF)
• user roles permitted

When the module is delivered with limited reporting, the sponsor rejects it. A high-scoring answer would recommend:

1. clarifying acceptance criteria early,
2. documenting them in the project plan and requirements,
3. assigning accountability for approvals (RACI),
4. scheduling review checkpoints.

2.2 Human resource planning: skills matrix and competence-based assignment

Effective project team planning goes beyond headcount. It considers competence fit:

• relevant technical skills
• experience with similar deliverables
• ability to work in the project environment (collaboration, reporting discipline)
• understanding of quality and risk processes

A practical method is a skills matrix, mapping tasks/work packages to required competencies and available team members. For exam purposes, you can describe the matrix concept and how it supports:

• appropriate task allocation
• reduced training costs
• fewer errors and rework

Skills matrix example (illustrative):

• Data migration work package requires: mapping skills, validation skills, knowledge of database tools.
• Training package requires: instructional design skills, facilitation skills.

If a team member lacks migration validation experience, the project may need:

• pairing with an experienced specialist
• targeted training before go-live
• additional quality checks

2.3 Team charter and working agreements

A team charter is an agreement describing:

• purpose and goals
• roles and responsibilities (often aligned with RACI)
• team operating norms (meeting cadence, decision-making rules)
• communication expectations (where updates are posted, response times)
• escalation routes for risks and conflicts

Working agreements are especially valuable when:

• the team is distributed (remote collaboration)
• multiple functional groups collaborate (matrix environment)
• team members are temporary or shared across projects

Exam-ready content to include:

• decision-making approach (e.g., consensus with sponsor approval for major scope changes)
• meeting schedule and outputs (agenda, minutes, action lists)
• confidentiality rules and document control

2.4 Communication planning: channels, frequency, and message purpose

Communication planning transforms “we will communicate” into a real management system.

A useful breakdown:

1. Communication requirements: who needs what information and why
2. Information distribution: how messages are sent (email, meetings, dashboards)
3. Frequency: weekly status, bi-weekly risk review, monthly steering committee
4. Ownership: who sends, who approves, who records
5. Feedback mechanisms: Q&A, review meetings, sign-offs

Common tools:

• Communication management plan
• Stakeholder register
• Issue log and risk register
• Meeting minutes and action registers

Why “message purpose” matters:
Sometimes stakeholders are overwhelmed with irrelevant detail. For example:

• operational managers may need detailed defect metrics,
• sponsors need progress against milestones and major variances.

High-scoring answers tailor message depth to stakeholder needs.

2.5 Meeting management: effective cadence and artifacts

Project teams frequently use recurring meetings. The key is to define:

• purpose,
• attendees,
• agenda structure,
• required outputs.

Common meetings:

• Kick-off meeting: align on scope, roles, risks, initial plan.
• Daily/stand-up (for agile teams): obstacles and next steps.
• Weekly project review: progress vs plan, risks, action items.
• Technical/design review: validate architecture decisions.
• Steering committee: strategic decisions and escalations.

Artifact emphasis (common exam marker):

• agenda must be prepared
• decisions must be documented
• action items must have owners and due dates

2.6 Conflict and negotiation within team management

Conflict is not always negative; it can be productive if managed properly. Project teams experience conflict due to:

• scope disagreements
• priority clashes (resource competition)
• communication breakdowns
• personality and value differences
• technical uncertainty

A project manager’s interventions can include:

• clarifying requirements and acceptance criteria
• renegotiating scope trade-offs (time, cost, scope)
• mediation between functional managers
• using decision rules from the team charter

Counter-argument to memorize (often appears in exam answers):
Some learners propose “avoid conflict.” However, conflict avoidance can hide risks and delay problem resolution. The better approach is:

• manage conflict constructively,
• address root causes,
• maintain professional standards.

2.7 Motivation and empowerment: aligning team goals with project outcomes

Motivation influences performance and retention. Team motivation is supported by:

• meaningful work and clear objectives
• fairness in workload distribution
• recognition of achievements
• autonomy in how tasks are executed (within boundaries)
• supportive leadership and coaching

Exam scenario example:
If team members feel their contributions are ignored and only failures are reported, motivation drops. A strong answer includes:

• regular recognition,
• fair feedback cycles,
• opportunities for team input into planning,
• transparent performance metrics.

2.8 Performance agreements: milestones, deliverables, and quality gates

Performance management starts with measurable expectations:

• milestones (time-based checkpoints)
• deliverables (output-based expectations)
• quality gates (review standards before approval)

Quality gates might include:

• peer review before submission
• testing and validation before acceptance
• compliance checks before release

A performance agreement concept can be described as:

• “What success looks like”
• “How success will be measured”
• “When success is evaluated”
• “Who approves”

This ties directly to later performance tracking and corrective actions.

3) Monitoring, Controlling, and Supporting Project Teams (Performance, Risks, Issues, and Change)

3.1 Establishing baseline performance and tracking progress

Monitoring team performance requires reference points:

• scope baseline (what is included)
• schedule baseline (planned timing)
• cost baseline (planned budget)
• quality baseline (standards and acceptance criteria)
• risk baseline (priority and mitigation plans)

Even though these are project-level baselines, they directly affect team management decisions. For instance:

• schedule slippage may cause resource reallocation
• quality failures may require additional testing time
• risk increases may require more frequent reviews or training

In exam answers, link tracking activities to management actions.

3.2 Team reporting systems: status reports, dashboards, and metrics

Common team-level reporting:

• status updates: completed work, work planned, obstacles
• progress metrics: percent complete, milestone attainment, deliverables accepted
• quality metrics: defects, rework rate, test pass rates
• schedule metrics: variance against planned dates
• risk/issue status: changes in probability/impact and mitigation progress

Example of a coherent metrics approach:
If a development workstream shows a rising defect rate, the manager may:

• increase code review frequency,
• allocate additional QA support,
• adjust the timeline by updating baselines through formal change control if needed.

3.3 Handling issues vs risks (and using logs correctly)

An issue is a problem that already exists and needs action. A risk is a potential event with probability and impact.

A well-managed team uses:

• Issue log: action required now; includes owner and due date.
• Risk register: mitigation plans, triggers, owners.

Exam tip:
If a question asks, “What should the project team do when an issue is discovered?” the answer should mention documenting it in the issue log, assigning ownership, prioritizing based on impact, and implementing corrective actions.

If it asks, “What if a new potential event is identified?” then it belongs in the risk register with:

• updated probability/impact,
• mitigation and contingency plans,
• monitoring triggers.

3.4 Change management impact on team workload and morale

Change is inevitable, but unmanaged change destroys team performance.

Common change sources:

• stakeholder request
• regulation updates
• supplier delays
• technology changes
• lessons learned from earlier work packages

A team manager must translate change into:

• revised task schedules
• updated deliverable definitions
• new acceptance criteria if necessary
• communication updates to stakeholders and team members

Important consistency note (exam logic):
When scope changes, the project plan must reflect trade-offs. If time cannot change, then cost or scope may need adjustment, and acceptance criteria may require re-negotiation.

3.5 Coaching and feedback cycles: improving performance without blame

Constructive feedback supports learning and reduces rework. A coaching approach includes:

• specific observations (“the test plan lacked scenario X”)
• impact (“this caused late defects”)
• solution direction (“update test plan to include scenario X and run regression”)
• follow-up (“verify in next QA cycle”)

Avoid blame-only feedback. Blame may reduce psychological safety and cause hidden errors. High-performing team environments treat mistakes as signals for process improvement.

3.6 Managing underperformance: diagnosis before discipline

Underperformance is common in projects, especially when:

• tasks were unclear
• resources were overloaded
• dependencies failed
• team members lack competence
• motivation is low

A structured approach to underperformance management:

1. Diagnose the cause: skill gap, ambiguity, workload, dependency, or process issue.
2. Clarify expectations: revisit acceptance criteria and deliverables.
3. Provide support: coaching, training, peer assistance.
4. Adjust workload or timeline if the cause is structural.
5. Escalate if needed: if performance does not improve after support.

This approach is frequently rewarded in exams because it aligns with ethical leadership and sound management reasoning.

3.7 Managing performance in virtual and hybrid teams

Remote work introduces communication delays and coordination difficulties. Team management must therefore include:

• explicit communication schedules
• written documentation norms (minutes, decisions, requirements)
• collaboration tools and document control
• response-time expectations (e.g., “respond within 24 hours”)

A common scenario:
If urgent decisions are made in informal chats, others may not be aware. The correct management action is:

• document decisions in official project repositories,
• ensure action items are assigned and tracked.

3.8 Conflict resolution and escalation paths

Project teams must know how to escalate. A reasonable escalation structure:

• team-level discussion first (direct manager, workstream lead)
• cross-functional mediation (if functional managers are involved)
• sponsor/steering escalation for scope, budget, or major timeline decisions

The escalation path should be consistent with the team charter and stakeholder engagement plan.

Exam counter-argument to memorize:
“Escalate immediately” is not always correct. Premature escalation can bypass team learning and waste sponsor time. Escalate when:

• decision is beyond team authority,
• time-critical constraints require higher-level intervention,
• conflict blocks delivery.

3.9 Using retrospectives and lessons learned to improve team capability

To manage teams effectively over time, project managers use:

• retrospectives (especially in agile contexts)
• lessons learned sessions at phase boundaries
• continuous improvement updates to processes and templates

A retrospective should aim for:

• “what worked,”
• “what didn’t,”
• “what we will change next time,”
• and assignment of owners for improvement actions.

This supports maturity and reduces repeat failures.

4) Practical Tools and Templates for Team Management (What to Write in Exams and Assignments)

4.1 A “team management toolkit” mindset

Exams often test your ability to choose and describe tools. Below is a toolkit aligned to project team management. It’s written in a way that can be adapted into assignment answers.

Core tools you should confidently name and use

• RACI matrix (role clarity)
• Team charter (working agreements)
• Communication management plan (channels, frequency, purpose)
• Issue log and risk register (issue vs risk distinction)
• WBS and work package descriptions (definition of work)
• Acceptance criteria (definition of “done”)
• Status reports (progress tracking)
• Escalation matrix / escalation path (decision authority)
• Retrospectives and lessons learned (continuous improvement)

A high-scoring response typically includes:

• what the tool is,
• why it exists,
• how it is used,
• who it involves,
• what output it produces.

4.2 Example: Building a RACI for a project deliverable set

Consider a project to deliver a “training rollout”:
Deliverables:

1. Training needs analysis report
2. Training materials
3. Training delivery sessions
4. Post-training evaluation report

A simplified RACI:

• Training needs analysis report
  • R: Training analyst
  • A: Training lead
  • C: HR manager, Project manager
  • I: Sponsor
• Training materials
  • R: Instructional designer
  • A: Training lead
  • C: Subject matter experts
  • I: Sponsor
• Training delivery sessions
  • R: Facilitators
  • A: Training operations manager
  • C: Training lead, HR manager
  • I: Project manager and Sponsor (as per schedule)
• Post-training evaluation report
  • R: Evaluation analyst
  • A: Training lead
  • C: HR manager, Project manager
  • I: Sponsor

This kind of example demonstrates how role clarity prevents gaps like “who approves training readiness?” or “who validates evaluation methodology?”

4.3 Example: Communication plan for a 10-week project timeline

While project timelines vary, exam questions often reward you for showing a logical cadence. Here is an illustrative timeline approach for a 10-week project:

• Weekly team stand-up / project sync (Week 1 to Week 10)
  • Purpose: obstacles and immediate next steps
• Weekly progress report to sponsor (End of Week 1 to End of Week 10)
  • Purpose: milestone progress, major variances, top risks/issues
• Midpoint risk review (End of Week 5)
  • Purpose: update probability/impact and mitigation effectiveness
• End-phase acceptance review (End of Week 10)
  • Purpose: confirm deliverable acceptance criteria met

Even if your exam scenario differs, the structure (weekly operational cadence + milestone-based strategic checkpoints) is transferable.

4.4 Example: Issue log entry structure (and why it matters)

An issue log entry typically includes:

• Issue ID
• Description
• Category (schedule, scope, quality, resource, stakeholder)
• Owner
• Impact
• Priority (High/Medium/Low)
• Target resolution date
• Status (open, in progress, resolved)
• Resolution notes

Why it matters:
If learners provide narrative only (“We had an issue with supplier delays”), without ownership, priority, and due dates, the project cannot track performance or enforce accountability.

4.5 Example: Risk register entry structure (with probability and impact)

A risk register entry typically includes:

• Risk ID
• Risk description
• Probability (e.g., Low/Medium/High or numeric)
• Impact (e.g., schedule/cost/quality)
• Overall risk rating
• Mitigation plan
• Trigger/early warning indicator
• Contingency plan
• Risk owner
• Current status

Exam-friendly phrasing:
“Mitigation aims to reduce probability; contingency aims to reduce impact if risk materializes.”

4.6 Stakeholder engagement as team management support

Team performance is affected by stakeholder behavior. Tools for stakeholder engagement include:

• stakeholder analysis (power/interest mapping)
• engagement strategies (manage closely, keep satisfied, monitor, inform)
• scheduled consultation and sign-off meetings

Example scenario:
If users are not involved early, requirements may be wrong. That creates rework for the team. Better engagement supports faster acceptance and reduced conflict.

4.7 Quality assurance and team-based quality ownership

Quality is not just a QA department job; it’s a team responsibility supported by:

• checklists and review processes
• peer review before release
• test plan execution and documented results
• configuration management and document control

An exam answer may mention “quality gates.” You can strengthen it by specifying:

• who performs the gate review,
• what evidence is required,
• what happens if evidence is insufficient.

4.8 Templates you can describe in essays (without needing to draw them)

In written exams, you may be asked to “describe a communication plan” or “outline an issue log.” You can write:

• a bullet list of sections included in the plan/log,
• and one short example entry.

This approach often scores because markers can see you understand the structure.

4.9 Ethical team management and confidentiality

Team management has ethical dimensions:

• confidentiality of sensitive information
• fair treatment and non-discrimination
• transparent reporting (no “hide the truth” status updates)
• respecting intellectual property and document control

Ethical management supports trust—trust improves information flow, reducing hidden issues and late surprises.

5) Exam-Ready Integrated Case Studies (Team Leadership Under Pressure) — MNG 0001 / PM Modules + MANCOSA Elective Scenarios

5.1 Case Study A: Missed milestone due to unclear acceptance criteria

Scenario:
A project team is tasked with delivering a “basic reporting dashboard” by the end of Week 6. The sponsor says reporting is needed “for monitoring student performance,” but the acceptance criteria were not fully defined. By Week 6, the team delivers a dashboard with limited indicators. The sponsor rejects it and requires changes before acceptance.

Diagnose the problem (what caused it?):

1. Acceptance criteria were vague.
2. Stakeholder expectations were not translated into measurable requirements.
3. Accountability for acceptance sign-off may have been unclear in team agreements.

Team management actions (what should the project manager do?):

1. Convene a requirements/acceptance workshop with:
   • sponsor,
   • end users (or operations stakeholders),
   • business analysts,
   • technical lead,
   • QA.
2. Document acceptance criteria in measurable terms (examples):
   • indicator list (e.g., attendance rate, pass rate, module completion)
   • time windows (weekly/monthly)
   • export requirements (CSV/PDF)
3. Update RACI so approval and sign-off responsibilities are explicit.
4. Create a revised work plan/WBS for the remaining indicators.
5. Communicate updated plan to stakeholders and team using the communication plan cadence.

Expected outcome:
Fewer rework loops, clearer deliverable definition, improved team confidence, and faster acceptance decisions.

Exam-style evaluation points to include:

• Link actions to improved clarity and accountability.
• Mention how the team charter and acceptance criteria reduce conflict.
• Show why issue vs risk distinction matters (the rejection is an issue requiring corrective action).

5.2 Case Study B: Underperformance due to workload imbalance in a matrix organization

Scenario:
In a matrix structure, team members report to both functional managers and the project manager. During Weeks 3–4, the schedule slips. Several team members are working on parallel tasks for other projects. The project manager notices incomplete work packages and rising defect rates.

Diagnose root causes:

• Resource availability conflicts (functional priority).
• Lack of workload balancing.
• Possibly inadequate training or unclear task boundaries for new deliverables.

Actions to manage the team:

1. Review resource plan and current allocations across projects.
2. Use skills matrix to confirm competence fit for critical tasks.
3. Hold a coordination meeting with functional managers:
   • negotiate priority for project-critical work packages,
   • request temporary reallocation or protected time.
4. Adjust the schedule baselines using formal change control if necessary.
5. Apply coaching/feedback cycles:
   • identify why defects are increasing,
   • add peer review checkpoints and QA support.

Counter-argument to consider (and address in answers):

• “Just push the team harder” is not sustainable.
• Overwork reduces quality and increases turnover risk.
  A high-quality answer explains that workload balancing and prioritization are more effective than pressure.

5.3 Case Study C: Conflict between technical and operational teams

Scenario:
A technical team delivers a solution but operational teams report that it is hard to support in daily operations. The conflict escalates: technical claims the operational team didn’t provide requirements; operational claims technical ignored usability standards.

Root cause analysis:

• Requirement gaps (usability and operational constraints).
• Missing quality gates for operational readiness.
• Communication breakdown between teams.

Team management strategy:

1. Use a structured conflict resolution approach:
   • clarify expectations and acceptance criteria for operational readiness.
2. Create a joint review:
   • technical lead, operations lead, QA, and sponsor representative.
3. Update acceptance criteria to include usability and supportability measures:
   • documentation completeness
   • training coverage
   • monitoring/alerting requirements
4. Ensure RACI clarifies:
   • who is accountable for operational readiness sign-off.
5. Implement continuous feedback:
   • pilot the solution with real operations users.

Why this works:
It transforms conflict from blame into a requirements-and-quality problem that can be managed with clear artifacts.

5.4 Case Study D: Remote team delays due to decision-making in informal channels

Scenario:
A distributed team makes multiple decisions in informal messaging groups. Later, team members discover their tasks are based on outdated requirements. Rework increases and confidence drops.

Diagnosis:

• Decisions not recorded in official project repositories.
• Communication plan lacks clarity on:
  • where decisions are documented,
  • who communicates final changes,
  • expected response times.

Corrective actions:

1. Establish a “single source of truth” document repository.
2. Require that major decisions be documented with:
   • decision date,
   • decision owner,
   • rationale,
   • impact on schedule/scope/quality,
   • updated links to requirements.
3. Update the communication management plan:
   • meeting cadence for decision approvals,
   • distribution frequency of requirement updates.
4. Provide training for the team on document control process.

Expected improvement:
Reduced rework, improved team alignment, better tracking for performance reporting.

5.5 Case Study E: Handling a risk that becomes an issue

Scenario:
Early in a project, a risk was logged: “Supplier may delay delivery of key components.” Mitigation included checking supplier status weekly. By Week 4, the supplier misses the delivery date, turning the risk into an issue. The team is at risk of missing a Week 6 milestone.

Team management actions:

1. Update risk register status (risk materialized) and create an issue in the issue log.
2. Assign an issue owner and set a resolution target date.
3. Trigger mitigation actions:
   • request revised delivery schedule,
   • explore substitute parts (if allowed),
   • adjust sequencing of work packages to reduce dependency impact.
4. If timeline is impacted, initiate change control:
   • communicate updated schedule impact to sponsor,
   • propose trade-offs (scope or cost adjustments).
5. Maintain psychological safety and transparent reporting:
   • do not blame individuals for supplier delay,
   • focus on corrective action and lessons learned.

Key exam point:
Strong answers explicitly show the transformation from risk management to issue management.

5.6 Linking to MANCOSA elective expectations and assignment writing style

MANCOSA’s project management electives often test applied understanding rather than rote definitions. In assignments/exams, high grades usually come from:

• selecting relevant tools,
• linking them to the scenario cause,
• and explaining why the approach will improve outcomes.

A strong assignment structure for team management questions can be:

1. State the problem clearly (what happened? who is affected? what is the impact?)
2. Identify likely root causes (clarity, accountability, resources, communication, quality gates, motivation)
3. Apply specific tools (RACI, team charter, communication plan, issue log, risk register, acceptance criteria)
4. Recommend actions (who does what, by when, and how it will be measured)
5. Explain expected outcomes (reduced rework, improved schedule reliability, better acceptance)

5.7 University-aligned phrasing cues (South Africa exam language)

Learners in South Africa often encounter management writing expectations across modules such as:

• MNG 0001 (MANCOSA Project Management) type summaries,
• project leadership and team management outcomes in PM-oriented curricula,
• and related content in Unisa and CUT project management education where learners must demonstrate application, not only definitions.

When writing answers, it helps to include keywords commonly rewarded in such modules:

• stakeholder management
• team charter
• communication management plan
• RACI responsibility assignment
• issue and risk management
• quality gates
• change control
• performance monitoring
• conflict resolution
• lessons learned

These terms signal that the learner understands the standard project management toolkit used across curricula.

Concluding study checklist (quick revision for exams)

Before sitting your exam, ensure you can do the following without hesitation:

• Explain the difference between project team members and stakeholders, and identify who should be consulted vs who should execute.
• Create or describe a RACI for a deliverable and use it to justify accountability.
• Outline a communication management plan with appropriate cadence and message purpose.
• Distinguish issues vs risks, and describe what each log should contain.
• Demonstrate underperformance management with a diagnose → support → adjust/discipline logic.
• Apply acceptance criteria and quality gates to prevent late rework.
• Use case-study reasoning: problem → root cause → intervention → expected impact.

This integrated approach ensures your answers align with how MANCOSA elective questions typically assess team management competence: through structured application, tool selection, and clear management reasoning.