Project Initiation and Planning is the stage where a project becomes real: the idea is translated into a charter, objectives, scope boundaries, a credible plan, and a governance structure that can survive risk and change. For Boston City Campus learners, this “Boston Module” focuses on how to move from problem definition to actionable planning—without skipping the controls that protect time, cost, and quality. These exam notes summarise the essential concepts, step-by-step approaches, and common assessment patterns relevant to South African learners, including modules often referenced alongside UNISA MNG 0001 (Introduction to Project Management) and project management course content commonly aligned to UNISA/College of Economic and Management Sciences short-course pathways.
1) Project Initiation: From Problem Statement to Project Charter (Boston Module)
Why initiation matters in project management exams
In most university-style questions (especially in MNG 0001-type introductory project management assessments and Boston project management short-course exams), “initiation” is tested as the bridge between strategy and execution. Students often lose marks when they jump straight to schedules or resource plans before establishing:
- Purpose (why the project exists)
- Objectives (what success looks like)
- Scope boundaries (what is included/excluded)
- Stakeholders (who cares and who decides)
- High-level risks (what could derail outcomes)
- Governance (how decisions will be made)
A key exam theme is that initiation reduces uncertainty. A well-crafted charter does not eliminate risk, but it creates clarity so planning and control can be justified and audited.
Key outputs of project initiation
In a Boston-module framing, initiation typically produces a small set of powerful documents or artefacts. These are often listed explicitly in exam answers:
- Project Charter
- Authorizes the project formally
- Provides high-level objectives, scope, stakeholders, and governance
- Initial Stakeholder Register / Stakeholder Identification
- Initial Risk Assessment (high-level)
- Business Case (or at least a justification summary)
- Initial scope statement (often part of the charter)
The Project Charter: the “exam favourite”
The project charter is the document that answers: Who decided to start this project and why? It usually contains:
- Project title and brief description
- Project purpose and problem/opportunity statement
- Measurable objectives (commonly mapped to SMART)
- High-level scope and constraints
- Assumptions and exclusions
- Milestone summary (not detailed schedules—just key checkpoints)
- Roles and responsibilities (Project Sponsor, Project Manager, Steering Committee, etc.)
- Stakeholder list and preliminary engagement approach
- Budget range or funding source (sometimes high-level only)
- Governance and escalation routes
Common exam trick: If a student lists only “objectives” and “budget” but fails to mention authority, governance, scope boundaries, and stakeholder roles, they often score below a full-mark response.
SMART objectives and objective hierarchies
Many South African assessments tie initiation closely to objective formulation. A typical approach:
- Define project objectives (outcomes)
- Define deliverables (outputs)
- Define performance indicators (how you measure outcomes)
For example, if a project is “implement a student portal,” the objective might be:
- “Enable authenticated students to access modules, announcements, and assessments within 30 minutes average login time by end of semester.”
This is measurable. The deliverables could include:
- Authentication system, UI portal, content pipeline, and reporting dashboard.
Then performance measures:
- Average login time, uptime %, and user adoption metrics.
Business case and justification: what counts as “enough”?
In some modules, students are asked to explain the business case rather than calculate it. The business case should demonstrate:
- Benefits (financial and non-financial)
- Costs (one-time and ongoing)
- Options considered (e.g., build vs buy vs partner)
- Viability (funding, capacity, constraints)
- Risks (why benefits might not materialise)
Even when calculations aren’t required, exam answers should show a logical justification structure: benefits > costs and risks are managed.
Stakeholder identification at initiation
Stakeholders include anyone affected by decisions or outcomes. Exams often reward students who show they can differentiate:
- Sponsor (funds, authorizes, provides direction)
- Project Manager (plans and coordinates delivery)
- Customers/Users (benefit from outputs; provide requirements)
- Performing team (deliver the work)
- Regulators/Compliance bodies (ensure legal alignment)
- Suppliers/Contractors (provide goods/services)
Stakeholder mapping (power vs interest) in simple terms
A common technique is to categorize stakeholders by:
- Power (influence over resources/decisions)
- Interest (impact from project outcomes)
Typical categories:
- High power / high interest: manage closely, frequent communication
- High power / low interest: keep satisfied, targeted communication
- Low power / high interest: keep informed, involve when useful
- Low power / low interest: monitor, minimal communication
Initiation risks: how deep should you go?
At initiation, risk analysis should be high-level. You typically do:
- Identify major risks
- Assess likelihood and impact broadly
- Create initial risk responses (at least for top risks)
- Assign risk ownership
Exam example: top risks in a campus project
Consider a campus-related project (the type common in South Africa). Typical initiation risks might be:
- Requirement changes due to stakeholder feedback cycles
- Delays in vendor delivery of hardware/software
- Staff availability constraints during peak academic periods
- Data protection and access control weaknesses
The exam expectation: students must show a method, not just a list of risks. A method includes likelihood/impact scoring and ownership.
2) Project Planning: Scope, Schedule, Cost, Quality, and Risk Controls (Boston Module)
Planning as a disciplined conversion of “what” into “how”
After initiation, planning answers the exam question: How will we deliver the objectives within constraints? Planning typically expands:
- Scope definition and work breakdown structure
- Scheduling and sequencing of activities
- Estimating costs and building a budget baseline
- Defining quality standards and acceptance criteria
- Creating a risk management plan
- Planning communications and stakeholder engagement
- Defining procurement approach (if relevant)
- Planning change control and governance processes
In Boston module assessments, planning is often tested as a process (inputs → techniques/tools → outputs) rather than a set of vague intentions.
Scope planning and scope definition
A complete scope answer usually includes four layers:
- Scope statement: what is included and excluded
- Work breakdown structure (WBS): how you break work into manageable components
- Requirements: specific needs of stakeholders/users
- Acceptance criteria: how the deliverables will be verified
Scope boundaries: included vs excluded
Exams reward clarity on exclusions because exclusions reduce scope creep. For example:
- Included: student login, module access pages, announcement feed
- Excluded: financial transaction processing, identity verification with government documents (if not needed)
Even if exclusions are not explicitly asked, providing them improves the credibility of the answer.
Work Breakdown Structure (WBS): from deliverables to tasks
A WBS structures project work into levels:
- Level 1: major deliverables (e.g., “Portal Development”)
- Level 2: components (e.g., “UI/Frontend,” “Backend Services,” “Testing”)
- Level 3: work packages (e.g., “Design login page,” “Implement session management”)
- Work packages become units for estimation and scheduling
WBS exam tip: numbering and logic
Students should present a logical structure and avoid listing activities without grouping. A typical mini-WBS structure might be written in an exam like:
- Portal Development
1.1 Frontend Design
1.2 Backend API
1.3 Database & Security - Testing & Quality Assurance
2.1 Test Planning
2.2 Security Testing
2.3 User Acceptance Testing - Deployment & Handover
3.1 Deployment
3.2 Training
3.3 Documentation
Even if the exam does not require WBS diagrams, writing a clear breakdown often earns marks.
Scheduling: sequencing and critical thinking about dependencies
A plan without sequencing is usually incomplete. In scheduling, key concepts include:
- Dependencies: how one activity affects another
- Finish-to-start (FS), start-to-start (SS), finish-to-finish (FF)
- Critical path: sequence with zero float (most sensitive to delays)
- Milestones: key checkpoints (not every small task)
- Resources: people/equipment constraints that impact realistic scheduling
Example: a realistic sequence for a systems project
A simplified dependency chain:
- Requirements sign-off must complete before design begins.
- Database design must complete before backend API implementation can connect.
- Backend implementation must complete before testing begins.
- Security testing should occur after key security components exist.
- Deployment should happen after UAT pass.
Exams often ask students to identify which dependency is missing when a schedule “looks optimistic.”
Estimating cost: from estimates to budget baseline
Cost planning typically includes:
- Estimation approach (analogous, parametric, bottom-up, three-point estimates)
- Cost categories (labour, materials/software licenses, travel, overhead)
- Budget allocation by WBS component
- Contingency and management reserves for uncertainty
Bottom-up estimation: a disciplined method
Bottom-up estimation means estimate each work package, then roll up. A student gains marks by explaining why this method is more accurate when work is sufficiently defined, but more expensive in time to create.
Contingency vs management reserve (frequent exam question)
Students often confuse the two:
- Contingency: for identified risks (or uncertainties) that are already recognized
- Management reserve: for unknown-unknowns or high-level risk not identified yet
A strong answer distinguishes them and links them to risk management.
Quality planning: meeting requirements, not just producing deliverables
In exams, quality is often assessed as:
- Quality planning outputs (quality standards)
- Quality assurance (process-focused audits/activities)
- Quality control (inspection/testing to verify outputs)
Acceptance criteria and quality metrics
Quality planning should include how to verify deliverables. Examples:
- “Login page supports accessibility standards (e.g., contrast ratios and keyboard navigation).”
- “UAT sign-off by course representatives and IT support before deployment.”
- “Security testing shows no critical vulnerabilities.”
Students should also mention traceability where possible: link requirements to test cases and acceptance criteria.
Risk planning: probability/impact and response strategies
Risk planning is more than listing risks. A typical risk plan includes:
- Risk identification
- Risk analysis (qualitative or quantitative)
- Risk response planning
- Risk monitoring and control
Common risk response strategies
For each major risk:
- Avoid (change plan to eliminate risk)
- Mitigate (reduce likelihood/impact)
- Transfer (shift impact via contract/insurance)
- Accept (no change; have contingency/monitoring)
Exams reward students who tie a risk to a response and also assign ownership.
Change control and planning for control
Planning should include how changes will be handled. A Boston module view typically expects:
- A change request process
- Roles for approving changes (often sponsor/steering committee)
- Assessment of change impacts (scope, schedule, cost, quality)
- Version control for documents
- Traceability and documentation of decisions
A credible exam answer describes change control as an ongoing governance mechanism, not a one-time formality.
Integrated planning: combining scope, schedule, and cost
The most complete planning answers show integration. For example:
- WBS determines activities
- Activities drive scheduling
- Activities drive resource and cost estimates
- Cost baseline is compared against actuals later (cost control)
Exams often ask: “Explain why scope changes affect the schedule and cost.” A strong response links:
- Additional scope → additional work packages → more tasks → longer duration and more labour/licensing → budget increases or trade-offs.
3) Project Planning Artefacts and Governance: From Communication Plans to Procurement (Boston Module)
Project management plan: the “single source of truth”
Many learners are asked to name components of the project management plan. A planning response should communicate that the project management plan is an integrated document. It often includes:
- Scope management plan
- Schedule management plan
- Cost management plan
- Quality management plan
- Risk management plan
- Stakeholder engagement/communication plan
- Procurement management plan (when suppliers are involved)
- Change management plan / configuration management
In exams, listing these components clearly is important, but more important is explaining what each component is used for.
Communication planning: keeping stakeholders aligned
Communication is a planning concern because poor communication becomes a project risk.
What communication planning covers
A communication plan typically includes:
- Audience (who needs the info)
- Message (what they need to know)
- Format (meeting, email, dashboard, report)
- Frequency (weekly status, monthly steering meeting)
- Owner (who sends/maintains it)
- Escalation thresholds (when to escalate issues)
Example communication plan (structured)
A typical weekly cycle in many project environments:
- Weekly project team meeting: progress, blockers, changes
- Bi-weekly stakeholder update: key milestones and risks
- Monthly steering committee: budget status, scope/schedule changes approval
Even when exams do not demand exact frequencies, demonstrating a structured plan earns marks.
Stakeholder engagement: planning interactions, not just listing names
Stakeholder engagement planning answers:
- How will stakeholders influence project success?
- What level of involvement is expected?
A strong exam answer uses the power/interest mapping and then translates categories into engagement strategies:
- High power/high interest: co-decision and active involvement
- High power/low interest: executive updates and brief decisions
- Low power/high interest: workshops, training sessions, feedback loops
- Low power/low interest: periodic updates and monitoring
Procurement planning: when “buy” affects time and risk
Many student projects include procurement: software licenses, contractors, equipment, or training services. Planning procurement helps avoid delivery surprises.
Procurement plan includes
- What to procure (deliverables, components)
- Procurement approach (tender, quotes, framework agreement)
- Selection criteria (cost, experience, technical capability)
- Contract type considerations (fixed price vs time and materials)
- Timeline integration (procurement lead times)
- Risk responsibilities and contract clauses
Risk perspective in procurement
A frequent exam discussion is: procurement risks are not just delays. They include:
- Quality mismatches and acceptance disputes
- Data/security responsibilities
- Contract performance monitoring
- Change order impacts
A strong answer links procurement planning to schedule and risk controls.
Governance: decision rights, reporting lines, and escalation
Governance is the mechanism that keeps the project on track when uncertainties arise. Typical governance structures:
- Project Sponsor: ultimate accountability and authority
- Project Manager: operational control and coordination
- Steering Committee: strategic direction, approves major changes
- Working groups/technical boards: handle specialist decisions
Escalation in governance
A good exam response describes thresholds:
- Minor scope changes can be approved by Project Manager within constraints
- Major scope, cost overrun beyond a threshold, or schedule slip beyond a threshold require steering committee approval
Even without numeric thresholds, the principle must be explicit.
Baselines: scope baseline, schedule baseline, cost baseline
Baselines are crucial because control later compares actuals to the planned reference. Planning should define baselines clearly:
- Scope baseline: finalized scope statement and WBS
- Schedule baseline: agreed schedule with milestones/dates
- Cost baseline: budget allocated per WBS with contingency if used
Why baselines matter in exams
Students often describe “monitoring” but forget “compare to baseline.” A high-mark answer mentions:
- Baseline is the planned reference
- Variance analysis identifies deviations
- Corrective actions and change requests address deviations
Document control and versioning
Because multiple stakeholders contribute documents, planning must address document control:
- Who can edit and who approves
- How versions are numbered
- Where the “approved” copy is stored
- Change history and traceability
A governance plan without document control often leads to confusion and disputes.
Quality gates and stage-gate thinking
Many Boston module exams reward stage-gate logic, especially in planning phases where outcomes must be verified before continuing.
A stage-gate model:
- Gate 1: requirements sign-off
- Gate 2: design approval
- Gate 3: build completion and QA pass
- Gate 4: UAT pass and deployment readiness
Stage gates reduce the risk of building the wrong solution or deploying prematurely.
4) Risk Management in Initiation and Planning: Tools, Responses, and Control (Boston Module)
Risk management as a continuous discipline
A typical misconception is treating risk management as a one-time worksheet completed at the start. Exams expect a risk management cycle:
- Identify risks
- Analyse and prioritize
- Plan responses
- Monitor and control
- Update risk register as new risks emerge
Risk identification: where do risks come from?
Risks originate from many sources:
- Requirements uncertainty
- Technical complexity
- Resource availability
- Vendor performance
- Regulatory compliance
- Stakeholder resistance
- External events (e.g., power disruptions, transport delays, political or academic calendar shocks)
Example: campus context risks
In a university/campus-like environment, common risks include:
- Academic calendar constraints affecting availability of students or staff
- IT infrastructure readiness (servers, Wi-Fi bandwidth)
- Data protection and access approvals
- Multiple departments requesting changes concurrently
A top-scoring answer shows risk identification methods, such as brainstorming with stakeholders, reviewing historical project data, or using checklists.
Risk analysis: qualitative vs quantitative
Exams often ask students to explain “qualitative analysis” even if they don’t require numbers.
Qualitative risk analysis
- Likelihood categories (e.g., low/medium/high)
- Impact categories (e.g., minor/moderate/major)
- A risk matrix to prioritize risks
Quantitative analysis (when appropriate)
- Expected monetary value (EMV)
- Probabilistic schedule analysis (e.g., simulation)
- Sensitivity analysis
If a question is introductory, qualitative analysis usually scores well. If it’s advanced, qualitative still must be explained first, and quantitative introduced as “where needed.”
Risk register: the structured record
A risk register typically contains:
- Risk ID
- Risk description
- Category (technical, schedule, cost, stakeholder, external, etc.)
- Likelihood rating
- Impact rating
- Overall priority score (if used)
- Risk response strategy
- Owner
- Trigger/early warning signs
- Current status (open/closed/monitoring)
Why triggers matter
Triggers help move from “we identified a risk” to “we act.” For example:
- Risk: Vendor delivery delays
- Trigger: supplier misses weekly progress updates for two consecutive weeks
- Response: activate alternate supplier plan or adjust integration schedule
Response planning depth: “what you will do”
A high-mark answer describes response actions at the right granularity.
For each top risk, include:
- Preventive actions (reduce likelihood)
- Contingency actions (reduce impact if it happens)
- Fallback actions (alternative if contingency fails)
- Owner and timing (who does what, and when)
Risk ownership and accountability
Risk ownership should be assigned so that someone is accountable for monitoring and response initiation. Exam answers that say “everyone is responsible” are typically weaker because they ignore accountability.
Risk monitoring and control: how plans become reality
Risk monitoring uses:
- Scheduled risk reviews
- Tracking triggers
- Updating likelihood/impact ratings
- Recording new risks and closing resolved risks
- Ensuring that contingency reserves are used appropriately
Common exam question pattern
“Explain how risk management contributes to project success.”
Strong answer:
- Early identification reduces surprises
- Planned responses prevent reactive chaos
- Monitoring ensures risks don’t go stale
- Updates keep governance informed and enable informed change control
Managing uncertainty vs managing risk
Some exam questions distinguish uncertainty from risk:
- Risk: events with probability and impact known or estimable
- Uncertainty: events where probability cannot be estimated reliably
A balanced answer notes that both require planning:
- For risk: probability/impact and response strategies
- For uncertainty: options thinking, iterative planning, buffers, and discovery activities
5) Practical Planning Workflows and Exam-Style Scenarios (Boston Module)
A coherent end-to-end workflow (initiation → planning)
Exams frequently test whether students can narrate a logical progression. The following workflow is consistent with how Boston module planning summaries are commonly assessed:
-
Initiation
- Draft charter (purpose, objectives, scope boundaries, governance)
- Identify key stakeholders and sponsor authority
- Summarize business case justification
- Identify initial risks (high level)
-
Planning
- Define scope statement and WBS
- Develop schedule (activities, dependencies, milestones)
- Estimate costs and build budget baseline
- Plan quality standards and acceptance criteria
- Plan risk register and responses
- Plan stakeholder communications and engagement
- Plan procurement approach if external inputs are needed
- Establish baselines and change control rules
-
Readiness for execution
- Confirm documentation approvals (stage gate / authorization)
- Ensure roles and reporting structures are understood
- Ensure reserves and contingencies exist where appropriate
A complete exam response presents this as a connected system rather than isolated topics.
Exam-style scenario 1: IT system upgrade for a teaching department
Scenario description (for practice): A teaching department wants an upgraded “student portal” that supports secure login and improved module access before the next academic semester starts. There is a sponsor in the faculty, a project manager in the IT office, and users include lecturers and registered students.
Initiation marks to target
A full initiation answer should include:
-
Charter elements:
- Purpose: improve student access and reduce manual queries
- Objectives: “secure login and module access by semester start”
- High-level scope boundaries:
- included: portal UI, authentication, module access views
- excluded: student fee payments (handled by existing system)
- Governance: sponsor approval authority, steering committee monthly
- Stakeholders: sponsor, project manager, IT team, lecturers, student representatives
-
High-level risk themes:
- schedule slip due to procurement delays
- security issues due to access control design complexity
- requirements changes due to lecturer feedback cycles
Planning marks to target
A strong planning answer includes:
- Scope/WBS:
- Frontend design, backend services, database & security, testing & UAT, deployment & training
- Schedule:
- requirements sign-off → design → build → testing → UAT → deployment
- identify milestones (e.g., design approval date, UAT completion date)
- Cost baseline:
- labour and software license categories (no need for exact numbers unless asked)
- mention contingency for identified risks like vendor delays
- Quality:
- acceptance criteria for UAT and security testing
- Risk:
- risk register structure and response strategies (mitigate vendor delays, transfer security testing to specialized vendor if planned, etc.)
- Communication:
- weekly team meetings, bi-weekly stakeholder updates, monthly steering committee
Exam-style scenario 2: Construction/maintenance project with procurement and safety
Scenario description (for practice): A municipality plans maintenance of a community facility. Procurement is required for materials and contractors. Safety compliance is mandatory.
What initiation should cover
- Charter purpose: extend facility operational life and improve safety compliance
- SMART objectives:
- “Complete major repairs before a target date”
- “Achieve compliance with safety inspection requirements”
- Stakeholders:
- municipal sponsor, facility management, safety officer, contractors, community representatives
- High-level risk identification:
- contractor availability
- weather disruptions
- safety incident probability and impact
- procurement delays
Planning what the examiner expects
- WBS:
- site preparation, demolition, repairs, installation, inspections, commissioning, handover
- Schedule:
- dependencies such as procurement receipt before installation
- milestones like “safety inspection pass” before opening to public
- Cost planning:
- cost categories: labour, materials, contractor fees, transport
- contingency for weather and procurement delays
- Quality planning:
- acceptance criteria tied to inspection requirements
- Risk planning:
- owner assignment (e.g., safety officer owns safety risk monitoring)
- triggers (e.g., adverse weather forecast requiring stop-work procedure)
- Procurement:
- supplier selection criteria including past performance and compliance capability
- Governance:
- escalation rules for change orders and safety-related stoppages
This scenario tends to reward students who link governance, procurement, and risk controls—showing that planning is integrated.
Common “lost marks” and how to avoid them in Boston module answers
1) Confusing initiation with planning
A weak answer jumps into detailed scheduling and budgeting during initiation. A strong answer keeps initiation outputs high-level and uses planning to build detail.
2) Listing documents without explaining purpose
Exams prefer “document + what it contains + why it matters.” If you list “risk register” but don’t mention how it supports monitoring and control, marks are reduced.
3) Vague objectives
If objectives aren’t measurable or time-bound, it is harder to build acceptance criteria and performance measurement. Strong answers use SMART logic and link objectives to deliverables and KPIs.
4) No scope boundaries
Scope creep is the most common planning failure. Including explicit exclusions and acceptance criteria makes the plan testable.
5) No baseline thinking
Students sometimes mention monitoring but not comparing to baselines. A strong answer always anchors control to scope/schedule/cost baselines.
Mini checklists you can use in exam writing
Initiation checklist (top items)
- Charter authorization and governance
- SMART objectives and success measures
- High-level scope boundaries (included/excluded)
- Business case justification
- Stakeholder identification and roles (sponsor, PM, users)
- High-level risk themes and early ownership
Planning checklist (top items)
- Scope statement + WBS
- Schedule with dependencies and milestones
- Cost estimation approach + budget baseline
- Quality standards + acceptance criteria
- Risk register with response strategies and triggers
- Communication plan: audience, message, frequency, owner
- Procurement plan (if applicable)
- Change control and document/configuration management
- Readiness for execution: approvals and stage gates
Closing synthesis: what markers want you to demonstrate
In Boston Module Project Initiation and Planning exam questions (and in related university project management modules such as UNISA MNG 0001-style introductory project management content), markers look for the same core competencies:
- You can explain why initiation and planning outputs exist (not just name them).
- You can show integration: scope drives WBS; WBS drives schedule; schedule drives cost; quality and risk planning create measurable control.
- You can structure answers for real governance: baselines, change control, stakeholder communication, and escalation.
When your answers are coherent, structured, and linked—rather than a list of disconnected concepts—you consistently score higher.
QUICK REVISION (1-page style) — Boston Module Summary Points
- Initiation outcome: Project Charter + initial stakeholder and risk identification + business justification.
- Planning outcome: Integrated Project Management Plan covering scope, schedule, cost, quality, risk, communications, procurement, and change control.
- Core planning artefacts:
- WBS for scope breakdown
- Schedule with dependencies and milestones
- Cost baseline with contingency where relevant
- Quality plan with acceptance criteria
- Risk register with owners and triggers
- Communication plan with frequency, audience, and message
- Baselines + change control for governance
- Exam strategy: write as a workflow (initiate → charter → plan → baselines → control readiness), and include stakeholder and governance elements in every scenario answer.
