6.2 Project Management While Planning and Conducting Engagements
Key Takeaways
- Documented engagement objectives or charter are the scope baseline against which hours, milestones, RACI, and change control are measured
- Engagement RACI assigns Responsible, Accountable, Consulted, and Informed for this team's tasks; Accountable is a single person, not a committee
- Budget hours and dependencies — access before extracts, extracts before samples — are how you detect drift in time to re-plan instead of silently dropping tests
- Engagement risk (skill gaps, access delays, specialist timing) is distinct from the activity's inherent risk and is managed through project controls
- GIAS supervision starts in planning; status reporting to the supervisor is required even on short jobs — small size is not an exemption from a work program or a baseline
6.2 Project Management While Planning and Conducting Engagements
Quick Answer: Treat the engagement as a project. The charter or documented objectives are the scope baseline. Then you run milestones, a team RACI, budget hours, dependencies, change control (the same path as Chapter 2), engagement-level risk, and status reporting to the supervisor. GIAS supervision starts in planning, not at the draft communication. “Small job” is not an exemption.
Official A4 also asks you to describe project management concepts as they relate to planning and conducting an engagement. CIA Part 2 is the engagement exam. Project management here is how the in-charge keeps Principle 13 planning and Principle 14 fieldwork on the rails — not how the CAE builds the annual audit plan (that is Part 3 / Domain IV). Hours, people, and tools you simply do not have are Chapter 10; this section is how you run the work you did resource.
Why project management is professional work, not bureaucracy
An engagement consumes calendar time, specialist time, and the client’s time. Without a baseline, you cannot tell a scope change from a delay, or a skill gap from a lazy test. The exam’s favorite wrong answer is: skip the project-management artifacts because the job is only two weeks, the team is two people, or “we all know the process.” GIAS does not size-exempt Standard 13.3 objectives, Standard 13.6 the work program, documentation, or supervision. A 40-hour mini-review still needs a written purpose, an hours budget, a named reviewer, and a way to raise an access delay.
Scale the artifacts. Do not delete them.
Charter and objectives as the scope baseline
The engagement charter — or the documented objectives-and-scope communication, if your shop uses that form — is the baseline. Every later project-management number is measured against it: hours, milestones, RACI, and change requests.
Baseline contents the exam expects you to recognize:
- Purpose (assurance versus consulting) and objectives.
- Scope: period, locations, systems, processes, and explicit exclusions.
- Criteria (Chapter 3) at a level that tests can be designed.
- Timing window and, at a planning level, who will receive engagement communication (final-report attributes are Part 3).
- Team and specialist names at a planning level.
If the baseline lives only in someone’s head, you cannot perform change control. Chapter 2 already taught that mid-planning and mid-fieldwork changes to objectives or scope need a visible path: assess impact, obtain the right approval, communicate, and update the file. This chapter is the project side of that path. You cannot impact-assess a change if you never budgeted hours or named a milestone.
Milestones
Break the engagement into dated outcomes, not vibes. Typical assurance milestones:
| Milestone | What “done” means | Why it exists |
|---|---|---|
| Planning complete | Objectives, scope, criteria, approach, work program, and hours approved by the supervisor | Supervision starts here; fieldwork before this is unapproved testing |
| Kickoff / access granted | Opening communication issued; system access and populations available | Access delay is an engagement risk, not a client personality issue |
| Interim or sprint checkpoint | Agreed tests complete; exceptions logged; program updates documented | Agile and traditional both need a point where the supervisor sees drift |
| Fieldwork complete | Planned procedures done or formally waived; open items listed | Stops “one more sample” from silently eating reporting time |
| Supervisor review of workpapers | Review notes cleared or tracked | Quality is a project gate, not a courtesy |
Dates without owners are decoration. Each milestone has a name, a date, and a RACI role who is accountable.
RACI for the engagement team
RACI (Responsible, Accountable, Consulted, Informed) on an engagement is about this team’s tasks, not the client’s business process. Process-level RACI maps belong with later process-mapping work. Mixing the two is a common muddle: the warehouse manager is Responsible for cycle counts in the business; the staff auditor is Responsible for testing those counts.
| Task | Responsible | Accountable | Consulted | Informed |
|---|---|---|---|---|
| Objectives, scope, criteria | In-charge | Supervisor / CAE designee | Process owner | Audit client management |
| Work program | In-charge | Supervisor | IT or compliance specialist | Staff assigned tests |
| Fieldwork tests | Staff or specialist | In-charge | Process owner (walk-throughs) | Supervisor (status) |
| Scope-change assessment | In-charge | Supervisor (approval path per Chapter 2) | Process owner, specialist | CAE if significant |
| Status reporting | In-charge | Supervisor | — | Client contact as agreed |
Accountable is one person. Two “accountables” means nobody is. A common failure: the IT specialist is Consulted on the kickoff slide and then treated as Accountable for the entire integrated objective with no hours and no review. Write the RACI so a reviewer can see who signs the program, who performs the test, and who reviews the evidence.
Budget hours
Hours are the time dimension of Standard 13.5 Engagement Resources as they apply to this job. You are not writing Chapter 10’s resource-limitation implications here; you are allocating the hours you have and noticing when the allocation breaks.
A usable budget splits:
- Planning, including program write-up and supervisor review of the plan.
- Fieldwork by test area and by person (staff versus specialist).
- Supervision and rework — review notes are work, not leftover.
- Contingency for known engagement risks (access, translations, first-time process).
Timeboxing without a baseline is theater. If accounts-payable testing was budgeted 40 hours and you are at 38 with half the sample left, that is a project signal: stop, re-estimate, change scope through control, or add hours. It is not a signal to silently drop the last 50 invoices so the original date still looks green.
Dependencies
Dependencies are finish-to-start facts the calendar must respect:
- You cannot sample three-way match until the population extract is complete and reconciled to a control total.
- You cannot test user access until the IT specialist’s window and production-read access exist.
- You cannot start plant 2 counts until plant 1’s method is validated (an agile sequence) or until travel is booked (hybrid).
- You cannot close fieldwork while a scope limitation is still unescalated (Chapter 2).
Map dependencies in planning. A pretty timeline that ignores the extract-before-sample dependency is how engagements slip and then shrink scope to hit the original date.
Change control during planning and fieldwork
This is the same discipline as Chapter 2, viewed as a project. Triggers include stakeholder requests, new information, access failure, a specialist no-show, or an emerging risk. Actions: compare to the baseline, estimate impact on objectives, hours, milestones, and evidence quality, take the approval path, update the charter, program, and budget, and tell the people on the RACI.
Silent shrink to “make the date” is a scope limitation you hid. Silent expand is unplanned work with no supervision. Either way the file no longer explains what was promised. Agile backlogs do not get a free pass: pulling a new audit question into the next sprint is a program update against the baseline, not a hobby.
Risk of the engagement itself
Activity risk is what can go wrong in the process under review — duplicate payments, stock-outs, privacy incidents. Engagement risk is what can go wrong with the audit project: the team lacks a skill, the ERP access ticket takes three weeks, the specialist is on another job, the site is closed, a key manager is on leave, translation of contracts slips.
GIAS planning requires you to consider whether the team can perform the work (competency and resources). Log engagement risks with owners and responses the same way you would log a project risk:
| Engagement risk | Signal | Project-management response |
|---|---|---|
| Skill gap (no IT auditor on an ERP-integrated job) | Program has IT tests; roster does not | Obtain a specialist, change approach, or raise a resource limitation (Chapter 10) |
| Access delay | Kickoff done; no production extract | Slip the milestone, use a remote follow-up, or document a limitation if access is denied |
| Key-person unavailability | Only one warehouse manager can walk the cage | Reschedule the on-site window; do not fake a video count |
| Scope instability | Weekly “also look at…” emails | Change control, not backlog stuffing without hours |
Do not relabel engagement risk as activity risk to avoid asking for help. A missing IT skill is not “inherent risk of the general ledger.” It is a project problem.
Status reporting and supervision from day one
GIAS supervision starts in planning. The supervisor (or CAE designee) reviews objectives, scope, approach, program, and hours before substantive fieldwork is treated as approved. Status reporting is how the in-charge makes that supervision real: percent complete against milestones, hours versus budget, open engagement risks, emerging findings that may force a program change, and decisions needed.
Status can be a short written note, a dashboard, or a standing meeting — the medium is not the test. The test is whether the supervisor can still redirect the engagement in time. Saving all review for the draft communication is a Part 2 fail pattern. Full mechanics of assignment, workpaper review, and auditor evaluation are Chapter 17; here you only need the project-management truth: no status, no supervision.
The “small engagement” trap
A surprise payroll review, a two-day look at a prior issue, a short consulting memo — still an engagement. Scale the artifacts; do not skip them. A one-page objective, a 12-hour budget, a two-line RACI, two milestones (plan approved / fieldwork done), and an email status to the supervisor is project management. Zero of those items is the trap. The exam will offer “too small to need a program” as a comfort answer. It is wrong.
When hours, skills, or technology are genuinely insufficient even after this discipline, that is resource limitation — Chapter 10 — not a reason to skip project management. You cannot know you are limited if you never budgeted.
The testable sequence is: baseline first, then milestones, RACI, hours, dependencies, change control, engagement risk, and status to the supervisor from planning onward. Comfort is not a scheduling control.
A two-person team is assigned a 40-hour surprise review of overtime premiums. The in-charge wants to skip milestones, a RACI, and status notes because the job is too small for project management. Which statement is correct?
During fieldwork, the process owner asks the team to add a new warehouse to scope. The in-charge has a signed objectives memo, a 180-hour budget, and a fieldwork-complete milestone in two weeks. What is the project-management role of that signed memo?
An integrated procure-to-pay engagement includes IT access tests, but the IT specialist's start date slipped three weeks and production-read access is still pending. Duplicate-payment inherent risk in AP is unchanged. How should the in-charge classify and handle the slip?