Project Governance, the Business Case and Feasibility

Project governance, the business case and feasibility. This is where Domain 3 begins, and the exam tests something specific: who owns a project, what justifies it, and what an I-T auditor may and may not do while it happens.

Picture a project that is already staffed and building. You ask for the approved business case and the feasibility study, and there is neither. It has a budget and a deadline, but nothing on record says why the organisation is spending the money, or how anyone will later know it worked. The code may turn out fine. The governance gap is the finding.

The exam separates who delivers a project from who owns it, and questions turn on that line. So keep the two apart as we go: delivering is not the same as owning.

First role: the sponsor. A business owner who owns the business case, secures the funding, and is accountable for the benefits the project exists to deliver. When a question asks who owns the benefits, it is the sponsor, not I-T.

Second: the steering committee. It provides governance and oversight, resolves cross-functional issues, keeps the project aligned with strategy, and approves progression at each stage gate. It governs; it does not do the day-to-day work.

Third: the project manager. They run delivery, managing scope, schedule and cost, and reporting progress. They deliver the project, but they do not own the business benefits that justify it. Confusing delivery with ownership is the reliable trap.

Now, what justifies a project before it spends resources. The business case sets expected costs against expected benefits and shows how the work supports strategy. And it is not written once and filed. It is revisited at each stage gate, so a project whose costs have ballooned or whose benefits have evaporated can be stopped rather than finished out of momentum.

Feasibility is a separate question: not is it worth doing, but can it be done. Economic, does it pay back. Technical, can it be built with the technology and skills available. Operational, will the organisation actually adopt and run it. Scheduling and legal, can it be delivered in time and within the law. A project that fails feasibility should not proceed, however attractive the business case looks.

So where does the auditor sit. The auditor may review the governance and the controls being designed in, advise on what controls the system needs, early advice makes them cheaper and stronger, and report to the sponsor and the committee. What the auditor may not do is own any of it: manage the project, make the go or no-go decision, or design and build the controls.

Because the moment you design a control, you cannot later give an independent opinion on whether it works. Advise, do not own. It is the same discipline as reporting a finding rather than fixing it in Domain 1, and evaluating a risk response rather than making it in Domain 2.

And here is why the missing case matters so much. Without an approved business case and feasibility study, there is no documented justification, no confirmation the project is viable, and no benchmark. At the end of the domain, the post-implementation review will have nothing to measure success against. No case, no benchmark.

So carry this away. I-T and the project manager build and deliver; the business sponsor owns the reason and the result. When a project has no approved case, that governance gap is the finding, and the business case belongs to the business, not to I-T.