Topics in this domain
- Project Roles and Governance
- PMBOK Phases
- Gantt, PERT, Critical Path
- Function Point Analysis
- Earned Value and Project Risk
- Business Case and Feasibility
- Benefits Realization
- SDLC Phases Overview
- Requirements Definition
- System Design
- Waterfall vs. Iterative vs. Prototyping
- Agile
- DevOps and DevSecOps
- RAD, CASE, Low-Code
- Build, Coding Standards, Code Review
- Testing Levels: Unit, Integration, System, UAT
- Regression, Sociability, Parallel, Pilot Testing
- Defect Management
- Data Migration and Conversion
- Change-Over: Parallel, Phased, Abrupt
- Go-Live Readiness and Acceptance
- Post-Implementation Review
- Input Controls
- Processing Controls
- Output Controls
- Data Integrity and ACID
- EDI and E-Commerce Controls
Project Roles and Governance
Everyone has a job
An IT project is like building a house. Someone pays and decides what they want (the sponsor). A site manager runs the work (the project manager). The future residents say what they need and check the result (the users). An inspector checks it’s built properly (quality assurance). When these roles blur, projects drift, overspend or deliver the wrong thing.
| Role | Responsibility |
|---|---|
| Senior management | Commits resources and approves the project as part of the portfolio |
| Project sponsor | Senior business executive who owns the business case, provides funding, champions the project, and is accountable for benefits |
| Steering committee | Overall direction; reviews progress at stage gates; approves major changes to scope, budget or schedule; resolves escalated issues; decides go or no-go |
| Project manager | Plans, organises, staffs and controls the project day to day, within the agreed scope, time and budget |
| User management | Defines requirements, provides subject experts, takes part in testing, and formally accepts the system |
| Development management | Provides the technical people and delivers the solution |
| Quality assurance | Independently reviews deliverables and checks standards and methods are followed |
| Security officer | Makes sure security requirements are defined and met |
| IS auditor | Advises on controls and reviews project risk and governance, without making management decisions |
Three ways to organise a project
| Structure | Project manager’s authority | Main issue |
|---|---|---|
| Functional | Low; the department head decides | The project competes with normal work |
| Projectised (dedicated team) | High | Costly; the team breaks up at the end |
| Matrix | Shared with department managers | Staff have two bosses and clashing priorities |
Keeping a project under control
- An approved business case before significant spending
- Stage gates where the steering committee checks the project is still worth doing and ready for the next stage
- Change control over scope, budget and schedule, with set approval levels
- Honest status reporting on progress, risks and issues
- Quality and risk management throughout
- Closure: formal acceptance, handover and lessons learned
The auditor on a project
The IS auditor can be involved throughout a project, checking that controls are designed in, that governance works, and that risks are managed. The auditor:
- reviews business cases, requirements and designs for controls and audit trails
- attends steering committee meetings as an observer or adviser
- reviews test plans and results
- assesses readiness before go-live
The auditor doesn’t approve deliverables, design controls or make go/no-go decisions. That would impair their independence when auditing the system later.
Example. A CRM project’s steering committee approves a 40% scope increase proposed by the vendor, without the sponsor present and without updating the business case. The auditor reports a governance weakness: major changes should be assessed against the business case and approved by the sponsor.
How the exam asks about it
| If the question asks… | The answer is usually… |
|---|---|
| Who is accountable for project benefits? | The project sponsor |
| Who approves major scope changes? | The steering committee (with the sponsor) |
| Who accepts the system? | User management |
| The auditor’s role in a project | Advice and independent review; no decision-making |
| Main risk of a matrix structure | Conflicting priorities between project and department managers |
In short
- The project sponsor owns the business case and funding, and is accountable for the project delivering its benefits.
- The steering committee gives direction and makes the big decisions: scope, budget, and go or no-go at stage gates.
- The project manager plans and runs day-to-day delivery within the agreed limits.
- User management defines requirements, takes part in testing, and formally accepts the system.
- Quality assurance independently reviews deliverables and process.
- The IS auditor advises on controls and reviews risk, without making management decisions.
- Projects can be organised functionally, as a dedicated team (projectised), or as a matrix; matrix splits authority and causes priority clashes.
Exam traps
- The sponsor, not the project manager, is accountable for business benefits.
- The steering committee decides on major changes; the project manager proposes them.
- Acceptance is the users' decision, not IT's.
- An auditor who signs off a project deliverable loses independence.
- In a matrix structure, conflicting priorities between department and project managers are the main risk.
Slides
Click the slide and use the arrow keys. F toggles full screen.
Everyone has a job
An IT project is like building a house. Someone pays and decides what they want (the sponsor), a site manager runs the work (the project manager), the future residents say what they need and check the result (the users), and an inspector checks it's built properly (QA).
When these roles blur, projects drift, overspend or deliver the wrong thing.
Three ways to organise a project