Information Systems Acquisition, Development and Implementation practice questions

A project steering committee must be led by business stakeholders so that project direction stays aligned with business needs.

The steering committee sets direction for the project: it approves scope, priorities and funding and decides whether to continue at each gate. When only IT and the vendor sit on it, nobody who owns the business outcome is directing those decisions, so the project can drift from what the business needs. The other options are real project issues but do not follow from the composition described, and an all-IT committee has more technical depth, not less.

1. Identify what the steering committee decides.
2. Notice which stakeholders are missing from it.
3. Link the missing business voice to the risk of misaligned decisions.
4. Reject narrower delivery and reporting concerns.

Exam tip: A steering committee without business owners cannot keep a project aligned with business needs.

An IS auditor can advise on a project's controls but must not design, own or approve them.

Early auditor involvement is valuable because control weaknesses are cheapest to fix during design. Independence is preserved as long as the auditor acts in an advisory capacity: reviewing designs, raising observations and recommending improvements, while management and the project's own governance approve them. Approving gates or designing controls makes the auditor responsible for the very controls they later audit. Refusing all involvement keeps independence but wastes the most cost-effective point of influence, so it is the weaker choice.

1. Recognise the later post-go-live audit as the independence constraint.
2. Separate advising and reviewing from approving and designing.
3. Weigh early value against self-review risk.
4. Choose the advisory role that keeps approval with management.

Exam tip: Advise and review during development; leave design and approval with management.

The cost of adding or correcting a control rises the later in the SDLC it is identified.

Control requirements identified during requirements definition and design can be built into the system as it is created. Each later phase raises the cost: code must be rewritten after coding, tested work must be redone after acceptance testing, and a production system must be changed after go-live. With limited hours, the auditor gets the most value by reviewing control requirements and designs early.

1. Recall that rework costs grow phase by phase.
2. Locate where controls are first specified.
3. Compare the cost of change in each later phase.
4. Choose the earliest phase listed.

Exam tip: Get involved at requirements and design: controls built in early cost least.

Scope changes during development are controlled through a formal change request process against the approved baseline.

Changes made directly at users' request bypass the project's baseline: nobody assesses their effect on cost, schedule, benefits or controls, and nobody with authority approves them. That is how scope creep and unauthorized functionality enter a system. Formal change control fixes the root cause by requiring each change to be requested, assessed and approved. Freezing all requirements is too blunt, documenting afterwards does not control the decision, and a cap still lets unassessed changes in.

1. Identify that changes bypass the approved baseline.
2. Ask what control decides whether a change should happen.
3. Prefer the control that assesses impact before work starts.
4. Reject options that only record or limit changes.

Exam tip: Every scope change needs a request, an impact assessment and an approval before it is built.

The business case is revisited whenever costs, scope or benefits change materially, not only when a project is approved.

Each change request was approved individually, so change control worked, but together they have changed the economics of the whole investment. With costs up and benefits flat, the original justification may no longer hold, so the sponsor should revalidate the business case before further funding. Re-baselining and adding contingency are management actions that assume continuation, and recommending cancellation jumps to a conclusion before the evidence exists.

1. Note that individual approvals do not confirm the overall justification.
2. Compare the new costs with the unchanged benefits.
3. Identify the business case as the decision document for continuing.
4. Choose revalidation by the sponsor before more funding.

Exam tip: Approved changes can still break the business case; revalidate it before funding continues.

Earned value analysis measures progress by completed work, not by money or effort spent.

Spending 60 percent of the budget proves only that money was spent. Earned value assigns each deliverable its planned value and credits it only when completed, so the auditor can compare the value of work actually done with the work planned by now (schedule variance) and with the actual cost (cost variance). Hours logged and budget burn measure input, and the manager's own estimate is not independent evidence.

1. Spot that the report equates spending with progress.
2. Look for a measure based on completed output.
3. Prefer evidence that compares output with both plan and cost.
4. Reject input measures and self-assessments.

Exam tip: Progress is the value of work completed, not the budget or hours consumed.