FIT2002 IT Project Management
FIT2002 Overview
- Monash University
- Semester 2 2026
- Level 2
- Project Management
FIT2002 IT Project Management is a Monash University unit about turning a promising idea into work that can be authorised, planned, delivered and reviewed. The unit joins plan-driven project controls with adaptive delivery.
- Assessment mix Two connected projects and a Quiz / Test category carry the published grade.
- Core habit Trace every recommendation to scenario evidence, an artefact and a practical consequence.
- Quantitative work Show formulas, substitutions, units and the decision that follows from the result.
- Delivery lens Choose predictive, hybrid or adaptive controls from uncertainty and stakeholder needs.
How FIT2002 is assessed
| Component | Weight | Format |
|---|---|---|
| 1. Project | 35% | A1.1 project foundations and A1.2 integrated project plan. Published due points include 21 August and 28 September 2026. |
| 2. Project | 40% | Agile execution, Scrum demonstrations, oral assessment, team written work and individual reflection. Written submissions are due 9 November 2026. |
| 3. Quiz / Test | 25% | Workshop bonus quizzes and the Week 8 class test. The supplied practice test represents a 90-minute, 50-mark format with selection and written-response sections. |
The three official Semester 2 categories sum to 100%. Operational times, venues and submission settings remain controlled by the current Monash learning system.
Current FIT2002 dates
| Date | Item | Control |
|---|---|---|
| 21 August 2026 at 11:55 pm | A1.1 project foundations | The published A1.1 specification assigns 10% of the unit grade. |
| 16 September 2026 | Class test | The Moodle assessment page lists the Week 8 test date. |
| 28 September 2026 at 11:55 pm | A1.2 integrated project plan | The published A1.2 specification assigns 25% of the unit grade. |
| 9 November 2026 at 11:55 pm | Project 2 written submissions | Team and individual written submissions use the published deadline. |
Dates come from the published Semester 2 2026 assessment pages and task specifications. Confirm exact deadlines and submission settings in the live LMS.
What FIT2002 covers
Follow the project journey from strategic fit and authorisation through scope, schedule, cost and quality, then use Agile, Scrum, risk, ethics and leadership to govern delivery.
Project Fundamentals and Strategic Fit
Projects versus operations, strategic alignment, value, success criteria and constraint trade-offs.Project fundamentals begin with a boundary: a project is a temporary effort that creates a distinct result, while operations sustain recurring capability. That boundary determines whether uncertainty, change and coordination need project governance.
- Projects as temporary, unique and progressively elaborated efforts
- Operations as repeatable work that sustains organisational capability
- Strategic objectives, benefits and the logic used to justify investment
- Time, cost, scope and quality as connected decision constraints
- Outputs, outcomes and benefits as different levels of project value
- Success criteria that combine delivery performance and stakeholder value
Business Cases and Project Initiation
Business justification, proposals, project charters, authorisation boundaries and evidence-led selection.Project initiation turns an attractive idea into an authorised commitment. A business case explains the problem or opportunity, compares feasible options and tests whether expected benefits justify costs, risks and organisational disruption.
- Business need and strategic objective as the starting justification
- Options analysis using benefits, costs, feasibility and risk
- Business cases as investment evidence rather than delivery plans
- Project proposals as recommendations for a selected course of action
- Project charters as formal authority and high-level boundaries
- Sponsors, project managers and approval rights during initiation
Scope, Requirements and Stakeholders
Scope statements, measurable requirements, acceptance criteria, traceability and stakeholder engagement.Scope management defines what the project will deliver and where responsibility stops. Requirements turn stakeholder needs into statements that can guide design, planning and acceptance.
- Scope statements containing deliverables, boundaries and exclusions
- Functional and quality requirements expressed in testable language
- Acceptance criteria as the bridge from requirement to verification
- Requirements traceability from source through work and evidence
- Stakeholder identification using interest, influence and impact
- Engagement choices matched to stakeholder needs and decision rights
WBS, Scheduling and Critical Paths
The WBS, estimation, dependencies, PERT, network logic, float, milestones and Gantt schedules.Schedule planning begins by decomposing authorised scope, not by drawing dates. A deliverable-oriented Work Breakdown Structure reveals the complete work and creates work packages that can be estimated, assigned and controlled.
- Deliverable-oriented decomposition and the complete scope rule
- Work packages as estimable and controllable units of work
- Activities, dependencies, milestones and network sequencing
- Three-point estimation using optimistic, likely and pessimistic values
- Complete path totals and identification of the critical path
- Float as scheduling flexibility rather than unused project time
Cost Planning and Quality Decisions
Traceable cost models, contingency, quality planning, assurance, control and cost-of-quality choices.Cost planning translates scoped work and resource assumptions into a traceable financial model. Estimates should identify quantities, rates, timing, uncertainty and their source rather than present a single unexplained total.
- Cost estimates built from quantities, rates, timing and assumptions
- Direct, indirect, fixed and variable costs in project decisions
- Contingency for identified uncertainty and transparent estimate ranges
- Relevant future costs contrasted with sunk historical expenditure
- Quality planning through standards, measures and acceptance evidence
- Quality assurance as process confidence and control as output checking
Quality Tools and Agile Mindset
Quality-improvement tools, Agile values and context-based predictive, hybrid or adaptive delivery.Quality improvement uses evidence to understand variation and focus effort.
- Check sheets and consistent operational collection of defect evidence
- Pareto analysis for prioritising the largest recorded categories
- Cause-and-effect analysis for organising testable explanations
- Control charts for detecting unusual variation over time
- Agile values and short feedback cycles under meaningful uncertainty
- Predictive, adaptive and hybrid delivery as contextual choices
Scrum Roles, Events and Commitments
Scrum accountabilities, events, goals, backlog control, the Definition of Done and empirical adaptation.Scrum is a lightweight framework for generating value through adaptive solutions to complex problems.
- Product Owner accountability for value and Product Backlog management
- Developers' accountability for planning and creating a usable Increment
- Scrum Master accountability for Scrum and team effectiveness
- The Sprint as a container for inspection and adaptation events
- Sprint Planning, Daily Scrum, Sprint Review and Sprint Retrospective
- Product Goal, Sprint Goal and Definition of Done as commitments
Product Backlogs and Sprint Planning
Backlog ordering, refinement, estimation, Sprint Goals, visual management and value-based selection.Product Backlog management makes future product options visible and ordered. Ordering is not a permanent ranking produced by one formula; it reflects value, risk, dependency, learning and the Product Goal.
- Product Backlog as an emergent ordered list of product options
- Ordering by value, risk, dependency, learning and Product Goal
- Backlog refinement as an ongoing clarification and sizing activity
- Relative estimation for effort, complexity and uncertainty comparison
- Sprint Planning through why, what and how decision questions
- Sprint Goals as coherent value objectives rather than task inventories
Project Risk and Response Planning
Risk versus issue, registers, qualitative analysis, response ownership, triggers and indicators.Project risk is uncertainty that may affect objectives; an issue has already occurred or currently exists.
- Risk as uncertain effect contrasted with an issue already present
- Cause-event-effect statements that make uncertainty actionable
- Probability, impact, proximity and urgency in qualitative analysis
- Threat and opportunity responses matched to project context
- Risk owners, action owners and explicit decision responsibilities
- Triggers and indicators that support timely escalation or contingency
Ethics, Leadership and Reflection
Professional codes, ethical frameworks, leadership styles, role choices, retrospectives and accountable action.Ethical project management requires more than legal compliance or sponsor preference.
- Professional obligations and ethical tensions in project decisions
- Stakeholder consequences, rights, fairness and transparent reasoning
- Utilitarian and deontological lenses applied without mechanical answers
- Leadership approaches selected from urgency, capability and context
- Servant and shared leadership as enablement with accountability
- Psychological safety, escalation channels and responsible challenge
Early topics establish the difference between projects and operations, strategic alignment, value, success criteria and the trade-offs among scope, time, cost and quality.
The planning sequence then builds the connected artefacts a sponsor needs: a project proposal, charter, scope statement, requirements, traceability, Work Breakdown Structure, network and Gantt schedule, cost model and quality evidence.
The second half changes the delivery question from "Can this plan hold together?" to "How should the team learn and adapt while protecting value and governance?" Students compare predictive, hybrid and adaptive approaches, apply Agile values, distinguish Scrum accountabilities and events, order and refine a Product Backlog, form Sprint Goals and use visual management to inspect flow.
Risk management turns uncertainty into owned responses, triggers and indicators. Ethics and leadership close the course by examining professional duties, consequences, team behaviour and reflective improvement.
The published assessment structure is built around connected project work. Project 1 moves from justification into an integrated predictive plan.
Project 2 carries the same project into Agile execution, demonstrations, oral explanation and written reflection. The Quiz / Test component includes short workshop quizzes and a timed Week 8 class test. The supplied practice resource represents that test as a mixture of single-best-answer questions and written scenarios.
Across both projects and the test, strong work is specific: it names the relevant artefact or accountability, applies evidence from the scenario, shows numerical working where needed, and explains the consequence of the decision.
Worked example · free
Recalculate a critical path when one activity changes
- +2PERT for B = (3 + 4 x 5 + 9) / 6 = 32 / 6 = 5.33 days.
- +1Path A-B-D-F = 2 + 5.33 + 4 + 1 = 12.33 days.
- +2Path A-C-E-F = 2 + 6 + 2 + 1 = 11 days, so A-B-D-F is initially critical.
- +1If C becomes 8 days, A-C-E-F becomes 13 days and takes over as the critical path.
- +1Conclude that the planned finish is now controlled by A-C-E-F, so the schedule and related risk response must be updated.
Key terms
- Project charter
- A document that authorises the project and establishes its high-level objectives, boundaries, stakeholders and governance.
- Strategic alignment
- The demonstrable connection between a proposed project and an organisation's objectives or value priorities.
- Scope statement
- The agreed description of deliverables, boundaries, exclusions, assumptions and acceptance context for the project.
- Traceability matrix
- A record linking each requirement to its origin, delivery work, verification and acceptance evidence.
- Work Breakdown Structure
- A deliverable-oriented decomposition of the complete authorised scope into manageable work packages.
- Critical path
- The longest current dependency path through the activity network, which sets the minimum project duration.
- Quality assurance
- The process-focused work that checks whether project methods are capable of producing the required quality.
- Product Backlog
- An emergent ordered list of options for improving a product and advancing its Product Goal.
- Sprint Goal
- The single objective that explains why a Sprint is valuable and guides trade-offs during delivery.
- Definition of Done
- The shared quality state that work must satisfy before it can be included in a Done Increment.
- Risk trigger
- An observable condition indicating that a risk event or response threshold requires attention.
- Servant leadership
- A leadership approach that enables others, removes impediments and builds team capability while preserving accountability.
FIT2002 FAQ
How is the unit assessed?
The official Semester 2 structure has three categories: Project 1 at 35%, Project 2 at 40%, and Quiz / Test at 25%. Project 1 links justification to an integrated plan. Project 2 covers Agile execution, demonstrations, oral work and written reflection. The Quiz / Test category includes workshop bonus quizzes and the Week 8 class test.
What is the final assessment task?
The published sequence ends with Project 2 work, including Scrum activity, an oral assessment, a team written submission and an individual learning journey with a portfolio artefact. The published written deadline is 9 November 2026. Use the current Monash learning system for operational submission settings and any later instructions.
Why can the unit feel difficult?
The challenge is integration rather than one isolated formula. A scope decision changes the WBS, schedule, cost, quality evidence, backlog and risks. Strong answers also have to move from naming a framework to applying scenario evidence and explaining consequences. Students who keep an assumption and decision trail usually find the connected tasks easier to control.
Is there a hurdle requirement?
The official Semester 2 assessment rows are published as Project, Project, and Quiz / Test components with their weights. The handbook record does not flag those rows as hurdle tasks. Check the current Monash handbook and learning system for any operational pass conditions that may be added or clarified for your enrolment.
What is the class-test format?
The supplied Semester 2 practice resource states that it matches the real test's length, structure, marks and response style. It represents 90 minutes and 50 marks: 20 single-best-answer questions worth 20 marks, followed by 4 short written responses worth 30 marks. It also uses one handwritten, double-sided A4 note sheet for the simulation.
How much mathematics is used?
The unit uses practical project calculations rather than advanced mathematics. You should be ready to show PERT substitution, path totals, critical-path changes, cost quantities, rates and financial reasoning such as NPV. Marks depend on working, units and interpretation, so a correct number without a project decision is usually incomplete.
Which offering does this guide follow?
This guide follows the captured Semester 2 2026 Monash offering. Its assessment dates, workshop sequence and class-test practice are tied to that teaching period. If your current learning system shows a later update, use the live Monash instruction for operational decisions and treat this guide as the conceptual and revision map.
Is this an official Monash guide?
No. This is an independent AskSia study resource grounded in Monash University teaching and assessment materials. The explanations, diagrams and practice questions are newly authored for study. Official requirements, dates, venues, submission settings and any later changes remain controlled by Monash University and the current learning system.
Questions students ask in each FIT2002 chapter
- How can I distinguish a project from routine operations?
- Look for a bounded change objective, a distinct deliverable, a temporary team or governance structure, and an identifiable point at which the change effort closes. Repetition alone does not decide the issue. The daily use of a system is operational, while a temporary initiative to replace or substantially redesign that system is normally a project. Chapter 01 · Project Fundamentals and Strategic Fit
- What is the main difference between a business case and a charter?
- A business case answers whether an investment should proceed and why a particular option is justified. A charter follows the selection decision and gives the project formal authority, boundaries and governance. They can share facts, but their decision purposes differ. If the preferred option remains unproved, the charter should authorise validation rather than pretending full delivery is settled. Chapter 02 · Business Cases and Project Initiation
- How do scope and requirements differ?
- Scope sets the authorised boundary of the project and its deliverables. Requirements describe capabilities and qualities that work inside that boundary must satisfy. A requirement may clarify scope, but not every scope statement is a requirement. Keep them consistent by tracing requirements to deliverables and treating additions outside the baseline through formal change control. Chapter 03 · Scope, Requirements and Stakeholders
- Why should the WBS be created before the schedule?
- The schedule needs a trustworthy account of the work. A WBS decomposes authorised deliverables and exposes omissions before activities, durations and dates are assigned. Scheduling first can produce precise dates for an incomplete scope. After work packages are defined, the team can identify activities, dependencies, estimates, resources and milestones on a more defensible basis. Chapter 04 · WBS, Scheduling and Critical Paths
- What makes a project cost estimate traceable?
- A reviewer should be able to move from each total back to its work package, quantity, unit rate, timing, assumption and evidence source. Keep subtotals visible and state whether taxes, shared costs and contingency are included. Traceability allows a changed assumption to be recalculated without rebuilding the entire budget or hiding the effect inside a lump sum. Chapter 05 · Cost Planning and Quality Decisions
- Does Agile mean that a team should avoid documentation?
- No. Agile values useful working outcomes over excessive documentation, not zero documentation. Record what supports shared understanding, compliance, maintainability, acceptance and future decisions. The question is whether an artefact earns its cost and stays current. A concise decision record or executable test can be more valuable than a long document nobody uses. Chapter 06 · Quality Tools and Agile Mindset
- Who can change work during a Sprint?
- Developers adapt the Sprint Backlog as they learn, and the Product Owner and Developers can renegotiate selected scope without endangering the Sprint Goal. Changes should remain transparent and quality must not decrease. External stakeholders do not directly assign hidden work. If the Sprint Goal becomes obsolete, only the Product Owner has the authority to cancel the Sprint. Chapter 07 · Scrum Roles, Events and Commitments
- Who decides the order of the Product Backlog?
- The Product Owner is accountable for effective Product Backlog management, including ordering. Good ordering still draws on stakeholder input, technical knowledge, risk evidence and Developers' understanding. Accountability does not mean making every judgement alone. The order should remain transparent and adaptable when value, dependency, uncertainty or the Product Goal changes. Chapter 08 · Product Backlogs and Sprint Planning
- How can I tell whether something is a risk or an issue?
- Ask whether the uncertain event has already happened. If a supplier might miss a date, it remains a risk; if the contracted date has passed without delivery, the project has an issue. The same subject can move from risk to issue over time, so update the register and action process rather than keeping obsolete wording. Chapter 09 · Project Risk and Response Planning
- What should I do when two ethical frameworks point differently?
- Make the disagreement visible rather than forcing artificial agreement. Check facts and affected stakeholders, state what each lens highlights, identify non-negotiable duties or rights, and compare feasible actions. Then justify a decision with safeguards and review points. Ethical reasoning is strongest when it acknowledges uncertainty and distribution of harm instead of using one label as automatic permission. Chapter 10 · Ethics, Leadership and Reflection
How to prepare for the assessments
Revise FIT2002 as one chain of decisions. Begin with value and authorisation, then trace an example project through scope, requirements, WBS, schedule, cost, quality and risk. For each artefact, ask which earlier decision it carries forward and which later decision relies on it. Recompute PERT, path and cost anchors from printed inputs, but always finish with the delivery consequence.
For Agile and Scrum, learn the accountabilities and the purpose of each event, then practise changed scenarios rather than memorising definitions. Before the class test, rehearse short responses that name the rule, apply scenario evidence, show working and state a consequence.
Before project submissions, audit consistency in both directions: every deliverable should support authorised value, and every planned activity should trace back to scope. Keep operational dates and submission settings checked in the current Monash learning system.
Your AI Project Management tutor for FIT2002
Stuck on a hard FIT2002 question? Sia is AskSia’s AI Project Management tutor — ask any FIT2002 IT Project Management question and get a clear, step-by-step explanation grounded in how the course is actually taught and assessed. Read this whole study guide free, then take your hardest questions to Sia.