MAN 315 – Project Management & Systems Thinking (Rhodes) Study Guide

MAN 315 (Project Management & Systems Thinking) at Rhodes University sits at the intersection of structured project delivery and the ability to understand projects as systems—interacting parts, feedback loops, constraints, and human behaviour. This study guide is designed to help you answer exam-style questions that test both technical project management (scope, schedule, risk, cost, stakeholders) and systems thinking (causal loops, dynamic complexity, mental models, and intervention design). You’ll find concepts explained with exam-ready language, plus worked examples and practical checklists aligned with what South African university students commonly need for modules like MNG 0001 (common in Unisa-style curricula) and project management components found across UNISA, CUT, and other SA universities, while remaining specific to the Rhodes MAN 315 framing.

Rhodes University: MAN 315 Foundations — From Projects to Systems

What the Module Is Really Testing (Exam Mindset)

In MAN 315, marks often come from demonstrating that you can:

1. Define and structure a project: purpose, objectives, deliverables, constraints, stakeholders, governance.
2. Plan delivery realistically: work breakdown, scheduling logic, resource assumptions, budgeting approach, quality targets.
3. Manage uncertainty: risk identification, risk analysis, response planning, monitoring and review cycles.
4. Think systemically: understand how project decisions change relationships over time—especially through feedback loops, delays, and unintended consequences.

A typical exam prompt may ask you to:

• Compare “traditional” project management vs systems thinking.
• Explain why a project plan can fail even when activities are “well scheduled.”
• Recommend interventions using causal reasoning (e.g., “What lever would you pull to improve the situation?”).

Key exam phrasing you should be comfortable using:

• “The project exists inside a wider system (organizational, social, technical, regulatory).”
• “Certain outcomes are emergent—they result from interactions rather than single actions.”
• “Delays and feedback loops create non-linear effects; therefore, monitoring must track leading indicators, not only lagging ones.”

Projects as Systems: Core Systems Thinking Concepts

Systems thinking views a project as part of a larger system with interacting components. In exam answers, you want to clearly identify:

• System boundary: What is inside vs outside the project scope?
• Actors and stakeholders: who influences what?
• Resources and constraints: staffing, budgets, supply chain, procurement rules.
• Information flows: how decisions get made (meetings, reporting lines, dashboards).
• Feedback loops: how actions today affect conditions tomorrow.

Feedback Loops (Causal Loop Diagrams)

Two core loop types commonly appear:

1. Reinforcing loop (R): “growth/accumulation” dynamics

   • Example: If training improves competence, competence increases performance; better performance may increase confidence, leading to more training—faster capability development.

2. Balancing loop (B): “stabilizing/goal-seeking” dynamics

   • Example: If quality defects increase, corrective actions begin; corrective actions reduce defects; reduced defects lowers corrective pressure.

In a project context, many problems are balancing loops that become ineffective because of delay or poor information. Delays cause overshoot, oscillation, or chronic underperformance.

Delays: Why “Corrective Action” Can Be Too Late

A project plan may appear sensible until you account for:

• Lead time delays: materials procurement, vendor response times.
• Learning delays: training takes time to translate into performance.
• Approval delays: sign-offs and governance steps.

Exam-style takeaway:
If your reporting system reacts only after defects occur (lagging indicators), you might repeatedly “over-correct.” Systems thinking suggests using leading indicators (e.g., early quality signals, stakeholder satisfaction trends, defect rates in pilot phases).

Traditional Project Management vs Systems Thinking (Comparison)

You may be asked to contrast two approaches. A strong answer typically includes:

• Traditional PM emphasis:
  • Scope definition, schedule (critical path), budgeting, milestone control.
  • Often assumes causality is straightforward: do tasks → achieve outcomes.
• Systems thinking emphasis:
  • Complex causality: do tasks → change system behaviour through interactions.
  • Focus on feedback, system constraints, unintended consequences, and adaptive control.

A balanced exam response argues that systems thinking does not replace good PM. Instead, it improves the quality of assumptions and the design of control systems.

Rhodes-Style Practical Application: A Mini Case (Exam Scenario)

Consider a Rhodes university project (use-case similar to many SA university environments): a department wants to implement a new learning platform.

Project objective (simplified):

• Launch by end of Semester 2
• Train lecturers
• Migrate course content
• Ensure stable performance during assessment periods

A traditional PM plan may specify:

• Tasks, due dates, resources
• Milestones: “training complete,” “migration complete,” “go-live”
• Risk register

However, systems thinking highlights potential issues:

• Stakeholder behaviour loop: lecturers delay uploading content until they see peers do it.
• Resource constraint loop: helpdesk overload reduces support quality → lecturers lose confidence → more delays.
• Approval delay: IT security approvals take time, but training scheduled early creates pressure.

Exam link: you would conclude that schedule control alone won’t solve delays caused by stakeholder interaction and institutional procedures. Interventions might include:

• Create peer champion incentives
• Stage migration in pilot courses
• Use leading indicators (upload progress, helpdesk response times)
• Adjust training sequence to match readiness of course content

Building a Systems-Friendly Project Management Plan

A practical systems-thinking approach to project planning includes:

1. Identify system boundary
   • Include upstream constraints (procurement lead time, governance sign-offs, user readiness).
2. Map actors and incentives
   • What do stakeholders gain/lose if deadlines slip?
3. Identify feedback loops
   • Where does performance improve or degrade through interactions?
4. Add monitoring for leading indicators
   • Don’t only report “milestones hit”; track drivers like adoption rates, defect trends.
5. Plan adaptive governance
   • Create decision points where learning can change course.

Rhodes University: Project Planning, Governance, and Stakeholder Management (MAN 315 Core Delivery)

Project Definition: Scope, Objectives, and Success Criteria

Most project exam questions start with definition. You should be able to clearly distinguish:

• Project charter / project purpose: why it exists.
• Objectives: what outcomes are desired.
• Deliverables: tangible outputs.
• Success criteria: how success is judged (quality, time, cost, adoption, satisfaction).

Triple Constraint (Time–Cost–Scope) and Beyond

Traditional PM often uses the “triple constraint.” In exam answers, expand beyond it:

• Scope: what is included/excluded.
• Schedule: timeline and milestone achievement.
• Cost: budget allocation and control.
• Plus common extra “constraints” in real projects:
  • Quality
  • Risk tolerance
  • Compliance/regulatory requirements
  • Stakeholder acceptance/adoption

A common exam trap is to state “success is on time and on budget.” A stronger answer argues that success must also include fitness for use and stakeholder value.

Work Breakdown Structure (WBS) and Deliverable Logic

You may be tested on WBS structure and how it supports planning.

WBS should be deliverable-oriented, breaking the project into manageable components. In exam terms:

1. Start with major deliverables.
2. Break down into work packages.
3. Ensure each work package has:
   • Clear scope
   • Ownership
   • Expected inputs/outputs
   • Measurable completion criteria

Worked Example: WBS to Scheduling

Suppose your project has one deliverable: “Student Support Helpdesk System.”

Break into work packages:

• WP1: Requirements gathering
• WP2: Vendor selection
• WP3: Configuration and testing
• WP4: Training for support staff
• WP5: Go-live and stabilization

Then scheduling uses dependency logic:

• WP2 depends on WP1 (you need requirements before vendor selection)
• WP3 depends on WP2 and includes testing tasks
• WP4 depends on enough of WP3 being stable
• WP5 depends on WP4 completion and final testing readiness

Even if you don’t compute numbers in the exam, you can score well by explaining the logic: dependencies + resources + constraints.

Scheduling Fundamentals: Milestones, Dependencies, and Critical Path Logic

In many South African university exams, you are expected to understand:

• Milestones: significant events with measurable completion
• Dependencies:
  • Finish-to-start (FS)
  • Start-to-start (SS)
  • Finish-to-finish (FF)
  • Start-to-finish (SF)
• Critical path concept: activities with zero slack that determine project duration

You should be able to explain critical path simply:

• The chain of tasks that controls end date.
• Delays in critical path tasks delay the project unless re-planning occurs.

Systems Twist: When Critical Path Isn’t the Real Constraint

Systems thinking challenges the assumption that the critical path always reflects the main cause of delay.

Example:

• Schedule critical tasks may be ready, but stakeholders do not provide decisions due to workload.
• The project’s effective constraint becomes decision capacity, not engineering duration.

Thus, exam-level responses should mention:

• “We must identify constraints across the system, such as governance decision throughput.”

Project Governance: Roles, Decision Rights, and Control Loops

Governance answers often gain marks when you link governance to system behaviour.

Common governance elements:

• Steering committee: direction, escalations, major approvals.
• Project manager: day-to-day coordination.
• Project team / workstream leads: execution responsibility.
• Risk owner: accountable for mitigation actions.
• Change control board (CCB): approves scope changes.

Control Cycle: Plan–Do–Check–Act (P-D-C-A)

Even if you don’t use formal P-D-C-A in your syllabus, you should describe a similar logic:

1. Plan (baseline scope/schedule/cost)
2. Do (execute)
3. Check (monitor performance and compliance)
4. Act (correct course, re-baseline if needed)

Systems thinking improves control by:

• using learning loops (not just performance loops),
• correcting root causes rather than symptoms.

Stakeholder Management: Power–Interest and Engagement Strategy

Stakeholder questions are common. A strong answer includes:

• stakeholder identification,
• interest/power mapping,
• engagement planning,
• communication strategy.

Stakeholder Mapping

You can use a power–interest matrix categories:

• High power / high interest: manage closely
• High power / low interest: keep satisfied
• Low power / high interest: keep informed
• Low power / low interest: monitor

Communication Plan (Exam-Ready Elements)

A good communication plan includes:

• message content,
• channel (email, meetings, workshops),
• frequency,
• audience,
• feedback/response mechanism.

Systems thinking emphasizes:

• communication itself changes system behaviour,
• delays in communication create delays in decisions.

Worked Scenario: Stakeholder Misalignment Causing Rework

Consider a project to install new lab equipment at an academic department.

Stakeholders:

• lecturer users,
• maintenance staff,
• procurement office,
• HSE/compliance.

Traditional PM may focus on installation schedule. Systems thinking adds:

• HSE approval delays can occur because maintenance staff need training documentation.
• If training is not coordinated with procurement documents, compliance sign-off will not happen in time.
• This leads to rework: the equipment is installed early, but cannot be used until documentation is complete.

Exam answer: recommend an integrated workstream or “compliance readiness checklist” that runs in parallel with installation, not sequentially.

Rhodes University: Risk, Cost, Quality, and Change Control in a Systems Context

Risk Management: Identifying, Analyzing, Responding

Risk management often appears in exam questions with:

• risk identification,
• qualitative and/or quantitative analysis,
• mitigation and contingency planning,
• monitoring and review.

A strong answer structures risk management as:

1. Identify risks
2. Assess likelihood and impact
3. Plan responses
4. Implement risk controls
5. Monitor and update

Risk Register Essentials

A risk register typically includes:

• risk description
• cause
• event
• likelihood (L)
• impact (I)
• risk score (optional)
• owner
• response strategy
• triggers (early warning signs)
• contingency plan
• status

Systems Thinking: Turning “Risk” into “System Dynamics”

Many student answers treat risk as isolated events. Systems thinking asks you to examine:

• what generates the risk repeatedly,
• how a risk interacts with other factors,
• whether the risk is amplified by feedback loops.

Example: “Vendor delays procurement” is a risk event, but systems thinking looks for causes like:

• procurement process bottlenecks,
• unclear specifications causing vendor clarifications,
• lack of decision rights causing approvals to stall.

You can often score well by writing:

• “The risk is not only a probability; it is the symptom of underlying system constraints.”

Worked Example: Risk With a Feedback Loop

Scenario:

• A project relies on stakeholder sign-offs for design approvals.
• Sign-offs are delayed when stakeholders are busy during teaching periods.
• Delayed approvals cause rework because downstream work starts based on assumptions.

Feedback loop:

1. Busy teaching period → delayed sign-off
2. Delayed sign-off → assumption-based design progress
3. Assumption-based progress → mismatch with actual needs
4. Mismatch → rework request → further workload for stakeholders
5. More workload → even slower sign-offs

Systems-based intervention options:

• Adjust schedule around teaching peaks (shift milestones)
• Use “assumption review” checkpoints early
• Provide lightweight decision templates for faster sign-off
• Bring stakeholders into a co-design workshop to reduce rework

In an exam answer, emphasise that mitigation should break the loop, not just add contingency time.

Cost Management: Budgeting, Earned Value Logic, and Trade-offs

Cost management can be tested conceptually, even when calculations are not required. Be able to explain:

• baseline budget,
• cost estimates and forecasting,
• cost control mechanisms,
• approvals for spending.

Earned Value (EV) Concepts (If Covered)

If your coursework includes EV, core terms:

• Planned Value (PV): budgeted cost of planned work.
• Earned Value (EV): budgeted cost of completed work.
• Actual Cost (AC): actual cost spent.

Common derived metrics:

• Schedule Variance (SV) = EV − PV
• Cost Variance (CV) = EV − AC
• Cost Performance Index (CPI) = EV / AC
• Schedule Performance Index (SPI) = EV / PV

A systems twist: cost performance may look okay early while adoption or quality issues create later costs (e.g., rework, training deficits). Therefore, monitoring should include leading cost drivers, not only EV at milestone points.

Quality Management: Standards, Verification, Validation

Quality in projects is often confused with “inspection.” Quality management includes:

• quality planning,
• quality assurance (process compliance),
• quality control (verification of deliverables),
• documentation and acceptance criteria.

Verification vs Validation

• Verification: did we build the deliverable according to specification? (e.g., testing vs requirements)
• Validation: does it satisfy stakeholder needs and intended use? (e.g., user acceptance testing)

Systems thinking improves quality by recognizing that:

• user adoption affects whether the “deliverable” achieves outcomes.
• Training and support are part of quality of the system, not just of technical components.

Change Control: Scope Creep, Baselines, and Governance

Change management is frequently tested as a scenario.

A strong exam answer covers:

• why changes happen,
• how changes are assessed,
• what process controls them.

Common change process:

1. change request submitted,
2. impact assessment (scope/schedule/cost/quality/risk),
3. decision approval (CCB/steering),
4. update baselines,
5. communicate change and re-plan.

Systems Thinking: Why “Small Changes” Create Large Effects

Systems thinking says changes can have non-linear impacts via:

• dependencies,
• stakeholder expectations,
• resource constraints,
• feedback loop disruptions.

Example: adding a feature to a learning platform may increase:

• testing load,
• user training time,
• support demand,
• compliance documentation,
• integration complexity.

Thus, your exam answer should show you understand “change is not only a line item; it’s an interaction.”

Rhodes University: Systems Thinking Tools for Projects — Causal Loops, Modelling, and Practical Interventions

Causal Loop Diagrams (CLDs): How to Draw and Use Them

Causal loop diagrams express relationships:

• arrows indicate direction of influence,
• signs indicate positive or negative effect.

A positive relationship means:

• if A increases, B tends to increase.

A negative relationship means:

• if A increases, B tends to decrease.

You then identify loops:

• Reinforcing loop (same direction effects around the loop)
• Balancing loop (opposing effects around the loop)

Example CLD: Project Delays and Stakeholder Confidence

Variables:

• Project progress completion rate
• Stakeholder confidence
• Stakeholder support responsiveness
• Decision throughput
• Approval speed

Causal logic (simplified):

• If progress completion rate increases → stakeholder confidence increases (+)
• Higher confidence → more support responsiveness increases (+)
• Support responsiveness increases → decision throughput increases (+)
• Higher decision throughput → approval speed increases (+)
• Faster approvals → progress completion rate increases (+)

This forms a reinforcing loop. If the loop breaks (e.g., initial delays lower confidence), the system may get stuck in a cycle of slower support and more delays.

Exam approach:

• Explain “how a small initial delay can cascade.”
• Propose interventions to strengthen the reinforcing loop early (e.g., fast-track initial wins and provide transparent progress signals).

Modelling Complexity: Stock-and-Flow Thinking (Conceptual)

Some MAN 315 offerings use stock-and-flow reasoning. Even if your course doesn’t require modelling diagrams, you should understand the concept:

• Stocks: accumulations (e.g., “tasks pending approval”).
• Flows: rates that change stocks (e.g., “approval rate”).
• Dynamics come from the relationship between stocks and flows and feedback.

Example:

• Stock: “Unresolved issues”
• Flow: “Issue resolution rate”
• Another flow: “New issues created”
• Resolution rate may depend on team capacity and stakeholder availability.

Systems thinking helps identify when:

• increasing resolution capacity helps,
• but only after stakeholder decision throughput improves.

Mental Models and Learning: Why Projects Need Double-Loop Learning

Mental models are the internal assumptions people use to interpret problems. In project settings, typical mental models include:

• “If we plan better, delays will disappear.”
• “If we add more people, schedule issues will solve themselves.”
• “Risk registers prevent problems.”

Systems thinking suggests these assumptions can fail because:

• problems are caused by interactions,
• not just by lacking information.

Double-loop learning:

• single-loop: correct actions within existing assumptions
• double-loop: challenge the assumptions themselves

Exam response should include:

• what assumption is being challenged,
• what new approach results,
• how to test the improved assumption.

Intervention Design: Choosing Leverage Points

In systems thinking, you aim for the highest leverage intervention—where small changes produce large improvements.

Leverage points in projects can include:

1. Information flows: improve transparency, increase frequency of decision-making feedback.
2. Rules and governance: clarify decision rights, set escalation thresholds.
3. Incentives and stakeholder commitments: align motivations.
4. System structure: reduce dependency chains (parallelize workstreams).
5. Physical constraints/resources: improve capacity or procurement strategy.

Example: Fixing a “Communication Failure” Properly

A traditional response to stakeholder frustration is “send more emails.” Systems thinking asks:

• why are they frustrated?
• Is it late information, unclear decision criteria, or misaligned responsibilities?

If frustration is due to late decisions:

• more emails won’t change throughput.
• better intervention: create faster decision cycles, define acceptance criteria, and run pre-approval workshops.

Practical Systems Thinking Tools for Project Managers

Use these tools in exam answers as “appropriate interventions”:

1) Stakeholder Feedback Loops

• define what metrics track adoption, satisfaction, and friction,
• ensure feedback is reviewed regularly (weekly or bi-weekly),
• link feedback to decision mechanisms.

2) Causal Analysis of Root Causes

Instead of “root cause = lack of training,” do causal decomposition:

• Is training late due to procurement lead time?
• Is adoption low because support staff are unprepared?
• Is support backlog increasing because governance escalation is slow?

3) Scenario Planning and Assumption Testing

Projects are uncertain; scenario planning asks:

• what assumptions must hold,
• which assumptions are most risky,
• how you will test them early.

Example assumptions:

• “Lecturers will upload content by Week 4.”
  You test via:
• pilot courses,
• early “upload readiness” checkpoints,
• support capacity adjustments.

Worked Case: A Campus Sustainability Project With System Behaviour

Scenario (typical Rhodes/SA public-sector style):
A sustainability project introduces energy-saving measures across campus buildings. The project team plans:

• install smart meters,
• train facility managers,
• implement schedule-based HVAC adjustments.

After initial rollout:

• energy savings are inconsistent,
• complaints rise because comfort levels change,
• some buildings revert to old settings.

Systems thinking lens:

• Comfort complaints reduce stakeholder buy-in.
• Reduced buy-in lowers willingness to maintain new schedules.
• Maintenance backlog increases because staff are dealing with complaints.
• Increased backlog leads to reverting schedules, reducing savings.
• Reduced savings undermines confidence further, amplifying the cycle.

Interventions:

1. Feedback redesign: provide building-level dashboards and simple reporting on comfort + energy.
2. Stakeholder engagement: include facilities staff in co-design of schedules.
3. Training sequencing: train before full rollout, with practice in one building.
4. Governance rules: define escalation path for comfort issues with rapid response times.
5. Leading indicators: track complaint rate and adjustment completion rate early.

Exam conclusion:

• The project failed not because meters were faulty, but because the system’s feedback loops and incentives caused “reversion behaviour.”

Rhodes University: Integrated Exam Answer Frameworks — How to Score High in MAN 315

The “5-Layer” Structure for Strong Answers

When faced with an exam question, a high-scoring structure is to answer at five layers:

1. Purpose and context
   • what is the project trying to change and for whom?
2. Project delivery logic
   • scope, schedule, cost, quality, governance.
3. Risks and uncertainties
   • what could derail outcomes and why?
4. Systems dynamics
   • feedback loops, delays, constraints, mental models.
5. Intervention and learning
   • what should be done differently and how will you monitor whether it worked?

Using this template prevents shallow answers that only repeat PM vocabulary.

Common Exam Question Types (and What Markers Usually Look For)

1) “Explain the difference between project management and systems thinking.”

Markers look for:

• a clear definition of both,
• a concrete example where traditional PM misses system dynamics,
• an explanation of how systems thinking improves control and learning.

Good answer elements:

• mention feedback loops and delays,
• mention system boundaries,
• show you don’t reject PM—extend it.

2) “Discuss stakeholders and engagement strategy for a project.”

Markers look for:

• stakeholder mapping,
• engagement plan detail (frequency, channel, purpose),
• governance tie-in (decision rights and escalation).

Systems tie-in:

• communication delays cause decision delays,
• stakeholder incentives affect execution behaviour.

3) “Analyse project risk in a scenario.”

Markers look for:

• risk register logic,
• causes and triggers,
• mitigation actions linked to root causes,
• monitoring.

Systems tie-in:

• show whether risk is repeating due to feedback.

4) “Propose an intervention to solve a ‘project failure pattern.’”

Markers look for:

• leverage point identification,
• realistic sequencing,
• monitoring plan using leading indicators.

Mini-Rubric: Self-Check Before You Submit

Use this quick rubric to ensure your answer includes essential content:

• Definitions: did you define key terms (scope, baseline, feedback loop, stakeholder engagement)?
• Causal logic: did you explain why the problem happens (not just what happens)?
• Systems elements: did you mention delays/feedback/constraints/mental models?
• Actionability: did you propose interventions and explain expected effects?
• Monitoring: did you include how you’d know the intervention is working?

Worked Example: Turning a Poor Answer into an Excellent One

Poor answer (typical student response):

• “The project is delayed because of risk and stakeholders. We need better planning and more communication.”

Why it loses marks:

• vague causes,
• no systems dynamics,
• no measurable interventions,
• no monitoring detail.

Excellent answer should include:

• a specific causal story (e.g., delays → confidence loss → reduced stakeholder responsiveness → further delays),
• a systems tool (describe a reinforcing loop),
• intervention at a leverage point (e.g., governance decision throughput + leading indicators),
• monitoring plan (weekly “decision cycle time” and “approval readiness” metrics).

You can score well by explicitly linking “what you do” to “how behaviour changes.”

Quantitative Thinking Without Over-Calculation

Even when calculations are not demanded, exam questions may test quantitative reasoning:

• prioritization,
• time-cost trade-offs,
• “what happens if we reassign resources?”

For example, if you reduce schedule by adding resources (fast tracking), a systems answer notes:

• increased workload may reduce quality,
• stakeholder availability may become the bottleneck,
• communication overhead may grow.

So, your answer should show:

• awareness of secondary effects,
• risk of rework and compliance issues,
• need for leading indicators.

Integration With Broader SA University Concepts

Rhodes modules often align in theme with project management and leadership components students see across South African institutions. You’ll likely recognize terms such as:

• project governance,
• stakeholder management,
• risk registers,
• monitoring and control.

Where other universities may frame similar content under generic project management or management courses (for example, modules like MNG 0001 style foundational management or “project management fundamentals” in various programmes), MAN 315’s differentiation is the systems thinking requirement—you must consistently bring the “system behaviour” lens into your project decisions and explanations.

Exam Preparation Checklist (Practical, Rhodes-Relevant)

Use these study actions as a final revision routine:

1. Draw 3 causal loop diagrams from memory
   • delays + stakeholder confidence,
   • risk feedback + rework loop,
   • adoption feedback + support capacity loop
2. Write a one-page risk register template
   • ensure triggers and owners are included
3. Prepare 2 stakeholder engagement maps
   • one high power/high interest group,
   • one low power/high interest group
4. Practise one integrated scenario response
   • include: scope/schedule control + risk + system dynamics + intervention + monitoring
5. Create a “leading indicators list”
   • examples: decision cycle time, early defect trends, adoption usage counts, helpdesk response time

Conclusion: Mastering MAN 315 Through Systems-Aware Project Management

MAN 315 rewards answers that are not only correct, but also causally coherent and action-oriented. Strong exam performance comes from connecting project delivery mechanics—scope, schedule, cost, quality, governance—with systems thinking tools—feedback loops, delays, constraints, and mental models. When you explain not just “what to do,” but “why the system behaves that way,” your responses become clearer, more persuasive, and more grounded in realistic project environments.

If you consistently apply the layered answer framework—context → project logic → risk → systems dynamics → intervention and monitoring—you’ll be able to handle varied question formats while demonstrating the Rhodes-level understanding that MAN 315 is designed to assess.