01Home 02Work With Me 03Speaking 04Research 05Teaching 06Students 07Products 08News 09Writing 10About 11Platform New 12Contact 13Curriculum Vitae
MBI804Practice

The outside auditor: peer audit round

The class swaps post-mortems — you audit a project you did not run, and nobody gets their own back. Practise the four audit questions on a fictional scenario whose author is confident and wrong about all of them, sort eight sentences into restating, asserting and auditing, choose a risk response where mitigating is the wrong answer, then build the one-page Corrective Action Plan and export it.

IT Project Management12 min readFree, no login
MBI804 · The outside auditor: peer audit round The first screen of The outside auditor: peer audit round

This is the written version of The outside auditor: peer audit round, taken from the lesson itself. The simulations, drag-and-drop activities and quizzes only work in the interactive lesson.

In Lesson 1 you wrote up a project you lived through. This round shuffles those write-ups: everyone audits a classmate’s project, nobody gets their own back, and each of you hands that project’s sponsor a plan they could act on. This page is the training and the brief — practise the four questions on a scenario nobody has to defend, then go and do it for real.

Practice here 30 minutes Then the real one 500–800 words plus a one-page plan Needs the link your lecturer posts in Teams

By the end of this activity you can

  • Take an auditor’s stance on a project you did not run and have no stake in
  • Test a post-mortem’s claim about what moved against the evidence in its own text
  • Keep or overturn a methodology verdict by arguing from the project’s attributes
  • Tell a risk that is still open from a defect that was already closed
  • Write a Corrective Action Plan a sponsor could act on, with owners and dates

1 · The stanceYou did not run this project.

The whole reason peer review works is that the person reading has nothing invested in the conclusion. Switch the lens and watch what changes.

A post-mortem written by the person who lived through a project is the most useful document you will get and the least neutral. It is not dishonesty — it is that the version of events where the delay was somebody else’s fault is genuinely easier to remember, and the features that quietly disappeared are genuinely easier to recategorise than to mourn.

Your job is not to catch them out. It is to read the same evidence without needing any particular conclusion from it.

What the author is doingExplaining

Writing up a project they lived through, to somebody who was not there. The account has to hang together, so the parts that do not fit get smoothed.

Defending, a little

Nobody writes a post-mortem of their own project neutrally. Not dishonestly — but the version where the delay was somebody else’s fault is genuinely easier to remember.

Reclassifying

The strongest move available, and it is usually unconscious: something that was promised becomes a “nice-to-have”, and the scope never officially moved.

Fixing what they can measure

The proposed change almost always addresses the part of the project that had a number on it, because that is the part that felt like the failure.

2 · The briefFour questions, then a plan

The same four you will get in your task PDF, and the six parts of the plan that follows them. Nothing here is a surprise on the day.

  1. 1 Constraint check Does the evidence support the author’s claim about what moved — scope, time, cost or quality? Would you name a different one? Justify it from specific details in the scenario, not from general theory.
  2. 2 Methodology verdict The author names what the project was run as and what it should have been. Keep or overturn that verdict, arguing from the project’s own attributes: how volatile the requirements were, what depended on what, where the knowledge sat.
  3. 3 The missed risk Is “the risk nobody named” really the biggest one a reasonable person could have caught at kick-off? Or is there a bigger one the author still has not seen?
  4. 4 Stress-test the fix Take the author’s “what I would change”. If only that had been done, would the project genuinely have turned out differently? Where does their own fix still fail?

Then: a one-page Corrective Action Plan, in six partsProblem statement

One sentence. A condition that still exists, not a history of what happened.

Root cause

One sentence. A decision somebody made, not the last event before it broke.

Methodology adjustment

With a one-line reason. “None needed” is a legitimate answer if you can defend it.

The top risk

One risk, with a named response: avoid, mitigate, transfer or accept.

Two next actions

Each with an owner and a timeframe. No owner means it is not an action yet.

The report is roughly 500–800 words and answers the four questions in order. The plan is one page and is written to the assigned project’s sponsor, not to your lecturer — which is the constraint that keeps it short and committing.

3 · PracticeAudit one nobody has to defend

A made-up post-mortem in exactly the six fields a real one uses. Its author is confident, plausible and wrong about all four questions — which is the point.

The scenario below is fictional. It was written for this page so that you can get the four moves wrong somewhere it costs nothing, before you do it on a classmate’s real project. Read it once, then work through the four questions one at a time — the scenario stays on screen throughout.

Practice scenario Fictional

Replacing the paper sign-in sheet at a community health clinic with a tablet kiosk

We said eight weeks and it took eleven, so time is the one that gave. Scope held — every feature on the original list shipped — and we did not go over budget. The extra three weeks went on the kiosk crashing when two people tapped at once, and on waiting for the clinic’s IT person to come back from leave to open a port for us. We did drop the large-text mode and the screen-reader labels near the end, and the paper sheet stayed on the desk as a backup because we ran out of time to test what happens when the kiosk is offline, but those were not really features, they were nice-to-haves we had talked about rather than promised.

The delay End date: yes, eventually

Three weeks late in total. The crash under two simultaneous taps took two weeks to find and fix because we could only reproduce it on the real device. The port took another week, and there was nothing to do while we waited — the IT person was the only one with the rights and he was away. Nothing outside the project was waiting on us. The clinic just kept using paper for three more weeks and the manager was relaxed about it.

Methodology Run as Agile, called for Agile

We ran it in two-week sprints with a standup every morning and a board, so it was Agile, and I think that was right for it. The requirements did move — the manager kept thinking of things once she saw the screens. We showed the working kiosk to the clinic at the end of week ten, a week before go-live, and she asked for three changes, which we did in the last week. If we had written a specification up front we would have got it wrong, so Agile was the right call.

The risk nobody named Response: Mitigate

Nobody wrote down that the clinic’s IT was one person. We should have mitigated it by getting a second person with admin rights named at the start, or by asking for the port to be opened in week one instead of week nine.

What the original author would change

I would have asked for the port in week one instead of week nine. That is the three weeks, and everything else went fine. The receptionist did say in the second week that she would rather keep the paper sheet, but she came round once she saw it working.

A fictional post-mortem, written for practice in the same six fields a real one uses

Question 1 of 4Constraint check

Does the evidence actually support the author’s claim about what moved? Would you name a different corner?

Read “What actually moved” twice — the second time, watch what gets reclassified.

0 of 4 answered. In all four, the author’s own verdict is on the list and is never the strongest answer — which is the whole reason the audit is done by somebody else.

4 · What earns marksRestating, asserting, auditing

Two of these three feel like work while you are writing them, and only one of them is the work. Eight sentences, three buckets.

The brief says “do not simply restate the scenario, engage critically with the original author’s conclusions”. That sentence is doing a lot of work, so here it is as something you can sort. A claim, the evidence for it, and why it matters — all three in the same sentence, is what an audit reads like.

Restates

True, and already in the document. Adds nothing a marker did not have.

Asserts

A verdict with no evidence attached. Could have been written without reading.

Audits

A claim, the evidence for it, and why it matters. This is the one that earns marks.

Eight sentences from a draft audit · put each one in a bucket

“The author says the project took eleven weeks against a planned eight.”

“The methodology verdict is wrong.”

“The author calls the large-text mode a nice-to-have, but it is how a patient with low vision signs in unaided — that reclassification is where quality moved.”

“This project was clearly badly managed from the start.”

“The clinic’s IT person was on leave, and only he held the rights to open the port.”

“The receptionist’s objection in week two is recorded as a problem that resolved itself, with no evidence offered beyond her agreeing.”

“Agile would have solved this.”

“Sprints and a daily standup are named, but the first demo to the clinic was week ten of eleven, so the iteration loop never closed with a user inside it.”

0 right of 0 placed. A report made only of the first two buckets can be long, fluent and still say nothing a marker could disagree with — which is what makes it a weak audit rather than a short one.

5 · The plan’s hardest lineNaming a response, not reaching for one

Your plan asks for one risk with a named strategy. “Mitigate” is what almost everyone writes, and for one of these four it is the wrong answer.

Risk Only one person at the clinic holds the rights the project needs, and he takes leave mid-project.

Three of these four are best answered by mitigating or transferring. One is not, and it is the one where the consequence lands on a person rather than on a schedule or a budget — which is the test worth carrying into your own Corrective Action Plan.

6 · Your deliverableBuild the Corrective Action Plan

Six fields, one at a time, assembling into the page you attach to your report. Everything stays in this browser.

Come back to this once you have your assigned scenario and write the plan for that project. It saves as you type, so you can leave it half-finished and return. When it is done, export the PDF and attach it behind your audit report as a single file.

Start hereWhich project is this plan for?

The project you were assigned, in the author’s own words or your own. This is the plan’s header, not a finding.

Your page, so far

MBI804 · Corrective Action Plan Peer audit

The project you were assigned

Not yet answered.

Everything you type stays in this browser and is saved as you go. Nothing is uploaded from this page — export the PDF and attach it to the report you submit through the activity site.

7 · The real roundHow to run it.

Six steps, no account, and one PDF at the end. Your index number is the only thing you need.

  1. 1 Open the activity site Use the link your lecturer posts in Teams and enter your student index number. No account, no password.
  2. 2 Read your assigned scenario It is a classmate’s post-mortem, never your own. You will not be told whose it is, and you should not go looking.
  3. 3 Download your task PDF The same four questions you practised here, wrapped around your specific scenario, plus the submission checklist.
  4. 4 Write the audit Roughly 500–800 words, addressed to the four numbered questions in order. Engage with the author’s conclusions rather than restating their project.
  5. 5 Add the Corrective Action Plan One page, written as you would hand it to that project’s sponsor. The builder on this page exports it as a PDF.
  6. 6 Upload one PDF Report and plan in a single file, through the same site, using the same index number.

Where the site is

The activity site link is posted in Teams by your lecturer, because the assignments are built for one specific cohort. It asks for your student index number and nothing else — no account, no password.

Some ground rulesYou will never be given your own project

The assignment list is built so that nobody audits themselves. If you recognise the scenario as yours, say so and you will be reassigned.

Do not go looking for the author

The write-ups are anonymous to you on purpose. An audit that guesses at who wrote it stops being an audit of the project.

Audit the project, not the person

“This was badly managed” is a grade, not a finding. Every criticism should point at a decision and the evidence for it.

These are real workplaces

Somebody trusted the class with something that actually happened at their job. Keep it inside the class, and write about it the way you would want yours written about.

Submit it as your own work

The report is read as your own reasoning about a specific document. Submissions are checked, and an audit that could have been written without reading the scenario is visible from the first paragraph.

What you are marked onWhether the finding survives the evidence

Not whether you agree or disagree with the author. A well-argued “keep the verdict” beats a badly argued overturn.

Whether you argued from the project

This is LO1 in miniature. A methodology recommendation that comes from preference rather than from the project’s attributes loses the same marks here as it does in the 60% case study.

Whether the plan could be acted on

Owners, timeframes, a named response strategy. A sponsor should be able to read it once and know what happens on Monday.

Before you start the real oneCheck yourself

Four questions on the moves this activity is marked on. Nothing is stored and nothing is reported.

A post-mortem says every feature shipped, the budget held, and the project ran three weeks late with no external deadline. Buried in the same paragraph: two accessibility features were dropped at the end and described as “nice-to-haves we had talked about rather than promised”. What moved?

What this lesson saidFive things to carry into your audit

  • 01 An auditor has no stake in the author being right. That is the entire value of doing this on somebody else’s project instead of your own, and it is why the assignment never gives you back your own write-up.
  • 02 Watch for the sentence where a commitment becomes a preference. That reclassification is how quality moves without anybody approving it, and finding it is often the whole audit.
  • 03 Check a methodology against the project, not against its ceremonies. Sprints and standups are the visible half. A usable increment in front of a real user every iteration is the half that does the work.
  • 04 A closed defect is not a risk. The register is for what has not happened yet. Filling it with what already did leaves the live exposures unnamed.
  • 05 An action with no owner and no date is a wish. Six committing sentences beat six paragraphs of analysis, and that is what a sponsor can actually act on.

The practice ends here. The real one is a classmate’s project, and it is waiting behind the link in Teams.

Your lecturerBe the reader you wanted.

Somebody in this class wrote down something that genuinely went wrong at their work and handed it over. The most useful thing you can give them back is not a compliment and not a verdict — it is the one sentence in their own write-up that they read past, and what it actually means. That is what an audit is, and it is the only part of this that is hard.

Yasas Sri Wickramasinghe MBI804 lecturer

Now try the real thing.

Everything above is on one page so you can read it anywhere. The lesson itself runs in your browser: no login, no install.

More from MBI804, IT Project Management

MBI804 · Lesson What a project is, and what decides how to run it The whole of Lesson 1: pin two corners of the constraint triangle and watch the third move, slide a delay along a real schedule to find which tasks the launch date cares about, choose between Agile, Waterfall and PRINCE2 across four project shapes, then price a risk on the grid. Read the lesson → MBI804 · Lesson The Business Model Canvas How a business model works, laid out on one page in nine blocks. Then a 90-minute group activity: six people, one IT business idea, a canvas filled in digitally and presented as a short slide deck. Read the lesson → MBI804 · Lesson Waterfall, Spiral, PRINCE2 and Agile — and Scrum up close Lesson 2, and the one the 60% case study leans on. Four lifecycles drawn rather than described, a change dragged along the cost-of-change curve, Boehm’s spiral walked loop by loop, PRINCE2’s seven principles, themes and processes opened one at a time, then the whole Agile family — and Scrum in full: a clickable framework diagram, twelve “whose job is this?” situations, timeboxes that scale with the Sprint, and a board with a live burndown. Read the lesson → MBI804 · Lesson The Scrum studio: a Sprint you can watch, pause and orbit Lesson 3. Six 3D miniatures build a parcel drone through three one-week Sprints while a caption says what is happening and a timeline marks every milestone: the Product Backlog ordered on the wall, refined and estimated with Planning Poker, Sprint Planning pulling cards into the Sprint Backlog, a fifteen-minute Daily Scrum every morning, an impediment landing and being cleared, stakeholders watching the drone lift off at the Review, one improvement from each Retrospective. Voice-narrated, it pauses after each step so you can read, then a seven-question check. Read the lesson → MBI804 MBI804 · Lesson Project cost management Plan, estimate, budget — and avoid the traps that sink most IT projects. Seven interactive sections around the SecurePay NZ scenario: PERT calculator, budget builder, live S-curve and a closing challenge. Open on the lessons site ↗ MBI804 · Lesson The collaboration reflex Conflict and communication management taught through forty-five real, anonymised classroom conflicts: six full stories, four frameworks, and the one reflex experienced professionals reach for even when it is the wrong answer. Read the lesson →