Project Management Controls in System Development

Introduction
System development projects are among the riskiest initiatives an organization undertakes. They consume significant capital, change how people work, and frequently fail to deliver on time, within budget, or to the required quality. For the IIA Certification in Risk Management Assurance (CRMA), the topic Project Management Controls in System Development sits within the domain of Evaluating Risk Management Processes. The exam expects you to understand how project management controls mitigate the risks inherent in building or acquiring systems, and how a risk assurance professional evaluates whether those controls are adequate and effective.

Why This Topic Is Important
1. High failure rates. Industry studies consistently show that a large share of IT projects are late, over budget, or cancelled. Weak project management is the most common root cause.
2. Material financial exposure. System projects often represent multi-million-dollar investments. Cost overruns and abandoned projects directly erode shareholder value.
3. Operational and strategic risk. A failed ERP, core banking, or customer system can disrupt operations, damage reputation, and derail strategy.
4. Control and compliance risk. Systems built without disciplined controls may lack proper segregation of duties, audit trails, data integrity, or regulatory compliance features.
5. Governance expectation. Boards and audit committees expect assurance that major projects are governed, monitored, and that risks are managed proactively rather than discovered after go-live.
6. Internal audit's role. The IIA Standards require internal audit to evaluate risk exposures relating to information systems and to assess the adequacy of controls over significant projects. The CRMA builds on this by focusing on the risk management dimension.

What Project Management Controls Are
Project management controls are the policies, procedures, structures, and activities that ensure a system development project achieves its objectives for scope, schedule, cost, quality, and benefits while managing associated risks. They operate at two levels:

Governance-level controls (the oversight environment):
- Executive sponsorship and a project steering committee with clear authority.
- Approved business case with defined benefits and investment criteria.
- Portfolio-level prioritization and alignment with strategy.
- Defined roles, responsibilities, and accountability (sponsor, project manager, business owner, IT, QA, internal audit as advisor).
- Stage gates or phase approvals requiring formal sign-off before proceeding.

Project-level controls (day-to-day management):
- Project charter and detailed plan (work breakdown structure, milestones, resource plan).
- Scope management and formal change control.
- Schedule and budget tracking against baselines (e.g., earned value analysis).
- Risk and issue registers with owners, ratings, and mitigation actions.
- Quality assurance including requirements traceability, testing strategy, and acceptance criteria.
- Communication and status reporting to stakeholders.
- Resource and vendor management, including contract controls.
- Documentation standards and configuration management.
- Post-implementation review and benefits realization tracking.

How It Works: Controls Across the System Development Life Cycle
Project management controls wrap around the System Development Life Cycle (SDLC). Whether the organization uses waterfall, iterative, or agile methods, the control objectives are similar even if the mechanisms differ.

1. Initiation and Feasibility
Key controls: business case approval, feasibility study (technical, economic, operational, legal), identification of the sponsor, preliminary risk assessment, and alignment with the IT and business strategy. Risk addressed: investing in the wrong project or one that cannot succeed.

2. Planning
Key controls: project charter, detailed project plan, baseline budget and schedule, resource allocation, risk management plan, quality plan, communication plan, stakeholder analysis, and definition of acceptance criteria. Risk addressed: unrealistic expectations, unclear scope, unmanaged dependencies.

3. Requirements and Design
Key controls: user involvement in requirements, formal sign-off of requirements, requirements traceability matrix, inclusion of security, privacy, and internal control requirements (auditability, segregation of duties, data validation), design reviews, and architecture approval. Risk addressed: building a system that does not meet business needs or lacks embedded controls.

4. Development / Build (or Configuration and Acquisition)
Key controls: coding standards, peer reviews, version control, separation of development, test, and production environments, vendor performance monitoring, and controls over customizations to packaged software. Risk addressed: defects, unauthorized changes, vendor non-performance.

5. Testing
Key controls: test strategy covering unit, integration, system, regression, performance, security, and user acceptance testing (UAT); test cases linked to requirements; defect tracking; independent testing where practical; formal UAT sign-off by business owners. Risk addressed: releasing a system with errors or control gaps.

6. Implementation / Go-Live
Key controls: data conversion and migration controls with reconciliation, cut-over plan, rollback or contingency plan, training, go/no-go decision by the steering committee, and parallel or phased rollout where risk warrants. Risk addressed: business disruption, data loss, user rejection.

7. Closure and Post-Implementation
Key controls: post-implementation review (PIR) comparing results to the business case, lessons learned, benefits realization tracking, transition to operations and support, and formal project closure. Risk addressed: failing to learn from problems and failing to capture promised benefits.

Cross-Cutting Monitoring Controls
- Status reporting: regular, accurate, and honest reporting of progress, often using red/amber/green indicators tied to defined thresholds.
- Earned value management: comparing planned value, earned value, and actual cost to detect schedule and cost variance early.
- Change control board: evaluating the impact of scope changes on cost, time, quality, and risk before approval, to prevent scope creep.
- Risk register: continuously identifying, assessing, responding to, and monitoring project risks; escalating those beyond tolerance.
- Independent quality assurance or project health checks: periodic reviews by a party independent of the project team.

Methodology Considerations: Waterfall vs. Agile
The exam may test whether you understand that control objectives remain constant while control mechanisms adapt. In waterfall, controls are enforced through sequential phase gates and comprehensive upfront documentation. In agile, controls are embedded in sprint planning, definition of done, backlog prioritization by a product owner, continuous testing, sprint reviews, and retrospectives. An auditor should not conclude agile is uncontrolled simply because documentation is lighter; instead, evaluate whether scope, quality, risk, and stakeholder engagement are managed through the iterative cadence.

The Risk Assurance Professional's Role
Under the CRMA perspective, the practitioner evaluates how well project risks are identified, assessed, responded to, and monitored. Typical evaluation steps include:
1. Confirm a governance structure exists and functions (steering committee minutes show real decisions, not rubber stamps).
2. Review the business case and verify that assumptions are monitored and benefits are tracked.
3. Assess whether the project risk register is current, risks have owners, and responses are appropriate and executed.
4. Test the change control process for completeness and authorization.
5. Compare reported status to underlying evidence (watch for optimistic reporting).
6. Evaluate testing adequacy, especially UAT sign-off and coverage of control requirements.
7. Review data conversion reconciliations and cut-over readiness.
8. Confirm that lessons learned and PIR findings feed back into the organization's project methodology.

Internal audit can participate in three ways, and the exam likes to distinguish them: as an assurance provider (auditing the project or its controls), as a consultant or advisor (offering control advice during development), or by performing a post-implementation review. In all cases, independence must be preserved: auditors should not design, build, or take management decisions on the system they may later audit.

Common Weaknesses and Red Flags
- No executive sponsor, or a sponsor who is disengaged.
- Business case never updated after major scope or cost changes.
- Scope creep through informal changes without impact analysis.
- Status reports consistently green while milestones slip.
- Risk register that is static, generic, or lacks owners and dates.
- Compressed or skipped testing to protect the go-live date.
- Users not involved in requirements or acceptance.
- Security and audit requirements added as an afterthought.
- Heavy reliance on a vendor without contract milestones, acceptance criteria, or exit provisions.
- No post-implementation review, so benefits are never measured.

Key Terms to Know
Business case – justification for the project linking costs to expected benefits.
Steering committee – senior oversight body providing direction and approving stage gates.
Project charter – document formally authorizing the project and the project manager's authority.
Scope creep – uncontrolled growth in project scope.
Change control – formal process for evaluating and approving changes to scope, schedule, or budget.
Earned value management (EVM) – technique integrating scope, schedule, and cost measurement.
Requirements traceability matrix – links requirements to design, build, and test cases.
User acceptance testing (UAT) – testing by business users to confirm the system meets requirements.
Stage gate / phase review – formal checkpoint requiring approval to proceed.
Post-implementation review (PIR) – evaluation after go-live of outcomes versus objectives.
Benefits realization – process ensuring projected benefits are actually achieved.

Exam Tips: Answering Questions on Project Management Controls in System Development

Tip 1 – Think in terms of control objectives, not just activities. When a question asks for the best control, map each option to the risk it addresses. The correct answer is usually the control most directly aligned with the specific risk in the scenario (e.g., scope creep → formal change control; benefits not achieved → post-implementation review and benefits tracking).

Tip 2 – Prioritize governance and preventive controls. IIA-style questions tend to favor answers involving sponsorship, steering committee oversight, stage-gate approvals, and upfront requirements sign-off over after-the-fact detective measures, unless the question specifically asks about detection or monitoring.

Tip 3 – Know the right control for each SDLC phase. If a scenario mentions data migration, think reconciliation and rollback plans. If it mentions go-live, think go/no-go decision and UAT sign-off. If it mentions requirements, think user involvement and traceability. Matching the control to the phase eliminates distractors quickly.

Tip 4 – Remember internal audit independence. If a question asks what the internal auditor should do during a system development project, choose options that involve advising on controls, reviewing deliverables, or reporting concerns to the steering committee. Reject options where the auditor designs controls, approves changes, or makes management decisions, as these impair objectivity.

Tip 5 – Watch for optimistic reporting scenarios. When a question describes status reports that are all green but milestones are slipping or budgets are overrun, the best auditor response is to independently verify progress against evidence (milestone deliverables, EVM data, defect logs) and escalate to the steering committee, not to accept the project manager's assurances.

Tip 6 – Distinguish agile from uncontrolled. If an option implies that agile projects cannot be audited or do not need controls, it is wrong. The correct answer evaluates how agile ceremonies and artifacts (backlog, definition of done, sprint reviews) achieve control objectives.

Tip 7 – Pick the most comprehensive and risk-based answer. When two options look correct, the better one typically addresses the root cause or the highest risk, or applies to the whole project rather than a single element. Avoid answers that are overly narrow or merely procedural.

Tip 8 – Read qualifiers carefully. Words like most important, primary, best, first, and least likely change the answer. For first step questions, the answer is usually about understanding the project (reviewing the business case, charter, and governance) before testing detailed controls.

Tip 9 – Link to the CRMA domain. Frame your answer around the risk management process: identification, assessment, response, monitoring, and reporting. Questions in this domain reward answers that evaluate whether the process for managing project risk is sound, not merely whether a single control exists.

Tip 10 – Use elimination. Discard options that: violate independence, address a different risk than the one described, occur in the wrong phase, or rely solely on management representations without evidence. What remains is usually the answer.

Worked Example
Scenario: A large ERP implementation is six months behind schedule and 40 percent over budget. The project manager reports that scope has expanded significantly at the request of various business units. Which control weakness most likely contributed to this situation?
A. Inadequate user acceptance testing.
B. Lack of a formal change control process.
C. Insufficient data conversion reconciliation.
D. Absence of a post-implementation review.

Analysis: The scenario describes scope expansion leading to time and cost overruns, which is classic scope creep. UAT (A) and data conversion (C) address quality and migration risks, not scope. A PIR (D) occurs after go-live and cannot prevent overruns during the project. The best answer is B, because formal change control requires impact assessment and authorization before scope changes are accepted.

Summary
Project management controls in system development ensure that major system investments are governed, planned, executed, monitored, and closed in a disciplined way that manages risk and delivers intended benefits. For the CRMA exam, focus on how controls map to risks across the SDLC, the governance structures that provide oversight, the role and independence of internal audit, and the warning signs of a troubled project. Approach each question by identifying the risk in the scenario, matching it to the control that most directly addresses it, and respecting the principles of risk-based assurance and auditor objectivity.