Project Management and Change Control

Project management is the application of knowledge, skills, tools, and techniques to project activities to meet the project requirements. A project is a temporary endeavour undertaken to create a unique product, service, or result. It has a defined beginning and end, unlike ongoing operations like processing payroll. Change control is the formal process by which changes to a project's scope, schedule, or resources are introduced and approved. Together, they form the discipline that ensures an IT system is delivered on time, within budget, and with the required quality.

Why do organisations need formal project management? Without it, work is reactive and disorganised. Teams might build features nobody asked for, run out of money halfway through, or deliver a system that cannot connect to other company systems. Project management provides a structured lifecycle: initiation, planning, execution, monitoring and controlling, and closure. In each phase, specific documents and reviews are required.

A key framework used by many auditors is the PMBOK Guide (Project Management Body of Knowledge) from the Project Management Institute. It defines ten knowledge areas, including scope management, time management, cost management, quality management, and risk management. For CISA, the most important areas are scope, time, cost, quality, and risk. - Scope management ensures that the project includes all the work required—and only the work required—to complete the project successfully. The scope statement is the formal document that lists what is in and out of scope. Scope creep is the uncontrolled expansion of project scope without adjustments to time, cost, or resources. It is a primary cause of project failure. - Time management involves defining activities, sequencing them, estimating durations, and developing a schedule. The critical path is the longest sequence of activities that must be completed on time for the whole project to finish on schedule. Any delay on the critical path delays the entire project. - Cost management includes estimating, budgeting, and controlling costs so the project can be completed within the approved budget. Earned Value Management (EVM) is a technique that compares planned work to actual work and costs to measure project performance. - Quality management ensures the project's deliverables meet the required standards. It is not about inspecting defects out at the end; it is about building quality into processes throughout.

Change control is often formalised through a Change Control Board (CCB). The CCB is a group of authorised stakeholders who review and approve or reject change requests. Every proposed change must be documented, evaluated for impact on scope, schedule, cost, quality, and risk, and then voted on by the CCB. Approved changes update the project baseline—the original plan against which performance is measured. Unapproved changes are forbidden. This process prevents unauthorised modifications that could introduce security vulnerabilities, break integrations, or waste resources.

The distinction between a project and operational work is essential. A project is temporary and unique. Operations are ongoing and repetitive. An IT professional might manage a project to deploy a new customer relationship management (CRM) system (a project). Once deployed, maintaining user accounts and fixing bugs is operational work. Change control applies to both, but the process often differs: a project's change control is typically more flexible than the strict change management for a live production system.

For the CISA exam, you need to understand that the auditor's role is to evaluate whether project management practices and change control processes are adequate and effective. The auditor does not manage the project. The auditor reviews project documentation, observes status meetings, examines change request logs, and tests whether controls are working as intended. They look for red flags like missing risk assessments, undocumented changes, or projects that have missed every milestone.

Maria is an IT project manager at a mid-sized insurance company. She is tasked with implementing a new claims processing application—a project budgeted at £2 million with a twelve-month timeline. The project is in the planning phase. She works with her team to create a work breakdown structure (WBS), breaking the project into smaller tasks: requirements gathering, database design, front-end development, integration testing, and user training. She uses Microsoft Project to build a schedule, identifies the critical path (which includes database design and integration testing), and gets the plan approved by the steering committee.

Six months in, the claims department asks for a new feature: the system should automatically flag duplicate claims using an external fraud database. This request was not in the original scope. Maria does not say yes immediately. She asks the product owner to submit a formal change request. The change request describes the proposed feature, outlines the business need, and requests an assessment.

Maria then leads an impact analysis. She estimates that:

Maria presents the change request and impact analysis to the Change Control Board. The CCB includes the IT director, the claims department head, the chief financial officer, and an information security representative. They discuss the trade-offs. The claims department head argues the feature will reduce fraud losses significantly. The CFO worries about the budget overrun. The security officer notes that the new integration must comply with GDPR data protection requirements. The CCB approves the change but requires the security assessment to be completed before development begins.

Maria updates the project baseline: she revises the schedule, increases the budget by £150,000, and adds a new work package for security assessment. She communicates the approved change to the team and updates the project documentation. Every team member understands that no further changes can happen without going through the same formal process.

Without this controlled process, the same feature might have been added unofficially by a developer who heard about it from a colleague. The developer might have worked on it for weeks, taking time away from the critical path tasks. The budget would have been exceeded with no visibility, and the security risk might have gone unaddressed until a data breach occurred. The auditor reviewing this project would examine the change request log, verify that all changes went through the CCB, ensure the impact assessment was documented, and check that the baseline was formally updated. They would also look for evidence that the team followed the process—not just that the policy existed on paper.