CISA Systems Acquisition and Development: Project Governance, Business Cases, SDLC Methods and Control Design

A system development project is governed by the business that pays for it and run by the people who deliver it. The project sponsor owns the business case, provides the funding, owns the benefits and finally accepts that the delivered system meets business needs. A business-led steering committee directs the project: it approves scope and priorities, releases funding and makes the go/no-go decision at each phase gate. The project manager plans and runs the work within the approved scope, budget and schedule. Everyone else, from analysts to quality assurance, serves those objectives rather than owning them.

The governance weakness an IS auditor looks for is a missing business voice. When everyone directing a project sits on the delivery side, the board can judge technical progress well, but nobody at the table owns the outcome the investment was made for, so choices about what to build first, what to drop and where money goes follow delivery convenience rather than business need. Picture a payroll replacement whose board meets without the HR or finance directors: it may hit every technical milestone and still deliver a system that pays people the way the project team assumed rather than the way the business needs. A sponsor in name only, who never attends or decides, creates the same gap. This is how the auditor tests the official task of evaluating IT resource and project management for alignment with the organization's strategies and objectives: every major project should trace to a business objective and be directed by the people who own it.

During development the IS auditor advises and reviews; management designs, owns and approves. Auditor involvement is most valuable early, because control weaknesses found at requirements and design are cheap to fix. Independence is preserved as long as the auditor acts in an advisory capacity. The test is simple: the auditor will usually audit the system after go-live, and nobody can objectively audit a control they designed, specified or approved.

Taking part early does not compromise a later audit; staying away only removes the cheapest chance to influence the design. Any trade-off a finding creates, such as a delay to release, is the sponsor's decision, taken with the auditor's advice in hand. The ISACA Code of Professional Ethics and the IS audit standards on organizational independence and auditor objectivity (ITAF 1002 and 1003) apply to advisory work just as they do to assurance work. This is also how the auditor meets the official task of providing guidance to improve the quality and control of information systems.

Two project management controls matter most to an IS auditor: formal change control that protects the approved scope baseline, and progress measurement based on work actually completed. Together they show whether a project is still delivering what was approved, on the schedule and budget committed to it.

Scope control against the baseline

Every change to an approved scope must go through formal change control: a recorded request, an impact assessment and approval at the right level before the work is done. Once requirements are approved, they become the project's baseline, and cost, schedule and benefits are planned against it. A change that reaches the build informally, through a hallway conversation, a message to a tester or a favour between teams, skips both steps: nobody assesses its effect on cost, schedule, benefits or controls, and nobody with authority approves it. That is how scope creep and unauthorized functionality enter a system.

A complete impact assessment covers every dimension of the baseline, not just the budget:

• Cost: the change's own cost and whether contingency is being consumed by scope rather than kept for unforeseen risks.
• Schedule: whether the change touches the critical path and moves a committed date, especially a regulatory or contractual one.
• Benefits and risk: whether the change still serves the business case and whether it adds or weakens controls.
• Authority: changes beyond the project manager's delegated limits, or that put a committed date at risk, go to the steering committee or sponsor.

An approval that looks at one dimension is incomplete: a change can be affordable and still unacceptable because it delays a date the organization has committed to, or on time and still unacceptable because it removes a control. Good change control is managed change, not no change; freezing requirements outright stops creep but also blocks the justified changes a project needs.

Change control also has a cumulative effect. Each change can be properly approved on its own merits while the changes together alter the economics of the whole investment, which is why the business case has to be revisited when the sum of approved changes moves costs, scope or benefits materially (see the business case section below).

Measuring progress with earned value

Real progress is the value of the work completed, not the money or hours consumed. Spending shows only that money went out, and effort or self-assessed completion is input or opinion. Earned value management credits work only when a deliverable is finished, so it measures output and is the strongest evidence of actual progress.

The ratios SPI (EV ÷ PV) and CPI (EV ÷ AC) express the same comparisons as indices, where a value below 1 signals trouble. A worked example: by month six a data-migration project planned to complete work budgeted at 400,000 (PV). The deliverables actually finished were budgeted at 300,000 (EV), and they cost 360,000 (AC). SV is −100,000 and SPI 0.75, so the project is behind schedule; CV is −60,000 and CPI about 0.83, so it is over budget on what it has delivered. Its spending report alone would have shown only that 360,000 had gone out.

Critical path and float

The critical path is the longest chain of dependent tasks through the schedule; its tasks have zero float, so any slip on the critical path moves the end date by the same amount unless the work is recovered (for example by adding resources). Total float is how far a task can slip without moving the end date. For example, a non-critical task with five days of total float that slips three days leaves two days of float and the end date unchanged; had it slipped seven days, it would have exceeded its float by two, its path would have become critical and the end date would move by two days. Float belongs to its own path and cannot absorb a delay elsewhere, and delays on different paths do not add up: the end date is set by whichever path is now the longest. Critical path analysis is often shown on a Gantt chart (tasks against time) or as a PERT network, where PERT estimates a task's duration from optimistic, most likely and pessimistic estimates.

Estimating size and effort

Budgets and schedules are only as reliable as the size estimate behind them. Function point analysis estimates software size from the functions the user sees (inputs, outputs, inquiries, internal files and interfaces), which makes it usable before any code exists; counts of source lines of code depend on the language and can only be measured late. Timebox management fixes a delivery period and adjusts scope to fit it, which is how iterative methods keep schedules under control. An auditor reviewing a project plan checks that estimates have a documented basis, that the schedule identifies its critical path and that progress is reported against a baseline.

A business case is the justification for an investment: it shows that the proposed solution is the best way to meet a stated business objective, at a cost the benefits justify. It is prepared before the organization commits to a solution, normally by the sponsoring business unit, because the business owns the case. The official task asks the IS auditor to evaluate whether the business cases related to information systems meet business objectives.

A sound business case contains:

• The business objective or problem and how the investment links to strategy.
• Alternatives, including doing nothing or keeping the current system, which is the baseline every option is measured against.
• Full costs over the system's life, not just the purchase price (see total cost of ownership below).
• Measurable benefits with an accountable owner. Non-financial benefits such as customer satisfaction are legitimate if they can be measured. Benefits with no measure and no owner are the serious weakness, because nobody can later show whether they were realized.
• Risks and assumptions, and the result of the feasibility analysis.

Detailed design specifications, acceptance test plans and negotiated contract terms do not belong in a business case: they are products of later phases that depend on the case being approved first. Early cost estimates prepared before vendor prices are known are normal; they are refined at later gates.

A living document

The business case is revisited at each phase gate and whenever costs, scope or benefits change materially, and the sponsor revalidates it before further funding is released. Approved change requests can break a business case just as surely as unapproved ones if, together, they raise costs while benefits stay flat. An outside event, such as a merger that makes a system redundant for half its users or a market shift that halves expected sales, can do the same from the benefits side. Revalidation comes first because every other decision about the project depends on its answer.

The continue-or-stop decision looks forward. Money already spent is a sunk cost: it cannot be recovered whichever way the decision goes, so it is excluded. The question is whether the remaining cost is justified by the benefits still achievable. Suppose a warehouse system has already cost 3 million, finishing it needs another 1 million, and the benefits still achievable are now worth 0.8 million: finishing destroys 0.2 million of value, however much has been spent. If the remaining benefits were worth 1.5 million, finishing would be the right call even though the original case no longer holds. Any decision that adjusts the project to fit what has already been spent, rather than what is still to come, lets sunk costs drive it.

Business cases compare options on their whole-life cost and on the value they create, using total cost of ownership for the cost side and net present value as the main measure of value. Each common measure answers a different question, and the auditor checks that the measure used matches the criterion the organization's investment policy sets.

Two errors recur. The first is comparing options on purchase price alone, which leaves out most of what a system costs over its life; only a whole-life view such as TCO puts the options on equal terms. The second is using a measure that answers a different question from the one the policy asks. Payback says how fast the money comes back; NPV says how much value is created. Take two options that each cost 100. Option A returns 50 in each of its first two years and nothing after, so it pays back in two years but creates no value beyond its cost. Option B returns 30, 30, 40, 60 and 60 over five years, so it pays back only in year three but returns 220 in total. Payback prefers A; whole-life value clearly prefers B. Discounted payback fixes the time-value flaw but still ignores returns after recovery.

A feasibility study tests whether a proposed system should and can be built, from several angles, before the organization commits to it. Each dimension asks a different question, and a study that skips one leaves that risk unexamined.

The feasibility study feeds the business case: its findings on costs, technical options and adoption are what the case's alternatives and estimates rest on. Feasibility also covers the build-or-buy question: whether to develop in-house, buy and configure a package, or use a cloud service, each with different cost, control and dependency implications.

The right development methodology is the one that fits how stable the requirements are, when the business needs working software and how much formal documentation and sign-off the organization or its regulator requires. The IS auditor evaluates whether the chosen method suits the project and whether controls are built into it, rather than preferring any method in itself.

Weigh all the constraints together rather than one at a time. Requirement stability points toward a plan-driven or an adaptive method; a need for some working software early points toward splitting delivery; a need for documented approval of each stage points toward methods whose phases end in sign-offs. Incremental development is the method that combines plan-driven discipline with early partial delivery, because each planned increment still passes through its own documented phases. A public agency rolling out a permit system region by region against a published specification is a typical fit. When requirements are genuinely evolving and the business can stay closely involved, agile fits better than any sequential method.

Whatever the method, the organization can also acquire rather than build. Buying a package is an alternative route through the same life cycle: requirements still come first, and selection replaces design and coding (see the acquisition section below).

In agile development, controls are built into every increment through acceptance criteria and the definition of done, and the business directs priorities through the product owner. Because Scrum delivers small increments continuously, there is no single design phase or final review where controls could be added. Writing control and security criteria into each backlog item's acceptance criteria, and into the team's definition of done, means no increment counts as done without them. Checking controls only once at the end would find gaps when they are most expensive to fix.

The same principle extends to DevOps pipelines, where security testing is automated into the build so that every change is checked, rather than reviewed once at the end.

Prototyping and RAD risks

Prototypes are built for speed and user feedback, so input validation, access security, audit trails, reconciliation and recovery are often left out. The greatest control risk is that a prototype users like is promoted to production as it stands, carrying those gaps with it. A related risk comes from what a prototype cannot show. Users review what they see, but much of a system's control lives behind the screen: reconciliation of interfaced data, edit checks on batch loads, audit trails and recovery. A specification built from demonstrations alone tends to leave those out. The remedy is to define control requirements explicitly alongside the prototype and to treat the prototype as a model, not the finished system.

Requirements, including control requirements, are defined and formally approved by the business users who own the process, and a requirements traceability matrix proves each one was carried through design and testing. Requirements drafted by anyone other than the process owners, whether the technology team, a consultant or a supplier, describe how the drafter believes the process works. Only the owners can confirm details such as approval limits, exception handling and segregation rules, so they review and formally approve the requirements before design begins; anything built on unconfirmed requirements inherits their errors.

A traceability matrix links every approved requirement to the design elements that address it and the test cases that verify it, so a requirement with no design or test entry is visibly a gap. Other project documents each cover a single stage, such as what was agreed or what was tested, so only a matrix that links stages shows requirement-by-requirement coverage. (Running the tests themselves belongs to implementation, covered in the Information systems implementation lesson.)

Acquiring a package

When the organization buys rather than builds, the decision point for controls moves earlier. Once a package is selected, the organization can only configure it, customize it, negotiate contract terms or work around it; configuration can switch on what the package offers but cannot add controls it lacks. So control and security requirements belong in the request for proposal (RFP), where vendors must say how they meet them and the evaluation can score them, screening out a package that cannot. Any shortfall found after the choice is made is found once the organization is already committed.

• Evaluation criteria and their weights are defined and approved before proposals arrive, which ties the choice to the requirements and stops criteria being bent toward a favoured vendor. Information the vendor selects, or a single factor such as price, can inform the scores but should not replace them.
• Source code escrow places the source code with an independent third party for release on defined events such as the vendor ceasing to trade. It protects only if it covers all the code the organization depends on, including customizations built for it, and if each deposit is verified as complete and buildable; the release events and the organization's right to use the code once released must be written into the agreement.

Vendor due diligence, contract terms and ongoing vendor management are covered in the IT management lesson (Domain 2).

Controls are identified and designed at requirements and design, when building them in costs least; each later phase raises the cost of adding one. A control gap found during coding means reworking finished code, at acceptance testing it means changing a nearly finished system and delaying go-live, and after go-live it means changing a production system, the most expensive point of all. That is why audit effort on a project buys the most when spent on control requirements and designs. Preventive controls designed into the system, such as segregation of duties in the role design, are preferred over detective controls added later.

Input and processing controls

Batch controls are recalculated when a batch is received and compared with the totals prepared at source, before processing; match the control to the property that must be protected. Processing controls such as run-to-run totals and reconciliations, and output controls, are designed in the same way, and audit trails record who did what so that activity can be traced.

Segregation of duties in the design

Role design is where incompatible duties are separated most cheaply. A role that can both change an employee's bank details and release the payroll run lets one person divert salaries to an account they control. Detective controls such as logs and periodic reviews find that misuse only after the money has gone; separating the duties in the role design prevents it and addresses the root cause. If the fix costs time, the auditor recommends it before release and the sponsor decides with full information on the risk, because a conflict released into production is harder and costlier to remove.