Software Project Management
Computer ScienceΒ· 45 min read
1. Core Principles and Key Termsβ β ββββ± 15 min
Software project management is the practice of planning, monitoring, and controlling software development to deliver a product that meets stakeholder requirements within agreed time, cost, and quality constraints. All projects are bound by the triple constraint of scope, time, and cost, which must be balanced to deliver a successful outcome.
Software Project Management
The process of initiating, planning, executing, monitoring, and closing software development work to meet specific goals and success criteria
Example:
A team building a student attendance app manages developer hours, deadlines, and changing client feature requests to deliver a working product on budget.
Scope: The set of features and requirements the project must deliver
Stakeholders: All people or groups affected by the project outcome
Risk: Any uncertain event that can positively or negatively impact the project
Deliverable: A tangible or intangible output produced during the project
Identify 4 key constraints for a project to develop a new e-commerce website for a small local business.
- 1
Step 1: Define what a project constraint is: any factor that limits project delivery.
- 2
Step 2: Identify the first two constraints: scope (required features: checkout, user accounts, inventory tracking) and time (deadline before the holiday shopping season).
- 3
Step 3: Identify the remaining two constraints: cost (limited small business budget for developer hours) and quality (must meet security standards for handling customer payment data).
2. Project Management Methodologiesβ β β βββ± 20 min
CIE 9618 frequently asks for comparisons of the two most common project management methodologies: waterfall and agile. A methodology is a structured approach to organizing and completing project work.
Below is a comparison of the two core methodologies tested in the exam:
Waterfall
Linear sequential approach where each phase of development is completed before moving to the next. Requirements are fixed and fully documented at the start of the project.
+ Pros: Easy to manage and schedule; Clear comprehensive documentation; Works well for small projects with stable requirements
β Cons: Inflexible to changing requirements; Testing occurs late, leading to costly rework; Full product is only delivered at the end
Agile
Iterative incremental approach where work is split into short fixed-length sprints. Requirements evolve over time, with regular stakeholder feedback after each sprint.
+ Pros: Adapts easily to changing requirements; Early working product is available for testing; Lower risk of costly major rework
β Cons: Higher risk of unmanaged scope creep; Less comprehensive documentation; Final cost and timeline are harder to predict upfront
Recommend a methodology for a project developing a new social media app where requirements are not fully defined, and the client wants regular updates to adjust features.
- 1
Step 1: Analyze the key characteristics of the scenario: unclear initial requirements, need for regular client input and changes.
- 2
Step 2: Eliminate waterfall: Waterfall requires all requirements to be fixed at the start, and cannot accommodate mid-project changes without major disruption and cost.
- 3
Step 3: Justify agile: Agile splits work into 2-4 week sprints, after each sprint the client can review the working product and adjust requirements. This matches the scenario needs perfectly.
3. Scheduling and Risk Managementβ β β βββ± 20 min
Project scheduling involves breaking work into tasks, identifying dependencies between tasks, and tracking progress against deadlines. Risk management is the process of identifying potential problems and putting mitigation strategies in place to reduce their impact.
Critical Path
The longest sequence of dependent tasks that determines the shortest possible time to complete the entire project. Any delay to a task on the critical path delays the overall project end date.
Example:
If designing a database must be completed before coding the app backend, both tasks are part of the critical path.
Common software project risks include scope creep, staff turnover, unrealistic deadlines, and unproven technical complexity. Each risk has a corresponding mitigation strategy to reduce impact.
A software project is at risk of scope creep from regular client requests for new features. Explain one effective mitigation strategy for this risk.
- 1
Step 1: Define scope creep to set context: uncontrolled, unapproved changes to project scope that lead to delays and increased cost.
- 2
Step 2: Describe a formal change control process: all new feature requests are written down, assessed for their impact on project time, cost, and scope, and only approved or rejected by the project steering group before any work begins.
- 3
Step 3: Explain why this works: it prevents unplanned work from being added to the project without adjusting deadlines and budget to accommodate the change, keeping the project on track.
4. Team Roles and Stakeholder Managementβ β ββββ± 10 min
CIE exam questions often ask about the responsibilities of key roles in a software project team. Below are the core roles you need to remember:
Project Manager: Overall responsibility for planning, scheduling, budget, and on-time delivery
Business Analyst: Elicits and documents requirements from stakeholders
Developer: Writes, tests, and maintains code for the product
Tester: Independently verifies that the product meets requirements and identifies bugs
Client/End User: Defines requirements and accepts the final product
A development team has no clear understanding of what the client needs from the product. Which role is responsible for resolving this, and why?
- 1
Step 1: Identify the correct role: Business Analyst.
- 2
Step 2: Explain the role's core responsibility: Business Analysts communicate directly with clients and stakeholders to elicit, clarify, and document requirements clearly for the development team.
- 3
Step 3: Justify: A clear requirements document produced by the Business Analyst removes ambiguity and ensures the team builds a product that matches the client's needs.
5. Common Pitfalls
Wrong move:
Defaulting to agile as the correct answer regardless of scenario context
Why:
Many students learn agile is modern and automatically select it, even when the scenario describes fixed requirements.
Correct move:
Always match the methodology to the scenario: use waterfall for fixed, stable requirements and agile for changing, unclear requirements.
Wrong move:
Claiming any delay to any task delays the whole project
Why:
Students forget that only critical path tasks affect the overall project end date.
Correct move:
Only tasks on the critical path have zero slack/float. Non-critical tasks can be delayed up to their slack time without changing the project end date.
Wrong move:
Calling all scope changes scope creep
Why:
Controlled, approved scope changes are a normal part of any project. Scope creep refers specifically to uncontrolled changes.
Correct move:
Only label unapproved, unplanned changes to project scope that add work without adjusting time or cost as scope creep.
Wrong move:
Stating agile projects have no documentation
Why:
Agile prioritizes working software over comprehensive documentation, which is often misinterpreted as no documentation at all.
Correct move:
Agile projects still include sufficient documentation for maintenance and future development, just less comprehensive than waterfall.
Wrong move:
Assigning requirements gathering to the project manager
Why:
Students often mix up the responsibilities of project managers and business analysts.
Correct move:
Business analysts are responsible for eliciting and documenting requirements; project managers focus on planning, scheduling, and budget.
6. Quick Reference Cheatsheet
Concept | Waterfall | Agile |
|---|---|---|
Approach | Linear sequential | Iterative incremental |
Requirements | Fixed at start | Evolve over time |
Best for | Stable requirements, regulation-heavy projects | Changing requirements, innovative projects |
Documentation | Comprehensive | Sufficient, just-in-time |
Risk of scope creep | Low | High (if unmanaged) |
Delivery | Full product at project end | Working increment each sprint |
Flexibility to change | Low | High |
7. Frequently Asked
What is the difference between float (slack) and the critical path?
The critical path is the sequence of tasks that determines the minimum project completion time, with zero float. Float (slack) is the amount of time a non-critical task can be delayed without delaying the overall project end date.
When this came up on past exams
AI-estimated based on syllabus patterns β cross-check with official past papers for accuracy. Use only as revision-focus signals.
- 2022 Β· 12
Compare waterfall and agile methodologies
- 2023 Β· 11
Explain critical path analysis
- 2024 Β· 12
Mitigation for scope creep risk
Going deeper
What's Next
Software project management is a core foundation for all further study of software engineering, and lays the groundwork for understanding system development, requirements gathering, and quality assurance for complex projects. This sub-topic is heavily weighted in CIE 9618 Paper 1, with frequent 6-8 mark extended response questions testing your ability to apply concepts to specific scenarios. Focus on practicing methodology comparisons and risk mitigation examples to score full marks. Explore the links below to build on your knowledge of connected concepts.