Home Learning Paths ECU Lab Assessments Interview Preparation Arena Pricing Log In Sign Up

MAN.3 Purpose & Why It Fails Most

Official Purpose Statement: "The purpose of the Project Management Process is to identify, establish, coordinate, and monitor the activities, resources, and constraints of a project in order to produce a specified product, that satisfies the project's defined requirements within the specified constraints."

MAN.3 is the backbone of CL2. Every Generic Practice at CL2 (GP 2.1.1–2.1.6) requires project management discipline - process objectives, plans, monitoring, role assignments, and resource management. A project with excellent SWE.1–SWE.6 engineering but no documented project management will plateau at CL1 on all processes regardless of engineering quality.

📋 Learning Objectives

  • Produce a project plan that satisfies all MAN.3 Base Practice requirements
  • Operate status tracking that generates usable GP 2.1.3 evidence (actuals vs. plan)
  • Manage project scope, schedule, resources, and constraints with documented decision trails
  • Understand the difference between a decorative project plan and a managed project plan

MAN.3 Base Practices

BPNameWhat It RequiresEvidenceThe Assessor Test
BP1Define the scope of workProject scope is documented: what is in scope, what is explicitly out of scope, what are the deliverables, what are the acceptance criteria for the project as a whole. Scope changes are controlled through CR process.Project scope statement / SOW; project initiation document"What is in scope for this project?" - answer must be in a document, not verbal
BP2Define project life cycleThe development lifecycle is documented: phases (concept, development, proto delivery, series production), milestones, entry and exit criteria per phase, review gates. For Agile projects: sprint/PI structure, release cadence, definition of done.Project lifecycle description in project plan; phase/milestone table with dates"What are your project milestones and what must be true to pass each gate?" - must be in the plan
BP3Develop a project planThe project plan is the central MAN.3 artifact. Must contain: WBS (work breakdown structure) or equivalent task list, milestone schedule with dates, resource allocation (who does what, how many hours), effort estimates, dependencies between tasks, tool and infrastructure requirements. Plan is at enough detail to manage against weekly - not just high-level Gantt.Project plan (MS Project, Jira roadmap, or equivalent) with WBS + schedule + resource assignment"Show me how you planned the SWE.1 requirements engineering work - activities, schedule, who was assigned, how many hours estimated." If only a milestone is shown without activity-level breakdown, BP3 is partially achieved.
BP4Monitor the projectActual progress is tracked against the plan and documented. Status meetings held with documented minutes showing: actuals vs. planned (tasks completed, milestones hit/missed, effort burned vs. estimated), deviations identified, corrective actions decided and assigned. This is the most critical BP for GP 2.1.3 evidence.Status meeting minutes or project status reports with actuals vs. plan; action log with owner and due date"Show me a status meeting where you identified a deviation from plan and decided on a corrective action." If minutes exist but only say "reviewed project status - all OK" with no actuals, this is insufficient.
BP5Take corrective actionWhen deviations from plan are identified (BP4), corrective actions are documented, assigned to an owner, tracked to completion, and their effectiveness verified. Replanning when necessary - an updated project plan with revised dates is itself evidence of managed project management.Corrective action log or integrated in the issue tracker; updated project plan with revision history"Show me a corrective action that was logged, tracked, and closed." If no corrective actions ever existed, the project was either perfectly planned (impossible) or deviations were managed without documentation.
BP6Manage project closureProject closure is formal: deliverables accepted by customer, lessons learned documented, process improvement inputs fed into the organizational QMS (CL3 interface), project records archived and accessible.Project closure report; lessons learned log; customer acceptance recordLess frequently assessed in ongoing projects; key for final assessment at series production release

The Decorative Plan vs. The Managed Plan

The single most common MAN.3 finding: the project plan exists and is detailed, but there is no evidence it was used for management decisions. The plan was produced at project start for the kickoff and never updated. Status meetings were held but the plan was not referenced. This is a "decorative plan" - it exists for appearance, not for management.

Evidence That Distinguishes a Managed Plan

Evidence TypeDecorative Plan (Insufficient)Managed Plan (Sufficient)
Status meeting minutes"Project status meeting held 2024-03-15. All topics discussed.""Status 2024-03-15: SWE.1 planned 80% complete, actual 65% complete. Deviation: SRS elicitation delayed by 2 weeks due to late OEM interface spec delivery. Corrective action: weekend workshop scheduled for 2024-03-22 to accelerate. Owner: K. Müller. Revised SRS baseline date: 2024-04-05 (was 2024-03-28)."
Plan revision historySingle version of the plan from project start; no revisionsPlan v1.0 (2024-01-10) → v1.1 (2024-03-28, SRS milestone revised per corrective action) → v1.2 (2024-06-15, integration milestone adjusted for HW delay). Each revision references the decision that drove it.
Resource trackingResource allocation column in plan shows names; no actual hours trackedMonthly actual vs. planned effort per person per activity. Used to identify over/under-allocation early and replan.
Milestone trackingOriginal milestone dates never updated even as they are missedMilestone register: planned date, actual date, deviation (days), reason for deviation, and impact on dependent milestones.

Minimum MAN.3 Status Meeting Minute Template

The following structure satisfies the GP 2.1.3 monitoring requirement and provides direct assessment evidence:

  • Meeting date, attendees, project version under review
  • Planned vs. actual - per process: For each active SWE/SYS/SUP process: tasks planned this period, tasks completed, open issues, deviation from schedule (days)
  • Open actions from last meeting: Action-ID, owner, due, status (open/closed), if closed: evidence of closure
  • New deviations identified: Description, root cause, impact, corrective action, owner, due date
  • New action items: Action-ID, description, owner, due date
  • Next meeting date and focus areas

✅ MAN.3 CL2 Readiness Checklist

  • ✅ Project plan with WBS, milestone schedule, resource assignments, effort estimates
  • ✅ Project lifecycle defined: phases, milestones, entry/exit criteria
  • ✅ Weekly/biweekly status meetings with structured minutes: actuals vs. planned, deviations identified, corrective actions assigned
  • ✅ Corrective action log with owner, due date, status, and closure evidence
  • ✅ Plan revision history: each revision linked to the deviation or decision that caused it
  • ✅ RACI or equivalent: roles and responsibilities per process area explicitly assigned
  • ✅ Resource plan: tool availability, personnel assignments, training requirements

What's Next

Continue to SYS.1–SYS.5: System Engineering Processes, which address the system-level V-model above the software layer - how stakeholder requirements are captured, how the system architecture partitions HW/SW responsibilities, and how system integration and qualification testing are performed.

← PreviousSYS.1–SYS.5 - System Engineering Processes Next →SUP.1 - Quality Assurance