Revision pack
Built from the Week 9 seminar deck (all 30 slides), the Week 9 cleaned transcript, the official Week 9 Change Request template, the Week 9 dossier, the Week 1 assessment slides and the Weeks 4–8 seminar recordings. Everything here is labelled by how strong the evidence is. Works offline; nothing loads from the internet.
Read this once. The 25-minute limit is the single biggest thing shaping how you should write.
| Fact | Detail | Evidence |
|---|---|---|
| What | Path B Exam 4, worth 10%. The last of the four Path B in-term exams (10 / 15 / 10 / 10). | CONFIRMED Wk09 slide 2; Wk01 slide 8 |
| When | Start of the Week 10 seminar, before the team presentations begin. | CONFIRMED Wk01 slide 13; Wk09 transcript |
| How long | 30 minutes total = 5 minutes reading + 25 minutes writing. | CONFIRMED Wk01 slides 10, 13 |
| Bring | Your student ID card. “NO STUDENT ID, NO EXAM… THERE ARE NO EXCEPTIONS TO THIS RULE (this includes if you bring another ID such as passport).” | CONFIRMED Wk01 slide 13 |
| What it tests | “SYNTHESISING your knowledge and applying them to specific scenarios.” | CONFIRMED Wk01 slide 10 |
| If you miss it | Apply for special consideration → supplementary exam in Week 11. You may only do this for one Path B exam; miss more than one and you default to Path A. | CONFIRMED Wk01 slide 10 |
| Being late | For an ordinary seminar, arriving more than 10 minutes after the seminar start means you are marked absent. For a seminar containing a Path B exam, arriving after the Path B exam has concluded means you are marked absent for seminar participation. | CONFIRMED Wk01 slide 13; CoPC Guide p.2 |
EXAM SIGNAL The Week 9 seminar opened by saying the session was deliberately selective because there is one more exam next week, and the topics highlighted that day are the ones to prepare. That is the strongest scoping statement available.
PREDICTION In Week 4 the lecturer-in-charge described how the exams are scoped: each one primarily covers the weeks since the last exam, while assuming you still know everything before it. Exam 1 covered Weeks 1–3; Exam 2 covered Weeks 4–5 (“scope and schedule”). Exam 3 sat at the start of Week 9, so it could only have covered Weeks 7–8. That leaves Week 9 as the primary content for Exam 4, with Weeks 1–8 assumed knowledge you may need to draw on.
CONFIRMED Slide 3 of the Week 9 deck lists, in its own words, the “Top skills you’ll learn this week”. These are officially listed Week 9 learning outcomes — not an Exam 4 specification, and the slide does not mention the exam. PREDICTION Their relevance to Exam 4 is strongly supported by the seminar signals in the box above, but the exact Exam 4 scope remains unconfirmed because no dedicated announcement or exam guide was found. On that basis these are the five skills this pack treats as priorities:
JUDGEMENT Notice what is not on that list: resource management, the organisational environment and SWOT. Topic 1 got 30 minutes of class time but produced only one skill statement (conflict). Allocate your revision time by that skill list and by which topics had an exercise or a Slido — not by how many slides a topic occupied. That is why §7 is short and §2 is long.
A distinction worth keeping straight. In the Week 4 recording the lecturer-in-charge described a two-hour exam with “three or four questions… some may have parts, part A, part B, part C… some may have a case study you need to refer to.” That description was about the Path A final exam sat in the university exam period, not your Path B in-term exam.
For Path B the confirmed number is 25 writing minutes. PREDICTION That realistically supports two or three short scenario questions, possibly with parts. Do not plan essays.
One method that works for every question type in this exam. Learn this before you learn any content.
EXAM SIGNAL The lecturer-in-charge, describing his own mock-exam feedback in the Week 4 seminar:
“…a lot of you did description and explanation really well. But the justification of rationale wasn’t as well… this is what I propose, this is why I propose it, and this should be the outcome … as a result of following my proposal. That is what I’m after. And again, three sentences… If I was marking the mock exam, the average would be a pass.”
Week 4 seminar recording (raw auto-transcript; wording lightly cleaned, meaning unchanged)
EXAM SIGNAL The Week 9 seminar said the same thing twice: the wanted shape is decision → assumptions → justification, and there was an explicit warning that verbose answers lose marks because markers have seen too many long responses that never make the reasoning clear. Give dot points.
| # | Step | What it looks like on the page | Lines |
|---|---|---|---|
| 1 | Recommendation | One sentence, first. “I recommend the CCB defer the biometric-login change to a post-pilot release.” Never make the marker hunt for your position. | 1 |
| 2 | Material assumptions | Only the ones your answer actually depends on. “Assuming the pilot date is a fixed sponsor commitment and no biometric vendor is currently contracted.” | 1–2 |
| 3 | Justification from the scenario | Quote the scenario’s own facts back. Not “biometrics take time” but “two weeks remain and no security assessment has been run.” | 2–4 |
| 4 | Impacts across project areas | Never one factor. Scope / schedule / cost / quality / resources / risk / procurement / stakeholders, as relevant. | 3–6 |
| 5 | Governance & follow-through | Who decides, what gets documented, what downstream artefacts update, who is told. This is where the last marks live. | 1–2 |
Collapse to the lecturer’s three sentences: what I propose → why I propose it → what outcome follows. Then add one governance line if you have 20 seconds. That still beats a page of definitions.
EXAM SIGNAL Each of these was raised explicitly by teaching staff in a recorded seminar.
JUDGEMENT Keep definitions to one sentence unless the question explicitly asks for explanation. Do not omit a requested definition — if the question asks you to define or explain something, that is marked. But spend most of the answer on application and justification. The Week 9 presentation advice generalises to the exam: assume your audience knows project management, so if you mention a RAID log, don’t spend three lines explaining what a RAID log is — say why this entry matters. Lead with how and why, not what.
EXAM SIGNAL The highest-priority topic in this pack. It was the only Week 9 topic explicitly flagged as an exam focus area, it took roughly 50 of the seminar’s minutes including a 20-minute group exercise, it has its own official template, and the consolidated feedback was introduced as “the format wanted in the presentation and the exam”.
CONFIRMED Any proposed change to the approved scope, cost baseline or schedule baseline — the triple constraint — must follow the authorised change-control process. Slide 23 adds that change requests are an output of monitoring and controlling project work, and that they contain three things:
JUDGEMENT A performance variance does not automatically mean the baseline should be changed. A variance is a difference between actual and planned performance. Corrective action may be enough to recover performance against the existing baseline. The baseline changes only once an authorised change has been approved. One line saying this separates a precise answer from a generic one.
| Type | Official wording (Wk09 slide 23) | Trigger — how to tell them apart |
|---|---|---|
| Corrective action | “should result in improvements in project performance” | Performance has already drifted off plan and you are pulling it back. Behind schedule, over budget, low velocity. Something happened; fix the performance. |
| Preventive action | “reduce the probability of negative consequences associated with project risks” | Adding a security review gate, conducting an early integration test, or cross-training a second developer. The risk has not occurred; the action reduces its probability or expected consequence. Might happen; lower the probability. not this Adding contingency reserve is not a preventive action. It provides authorised budget capacity for an approved risk response, or for the consequences if the risk occurs — it does not itself reduce the probability of the risk event. |
| Defect repair | “bringing defective deliverables into conformance with requirements” | A deliverable does not meet its stated requirement. Wrong accessibility data in the map layer; a page that loads in eight seconds against a two-second criterion. The product is wrong; make it conform. |
CONFIRMED Slide 24: “Integrated change control involves identifying, evaluating, and managing changes throughout the project life cycle.” Three objectives:
CONFIRMED Slide 24: “a formal group of people responsible for approving or rejecting changes on a project.” They meet on a regular frequency, but time-sensitive changes may go through an emergency change policy, and smaller changes may be managed outside a CCB — the project should define a procedure for these. Change requests “often have a formal, documented process that describes when and how official project documents and work may be changed” and outlines who is authorised to make changes.
EXAM SIGNAL Why a CCB exists, from the seminar: oversight (otherwise everyone changes whatever they want), a middleman between requesters and the delivery team who assesses whether the change is worth the investment, and standardisation across the portfolio. A portfolio-level tell: if the same type of change request keeps arriving from different programs, that signals a systemic gap, not a project problem.
CONFIRMED Slide 24: “identifying and controlling the functional and physical design characteristics of products and their support documentation.” Specialists identify and document configuration requirements, control changes, record and report changes, and audit the products to verify conformance to requirements. The seminar’s plain-English version: making sure what was designed from a quality perspective is actually what gets delivered.
EXAM SIGNAL Given in the seminar as the sequence to memorise:
CONFIRMED This is the biggest correction this pack makes to the “assess time, cost and scope” shorthand. The official Week 9 CR template asks you to assess eight named areas, and its own summary sentence names stakeholders as a ninth consideration.
Every row that is not the pre-filled example carries the instruction: “<Please assess impact, if any. If none, outline why>”. Saying “no impact” is allowed — saying nothing is not.
| Area | What to write |
|---|---|
| Scope | What is added to or removed from the approved baseline. The template’s own worked example: “Adds new authentication requirements, integration work, fallback-login functionality, documentation and testing to the approved project scope.” Also test it against the agreed scope: was this identified as a key requirement early? |
| Schedule | Added activities, their duration, whether they sit on the critical path, and the effect on the committed date. Name the date. |
| Cost | Build, licence and operating costs; additional test cycles; whether contingency is legitimately available for an approved risk response; and whether additional authorised budget or a cost-baseline adjustment is required. |
| Quality | Effect on agreed acceptance criteria and quality gates. Is there time for UAT? Does it conflict with a stated usability or performance standard? |
| Resources | Who has to do it, whether they have the capability and the capacity, and what they stop doing instead. |
| Risk | New risks introduced (privacy, security, integration, reputational) and whether existing risks get worse. Link to the RAID log. |
| Procurement | Does this need a vendor you don’t have? A new SOW, RFP/RFQ, evaluation, contract and SLA is a procurement cycle, not a purchase. |
| Other (if any) | In practice: stakeholders and communications. Who asked, what their priority is, what deferring does to that relationship. |
WEEK9/Week 9 CR Template.pptx. Header fields also include CR ID, date, requestor, objective, priority (Low/Med/High) and “Decision by”. The template’s columns are Area · Likely impact · Response / mitigation — so for each impact you name, also name what you would do about it.
CONFIRMED The template includes an illustrative rationale block. It is a ready-made answer skeleton — memorise the shape:
The template carries a note from the lecturer that this bottom section need not be filled in during the class exercise — it is “illustrative of what you would see in a typical CR template”. It is still the clearest official statement of the reasoning shape the course wants, which is why it is here.
| Decision | When it is the right call | What you must add |
|---|---|---|
| Approve | The change maps to a priority the scenario has actually stated (e.g. credibility, security, a regulatory need) and a credible mitigation makes the schedule/quality risk acceptable — for example a vendor with proven capability in exactly this area. | The assumption the mitigation rests on. “This rests on the assumption that the vendor can implement it in time; state the assumption, and if it holds, the mitigation holds.” |
| Reject | The change is not needed, is already met another way, or the impact is disproportionate to the value at any point. | What already meets the need. The strongest point made in class was that authentication already exists, so adding another mechanism adds a whole additional process and time. |
| Defer | The change has genuine value but cannot be assessed or delivered within the current constraint. Route it to a later release. | A named future release and a date to come back. See the warning below. |
EXAM SIGNAL The single most quotable line from the exercise debrief:
“Deferring is a rejection at this point in time. You are rejecting it now with the option to revisit in a later scope release (v2.0).”
Week 9 seminar, tutor response to Group 9 — from the cleaned transcript
So a defer answer must still carry a full impact rationale. “Defer” is not a way to avoid making the argument.
Two traps the tutors called out by name.
JUDGEMENT Two more levers the seminar legitimised, worth one line each if they fit:
EXAM SIGNAL “Approval is not the end.” A scope change flows into the scope documentation → WBS → schedule management plan → and onward. It has both a documentation impact and a communication impact. The exercise debrief listed this under “bonus marks — governance”.
CONFIRMED Slide 25 asks exactly this: “What could happen if the team implemented the change before completing this assessment?” Have an answer ready — it is a plausible exam sub-part.
JUDGEMENT Uncontrolled scope creep; baselines become meaningless so you can no longer tell whether you are on track; cost and schedule overrun goes undetected; unassessed security and quality gaps may reach the pilot; no audit trail of who authorised what; stakeholders and dependent teams are surprised; and the rework costs more than the assessment would have.
↑ topOfficial skill #3 is “interpret NPV, ROI and payback information” — not “calculate”. Know the formulas, but expect to be asked what the numbers mean together.
EXAM SIGNAL Before execution, before the go/no-go decision. To calculate them you must already know what you are delivering, over what duration, with how many people, at what cost, for what benefits. A tutor drew the line explicitly: earned value and planned value are cost control tools used once your budget baseline is set; NPV supports the business case. It is one metric among several answering “is this project worth doing?”
CONFIRMED Slide 15 definition, verbatim: “A method of calculating the expected net monetary gain or loss from a project by discounting all expected future cash inflows and outflows to the present point in time.”
CONFIRMED Decision rule, verbatim: “Projects with positive NPVs should be considered if financial value is a key criterion. Higher NPVs are preferred.” The conditional clause matters — it is the seed of the whole multi-criteria argument.
CONFIRMED Three steps: (1) determine estimated costs and benefits for the life of the project and the products it produces; (2) determine the discount rate; (3) calculate the net present value.
Discount rate 10%. Both projects have the same total cash flow, and different NPVs.
| Project 1 | Yr 1 | Yr 2 | Yr 3 | Yr 4 | Yr 5 | Total |
|---|---|---|---|---|---|---|
| Benefits | $0 | $2,000 | $3,000 | $4,000 | $5,000 | $14,000 |
| Costs | $5,000 | $1,000 | $1,000 | $1,000 | $1,000 | $9,000 |
| Cash flow | ($5,000) | $1,000 | $2,000 | $3,000 | $4,000 | $5,000 |
| NPV | =npv(b1,b6:f6) | $2,316 | ||||
| Project 2 | Yr 1 | Yr 2 | Yr 3 | Yr 4 | Yr 5 | Total |
|---|---|---|---|---|---|---|
| Benefits | $1,000 | $2,000 | $4,000 | $4,000 | $4,000 | $15,000 |
| Costs | $2,000 | $2,000 | $2,000 | $2,000 | $2,000 | $10,000 |
| Cash flow | ($1,000) | $0 | $2,000 | $2,000 | $2,000 | $5,000 |
| NPV | =npv(b1,b13:f13) | $3,201 | ||||
NPV() does): Project 1 = $2,316.35, Project 2 = $3,201.41. The slide’s own callout: “Note that totals are equal, but NPVs are not because of the time value of money.”
EXAM SIGNAL The examinable insight is why they differ. Both projects return $5,000 in total. Project 2 wins because its money arrives earlier and its up-front outflow is smaller. A project that earns most of its money late is worth less than one that earns early. If you are handed two projects with identical totals, that is the point being tested.
EXAM SIGNAL Money today is worth more than money in the future because of inflation and risk. Governments typically use a lower rate; higher-risk contexts use a higher one. 10% is the working default in this course and the textbook. What the rate actually does is set the hurdle: returns must grow by at least that rate for the project to break even in present-value terms.
CONFIRMED Slide 15’s “important considerations”: some organisations treat the investment year as Year 0 and do not discount Year 0 costs; the discount rate can vary, often based on the prime rate and other economic considerations; costs can be entered as negative numbers and listed first.
CONFIRMED Slide 16 headline: “Calculated by subtracting the project costs from the benefits and then dividing by the costs.” And the equation, exactly as printed:
EXAM SIGNAL Interpretation from the seminar: the most widely used method — for every dollar spent, how much comes back? In business, ideally around $2 back per $1. In government it is not about the dollar multiple at all — it is about whether you are improving and impacting people’s lives, and assigning a monetary value to that carries its own assumptions.
The slide gives NPV but not ROI for Figure 4-4. Applying the slide formula to the same figures at 10%:
| PV of benefits | PV of costs | NPV | ROI | |
|---|---|---|---|---|
| Project 1 | $9,743.50 | $7,427.15 | $2,316.35 | 31.2% |
| Project 2 | $10,782.98 | $7,581.57 | $3,201.41 | 42.2% |
Project 1: 2,316.35 ÷ 7,427.15 = 0.312. Project 2: 3,201.41 ÷ 7,581.57 = 0.422.
Label this clearly if you use it: these ROI figures are derived by applying the slide formula to the slide’s figures. They are not printed on the slide. The cross-check that they are right is that PV benefits − PV costs reproduces the slide’s published NPV to the dollar in both cases.
CONFIRMED Slide 16: “Amount of time it will take to recoup the total dollars invested in a project.” Also: it “determines how much time will elapse before accrued benefits overtake accrued and continuing costs”; “payback occurs when the net cumulative discounted benefits equals the costs”; and “many organisations have requirements for the length of the payback period of an investment.” Figure 4-6 charts cumulative costs against cumulative benefits and marks the crossing point.
JUDGEMENT Payback measures when you get your money back. It says nothing about how much you make. It ignores everything that happens after the crossing point, so a project with a short payback and a small tail can beat a project with a long payback and a huge tail on this metric alone — which is exactly why the funding Slido has the answer it has.
Cumulative discounted net cash flow, 10%:
| End Yr 1 | Yr 2 | Yr 3 | Yr 4 | Yr 5 | |
|---|---|---|---|---|---|
| Project 1 | −$4,545 | −$3,719 | −$2,216 | −$167 | +$2,316 |
| Project 2 | −$909 | −$909 | +$594 | +$1,960 | +$3,201 |
Project 1 is still $167 short at the end of Year 4 and pays back during Year 5. Project 2 pays back during Year 3. Here all three metrics agree and point to Project 2 — that is the easy case. The exam case is the one where they disagree.
CONFIRMED Slide 16: “a systematic process for selecting projects based on many criteria.” Three steps: (1) assign weights (percentages) to each criterion so they add up to 100%; (2) assign scores to each criterion for each project; (3) multiply the scores by the weights and get the total weighted score.
| Criteria | Weight | Proj 1 | Proj 2 | Proj 3 | Proj 4 |
|---|---|---|---|---|---|
| Supports key business objectives | 25% | 90 | 90 | 50 | 20 |
| Has strong internal sponsor | 15% | 70 | 90 | 50 | 20 |
| Has strong customer support | 15% | 50 | 90 | 50 | 20 |
| Uses realistic level of technology | 10% | 25 | 90 | 50 | 70 |
| Can be implemented in one year or less | 5% | 20 | 20 | 50 | 90 |
| Provides positive NPV | 20% | 50 | 70 | 50 | 50 |
| Has low risk in meeting scope, time and cost goals | 10% | 20 | 50 | 50 | 90 |
| Weighted project score | 100% | 56.0 | 78.5 | 50.0 | 41.5 |
JUDGEMENT Two things to say about this table if you get the chance. First, Project 4 scores best on speed (90) and best on low risk (90) and still finishes last — because it scores 20 on the most heavily weighted criterion. Being good at the cheap criteria doesn’t save you. Second, “provides positive NPV” is one row worth 20%. The course’s own model treats a financial metric as a decision input, not the decision.
CONFIRMED Slide 17 ran this as a Slido, with the share question “Which criterion (NPV, ROI, payback period, organisational priorities) should carry the most weight in this decision, and why?”
A project has a positive NPV and a strong ROI, but its payback period exceeds the organisation’s maximum threshold. Best recommendation?
Week 9 Slido. Class answer: D.
A) Approve — NPV is positive
B) Reject — it breaches the payback requirement
C) Recommend approval on strong ROI
D) Assess against organisational priorities and clarify whether the threshold is mandatory
EXAM SIGNAL The seminar said of this question: “this is the type of question to expect”, and added that a different answer is acceptable provided you can justify it and state your assumptions.
| Metric | What it tells you | What it does not tell you |
|---|---|---|
| NPV positive | Value is created once the timing of cash flows has been accounted for. Higher is better. | NPV incorporates the timing of cash flows, but a single NPV figure does not reveal the detailed cash-flow profile, liquidity pressure or exact payback period. It also says nothing non-financial. |
| ROI strong | Efficiency — return per dollar invested. | Absolute size of the return; timing; risk; strategic fit. |
| Payback long | Cash is tied up for a long time; exposure to changing assumptions is higher. | Whether total value over the life is good. Everything after the crossing point. |
| Weighted score | Fit against the criteria the organisation says it cares about. | Absolute financial value; and it is only as good as the weights, which are themselves a judgement. |
EXAM SIGNAL Two questions, in this order: (1) What does the organisation normally use? Which method is understood and already drives decisions there — ask. (2) What are your assumptions, and can you defend them? Observed across previous cohorts: groups that picked the simplest intuitive method and executed cleanly did as well as groups that chose a complex method and worked through the assumptions. Both worked.
EXAM SIGNAL This block is where a top answer separates itself. Three connected points, all made at length in the seminar.
EXAM SIGNAL The worked case: a project where about $4 million had already been spent was killed because the underlying assumptions were no longer valid. Their business cases were 18 months to 2 years old — not long, but the AI landscape had moved enough that the projected benefits no longer held. Several were put on hold.
The principle to write down: money already spent is sunk and cannot be recovered by continuing. The decision is made only on future costs against future benefits. $4 million already spent is acceptable to walk away from when it protects against a $100 million commitment that no longer stacks up. “We’ve already spent X” is never a justification on its own — and if a scenario offers it to you, saying so is the mark.
Official skill #2: “explain key procurement decisions and vendor-selection considerations.” One Slido, one dominant rule.
CONFIRMED Slide 11. “Procurement: acquiring goods and/or services from an outside source.”
| Process | Official description | Key output |
|---|---|---|
| Planning procurement management | “Determining what to procure, when and how to do it.” As PM, consider what project needs can best be met using products and services outside the organisation. | The make-or-buy decision. |
| Conducting procurements | “Obtaining vendor responses, selecting vendors and awarding contracts.” Assess responses against the evaluation criteria you formed; develop a shortlist; contract negotiations may occur, i.e. a best and final offer (BAFO). | A contract, signed by both buyer and vendor. |
| Controlling procurements | “Managing relationships and vendors, monitoring contract performance, making changes as needed and closing out contracts.” | Performance managed; contract closed. |
EXAM SIGNAL The first question, and the test to apply: what is the core purpose of the business, and are the money, the risk and the capability build worth it?
Both directions are reversible, and the seminar gave a failure mode for each:
CONFIRMED Slide 11: “If the decision is to buy, we must then consider: Statement of Work (SOW) which describes the work required from the vendor, giving bidders a good understanding of the buyer’s expectations; and bid documents such as Request for Proposal (RFP) or Request for Quote (RFQ) to solicit proposals and/or quotes from prospective vendors, which we will assess against evaluation criteria.”
| Instrument | What it is | When you use it |
|---|---|---|
| SOW | Statement of Work — describes the work required from the vendor. SLIDE | Once you have decided to buy, before going to market. It is what gives bidders a good understanding of your expectations — and what you later hold them to. |
| RFI | Request for Information. SEMINAR ONLY | Earliest stage, when you do not yet know who is out there or what is possible. It is a market scan, not a buy. |
| RFP | Request for Proposal. SLIDE | When the solution is open and you want vendors to propose an approach. You are buying thinking as well as delivery. |
| RFQ | Request for Quote. SLIDE | When the requirement is already well specified and you essentially need a price. |
EXAM SIGNAL Cost cannot be the only criterion. The consulting example given: clients would spend around 18 months negotiating, pick the cheaper vendor, and come back 6–12 months later because the cheap vendor couldn’t deliver — at which point there was no discount. “Single-factor decisions fail. The cheapest vendor is irrelevant if the project fails. The highest quality is irrelevant if you can’t deliver it.”
| Criteria | Weight | P1 rating | P1 score | P2 rating | P2 score | P3 rating | P3 score |
|---|---|---|---|---|---|---|---|
| Technical approach | 30% | 90 | 27.0 | 80 | 24.0 | 70 | 21.0 |
| Management approach | 30% | 85 | 25.5 | 75 | 22.5 | 85 | 25.5 |
| Past performance | 20% | 95 | 19.0 | 70 | 14.0 | 75 | 15.0 |
| Price | 20% | 75 | 15.0 | 95 | 19.0 | 80 | 16.0 |
| Total score | 100% | 86.5 | 79.5 | 77.5 |
Your project needs a specialist vendor for a critical system component. Vendor A costs 40% less but has limited experience. Vendor B is experienced but cannot guarantee delivery by your deadline.
Week 9 Slido. Class answer: C.
A) Vendor A — lowest cost
B) Vendor B — experience reduces quality risk
C) Evaluate both against weighted criteria (cost, schedule, risk)
D) Reject both, do it internally
EXAM SIGNAL The rationale accepted: the question gives no information about the project state. If cost is the binding constraint, weight cost. If quality is the priority and there is schedule buffer, weight quality. Build a weighted matrix — the example floated in class was 60% cost / 30% quality / 10% other — and score both vendors against it. A student also added relationship management as a legitimate criterion: a vendor who closes this technology gap can be leveraged for other skills on the project at lower marginal cost. Accepted alongside C.
Cost · schedule / delivery certainty · technical capability and relevant experience · management approach · past performance · risk (delivery, security, data handling, compliance) · cultural and relationship fit / leverage for future work · exit and transition terms. Then say what weights you would set and why the scenario justifies them. That last clause is where the judgement mark sits — and the seminar was explicit that all of this rests on assumptions: assuming customer outcome outweighs cost is an assumption, and for a smaller company cost may genuinely be the dominant driver. That is fine — just make the assumption explicit.
CONFIRMED Slide 11: contracts “may be fixed price, cost-reimbursable (plus fee), time and material or unit price.”
JUDGEMENT RECOGNITION LEVEL The slide shows the textbook’s contract-risk spectrum (Figure 12-3). The examinable idea is the direction, not the acronyms: cost-reimbursable contracts leave more risk with the buyer (you carry the cost overrun), while firm fixed-price contracts push more risk onto the seller (they carry it). Everything in between trades that risk off. If a scenario has uncertain scope, a fixed price is hard to get and expensive; if scope is well specified, fixed price protects you.
CONFIRMED Slide 11: ensure the vendor meets contractual requirements; the project team must be aware of potential legal problems caused by not understanding a contract; changes must include impact analysis and must be documented in writing; closing a procurement means the project determines all work has been completed correctly and satisfactorily, and the contract should include requirements for formal acceptance and closure; alternate dispute resolution such as mediation or arbitration can be used if parties do not agree.
EXAM SIGNAL Not named on the slide but given real weight in the seminar. An SLA sets response and resolution commitments — respond within 24 hours, 12 hours, or 60 minutes. One example raised: if not fixed within 10 business days, the customer gets a full refund.
The danger to quote: SLAs can explode your cost without you noticing. If you over-promise in the statement of work to win the bid — “everyone else says 60 minutes, we’ll do 30” — and you aren’t set up for it, you pay penalties, and worse, you damage the client relationship. Governance of a new vendor was described as weekly, monthly and quarterly meetings at different levels.
Official skill #1: “select an appropriate response to project conflict.” It is a classification-then-choice task. Learn the five definitions verbatim and learn a selection rule.
CONFIRMED Slide 8: “Conflict is inevitable: projects can get stressful, people can behave inappropriately and strong opinions can be shared on how things can and should be done. Conflict can be detrimental to a project and must be managed!”
CONFIRMED Two sources, and the distinction matters for which technique you pick:
CONFIRMED “As the PM, you should act with impartiality and fairness. You may need to involve other parties such as HR. Poor management of conflict can have a negative impact on team morale and escalate into bigger problems.” You must also ensure “a clear governance structure and mechanism for managing disputes (including escalation pathways)” and communicate clearly what “acceptable” behaviour is.
CONFIRMED The nuance most students miss, printed on slide 8: “Conflict can be constructive! It allows us to avoid groupthink by challenging ideas and coming up with better alternatives. Importantly though, task-related conflict, NOT emotional conflict, helps improve team performance.” The seminar’s version: without the friction there’s no shine — but too much friction produces analysis paralysis, and that is what governance is for: someone decides, a direction is picked, everyone follows.
CONFIRMED The middle column is the slide’s wording, verbatim. Learn it — you can quote it in one line and spend your time on the selection.
| Technique | Slide definition (verbatim) | Choose it when | The risk |
|---|---|---|---|
| Confrontation | “directly face conflict using a problem-solving approach and work through disagreements” | It is a task conflict, the root cause matters, and there is time to work it through. The default for a genuine technical disagreement. | Escalates if the conflict has already become emotional. |
| Compromise | “use a give and take approach by negotiating a solution that brings satisfaction to each party” | Both sides hold valid, partial information — especially when they know the business better than you do. | Nobody is fully satisfied; may not fix the root cause. |
| Smoothing | “de-emphasise areas of difference and emphasise areas of agreement” | You need to lower the temperature, protect a relationship, or buy time before a real conversation. | The problem is unresolved and recurs. |
| Forcing | “use a win-lose approach, and make a decision as to what will happen” | A deadline forces the call, or safety/compliance leaves no room. Justified by the constraint, not by your authority. | Morale damage. The seminar’s example was a program director who does this “without registering the impact on the team”. |
| Withdrawal | “let the parties sort it out themselves, or postpone and step back if more information needed or to lower emotion” | You need more information, emotions are too high to be productive, or the matter is genuinely above your pay grade. | Reads as avoidance if you never come back to it. |
JUDGEMENT Slide 9 explicitly permits “one or a combination of the techniques”, so a layered answer is legitimate and usually stronger.
EXAM SIGNAL The seminar’s summarising point: none of the five is wrong — it depends on the situation and the personalities. What matters is knowing which one you default to, and knowing when to choose which. “The successful people in leadership aren’t the ones who always win or always avoid — they’re the ones who adapt to the situation.”
Where challenge isn’t encouraged, you get green-on-the-outside, red-on-the-inside reporting: good news that collapses when you deep-dive, and you deal with the impact later anyway. It is a useful one-clause justification for why constructive task conflict is worth protecting — but it is an anecdote, not examinable content.
Official skill #5: “explain how integration supports organisational value.” Lighter than §2–§5, but closure has an explicit warning attached to it.
CONFIRMED Slide 20: “The central theme throughout this course is that you, as the PM, must co-ordinate ALL knowledge areas throughout a project’s lifecycle.”
CONFIRMED Why it belongs to the project manager — four “someone must” statements: someone must take responsibility for coordinating all of the people, plans and work; someone must focus on the big picture and steer the team toward successful completion; someone must make the final decisions when conflicts occur among project goals or people; someone must communicate key project information to top management.
EXAM SIGNAL The seminar’s framing for “how integration supports organisational value”: you need one person who understands the project end to end, who holds direction and scope, and who can see what is happening where. And a failure mode worth quoting: “Most projects are business-led and technology-enabled.” Projects led entirely by technology groups fail — you need the business, product owners and product managers, leading.
CONFIRMED Slide 21: “A document used to coordinate all project planning documents and help guide a project’s execution and control. Plans created in the other knowledge areas are considered subsidiary parts of the overall project management plan.” They “should be dynamic, flexible, and subject to change when the environment or project changes.”
Scope · Requirements · Schedule · Cost · Quality · Resource · Comms · Risk · Procurement.
JUDGEMENT This list is your ready-made checklist for “what else does this change touch?” — it maps almost exactly onto the CR template’s eight impact areas.
CONFIRMED Slide 22: “the majority of your time and money will be spent on project execution.” The focus is to direct/lead your project team, manage stakeholder relationships, and ensure the work in your PMP is appropriately managed. Two levers named: strong leadership and a supportive culture (“if project managers follow through on their own plans, their team members are more likely to do the same”; organisational guidelines and templates make it easier), and product, business and application-area knowledge (understanding the language of the business and the technical experts on the team).
CONFIRMED Slide 23: “Monitoring project work includes collecting, measuring, and disseminating performance information. Change is also inevitable — to control this, your PMP provides the baseline for identifying and controlling project changes.” A baseline is “a starting point, measurement or observation that is documented so it can be used for future comparison.”
CONFIRMED Two important outputs: change requests (containing corrective actions, preventive actions and defect repairs — see §2.1) and work performance reports (“status reports, progress reports, memos, and other documents used to communicate performance”).
JUDGEMENT This is the join between §6 and §2, and it is the cleanest way to answer “how does integration support organisational value”: the PMP sets the baseline → monitoring detects variance against it → variance produces change requests → integrated change control decides → the baseline and all subsidiary plans update → and the organisation always knows where the project actually stands. That loop is the value.
CONFIRMED Slide 26: “To close a project or phase, you must finalise all activities and transfer the completed or cancelled work to the appropriate people.” Main inputs: project charter, project management plan, project documents, accepted deliverables, business documents, agreements, procurement documentation, organisational process assets. Main tools and techniques: expert judgment, data analysis, meetings.
JUDGEMENT Note “completed or cancelled”. You close a killed project too — that is what makes the sunk-cost decision in §3.6 an executable one rather than just a stance.
EXAM SIGNAL The seminar’s framing: the most common mistake is that projects don’t finish properly. Money and time have run out and people just leave. Options, simplest to most formal:
And the parallel that was drawn explicitly in class: the same failure appears in presentations and exams — people don’t finish their thoughts or fully answer the question. “People routinely forget to do this, and they remember the people who do it well.”
Name: formal acceptance and sign-off of deliverables against the acceptance criteria · handover to the operational owner with documentation and support arrangements · close out contracts (formal acceptance and closure per the contract; resolve any disputes) · release resources · final financial reconciliation against the cost baseline · lessons learned captured into organisational process assets · archive the project documents and change log · and communicate closure to stakeholders. Then say who signs.
SUPPORTING 30 minutes of class time, but no official skill statement points here and it was not tested by a Slido. Know it well enough to recognise it and use it as supporting justification. Exam Mode shows the strip below; the detail is in Full Reference Mode.
CONFIRMED Slide 7, with the header “People determine the success and failure of organisations and projects!”
| Process | Official description | Detail worth keeping |
|---|---|---|
| Resource planning | “identifying and documenting project roles, responsibilities and reporting relationships” | Outputs: project organisational charts; staffing management plans (“who do we need, how many, what will they do? Think WBS”); RACI. |
| Acquiring resources | “filling the positions on the project team” | Assign existing staff or hire externally; schedule specialists as required. Assign people to tasks at appropriate experience levels — “sometimes this process involves compromise as we don’t always get who we need.” Resource levelling: initially over-allocate people (>100% load) so you can resolve resource conflicts by delaying tasks. |
| Developing and managing the team | “ensuring individuals work together well as a team and tracking performance and resolving conflict” | Team building matters. Training categories: technical, methodology (e.g. Agile), project admin, business (“ensure you understand the business for which you are developing a system — this is a COMMON criticism of IT professionals”), and personal. |
| Controlling the project team | “ensuring resources are available as planned and are utilised accordingly” | Monitor planned versus actual resource utilisation and take corrective actions as needed. This is where status reporting lives: what did we say we would do, what have we done, and for anything not done — why, and what does it mean? |
EXAM SIGNAL A tutor’s addition worth carrying into any answer: updating one artefact ripples through the others across the whole lifecycle. That is the same claim as §2.6 and §6.4, arriving from a third direction.
EXAM SIGNAL The company, sector, domain, structure and culture you operate in — a student answer accepted in class was “the structure of the company and how teams are set up.” It matters because structure determines how you acquire resources: build internally, hire externally, or buy. The practical advice: you don’t have to guess — ask for the org chart; even the “who we are” page tells you whether an organisation is flat or hierarchical.
CONFIRMED Slide 14: strategic planning and project selection “involves determining long-term objectives of an organisation, and deriving guardrails on which projects should be prioritised and funded.” Five considerations and methods: (1) focusing on broad organisational needs — wide impact/reach; (2) categorising IT projects — problem / opportunity / time; (3) performing Net Present Value or other financial analyses (such as Return on Investment); (4) using a weighted scoring model based on various criteria; (5) implementing a balanced scorecard — aligning business activity to strategy.
EXAM SIGNAL The seminar’s core message: you are not working in isolation. The lecturer’s own method on starting a new team — ask what the strategic objective of your boss is, and of your boss’s boss. “That, in a nutshell, is strategic planning: what are you going after, what is your role, what is your piece of the puzzle.”
SWOT. A 360-degree view. Internal: what are we good at (strengths), what are we not good at (weaknesses). External: where is our competitive advantage (opportunities), where are we losing (threats). Use it to identify priorities and weight them, to judge whether a project is aligned to what the organisation needs. JUDGEMENT The nuance worth one line: there is a default tendency to fix weaknesses, but sometimes the better move is to pick a project that reinforces an existing strength and compound it. Both are legitimate — say which you are doing and why.
RECOGNITION ONLY The balanced scorecard and the IT-planning-stages pyramid (Figure 4-3: IT strategy planning → business area analysis → project planning → resource allocation) appear on slide 14 but were not developed in class. Recognise the names; do not spend revision time on them.
Every question below is constructed by me for practice. None is a real past exam question and I have no access to the exam paper. Q1, Q2 and Q3 are built directly on the in-class exercise and the two Slidos, so they are the closest to the real thing.
Every answer comes in two layers. The exam-length answer is what you could realistically write in the time shown — 80–130 words for a 4–5 minute question, 120–180 for 6–7 minutes, 180–250 for 10 minutes. Beneath it, “Study rationale — why this answer works” holds the fuller reasoning: what earns the marks, why the alternatives were rejected, and the traps. Read the rationale while revising; rehearse the exam-length version.
Project Pulse’s technical lead wants to delay the pilot to fix usability issues, while the business lead insists on launching as scheduled to protect stakeholder confidence. Their disagreement has become personal, and you are the Project Manager responsible for resolving it. Which conflict-handling technique(s) would you use, and why?
This is the scenario printed on Week 9 slide 9 and role-played in class. Practice question wording; scenario is official.
Recommendation. Withdrawal briefly, then confrontation.
Assumption. The pilot date is a sponsor commitment but not contractually fixed.
Governance. Act with impartiality; involve HR if behaviour is the issue; escalate if it sits above my level. Any change to the pilot date goes through a change request.
Where the marks sit. The classification in line one is what signals you know slide 8. Most answers jump straight to a technique without saying what kind of conflict it is, and everything else follows from that classification — which is why it earns a whole line.
Why withdrawal first, and why it is not avoidance. The slide definition includes “postpone and step back if more information needed or to lower emotion”. Naming that phrase stops a marker reading your answer as “do nothing”. Time-boxing it is the detail that proves the point.
Why confrontation second. Severity-rating against the agreed acceptance criteria is what converts an emotional dispute back into a task one: you are not asking who is right, you are asking what the criteria say. It is also why the compromise fallback is a reduced-scope pilot rather than splitting the difference on the date — it keeps the decision anchored to quality gates. Both leads hold valid partial information: the technical lead on quality risk, the business lead on stakeholder confidence.
Why not forcing. Forcing is defensible only when a deadline removes the option of working it through. Nothing in the scenario says the date is immovable, so forcing buys a decision at the cost of team morale — the seminar’s example of a program director who forces “without registering the impact on the team” is the cautionary case.
The governance line. Impartiality and fairness, HR involvement and escalation pathways are all printed on slide 8, so they are cheap marks. The final clause matters most: a pilot-date change is a schedule-baseline change, so it goes through change control rather than being settled in the corridor.
Your project needs a specialist vendor for a critical system component. Vendor A costs 40% less but has limited experience. Vendor B is experienced but cannot guarantee delivery by your deadline. What do you recommend?
Wording from the Week 9 Slido. Practice question; the class answer was C.
Recommendation. Select neither yet — score both against weighted criteria first.
Assumption. The component is on the critical path, so a missed date delays the project.
Governance. Document the scoring, take it to the approving forum, hold the winner to the SOW.
Why “neither yet” beats picking one. The Slido answer was C, and the accepted reasoning was that the question deliberately withholds the project’s state. Declaring a winner means inventing the missing information. Saying so explicitly is the mark. If cost were the binding constraint you would weight cost; if quality were the priority and there were schedule buffer you would weight quality — you cannot tell which from the scenario.
Why the weights need a justification clause. Anyone can list criteria. What separates answers is the sentence tying the weighting to the scenario: because the component is critical and on the critical path, delivery certainty and technical risk outrank a 40% price saving. Weights must total 100% — a set that does not is an immediate error.
Getting Vendor B’s mitigation right. A fixed-price contract on its own does not solve a schedule problem: it reallocates cost risk, not time risk, and a vendor who cannot deliver on time still cannot deliver on time. An operational SLA is also the wrong instrument — SLAs govern service performance once something is running, not implementation milestones. The mechanisms that actually bear on a delivery date are committed milestones written into the contract, staged delivery so slippage becomes visible early, explicit contractual schedule obligations, an incentive tied specifically to on-time delivery, and a contingency plan for the case where the date slips anyway. If you mention an incentive, connect it to timeliness or it reads as a generic commercial lever.
Other criteria worth naming if you have room. Management approach, security and data handling, compliance, exit and transition terms, and the relationship-leverage point a student raised in class — a vendor who closes this technology gap can be reused for other skills at lower marginal cost.
The evidence to cite. Figure 12-4 on slide 11 makes this argument for you: Proposal 2 has the best price rating in the field (95) and still loses, 79.5 to 86.5.
A project has a positive NPV and a strong ROI, but its payback period exceeds the organisation’s maximum threshold. What is your recommendation to the investment committee?
Wording from the Week 9 Slido, which the seminar described as “the type of question to expect”. Class answer: D.
Recommendation. Do not decide on the metrics alone. Establish whether the payback threshold is mandatory, then assess against organisational priorities.
Assumption. The benefit estimates behind NPV and ROI are unvalidated.
Governance. If it proceeds, revalidate the benefit assumptions on a stated cycle and define a stop trigger.
Why the mandatory question comes first. It determines whether there is a decision to make at all. If the threshold is a policy rule, the only defensible moves are reject or seek a formal exemption; if it is a rule of thumb, the decision reverts to organisational priorities. Answering it first is what distinguishes D from the three single-factor options.
The NPV point, stated precisely. Be careful here — NPV does account for timing: that is exactly what discounting does, and the slide’s own Figure 4-4 example proves it (two projects with identical $5,000 totals produce $2,316 and $3,201 because one earns earlier). What a single NPV number does not give you is the profile: how much cash is negative in which year, what that does to liquidity, and when the crossing point falls. A long payback alongside a strong NPV can starve the organisation of funds for other projects — the class made this point directly, noting that five years of negative cash flow materially affects liquidity whatever the NPV says.
The multi-criteria move. A weighted scoring model makes the trade-off explicit and is the course’s own tool for it — and remember that on slide 16’s Figure 4-7, “provides positive NPV” is one row worth 20%.
A different answer is defensible. The seminar said so explicitly. “Reject” is a perfectly good answer if you state that you are treating the threshold as mandatory. What is not defensible is choosing without saying which assumption you made.
Two weeks before the Project Pulse pilot, Shona Bryan requests biometric login to improve security and user convenience. Complete the change request assessment and recommend whether the Change Control Board should approve, reject or defer.
This is the official Week 9 in-class exercise (slide 25 and the CR template). If any single question is worth rehearsing end-to-end, it is this one.
Recommendation. The CCB should DEFER the change to a post-pilot release (v2.0).
Assumptions. Authentication already exists in the approved pilot scope; the pilot date is a sponsor commitment; no approved biometric solution or vendor arrangement is confirmed.
Governance. Submit to the design forum, then the CCB for decision and sign-off. Record the decision and rationale in the change log and give Shona a dated reassessment point. Deferring is a rejection at this point in time.
The full template grid. In the exam you would write the bullets above. This is what the same assessment looks like filled into the official three-column template — Area · Likely impact · Response / mitigation — which is worth rehearsing because it forces you to pair every impact with an action.
| Area | Likely impact | Response / mitigation |
|---|---|---|
| Scope | Adds new authentication requirements, integration work, fallback-login functionality, documentation and testing to the approved scope. Biometric login was not identified as a key requirement at baseline. | Log as a candidate for v2.0 scope; do not amend the pilot scope baseline. |
| Schedule | Security assessment, build, integration and full test cannot be completed in two weeks. Directly threatens the committed pilot date. | Hold the pilot date; schedule the assessment into the post-pilot planning cycle. |
| Cost | Build or licence, plus operating cost and an additional test cycle. The feature is outside the approved cost baseline. It must be estimated and submitted through change control with an authorised budget and baseline adjustment if approved. Contingency should not be used simply to fund additional scope unless the cost is an approved response to a previously identified risk. | Cost it properly as part of the v2.0 business case rather than estimating under pressure, and adjust the baseline only on approval. |
| Quality | Insufficient time for full UAT before the pilot increases the likelihood that undetected defects could reach the pilot. Adding an authentication step also risks conflicting with the agreed usability standard. | Keep the existing acceptance criteria intact; require a full test cycle before any future implementation. |
| Resources | The change would require privacy, security, integration and testing capability that has not been confirmed as available within the two-week window, and existing capacity is already committed to pilot readiness. stated as an assumption, not a case fact | Assess capability and capacity as part of the v2.0 resource plan; confirm who would actually do the work before committing. |
| Risk | The change may introduce privacy and security exposure, depending on whether biometric templates or identity data are collected, stored or shared — the scenario does not specify the solution architecture, so this must be confirmed during impact assessment. It also introduces integration risk into a system about to go live, accessibility or exclusion risk for users who cannot or will not enrol, and reputational risk if the pilot slips. | Confirm the proposed architecture first; raise as a new RAID entry against v2.0, with privacy, security and accessibility review as preconditions. |
| Procurement | If no existing approved arrangement can be used, the change may require a make-or-buy decision, vendor due diligence, new contracting, or a variation to an existing contract. Whichever applies, it is unlikely to be completed safely within two weeks. | Check first whether an existing approved arrangement already covers this; otherwise fold into the v2.0 make-or-buy decision. |
| Other — stakeholders | The requester is the senior sponsor. Deferring without a commitment risks the relationship. | Respond personally with the rationale and a dated reassessment point. |
Why the rationale lands on schedule and risk. The template asks for “the most significant impacts … because …”. Here there is no path to a tested, privacy-assessed biometric capability in two weeks, and shipping it untested would put both the pilot and the institution’s data position at risk. Deferring is a rejection at this point in time — the value of the change is accepted, but not at this point in the schedule.
Downstream, if the CCB approved instead. Because the recommendation is to defer, no baselines change now. Had it been approved, the scope statement, WBS, schedule and cost baselines, quality plan, RAID log and procurement plan would all need updating — and the change log is written either way, for the audit trail.
On the assumptions. Every assumption in the answer is stated as an assumption, not asserted as a case fact. In particular, do not claim that the university holds no biometric data, that only the IT team can do the work, or that a specific capability definitely does not exist — none of that is confirmed in the course case. What you can defensibly say is that no approved biometric solution or specialist vendor has been confirmed for the pilot, and that the required capability has not been confirmed as available in the window. Same conclusion, defensible premises.
Three more places where certainty is easy to overclaim.
On priority ratings. The template has a Low/Med/High priority field. Only fill it in if you can justify the rating — for example “High, because the change carries privacy and security consequences and the decision window is two weeks”. An unexplained rating adds nothing and invites a challenge.
Two things this answer deliberately does not do. It does not propose an alternative product inside the rationale — that would raise a second change request. And it does not leave “defer” open-ended: an undated defer destroys trust as surely as a silent one.
Could you argue approve? Yes, if you state the assumption it rests on. The tutor’s constructed case: if a vendor has proven capability in user authentication, that mitigates the schedule risk; and if the student representative flagged credibility as a priority, authentication maps directly to it. The whole case then rests on the vendor being able to implement in time — state that assumption, and if it holds, the mitigation holds.
Three weeks into the pilot, the contracted data vendor asks to change the SLA from a 4-hour to a 24-hour response target for data-feed outages, in exchange for a 15% reduction in the annual fee. The pilot depends on the feed for room-availability information. Assess and recommend.
Constructed practice scenario. It is here so that your change-request technique does not depend on one memorised example.
Recommendation. Reject the proposed variation. Invite the vendor to submit a separately assessed revised variation, potentially using a tiered response target for teaching and non-teaching hours.
Assumption. Room-availability data is core to the pilot; a stale feed shows wrong information rather than degrading gracefully.
Governance. Route any variation through authorised procurement and change control. The CCB decides if it exceeds delegated authority or affects approved baselines. The revised tiered option must not be treated as automatically approved; it requires its own impact assessment and an authorised contract-change decision. Update the contract, SLA and RAID log only after approval.
Recognising the question type. A vendor-initiated proposal is still a change request. The instinct to treat “they are offering us a discount” as a commercial conversation is exactly the trap — the trigger here is a change to an agreed service commitment the pilot depends on, so it goes through change control. Cheaper is one criterion, not the criterion.
Why quality is the decisive impact. Every other impact is a number you could argue about. This one is binary: for a full working day, students would be shown room availability that is wrong. The pilot’s whole value proposition is trustworthy information, so the change attacks the thing the project exists to deliver.
Why inviting a revised variation beats both a flat reject and a counter-offer. A flat reject throws away a genuine insight: you have worked out when the risk actually bites, and a tiered target reflects that. But do not write the tiered target into your recommendation as though it were settled — a tiered target is itself a revised contract variation, and approving it inside your rejection rationale is exactly the “don’t smuggle in a second change” error the Week 9 tutors penalised. The clean move is to reject what was proposed and invite the vendor to submit the revised option so it can be assessed on its own merits. The revised tiered option must not be treated as automatically approved; it requires its own impact assessment and an authorised contract-change decision. Same commercial outcome, correct governance — and it still preserves the relationship while protecting the period that matters.
Be precise about which risk dimension actually moves. Relaxing the response target does not make a data-feed outage more likely to occur — the feed will fail as often as it always did. What changes is that each outage may last far longer, so its impact grows, and with it the likelihood that a user actually encounters stale data during one. Writing “this raises both the probability and the impact” is exactly the loose risk language Week 8 warned against. Name the dimension that moves, and update the existing RAID entry rather than raising a new risk.
Getting the governance language right. Two precision points. First, the course material talks about procurement documents, contracts and the authorised procurement process — it does not define a “procurement baseline”, so call this a contract variation. Second, do not write “the CCB decides, not the project team” as an absolute: slide 24 is explicit that smaller changes may be managed outside a CCB under a defined procedure, and that emergency change policies exist for time-sensitive changes. The accurate formulation is that it goes through the authorised change procedure, and the CCB decides where it exceeds delegated authority or touches approved baselines.
Also worth a clause if you have room. Contract changes must include impact analysis and be documented in writing (slide 11) — not settled verbally with the account manager. Notify pilot stakeholders of any change to the availability commitment. And update the contract, SLA, RAID log and affected project documents only after approval, never in anticipation of it.
Classify each of the following and justify in one line: (a) the pilot’s accessibility data is found to be out of date and does not meet the agreed accuracy criterion; (b) testing is running two weeks behind so an additional tester is added; (c) a second developer is cross-trained on the integration layer because only one person currently knows it.
Constructed practice question, built on the official definitions on slide 23.
All three are recommended within change requests, an output of monitoring and controlling project work. Note that (b) recovers performance against the existing baseline — it does not by itself change the baseline.
The three tells, in the order you should apply them. First ask whether a deliverable is failing a stated requirement — if so it is defect repair, whatever else is going on. Then ask whether the thing has already happened: if performance has drifted, it is corrective. If nothing has happened yet and you are acting on an entry in the risk register, it is preventive.
Why (a) is not corrective. Out-of-date accessibility data is tempting to call a performance problem, but the scenario says it “does not meet the agreed accuracy criterion”. That phrase is a conformance failure in a deliverable, which is the slide-23 definition of defect repair almost word for word.
Why (c) is not corrective. Nothing has gone wrong. A single person knowing the integration layer is a key-person risk, and cross-training reduces its probability of biting. If that person had already left and you were scrambling, it would be corrective.
The baseline clause is the extra mark. Adding a tester recovers performance against the plan you already have; it does not by itself mean the schedule baseline moves. Distinguishing recovery from re-baselining is exactly the precision §2.1 is about, and it costs one sentence.
A programme has spent $4m of an approved $40m budget. The business case was written 20 months ago and shows a positive NPV. The sponsor argues that stopping now would waste the $4m already invested. Two of the three benefit assumptions no longer hold because the technology landscape has changed. What do you recommend?
Constructed practice scenario, modelled closely on the case described in the Week 9 seminar.
Recommendation. Stop or pause pending a re-baselined business case. Do not continue on the strength of the original NPV.
Assumption. The two invalidated assumptions materially drove the benefit figure and no compensating benefit has emerged.
Governance. Take the revised assumptions to the investment forum with a re-run appraisal; recommend formal closure or a re-scoped pilot with a stated stop trigger, and monitor the new assumptions continuously.
Naming the sunk-cost fallacy is the whole question. The sponsor has handed you the fallacy in the stem — “stopping now would waste the $4m already invested”. An answer that does not identify and reject that reasoning has missed the point of the question, however sensible the rest of it is.
Frame it as $36m, not $40m. The precise move is to restate the decision as the remaining commitment against the revised benefits. That single reframing is what converts a stance into an analysis.
Why the NPV does not rescue it. The seminar’s line is the one to have ready: “At the end of the day they’re just numbers. The question is always what assumptions sit underneath them.” The real case behind this scenario had business cases 18 months to 2 years old where the AI landscape had moved enough that projected benefits no longer held, and roughly $4m was written off against a potential $100m commitment.
Closure is part of stopping. Slide 26 says you transfer completed or cancelled work. Recommending formal closure — rather than just “stop” — is what makes the recommendation executable, and it picks up the lessons-learned mark.
The legitimate counter-argument. If the programme also addresses a non-financial obligation — customer-harm risk, compliance, legacy remediation — that can override a weak financial case, exactly as in the $100m/$11m case the lecturer described. Say so explicitly rather than letting it hide inside the numbers.
The Project Pulse pilot has finished. The sponsor asks you to “just move on to the next phase.” What do you do to close the pilot properly, and why does it matter?
Constructed practice question, built on slide 26 and the seminar’s closure discussion.
Recommendation. Run a formal closure before starting the next phase: a documented handover plus steering-committee sign-off.
Why it matters. Closure finalises all activities and transfers completed or cancelled work to the right people. Skipping it means the next phase starts with no validated acceptance, no operational owner, open contracts and no audit trail.
The question is really about discipline under pressure. The sponsor is asking you to skip a step. A good answer does not argue with the sponsor — it shows that closure is quick, proportionate and protective, and sizes it to a pilot rather than proposing a heavyweight process.
Scale the formality. The seminar gave a spectrum: at the simplest, a handover email saying thank you, where all documentation is captured and what was decided; at the most formal, a steering committee sign-off with finance, risk and HR signing. Naming both, and choosing one for this scenario, shows judgement rather than recitation.
Do not forget the contracts. Slide 11 says closing a procurement means the project determines all work has been completed correctly and satisfactorily, and that the contract should include requirements for formal acceptance and closure, with mediation or arbitration available if the parties disagree. Most answers omit this and lose an easy mark.
“Completed or cancelled”. Slide 26’s wording matters: you close a killed project too. That is the link to Q7 — it is what makes a stop decision executable rather than just a stance.
The line to finish on. The seminar’s framing was that the most common mistake is projects not finishing properly: money and time run out and people simply leave. And the class was told the same failure shows up in presentations and exams — people don’t finish their thoughts. Finishing this answer cleanly is itself the point.
The Project Pulse team must decide whether to build the campus wayfinding engine in-house or licence it from a specialist vendor. What decision framework would you apply, and what would make you change your mind later?
Constructed practice question, built on the seminar’s make-or-buy discussion and slide 11.
Recommendation. Apply the core-purpose test, then a weighted comparison, and treat the decision as reversible.
What would change my mind. Losing too much IP brings the capability back in-house; a vendor damaging user experience triggers termination. Any later switch is a change request.
Lead with the test, not the answer. The question asks for a framework, so a confident “we should buy it” without the test underneath answers a different question. The core-purpose test — is this central to what the organisation exists to do, and are the money, risk and capability build worth it — is the seminar’s own first question.
The clause that makes it more than a recital. “Unless the wayfinding data is what makes the product distinctive” is the sentence that shows you can see when the default reverses. It is also true to the Project Pulse case, where trustworthy accessibility and room data is the value proposition.
Buying is not the fast option by default. Most answers assume buy = quicker. Naming the procurement cycle — SOW, RFP/RFQ, evaluation, contract, SLA — corrects that, and links this question straight to §4.
The reversibility point is the second half of the question. Both failure modes came from the seminar and both are reversible: outsource too much and lose IP, so you bring it back in-house; the vendor damages the customer experience, so you terminate. The industry precedent is the reversal on external data centres — for years the consensus was that data management could sit outside, and with cyber risk and agentic AI organisations now want data held close and often onshore. That reversal came from experience and incidents.
Close the loop. A later switch is itself a change request with procurement, cost, schedule and risk impacts. Make-or-buy is reviewed, not decided once.
Question on the front, answer hidden. Weighted toward the five priority Week 9 skills. Anything you can’t answer in ten seconds goes back to its section.
ROI = (total discounted benefits − total discounted costs) / discounted costsHidden in Exam Mode. Here so you can check anything in this pack against the original material.
| Slide | Content | Used in |
|---|---|---|
| 1 | Title. Presented Monday by Donia Saeidi (Head of Digital Retail and Transition, Unite Program @ Westpac); Thursday by Xavier Jusay (Lecturer @ SISTM UNSW, former EY Senior Mgr). | — |
| 2 | “Where are we?” — course roadmap and assessment timeline. Shows Path B Exam 4, Week 10, 10%. | §0 |
| 3 | Agenda (30/20/20/50 min) + “Top skills you’ll learn this week” + reading: Chapters 4, 9 (pp 409–411) and 12. | §0 — the scoping backbone of this pack |
| 4 | Project Pulse — “Is Project Pulse worth doing?” (the Week 9 CoPC task). | Context only |
| 5 | Rewind to Week 1 — the PM framework, with integration, resource and procurement highlighted. | §6 |
| 6 | Topic 1 divider. | — |
| 7 | Project Resource Management — four processes, outputs, resource levelling, training categories. | §7.1 |
| 8 | Conflict management — sources, impartiality, five techniques, escalation pathways, task vs emotional conflict. | §5 |
| 9 | Conflict role-play exercise (10 min): technical lead vs business lead over delaying the pilot. | §5.3, Practice Q1 |
| 10 | Topic 2 divider. | — |
| 11 | Procurement Management — three processes, SOW, RFP/RFQ, evaluation criteria, Figure 12-4, contract types (Figure 12-3), BAFO, closing, dispute resolution. | §4 |
| 12 | “Which vendor?” Slido (2 min) + share question on the importance of cost. | §4.5, Practice Q2 |
| 13 | Topic 3 divider. | — |
| 14 | Strategic Planning and Project Selection — five methods, SWOT mind map (Figure 4-2), IT planning stages (Figure 4-3). | §7.3 |
| 15 | NPV — definition, rule, three steps, Figure 4-4 worked example, important considerations. | §3.1 |
| 16 | ROI, payback, weighted scoring — formula, Figure 4-6 payback chart, Figure 4-7 weighted scoring. | §3.2–3.4 |
| 17 | “Would you fund this project?” Slido + share question on which criterion should carry most weight. | §3.5, Practice Q3 |
| 18 | Break. | — |
| 19 | Topic 4 divider. | — |
| 20 | Integration Management — why it matters, six processes. | §6.1 |
| 21 | The PMP — definition, contents, nine subsidiary plans. | §6.2 |
| 22 | Directing and managing project work. | §6.3 |
| 23 | Monitoring and controlling — baseline definition, change requests (corrective / preventive / defect repair), work performance reports, sample performance report. | §2.1, §6.4 |
| 24 | Integrated change control — three objectives, CRs and the CCB, configuration management. | §2.2 |
| 25 | The biometric-login CR exercise (20 min) + share question on implementing before assessing. | §2.4, §2.7, Practice Q4 |
| 26 | Closing the project or phase — inputs, tools and techniques. | §6.5 |
| 27 | Week 10 presentation timetable (Seminars A, B, C; QUAD 1043 and 2055). | Not exam content |
| 28 | Key takeaways (tl;dr). | Cross-check |
| 29–30 | Thank you; copyright notice. | — |
CONFIRMED Slide 3 sets the reading as Chapters 4, 9 (pp 409–411) and 12. No textbook file exists in this course folder, so nothing in this pack is taken from the textbook directly. The figure numbers on the slides confirm the mapping:
PREDICTION Earlier content is assumed, not the focus. One line each — enough to use it in a justification, not enough to answer a question about it.
| Week | What you might need to reach for |
|---|---|
| 1 | Triple constraint (scope/time/cost) and the 10 knowledge areas; project integration management as the area that affects and is affected by all others. |
| 2 | Stakeholder register and the power/interest grid; communication planning; capability vs capacity; the project charter. |
| 3 | Process groups; methodology choice (waterfall vs agile) and the fact that a methodology both reduces and creates risk. |
| 4 | Scope statement; business / functional / non-functional requirements; WBS; scope baseline = scope statement + WBS; scope creep. |
| 5 | Activity list, dependencies, milestones, Gantt chart, critical path — what a schedule impact actually consists of. |
| 7 | Direct vs indirect cost; contingency reserves (known unknowns) vs management reserves (unknown unknowns); the cost baseline; quality dimensions (functionality, performance, reliability, maintainability) and acceptance criteria such as “no critical or high defects at go-live”. |
| 8 | RAID log, and the distinction between its entries: a risk is an uncertain event that may happen; an issue is a current problem that already exists or has occurred; a dependency is a person, condition, decision, service or deliverable that the project relies on. Qualitative analysis uses a probability and impact matrix. Risk responses including acceptance, which must be signed off; residual and secondary risk. |
| Cut or compressed | Why |
|---|---|
| PMBOK inputs / tools / outputs lists beyond what slides 23 and 26 print | Not emphasised, and 25 minutes rewards judgement over recall. |
| The 17-vendor anecdote; vendor courtship and account management as a career; preferred-vendor-list mechanics at a large bank; the lecturer’s own career trajectory | Context, not examinable. None of it changes an answer. |
| Balanced scorecard; IT planning stages pyramid | Named on slide 14, never developed. Recognition only — kept as one line in §7.3. |
| Contract type acronyms (CPPC, CPFF, CPIF, CPAF, FPI, FP-EPA, FFP) | Shown only as a textbook figure with no class discussion. The examinable idea is the risk-shift direction, which is in §4.6. |
| Week 10 presentation guidance (six minutes, no notes, no phone, rubric, mock sessions) | Governs the Team Project, not Exam 4. The one thing worth knowing — the exam runs first, then presentations — is in §0. |
| The Week 9 CoPC task (“Is Project Pulse worth doing?”, 500 words, two artefacts) | Already submitted; it is a CoPC assessment, not exam content. Its reasoning shape is reused in §1. |
| File | Extent | Authority |
|---|---|---|
WEEK9/INFS3703 Wk09 Seminar.pdf | All 30 slides | Official — primary |
WEEK9/seminar_week9_clean_transcript.md | Full (519 lines) | Edited transcript — emphasis and exam signals |
WEEK9/Week 9 CR Template.pptx | Full text and layout extracted | Official — primary |
WEEK9/Week 9 Dossier.pdf | Full (1 page) | Official — context |
WEEK1/INFS3703 Wk01 Seminar.pdf | Slides 8–14 | Official — exam format |
assessments/INFS3703 CoPC Assessment Guide.pdf | Full (6 pages) | Official — rubric language, attendance rule |
WEEK4/seminar recording transcript.txt | All 55 “exam” passages in context | Raw transcript — answer technique, exam scoping pattern |
WEEK8/sem transcript wk8.txt | All 26 “exam” passages in context | Raw transcript — mini-case format, risk answering |
WEEK7/wk7 seminar trascript.txt, WEEK5/wk5 seminar rec.txt | All “exam” passages in context | Raw transcript — corroboration |
WEEK9/Week9_Prework_draft/*, Week9 Project Pulse concise judgement.* | Final recommendation + audit read in full | Student work — case context only, never a definition |
Course_Weeks_1-8_Complete_Guide.md | Targeted sections | Prior derived pack — cross-checked against Wk01 slides, never relied on alone |
assessments/INFS3703 Team Project Assessment Guide.pdf | Not read | Governs the Week 10 presentation, not Exam 4 |